Cooperative Hypermedia Management Systems

J. Verbyla and C. Watters*
Department of Computer Science, Flinders University of South Australia,
GPO Box 2100 Adelaide, South Australia, 5001
*Faculty of Computer Science, Dalhousie University,
Nova Scotia, Canada


The benefits of including hypertext functionality in application systems have become widely accepted. Users expect applications to provide browsing and linking capabilities to augment search and command capabilities. Three approaches to providing such environments are feasible. The first two of these involve retrofitting hypertext functionality to third-party applications, and building an 'open' hypertext system that manages the integration of third-party applications with hypertext. The third approach involves building a task-oriented environment that enables a hypertext management system to be constructed, building block style, using third-party applications as building units that cooperate in the delivery of the required functionality. The paper argues that the last of these approaches, cooperative hypermedia management systems, is the most realistic. A model for such systems is described. Issues involved in designing and building such systems are discussed and examples presented.

1 Introduction

The dominance of the World Wide Web browser as the preferred interface for an increasing number of tasks indicates the wide acceptance of the benefits of hypertext functionality for task-oriented applications. The linking and browsing capabilities associated with hypertext navigation are increasingly expected to be part of the interface of any information delivery system.

It is an impossible task, however, for a single information delivery system to meet the needs of all users or to support all hypertext tasks. Some or all of the functionality provided by an application must be tailorable because:

Many of the required specialized functionalities are already available in third-party applications. Furthermore, incorporating existing software is appealing on the grounds of software efficiency, reduction in development time, and user consistency. [DAVK94]

There are three possible approaches to integrating third-party applications and hypertext functionality:

The first of these involves adding hypertext functionalities to existing applications. It is difficult, however, to introduce hypermedia functionality to existing third-party applications. Vendors must either release source code or agree to the addition of the desired functionality, and interface protocols must be accepted. The advantage of this approach is that the hypertext engine and the display engine are tightly coupled, so that a sophisticated level of data-specific linking can be achieved, and advertised link anchors can appear in the data. A disadvantage is that every application must be modified.

Customized access to third-party applications requires that the hypertext system incorporates customized application programming interface (API) access to the applications. It is difficult to rationalize the expense of building customized access to third-party software for individual hypertext systems. For instance, changes in the external software could require changes in the hypertext systems. An example is the proxy program approach. Proxy programs sit between the hypertext link service and the viewer, translating the actions in one system to actions that the other can understand. The disadvantage is that a proxy must be written for each application to be integrated. Proxy programs also have difficulty in reconciling advertised link endpoints with data displayed by the application, so only dynamically-computed, non-advertised links can be provided. In [DAVK94] buttons representing links are placed in the toolbar of the proxy program, allowing a sort of advertised link, although the connection between the clickable button and the actual linked object may not be clear.

An alternative solution would be to build hypermedia management systems (HMSs) that cooperate with third-party software. Instead of putting hypermedia into third-party applications, we aim to make the applications available to hypertext applications via a HMS. Open hypertext systems have taken this approach, and protocols to accomplish the design and implementation of HMSs that include third-party applications are under development. [WIIL97]
The cooperative approach that we favor is the provision of a structure that allows hypertext systems to be built by selecting the functionalities required and 'hooking' applications that provide those components together at runtime. The single greatest advantage of this principle is that the functionality of the HMS is implicitly unbounded. Any third-party application with a scriptable interface can be used by such a HMS to display information or, if it has a query interface, can be used to perform link computations. For example, the prototype hypermedia system described in [ASHV94] was able to make use of both Unix shell scripts and Oracle SQL statements to provide a set of link type (computations) that could be extended while the hypermedia system was in use.

Customized and cooperative approaches differ from the retrofitting approach in that hypertext functionality is overlaid on existing display applications without any alteration to these applications. Customized and cooperative approaches differ from each other in that customization is a planned process for integrating a set of applications, whereas the cooperation focuses on an architecture designed to make use of the computation and display capabilities of arbitrary applications, i.e. it is not necessary to plan ahead. In the most general architectures, such as those using services brokers, [NEWT97] the application to perform link computations and display of data is selected at the last moment. So the customized approach is an early binding one, whereas the cooperative HMS uses late binding of applications for the required service.

There is of course no reason why a hypermedia system should not use a combination of these approaches. The most flexible and extensible of the three is the cooperative approach. Unlike retrofitting, this approach does not involve adjusting the third-party application. And unlike the customization approach, the cooperative approach does not involve the development of specific APIs for such applications. Furthermore, the proposed architecture for cooperative hypermedia management is such that any hypermedia system so built could link to retrofitted third-party applications and to applications with customized APIs without an additional change.

The paper first examines (architecture) models for HMSs and then describes in more detail the cooperative model for HMSs.

2 Architecture/model

Several general (conceptual architecture) models for hypertext management systems (HMSs), such as the Dexter model and extensions, the Amsterdam model, Hypermedia-in-the-Large, and the Open HyperBase model, are described in the literature. [HALS94, HARB94, LEGS94, OREN90] This section will look at such HMS models as being of one of three generic types: unified, collaborative and cooperative (Figures 1, 2, 3).

Figure 1

Figure 1. Unified model of a HMS is typified by the Dexter model. [HALS94] This model has three layers: application, hyperbase and storage (information components and links). Links are defined by the components at which they start and finish. In such a system, storage of links requires the associated storage of the defining nodes (either absolutely or by reference). We call this the unified model as all node data, all link data and all specifications are defined and stored in one common data set

Figure 2. Collaborative model of a HMS is typified by the Open Hypertext Model. This model stores links and node information in a separate database and to define protocols to allow access to specific third-party applications. This is called a collaborative model because specific applications are included in hypertext application system designs as active collaborators for a given task

Figure 3. In the cooperative model, no individual links or data need be stored by the HMS. All links and data are local to their specific native application and such applications may be called as needed. Cooperating applications may be private or third-party. The HMS does not deal with individual links but rather with link (type) specifications. This model also has three layers, but with the fundamental difference that the storage layer now contains only link (type) specifications. The information components remain in their native applications in the application layer. Linking is accomplished by the HMS, which coordinates the execution of the link specification. Link specifications may be expressed in the query or access language specific to a cooperating application or they may be expressed in a mutually-intelligible query language [NEWT97]

The cooperative HMS can also store individual links should this be required. This allows:

Despite this, it needs to be emphasized that the cooperative model HMS can function without any facility for storage of individual links.

An important feature of the cooperative model is that absolutely no reformatting, no marking up, and no migration of information is necessary. There is no need for compliance with a restrictive information format specific to the HMS, such as HTML or XML. [W3C97] The information remains in its native environment, and the specialised tools developed for handling it in that environment are still available. Computational services also remain in their native environment, i.e. one does not need to build computational services into the HMS. In short, the cooperative HMS requires no native data format and no native link computation software. These can be imported. They all are in the 'pure' version of this architecture. it For response time purposes, however, it may be desirable to build some generally-useful computation tools such as text-based computations into the HMS software, although this departs somewhat from the pure architecture.

The important point is that the HMS functions by default without any internal representation and without any in-built computation software. This substantially extends the scope of information that can be made available. Each of the components can still operate as a stand-alone application so there is no disadvantage arising from cooperation with the HMS. This model has the undoubted advantages of being simpler to implement and simpler to upgrade. Furthermore, users can assemble the applications and functionality they want to use for a given task.

We can describe two implementation variations of this architecture model: direct mode and indirect mode.

In direct (or foreground) mode, links are executed as calls to applications and then the called application effectively moves to the foreground and responds to the call. The user may interact directly with the destination application. The destination application uses its own input and display capabilities and its use is obvious to the user. In this mode, links are one-way, from the source to the destination application.

An early version of the interactive mathematics dictionary hypertext application by Watters [WATH94] demonstrates the direct mode. Figure 4 shows a link from the text to Maple, a large stand-alone symbolic algebra system. The link specification from the text to Maple includes information for use by Maple but the display and interaction with the results is handled exclusively by Maple. In this case the user can interact directly with Maple, independently of the dictionary application, if desired. This corresponds to the 'launch-only' level of cooperation described in [DAVK94].

In the direct mode it is still possible to get links from a third-party application to something else. This is done by using the cut buffer to duplicate an object of interest from the third-party application so that the HMS can see it and hence grant further links on it. [DAVK94]

Figure 4. Direct mode link example

Figure 4. Direct mode example (
full-size figure)

Indirect (or background) mode provides a seamless and integrated link service among the cooperating applications. Figure 5 shows the activation of a link from a newer generation of the interactive math dictionary application. [MATH97] Maple is still responsible for generating the results of links, but now the source application gets the results directly from the destination application and the user is not really aware of the cooperation of the third-party software. Notice that the user can no longer interact directly with the Maple software but only indirectly through the dictionary application.

Figure 5. Indirect mode                 link             example

Figure 5. Indirect mode example (
full-size figure)

The feasibility and flexibility of the indirect mode approach to cooperative HMSs has also been shown by the provision of hypermedia functionality simultaneously via a number of different applications. Ashman and Chase [ASHC93] used this approach successfully with databases (Oracle, Progress, Sybase) and Ashman and Verbyla tested it on other information systems. [ASHV93, ASHV94] The HMS uses the same core operations to implement all link types so there is no need to alter software as new link specifications and new third-party applications are incorporated. The functionality of the third-party application, when needed as part of the link specification evaluation, is utilized through its own invocation method, so no changes are necessary to its software either.

3 Design issues for cooperative HMS

This section defines the hypertext components and examines issues of specification for building cooperative HMSs.

3.1 Components

A hypertext application can be described, at its most basic level, as a set of nodes and a set of links, where nodes represent information and links represent relationships. In a cooperative HMS, nodes may represent both nodes and links that are not persistent but that are generated by a process as needed. We define a node N in this environment to be a unit of information, of whatever media, by the tuple
N=<structure, content, access>
where This definition does not differentiate when or where the information was created, i.e. whether it is persistent or virtual, nor what application it belongs to. This means that we can have nodes that are databases (inventories, bank accounts, etc.), and nodes that are the results of processes, such as simulations, computations, searches, or some other internal or external process.

Links are (instances of) relationships and are defined by the tuple

L=<type, source, destination, [content]>
where A link set is a set of links grouped together (usually) because they are all generated by the same process, i.e. by the same link type specification. For example, a link set could be all links created by the same query.

A link is generated by a process. The activation of a link, that is the traversal from a source to a destination, is accomplished by a navigation process. The relationship (or link type) determines what processes are invoked to activate a particular link. The process may vary in complexity from simple 'goto' links, that require the activation of cooperating links, to links that activate processes in other applications, and links that bring data to other applications for processing. The categorization of dynamic links into levels of complexity is described elsewhere. [WATT97] Regardless of complexity, in essence the link generation and activation processes must enable the following:

In any case, the necessary computation can be performed by the appropriate cooperating application.

The interactive dictionary shown in Figure 5 is an example of the activation of a dynamic link from a static data node, in this case the entry to a third-party application, Maple. In this example, although Maple generates the numeric results, the display is controlled by the dictionary application.

As discussed in the next sub-section, the functional model of the link [ASHV93] provides a generic structure for specifying a link type and has provided the basis for an architecture to implement a cooperative HMS. It should be noted that no assumption is made about when (nor where) the process (or any of its sub-processes) is executed. The link may be pre-computed and persistent thereafter, computed and cached for some lifetime before re-computation, or the link may be computed 'just-in-time'. These later links tend to be dynamic links which, like virtual nodes, are generated as needed and, furthermore, the target destination of such links need not exist as a persistent node nor does the target application have to exist at specification time. For instance, in a prototype HMS based on the functional model of the link [ASHV94], Unix man (manual) pages had links dynamically generated to related pages regardless of whether those other pages were available. Furthermore, the source pages remained in native nroff format with no additional mark-up being required.

3.2 Specification issues

We have been considering the problem of integrating hypermedia functionality with existing third-party applications for some time, including database management systems, geographic information systems, and mathematically based information systems. [ASHV93, ASHV94, WATH94, WATT96] We have found a way to superimpose linking on to a number of third-party applications, with no limit to the number of applications which can be included, no constraints on the location of the applications and no constraints on the types of information they handle. This is done by using the usual access/query interface of each third-party application to generate links. Others have developed alternate approaches, such as Microcosm which is essentially a collection of communication protocols that enable the integration of all types of information processing tools, including a hypermedia link service. [HALL96]

A link type specification consists of two computation rules which reflect the two core requirements of the link activation process described earlier, namely source certification or determination, and destination computation. These rules might, for example, be implemented as scripts or queries. Each rule can be in any script or query language, so one link specification might use two languages, one each for the source set and destination set computations. There is no requirement that different link specifications must use the same language, such as in [TNHN91], and this feature is one that radically separates our approach from that of any other. In particular, it enables linking between any combination of third-party applications.

A second fundamentally important aspect that permits inter-application linking is the need to specify not only the destination computation of a linking operation, but also the source determination. The destination computation makes it possible to link into a third-party application; the source determination makes it possible to link out of a third-party application.

An important feature that distinguishes this approach is the form in which all link types are represented. Our link types are not necessarily defined on a static set of source objects; instead the validity of each candidate source object is determined at the time it is required. The static source set approach implicitly relies on the predetermined validity of the objects in the source set. This disposes the set of links to integrity constraint errors such as the World Wide Web's 'Error 404', however, resulting from the deletion and relocation of data. [ASHM98] It also means that the 'completeness' of a set of links [THIS97] is not guaranteed as new data may have been added for which links should exist but do not.

3.3 Link and node management

Dividing the link generation and activation into the two phases of source determination and destination computation makes it possible to involve four (or more) third-party applications in any one link specification, namely: The cooperative HMS [ASHV94] may have no link or node computation capability of its own. Instead, it delegates all computation duties to third-party applications, reserving for itself the duty of organizing and notifying link computation results. The third-party applications participate in a link computation via their usual interface language. As the languages are interpretative, new link specifications and modifications of existing link specifications can be done 'on the fly' without the need for preprocessing.

3.4 Standalone application versus cooperative HMSs

In the cooperative HMS approach, any application which has a query or access language can be used in a hypermedia application. There are overheads, however, such as those of communication associated with the cooperative HMS approach. Consequently, in some cases it may be preferable to use a single system with built-in hypermedia functions tailored for the given task. Designers of future information delivery tools might ask the following questions:

4 World Wide Web as a cooperative HMS

The example of the World Wide Web is considered in this section because it currently functions as a partially cooperative HMS. Furthermore, the Web has the potential in the future to develop into a fully cooperative HMS.

The Web's fundamental HTML-based link model requires that the source of a link be statically specified by embedding it into the HTML document in-situ an <a>-tag pair which contains a href attribute, the destination address (URL). [W3C97] While not completely requiring that all node data, all link data and all specifications are of one common data set, the Web-based HTML hypermedia model is effectively a unified model (see section 2). Its hypermedia functionality breaks down if the destination node (data) is not an HTML document. Non-HTML destination documents typically require that the browser spawn an external viewer. Since such viewers are not fitted with hypermedia functionality, they are dead-ends, i.e. there are no links out of them.

Developments on the Web to support dynamic documents are freeing it from the limitations of the unified model and consequently the Web is becoming a partially cooperative HMS. The qualifier 'partially' applies because the cooperation is still restricted to destination computation. XML and XLS, [W3C98] however, may provide the infrastructure required for applications to cooperate at a functional level on the Web. These may provide the means of incorporating link type specification and dynamic linking into Web functionality. An alternative approach to enhancing the hypertext functionality of the Web (along with other functionalities) has been adopted by the Hyper-G project. [MAUR95] The approach of Hyper-G (and HyperWave, its commercial version) is to incorporate a data model that is much richer than that provided by the Web.

Server-side support for dynamic documents via CGI scripts [NCSA] and, more recently, Java servlets, [SUNb] enable the Web to access third-party applications such as database management systems to link to dynamically created documents. Such destination nodes are returned to the client as HTML marked-up documents, so the user (client) does not need to be aware of the cooperation of the applications. This is a successful example of the indirect mode of the cooperative HMS model (see section 2). It is possible that with the development of a HTTP protocol that supports sessions and transactions, [W3C97] access to server-side execution will further evolve to enable direct (mode) interaction with cooperating applications.

Client-side support is less well established than server-side support for dynamic documents; only recently has it begun to receive significant attention. Such support can take one of three approaches. The first two approaches involve embedded active objects. Active embedded objects, typically Javascript code, [NETS] and referenced embedded objects, typically Java applets, [SUNa] respond to requests for access by dynamically constructing the document required. The third form of client-side support uses dynamic object linking, [W3C97] like that provided by Microsoft's OLE and Apple's OpenDoc. When activated this form of destination computation can provide a link to another application, which the user can interact with directly. This is the direct mode of the cooperative HMSs.

The above discussion indicates that with respect to destination computation, at least, the Web functions partially as a cooperative HMS. A much more difficult issue is that of source determination. All of the above-mentioned destination computations still have as their source embedded tags in an HTML document. A limited amount of research has been done on alternative (or additional) forms of source determination for the Web. Most of this research has focussed on annotation links [ROSM95] since the temporary nature and potential one-to-many nature of such links makes them poor candidates for embedded, marked-up sources.

There is significant scope for further developments in the utilization of third-party applications for Web-based link source determination. For instance, a browser could be extended so that a user can be provided with access to a query link type which when activated would feed the keywords determined from the current document into a search engine request. This computation of 'similar document' destinations is already a feature of a number of search engines. The link would then result in a dynamic destination document containing links to 'similar' documents. (Such pointer-list documents are a necessary feature of the Web because of its inherent one-to-one unidirectional linking.) Similar possibilities exist for browser plug-ins providing dictionary, thesaurus and manual look-up links that are available from a dynamically determined source such as through user selection (highlighting) of text.

5 Summary

Consideration of actual and potential types of Web-based cooperation with third-party applications highlights the significant practical benefits that arise from dynamic linking mechanisms. Such mechanisms enable computation and display functionalities already available in third-party applications to be exploited in a hypermedia system. These mechanisms are encapsulated in the general model for cooperative HMSs which was detailed and discussed in this paper. The model provides a basis for constructing systems that utilize the benefits of such cooperation to deliver the required, possibly specialised, functionality. Furthermore, in the case of existing systems such as the Web the model can be used as a guide, with respect to cooperation, to future developments that could extend functionality. The model is comprehensive in its approach to meeting the increasing demand for task-oriented applications to have interfaces incorporating hypermedia functionality.


[ASHM98] Ashman, H.L. (1998) "Theory and Practice of Large-Scale Hypermedia Management Systems". Doctoral thesis, Royal Melbourne Institute of Technology, Australia

[ASHC93] Ashman, H.L. and Chase, G.R. (1993) "Link Management in a Geographic Hypermedia Information System". Proceedings of the 4th Australian Conference on Information Systems, University of Queensland, pp. 327-334

[ASHV93] Ashman, H.L. and Verbyla, J.L.M. (1993) "Externalizing Hypermedia Structures with the Functional Model of the Link". Proceedings of Online Information '93 (Learned Information), pp. 291-301 (abstract only)

[ASHV94] Ashman, H.L., Verbyla, J.L.M. and Cawley, T. (1994) "Hypermedia Management in Large-Scale Information Systems Using the Functional Model of the Link". Proceedings of the Fifth Australasian Database Conference, New Zealand, January, pp. 247-257

[DAVK94] Davis, H.C., Knight, S. and Hall, W. (1994) "Light Hypermedia Link Services: A Study of Third-Party Application Integration". Proceedings of the European Conference on Hypermedia Technologies (ACM), pp. 41-50

[HALS94] Halasz, F. and Schwartz, M. (1994) "The Dexter Hypertext Reference Model". Communications of the ACM, Vol. 37, No. 2, February, 30-39

[HALL96] Hall, W., Davis, H. and Hutchings, G. (1996) Rethinking Hypermedia: The Microcosm Approach (Kluwer Academic Publishers: Boston)

[HARB94] Hardman, L., Bulterman, D. and vanRossum, G. (1994) "The Amsterdam Hypermedia Model: Adding Time and Context to the Dexter Model". Communications of the ACM, Vol. 37, No. 2, February, 50-61

[LEGS94] Leggett, J. J. and Schnase, J.L. (1994) "Viewing Dexter with Open Eyes". Communications of the ACM, Vol. 37, No. 2, February, 77-86

[MATH97] MathResource, Interactive Math Dictionary

[MAUR95] Maurer, H. (1995) Hyperwave: The Next Generation Web Solution (Prentice-Hall)

[NCSA98] NCSA (1998) CGI Documentation (including CGI 1.1 Specification)

[NETS98] Netscape (1998) Javascript Tutorials and Developer's Guides

[NEWT97] Newton, P. (1997) "HIPPO: Incorporating Hypertext using Fuzzy Components". Third Workshop on Hypertext Functionality (HTF3), Southampton, UK

[OREN90] Oren. T. (1990) "Toward Open Hypertext: Requirements for Distributed Hypermedia Standards". Proceedings of the Hypertext Standardization Workshop, NIST, USA, January, pp. 189-196

[ROSM95] Roscheisen,M., Mogensen, C. and Winograd, T. (1995) "Beyond browsing: Shared Comments, SOAPs, Trails and on-line Communities". Proceedings of WWW5

[SUN98a] Sun Microsystems (1998) Java Developer's Kit

[SUN98b] Sun Microsystems (1998) Java Servlets API

[TNHN91] Tanaka, K., Nishikawa,N., Hirayima, S. and Nanba, K. (1991) "Query Pairs as Hypertext Links". In Proceedings of the 7th International Conference on Data Engineering (IEEE Computer Society Press), pp. 456-463

[THIS97] Thistlewaite, P. (1997) "Automatic Construction and Managment of Large Open Webs". Information Processing and Management, Vol. 33, No. 4, 161-173

[WATT96] Watters, C. (1996) "Dynamic Links". Proceedings of the Second International Workshop on Incorporating Hypertext Functionality Into Software Systems II (HTF II), Washington, D. C., USA, March

[WATT97] Watters, C. (1997) "Link Levels in an Open Hypertext View". Third Workshop on Hypertext Functionality (HTF3), Southampton, April

[WATH94] Watters, C. and Ho, J. (1994) "MathProbe: Active Mathematical Dictionary". RIAO94 (Recherche d'Information Assistee par Ordinateur) Conference Proceedings, New York, October, pp. 552-569

[WIIL97] Wiil, U. K. (Ed.) (1997) Proceedings of the third Workshop on Open Hypermedia Systems, Southampton, April, appears in Technical Report of the Danish National Centre for IT Research

[W3C98] World Wide Web Consortium (1998) XML standard

[W3C97] World Wide Web Consortium (1997) HTTP Standards and Next Generation Drafts