Link Engine/Hypermedia Engine/Link Service

Developers of Intermedia were interested in developing a multiuser hypermedia framework whereby hypertext functionality could be handled at the system level - linking would be available for all participating applications [Haan et al., 1992]. They proposed "The IRIS Hypermedia Services" to provide an integrated desktop environment for hypermedia applications such as InterWord, InterDraw, InterVal, InterVideo, and InterPlay. These services contain the following components: Intermedia Layer, Link Client, and Link Server. These components are independent of both operating system and Graphical User Interface.

The documents themselves are stored as Unix files while the link and anchor data are stored in a DBMS. The Link Client, the Link Server, and the DBMS together form the Link Engine. The Intermedia Layer is responsible for all live data manipulation while the Link Engine is responsible for the storage and retrieval of link data. With such an approach Intermedia documents could be interchanged with KMS using the Dexter Interchange Format (described in Section 3.?).

According to Intermedia researchers, following are the requirements to make hypermedia an integrated part of the computing environment:

1. Integration of hypermedia into the desktop. The Link Engine must be integrated into the computing environment just as the file system is today. A higher level toolkit or an application programmer interface (API) must be provided for application developers to issue calls for hypermedia support.
2. Hypermedia systems must provide multiple contexts or multiple webs in order to fully exploit hypertext linking across all applications.
3. Hypermedia applications must support filtering and incremental query construction.
4. Wide Area Hypermedia - Hypermedia functionality must be extended to support Wide Area Networks in addition to LANs.
5. Building an integrated hypermedia environment is made easier with object-oriented techniques. Also, the most logical DBMS to use for storing link and anchor data would be an Object-Oriented Data Base Management System.

In order to provide an integrated desktop with full hypermedia functionality, Bieber has proposed a system-wide hypermedia engine based on the notion of a generalized hypermedia using bridge laws (See Chapter 2, Section 5 - Dynamic Hypertext) [Bieber, 1993]. This engine would bind independent back-end applications such as Decision Support Systems, Expert Systems, Databases and front-ends (interface-oriented applications such as word processors, graphics packages) through message-passing mechanisms. Bridge laws map the objects defined in the back-end such as models, variables, calculations to objects in the front-end such as nodes, links, and link markers.

Bieber has suggested the following front-end and back-end requirements for system-level approaches to hypermedia integration or client/engine cooperation.

Similar to Intermedia's Link Engine and Bieber's Hypermedia Engine, Sun's Link Service offers an extensible protocol to create and maintain relationships between autonomous front-end applications [Pearl, 1989]. Similar to the approaches seen earlier, editing and storing of data objects is managed by independent applications which also provide some amount of front-end operations on links. The Link Service stores only the representations of the nodes rather than the nodes themselves. Thus, the definition and granularity of nodes are left to the individual applications. Also, the storage of node data is independent of the storage of link data.

The Link Service makes it easier for applications to add hypertext functionality by providing a simple protocol, a shared back-end or link server, a library, and utilities to manage the link database (See Figure 6.2). Applications communicate with the link server through the Link Service protocol. This service allows independent applications to integrate linking mechanisms into their standard functionality and become part of an extensible and open hypertext system. Existing text and graphics editors can be integrated into such a framework without any modifications. Due to the separation of node and link data, the Link Service does not provide version control, node content editors, concurrent multi-user access, or other forms of data integration.

Figure 6.2 Link Service - An Architecture for Open Hypertext [Pearl, 1989].

Some of the issues involved in developing such an open hypertext system include the following: [Pearl, 1989]

• The User Interface for the creation and management of links should be consistent with the editors provided by the individual applications.
• Since the Link Service and the applications are separate processes decisions must be made about sharing/dividing the responsibility for exception handling and user dialogs.
• The Link Service should detect and remove dangling links, either implicitly or explicitly. Implicit removal can happen when a user tries to follow a link from its valid end to its invalid end by suggesting to the user to remove the link. Explicit removal can happen, through a link garbage collection mechanism, by tracking links, validating nodes and removing invalid links.
• While versioning of data objects can be left to the individual applications, the Link Service must still handle the versioning of links. However, the consistency of a versioned hypertext cannot be guaranteed if nodes are versioned separately from links.
• Unstructured documents such as ASCII files cannot be handled elegantly since they are not uniquely indexed nor do they carry semantics.
• The issue of traversing links across networks and locating objects located at remote sites is very important due to performance and cost factors. Also, decisions have to be made about where on the network should the Link Service process be located. Another related issue is the invocation of an application which may not be currently running although the user is following a link to a node managed by that application.