Hypermedia Operating
Systems:
Peter J. Nürnberg, John J. Leggett, Erich R. Schneider
Hypermedia Research Laboratory
Texas A&M University
College Station, TX 77843-3112 USA
E-mail:{pnuern, leggett, erich}@bush.cs.tamu.edu
Tel: 1-409-862-3217
John L. Schnase
Center for Botanical Informatics
Missouri Botanical Garden
St. Louis, MO 63166-0299 USA
E-mail: schnase@mobot.org
Tel: 1-324-577-9570
KEYWORDS: open hypermedia systems, operating systems, system architectures, hyperbases, link services, hypermedia applications
This paper describes a third view of hypermedia -- hypermedia as a computing paradigm. Specifically, we explore the implications of pushing hypermedia beyond its traditional role in human-computer interaction and information organization into the computer's core operating environment. We believe the resulting hypermedia operating systems provide a new paradigm for computing -- one in which human-computer interaction, information storage and retrieval, programming, and control are integrated in a common conceptual framework.
Silberschatz and Galvin [26] define an operating system as "a program that acts as an intermediary between a user of a computer and the computer hardware." They state that "the purpose of an operating system is to provide an environment in which a user can execute programs in a convenient and efficient manner." In this paper, we primarily seek to justify the convenience afforded by hypermedia operating systems, not their necessity. However, we also show how hypermedia operating systems can potentially improve the efficiency of a wide range of hypermedia applications.
We begin by describing the concept of data, structure, and behavior separation. We then provide four fundamental characteristics of hypermedia operating systems and examine these with respect to traditional operating system components, emphasizing convenience and efficiency gains versus traditional operating systems. This leads to a general hypermedia operating system architecture. Next, we describe HOSS -- a hypermedia operating system implementation derived from the general architecture. Finally, we discuss shortcomings of the current implementation and our plans for future work.
The importance of separating structure from data is widely recognized [2, 18, 30]. The separation of structure from data allows computation in and over structural entities [8]. Most system architectures, however, do not explicitly separate behavior from structure. Static traversal semantics or other embedded behaviors associated with the structure are often implicit within hypermedia systems. In general, any system that does such embedding of behavior cannot admit an open set of behaviors in a straightforward manner. To limit such computation unnecessarily limits the usefulness and flexibility of a system.
The case for open computational entities in other parts of the hypermedia system (e.g. openness with respect to applications) is well established [5, 12, 18, 21]. However, the explicit case for open computational entities in general and thus by extension for open sets of behaviors is only now being considered. Once an open set of behaviors is admitted, separation of behavior from structure follows from the same arguments as those for separation of structure from data: multiple behaviors (structures) over the same structure (data), behavioral (structural) integrity divorced from structural (data) integrity, etc. The remainder of this paper assumes an environment in which the separation of data, structure, and behavior is explicit (see Figure 1).
Figure 1. Separation of Behavior, Structure, and Data.
Process Types. In a hypermedia operating system, we distinguish three fundamental types of processes: application, behavior, and structure-caching. The following discussion motivates the distinction of each type of process and provides a rationale for implementing and managing these processes as either heavy-weight or light-weight processes (threads).
Application processes. Application processes are user processes familiar from conventional operating systems (editors, spreadsheets, etc.). The nature of these processes is open and cannot be known in advance. Therefore, process management, scheduling, swapping, and resource allocation for these processes can be managed as in conventional operating systems.
Behavior processes. Behavior processes are associated with structural entities and should be managed differently at the operating system level from standard user processes such as applications. Consider a general case of computation over structure. Behavior processes associated with a structural element are executed, which in turn may cause other behavior processes associated with "nearby" structural elements to be executed, and so forth, until the computation is complete. This computation may take the simple form of "link traversal" (traversing structural elements from one data object to another) or more complicated forms (traversing structure to find all data objects within a given "distance" that contain a certain attribute with a certain value and displaying their names).
Consider the data space requirements of these behavior processes. Suppose a cache of structural elements existed in some data space. Many behavior processes associated with structural elements would find this cache very useful. The most practical approach for managing these behavior processes is to thread them inside a structure-caching process. The expectation is that there would be an efficiency gain in a system that threaded behaviors inside a process that cached structural information, compared to a system in which each behavior was implemented as a heavy-weight process that acquired structural information via inter-process communication (IPC) from a separate server process.
Threading implies sharing code space as well as data space. Does this present a problem? On the contrary, this can provide a performance advantage. Consider a structure-caching heavy-weight process that dynamically loads behavior code when the behavior is executed for the first time. In systems where a small set of behaviors is called for in a large number of structural computations, the loading of the code for these behaviors (which must also be present in heavy-weight process solutions) need only be done once.
Structure-caching processes. We have already mentioned the third process type -- structure-caching processes. These processes are different from other processes in the system because they must load and thread an arbitrary set of behaviors. This has special implications for memory management.
Since structure-caching processes admit an arbitrary set of behaviors, the process space might grow very large. Additionally, the cached structure space itself might be very large. Traditional approaches to memory management take advantage of the principle of locality of reference. However, the locality properties of structure-caching processes within a hypermedia operating system are presently unknown. It is important that we discover the differences between traditional and hypermedia locality properties. The operating system could exploit these differences, if known, to improve efficiency. Almost certainly, analysis of the hypermedia structures will allow better guesses to be made as to which behaviors should be kept in main memory and which should be swapped out. The operating system may only take advantage of hypermedia locality properties if it can distinguish and interpret hypermedia structures in the system.
First-Class Structure. The preceding section established the importance of a hypermedia operating system treating structure as a first-class entity. Specifically, we argued that operating systems must recognize structure objects on par with data objects. What further implications are there to first-class structure?
A traditional operating system is responsible for providing the following functionality in a file system: creation, deletion, and manipulation of files and directories; mapping files to secondary storage; and providing means to back up secondary storage. Consider replacing the file system of a conventional operating system with a hyperbase. A hyperbase provides both data and structure management capabilities [14, 19, 22, 23, 28]. All of the above tasks should be supported for data and structure objects in a hypermedia operating system: creation, deletion, and manipulation of data and structural objects, sets of data objects, and sets of structural objects; mapping those objects and sets of objects to secondary storage; and providing the means to back up all types of objects and sets of objects.
Structural abstractions. Are there advantages to providing four abstractions (data object, data object set, structural object, structural object set) instead of two (file, directory)? Certainly, differentiation of structural abstractions is useful for processes that lie above the file system. For example, the scheduler (as discussed above) must differentiate between structure and data in order to make intelligent swapping decisions. Also, providing structural abstraction support also facilitates pervasive back-end and front-end hypermedia, discussed below.
Pervasive Back-end Hypermedia. Pervasive hypermedia in the system back-end has implications for the protection system of a hypermedia operating system. In many operating systems, access control over an object consists of permissions granted to various user groups for various operations. These operations are performed directly on the objects. In a pervasive hypermedia environment, in which objects may be included as referents of structural entities, extending access control to account for operations performed indirectly on objects becomes possible. That is, it may be desirable to enforce permissions involving how objects may be referenced.
Reference permissions. Indirect (or reference) permissions in traditional operating systems are difficult to support. For example, consider how annotations in such systems would be made. One option is for no distinction to exist between data and structural objects anywhere in the system. If this were true, "structure" would be effected by embedded reference in the data objects themselves. In order for the operating system to operate on these embedded references, it must be able to interpret any arbitrary data object -- an impractical solution. Another option would be for data and structural elements to be distinguished in the user space "above" the operating system. However, in this scenario, again, the operating system understands only data objects, and again it would be required to interpret arbitrary data objects. It is only when the operating system is aware of structure that it can parse such structure and attempt to enforce reference restrictions.
Pervasive Front-end Hypermedia. Pervasive hypermedia in the system front-end has implications for the command interpreter system of a hypermedia operating system. Application processes can be passive participants in inter-application linking thereby allowing a convenient mechanism for personalization that is available to every process. Also, since the operating system itself is aware of hypermedia functionality, it can provide system calls that implement hypermedia functionality. Not only would the construction of monolithic hypermedia systems be easier in such a programming framework, but hypermedia command interpreter systems could be easily constructed. Such a hypermedia command interpreter system would be distinct from command-line interpreters (e.g. UNIX shells) or GUI interpreters (e.g. MacOS interpreter).
Inter-application linking. Passive participation in inter-application linking can be effected by a simple link services protocol [18, 19]. Structure traversals can be effected at a higher level, allowing applications to be unaware of the details of structure management and the structure management subsystem to be unaware of the details of application data. In systems in which non-embedded structure management is provided by the operating system itself, the implementation of a server of inter-application link services is straightforward.
Figure 2. Modeling "make" and "cron" with hypermedia structures.
Hypermedia command interpreter systems. Since structure management in a hypermedia operating system would be pervasive, the command interpreter system would have some method by which users of the system could manipulate structure outside of any particular application. For example, consider modeling the "make" utility in a system in which the relationships among objects were themselves first-class objects. Rules for building objects could be implemented as behaviors over the structure defined by a dependency graph over the objects. As another example, scheduling of jobs in a "cron"-like manner could be implemented as behaviors over structure among various objects, including an application object that is latent until the specified "wake-up" time, at which point the application performs the appropriate traversals and spawns the appropriate behaviors (see Figure 2).
Link Navigation. Suppose a user has started a text editor application and is displaying a file in which a word is linked to a part of a line drawing produced by a graphics editor. This situation is drawn in figure 3.
Figure 3. Structure Between a Text File and a Line Drawing.
This figure represents only the data and structure involved in this association. Not shown are the behaviors associated with the structural elements, the applications that display the data, and the structure-caching process that manages the structural association.
In this example, if the user has just loaded the text file, it would be reasonable to assume that the probability of the line drawing being accessed in the near future has become higher than otherwise due to existing navigable structure between it and the text file. Furthermore, the behaviors associated with the structural elements connected to the word in this text file are also now more likely to be invoked than if the user were not displaying the text file. In an operating system unaware of the existence of structure, such a conclusion cannot be reached. The hypermedia operating system, however, understands what structure is -- it can draw the conclusion that the behavior code and line drawing may be needed soon, and thus can pre-fetch them. This pre-fetching is based upon a semantic locality that cannot be derived in absence of the knowledge of structure. Other operating systems must rely soley upon traditional notions of locality based on distance in logical memory.
Inter-Behavior Communication. Suppose a user has started a text editor and is displaying a file in which a word is linked to its definition in some dictionary. This situation is drawn in figure 4.
Figure 4. Structure Between a Text File and a Dictionary.
As before, the applications and behaviors are not shown. When the user decides to navigate from the association end-point in the text file, the left-side behavior is to query the application for the text string, pass this to the association behavior which stems and normalizes the word, and then passes the string to the behavior attached to the right-side, which then looks up the string in the dictionary. The right-side behavior now passes the definition back up through the association to the left-side behavior, which passes it to the original text editor.
Suppose that the behaviors in this example are running on the same machine. Behaviors that do not make special provisions to the contrary will have to communicate via inter-process communication channels. In a hypermedia operating system, these behaviors would be threaded in the structure-caching process, thereby sharing a common data space. The intra-process communication between these behaviors would occur in shared memory, which is much faster than any inter-process communication scheme. While behaviors in generic operating systems can use shared memory to communicate, they must make special provisions for doing so. In a hypermedia operating system, behaviors by definition share data space -- no special provisions need be made.
Figure 5. A General Hypermedia Operating System Architecture.
Table 1. The HOSS family tree of process-oriented hypermedia systems
Figure 6. HOSS Architecture.
HCMT, HPMT, and SunOS 5.4. Much of the above discussion that makes the case for hypermedia operating systems on efficiency grounds relies on a sophisticated process model. Heavy-weight and light-weight processes must be provided, dynamic loading of code segments must be convenient and efficient, and inter-process communication (or more generally, event handling) from several sources at once must be supported.
These process requirements are similar to those for general open, extensible, and distributed hypermedia environments [17]. We have developed two toolkits that provide the functionality necessary to meet these requirements. The first is the HOSS Communications Model Toolkit (HCMT). HCMT provides medium, port, event, and protocol abstract data types (ADT's), mechanisms for handling event-driven IPC, and tools for building dynamic medium and protocol libraries. The second toolkit is the HOSS Process Model Toolkit (HPMT). HPMT implements higher level IPC abstractions used for location services in a distributed environment and mechanisms for handling several event sources simultaneously.
These toolkits provide appropriate communications and process models for a hypermedia operating system simulation, because they support dynamic loading, threading, virtually transparent IPC mechanisms, and a general event structure appropriate for highly distributed systems. These toolkits are implemented on top of SunOS 5.4 and take advantage of its thread libraries, I/O systems, and other lower-level functionality. In general, any operating system that provides thread scheduling can host the HOSS prototype.
HBproc. The HOSS HBproc consists of a Versioned Object Manager (VOM) and an Association Set Manager (ASM). The VOM acts as a client of some Storage Manager (SM) that exists outside of the hyperbase. The Versioned Object Manager serves simple object and composite object ADT's and provides full versioning support for both [9]. The Association Set Manager is implemented as a client of the VOM, mapping its versioned object abstractions to structural entity abstractions called associations and association sets [14, 19]. Because the ASM is a client of the VOM, it inherits versioning support for its ADT's as well.
Both the Versioned Object Manager and Association Set Manager have been designed and implemented on SUN workstations running SunOS 5.4. VOM's (or, in earlier prototypes that did not exhibit versioning, OM's) have been implemented on top of various Storage Managers, including Saberel (a proprietary semantic database), Postgres [27] (an extended relational database), and Illustra [10] (an object relational database). Currently, HOSS Versioned Object Managers exist for the latter two Storage Managers.
The VOM and ASM provide data object and structural object services respectively. Since the ASM is a VOM client, however, not threading both processes inside the same data space would lead to IPC calls for every structural object request made of the hyperbase. This is clearly an unacceptable performance penalty for providing structure. Therefore, the decision was made to keep hyperbase processes in the same data space, effecting much greater communication speeds between client and server.
Sprocs. HOSS allows an open set of peers to the general hypermedia operating system LSproc. These peers are called Sprocs (structure processors). Sprocs are heavy-weight processes in which caching, loading, and service dispatch threads are loaded at startup (called collectively the "Structure Paradigm Manager"), and behavior code and structure are cached and swapped out. All Sprocs are clients of the Association Set Manager. The difference between Sprocs lies in the kinds of structure they manipulate.
Two HOSS Sprocs have been implemented. The first of these is the Link Services Manager (LSM). The LSM functions in HOSS in the capacity of the "structure caching and behavior loading" process described above. The LSM allows users to "open" sets of structural elements, thereby caching them in the LSM space. It also spawns threads of control for behaviors (loading the code for those behaviors if necessary). Finally, the LSM manages user session inter-application linking by being the target of application requests for link services.
The Taxon Manager (TaxMan) provides a second example of a HOSS Sproc. TaxMan acts as a client of both the Versioned Object Manager and the Association Set Manager, and serves taxonomic structural abstractions. Taxonomic abstractions are widely useful. For example, botanists use species, genus, and family taxa to classify plant specimens and linguists categorize linguistic samples into languages or linguistic taxa. The special significance of TaxMan, as opposed to other metadata managers (see below) or applications, lies in its particular function -- managing taxonomic structure. Many of the same arguments (from above) that apply to the LSM as a special kind of process that should dynamically load and thread behaviors over traversal structure can be applied to the TaxMan as a special kind of process that should dynamically load and thread behaviors over taxonomic structures.
Metadata Managers. In the general hypermedia operating system architecture (Figure 5), processes not of the OSproc, HBproc, LSproc, or command interpreter variety were grouped together as applications. However, HOSS divides this group into metadata managers and "true" applications. Metadata managers are system processes that primarily serve abstractions to other system processes, whereas applications primarily serve human clients.
Applications and metadata managers build from abstractions served by other metadata managers, Sprocs, and the HBproc. The significance of making this distinction in light of operating system policy is that applications, being by definition front-end processes and thus directly interacting with the user, require different scheduling than metadata managers. Additionally, since metadata managers by definition export functionality, they must interact with locator servers to make their abstractions and ports known to other clients. The current HOSS prototype does not yet effect any scheduling differences, but it does implement a location services scheme (process groups) whereby metadata managers advertise their services, and applications and metadata managers query for access to other services.
Hsh. The HOSS Shell (Hsh) acts as a primitive command interpreter to the prototype operating system functions. It allows users to manage connections to hyperbases, set and unset various "environment" variables used by the LSM and other programs, and spawn applications and metadata managers. The Hsh functions in the same capacity as shells in UNIX.
Applications. The HOSS makes no assumptions about the structure of applications. It simply uses the default policies of SunOS 5.4 for scheduling, main memory management, etc. when managing applications. However, totally unmodified applications do not take advantage of any efficiencies or conveniences afforded by HOSS. Applications that have been developed for use with HOSS generally adopt at least an open linking protocol so that their data may be linked with data from other applications via the Link Services Manager. The HCMT and HPMT toolkits provide a high-level application program interface (API) to inter-process communication facilities that can be used to handle this link services protocol. Furthermore, the applications developed to date for use in HOSS store and retrieve objects through the hyperbase back-end instead of the native SunOS 5.4 file system.
Examples of HOSS applications include a spatial text editor (HyperEd [3]), an animation tool (Sangam [24]) and a shared reviewing tool (Scholia [13]). Additionally, several WWW Common Gateway Interface (CGI) programs have been written that connect to HOSS servers.
The notion of a command interpreter is poorly defined in HOSS. For example, applications are currently launched from both the Hsh and the LSM; that is, the LSM does not use the facilities of the Hsh. Also, process groups, a notion intended to support location services for applications requesting servers of particular ADT's, is not well addressed in the Hsh. Finally, the Hsh interface is not customizable, and it must be redesigned to handle more straightforwardly the demands of a distributed system. The next version will better support process groups, a GUI for application scheduling and launching, and customizability.
Much work must be done in this regard in the HOSS prototype. Currently, the LSM loads structure data and behavior code only on demand. Data may be explicitly unloaded, but behavior code is never unloaded. This suggests two areas for improvement: pre-fetching and swapping. The LSM should be able to pre-fetch data or code based on an analysis of already loaded data. By examining the structure currently (or recently) in use, the LSM should be able to at least pre-fetch code that may be executed in the near-term. For example, the LSM could pre-fetch all behaviors associated with all structural entities that are related in the first, second, or third degree to the last entities referenced. Other pre-fetching algorithms will be designed after gathering data from actual long-term use of the HOSS prototype.
The LSM should also swap out code and data not likely to be used in the near-term. For example, swapping out code and data that has not been referenced in some amount of time and that is not related to some "last-referenced" structural entity set. Even these simple approaches would likely improve general operating system performance over that found in systems that are unaware of the hypermedia semantics of the code and data in the system.
In the HOSS, for example, the TaxMan and the LSM never operate over the same structures or behaviors. This means that consistency of the structure is an issue that must be resolved only between instances of the same program. However, two types of Sprocs could interact over overlapping sets of structure and behavior. In fact, if the Sprocs level in the architecture is open, one cannot know a priori all the possible Sprocs that could affect a given structural entity set. This implies the need for more stringent concurrency control at the ASM level than is currently implemented.
This work may be viewed as an extension of hyperbase research. Part of the prototype described in this paper represents the latest descendent in a line of hyperbase research prototypes. Certainly, a host of low-level issues (e.g. thread scheduling) need to be addressed issues traditionally beneath the concern of hypermedia system designers.
However, hypermedia operating system services can also be seen as an extension of a more front-end concern -- seamless inter-application linking. The availability of pervasive first-class structure enables both user and programmer to rethink old human-computer interaction styles. The front-end ramifications are numerous.
In summary, we have outlined a view of hypermedia that is qualitatively different than the traditional view of hypermedia as a human-computer interaction paradigm or information organization paradigm. We offer a new perspective on hypermedia systems. While this is only a beginning, we feel that viewing hypermedia as a computing paradigm offers a broad new field of research.
2. Campbell, B., and Goodman, J. M. 1988. HAM: a general-purpose hypertext abstract machine. Communications of the ACM, 31, 7, (Jul).
3. D'Arlach, C. X., and Leggett, J. J. 1994. HyperEd: a spatial hypertext editor. Department of Computer Science Technical Report No. TAMU-HRL-94-005, Texas A&M University.
4. Engelbart, D. C., and English, W. 1968. A research center for augmenting human intellect. AFIPS Conference Proceedings, 1968 Fall Joint Computer Conference, (San Francisco, CA, Dec).
5. Fountain, A. M., Hall, W., Heath, I., and Davis, H. C. 1990. Microcosm: an open model for hypermedia with dynamic linking. Proceedings of ECHT '90, (Versailles, France, Nov).
6. Grønbæk, K., and Trigg, R. H. 1994. Design issues for a Dexter-based hypermedia system. Communications of the ACM, 37, 2, (Feb), 40-49.
7. Halasz, F., Moran, T., and Trigg, R. 1987. NoteCards in a nutshell. Proceedings of the CHI '87 Conference on Human Factors in Computing Systems, (Toronto, Canada, Apr).
8. Halasz, F. G. 1988. Reflections on NoteCards: seven issues for the next generation of hypermedia systems. Communications of the ACM, 31, 7, (Jul).
9. Hicks, D. L. 1993. A Version Control Architecture for Advanced Hypermedia Environments. Ph.D. dissertation, Department of Computer Science, Texas A&M University.
10. Illustra Information Technologies, Inc. 1995. Illustra User's Guide. Oakland, CA: Illustra Information Technologies, Inc.
11. Joyce, Michael. 1991. Storyspace as a hypertext system for writers and readers of varying ability Technical Briefing. Proceedings of the Third ACM Conference on Hypertext (Hypertext '91), (San Antonio, TX, Dec).
12. Kacmar, C., and Leggett, J. 1991. PROXHY: A process-oriented extensible hypertext architecture. ACM Transactions on Information Systems, 9, 4, (Oct) (339-419).
13. Kostovassilis, V., and Leggett, J. J. 1994. Prototyping Scholia's reviewing tool. Department of Computer Science Technical Report TAMU-HRL-94-004, Texas A&M University.
14. Leggett, J. J., and Schnase, J. L. 1994. Viewing Dexter with open eyes. Communications of the ACM, 37, 2, (Feb), 76-86.
15. Marshall, C. C., Shipman, F. M., and Coombs, J. H. 1994. VIKI: spatial hypertext supporting emergent structure. Proceedings of ECHT '94, (Edinburgh, Scotland, Sep).
16. Nelson, T. H. 1965. A file structure for the complex, the changing, and the indeterminate. Proceedings of the 20th National ACM Conference.
17. Nürnberg, P. J. 1994. Implications of an open, extensible, and distributed hypermedia information system architecture for inter-process communication subsystem design. M.S. thesis, Department of Computer Science, Texas A&M University.
18. Pearl, Amy. 1989. Sun's link service: a protocol for open linking. Proceedings of the Second ACM Conference on Hypertext (Hypertext '89) (Pittsburgh, PA, Nov)
19. Schnase, J. L. 1992. HB2: A hyperbase management system for open, distributed hypermedia system architectures. Ph. D. Dissertation, Department of Computer Science, Texas A&M University.
20. Schnase, J. L., Leggett, J. J., Hicks, D. L., Nürnberg, P. J., and Sanchez, J. A. 1993. HB1: Design and implementation of a hyperbase management system. Electronic Publishing: Origination, Dissemination and Design, 6, 1, (Mar), 35-63.
21. Schnase, J. L., Leggett, J. J., Hicks, D. L., Nürnberg, P. J., and Sanchez, J. A. 1994. Open architectures for integrated, hypermedia-based information systems. Proceedings of the 27th Annual Hawaii International Conference on System Science (HICSS '94), (Maui, HI, Jan).
22. Schütt, H. A., and Streitz, N. 1990. HyperBase: a hypermedia engine based on a relational database management system. Proceedings of ECHT '90, (Versailles, France, Nov).
23. Shackelford, D. E., Smith, J. B., and Smith, F. D. 1993. The architecture and implementation of a distributed hypermedia storage system. Proceedings of the Fifth ACM Conference on Hypertext (Hypertext '93) (Seattle, WA, Nov).
24. Shah, A. A., and Leggett, J. J. 1993. Image Manager. Department of Computer Science Technical Report No. TAMU-HRL-93-003, Texas A&M University.
25. Shipman, F. M., and McCall, R. J. 1994. Supporting knowledge-base evolution with incremental formaliza- tion. Proceedings of CHI '94, (Boston, MA, Apr.)
26. Silberschatz, A., and Galvin, P. B. 1994. Operating System Concepts Reading, MA: Addison-Wesley.
27. Stonebraker, M., and Kemnitz, G. 1991. The POSTGRES next-generation database management system. Communications of the ACM, 34, 10, (Oct), 78-92.
28. Wiil, U. K. 1993. Experiences with HyperBase: A multiuser hypertext database. SIGMOD RECORD, 22, 4, (Dec), 19-25.
29. Wiil, U. K. and Leggett, J. J. 1993. Concurrency control in collaborative hypertext systems. Proceedings of the Fifth ACM Conference on Hypertext (Hypertext `93), (Seattle, WA, Nov.)
30. Yankelovich, N., Haan, B., Meyrowitz, N., and Drucker, S. 1988. Intermedia: The concept and the construction of a seamless information environment. IEEE Computer, 21, 1, (Jan), 81-96.
