Information Systems
Hypermedia
Higher
8176
Autumn 2000
HIGHER STILL
Information
Systems
Hypermedia
Higher
Support Materials
INTRODUCTION
These notes are to be used in conjunction with the existing Hypermedia Teaching and
Learning materials on the Amsterdam and Dexter models.
The purpose of this document is to simplify and explain with the use of examples
some of the more complex concepts involved in the Amsterdam and Dexter models.
It is hoped that these notes will provide the student with a clearer understanding of the
main features of each model.
Information Systems: Hypermedia (H)
1
HYPERMEDIA
The Dexter Model
The Dexter model tries to provide a standard terminology and a description of the
most important features found in hypertext systems. The Dexter Model is not a “real”
hypertext system, it is a theoretical framework against which real systems can be
compared
The Dexter Model divides a hypertext system into three layers, the Storage Layer, the
Within-Component Layer and the Run-Time Layer.
Run-Time Layer
Presentation of the hypertext to the user
Presentation Specifications
Storage Layer
A database containing a network of nodes and links
Anchoring
Within-Component Layer
The content/structure inside the nodes
Fig. 1.1 Layers of the Dexter Model
The Storage Layer
A database containing a network of nodes and links. Nodes are called components
and components can contain text, graphics, animations, etc.
There are basically three types of component, atomic component, composite
component and link component.
Atomic components are the ‘nodes’ of a hypertext network. It consists of three parts:
Content: a piece of data of a single media type e.g. a paragraph of text, an image, a
sound file, a video.
Attributes: information about how the content is recorded e.g. the date the component
is last changed, the ownership of the component.
Presentation specification: information about how the content is to be displayed to the
user e.g. the preferred number of colours to display a gif file, the size of the window
to be displayed and the location of the window.
Information Systems: Hypermedia (H)
2
Composite components are constructed from other components. They may contain
atomic components, link components or other composite components with certain
restrictions e.g. a composite component cannot contain itself.
Link components connect other components together.
The storage layer has two functions, a resolver function and an accessor function.
These functions are jointly responsible for “retrieving” components i.e. mapping
specifications of components into the components themselves.
Every component has a unique identifier (UID). The accessor function is responsible
for accessing a component given its UID.
The resolver function is responsible for resolving a component specification into a
UID which can be passed to the accessor function.
Anchoring
Anchoring is a way of referring to items within an individual component. Links can
be made between specific components as well as between components themselves.
Anchors are made up of an anchor id and an anchor value.
The anchor value is used to locate a part of the content of the component. For
example, if the content of the component is a text file with 20 lines, an anchor id of
#fifthline and an anchor value of 5 may refer to the fifth line of that file. The anchor
id is unique within a specific component
The Within-Component Layer
This deals with the content and internal structure of components. It is responsible for
the content selection of individual components through anchors. Content selection
means the selection of a portion of the content. If the content of a hypertext
component is a file, the ability to locate only the second line of this file is an example
of content selection.
The Run-Time Layer
The Run-Time Layer deals with the presentation of the hypertext to the user and user
interaction e.g. displaying a gif file hypertext component, resolving the link after a
user click on an anchor of a hypertext document and then retrieve and display the
destination document addressed by the link.
Presentation Specifications
The interface between the run-time layer and the storage layer is implemented by
means of presentation specifications, which allow information about how a
component is to be presented to user to be held within the storage layer. For example,
an animation component can be reached via two different links: if it is accessed via
the student’s links, it appears as a running animation, but if it accessed via the
teacher’s link it appears in editing mode.
Information Systems: Hypermedia (H)
3
The main concept of the run-time layer is the instantiation of a component i.e. the
presentation of a component to the user. Operationally an instantiation should be
thought of as a kind of runtime cache for the component. A ‘copy’ of the original is
cached in the instantiation, the user views and/or edits this instantiation and the
altered cache is then ‘written’ back to the storage layer.
At any given moment the user can be viewing or editing any number of component
instantiations. The run-time layer includes an entity called a session which keeps track
of the moment-by-moment relationship between components and instantiations.
Access to a hypertext network is obtained by opening a session e.g. openSession
/LQN ZKLFK ZLOO
OLQN WR FRPSRQHQW
Fig. 1.2 The Three Layers Embedded in an actual Hypertext System
Fig. 1.2 summarises the layers of the Dexter model. It shows a four-component
hypertext network. The storage layer contains four components, including the link.
The contents of the components (text and graphics) are located in the withincomponent layer. In the runtime layer the single graphics component is presented to
the user. The arrow at the bottom of the computer screen marks the link from this
component.
Information Systems: Hypermedia (H)
4
The Amsterdam Model
The Amsterdam Model extends the Dexter model in three ways:
1. It can deal with links within components. They can be used to allow fastforwarding through data, or to allow some elements of a component to persist
while others change as a link is followed e.g. an audio commentary could keep
running while the user flicks through a succession of images.
2. It can deal with complex temporal relationships found in time-based media such
as audio and video e.g. synchronising a soundtrack with a video clip.
3. It can deal with high level presentation attributes e.g. to play all audio elements at
the same volume and tone settings, or display all video elements at the same
screen size.
1. Links within Components
A major problem with many hypermedia models (such as that which underlies the
Web) is that they do not support the notion of context. For example, if we are to
navigate using a link to subsequently present new information, then what elements of
the current presentation should be discarded prior to presenting the new information.
For example, if we select a link should the background music continue to play?
The Amsterdam model manages this idea by specifying the context for each anchor
associated with a link. The context defines the part of the presentation which will be
affected when the link is followed. The resulting overall structure of the Amsterdam
model is a collection of components, links and channels.
Components
Atomic component: (like those in the Dexter Model)
contains information which refers to a particular data block e.g.
• presentation information
• component attributes
• link anchor information
• a contents field
• information about time based aspects of the block
• presentation attributes
Composite component:
contains information about a collection of blocks and several items not found in the
Dexter Model e.g.
• used to build a presentation rather than simply to collect components together for
navigational purposes.
• presentation attributes contain component-specific information, but not duration
values which can be obtained from individual components.
Information Systems: Hypermedia (H)
5
Links
The links in the Amsterdam model are similar to the links in the Dexter model, with
the exception that each link in the Amsterdam also specifies a context which defines
the media elements which are affected by the selection of a link.
Anchors
Anchors and attributes in the Amsterdam model are similar to those in the Dexter
model, except that an anchor can be reduced to a component-id and an anchor-id. A
composite component can be either parallel or choice. Parallel composite components
display all of their elements while choice composite components display either no
elements or one element at a time.
2. Temporal relationships
Temporal relationships between the data items can be separated into two broad
classes.
Collection: those related to identifying the components which are to be presented
together
Synchronisation: those related to the order in which the components are to be
presented.
Most development tools provide little or no support for ensuring that different media
remain suitably synchronised, especially as the context changes and/or links are
followed (for example, if we follow a link from a Web page which contains audio to a
Web page which does not contain audio, should the audio continue to play?). Another
example would be presenting text with an associated audio track, and the text should
be changed at discrete points in the audio presentation. The text and the audio need to
be synchronised in a relatively complex manner. The Amsterdam model ensures that
different media remain suitably synchronised with the use of synchronisation arcs.
There are two types of synchronisation:
Coarse Grained: used to synchronise different components e.g. a video clip and a
sound clip.
Fine Grained: used for synchronisation between components e.g. two or three sound
clips which are played one after the other
Synchronisation arcs
Synchronisation arcs provide a mechanism for representing the relationships between
different media and showing when media should be started, continued or terminated.
The result is a consistency of synchronisation.
The synchronisation arc (or syn arc) allows the author to specify fine grained
synchronisation. It is a method of passing details of synchronisation requirements to
the run-time system. It consists of 3 main parts:
• Source and destination components
• Scheduling interval
• Synchronisation type
Information Systems: Hypermedia (H)
6
3. High-Level Presentation Specification Attributes
Each screen in a hypermedia presentation can use various output media including text,
audio, and video. Although each screen will have its own data elements it is likely
that data elements of the same type will have attributes which are common throughout
the entire presentation e.g. to play all audio elements at the same volume and tone
settings or display all video elements at the same screen size.
Some of these attributes may be determined by the data itself (e.g. a mono soundtrack
cannot be played in stereo), others may be determined by the user (e.g. the volume of
audio tracks), while others may be imposed by the display equipment (e.g. display
resolution)
Since all these attributers can be defined for the whole presentation, rather than
screen-by-screen, there should be some way of defining them globally. These global
attributes would be attached to media types, rather than to individual components.
They are manipulated by means of channels.
Channels
Every time a file is sent to a printer or a disk drive a communication link between the
computer and the output device is established. This is like a channel along which the
information is sent. The channel contains information about the output device itself
and how it is to be accessed.
In the Amsterdam model, channels can be regarded as abstract output devices for
playing the contents of a component. Each channel is used to display one or more
media types and has the characteristics of that type associated with it e.g. font and
style for a text channel or volume for an audio channel.
The choice and time-dependent composition of composite components provide a
technique for organising the information in a media-independent way, whilst still
taking into account logical groupings of different media. For example, providing a
choice-composition between different audio components which provide the same
information in different languages, e.g. English and Dutch.
Channels provide a mechanism for managing media in an application independent
way. The channels become the interface between the information components and the
presentation engine. Any changes to the presentation (such as changes to the screen
layout, display resolutions, etc.) can be implemented by controlling the channels
rather than modifying the individual media components.
Channels can therefore store information which is independent of media type e.g. a
text element may have a black coloured font but the channel may give a yellow
background, or the sound channel may be switched off so that a sound clip does not
play. When a hypermedia document is played, the channels are mapped onto physical
output devices.
Information Systems: Hypermedia (H)
7
Information Systems: Hypermedia (H)
8