Hypermedia Reference Models

From the third generation of hypermedia systems, different reference models have been proposed with the aim of converting them to open systems and integrating their functionality in any framework or application. These models describe every conceptual element that includes, from the point of view of their authors, a hypermedia model. Three of the most extended ways of understanding and modeling these systems are in the following: HAM, TRELLIS and DEXTER.

Hypertext Abstract Machine – HAM (1987)

HAM is a general purpose, transaction-based, multi-user server for a hypertext storage system. It was a first attempt to express a hypermedia system based on an abstract model. The HAM does not describe the full hypertext system, just the HAM objects and their applicable operations are defined. The HAM is at the top

of the storage system, and it manages and provides the hypermedia information to the applications and user interfaces. This model defines five types of objects:

graphs, contexts, nodes, links and attributes. The HAM also maintains a history

of these objects which allows selective access through filtering mechanisms (by means of expressions based on object attributes and their values). Data access restriction mechanisms based on an Access Control List (ACL) are also included.

A graph is the highest level object and it contains one or more contexts. Contexts are subsets of nodes connected by links to a hyperdocument. Attributes can be attached to contexts, nodes, or links representing application-specific properties of objects or containing information that further describes an object. This model only describes two of these attributes: identifier and version based on the creation or updated time of an object. The Structure of this model can be observed in figure 7.

Figure 7. The HAM reference model

The Trellis reference model (1989)

Richard Furuta and P. David Stotts [Sto 1989][Fur 1990] developed a hypertext reference model (r-model) based on Petri Nets, called the Trellis System. The r-

model is separated into five logical levels, as shown in Figure 8. Within each level

there are one or more representations of part or all of the hypertext. In contrast to the HAM, the defined levels represent levels of abstraction, not components of the system.

The first level presents the components (structure, abstract contents, abstract

buttons and abstract containers) that are associated in the second level to form the

hypertext.

In addition to traditional nodes (abstract contents) and links (abstract buttons), the Trellis system supports two more elements: structure and containers. The first merely describes a skeleton of the graph which provides placeholders that will be associated with the hypertext abstract contents and relationships. The containers are an abstraction of how the information pieces of the hypertext are aggregated and combined for display.

Figure 8. Trellis metamodel

The relationship associations between the elements of the Abstract Component Level are made in the Abstract Hypertext Level. They can be content-structure, button-structure and container-structure associations. The Abstract Hypertext Level describes these associations but it does not describe how these associations will be displayed. The mapping between the abstract hypertext and windows is made in the Concrete Context Level. This indicates how a particular piece of information will be displayed, or the details of operations derived from a link

navigation. Finally, the fourth and fifth levels specify the visible presentation of the document on a particular user interface.

In Trellis, the model, the separation between components and associations and between components and their implementation by Petri nets is achieved by a dynamic adaptation of the appearance and the behavior of the hyperdocument when it is navigated. According to Stotts and Furuta, a hypertext document has two layers: a fixed underlying information structure that is created by the hypermedia author and a flexible structure that is superimposed on the former and is tuned to each user’s requirement.

The Dexter Model (1990)

The Dexter model is an attempt to capture, both formally and informally, the important abstractions found in a wide range of existing and proposed hypertext systems. The goal of the model is to provide a basis for comparing systems as well as for developing interchange and interoperability standards. The model is divided into three layers with glue in between as shown in Figure 9.

Figure 9. Dexter reference model [Hal 1990]

The Dexter model is focused on the storage layer, which models the basic node/link network structure that is the essence of the hypertext. The storage layer describes a sort of "database" that is composed of a hierarchy of data-containing "components" (normally called nodes) which are interconnected by relational

links. The storage layer focuses on the mechanisms by which the components and

links are "glued together" to form hypertext networks. The components are treated in this layer as generic containers of data.

In the within component layer the model is concerned with the contents and structure of the components of the hypertext network. This layer is purposefully not elaborated within the Dexter model. The range of possible content/structure that can be included in a component is completely open. It would have no sense to define a generic model to explicitly cover all possible data types for such components. Instead, the Dexter model treats the within-component structure as being outside of the hypertext model per se. It only treats the glue between the storage layer and the within-component layer, a mechanism for addressing (or referring to) locations or items within the content of an individual component. This mechanism is called anchoring.

The storage and within-component layers treat hypertext as an essentially static data structure. However, hypertext systems provide users with tools to access, view and manage the network structure. This functionality is captured by the

runtime layer of the model. The Dexter model provides only a bare-bones model

of the mechanism for presenting a hypertext to the user for viewing and editing. The range of possible tools is too broad and too diverse to allow a simple, generic model.

As in the case of anchoring, a critical aspect of the Dexter model is the interface between the storage layer and the runtime layer. However, this is accomplished using the notion of presentation specifications. These are mechanisms which present information of a component/network to the user. This information can be encoded into the hypertext network at the storage layer.