Open Hypermedia Systems Working Group

Collaboration via OHS - Analysis

Preliminaries

Authors
Jörg Haake

GMD-IPSI, Germany


Updates
Most recent: February 12, 1997


• created February 12, 1997
  

References


Other Links


• Scenario
  
• OHS mailing list discussion (when available)

Goals of the Scenario

Support for references between distributed hyperdocument partitions


Support for references from a hyperdocument maintained by one hypermedia environment into another hyperdocument maintained by another hypermedia environment. This includes not only the issue of addressing (URL's) but also of document retrieval and display of "foreign documents" and the storage of references to remote documents (parts).

Support for access control


To control access to documents/hypermedia objects, user authentification and the definition of access rights is required.

Support for group awareness


There must be some group awareness mechanism that allows the collaborators to recognize each other's presence (and activities). This mechanism consists of awareness detection (potentially in the server) and awareness presentation (in the client/browser).

Support for joint editing sessions


Thus, browsers need a mechanism to contact other/remote browsers and to establish a cooperative editing session. In such a session, the authors want to share a joint workspace (e.g., the workspace of one author) and a joint view (potentially some relaxed WYSIWIS presentation). For this, the coupled browsers or hypermedia environments need to translate their respective navigation commands into each other's "command language". Furthermore, the translation of different display techniques (even of a shared document) need to be supported. Additional communication channels (such as A/V or a chatbox) need to be provided.

Dynamic and spontaneous session creation, join and leave must be supported.

Support for consistency between remote document partitions


If co-authors change a document partition with dependencies to other remote document partitions (e.g., removing an object that is referenced by other remote objects) then consistency should be maintained. This can be achieved by different approaches: e.g., notification mechanisms, transactions, object replication and synchronization techniques.

Characters

Authors


Authors are humans using a hypermedia authoring environment to create and manipulate (possibly distributed) hyperdocuments.

Browsers


Browsers are clients (front end) of a hypermedia authoring environment providing (navigational) access to a hyperdocument provided by the server (back end) of a hypermedia authoring environment.

Servers


Servers are the back end of a hypermedia authoring environment providing storage, computational and retrieval functionality for accessing and manipulating hypermedia documents (nodes, links).

Hyperdocument


A hyperdocument is a graph structure consisting of (typed) nodes and (typed) links, that can be partitioned into one or more subsets each maintained by a server. Thus, links can either connect objects within one links (and be contained in that partition) - so called intra-server links - or links can connect objects located in different partitions (or be themselves contained in a different partition) - so called inter-server links). The same is true for references in general (say, objects referenced in aggregate nodes (composites)).

Session


A session is characterized by a set of collaborators using applications (here browsers) to access and manipulate a shared artifact (here the shared hyperdocument part) within a certain time interval. Different types of sessions can be defined depending on the specific kind of support they provide for the collaborators (e.g., extent of WYSIWIS property of shared views, synchronicity, communication channels, or specific operations).

Data

1. Hypermedia objects
   
   Description
   
   Nodes (atomic, composite), Links, Anchors etc. with attributes
   
   Access Issues
   
   Hypermedia objects are accessible by every browser that can connect to the server providing the object. Access rights might restrict access for certain authors.
   
   Synchronisity Issues
   
   Many authors can have simultaneous read access to the same hypermedia object. In order to ensure consistency, only "consistent" updates are allowed (issue of concurrency control).
   

2. Usage Informaion
   
   Description
   
   This is a record identifying who is currently working on a specific partition, and on which part of it. Potentially, more specific information (login time, current action etc.) could be provided. This information is required by the group awareness mechanism.
   
   Access Issues
   
   Every browser displaying a part of a partition can access the usage information of that partition. By accessing the usage information of related partitions, a kind of fisheye view of the usage situation could be provided.
   
   Synchronisity Issues
   
   Multiple parallel reads, but only the currently active browser of a user can update its user's usage information. If multiple browsers can execute in parallel, this is either a concurrency control problem or one needs to distinguish between different threads.
   

3. Session Information
   
   Description
   
   Describes the actual state of a session (e.g., users and their browsers, shared artifact, sharing properties, information required for joining, etc.). Note, a session is always stored at the partition where the shared artifact is maintained (e.g., represented by a composite node). The sharing properties can be arbitrarily complicated (e.g., coupling of view attributes, translation of certain operations between browsers).
   
   Access Issues
   
   Every browser in a session can read and potentially write the state (depending on floor control policy etc.). Other browsers can only read the session information for joining or for generating collaboration state overviews.
   
   Synchronisity Issues
   
   Is a floor control and concurrency control issue.
   

   ---

   Requirements for Participating Applications:

   Requirements for participating browsers are:
   Accessing and displaying group awareness
   

   Each browser needs to be able to access the usage information of the partitions it works on and to create some kind of visualization of the current usage situation in the workspace (or in the whole partition).

   Displaying remote partitions
   

   Each browser needs to be able to access a part of a remote partition via its link service and to display the retrieved object. If this is not possible, the next best option is to start the browser of the hypermedia environment maintaining the target partition on the user's workstation, so that the remote partitionis displayed via its natural interface. However, this requires the presence of an installed browser software on each participating user's machine.

   Following links accross partitions
   

   When asking the link server to trigger the destinations of a inter partition link, the link server has to trigger the display of th target objects (see above).

   Identifying its user
   

   To enable access control in the link server or stores, a user id must be provided.

   Commands for joining and leaving sessions
   

   Browsers must provide a UI for joining and leaving sessions, and controlling session behavior.

   Shared workspace functionality
   

   Browsers must provide both, functionality for transmitting their user's activities to other session members (e.g., scrolling, pointing, input activity) as well as functionality for receiving updates from remote collaborators' browsers (e.g., updating collaboration status, display etc.). This either requires a direct communication channels between cooperating browsers in a session, or a mediator object provided by the link server (see below).

   Notification interface
   

   A browser needs an interface for displaying notifications caused by remote collaborators' activities (e.g., removing referenced objects during the user's absence) and to deal with potential problems caused by these changes.

   ---

   Requirements for Link Server:

   Provide and update usage information for browsers
   

   Whenever browsers access objects via a link server, the respective usage information must be updated. Browsers can ask for usage information.

   Provide and update session information
   

   Whenever browsers access sessions via a link server (join or leave or change sharing aspects, or create sessions), the respective session information must be updated. Browsers can ask for session information.

   Provide notification information
   

   Browsers might ask for notifications (provided by the store) explicitly, or the link server might call the browser to deliver notifications actively.

   Provide access to other link servers information
   

   There are two general options when solving the problem of how browsers can access remote partitions: Either all requests are send to the local link server and transparently propagated to the target link server, or the browser itself can interact with several link servers at the same time.

   Provide mediator service to connect session members
   

   If a mediator object or service is used that mediates the communication between browsers in a session, this service can also be used to translate operations between different browsers. A more difficult problem is the translation between different display techniques.

   Public interface for access by other link servers or browsers
   

   Is required to allow other browsers to - directly or by using their link server - access objects maintained by this link server.

   ---

   Requirements for Stores:

   Storage of hypermedia objects
   

   as usual, inluding references to objects maintained by other link servers/stores.

   Storage of usage information
   

   see above

   Storage of session information
   

   see above

   ---

   Implementations:

   This section of the scenario is not to be filled in until the scenario has been circulated among the OHS mailing list (ohs@csdl.tamu.edu).

   ---

   Protocol Requirements:

   ---

   Jörg Haake
   GMD-IPSI, Germany
   haake@darmstadt.gmd.de
   http://www.darmstadt.gmd.de/~haake/