Open Hypermedia Systems Working Group
Introduction section compendium
1997.11.24
Open Hypermedia Systems Working Group
Introduction section compendium
1997.11.24
1.0 Introduction
This document contains the final and intermediate products of the Open Hypermedia Systems Working Group (OHSWG) effort. In this document, you will find a description of the group, its purpose, and history, released and in progress specifications, e-mail archives of discussions, pointers to off-site information that we are using, and much other material. This document is continually being updated and augmented as our work progresses.
We hope that this document will serve not only as a record of our work, but as an invitation for interested people to join our discussions and use our results. Each page of this document is maintained by one or more responsible people, whose names and contact information are included. Feel free to send questions or comments about any particular page to its maintainer(s) or to the group's mailing list. (The address of this list, as well as instructions on how to subscribe and post, are provided in the appendix page on group resources).
1.1 Brief description of the OHSWG
Peter J. Nürnberg, U Aarhus, Denmark
Previously, systems work in hypermedia tended to be directed toward the traditional application domain of navigation (i.e., the authoring and browsing of structure over data), as inspired by Bush's seminal article, As we may think [1945]. However, hypermedia structuring principles have been applied to a wide variety of domains, including hyperliterature and hypermedia art [Bernstein et al. 1991; Bolter and Joyce 1987; Bolter 1991; Kaplan 1994; Kinsella 1996; Landow and Kahn 1992; Leistøl 1994; Michalak and Coney 1993; Moulthrop 1989; Sawhney 1996], argumentation systems [Conklin and Begeman 1987; Fischer et al. 1989; McCall et al. 1990; Schuler and Smith 1990; Smolensky et al. 1988], spatial hypertext [Marshall and Shipman 1995], and systems for taxonomic work [Nürnberg et al. 1996, 1997; Parunak 1991, 1993].
Much systems work intended for supporting navigation is applicable to supporting these other domains as well. In order to deliver functionality to this broader class of clients, however, it was necessary to consider opening the set of structural abstractions supported by an OHS. A natural way in which to accomplish this is to generalize the link server of contemporary OHS's, replacing this single entity with an open set of link server peers (or simply, structure servers).
Considering an open set of structure servers, however, led to the separation of much of the component infrastructure from the definition of the structure server interfaces themselves. The definition and standardization of these component interfaces and the infrastructure that supports client/server interactions in this environment is the new focus of the group.
The basic purpose of the OHSWG is to standardize these aspects of OHS's. Currently, each OHS implements slightly different interfaces on different infrastructure, making applications integrated into one OHS unable to use the services of other OHS's. Standardization of these aspects of systems will allow clients to operate over all compliant OHS's. Since application integration is an open-ended task, such standardization saves effort on the most costly aspect of OHS implementation. Standardization also allows third parties to build naturally compliant application, bypassing the extra integration step completely.
Scenario-based specification. All functionality proposed to be part of a given architectural component should be justified through one or more scenarios of OHS use. That is, when proposing that some given functionality should be added to the OHS specifications, a scenario based on actual or foreseen use of an OHS should be submitted to the group for discussion. The group should reach a consensus on whether or not the scenario demonstrates the need for added OHS functionality before discussing how best to specify such functionality.
Component-based specification. Specifications should fall into one of three categories: infrastructure, domain, or framework. Infrastructure specifications address the functionality (interface and operational semantics) of OHS backends on which OHS middleware should be built. Domain specifications address the functionality of OHS middleware on which OHS clients can be built. Framework specifications address how components should request and deliver functionality they provide.
Open specification. The set of domain specifications is open, since the set of potentially useful structure models is open. Additionally, each domain specification should allow for extensibility and tailorability of the core abstractions defined by the specification.
1.2 Organization of this document
Peter J. Nürnberg, U Aarhus, Denmark
This document is divided into five sections and a set of appendices. The first section is entitled Introduction. It contains a brief introduction to the OHSWG, this explanation of the document organization, and a history of the group.
The second section is entitled Scenarios. It describes different scenarios of OHS use that direct the work of the group. It is a premise of this group that functionality should be added to a given architectural component only if a scenario for its use can be constructed and the group members can decide collectively that such a scenario should be handled by an OHS.
The third section is entitled Infrastructure. It describes the system infrastructure on top of which OHSWG middleware components should be built. It describes an OHS reference architecture, explanations of the responsibilities of the various architectural components in this reference architecture, and related issues.
The fourth section is entitled Framework. It describes the various technical issues in defining protocols between architectural components, interfaces to various components, and other related issues.
The fifth section is entitled Domains. It consists of an open set of descriptions of interfaces to OHS middleware. Each interface defines a different structural model to be used in a particular application domain.
The appendices consist of various additional group information, such as a list of subscribers to the OHSWG mailing lists, a complete listing and timetable for all OHSWG specifications and sample implementations, guidelines for authors of OHSWG material, and other related issues.
1.3 Message from the OHSWG chair
Uffe K. Wiil, CIT, Denmark
Open hypermedia technology is currently showing its potential for building hypermedia authoring and browsing environments encompassing existing, widely used applications such as Microsoft Word on Windows platforms and Emacs on Unix platforms. The ultimate goal is to introduce hypermedia technology into as many applications and components of existing computing environments as possible to evolve gradually current computing environments into a world-wide, unified hypermedia environment spanning multiple computing platforms. A significant step towards this rewarding and ambitious goal is to introduce open hypermedia standards that allow interoperability between the many small hypermedia environments that make up the global hypermedia environment. Standards also address the concerns of application developers who design applications and system developers who design hypermedia environments. This web site is the main source of information for the ongoing effort in the open hypermedia community to define common guidelines and standards for interoperation between open hypermedia environments.
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:
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. This historical overview sets the context for the contributions on this web site. The remainder of the overview is divided into four 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; and finally, Section 5 describes the current status of the standardization effort.
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.
Example: Link traversal in the WWW
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.)
Example: Link traversal in an open hypermedia environment
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).
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:
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.
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.
|
Time |
Name/Place |
Abbreviation |
Reference |
|
Jun 1998 |
4th Workshop on
Open Hypermedia Systems, |
OHS 4 |
planned |
|
Sep 1997 |
3.5 Open Hypermedia
System Working Group Meeting, |
OHS 3.5 |
[20] |
|
Apr 1997 |
3rd Workshop on
Open Hypermedia Systems, |
OHS 3 |
[21] |
|
Dec 1996 |
2.5
Open Hypermedia System Working Group Meeting, |
OHS 2.5 |
[6] |
|
Mar 1996 |
2nd Workshop on
Open Hypermedia Systems, |
OHS 2 |
[22] |
|
Sep 1994 |
1st Workshop on
Open Hypermedia Systems, |
OHS 1 |
[24] |
|
May 1994 |
Workshop, Open Hypertext Systems, |
[2] |
Table 1. Open hypermedia system workshops and working group meetings.
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 OHS 3.5 (September 1997). OHS 3.5 resulted in a major reorganization of the OHSWG as described in Section 5.
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:
Some of these scenarios have since been published at the OHSWG web site. As of December 1997, nine scenarios have been published on the web site and one scenario is being written.
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):
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.
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:
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.
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, 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:
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 [14] reflects this new organization of the work in the OHSWG.
[1] Anderson, K. M. A Critique of
the Open Hypermedia Protocol. In [21], pp. 11-17.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/anderson.html
[2] Aßfalg, R. (ed.). Proceedings of the Workshop on Open Hypertext Systems, (Konstanz, Germany, May 1994).
[3] Bapat, A. Propagating
Navigation. In [21], pp. 24-25.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/bapat.txt
[4] Barman, D. ACM Hypertext '96
Conference web site.
http://www.cs.unc.edu/~barman/HT96/
[5] Berners-Lee, T., Cailliau, R., Luotonen, A., Nielsen, H. F., and Secret, A. The World-Wide Web. Communications of the ACM, 37, 8, (August 1994), 76-82.
[6] Davis, H. C. 2.5 Open
Hypermedia System Working Group Meeting. (Southampton, England,
December 1996).
http://diana.ecs.soton.ac.uk/~hcd/research/invitation.htm
[7] Davis, H. C., Lewis, A., and
Rizk, A. OHP: A Draft Proposal for a Standard Open Hypermedia
Protocol. In [22], pp. 27-53.
http://www.daimi.aau.dk/~kock/OHS-HT96/Documents/ohp.html
[8] Davis, H. C., Reich, S., and
Rizk, A. OHP - Open Hypermedia Protocol. Working Draft 2.0, 20th June
1997.
http://diana.ecs.soton.ac.uk/~hcd/ohp/ohp.htm
[9] Demeyer, S. A Framework Browser
Scenario. In [21], pp. 26-36.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/demeyer.html
[10] Goose, S., Lewis, A., and Davis,
H. OHRA: Towards an Open Hypermedia Reference Architecture and a
Migration Path for Existing Systems. In [21], pp. 45-61.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/goose.html
[11] Grønbæk, K., and
Wiil, U. K. Towards a Reference Architecture for Open Hypermedia. In
[21], pp. 62-72.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/gronbak.html
[12] Haake, J. M. Collaboration via OHS:
A Scenario. In [21], pp. 73-80.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/haake.html
[13] Hall, W., and Davis, H. A
Southampton Scenario for OHS. In [21], pp. 81-85.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/hall.txt
[14] Nürnberg, P. J. Open
Hypermedia System Working Group web site.
http://www.csdl.tamu.edu/ohs/
[15] Nürnberg, P. J. Open
Hypermedia System Working Group web site - scenarios page.
http://www.csdl.tamu.edu/ohs/scenarios/
[16] Nürnberg, P. J., and
Leggett, J. J. Navigational 1. OHS scenario at the OHSWG web
site.
http://www.csdl.tamu.edu/ohs/scenarios/nav1/
[17] Reich, S. How OHP's LocSpecs could
benefit from ISO/IEC 10744. In [21], pp. 98-105.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/reich.ps
[18] Rutledge, L., Hardman, L., and
van Ossenbruggen, J. Applying the HyTime Model to the Open Hypermedia
Protocol LocSpec. In [21], pp. 111-115.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/rutledge.html
[19] Trigg, R. H., and
Grønbæk, K. Heterogeneity, Structure, and CSCW: Three
Challenges for Open Hypermedia. In [21], pp. 131-136.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/trigg.html
[20] Wiil, U. K. 3.5 Open Hypermedia
System Working Group Meeting. (Aarhus, Denmark, September 1997).
http://www.daimi.aau.dk/~kock/OHS3.5/
[21] Wiil, U. K. (ed.). 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.
http://www.daimi.aau.dk/~kock/OHS-HT97/
[22] Wiil, U. K., and Demeyer,
S. (eds.). 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.
http://www.daimi.aau.dk/~kock/OHS-HT96/
[23] Wiil, U. K., and Whitehead, E. J.,
Jr. Interoperability and Open Hypermedia Systems. In [21],
pp. 137-145.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/wiil.html
[24] Wiil, U. K., and
Østerbye, K. (eds.). Proceedings of the ECHT '94 Workshop on
Open Hypermedia Systems, (Edinburgh, Scotland, September
1994). Department of Computer Science, Technical Report R-94-2038,
Aalborg University. October 1994.
http://www.daimi.aau.dk/~kock/OHS-ECHT94/
[25] Østerbye, K. Fred the
Programmer. In [21], pp. 146-149.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/osterbye.html
[26] Østerbye, K., and Wiil,
U. K. The Flag Taxonomy of Open Hypermedia Systems. In Proceedings of
Hypertext '96, (Washington, DC, March 1996), ACM Press,
pp. 129-139.
http://www.cs.unc.edu/~barman/HT96/P51/Flag.ps.gz
Open Hypermedia Systems Working Group