home staff teaching research projects location search
Home People Teaching Research Projects Useful

Sigi's Open Hypermedia Protocol (OHP) Page

This page is a collection of pointers on OHP - the Open Hypermedia Protocol.

OHP is part of a larger effort of the Open Hypermedia Systems Working Group (OHSWG) to address interoperability in Open Hypermedia Systems (OHS).

On this page you'll find

A brief overview and introduction to the Open Hypermedia Protocol Navigational Interface (OHP-Nav for short - BTW: if you can think of a better name, please tell me).
Slides from a Technical Briefing held at Hypertext '99, Darmstadt (Feb. 1999).
An OHP timeline.
Pointers to definitions and examples.
Pointers to sourcecode.
Pointers to proposals of modifications, extensions, etc.
Other pieces of information.

A Brief Overview and Introduction to OHP

Early hypertext systems were monolithic and closed, but newer systems tend to be open, distributed, and support collaboration. While this development has resulted in increased openness and flexibility [Nürnberg et al., 1998], integrating or adapting various different tools, such as content editors or viewers was a tedious task. Many developers were implementing essentially similar components, simply for the benefit of having their own platform on which to experiment with hypertexts.

At the Second Workshop on Open Hypermedia Systems (OHS) held in conjunction with the '96 ACM Hypertext Conference [Wiil and Demeyer, 1996] the Open Hypermedia Systems Working Group (OHSWG) was formed, and its main focus was interoperability between OHS's [Wiil, 1997] . The group felt that the community had reached a level of maturity and stability such that it was possible to abstract the common features of the various systems, and to propose to move towards one of the major goals of any open system: interoperability.

The development of a common protocol was seen as one step towards this goal of interoperability. In 1996, at the Second Workshop on Open Hypermedia Systems, Hugh Davis presented the first draft [Davis et al., 1996] of a protocol named the Open Hypermedia Protocol (this also indicates how important it is to participate in these workshops! Check out Uffe's workshop pages to see about current calls and events!).

Hugh introduced us to the notion of a "shim", which Webster's Dictionary defines as "a thin often tapered piece of material (as wood, metal, or stone) used to fill in space between things (as for support, leveling, or adjustment of fit)", and which in - OHP terminology - should play the role of a converter between the various protocols spoken in Open Hypermedia Systems. Have a look at a Figure 1 in the original paper graphically depicting this relationship.

The idea was to establish a light-weight protocol that would serve as a testbed for interoperability and also would avoid the effort of having to re-implement viewers. Soon the development of the protocol was seen as one part of a larger effort of the OHSWG to address interoperability. This ambitious objective raised a number of issues including the following:

The domain of the protocol as well as its functionality have been criticized [Anderson et al., 1997, Nürnberg and Leggett, 1997] and the protocol was subsequently considerably changed and targeted towards a protocol for navigating hypermedia objects. It was also decided that other domains such as taxonomic hypertext or spatial hypertext will have to be addressed by future - and possibly extended - versions of OHP.

Subsequently a common data model has been proposed by the Open Hypermedia Systems Working Group. The model attempts to be as inclusive as possible in the sense that it is capable of representing the link models assumed by most existing hypertext systems. However, it does not attempt to model the systems that have particular features such as transclusions in Xanadu or spatial hypertext systems. These systems will probably need to design their own interfaces.

Addressing interoperability not only requires some common understanding of the data model, it also demands for the under-lying architecture to be investigated and agreed upon. This is because the data model makes assumptions about the architecture and also because functionality and behavior are to a large extent based on the architecture. Therefore, the issue of a reference architecture has been put onto the agenda of open hypermedia research and proposals thereof exist (see e.g. [Grønbæk and Wiil, 1997, Goose et al., 1997, Nürnberg and Leggett, 1997]). What all of the proposals have in common is some sort of client side software that is responsible for managing OHP communication to the various applications and their communication to linkservers. The current proposal therefore includes the recommendation for such a set of software components which has been named the client side foo (CSF) in order to avoid overloaded terms.

Also the communication mechanism to be used for OHP has been controversial. Various mechanisms can be imagined: a simple ASCII type tagged protocol imple-mented using sockets as originally proposed; a CORBA compliant implementation using IIOP; or an OHP version for the Web using the proposed standardized extension to HTTP, PEP (Protocol Extension Protocol, [Nielsen et al., 1997]). These issues are discussed by the Open Hypermedia Systems Group within the context of frameworks.

Why Interoperable Hypertext Systems?

Everyone benefits if hyper-text systems are interoperable; end-users, content providers and developers.

From an end-users' point of view for example, inter-operable systems would allow the use of hypertext functionality in a standardised way, similar to features such as cut/copy/paste that are so common in today's sys-tems [Pearl, 1989] . Furthermore, users would be better able to choose between different vendors of hypertext applications because basic functionality e.g., for navigation, would be supported by all systems. And finally, consumers would be able to re-use others hypertexts, i.e., the anchors, links, tours, trails, etc. that have been authored, often with a lot of effort, in a similar way that people exchange bookmarks today.

Content providers would benefit in that their products could be re-used on multiple platforms and systems. Hence, interoperable hypermedia systems would form the foundation that would allow information re-use [Garzotto et al., 1986] . Not only would this decrease costs but also it would improve the usability and thus the quality of hypertexts.

Developers on the other hand benefit from standards by being able to re-use tools and components. So some might specialise in writing scalable high performance servers; others might specialise in implementing feature-packed clients. Also, integrations or adaptations would only have to be done once [Nürnberg et al., 1998] . Furthermore, the increased availability of standard tools would result in a proven and stable platform on which developers could prototype and evaluate their new tools.

A Set of open Protocols

Already in the first draft of OHP the need for a standardised document management for OHS's has been raised. Also, proposals for a reference architecture for CB-OHS's include the need for a document management protocol to be used in conjunction with OHP [Goose et al., 1997, Grønbæk and Wiil, 1997, Nürnberg and Leggett, 1997].

The Hypertext Transfer Protocol (HTTP, [Berners-Lee et al., 1996]) had originally been designed to incorporate functionality for manipulating hypertexts. A "LINK" request for instance, would have allowed clients to create a relationship between a set of URIs. However, these features have never been commonly implemented by Web servers or clients, and in any case, they would only have allowed very basic manipulation of hypertexts.

Also, as a document management protocol HTTP suffers some deficiencies such as the lack of support for addressing parts of data ("give me the last 10 seconds of a two hour video file") or the lack of support for authoring and versioning which has already been proposed as an extension [Whitehead, 1997]. The OHSWG therefore wants to promote additional interfaces. For instance, there is a proposal for a content specification protocol [Griffiths et al., 1999] which defines document management services over WANs and which could be used in conjunction with the existing OHP.

Summary

Hypertext systems have come a long way from monolithic, closed systems to component-based open hypermedia systems (CB-OHS's). We believe that the current work on interoperability, in particular the revelation of interfaces and subsequent definition of individual interacting components will ultimately lead to interoperable systems. These will benefit the end-users as consumers of hypertexts, the content providers as producers of hypertexts and finally also the system developers themselves.

Home - People - Teaching - Research - Projects - Useful - Search