Although including temporal multimedia within the structure of a hypertext system seems like a simple idea, most hypertext models cannot successfully incorporate complex collections of dynamic information. The Amsterdam Hypermedia Model (AHM) [85] attempts to present a framework that can be used to describe the basic features and operations common to hypermedia systems. It extends the Dexter hypertext model to include notions of time, high-level presentation attributes and link context, and while the model is based on a large number of detailed requirements [84] this section will focus on those related to the needs of temporal media.
The AHM extends the atomic components of Dexter by including temporal duration in the presentation specifications. This allows composite
components to be used to build a presentation structure rather than simply collect together related components, and thus the composite becomes the main mechanism for supporting temporal relationships in the AHM [85].
A composite can either display all its child components at once (a parallel composite) or only show at most one at a time (a choice composite), and has no need for a duration value itself since this can be calculated from the durations of its child components. Each child within a composite can be given an explicit start time, and this allows coarse-grained synchronisation between them. Finer, more powerful synchronisation is achieved using synchronisation arcs, or sync arcs, which are constraints the run-time system should enforce upon the
behaviour of two or more components.
While not a navigational link, the sync arc has endpoints representing the source and destination components. The timing relation is included as a target time with allowable margins either side and a synchronisation type. This type expresses whether the arc is relative to the start, end, or an offset into the component, and defines the synchronisation as hard (the constraint must be met and the application stop) or advisory (the application should continue
regardless). With these features a sync arc can express all the temporal relationships needed to ensure a synchronised presentation of components. In the AHM components that are to be shown together can be clearly separated into composites, and within the composites relative ordering and detailed timing constraints can be expressed [85]. Highly complex temporal presentations can be represented using the AHM; these ideas can be further expanded by introducing the concept of presentation time (see figure 2.6).
Time
Time
link Key:
atomic component
temporal composite component synchronisation arc
link
atomic anchor
Figure 2.6: Amsterdam hypermedia model overview
(from [84])
Presentation time [86] is the timing of the individual parts of a presentation and the temporal relations among them, and refers to timing from the
perspective of the reader experiencing the document as it is played (where a document is the storage representation of the presentation, whether a single file, multiple files or database). Presentation time can be further split into four sorts of time, each of these having its own time axis which can be used for
synchronising the control of other events, such that an event of one time type can trigger an event in another time type.
Media element time is the temporal length of the segment of media played in the presentation, and is an inherent property of that media element. Text, still images and live broadcasts have an indefinite duration.
Document time is the time assigned by an author for an element within the presentation which is then stored in the document.
For atomic components the document time will loop/stretch or clip/shrink the element in relation to its media element time, corresponding to the event projections of HyTime.
For composite components the document time is dependent on the synchronisations specified between the child components. If the
synchronisation is defined as soft, then if content is delayed at runtime the rest of the presentation should continue; if hard, the rest of the
presentation should pause until the content returns. Sync arcs specify the relative start times of child components, but if one component has an indefinite duration then a second sync arc can be used to instantiate the duration (scaling the indefinite duration to fit).
Rendered Time describes the time which is resolved after a choice has been made to select one of multiple alternatives for a particular media element. These choices may be offered to adapt the presentation to user preference or system hardware. Up to rendered time each combination of alternatives would produce a different presentation time.
Runtime is the time it takes, in real time, to play the presentation and includes any interaction the user may make with the presentation. These
interactions may include pausing, playing, fast forwarding or reversing and traversing links within the presentation and to other presentations. The situation is complicated further when the presentation is made up of more than one temporal composite, where one rendered time line continues while the user navigates through others.
It is argued [86] that these aspects should be incorporated into a document model of hypermedia in which time becomes a first class object, just as links did
in hypertext.