Cooperative hypermedia systems: a Dexter-based architecture. (Special Section: Hypermedia) (Technical)

The hypermedia work discussed here is derived from our participation in the DeVise project at Aarhus University in Denmark. Developing tools to support cooperative design in a variety of application areas including large engineering projects is one of the project's goals. The primary user organization in the Esprit projects EuroCoOp and EuroCODE, from which the DeVise group receives partial funding, is constructing one of the world's largest tunnel and bridge "links." The use settings for our tools are characterized by cooperative work distributed over time, space and hardware platforms. Cooperative work in engineering projects raises several requirements for hypermedia, such as: shared databases, support for awareness among users of shared materials, access from multiple platforms, open architecture for integration of applications, portability, extensibility and tailorability. The possibility for integrating applications already developed for the engineering domain with hypermedia facilities was a particularly important requirement to meet. For a detailed discussion of our use setting, the engineering project, and its CSCW and hypermedia requirements, see [5].

In an effort to address these requirements, we based our hypermedia system on the Dexter Hypertext Reference Model [10, 11] (called "Dexter" throughout this article). Dexter makes a clean separation between storage and run-time aspects of a system. Furthermore, it distinguishes the hypermedia system's responsibilities from those of other software with which it is integrated. The result is three layers, called storage, run-time, and within-component. Dexter defines the internal structure of the storage and run-time layers, but leaves the within-component layer's structure open. For example, within the storage layer Dexter defines the concept of component (covering the traditional notions of nodes and links) and a variety of subtypes of component. According to Dexter, a hypertext is simply a collection of components. The run-time layer defines concepts that represent storage layer entities transiently at run time. For example, a session represents a hypertext, while an instantiation represents a component. In addition, Dexter elucidates the interfaces between the three layers. Thus the concept of anchor connects storage and within-component layers, while presentation specification connects storage and run-time layers. See [10, 11] for further details on Dexter, and [7] for a discussion of our use of the Dexter concepts in hypermedia system design.

The Dexter model provides a solid framework for comparing hypermedia systems and discussing the design of new hypermedia systems, but the formal specification leaves many design decisions open. For instance, how do we support sharing of hypertexts and components among several users? How do the Dexter layers relate to a multiuser distributed hypermedia architecture? Where do we place the responsibility for locking, and event notifications?

Despite these questions, we decided to develop a hypermedia system supporting the generality of the Dexter model, which was taken as the starting point for our development. When dealing with the open questions about cooperation support, we have extended our design in line with the "spirit" of the model. Hence, we claim to provide a Dexter-compliant hypermedia framework and architecture, providing for example n-ary links and a rich variety of composites.

Development Activities

We have developed an object-oriented hypermedia framework from the Dexter concepts. The framework consists of generic class hierarchies modeling the concepts from the different layers of the Dexter model. A specific system is developed from the framework by specializing the generic classes. The details of the framework design are documented in a project report [4]. A working hypermedia system prototype (called DeVise Hypermedia, or DHM) was developed for both a Unix and a Macintosh platform. The development environment is the Scandinavian Mjolner BETA System (MBS), see [14, 15]. An object-oriented database (OODB) [2, 12] based on MBS is being developed in parallel with our hypermedia development. It is a general-purpose OODB--that is, the facilities work for any type of object independent of the application domain. The OODB design has, however, been highly influenced by the requirements from the parallel hypermedia development. Design issues related to the development of kernel hypermedia functionality are discussed in detail in [7]. Here we focus on design issues related to developing Dexter-based hypermedia support for cooperative work activities--for example, cooperative authoring and sharing of materials in large design projects such as bridge construction and software development. In particular, we address the questions about using the Dexter model as the basis for designing cooperative hypermedia. We also include a discussion of needs for development of OODB technology to meet cooperative hypermedia requirements.

Cooperative Work and Hypermedia Support

Design and authoring in large design projects involves cooperative work among individuals contributing to the overall design task. Such work involves both explicit communication and coordination, and implicit coordination through shared materials [17]. For instance, work on different parts of shared materials needs to be coordinated and related. Cooperative design and authoring in such settings may be supported in many different ways. In cooperative design situations, a number of users are manipulating a large body of shared material using a variety of editors. We assume the shared materials to be hypermedia networks with large sets of components (nodes, links and composites). Such hypermedia networks may be subdivided into parts identified by composites containing a subset of the components in the hypermedia network. The choice of computer support depends on the coordination requirements of the work. To describe the kind of support we aim at providing, we have identified six different modes of cooperation on shared materials:

1) Separate responsibilities. The design material is divided into disjoint parts, each of which is manipulated by at most one user. Other users may inspect parts manipulated by others. The cooperation here is quite loose and mainly consists of one user making use of designs developed by others.

2) Turn taking. As in mode 1, but each part may alternate among different users. No more than one user at a time is allowed to modify a given part. This mode of cooperation requires more support, to coordinate the work among users manipulating the same parts.

3) Dynamic exchange. During a session, users may exchange parts dynamically. One user A may want to modify a part currently being locked by another user B. User A may then ask user …