Stuart Goose
Andy Lewis and Hugh Davis
A small working group, co-ordinated by Davis, began work on establishing a protocol for open hypermedia systems (OHS). The initial aim of this protocol was to enable third party applications to access open hypermedia link service functionality in a consistent and standard manner. The first draft of the open hypermedia protocol (OHP) specification [8] appeared as a position paper at the OHS 2 workshop. It was generally acknowledged by the workshop attendees that the field was sufficiently mature for a standard to be defined, and as such the OHP initiative was launched.
At the OHS 2.5 workshop [6] the attendees continued discussions on both the OHP and practical scenarios. The group recognised that it was proving increasingly difficult to make progress on defining OHP without first establishing a reference architecture for open hypermedia systems upon which to base discussions. To date two reference models have been described in the literature. The Dexter Model [15] attempts to provide a standard hypermedia terminology coupled with a formal model of the common abstractions found within contemporary hypermedia systems. A three layer conceptual data model is presented without any suggestion of an architecture for realising the model. The Flag Taxonomy [20] attempts to capture the functionality and interaction of hypermedia systems in such a manner as to aid classification. Although some dissent exists in the research community as to whether Dexter is the appropriate reference model for hypermedia, it provides a principled basis upon which these discussions can take place. The authors of the Flag Taxonomy provide a parallel reference model for open hypermedia.
To establish an inclusive reference architecture for future open hypermedia systems we firmly believe that the following areas need to be satisfactorily addressed:
Preliminary work by Reich [21] and Rutledge et al [23] propose solutions for addressing the first issue of open location specifications. Grønbæk et al [14] provide an initial attempt at the second issue, a reference architecture for an open hypermedia system. They propose a synthesis architecture based around the conceptual layers of the Dexter Model and introduce three protocols for integrating with external entities.
In this paper we address primarily the final objective listed above, and present a model which illustrates how differing open hypermedia systems can be integrated in a manner which provides a powerful, distributed and collaborative architecture. By sub-dividing OHP into four distinct protocols for communication between four core components, hypermedia systems can buy into the reference architecture at the required level, hence providing a migration path.
During discussions on OHP at the OHS 2.5 workshop, it soon became apparent that this solution would prove inadequate. Although the protocol shim would enable third party applications to access a link server residing on a remote machine, the rich set of tools (e.g. navigation) that accompany most contemporary hypermedia systems would no longer be available within the user's environment. One solution is for the user to run an X windows server on their machine and thus allow the display of the link service tools to be redirected to their own screen. This is only a partial solution as similar facilities are not available for Microsoft Windows or Macintosh environments that enable applications to have their display redirected to remote machines. It is clear that this is not a problem if the link server(s) being accessed is executing on the user's machine, but a preferable solution would not be limited by such a constraint.
Much research has been conducted and many tools developed to assist
with hypermedia authoring [18, 5], the location of relevant documents
using content-based retrieval [17, 10] and the subsequent navigation
of such resources [4, 9]. The aim of the OHP initiative is
to enrich the user's environment by integrating third party
applications with existing link services, not to reduce the
effectiveness of link services by rendering the functionality of these
associated tools inaccessible to the end user. To overcome this
deficiency there was general agreement that some form of runtime on
the user's machine was necessary, extending the original model to that
shown in figure 2. The form and
functionality of the runtime was not decided, but one possible
approach would be to use a Java virtual machine [11] and develop a framework to allow
additional tools and functionality to be dynamically downloaded to the
user's machine. It is envisaged that the protocol shim functionality
will be incorporated within the runtime component.
Although not a pre-requisite for open hypermedia, the capability of
supporting collaborative work was thought by the working group to be
of key importance. The group therefore decided that a reference model
should not preclude such functionality from being incorporated at a
future date. A further requirement identified by the group as being of
importance was that of multimedia document/object management. A myriad
of both commercial and academic solutions exist for the management of
documents and, as such, the reference model needs to be open enough to
allow developers to utilise any third party product. Although the
exact functionality of each component and the protocols required to
connect them were left undefined, it was concluded at the December
meeting that the somewhat nebulous model shown in figure 3 would be useful in providing direction
for the OHP initiative.
It can be seen from this that the initial aims of OHP were too limited
in scope, and that for this initiative to encompass and enhance both
current and future developments in the field of hypermedia, it was
necessary to consider a far more advanced and flexible model.
Although this approach offers great flexibility and the potential for
a zero administration client, each link server must assume that the
runtime component has no local hypermedia tools of its own and should
therefore offer to provide them. This again, demands a complete
re-invention of the wheel, not once for each platform as with the
first approach, but once for each different link server. As each
different link server will supply its own client-side hypermedia tools
the problem of interface inconsistency is exacerbated. An additional
penalty will also be incurred each time a new tool is dynamically
downloaded prior to usage.
Rather than dictating that each runtime or link server must conform to
a rigid specification, this approach is designed to accommodate their
differences and allow them to co-exist. Additionally, this approach
would allow a hypermedia system with its own set of proprietary
viewers to utilise third party remote link service(s). A full
definition of the essential components and protocols is required to
achieve this.
Allowing a hypermedia system to act as a runtime component within the
model means that the hypermedia system can augment locally provided
link services with those of a remote link service(s). Interestingly,
if a runtime is represented by a hypermedia system with a link
service, then there is no reason why the runtime cannot also act as a
link service. Conversely, if a link service is represented by a
hypermedia system, then there is no reason why the link service cannot
also act as a runtime. This blurs the distinction between the two
entities as a client runtime can masquerade as a link server and a
link server can masquerade as a client runtime. It is by virtue of
their dual roles that greater scope for configuration is possible.
The authors strongly advocate this approach as it is the most
pragmatic of the three suggestions outlined in this section. This
approach appeals to common sense as there exists little reason for
discarding years of development when it can be exploited within the
model.
One approach to provide open and versatile LocSpecs would be to adopt
a similar technique used by Apple for the Macintosh inter-application
communication system. A LocSpec would consist of a set of named, typed
fields, each able to contain any form of data. There would be no
compulsory fields, but instead an expandable published standard
defining "sets" of fields and how they are to be used. As an example,
one set may be for the representation of text, and may define fields
which contain the text itself, character offset, length, paragraph and
word offset, preceding characters, anteceding characters, etc. Another
set would be defined to give document specifications. Sets may
complement each other, or may contain the same information in
different forms. Components receiving a LocSpec would look for their
preferred fields first, but may then fall back on more basic forms if
those were absent. This would be a highly versatile approach, but
careful attention would need to be paid in defining the initial sets
and in establishing a mechanism for people to publish their own. This
is an area requiring further discussion.
3. Why Re-invent The Runtime?
A runtime component will act as a mediator between the viewers and the
desired link server(s), but, as argued earlier, a minimal
implementation would be less than satisfactory for most users. We have
identified three distinct approaches to providing a runtime component
able to offer the rich set of presentation, authoring, navigation and
hypermedia link service tools that accompany many contemporary
systems.
3.1. Fresh Runtime Implementation
One solution is to implement the runtime and the entire range of
client-side hypermedia tools from scratch. This approach obviously
signifies a complete re-invention of the wheel and would, in our
opinion, involve an unreasonable amount of effort. The resultant
runtime would be, to some degree, platform dependent but only one
implementation would be required per platform. Although this approach
is unappealing, one significant advantage would be that a consistent
user interface could be provided across the platforms, as has been
achieved by Netscape, for example.
3.2. Virtual Machine Approach
An alternative approach would be to use a virtual machine, thus
allowing a minimal runtime component to be implemented in a byte-code
interpreted language, such as Java [11]. This has the advantage of being
extremely versatile as the associated client-side hypermedia tools can
be dynamically downloaded from the link server and executed
locally. In addition to this, the user can incorporate any custom
written tools with the runtime to supplement those provided by the
link server.
3.3. Reusing Existing Hypermedia Systems as Runtimes
A third alternative is to allow any existing hypermedia system to be
used as the runtime component. This strategy promotes the wholesale
re-use of existing and familiar client-side hypermedia tools, which is
an attractive proposition. This approach is also sufficiently open to
integrate with and combine the previous two approaches. This would
allow both the developer and user complete freedom over their choice
of runtime, which by adopting this approach would be their favoured
open hypermedia system.
4. Expressing Location Specifiers
A crucial part of the OHP [8] was the
Location Specifier, or LocSpec [13].
The original design of an OHP LocSpec was reviewed at the OHS 2.5
workshop [6], with the participants
universally agreed that it was insufficient for the needs of many
hypermedia systems and hence required improvement. Although too
detailed a topic to be rigorously addressed here, the reader is
referred to Reich [21] and Rutledge
et al [23] for a
comprehensive treatment of these issues. An archived discussion list
contains the most recent arguments
and proposals by active members of the open hypermedia research
community regarding the specification of LocSpecs. The authors feel
that if the approach advocated in this paper is to work effectively
then it is imperative that the final definition for a LocSpec be
sufficiently open and versatile. Ideally, LocSpecs should be able to
represent any anchor types used in any hypermedia system, past present
or future. This is a difficult, perhaps impossible goal, but a
challenging research topic.
5. An Open Hypermedia Reference Architecture (OHRA)
It has been discussed in previous sections how the OHP initiative has
driven the need for a well defined and open architecture while
retaining the rich hypermedia environments to which users have become
accustomed. Using the model in figure 3
as a starting point, we examine the protocols required to connect the
components and then present a reference architecture for open
hypermedia. We then review the individual components and discuss their
role within the architecture.
As an initial step, initiatives such as ODMA require investigation to examine and question whether or not they are sufficiently rich to support the activities required to deliver open hypermedia. Such an effort is already underway. For example, the ODMA standard has no mention of support for the streaming of multimedia objects. Although DHM [12], HyperDisco [29] and SP3 [16] provide proprietary solutions for document management and version control, further research is necessary to determine the minimum requirements of a document management system for open hypermedia and hence define a standard interface to third party products. Key issues to resolve include:
5.2.1. Viewer
Any third party application that respects the Viewer Protocol is able
to participate as a viewer in this architecture. This could be a
specially modified hypermedia viewer which had been written for an
existing system, a third party application with the necessary
modifications (e.g. Microsoft Word with custom written macros), or a
viewer explicitly developed to be Viewer Protocol compliant. If there
is a requirement for multimedia viewers to render in real time
streamed continuous media from external document management systems,
it is also necessary to support the Document Management Protocol.
5.2.2. Runtime Component
The runtime component can be realised in a number of ways, several of
which were enumerated in section 3. A
runtime may range from a Java virtual machine with no inherent
hypermedia facilities through to a fully fledged open hypermedia
system. The minimum requirement of a OHRA runtime is that it must
support the Viewer Protocol, if third party viewers are employed. If
access to remote link services are required then the Hypermedia
Protocol must also be supported, but to take full advantage of the
architecture a runtime should support the entire protocol suite.
Provision must also be made for a mechanism with which a user can select and connect to one or more link servers and collaboration servers. While connected to multiple link and collaboration servers an additional mechanism must be in place for specifying which particular server(s) a request is intended for.
We envisage that a user would connect to one or more Collaboration Servers to create and/or select group workspaces in which to operate. These workspaces would allow multiple users to rendezvous and collaborate over multiple link servers and document management systems. Collaboration services could be offered to the user through an additional menu available on the viewer (as with DHM), or in some other fashion consistent with the way in which link services are offered.
It may be the case that support for collaboration in contemporary hypermedia systems is buried in the many layers of the architecture. From figure 4, it may appear that we are advocating the development of a brand new module responsible only for collaboration, but there is no reason why an existing collaborative hypermedia system cannot be adapted to comply with OHRA. All that is required is for the system to expose the appropriate functionality and adhere to the Collaboration Protocol. A partial tailoring would allow runtime components to collaborate only upon its link server, whereas a complete tailoring would allow runtime components to use its collaboration services across a variety of independent link servers.
Preliminary research has been conducted by Wiil and Whitehead [30] which examines the interoperability issues involved when connecting two open hypermedia systems that each offer collaboration support. The results are promising, but demonstrate that this is a complex requirement and further work is necessary in order to generalise these early findings.
As with the Collaboration Server, there is no reason why the
proprietary document management systems that accompany most open
hypermedia systems cannot be adapted to comply with OHRA. Again, it
requires the developers to expose the appropriate functionality and
adhere to the Document Management Protocol.
6. OHRA Interoperability Scenario
In figure 5 we seek to demonstrate the
way in which contemporary open hypermedia systems could be mapped to
OHRA.
6.1. Runtime Layers
6.1.1. Microcosm
This is a full Microcosm hypermedia application in its own right, with
its own proprietary linkbases, documents and viewers. It is fully OHRA
compliant, and as such supports the Viewer, Hypermedia, Collaboration
and Document Management Protocols. It is thus able to use Viewer
Protocol enabled third party viewers in addition to its own. The
diagram shows that it is making use of enabled World Wide Web (WWW)
[3] and Microsoft Word viewers as
well as its proprietary video viewer.
Through the Hypermedia Protocol, Microcosm can access the Multicard
Link Service [22] and the services
available in the DHM session. In addition, Microcosm advertises its
own link querying, navigational and creation services to the other
runtime components, which in this case are the DHM and the Virtual
Machine Runtime (a). Via the Collaboration Server and the
Collaboration Protocol a joint session with the Virtual Machine
Runtime (a) and the DHM session can be held.
Microcosm can also use external data management systems to obtain data and documents not immediately available to it by supporting the Document Management Protocol. In this case, it can access both Documentum and the Internet Gateway. The former is an example of a commercial document storage and retrieval system, and the latter can interface with multiple Internet resources on behalf of a client.
The authors took the stance that rather than enforcing each runtime or link service wishing to participate to conform to a given specification, it would be preferable to accommodate the differences and allow them to co-exist. In this paper we have merely sought to identify the essential components and the associated protocols required for this philosophy to be realised. Without a clear agreement on the second objective listed above this may prove difficult as not all systems will be able to support all concepts and facilities resident in other systems.
Although the Open Hypermedia Systems research community has reached general agreement on the core responsibilities of each of the components of the architecture outlined in the paper, it is clear that further discussion would be necessary for these to be ratified. Without prior agreement upon the clear roles of the architectural components, a unilateral attempt at defining any of the four protocols identified by the authors would be non-productive, and as such these remain undefined. We now look to the wider research community for support and detailed discussion on refinements to the reference architecture and how it can be transformed into a framework for the global integration of open hypermedia systems. If a reference architecture can help guide the way towards the global integration of open hypermedia systems, then the research community can look forward to exploring emerging technologies, such as CORBA and mobile autonomous agents, and their potential for easing the non-trivial task of distributed information management.
[1] Anderson, K. M., A Critique of the Open
Hypermedia Protocol. In Proceedings of the 3rd Workshop on Open
Hypermedia Systems, Technical Report CIT-SR-97-01, pp1-4, April
1997. http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/anderson.html
[2] Aßfalg, R., The Proceedings of the Workshop on Open Hypertext Systems, May 1994.
[5] Carr, L. A., De Roure, D., Hall, W. and Hill,
G. J., The Distributed Link Service: A Tool for Publishers, Authors
and Readers. In Fourth International World Wide Web Conference,
Boston, Massachusetts, USA, December 1995. http://www.w3.org/Conferences/WWW4/Papers/178/
[6] Davis, H. C., 2.5 Open Hypermedia System
Working Group Meeting. Southampton, England, December 1996.
http://www.ecs.soton.ac.uk/~hcd/research/invitation.htm
[7] Davis, H. C., Hall, W., Heath, I., Hill,
G. J. and Wilkins, R. J., Towards an Integrated Information
Environment with Open Hypermedia Systems. In Proceedings of the
ACM Hypertext '92 Conference, Milano, Italy, pp181-190, November
1992. http://www.mmrg.ecs.soton.ac.uk/publications/papers/conference92/echt92abstract.html
[8] Davis H. C., Lewis, A.J. and Rizk, A., OHP:
A Draft Proposal for an Open Hypermedia Protocol, In The
Proceedings of the 2nd Workshop on Open Hypermedia Systems,
Technical Report UCI-ICS 96-10. http://www.daimi.aau.dk/~kock/OHS-HT96/Documents/ohp.html
[10] Golovchinsky, G., What the Query
Told The Link: The Integration of Hypertext and Information
Retrieval. In Proceedings of the ACM Hypertext '97 Conference,
Southampton, UK , pp67-74, March 1997.
[11] Gosling, J. and McGinton, H., The Java Language Environment: A
White Paper, 1995. http://java.sun.com/whitePaper/java-whitepaper-1.html
[14] Grønbæk, K. and Wiil,
U. K., Towards a Reference Architecture for Open Hypermedia. In
Proceedings of the 3rd Workshop on Open Hypermedia Systems,
Technical Report CIT-SR-97-01, pp31-38, April 1997. http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/gronbak.html
[17] Li, Z., Hall, W. and Davis, H. C., Hypermedia
Links and Information Retrieval. In Proceedings of the 14th
British 14th British Computer Society Research Colloquium on
Information Retrieval, Lancaster, UK, 1992. http://www.mmrg.ecs.soton.ac.uk/publications/papers/conference92/lancs.abstract.html
[18] Liu, P, Hampel, K. and Hsu, A., Towards
Automating the Creation of Hypermedia Service Manuals by Compiling
Specifications. In Proceedings of the IEEE International
Conference on Multimedia Computing and Systems, pp203-212, 1994.
http://www.scr.siemens.com/pdf/ieee94_2.pdf
[19] ODMA Association of Information and Image
Management (AIIM). http://www.aiim.org/odma
[21] Reich, S., How OHP's LocSpecs Could Benefit
From ISO/IEC 10744. In Proceedings of the 3rd Workshop on Open
Hypermedia Systems, Technical Report CIT-SR-97-01, pp54-59, April
1997. http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/reich.ps
[23] Rutledge, L. and Hardman, L. Applying
the HyTime Model to the Open Hypermedia Protocol. In Proceedings
of the 3rd Workshop on Open Hypermedia Systems, Technical Report
CIT-SR-97-01, pp63-65, April 1997. http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/rutledge.html
[25] Wiil, U. K. (eds.), Proceedings of the 3rd
Workshop on Open Hypermedia Systems. Technical Report CIT-SR-97-01,
The Danish National Centre for IT Research. http://www.daimi.aau.dk/~kock/OHS-HT97/
[26] Wiil, U. K. 3.5 Open Hypermedia System
Working Group Meeting. Aarhus, Denmark, September 1997. http://www.daimi.aau.dk/~kock/OHS3.5/
[27] Wiil, U. K. and Demeyer, S. (eds.), The
Proceedings of the 2nd Workshop on Open Hypermedia Systems, Technical
Report UCI-ICS 96-10, University of California Irvine, April 1996. http://www.daimi.aau.dk/~kock/OHS-HT96/
[28] Wiil, U. K. and Østerbye, K. (eds.),
The Proceedings of the ECHT '94 Workshop on Open Hypermedia Systems,
Technical Report R-94-2038, Aalborg University, March 1994. http://www.daimi.aau.dk/~kock/OHS-ECHT94/
[30] Wiil, U. K., and Whitehead, E. J.,
Jr. Interoperability and Open Hypermedia Systems. In Proceedings
of the ACM Hypertext '97 Workshop, Southampton, UK, pp. 137-145.
http://www.daimi.aau.dk/~kock/OHS-HT97/Papers/wiil.html