The graph and the browser

The problem with regard to the place of data storage (where) is dealt with in the description of the technical environment. In this paragraph attention is focused on how a group's data is stored. After the presentation of the storage structure we have chosen, a tool is introduced with which the group members can obtain an overall picture of their shared environment or the group memory.

COOPerator's storage structure

Some demands on the storage structure are listed here:

  1. it must be capable of handling a rather large amount of data in a structured way;
  2. it should be easy to search;
  3. it must be able to code a lot of blobs of data and their interconnections;
  4. preferably be versatile;
  5. should be easy to code to keep complexity low;
  6. it must support easy storage of hypertext structures.

The first, second and fifth point are surely satisfied by a structure like a tree. Trees are well documented, have good search algorithms and are rather easy to code. In the Quilt system which is described by Leland et. al. [1988], a tree structure is used to store the data of the document which is being worked on. But this lacks the hypertext-like aspects we wanted to provide the prototype with. Moreover, a tree is only capable to support the existence of one group whereas we want to support multiple groups. Departing from the tree structure the logical way to look is to the graph structure, which fits nicely to the list of demands. Even though searching a graph is a little more difficult, this is offset by the enhanced ability to store and code both the data in typed nodes and the connections in typed edges. Furthermore, given that a graph is just a collection of nodes and a collection of edges, this is an easily expandable and versatile structure.

The browser

Using the document facility or the agenda, group members only work on a distinguished subset within the graph. To provide them with an overall view of their shared workspace, we built a graphical browser. Within the browser, peers can either view the contents of all nodes or play them (e.g., whenever the node happens to be a multi media part) outside the normal context of the nodes (e.g., an appointment is normally examined within the context of the agenda). Essentially, this tool should assist the co-authors in their continuous update of the common ground.

Dependent on the group size, the number of joint documents, and the activity of the peers, the graph may become very large though. To prevent that co-writers get lost in their own group's work space, the browser has to be equipped with some navigational aids. For instance, COOPerator's graphical browser provides its users with a so called history list of their actions.


Index TOC

Sjoerd Michels, Tilburg, The Netherlands