This paper contributes to an ongoing effort on standardizing open hypermedia system architectures and communication interfaces. Open hypermedia systems share the property of being able to provide non-hypermedia applications with hypermedia structuring and navigation capabilities. This support is currently provided in many different ways. To be able to standardize communication interfaces, it is necessary to develop common understanding of the different architectures of existing systems and to develop a common reference architecture for open hypermedia systems. A reference architecture should provide a common language for the design of open hypermedia systems in terms of architectural elements and interfaces. The paper identifies a number of important requirements and characteristics for open hypermedia systems and examines some of the most well known open hypermedia architectures and reference models. The analysis illuminates the commonalties and differences in terminology and architectural elements. The analytical results are used to propose common terminology and a common reference architecture for open hypermedia systems (CoReArc). CoReArc identifies several different architectural elements and communication interfaces for potential interface standardization. Interface standardization may be achieved through a single physical protocol with several suites or topics or through several independent protocols. CoReArc can be used to identify and discuss the different communication interfaces of an open hypermedia system.
Open hypermedia systems (OHSs) address the difficult tasks of providing hypermedia services to computing entities (applications, stores and other services) in the computing environment. Using the services of an OHS, various computing entities can become hypermedia enabled and provide hypermedia services orthogonal to existing storage and display services. Hypermedia enabling of existing computing entities can potentially be a very complex task. One factor adding to the complexity is the lack of standards in the open hypermedia community. Each OHS defines its own data model, linking protocol (protocol to communicate with hypermedia enabled computing entities), system architecture and hypermedia services. The lack of consensus about what an OHS is has resulted in incompatible systems: a computing entity that has been enabled for one particular OHS cannot be used with other OHSs. It should be noted that openness could also apply to hypermedia data formats. Data formats such as HTML, SGML and HyTime can be considered open in the sense that files of arbitrary types may be referenced or embedded. This notion of openness requires that the rendering machine is open for plugging in rendition modules for the new data formats in question. However, data format openness is not the primary focus of open hypermedia research.
The open hypermedia community has formed a working group to address the important standardization issues. The Open Hypermedia System Working Group (OHSWG)  formed out of the 2nd Workshop on Open Hypermedia Systems at Hypertext '96 in Washington, DC (March 1996) . The initial goals of the OHSWG were to define open hypermedia systems and to define open link services. The 2.5 OHSWG meeting in Southampton, England (December 1996)  showed that it is difficult to discuss scenarios and especially protocols  without having a common consensus on what the concepts and building blocks (architectural elements) of an OHS are. Thus, a third goal defining an open hypermedia reference architecture was added to the OHSWG agenda at the 2.5 OHSWG meeting. The first work addressing the reference architecture issues ([11, 16, 44]) were presented at the 3rd Workshop on Open Hypermedia Systems at Hypertext '97 in Southampton, England (April 1997) .
This paper proposes a reference architecture for OHSs. The purpose of the paper is to continue the work towards common concepts, architectural elements and terminology for OHSs. A common consensus on these important issues is essentially a prerequisite for being able to identify (and discuss) the necessary communication interfaces of an OHS. We approach these issues by examining some of the most well known architectures and reference models for OHSs. The analysis is used to illuminate the commonalties and differences in terminology and architectural elements and to propose both common terminology and a common reference architecture for OHSs. We start in Section 2 by identifying a number of services that OHSs must provide and by listing a set of general requirements for an open hypermedia reference architecture. Section 3 examines six different open hypermedia reference models and architectures that has been proposed in the literature and Section 4 examines the use of different terminology in existing open hypermedia models and systems. Based on the discussion in Sections 3 and 4, Section 5 presents a proposal for a common open hypermedia reference architecture. The basic idea is to take the best of existing approaches and propose an architecture that can provide the identified services and fulfil the identified requirements. Section 6 concludes the paper
Before discussing and designing a reference architecture for open hypermedia, it must be made clear what it is that the open hypermedia community is trying to achieve. This section sets the context by discussing important services of an OHS and general requirements for an open hypermedia reference architecture.
Open hypermedia research pursues the goal of a global unified environment where hypermedia is the central paradigm for structuring information and navigating among pieces of information. In the ideal world, all operating systems support a set of standard open hypermedia structuring and navigation services and all services, applications and stores have been built to use these services . In the real world things are much different: no standards exist, open hypermedia services reside in middleware components rather than the operating systems, and existing services, applications and stores in most cases have not been built to use open hypermedia services. Thus, OHSs must provide a number of services to overcome some of the current "limitations" of the real world. This section lists six types of services (integration, interoperability, structuring, navigation, distribution and collaboration) that are important to OHSs and should be considered key issues when designing a reference architecture. Navigation and structuring are the core services of any OHS. Integration, interoperability and distribution are services that the OHS must provide to operate in the real world. Collaboration is a service that has proven very valuable in previously reported hypermedia work; this includes personal experiences accumulated from the DHM  and HyperDisco  projects as well as experiences from various other hypermedia projects. In the following, each service is briefly described and relevant and important previous work in the hypermedia field is listed for each service.
A core set of open hypermedia services could probably be identified, but in general an OHS should be capable of providing as many of these services or as few of these services as desirable. Thus, a reference architecture for OHSs should reflect the fact that OHSs provide different levels and types of services within the six areas listed above (and potentially other areas as well such as information retrieval). Thus, the above list of services is not considered to be complete. Future research is likely to add additional services to the list. However, the above six services are considered to be important and a reference architecture for open hypermedia should not in any way restrict these (and future) services.
In addition to the already mentioned requirements for hypermedia services, the following general requirements for an open hypermedia reference architecture are believed to be important:
The identified general requirements for OHS architectures will be used in Section 3 in the analysis of existing open hypermedia reference models and architectures and the identified open hypermedia services will be discussed again in Section 5 in connection with the proposed common reference architecture for open hypermedia.
Only a few open hypermedia reference models and architectures have been proposed in the literature. This section presents six approaches, the Flag model , the DHM architecture , the Shim architecture , the HyperDisco architecture  and its instantiation in the interoperability experiment described in , the HOSS architecture , and the open hypermedia reference architecture (OHRA)  (an updated version of the OHRA paper is also part of this special issue). Each of these six candidates is examined and matched against the four general requirements (Conceptual Architecture, Generality, Simplicity and Extensibility) and important contributions of each approach are identified. The approach taken in the subsequent sections is to use the results of the analysis to develop a reference architecture, which fulfils the requirements.
The Flag model  modifies and extends the terminology of the Dexter model  to deal explicitly with integration and use of existing third party viewers (applications). The main idea is to distinguish between storage aspects and runtime aspects and between structure and contents. These distinctions make the Flag model a general and conceptual reference model, which identifies four functional modules and four protocols in OHSs (see Figure 1).
Viewers use the session manager to manage structures (anchors, links, etc) in documents via the linking protocol. The session manager uses the data model manager to store and retrieve structures via the presentation protocol. The viewers use a storage manager to store and retrieve documents via the storage protocol. Some OHSs provide their own storage manager, which can be accessed directly from the viewers through the storage protocol or indirectly (via the session manager and data model manager modules) through the storage protocol. The Flag classifies OHSs into two categories, link servers, which are those systems that only provide structural storage (e.g., Microcosm , Chimera  and Multicard ) and open hyperbase systems, which can also handle storage of contents (e.g., DHM , SP3/HB3 , HOSS  and HyperDisco ).
The Flag model makes it explicit that existing viewers can participate in the hypermedia services and store contents in one place (e.g., the file system) via the storage protocol and store structure (and in some cases contents) in the OHS via the linking protocol. Another merit of the Flag model is that it is completely system independent and provides a general and conceptual framework to classify, describe and compare (open) hypermedia systems. This allows the Flag to be used both to specialize hypermedia concepts and terminology (the functional modules and protocols of the Flag can be mapped to several physical implementations) and to generalize architectural elements and hypermedia services (existing hypermedia systems can be described, classified, analyzed and compared in a system independent way using the concepts and terminology of the Flag). The Flag model is not immediately extensible for introduction of new modules and interfaces, but it is open ended in the sense that it does not prescribe the concepts to be used in the individual interfaces and modules.
Grønbæk et al.  present the architecture of the Devise Hypermedia system (DHM), which is a modified and extended Dexter-based  layered architecture featuring four conceptual layers: Application Layer, Communication Layer, Runtime Layer, and Storage Layer (Figure 2). The main contribution of this architecture is a mapping of the conceptual layers of DHM (and thus the original Dexter model) to a physical system architecture. The DHM architecture radically alters the sequence of Dexter's conceptual layers: (1) the Within-component Layer is renamed the Application Layer and is moved away from the Storage Layer and (2) a new fourth conceptual layer, the Communication Layer, models communication between the Application Layer and the Runtime Layer. The four conceptual layers are mapped to three physical layers of communicating processes (application, hypermedia service process and hypermedia database server). This physical architecture is not fixed - variants are possible: (1) the hypermedia database server may be just a library included in the hypermedia service process running as a single process, (2) the DHM browser application may be an integral part of the hypermedia service instead of being a separate process, and (3) the distribution of the processes among server hosts and user workstations may differ.
The Application Layer encompasses end-user applications integrated with the hypermedia system, and may include text, graphical and video applications as well as hypermedia browsers. An application handles a specific type of data object, e.g., text objects. The data objects may be stored by the applications in separate files outside the hypermedia database server or the applications may take advantage of the hypermedia database server storage facility. The data objects manipulated by these applications belong to the Dexter Within-component Layer. However,  interprets the conceptual Within-component Layer somewhat wider than the original Dexter model, because it is not limited to just passive data. The internal manipulation of the data objects is viewed as operations on the data objects but mediated by the dedicated application. Thus, an application's functionality belong to the Application Layer and not the Runtime Layer as proposed by the original Dexter model. The applications' hypermedia functionality only exists through communication with the corresponding Runtime Layer. An application represents the contents for a specific type of component by supporting a protocol for communication with the hypermedia service process.
The Communication Layer is responsible for the communication between the hypermedia service process and the applications. This layer implements the DHM protocol via the inter-application communication facility available on a given platform. The Communication Layer is physically realized in two places: through macros or plug-in modules in the applications and as classes and objects in the hypermedia service process.
The Runtime Layer implements the core hypermedia behavior specified by the generic classes of the Runtime Layer. The runtime classes are physically implemented within the hypermedia service process, which is responsible for handling links, anchors and components at runtime. The hypermedia service process communicates with the applications on the one hand and the hypermedia database server on the other hand.
The Storage Layer consists of two elements: the database schema implementing the extended Dexter Storage classes, and the physical hypermedia database system storing the objects. The Storage Layer is similar to the Communication Layer, being physically located in two different places in an implemented system. The hypermedia database server provides permanent physical storage for the hypermedia objects. The objects being stored are instances of classes specialized from the generic classes implementing the Dexter Storage Layer concepts. Depending on the type of database chosen, the Storage Layer classes may be represented in several ways.
Figure 2 shows a DHM scenario, where two users with their own applications are connected to multiple hypermedia databases and multiple document managers possibly distributed on several hosts in a network. The architectural elements of DHM and integrated applications are shown relative to the proposed conceptual layers of the architecture.
A strength of this architectural model is the combination of a diagram for the actual relationships among architectural elements of a specific system configuration and conceptual layers. A different system configuration can be mapped to exactly the same conceptual layers thus illuminating the specific differences in the configuration. While Figure 2 depicts a system configuration with ordinary desktop applications and a document management system typically running on a shared file system, Figure 3 presents another OHS configuration mapped onto the same conceptual layers in a consistent fashion. Another strength is that both an application / hypermedia service protocol and a hypermedia service / hypermedia database protocol are identified.
The main strength of this architecture model is the generality and simplicity of the conceptual layers and the notation, which can be mapped to many existing OHSs such as Microcosm , HyperDisco , and HOSS . As an example the mapping of Microcosm architectural elements onto conceptual layers may look like the following: Viewer to Application Layer, OHP to Communication Layer, Filter Manager to Runtime Layer, and Link bases to Storage Layer.
One weakness of the DHM architecture is the potential ambiguity in whether only architectural elements of the OHS or also the integrated applications are mapped to the conceptual layers. This ambiguity comes to the surface when locating the contents of components managed by the applications. Should the contents be mapped to the (physical) Storage Layer or to the Application Layer? The Application Layer is an extension of the original Dexter Within-Component Layer also covering the display and editing behavior coupled to the contents of components. As a consequence of this, the document management system in Figure 2 as well as the WWW server in Figure 3 are placed in the Application Layer. This choice may not seem immediately obvious since both document managers and WWW servers represent storage. This ambiguity is avoided in the Flag model (Section 3.1) where both the document management system and the WWW server would map onto the storage manager module.
Davis et al.  propose an architecture that supports reuse of third party application extension modules across different OHSs. The idea is that specific applications should be extended to communicate with a hypermedia service via a standardized protocol called OHP (Open Hypermedia Protocol). Having integrated applications this way, so-called shims should be implemented to fit the standardized OHP to proprietary protocols implemented by say DHM and Microcosm. This approach would then emancipate the OHP community for writing a lot of nearly identical extension modules for the applications to be integrated with each OHS. The idea is depicted in Figure 4. Third party applications are standard software packages developed without built-in hypermedia functionality. The Communication Protocol Shim is responsible for translating the logical protocol operation invoked from say the Application to the specific network protocol (NP) which will be understood by the Link Service. An example of such translation could be a Microsoft Windows application using the DDE to communicate the OHP operations to the shim which translates them into TCP/IP communication which is understood by the Unix based link service. The Hypertext Protocol Shim is responsible for mapping the OHP messages send by the third party application to the specific operations of the Link Service not yet providing native support for OHP. Finally, the Link Service is both responsible for runtime resolving of links given some selection from an application and for creating, storing, and retrieving links from physical storage.
The strength of the Shim architecture is the fitting of different open hypermedia protocols to support reuse of third party application tailoring modules with many different OHSs. It does a nice job in this respect, and it does not attempt to cover the rest of the hypermedia system architecture for instance database interfaces and the like. An implementation of OHP shims for the existing OHSs would make a clear improvement of interoperability among OHSs and tailored applications.
A weakness of the Shim architecture proposal is that it is limited in generality in the sense that it focuses closely on the fitting of different open hypermedia protocols. Moreover, a critical question may be raised to this approach: What are the long-term prospects of shims if the OHP is standardized? If all OHSs agree on the same OHP and the OHP becomes widely accepted, there is no need for the extra overhead involved in developing a Shim module and in translating from OHP to a proprietary protocol. The shim approach may however still be necessary in situations, where an OHS have to support many different carrier communication protocols such as TCP/IP, DDE and AppleEvent. In this situation the Shim may take responsibility for translating from the abstract OHP to the actual carrier communication protocol on a given platform. It may also be the case that an application or an OHS on one platform needs to use different carrier protocols at the same time, e.g., TCP/IP and DDE on Microsoft Windows.
The HyperDisco architecture (Figure 5) consists of three levels: tools consisting of both hypermedia tools and integrated third party applications, tool integrators and workspaces . Tool integrators provide the hypermedia services to tools and act as session managers coordinating users' access to multiple workspaces. A workspace provides both hypermedia database and document management system services. These architectural elements may exist in many-to-many relationships and may be distributed on wide area or local area networks.
A recent experiment which integrated the Chimera server to operate as a HyperDisco workspace  made use of a so-called wrapper to integrate an external store (in this case the Chimera server) to interoperate with HyperDisco. Wrappers are small program modules that encapsulate external applications and stores into a module that behaves according to given protocols. Originally, wrappers were only used to integrate third party applications with the HyperDisco system, but the wrapper approach has proven to work for external stores as well. The results from the experiment were generalized into a proposal for a general OHS architecture, which can be considered a specific instantiation of the HyperDisco architecture. Figure 6 shows this general OHS architecture in a scenario where an OHS supports integration of both external applications and external stores. The OHS consists of one or more native OHS Applications, one or more OHS Session Managers and one or more native OHS Stores.
Wrappers are used to enable external applications and external stores to conform to the OHS protocols. The OHS Session Manager is similar to the tool integrator. Thus, the OHS Session Manager provides hypermedia services to both external and native OHS applications. An OHS Application is an application that directly supports the OHS Presentation Protocol. Likewise, an OHS store is a store that directly supports the OHS Storage Protocol. The model in Figure 6 assumes that the OHS Session Manager is capable of using the standard Presentation Protocol and the standard Storage Protocol. This could be achieved by additional wrappers as in the Shim architecture (Section 3.3) or by adopting the OHS Session Manager to conform to the standards.
The main strength of the proposed general OHS architecture is the introduction of a second open hypermedia protocol (the Storage Protocol) and a second type of wrapper (the Storage Wrapper) handling integration of external stores such as databases, file systems, and special-purpose storage managers. Thus, integration of third party stores is handled in the same manner as integration of third party applications. The result is a simple and general model with few protocols and few types of architectural elements. The HyperDisco architecture shares the weakness with the DHM architecture that it is not made explicit where the content is stored if not stored in the workspace by means of the hypermedia database.
Nürnberg et al.  present an approach to supporting hypermedia at the operating system level. This includes a layered architecture denoted HOSS (Hypermedia Operating System Services). The HOSS architecture is depicted in Figure 7; the boxes correspond to processes. HOSS does not name the layers explicitly, but layers map to similar layers in the HyperDisco and DHM architectures. The top level processes represent general applications and two types of specific hypermedia applications. The second level, the Sprocs (Structure Processes) represent the different hypermedia services provided in terms of the different structures being managed. The third level, the HBprocs (HyperBase Processes) represents the storage of objects and associations. The lowest level represents the hosting operating system itself.
HOSS is a general conceptual architecture. The main strength of the HOSS architecture is the proposal for having multiple heterogeneous services (Sprocs) operating in parallel. The HOSS architecture thus proposes a broader spectrum of hypermedia services than just linking. Since the individual Sprocs provides different structures and services they also provide different protocols to the applications at the top level. A weakness in HOSS is that there is no distinction between structure and content storage. Since all HOSS objects are viewed as structural elements, the HOSS architecture specifies no explicit non-structural (content) storage.
Goose et al.  specify three areas that should be thoroughly investigated before a comprehensive reference architecture for future hypermedia systems can be defined:
OHRA is primarily an attempt to address the third issue. OHRA provides a model that illustrates how different OHSs can be integrated in a manner, which allows them to interoperate in a distributed and collaborative working environment (see Figure 4 in the OHRA paper also in this special issue).
OHRA introduces five components: viewer, runtime, link service, collaboration server and document management system and four protocols: viewer, collaborative, hypermedia and document management. The main strength of the OHRA proposal is that it sets focus on interoperability among OHSs. OHRA extends the view of OHSs to cover that the OHSs should themselves be open for integration. To facilitate such interoperability, OHRA introduces a distributed and collaborative model, which allows existing OHSs to interoperate at different levels using different protocols.
A weakness of OHRA is, however, that it seems to be more appropriate for the link server type of OHSs, which have no (or limited) support for collaboration and document management per se. In contrast to most of the hypermedia systems supporting some notion of collaboration, such as KMS , Intermedia , HyperDisco , DHM , OHRA proposes a separate architectural element that has collaboration support as its only responsibility. It is not clear from the proposal how the division of labor would be among a hyperbase with collaboration support and the collaboration server. Although the authors explicitly mention that it is possible to integrate open hyperbase type systems, it is not clear how this type of system can interoperate with other OHSs using the OHRA model. The scenario provided in  does not deal with these matters.
Another weakness of OHRA is that it is conceptually unclear what the distinctions between the different elements of the architecture are. Both the "Runtime" and "Link service" architectural elements appear in several different roles in the architecture (e.g., the Runtime in some situations covers entire systems including storage and in some situations its only a behavioral element in a system). This provides an argument to view OHRA as a proposal for implementing interoperability rather than as a reference architecture to be used for conceptual distinctions.
Table 1 summarizes the main strengths and weaknesses of the six candidate open hypermedia architectures and models analyzed in the previous sections.
|- emphasizes distinction between content and structure storage||- not open for addition of new types of modules and interfaces|
|- supports mapping of different systems to conceptual layers||- potential ambiguity in placing content storage in the architecture|
|- fits heterogeneous open hypermedia and communication protocols to each others||- limited scope
- shims become obsolete when standardized OHP is agreed upon
|- introduces an external storage protocol and storage wrappers||- same as DHM and HOSS|
|- introduces the concept of multiple heterogeneous hypermedia services||
- same as DHM and HyperDisco
|- focus on interoperability among different open hypermedia systems||- not a conceptual reference architecture
- complicated model
Table 1. Summary of strengths and weaknesses of the analyzed open hypermedia architectures and models.
The analysis summarized in Table 1 can help identify the main weaknesses to overcome and the main strengths to build on. We propose to make a synthesis of the following aspects of the analyzed architectures:
We see these four guidelines as the conclusion from the analysis, and in Section 5 we present a proposal for a common reference architecture which fulfils these guidelines. Before presenting this proposal a similar analysis will be made of the terminology used in open hypermedia architectures and models in order to propose common terminology for open hypermedia architecture discussions.
A reference architecture should be based on a consistent terminology. Based on the previous analysis and an analysis of systems described in [3, 9, 14, 19, 20, 26, 31, 38, 41, 46], a great diversity in terminology is revealed. Currently the OHS community uses a rich variety of different terms for essentially the same elements of the architectures. In the following, a term for each architectural element is proposed and the different terms used in the literature for essentially the same architectural element are enumerated.
The term Content Handler is proposed to describe the architectural elements of an OHS that supports viewing and editing of the actual data contents for the hypermedia structures. In the above systems and models content handlers are called: viewers, third party applications, participating applications, editors, applications, tools, metadata managers, hsh, ...
The term Hypermedia Service is proposed to denote the architectural element that handles the hypermedia structures at runtime. In the above systems and models this element is called: link service, runtime, tool integrator, session manager, hypermedia service, sproc, ...
The term Structure Database is proposed to denote the architectural element responsible for persistent storage of hypermedia structures. In the above systems and models this element is called: storage, link service, structure server, filter, OODB, HBMS, hyperbase, hyperbase system, workspace, data model manager, collaboration server, HBprocs, association set manager, ...
The term Interface is proposed to denote the connection between the hypermedia service and other architectural elements. In the above systems and models this is called: shim, protocol, wrapper, gateway, proxy, shell, communication translator, ...
To adopt a common reference architecture for open hypermedia, the open hypermedia community needs to agree on a consistent set of concepts, which provide a common understanding of the elements of the architecture. The choice of hypermedia data and process models such as Dexter and others should be orthogonal to the reference architecture. Although the above terminology seems quite diverse, there is much commonality in the functionality of the different elements across existing OHSs. In fact, there seems to be no serious obstacle - based on the examined systems - to just choose and define a term corresponding to each of the above elements. The common concepts introduced above will be used in the proposed reference architecture described in the following section.
This section presents a proposal for a Common Reference Architecture for open hypermedia (called CoReArc) as a synthesis of the important features of the examined architectures and reference models. The presentation will focus on the conceptual layers, architectural elements and interfaces of CoReArc. It will be explained how the four guidelines described in the "Summary of Architecture Analysis" (Section 3.7) have influenced the proposal. Moreover, a few examples of instantiations of the architecture are provided.
CoReArc is a layered architecture in the line of DHM/Dexter, HyperDisco and HOSS (see Figure 8).
The decisions made regarding the number of layers, the naming of layers, and the division of labor between the layers is an attempt to take the best ideas of the six analyzed architectures and models. CoReArc provides three conceptual layers:
Especially the first and second guidelines of Section 3.7 have influenced the conceptual layers of CoReArc. The first guideline led to a general and simple three layer architecture. The second guideline led to a clear distinction between storage of contents and storage of structure by having a Content Layer and a Structure Layer.
As shown in Figure 8, the central architectural element in CoReArc is the Hypermedia Service, which potentially can communicate with a number of architectural elements at all three layers through an open set of interfaces. The basic CoReArc diagram only depicts two other architectural elements (the Content Handler and the Structure Database and two interfaces connecting them to the Hypermedia Service (CHI and SDBI respectively). However, different instantiations of CoReArc will result in additional architectural elements and interfaces as illustrated in Section 5.4.
We envision the following division of labor between the basic architectural elements. The Hypermedia Service provides one or more of the services described in Section 2.1: navigation, structuring, integration, collaboration and interoperability. (Distribution is a feature of the entire architecture allowing architectural elements to be duplicated and run in parallel on different machines.) The Hypermedia Service will rely on the functionality of the Structure Database to provide the navigation, structuring and collaboration services. Integration and interoperability services will reside solely in the Hypermedia Service and will allow Content Handlers and other architectural elements to access the navigation, structuring and collaboration services.
To accommodate the fourth guideline of Section 3.7, many Hypermedia Service instances can run in parallel and provide different types of structuring, navigation and collaboration services to other architectural elements through an open set of interfaces.
Content handlers are in principle arbitrary applications that (in most cases) are not designed to be hypermedia applications. In order for Content Handlers to participate in an OHS, they need to be tailorable and support extensions regarding communication to Hypermedia Service, user interface to invoke hypermedia operations, and access to locspec information for selections made in the contents being handled.
Communication can take place in potentially many different places in the architecture. Communication interfaces are represented by a connection symbol between different architectural elements (lines with a double bar symbol on them). One could think of these interfaces as CORBA IDL interfaces. The interfaces represent peer-to-peer communication. This notation allows implementations either based on shims or interface modules in the architectural elements.
Two main conceptual interfaces are proposed in CoReArc, the Content Handler Interface (CHI) and the Structure DataBase Interface (SDBI). New types of services are envisioned in the future, which will lead to additional conceptual interfaces. Thus, there are a couple of dashed double bars, which are currently not connected to any architectural element. Among the types of integration that are expected to require new conceptual interfaces are document management systems, agents, and other hypermedia services. Thus, we envision a number of additional conceptual interfaces that can be useful in different settings such as the Document Manager Interface (DMI), the Agent Interface (AI), and the Hypermedia Service Interoperability Interface (HSII). These conceptual interfaces will be examined in Section 5.4.
One might object to the apparent complication of all of these conceptual interfaces, but the objective of this proposal is to make analytical distinctions between the different types of communications needed. The actual implementation of the conceptual interfaces should be similar to the idea of topics in DDE for Microsoft Windows or suites in Apples AppleEvent. The above conceptual interfaces may even themselves be divided into sub-suites, e.g., the CHI may have a core suite to handle linking and more advanced suites to handle composites [12, 18] and collaboration. The conceptual interfaces can thus be folded into a single physical protocol with common methods for initialization, error handling, etc.
Conceptual interfaces are logical definitions that may be communicated via many different kinds of on-the-wire protocols such as DDE, TCP/IP, CORBA, or Java RMI. A contribution from the Shim architecture is the proposal for having a specific module (the Shim) being responsible for translating between logical protocols and different types of on-the-wire protocols (the third guideline from Section 3.7). However, some of the standard component framework distribution mechanisms provide such protocol translations for free. Thus, it does not have to be a specific element in the hypermedia architecture.
The architecture diagram presented in Figure 8 is abstract and has a number of open points for adding new types of interfaces for systems. Moreover, it does not explicitly show how collaboration, distribution and interoperability is handled. This section concretizes these aspects by instantiating the abstract architecture into scenarios with specific systems and specific architectural elements involved.
A common kind of system to integrate with OHSs are standard document management systems such as Documentum and DocuPlex, which are used in many large enterprises to manage logical identification and access to documents [14, 20]. With our distinction between content and hypermedia structure, document management systems belong to the Content Layer (see Figure 9), since they manage only the documents that are structured by the hypermedia service.
Document management systems are different from typical viewer or editor types of content handlers, since they do not display or edit the content they only manage location independent identification, users' access and sometimes versioning of documents. We, thus, anticipate the specification of a new Document Management Interface (DMI), which contains operations to retrieve documents by Id, assign Ids to new documents, version existing documents, etc.
Agent technology  is becoming more common as means to filter information for users, e.g., on the Internet. Agents may learn from the user's search and browsing behavior and construct personal user profile structures that can be used to actively retrieve or filter relevant information for the user. Currently, agents are usually applied to textual contents or attributes assigned to contents. However, we foresee that agent technology will develop to search and filter based on the hypermedia structures themselves as well. Thus, we anticipate the specification of a new Agent Interface (AI). Moreover, we see agents as mainly a behavioral aspect of a hypermedia system and user profiles as a kind of structure, thus agents are placed at the Service Layer with their profiles at the Structure Layer (see Figure 10)
The AI is different from both the CHI and the SDBI, since it is mainly handling aspects such as assigning weights to or filtering structures being browsed or searched. The common way of communicating with agents is through a standardized language called KQML , which determines a need for a special agent interface [22, 33].
While it is easy to identify the specific architectural elements that handles integration, structuring and navigation services, distribution, interoperability and collaboration aspects are hard to express explicitly in a general architecture diagram. Interoperability is depicted implicitly in that each Hypermedia Service may communicate with other Hypermedia Services. The Hypermedia Service and Structure Database provide collaboration support, depending on the actual division of responsibilities among these two elements in a specific system. Distribution is depicted implicitly in that each Hypermedia Service may communicate with multiple Structure Databases and Content Handlers. Distribution, collaboration and interoperability is best illustrated by means of scenarios showing the actual configuration of instances of architectural elements in a specific use situation. Two different scenarios embodying CoReArc elements will be discussed.
Figure 11 depicts a scenario with two Hypermedia Services. Hypermedia Service 1 (HS1) manages a single user and hypermedia Service 2 (HS2) manages two users. HS1 and HS2 are both currently accessing two distributed Structure Database processes - one of these is shared (SDB2). Applying the collaboration suites of the interface, this setting supports asynchronous collaboration on the shared structures stored in SDB2 among users a, b and c. The communication via HSII directly between HS1 and HS2 may be used to enter into mutual sessions  or tightly coupled modes  of collaboration between users of HS1 and HS2.
Although this scenario does not describe an existing integration of systems, it would be a good description of an integration of DHM  (as HS1) and HyperDisco  (as HS2) where the SDBI has been standardized such that DHM hypermedia databases and HyperDisco workspaces can be accessed as a common distributed Structure Database system by both Hypermedia Services. Thus, CoReArc can be instantiated to illuminate both distribution, interoperability and collaboration aspects.
Figure 12 depicts a different scenario where a user is using one Content Handler (CH), which is connected to two different Hypermedia Services (HS1 and HS2) at the same time. Thus, the user is applying hypermedia structure residing in two different Structure Databases possibly residing at different places in the world. This illustrates that a tailoring of CH can be used to access two different Hypermedia Services. Again this scenario does not reflect an existing system integration, but it would be a good description of a setting where DHM/WWW  is used together with Microcosm's Distributed Link Service (DLS)  and the WWW. In this case CH would be Netscape Navigator, and the CHI based user interfaces would be provided through the DHM/WWW Java Applet and the DLS Gumshu respectively. This scenario describes the situation where a user may have layers of links from DHM and layers of links from DLS displayed on top of the same base WWW document.
This scenario may exist in a variant where both DLS and DHM/WWW use a proxy server approach, and all the structure retrieval and merging into HTML documents is handled at this level. This scenario can also be expressed with the proposed architectural notation as shown in Figure 13.
In this situation the communication interface represented with the double bars, does more work than just routing information; it composes a new message which represents a merge of content and structure in terms of the original HTML document with the external links inserted as common HTML link anchors .
This paper has provided a brief survey and analysis of six open hypermedia architectures and reference models with the goal to propose a common reference architecture for OHSs. The analysis revealed a lot of commonalties in the analyzed architectural elements, but it also uncovered a huge diversity in the use of terminology. We identified a small set of conceptually common elements, named them with proposed terms, and proposed a common reference architecture for open hypermedia named CoReArc. We believe that CoReArc is a good candidate for a common reference architecture for open hypermedia, which is conceptual, simple, general and extensible.
Many existing OHSs such as DHM, HyperDisco, HOSS and Microcosm can easily be mapped to the CoReArc conceptual architecture. The different OHSs are often broken down into a number of system modules, but at a conceptual level individual system modules can largely be categorized as belonging to a particular architectural layer. Thus, CoReArc can be seen both as a point of reference for comparing and analyzing the differences between existing OHSs and as a point of reference for identifying interfaces to standardize.
We wish to thank Jörg Haake, Charles Kacmar, Peter Nürnberg and Wendy Hall for their valuable comments, which helped improve the presentation of this paper. We would also like to acknowledge the contributions of the members of the open hypermedia community. A first version of this paper was presented at the 3rd OHS Workshop and we received encouraging and productive feedback. The work is partly sponsored by the Coconut project, CIT Project Grant #123, The Danish National Centre for IT Research.
 Robert M. Akscyn, Donald L. McCracken and Elise A. Yoder. KMS: A Distributed Hypermedia System for Managing Knowledge in Organizations. Communications of the ACM, 31, 7, (July 1988), 820-835.
 Kenneth M. Anderson. Integrating Open
Hypermedia Systems with the World Wide Web. In Hypertext '97
Proceedings, (Southampton, England, April 1997), ACM Press,
 Kenneth M. Anderson, Richard N. Taylor and E. James Whitehead, Jr. Chimera: Hypertext for Heterogeneous Software Environments. In ECHT '94 Proceedings, (Edinburgh, Scotland, September 1994), ACM Press, pp. 94-107.
 Tim Berners-Lee, Robert Cailliau, Ari Luotonen, Henrik F. Nielsen and Arthur Secret. The World Wide Web. Communications of the ACM, 37, 8, (August 1994), 76-82.
 Leslie Carr, David De Roure, Wendy Hall and Gary Hill. The Distributed Link Service: A Tool for Publishers, Authors and Readers. In WWW4 Proceedings, (Boston, MA, December 1995), O'Reilly & Associates, pp. 647-656.
 Jeff Conklin. Hypertext: An Introduction and Survey. IEEE Computer, 10, 9, (September 1987), 17-41.
 Hugh C. Davis. 2.5 Open Hypermedia System
Working Group Meeting. (Southampton, England, December 1996).
 Hugh C. Davis, Simon Knight and Wendy Hall. Light Hypermedia Link Services: A Study of Third Party Application Integration. In ECHT '94 Proceedings, (Edinburgh, Scotland, September 1994), ACM Press, pp. 41-50.
 Hugh Davis, Andy Lewis and Antoine
Rizk. OHP: A Draft Proposal for a Standard Open Hypermedia
Protocol. In , pp. 27-53.
 T. Finin, R. Fritzson, D. McKay, and R. MacEntire. KQML as an Agent Communication Language. In CIKM '94 Proceedings (November 1994), ACM Press.
 Stuart Goose, Andy Lewis and Hugh
Davis. OHRA: Towards an Open Hypermedia Reference Architecture and a
Migration Path for Existing Systems. In , pp. 45-61.
 Kaj Grønbæk. Composites in a Dexter-Based Hypermedia Framework. In ECHT '94 Proceedings, (Edinburg, Scotland, September 1994), ACM Press, pp. 59-69.
 Kaj Grønbæk, Niels
O. Bouvin and Lennert Sloth. Designing Dexter-based Hypermedia
Services for the World Wide Web. In Hypertext '97 Proceedings,
(Southampton, England, April 1997), ACM Press, pp. 146-156.
 Kaj Grønbæk, Jens A. Hem, Ole L. Madsen and Lennert Sloth. Cooperative Hypermedia Systems: A Dexter-based Architecture. Communications of the ACM, 37, 2, (February 1994), 64-74.
 Kaj Grønbæk and Randall
H. Trigg. Toward a Dexter-based model for open hypermedia: Unifying
embedded references and link objects. In Hypertext '96 Proceedings,
(Washington, DC, March 1996), ACM Press, pp. 149-160.
 Kaj Grønbæk and Uffe
K. Wiil. Towards a Reference Architecture for Open Hypermedia. In
, pp. 62-72.
 Jörg M. Haake, Christine M. Neuwirth and Norbert A. Streitz. Coexistence and Transformation of Informal and Formal Structures: Requirements for More Flexible Hypermedia Systems. In ECHT '94 Proceedings, (Edinburg, Scotland, September 1994), ACM Press, pp. 1-12.
 Frank G. Halasz. Reflections on NoteCards: Seven Issues for the Next Generation of Hypermedia Systems. Communications of the ACM, 31, 7, (July 1988), 836-852.
 Frank Halasz and Mayer Schwartz, The Dexter Hypertext Reference Model. Communications of the ACM, 37, 2, (February 1994), 30-39.
 Wendy Hall, Hugh Davis and Gerard Hutchings. Rethinking Hypermedia - The Microcosm Approach. Kluwer Academic Publishers, 1996.
 K. Jeffay, J. K. Lin, J. Menges, F. D. Smith and J. B. Smith. Architecture of the Artifact-Based Collaboration System Matrix. In CSCW '92 Proceedings, (Toronto, Canada, November 1992), ACM Press, pp. 195-202
 Søren B. Larsen. Hypermedia Agents - Towards a Protocol for Mediating Contents and Structure Search in Open Hypermedia Systems. Master's Thesis, Computer Science Department, Aarhus University, Denmark. 1997.
 John J. Leggett and John L. Schnase. Viewing Dexter with Open Eyes. Communications of the ACM, 37, 2, (February 1994), 76-86.
 Catherine C. Marshall and Frank
M. Shipman III. Spatial Hypertext and the Practice of Information
Triage. In Hypertext '97 Proceedings, (Southampton, England, April
1997), ACM Press, pp. 124-133.
 Catherine C. Marshall and Frank
M. Shipman III. Spatial Hypertext: Designing for
Change. Communications of the ACM, 38, 8, (August 1995), 88-97.
 Theodor H. Nelson. Computer Lib / Dream Machines, Redmond: Microsoft Press, 1987.
 John Noll and Walt Scacchi. Integrating Diverse Information Repositories: A Distributed Hypertext Approach. IEEE Computer, 14, 12, (December 1991), 38-45.
 Peter J. Nürnberg. Open Hypermedia
System Working Group web site.
 Peter J. Nürnberg and John
J. Leggett. And now for the tricky part: broadening the applicability
of open hypermedia systems. In , pp. 93-95.
 Peter J. Nürnberg, John
J. Leggett and Erich Schneider. As We Should Have Thought. In
Hypertext '97 Proceedings, (Southampton, England, April 1997), ACM
Press, pp. 96-101.
 Peter J. Nürnberg, John
J. Leggett, Erich Schneider and John L. Schnase. Hypermedia Operating
Systems: A New Paradigm for Computing. In Hypertext '96 Proceedings,
(Washington, DC, March 1996), ACM Press, pp. 194-202.
 Antoine Rizk and Louis Sauter. Multicard: An Open Hypermedia System. In ECHT '92 Proceedings, (Milan, Italy, December 1992), ACM Press, pp. 4-10.
 Michail Salampasis. An Agent-Based
Open Hypermedia Model for Digital Libraries. In , pp. 116-125.
 Norbert Streitz, Jörg Haake, Jörg Hannemann, Andreas Lemke, Wolfgang Schuler, Helge Schütt and Manfred Thüring. SEPIA: A Cooperative Hypermedia Authoring Environment. In ECHT '92 Proceedings, (Milan, Italy, December 1992), ACM Press, pp. 11-22.
 Manfred Thüring, Jörg Hannemann, and Jörg M. Haake. Hypermedia and Cognition: Designing for Comprehension. Communications of the ACM, 38, 8, (August 1995), 57-66.
 Randall H. Trigg. Guided Tours and Tabletops: Tools for Communicating in a Hypertext Environment. ACM Transactions of Information Systems, 6, 4, (October 1988), 398-414.
 Kenneth Utting and Nicole Yankelovich. Context and Orientation in Hypermedia Networks. ACM Transactions of Information Systems, 7, 1, (January 1989), 58-84.
 E. James Whitehead, Jr. An
Architectural Model for Application Integration in Open Hypermedia
Environments. In Hypertext '97 Proceedings, (Southampton, England,
April 1997), ACM Press, pp. 1-12.
 Uffe K. Wiil (editor). Proceedings
of the 3rd Workshop on Open Hypermedia Systems, Hypertext '97,
(Southampton, England, April 1997). CIT
Scientific Report no. SR-97-01, The Danish National Centre for IT
Research. July 1997.
 Uffe K. Wiil and Serge Demeyer
(editors). Proceedings of the 2nd Workshop on Open Hypermedia Systems,
Hypertext '96, (Washington, DC, March 1996). UCI-ICS Technical Report
96-10, Department of Information and Computer Science, University of
California, Irvine. April 1996.
 Uffe K. Wiil and John
J. Leggett. Workspaces: The HyperDisco Approach to Internet
Distribution. In Hypertext '97 Proceedings, (Southampton, England,
April 1997), ACM Press, pp. 13-23.
 Uffe K. Wiil and John J. Leggett. The
HyperDisco Approach to Open Hypermedia Systems. In Hypertext '96
Proceedings, (Washington, DC, March 1996), ACM Press,
 Uffe K. Wiil and John J. Leggett.
Concurrency Control in Collaborative Hypertext Systems. In Hypertext
'93 Proceedings, (Seattle, WA, November 1993), ACM Press, pp. 14-24.
 Uffe K. Wiil and E. James Whitehead,
Jr. Interoperability and Open Hypermedia Systems. In ,
 M. Wooldridge, and N. R. Jennings. Intelligent Agents: Theory and Practice. Knowledge Engineering Review, 10, 2, (October 1994).
 Kasper Østerbye and Uffe
K. Wiil. The Flag Taxonomy of Open Hypermedia Systems. In Hypertext
'96 Proceedings, (Washington, D.C., March 1996), ACM Press,