Open Hypermedia: Systems, Interoperability and Standards

1 Introduction

Open hypermedia research addresses the issues of integrating hypermedia functionality into existing applications in the computing environment. An open hypermedia system (OHS) is typically a middleware component in the computing environment offering hypermedia functionality to applications orthogonal to their storage and display functionality. Using the services of an OHS, existing applications in the computing environment can become "hypermedia enabled", thus supporting linking to and from information managed by the application without altering the information itself. To become "hypermedia enabled", applications must be extended to make the hypermedia functionality available in the user interface and must be able to communicate hypermedia requests to the OHS. The term open hypermedia environment is used to cover both the OHS and the set of hypermedia enabled applications. An open hypermedia environment is a subset of the overall computing environment in terms of applications, programs and services.

OHSs are currently being deployed in various application domains, including digital libraries, computing support for large engineering enterprises, software development and education. Yet, open hypermedia developers have until recently lacked consensus, common guidelines and standards for interoperation between OHSs and applications that request hypermedia services. Without such guidelines and standards, each open hypermedia system uses different approaches and techniques that inhibit interoperability. The immediate results of this are:

• Lack of presentation interoperability: applications enabled for one particular OHS cannot be used with other OHSs. Thus, currently, each application has to be enabled separately for each OHS instead of just once for all OHSs.
• Lack of storage interoperability: hypermedia structures built using one particular open hypermedia environment cannot be accessed and used by other open hypermedia environments. Thus, currently, each open hypermedia environment is an "island" instead of a part of a larger, unified hypermedia environment.
• Lack of system interoperability: hypermedia structures cannot be built across different open hypermedia environments. It is, for instance, not possible to create a link with one end in one particular open hypermedia environment and another end in another open hypermedia environment. This adds to the problem of open hypermedia environments being "islands" as mentioned above.

The open hypermedia community is currently addressing interoperability issues by defining a set of guidelines and standards for interoperation. A working group has been formed, and a number of meetings have been held in this ongoing standardization effort. The purpose of this special issue is to gather the best ideas from many individuals that participated in the open hypermedia meetings up until the summer of 1997. The contributions in the special issue capture the latest approaches and present useful lessons, guidelines, strategic goals and points of view on how to proceed with the work towards interoperability and standards for OHSs.

This editorial sets the context for the contributions in the special issue. The remainder of the editorial is divided into five parts. Section 2 contrasts closed and open hypermedia systems; Section 3 identifies different approaches to open hypermedia; Section 4 describes previous historical events of this ongoing standardization effort; Section 5 introduces each paper in the special issue; and finally, Section 6 describes the current status (as of November 1997) of the standardization effort.

2 Open versus closed hypermedia

The term open has different meanings in different contexts. Generally, a software system can be categorized as open if it specifies and publishes interfaces between its system components. However, what does open mean in the context of hypermedia systems and what does closed (or monolithic) mean? An important matter in hypermedia systems is the distinction between structure and content. Therefore, a hypermedia system that imposes a specific data model format (specifying both structure and contents formats) on its hypermedia enabled applications can be considered closed, since applications have to be custom-made to participate in this type of environment. In contrast, an open hypermedia system only imposes a specific structure format on its hypermedia enabled applications. Allowing applications to store contents in different formats potentially outside the hypermedia system is a basic requirement for integrating and using existing applications in an open hypermedia environment [26]. For example, the World Wide Web (WWW) [5] imposes the HTML format on its browsers (HTML embeds structure in the contents). The following example illustrates the conceptual operation of the WWW.

Link traversal in the WWW

1. The user clicks on an anchor in an HTML file displayed in a WWW browser. By definition, the URL for the other end of the link is embedded in the HTML file being displayed.
2. Based on the information in the URL, the WWW browser sends a "get" request to the appropriate WWW server holding the file at the other end of the link.
3. The WWW server sends the file back to the WWW server.
4. Based on the type of the file, the WWW browser will do one of the following:
5. • HTML file: the document contents will be interpreted and the document will be displayed with outgoing links if any. It may now be possible for the user to follow links to other files.
   • Other file type: the browser can itself display some file types (gif, xbm, etc.), but these file types have no outgoing links. (Only HTML files hold linking information.) If the browser cannot display the file itself, it will launch a plug-in or a separate application that can display the file. These applications have not been enabled to support hypermedia linking. Thus, in either case, the user has now reached a dead end in the hypermedia with no links to follow.

From a general software system perspective the WWW is open, since the interface between browsers and servers is well defined (the http protocol). However, a WWW browser must be custom-made to interpret and display HTML files. In order to integrate an existing application to operate as a WWW browser, the application would have to be altered to use HTML as its basic data model format. This would in most cases require a major rewrite of the application. From this perspective, the WWW is a closed hypermedia system. In general, a closed hypermedia system is characterized by only handling a closed set of data model formats and by having a closed set of hypermedia enabled applications that participate actively in the hypermedia services. An application that is simply launched to display a file cannot be considered a hypermedia enabled application, since it is unaware of the hypermedia system launching it.

An open hypermedia system allows an open set of applications to participate in the hypermedia services and supports an open set of data model formats. The following example illustrates the conceptual operation of an open hypermedia environment. (The exact operation varies from system to system.)

Link traversal in an open hypermedia environment

1. The application communicates a traverse link request to the open hypermedia system due to some action, which can be triggered by a user click on an anchor or by some other event taking place in the application.
2. The OHS resolves the link and determines the file(s) at the other end of the link. Some OHSs support n-ary links in which case step 3 will be repeated for each file at the other end of the link.
3. The OHS can now do one of the following things to display the file:
4. • It can request that an already running hypermedia enabled application display the file.
   • It can launch a hypermedia enabled application to display the file.
   • In case no hypermedia enabled applications can display the given file type, the OHS can (like the WWW) launch a "non-hypermedia-aware" application to display the file. Again, the user has reached a dead end with no available links (steps 4 through 8 do not take place for this file). In general, new data model formats can be supported in an open hypermedia environment by enabling an (existing) application that can handle the required data model format.
5. Based on the information from the OHS, the hypermedia enabled application opens the requested file (e.g., by retrieving the file from the file system).
6. The hypermedia enabled application sends a message to the open hypermedia system requesting anchors for the displayed file.
7. The OHS replies with a list of anchors.
8. The hypermedia enabled application displays the anchors and highlights the particular anchor that was connected by the traversed link.
9. The user can now traverse available links from the newly displayed file.

OHSs store the structure separate from the contents. Structure is superimposed on the contents at display time by the hypermedia enabled application handling the contents. Thus, the open set of applications making up an open hypermedia environment can link to and from documents available from many sources (including read-only sources) in the computing environment (e.g., file systems, CD-ROM's and databases).

3 Open hypermedia approaches

The overall goal in the design of an OHS is to produce a general set of hypermedia services that can be used by other applications, programs and services in the computing environment. A minimal requirement for an OHS is the provision of basic hypermedia linking services to an open set of applications (the ability to create, delete and modify anchors and links and the ability to traverse links). These services allow existing contents to be overlaid with hypermedia structures. Despite this common goal, existing OHSs vary in different ways:

• They introduce different ways (protocols) to communicate with enabled applications. Some OHSs use sockets (TCP/IP), others use remote procedure calls, while still others use platform dependent solutions such as Apple Events (Macintosh) or OLE (Windows).
• They introduce different hypermedia data models. Open hypermedia data models vary with respect to the number of endpoints of a link (two or more), whether or not they have a notion of anchor, etc.
• They introduce different hypermedia services. Some OHSs only support the basic hypermedia services that allows anchors and links to be attached to existing data, while other systems support more advanced features such as support for collaborative authoring of hypermedia structures and contents.
• They introduce different hypermedia system architectures. The spectrum of open hypermedia architectures introduced by current systems span from centralized client-server systems with a single storage server running on a local-area network to distributed multi-layered systems with multiple storage servers running at different Internet domains.
• They support different structures. Basically, all OHSs support hypermedia linking structures. In addition, some systems support other types of structures as well (composites, information retrieval links, spatial structures, taxonomic structures, etc.).
• They are typically divided into two general categories, open hyperbase systems and link server systems. Both categories provide basic hypermedia linking services to an open set of applications. In addition, open hyperbase systems provide hypermedia storage services as well, which includes the ability to store contents in the OHS (if desired) and various types of support for multiuser and collaborative authoring sessions over both hypermedia structures and contents (access control, version control, concurrency control and event notification).

The lack of consensus in the open hypermedia community about what exactly an OHS is (i.e., what data model and services they should provide and how they should be built) has led to the current line of workshops and meetings described in Section 4.

4 Historical overview of standardization efforts

The open hypermedia community has established itself as a very active part of the hypermedia community. Four workshops and two working group meetings have been held since 1994 (Table 1). Another workshop is planned for Hypertext '98 in June 1998. The workshop series at ACM Hypertext Conferences started in September 1994 at ECHT '94 in Edinburgh, Scotland. The ACM Hypertext Conference workshops are named in numerical order starting with the first at ECHT '94. The workshop in May 1994 in Konstanz, Germany is unrelated to the present line of events and will not be discussed further in this historical overview.

---

---

OHS 1 [24] resulted in two working groups, one focusing on open hypermedia reference models and one dealing with interoperability in OHSs. While the two groups never formally met, individual members of the groups conducted related research and produced a number of significant results, which were presented in position papers at OHS 2 [22] and in conference papers at the ACM Hypertext '96 Conference [4].

The participants at OHS 2 decided to form one new working group on OHSs. The initial mission of the Open Hypermedia System Working Group [14] (OHSWG) was to address two key issues: defining open hypermedia systems (the scenario subgroup) and defining open link services (the protocol subgroup). The OHSWG held its first meeting in December 1996 in Southampton [6] (named OHS 2.5 to indicate that the meeting took place in between OHS 2 and OHS 3). A third key issue, defining an OHS reference architecture (the reference architecture subgroup), was added to the OHSWG agenda at OHS 2.5.

On the surface, these three subgroups may have seemed independent. However, the idea was that the construction of the scenarios must inform the design of the architecture, which in turn specifies what protocols must be defined. The architecture cannot be designed without grounding in actual examples of how designers envision OHSs being used in the real world to solve real problems. Protocol design can only take place within an architectural framework.

By the time of OHS 3 [21], each of the three subgroups had produced significant results that were reported in position papers at the workshop. Of a total of twenty submissions, six position papers presented different scenarios, three position papers proposed different reference architectures and three position papers addressed protocol issues. OHS 3.5 in September 1997 in Aarhus [20] focused on protocol issues. The goal was to get a first working version of a linking protocol finished to allow for future implementations and interoperability experiments. The linking protocol is the protocol between applications and open hypermedia systems, which enables presentation interoperability.

Sections 4.1 through 4.3 describe the rationale behind each of the three OHSWG subgroups (scenario, reference architecture and protocol) and provide a brief overview of the work done by each subgroup up until the summer of 1997.

4.1 Scenario work

The purpose of writing scenarios is to try to define the scope of OHSs by example. Instead of defining the systems themselves, a "canonical" set of scenarios can be constructed to describe problems that can be addressed by OHSs. These scenarios should give the open hypermedia community a common terminology that can be used to measure the relative strengths and weaknesses (and the relative applicability) of different approaches to the open hypermedia application domain.

The OHSWG web site [14] became operational shortly after OHS 2. Among other things, the web site is used to publish scenarios and instructions [15] on how to submit scenarios to the OHSWG. The first scenario, "Navigational 1" [16], was submitted shortly before OHS 2.5 (November 1996). OHS 3 received a total of six scenarios dealing with many different aspects of open hypermedia:

• Propagating Navigation [3]
• A Framework Browser Scenario [9]
• Collaboration via OHS: A Scenario [12]
• A Southampton Scenario for OHS [13]
• Heterogeneity, Structure, and CSCW: Three Challenges for Open Hypermedia [19]
• Fred the Programmer [25]

Some of these scenarios have since been published at the OHSWG web site. As of November 1997, nine scenarios have been published on the web site and one scenario is being written.

4.2 Reference architecture work

The effort to define a reference architecture for OHSs is both of theoretical and practical interest. On the theoretical side, such an architecture will allow researchers to compare and contrast various systems. On the practical side, such an architecture can serve as the starting point for interoperability efforts at different architectural levels, including presentation and storage interoperability (Section 1), by identifying the necessary protocols among OHS components.

The reference architecture issue was added to the OHSWG agenda at OHS 2.5. Three position papers on the subject appeared at the following workshop (OHS 3):

• OHRA: Towards an Open Hypermedia Reference Architecture and a Migration Path for Existing Systems [10]
• Towards a Reference Architecture for Open Hypermedia [11]
• Interoperability and Open Hypermedia Systems [23]

These papers deal with different aspects and issues of open hypermedia architectures and propose different reference architectures for open hypermedia. The proposals identify a number of protocols that should be considered in OHS design.

4.3 Protocol work

The work in the protocol subgroup has mostly focused on the definition of a standard linking protocol. Through the linking protocol, various levels of hypermedia awareness on the part of the application, as well as various levels of functionality on the part of OHS, are implicitly defined. The work on the linking protocol will not only address the research question of the nature of open link services, but also provide a practical method of allowing presentation interoperability between different open hypermedia environments (Section 1).

A first draft version of a standard linking protocol for open hypermedia (called the Open Hypermedia Protocol version 1.2 or simply OHP 1.2 [7]) was presented at OHS 2. The OHP proposal was well received and was discussed again in detail at OHS 2.5. At OHS 3, three position papers provided critique and proposed changes to the OHP 1.2 proposal:

• A Critique of the Open Hypermedia Protocol [1]
• How OHP's LocSpecs could benefit from ISO/IEC 10744 [17]
• Applying the HyTime Model to the Open Hypermedia Protocol LocSpec [18]

Based on all the feedback, the OHP was extensively revised, and OHP version 2.0 [8] was released shortly before OHS 3.5. Both at OHS 3 and at OHS 3.5, other protocols (e.g., the storage protocol, which enables storage interoperability between open hypermedia environments) received increasing attention.

5 Contributions in this special issue

This special issue contains four research contributions from members of the OHSWG. The contributions are all based on papers from OHS 3 and cover the three OHSWG subgroup areas quite well (scenario, reference architecture and protocol). The papers were submitted in early June 1997 before OHS 3.5, which took place in September 1997. Most of the authors decided not to reflect the work that was done and the decisions that were made at OHS 3.5 when they made their final revisions for this special issue during the month of October 1997. However, the paper by Anderson, Taylor and Whitehead includes work and decisions from OHS 3.5. Section 6 provides a brief overview of the results of OHS 3.5.

The paper by Nürnberg and Leggett describes a vision for OHSs based on the authors' previous work in the OHS field. The authors envision that OHSs will evolve from being systems that essentially only serve an associative structure model (anchors and links) to being systems that serve an open set of structure models (associative structures, spatial structures, taxonomic structures, etc.) to its hypermedia enabled applications. The paper presents four different open hypermedia scenarios and uses the implications of these scenarios to motivate modifications to existing OHSWG proposals for reference architectures and protocols. A reference architecture and a set of protocols that can support an open set of structure models is proposed. The paper is based on the ideas described in the workshop paper entitled "And now for the tricky part: Broadening the applicability of open hypermedia systems".

Goose, Lewis and Davis identify three objectives for establishing a user environment that can encompass all existing OHSs: agreement upon a specification for location specifiers, an actual reference architecture for OHSs, and a globally distributed and collaborative model with a clear evolution path for existing OHSs. The authors address the third objective and present three different alternatives to achieve this objective. The proposed OHRA model illustrates how different OHSs can interoperate to form a powerful, distributed and collaborative user environment. Finally, an interoperability scenario shows how existing OHSs can be mapped to the OHRA model. The paper is a revised version of the workshop paper entitled " OHRA: Towards an open hypermedia reference architecture and a migration path for existing systems".

The paper by Grønbæk and Wiil presents a common reference architecture for open hypermedia. The authors identify a set of requirements and services for open hypermedia and examine some of the most prominent open hypermedia architectures and reference models. The analytical results are used to propose common terminology and a common reference architecture for open hypermedia (CoReArc). CoReArc identifies several architectural elements and communication interfaces that can be standardized to achieve different types of interoperability (presentation, storage and system). A number of scenarios are used to illustrate the functionality and operation of the individual architectural components. The paper is a revised version of the workshop paper entitled "Towards a reference architecture for open hypermedia".

Anderson, Taylor and Whitehead presents an analysis and discussion of the OHP. The paper provides an overview of the OHP (focusing on version 1.2), performs an analysis of its strengths and weaknesses, and makes specific recommendations for improvements to the protocol. Since the inception of the OHP, the authors have been actively involved in the attempts to evolve the OHP into a useful standard. At OHS 2, Taylor presented an invited talk on various aspects of the protocol including success/failure criteria, separation of concerns, and opportunities for leverage. At OHS 3, Anderson presented an earlier version of this paper. The present version of the paper captures the entire evolution of the OHP and includes important discussions that occurred at previous OHS workshops, OHSWG meetings and on the OHS mailing list.

6 Current status

A number of important decisions effecting the OHSWG's work were made at OHS 3.5 in September 1997. The three most dominating decisions taken were to adopt the scenario-driven idea to support an open set of structure models as advocated in the Nürnberg and Leggett paper in this special issue, to adopt a component-based approach to develop OHSWG compliant systems, and to base the implementation on existing component technology. The other decisions taken were more or less natural extensions to these ideas:

• Architecture. The architecture of an OHSWG compliant system includes three layers: storage, structure models, and hypermedia enabled applications. The structure model layer allows an open set of structure models to be served to hypermedia enabled applications. Each structure model will be served by a separate component in the architecture. One important model to be served here is the navigational (associative) hypertext model, which used to be the primary focus of the work in the OHSWG.
• Interfaces. The more general term interface was adopted instead of the term protocol. Each component provides a separate interface serving a specific structure model. Thus, the navigation component will implement the navigation interface. This decision expands the focus of the OHSWG work from the navigational domain to other structure domains such as spatial hypertext and taxonomic hypertext. As a result, an OHSWG compliant system can provide a number of interfaces to hypermedia enabled applications instead of just one (navigation interface).
• Component technology. Existing component technology enables the specification of a component's services (interface) in an implementation independent manner. In addition, a component framework, such as CORBA or Java RMI, implements low-level protocol issues automatically once implementations are supplied for the specific interfaces.

Thus, what used to be the concerns of the OHP is now being handled in the navigation component and by the underlying component framework. The OHSWG web site reflects this new organization of the work in the OHSWG.