CI Development Blog

The Use Case

The use case in question is when someone in a community, say Dr. Chu, submits a document that they want to manage further in their community. (This is in the Science ConOps.) Maybe they even want to develop a document collaboratively, say as a web page, even in real time. (This is not in the Science ConOps.) This need scales greatly: An org such as a classroom may have many such documents to manage or build, and there may be hundreds of such classrooms, for just one example.

How will ION support the corresponding features that will be expected? This question focuses on the community-collaboration-centric features of the ION system: What services will a community need to work collaboratively on and with materials, and what is our model for providing those services?

Information Resources vs Documents

Documents as described here are of course just one type of information resource as understood by ION. It is interesting to consider these concerns for other kinds of ION resources, but such consideration is not central to addressing the principal question of collaborative work on typical office documents (word processing, drawing, spreadsheet, presentation, vocabulary/ontology, and mind map being the most typical and relevant examples).

Models for Providing Collaborative Features

One can imagine 3 models to support these collaborative features in an ION context:

1) Self-Complete Model: ION is self-sufficient and provides a document management and content development capability. (See Desirable Features for Community Support below.) Integration Level: Very strong. Difficulty Level: Very challenging.

2) Simple Model: We expect users to go elsewhere for these capabilities; at most ION provides the ability to link to the materials by reference. ION can get a document and return a document, but it's always a blob, or at most a document that ION can display if it's in a known format. ION can pass messages and organize them into threads, but not maintain an edited collection of material in a single document, especially involving styles. Integration Level: Very weak. Difficulty Level: Very simple.

3) Integrated Model: ION provides the integrating front end to document management and content development solutions. ION can accept a document that is submitted, pass that document through to a dedicated document management system that is federated with ION, and presents an ION interface to the document (locally, or via a view into the federated document management system). ION can keep track of multiple related documents and display them in the integrated interface. For document development, ION likewise provides the connectivity to a content development capability, e.g., via an embedded applet. The actual content is kept in an external system a la Google docs, but the integration with ION information resource model is sophisticated and relatively seamless. Integration Level: Highly dependent on the implementation approach. Difficulty Level: Highly dependent on the implementation approach.

Our Documented Plans

We have laboratory and classroom facility services that relate, to wit these AS components:

  • Workspace services: Capabilities related to defining and using virtual workspaces of resources of many kind.
  • Interactive workspace: User interfaces and application integration services supporting interactive workspaces for data access, analysis, synthesis and publication activities.
  • Social networking service: Provides services to set up and manage social networks for scientists and educators that include bulletin boards, discussion forums. Includes integration/inclusion of content from web social networks.

The last is most suggestive of the kind of document creation and management envisioned by the use case.

In the Architecture and Design, the following appears under Virtual Collaboration Services: Capabilities include definition of a project by a project lead role, invitation of individuals to collaboration, selection of the resources available to all project members, management of project membership and resource use policy, use of data processing, analysis and visualization tools, the capability to define workflows and the publication of results to the public.

This clearly alludes to document management features, but it is ambiguous how rich those features will be.

Do we have any other design or other documentation that speaks to these capabilities?


Desirable Features for Community Support

At minimum for satisfied users, a collaborative document management system should be able to deal with group- and ID-based security models that support spontaneous group creation by users, nice and flexible document versioning, document typing (Word doc vs Excel doc vs ...), renaming and aliasing, URIs, viewing, and grouping (e.g., into hierarchical or smart folders), and subscription to document changes. This is essentially an OS.

A collaborative content development system should be able to provide the services that Google docs does, with the additional capability to point to specific parts and versions of the document, e.g., via HTTP anchors in URLs.

Existing Solutions

Existing collaborative solutions within our price range are limited, though steadily improving.

For document management: Confluence has a limited security model, poor content presentation, no user creation of groups (though there is a plugin for that), and limited document versioning and taxonomy utilization. Drupal (my favorite) after some customization (for groups and security/workflow) provides a better user experience (arguably) and much better taxonomy capabilities than Confluence, but in the end similar weaknesses.

For content development: Google docs is ahead of the pack, but needs the additional capabilities above. Its most valuable advancements are the real-time editing and the user creation of security groups. MediaWiki has nicer presentation/tracking of components of a document, but no real-time collaborative editing, and I think limited security.

Note that Confluence has plugins by AppFusions allowing access to Google docs and Alfresco (latter in development). This is interesting because (a) it represents a model for integrating one service presentation inside another, (b) AppFusions hints at some of the challenges of so doing, and (c) AppFusions has a consulting service for integrating services of this type.

Load Balancer Designs (2)

Unable to render embedded object: File (A10-LoadBal-Design) not found.Unable to render embedded object: File (Cisco-LoadBal-Design) not found.Unable to render embedded object: File (Ops environment in LB) not found.