Adding multimedia collections to the Dexter Model

Adding Multimedia Collections to the Dexter Model

Franca Garzotto, Luca Mainetti, Paolo Paolini

Politecnico di Milano - Department of Electronics and Information

Piazza Leonardo & Vinci 32-20129 Milano - Italy

Phone: +39-2-2399.3623 Fax: +39-2-2399.341 1

e-mail: {garzotto, mainetti, paolini]@elet.polimi.it

ABSTRACT]

The Dexter Model defines the notion of atomic

components and composite components, but it does not

prescribe, nor it suggests, any particular structure for

composite components. This paper proposes a specific type

of composite component, called “collection”.

A collection is a container holding several members.

Collections can contain other collections (nested

collections). Collections can be regarded as sets, but they

can also have an inner structure. Collections can be created

in several ways: manually, through queries, by operations

on other collections, by exploiting links, etc.

Collections introduce a navigational pattern, based on their

structure, that is different from the standard node&linknavigation.

If active media are considered, collections allow the design

and implementation of complex synchronisation strategies,

difficult to obtain otherwise.

The paper describes the motivations for using collections,

their structure, their navigational capabilities and a

number of possible authoring mechanisms. It also

examines the interplay between standard navigation and

collection navigation, possible synchronization strategies

for collections, as well as the requirements for the

definition of a mntime support (which could be used to

extend the runtime layer of the Dexter Model).

KEYWORDS: Dexter Model, Composite, Hypermcxlia

Design, Collection, Guided Tour, Active Media

1Permission to copy without fee all or part of this material is

granted provided that the copies are not made or distributed for

d-t commercial advautage, the ACM copyright notice and the

title of the publication and its date appear, and notice is given

that copyright is by permission of the Association for Computing

Machinery. To copy otherwise, or to republish, requires a fee

arKVW specific permission.43 1994 ACM 0-89791 -640-9/94/0009/$3.50

1 INTRODUCTION AND BACKGROUND

The Dexter Model [19] defines a set of primitives for

describing hypermedia applications. The model is based

upon three layers. The storage layer describes the data

structure of nodes and links. The runtime layer describes

the mechanisms to support the interaction of the user with

the application. The within-component layer describes the

internal structure of elementary values (e.g. a text, an

image, a video, etc.).

This paper proposes the adoption of the notion of

collection, as an extension to the storage layer, and the

related notions of collection-navigation and collection-

synchronization, as extensions to the runtime layer. A

collection can be considered a specialization of the generic

notion of composite component introduced by the Dexter

Model for the storage layer.

Concepts similar to what we call collection have been

proposed several times, by several authors. Our

contribution consists in pulling together severalindependent proposals, sometimes extending and

generalizing them. In addition, we discuss a number of

authoring mechanisms for collections, we propose a more

relevant role of collections within the navigation paradigm,

and an interpretation of the behaviour of collections that

takes into consideration also active media.

In Memex, Vannevar Bush proposed the idea of trail [3], a

group of elements gathered from a mass of information and

bound together to forma new “book2.

TEXTNET implemented trails as paths [24], used to

generate multiple different linear documents from a single

hypertext network, and [15] exploited the notion of trail as

“guided tours”, to support navigation of naive users across

educational material.

2 “...when numerous items have been thus joined together to form

a trail, they can be reviewed in turn, rapidly or slowly...” [3]

ECHT ’94 Proceedings 70 September 1994

The notion of guided tour is investigated in fiMher detail

in Trigg’s paper [25]. Trigg clearly highlights the role of

guided tours in hypertext applications, as a way “to ensure

the intelligibility of hypertext documents especially on

occasions when the authors are not present”. A guided tour

holds together a number of Tabletops, connecting them

together to form an arbitrary graph structure. A Tabletop is

a device of Notecards for displaying several values in a

single co-ordinated screen layout. The user interaction with

a guided tour exploits the topological arrangement of

tabletops in it, through commands as Start, Next, Previous,

Jump. The user can also leave a guided tour, following the

links outgoing from the cards in a Tabletop.

Marshall [20] further explores the notion of guided tours,

analyzing presentation conventions and issues related to

the design of expressive and intelligible guided tours.

Zellweger [29], within the context of her proposal of

Scripted Documents, introduces paths as a way to augment

the traditional navigation paradigm, and convincingly

argues that path constructs should become frost-class

citizens in hypermedia systems. Two relevant issues are

raised: the structuring of paths (linear, branching,

conditional) and their granularity. Zellweger also

introduces the elements for a runtime model, specifying

that a path can h traversed in three ways automatic

control, one step at the time (controlled by the user through

commands such as next, previous, etc.) and by direct

choice of the item of interest. A major contribution of this

work is the notion of active path entries, i.e., entries that

have their own behaviour, and the notion of Scripted

Document, which is “a procedural programmable path with

active entries, called scripf”, Multimedia entries are

presented as a special case of active entries.

Parunak’s work [26] points out the relevance of set oriented

hypertext. Parunak’s main objective is to support

taxonomic reasoning, i.e., the task (common to many

applications domains) of dealing with the comparison and

classification of pieces of information. A model based on

set theory and set operations, Parunak observes, is more

appropriate for this task than a graph based model. He

presents a system that supports creation and manipulation

of sets , and navigation across them. The basic browsing

operation is “not moving from node to node as a graph-

based hypermedia, but moving from an artefact to one of

the sets in which he is member, and then to other members

of that set”. Parunak observes that it is desirable to provide

both set based and graph based navigation in a hypermedia

system, but he does not discuss the issues raised by such a

hybrid approach any further.

Collection is a term also used in the context of Object

Oriented Data Bases. In [28], a collection is considered “a

way of aggregating related objects. Query (i.e., search) is

performed over some type of collection...”.

In our work to define logical primitives useful for the

design and implementation of hypermedia applications [4,

6,7,8,9, 10], we have defined several types of composite

among them, the most important are node, en[ity, web and

collection.

Informally speaking, a node is the basic unit of navigation

and it corresponds to what is typically intended as such in

the hypertext field, or to a card, in card-oriented systems.

An entity is a composite, grouping all the nodes

corresponding to the same “external world object” (e.g., all

the nodes corresponding to the monument “Duomo”). A

web is a composite, that generalizes the notion of link. A

collection is a composite grouping together members

(either nodes or webs or entities or other collections).

The notion of collection is the central focus of this paper.

In order to keep our discussion as general as possible, we

will not use the notions of entities and of webs (which are

not crucial to explain collections). We will use the notions

of node, providing a short explanation for it, and of link,relying upon an intuitive understanding of it.

In section 2 we present an informal introduction to nodes

and collections; in section 3 we describe several

mechanisms for creating collections; in section 4 we

examine the navigation capabilities determined by

collections; in section 5 we examine the usage of active

media with collections; in section 6 we draw the

conclusions, comparing more precisely our notion of

collection with previous works, and illustrating the future

directions of our research.

2 INFORMAL PRESENTATION OF NODES AND

COLLECTIONS

We need to introduce the preliminary notion of slot. A slot

is a value, i.e. an atomic piece of information, which, in a

context of a given application, cannot be further

decomposed. A slot is strictly correspondent to what the

Dexter Model calls “atomic component”3, that is to say a

component that is considered elementary both by the user

and by the application. A slot may have a complex inner a

stmctute, but (as it is the case for atomic components of

the Dexter model) there is no possibility of navigation

across this inner structure.

A node is a composite, which groups together a number of

slots, and represents a logical unit of information (and

9We do realize that the authors of the Dexter Model have a

dtiferent opinion, since they declare that “atomic components are

what is typically thought as nodes in a hypertext system...” [19].

This opinion however, seems to be in contradiction with what it

is said elsewhere in the same paper. In fact a node, intended as a

navigational unit, holds, in general, several atomic components

ECHT ’94 Proceedings

together.

71 September 1994

navigation) for the user. Examples of nodes could be the

monument “Duomo”, the shop “Armani”, the hotel “Hotel

de Milan”. The slots belonging to the same node are

closely related each other and they concur the description

of an object 4.

A collection is a composite, including several nodes. There

are several different reasons to put a node in a collection.

One reason could be the need of partitioning the set of

nodes in semantically consistent groups (taxonomy) [23].

Collectionss such as “Artists lives”, “Paintings”,

“Historical periods”, are an example of this taxonomic use

of the notion of collections.

Another reason to put a node in a collection could be the

need of organizing a specific presentation. Collections such

as “Erotic Art”, or “Figura Serpentina”, are an example of

this type of collections. Presentation collections are more

arbitrary than taxonomic collections, since they correspond

to more subjective points of view. The degree of

arbitrariness can very from mild (e.g. “Erotic Art”) to

extreme. Consider, for example, a collection such as “The

making of Painting”, where some paintings are used in

order to describe the manufacturing techniques. The choice

of which paintings should be introduced in such a

collection is very arbitrary, and based upon the subjective

point of view of the designer of the collection itself.

Collections can be homogeneous (i.e., containing nodes of

the same type), or heterogeneous, (i.e., containing nodes

of different types). Taxonomic collections, in general are

homogeneous, bit this is not a mandatory requirement.

Arbitnuy presentation collections are likely to be

heterogeneous.

Taxonomic collections are usually quite stable, in the sense

that, once they are defined, they are seldom modified.

Presentation collections, instead, can continuously be

modified, in order to make the content of the application

more accessible, in order to accommodate new points of

view, in order to present different culturrd perspectives, etc.

This is the reason why collections are so important for

hypermedia application~ they allow a continuous

modification and improvement of the way the content of an

application is organizxxl and presented, without having to

modify the core of the information (represented by the

nodes). This requirement was already stated by Hrdasz

[14], when he suggested avoidance of the “problem of

premature organization”, by using virtual structures.

Collections, in our interpretation, could be intended as an

4 As we have said in the previous smtion, we usually associate

external objects, such as “Duomo” to entities [4, 7] rather than to

nodes. An entity is a composite made of several nodes, cmnected

by structural links. In this paper we wish to avoid the additional

level of complexity introduced by entities, and therefore we

assume that all entities (e.g., ‘DuOmo”) consist of a single node.

5The examples here indicated are “loosely” related to the

application “Art-Gallery” of Microsoft.

example of virtual structures, in the sense introduced by

Halasz.

Collections may also include other collections (nested

collections). The collection “Monuments in Milan”, for

example, may contain the collections “Romanesque

Milan”, “Gothic Milan”, “Renaissance Milan”. These latter

collections, in turn, may include other collections, in order

to further organize the material. Mixed situations, where a

collection may include both nodes and other collections,

are seldom found, but they can’t be excluded.

We use the generic term member, to refer to an object

included in a collection, both if it is a single node, or

another collection.

A collection may also have information directly asscxiated

to it (i.e. not to the members). We consider this

information as belonging to a special node, that we call

collection node. Some of the slots of the collection node,

contain new information: e.g. the name of the collection,

an introductory text, an introductory graphics, etc. Other

slots of the collection node, instead, can be derived6 from

the members of the collection.

For the collection “Figura Serpentina”, for example, in the

collection node, beside the introductory text, there are the

miniature pictures and names of the paintings, members of

the collections; these pictures and these names are derivedfrom the corresponding slots of the members.

As far as inner structure is concerned, a collection can be

described in two ways:

as a set of members

as a structure holding together the members in a

topological arrangement.

Typical structures used in applications are sequences

(most common), trees (quite common), lattices and

generic graphs (less common), etc.

Some operations are easier to describe and implement if

collections are considered sets (e.g. union of two

collections, difference of two collections, etc.). Other

operations (the navigation operations) are more easily

described if the inner structure of the collections is

considered (e.g. Next, Previous, First, Last, etc. for a

collection structured as a sequence).

3 AUTHORING OF COLLECTIONS

Three operations are needed, in order to create a collection:

1. definition of the set of members

2. definition of the inner structure of the collection, and

placement of the members into it

3. definition of the node associated to the collection

c Informally speaking, a slot “s” is derived horn slots s1, 52.. sn if

it can be defiied a function f such thats = f(s 1, S2.. .sn).


3.1 Definition of the members of a collection

We have identified six basic methods to define the

members of a collection: built-in, intentional, pick-up,

set-oriented, link-oriented and session-based. These

basic methods can be combined together.

The built-in creation is the only method that does not

require another collection as a starting point. In this

respect it cart be considered the basis for any authoring

activity.

All the authoring systems provide built-in mechanisms to

create some collections. The systems that have typed

nodes, for example, have a built-in collection associated

with each node type. Untyped systems usually partition the

global set of nodes into smaller collections, according to

some user directives. In HYPERCARD, for example,

stacks are built-in collections. Creating a card in a stack

automatically places it in that collection. Books in

TOOLBOOK play art analogous role.

The intentional creation of a collection is based upon a

selection mechanism. It is necessary to specify a collection

(or a set of collections), to which the selection must be

applied, and a selection criterion. A selection engine must

be used, in order to interpret the selection request and to

compute the result. The result is the collection of all the

objects satisfying the selection criterion..

Different mechanisms of selection can be provided e.g.

Data Base queries, keywords search, content search7, etc.

Intentional creation of collections is a very powerful tool.

It is not applicable in all situation however. First of all the

proper attributes (for Data Base queries) and keywords

must be prepared in advance and intrusively embedded in

the description of the information objects, in order to allow

queries. In addition, this technique requires a (relatively)

skilled user, able to use a query language and to precisely

select the objects of hisfier interest.

The pick-up method is very popular among hypertext

systems. The author manually selects the members of

his/her interes~ while navigating around in the

application.

The pick-up method is typical for building arbitrary

collections, when the intensional selection can’t be applied.

The set-oriented method exploits the unstructured nature

of collections, applying set operations, such as Union,

Intersection, Difference, etc.

Let assume, for example, that we start with two collections

corresponding to the “Monuments in Area 1“ and

“Monuments in Area 2“; and also we have the collection

“Churches in Milan”. Through the union of the f~st two

collections, and the intersection of the result with the third

collection, we can obtain a collection having as members

all the churches in Areas 1 and 2 of Milan.

7 Either “tradhional” text-retrieval, or modem image content

search.

The link-oriented method for creating a collection is very

powerful, and it is very much in-line with the nature of

hypertext,

The starting point is a collection and a set of links

(possibly typed). Applying the links to all the members of

the collection, we obtain another collection, consisting of

the set of nodes connected to the members of the original

collection. L&us assume, for example, that we have a link

“author” associating each painting to the corresponding

painter. Let us assume that “Rcmm-1” is a collection of

paintings; applying the link “author” to it, we can obtain

the collection of all the painters who have an exhibit in

“Room-l”.

We have been recently experimented quite extensively the

link-oriented method of building collections [21]. The

method seems to be quite interesting, since it couples

expressive power with relative easiness of usage.

Most systems support session-based methods to build

collections. The “history”, i.e. the set of nodes that a user

has visited during a session, is a typical session-based

collection.

Some systems simply insert all the visited nodes in the

history, other systems allow specialized histories (e.g.

partitioning the visited nodes by type), or they may require

an explicit marking of the nodes that should be inserted in

the history.

Some systems treat history as an ordinary collection; other

systems allow special operations only on the history.

In practice, most environments do not provide all the six

methods for creating collections, but a few of them, with a

number of restrictions. In most applications collections are

prcdefined, and can’t be modified by the reader. The most

common tools provided are queries (intentional definition)

or history; the collections created by the reader can be

operated upon only in a special manner, and are kept

distinct from the ordinary collections.

We are experimenting, instead a different environment

where a second-k?vei author, can use a variety of

mechanisms for creating new collections, in order to

provide specialised access paths for the final readers.

3.2 Definition of the inner structure of a collection

The method to define the inner structure of a collection

clearly depends on its topology.

If the collection is organized as a sequence, it is required a

total ordering among its members. The ordering can be

achieved either manually, or through an intensional

specification, i.e., through the explicit definition of the

ordering criterion (in our applications, in general, we do

allow both manual and intensional orderings).

For lrees and lattices, a partial order among the membersmust be specified. Most of the systems allowing trees,

lattices or other kinds of generic graphs (e.g. Notccards),


make use of graphic interfaces in order to allow the author

to place the members in the proper relationships.

3.3 Definition of the node associated to the collection

The node asswiated to a collection plays three distinct

role~

1. it helps the reader to understand the content of the

collection.

2 It provides additionrd information for the collection.

3. It provides mechanisms to access the members of the

collections.

In order to help the reader to understand the content of the

collection, the collection node may present new

information (e.g., a title, an introductory text, etc.) or

information taken from the members (e.g., the names of

the members, part of their content, etc.). We call slots

where the new information is stored, own slots and

derived slots, those where the information “borrowed”

from the members is kept-

As far as the second role for collection nodes is concerned,

it may happen that a collection requires additional

information, beside the one provided in the introduction.

Let us assume, for example, that we let the reader use

“Gothic Milan” as a guided tour (discussed in the next

section), so that he can visualize the nodes one after the

other. We may want to add information about how to get

from a monument to the next monument. This information

does not belong to the members of the collection, since it

depends on the way (order) we arrange the monuments.

We can consider these traveling tips as slots of the

collection node, which are to be presented interleaved with

the members of the collection.

The use of the collection node as a device to access the

members of the collection is discussed at some extent in

the next section.

4 NAVIGATION AND COLLECTIONS

We have identified two basic ways to navigate with a

collection: Index and Guided-Tour 2%189.

In order to support index navigation, collection links are

created between the collection node and each of the

members (as well as their inverse one). From the collection

node, using these collection links, the user can select any

of the members; from a member the user cart return to the

collection node.

ElB!i!!?stithmlledion ride)

Fig. 1- Collection “Figura Serpentine”, showing collection node, collection members, and collection links

In order to support guided tour navigation, collection links As an example, let us describe the navigation patterns that

are created among the members, according to the topology we provide in our applications. Our collections areof the collection. These collection links allow the user to organized as sequences. The collection node shows all the

move among the members of a collection, without having members, with information sufficient for the user to

to traverse the collection node. The collection node must be identify them. The user can dynamically decide whether

connected to at least one of the members (the “frost” item), he/she wants to use index or guided tour navigation. For

in order to start the guided tour navigation (see Fig.1). index navigation, the user can select one of the members of

8 It is often the case that iodex links and guided tour links are randomly select an item, and start fi-om there a guided tour

provided at the same time. If this is the case the reader ean navigation.


the collection and jump to i~ from there he/she can go

back to the collection node. With guided tour navigation,

from one of the members the user can use guided tour links

(such as Next, Previous, First and Last), moving around in

the collection, without having to visit again the collection

node. We also provide two ways to halt the guided tour

navigation from one of the members: going back to the

collection node (Close command) or remaining on the

current member, but outside the collection control (Stop

command).

Complex issues arise when a member of a collection is

itself a collection (nested collections). Let us assume that

collection A contains collection B as one of its members.

Within A the collection node “b” is used to represent B,

From “b” it is possible to access the members of B, even if

they are not directly members of A.

Since the encapsulation of collections within other

collections can be defined at several levels of depth9,

collection navigation can create a stack of activated

collections.

When collections are activated as Indexes, nested

collections are used to implement hierarchical indexes, i.e.

a master index allows to select sub-indexes, each one of

them allowing to access a sub-index or an object,

Nested collections used as guided tours are more complex

to manag~ most of the applications we have seen either do

not allow nested guided tours, or, often, they show

inconsistencies (if not mistakes) in providing a proper

mntime support, thus becoming very disorienting for the

user.

Let us assume the we start a guided tour about the

“Monuments of Milan” and within it we start a guided tour

on “Churches” and within it we start a guided tour about

“Romanesque Churches”. The frost problem is to define

what is the proper behaviour when the end of the current

guided tour (Romanesque Churches) is reached and a Next

operation is activated. Some applications would jump to

the collection node of the next collection (say “Gothic

churches”); other applications would jump back to the

collection node of the containing collection (i.e.

“Churches”, in our example); other applications would

consider the Next operation as not executable, in the

described situation; other applications (as the “Art

Gallery’? would start again the guided tour on the current

application.

A more general problem concerns the possibility of directly

jumping from a level of nesting to another one (see Fig. 2).

From a node of “Romanesque Churches we could allow a

jump to the next Romanesque Church (Next at current

level, or level O), or a jump to “Churches” (up one level) or

a jump to the next member of “Churches” (Next at level -

9Say collection D, within C, within B, within A.

1), or a jump to “Monument” (up two levels), or a jump to

the next member of “Monument” (Next at level -2).

Monuments

A

---- --

Chumhes

A---- --

Rom~esque

Churches

Fig. 2- Nested collection

This wide range of possibilities offers the advantage of an

efficient interaction for the user, if he/she wishes to change

subject of the reading session; it has the disadvantage,

however, of adding complexity to the interaction dialogue

and to the lay out.

The usage of collections makes necessary to distinguish

two different styles of navigation standard linknavigation and collection navigation.The basic operation of standard link navigation is to follow

a link from a source node and to “instantiate” (according

to the Dexter Model terminology [14]) the target node,

which means, in turns, to present the slots of the targetnode (or some of them, depending on the context of the

link, as defined in [19]).

Let us observe that the standard links attached to a node

are relatively static: once they are defined they are seldom

modified.

The links determined by collections are context dependent,

and they are subject to frequent changes. Every time we

place “Duomo” in a different collection, we provide a new

different meaning for the notion of Next and Previous

applied to it. Having in mind that a node can appear in

several collections, and that collections can be also

dynamically created during a session, this makes a

substantial difference, with respect to standard links. One

of the consequences is that while standard links can be part

of the description of a node, collection links are instead

“external” to it. Answering to the question “what are the

links outgoing from the node Duomo?”, we would never

include, for example, all the possible Next or Previous

links, according to the different collections.

The interplay between standard links navigation and

collection navigation is often the origin of confusing

situations for the designer and for the reader.

Let us assume that the user activates collection “A (say“Romanesque Milan”) and, within it object “a” (say

“S.Ambrogio”) is selected. Is it possible to use the standard


(i.e., non-collection) links of “a”? If yes, assume that

(following one of these links) object “b (say S.Eustorgio),

also belonging to “A, is reached. Which one is the current

member of “A, object “a” or object “b”?

Let us now assume that from collection “A (say

‘churches”) node “a” (say “Duotno”) is reached, and from

there (following a standard link), node “b (say the

Historical Period” 13th Century”) is reached. Is it pxsible

from “b to activate the command “g&back-to-the-

collection node”? If yes, what should be the meaning? One

possibility is to go back to the collection node of “A

(“churches”); this is confusing because the current objec~

“b, does not belong to that collection. Artother possibility

is to go to a collection node where “b belongs (i.e. the

collection of the historical periods); but this is also

confusing, since this collection node has never keen

activated by the user.

Another issue is whether it is possible, from art object “a”

(say “Duomo”), to browse across all the collections

containing it, as one of their members. Most applications

would not allow such a browsing.

The above discussion shows a crucial point of the links

created by the collections: they are active for the members

if and only if the collection node has been activated before!

Lack of space prevents us to discuss other, more

elaborated, examples of confusing situations. We must say

that most of the applications we have seen seem either to

be simplistic, or to fall into a number of inconsistencies.

Simplistic applications are of two kinds: collection oriented

or link oriented.

Typical collection oriented applications are those where

hierarchies of indexes are used to locate the node of

interes~ and no proper standard link is defined for the

nodes.

Typical link oriented applications are those where a

taxonomic set of collections is used to start the session, and

from there on, standard links only can lx used to navigate;

the only collection operation that is allowed is to go back @

the “home node”, which is typically the root of the

taxonomic set of collections.More ambitious applications, that try to provide strong

support both for collection and link navigation, very often

exhibit an inconsistent behaviour (that is, they react

differently in conceptually similar situations), and thisquickly leads the reader to confusion and to the “getting

lost” syndrome.

Our point of view on the subject is that the problem must

be solved at its root a clean consistent run-time semantics

for collection navigation and its interplay with standard

link navigation is needed. Such a clean semantics can be

provided by the precise definition of an abstract mntime

engine, which can be used as a guideline both for the

implementation of applications, and for the design and

implementation of hypermedia systems. By runtime

engine, we mean an abstract but unambiguous

computational machine, capable of providing a ptvcise

operational specification for every possible user request. In

a forthcoming paper [11], we propose our runtime engine

specification for collection based navigation.

In this respect we believe that the current definition of the

run-time layer for the Dexter Model takes into

consideration standard link navigation only; therefore we

suggest an extension to it, in order to provide a better

specification for collection navigation, which represents a

great percentage of the dynamic behaviottr of many

applications.

5 COLLECTIONS AND MULTIMEDIA

It is already been discussed in [19] that some extensions to

the Dexter Model must be provided, when active media

(e.g. sound, animation, video, etc.) are considered.[1, 2, 19] have observed that some inner complexity of

multimedia behaviour can be confined at slot (i.e. atomic

component) level. If a slot, for example, contains a video,

synchronized with a speech and a musical comment, and

the user can interactively play with it, this has little impact

upon the surrounding environment. Let us call slotsynchronization the interactive presentation of a

multimedia slot.

The presentation of a standard (i.e., not a collection) node,

in a multimedia environment, requires synchronization

specifications: how the node should be started, how the

respective playing of the different slots should proceed, etc.

[1, 2,5, 12, 16, 17, 18, 19,22, 23] provide possible models

for this task, that we call node synchronization.

Assuming that slot synchronization and node

synchronization have been solved, we wish to address the

issue of collection synchronization.

Let us assume that the nodes defined for the monuments of

Milan, include10 , beside text and data, a speech commen~

a node musical comment, a video clip with its own spoken

comment, a number of slides, each one with a specific

spoken comment. Let us also assume that the standard

behaviour is the following: when the node is presented (orinstanciatcd, in the Dexter Model terminology) the not-

active slots are presented, together with the node spoken

comment. An interactive control for the video is provided.If the video is started, the node spoken comment is

suspended, being activated the audio associated to the

10The description that follows is a simplified version of the

enhancement of our “HyperMilano” application, currently under

development, through a co-operation of Politecnico with some

reserchem of the Institute for the History of Art at the Catholic

University of Milan.


video itself. The slides can be activated either manually or

in an automatic slide show: in both cases the spoken

comment, associated to each slide, supersedes the node

comment. For layout limitations, all the other information,

except a few data, are not visible while video is presented;

same thing applies for the presentation of the slides. The

musical comment of the node is played in a continuous

manner (with an automatic restart), independently from

the user interaction with the node.

Let us consider now the collection of “Churches”. How to

deal with the multimedia values in the collection node?

One simple solution could be to not include any

multimedia slot, at collection node level: in the index

mode, the user can select the node of his/her interest and

interact with it. In the guided tour mode, each node will be

selected manually, through collection navigation. This

Let us assume, now, that we want to present the collection

in the following way an graphic background, with a title

for the collection, a number of (small size) windows, a

spoken comment for the collection and a musical comment

for the collection.

Each window presents the video (but not the sound)

associated with each monument while the collection

spoken comment and the collection musical comment are

being played in parallel. The user can “click” over a

window, in order to select the node of his/her interest.

The collection node has the following slots: title (own),

background (own), spoken comment (own), musical

comment (own), video for each monument (derived). The

most relevant aspect is that the collection node applies to

the video slots of the nodes its own presentation

synchronization (i.e. small size and video only), which

supersedes the presentation normally applied by the nodes

approach, as [19] has already observed, is simple, but of to those slots.

limited applicability, since it keeps out active media fmm

collections. Most applications require more sophisticated

approaches.

3GlkchollIiue

3..1

,,

S%J.itj;’ “’.... -,

*’+ti i

4----------- ..- 1

No& “‘- ‘-m‘.,’,.

video1 ‘,’,,.,---

Lik@=%”;w-

. .

--

0

.I

o

TbXl

I Nods “.bo ~. ●-~.—-

‘,,’ ,,— IVideo M II‘.’ .-.

( t’

4

Fig. 3- Collection “Churches”. Synchronisation aspects are graphically described by synchronisation arcs.

ECHT ’94 Proceedings

Some collection links are omitted (see Fig. 1)

77 September 1994

Let us now define a different collection node for the same

collection of “Churches”. We would like to have an

introductory page, showing over a background, a few data

and a text. When the user requests it, an overview video is

started. The presentation, for the user, looks like an

interactive video, with the usual commands. A spoken and

a musical comment complete the presentation. The

overview video actually consists of “sukwequences” of the

videos associated to each monumen~ memker of the

collection. If the playing is suspended, the node of the

monument corresponding to the current video fragment is

presenti, the node can be explored by the useq a

“resume” command will start playing the overview video

again. According to our model, the collection node has the

following slots: collection title (own), background (own),

introductory text (own), collection data (own), collection

spoken comment (own), collection musical comment

(own), video for each monument (derived) (see Fig. 3).

The main difference, with respect to the previous example,

lays in the presentation strategy. The video slots

corresponding to the members, are played in sequence, one

after the other, with an additional interactive control.

Suspending the playing at a given frame, causes the

presentation of the member node, from which that frame

was derived.

Let us consider, as a final example, the case where

someone brings in a new video, showing an interesting

walking tour in Milan. How can we include it in our

application, and connect it to the previous material?

This is the way we would proceed. We would select all the

nodes that we consider related to the new video, inserting

them in a new collection, say “W-Tour-1”. The new video

would be logically fragmented in a number of slots, each

one being a short fragment, related to one or more nodes of

the new collection. The collection node will consist of a

background, a title, an introductory text, and the video

fragments, all the slots being not derived. Each one of the

video slots will have a “collection link” to the related

nodes, members of the collection. When the collection “W-

Tour-l” is activatedll , the user can read the introductory

text, and possibly start the video, interacting with it in the

usual manner. Suspending the video, the user can visit the

related nodes, and possibly their links to other nodes;

resuming the collection would start again the video. In this

way, the new video has been fully integrated in the pre-

existing application, with a certain number of additions,

but only minor changes to the previous definitions12. ,

The complexity of the interplay 0} collection

synchronization with node synchronization, is analogous to

the interplay among standard navigation and collection

11Possibly as a member of a collection of eolleetions,

12This example shows again the advantage of dealing with

collection links differently from standard links.

navigation, that has been discussed in the previous section.

The additional problem, already outlined by other

researchers [17, 18], is the definition of the state of a node

(either standard node or collection node) when it is left for

navigation what should be the proper presentation state of

multimedia slots? Possible answers are “exactly the state

reached at the time when the node was left”, “the initial

state”, a “safe” state, or others?

6 CONCLUSIONS

In this paper we have presented the notion of collection, as

a specialized interpretation of the composite component of

the Dexter Model. Our opinion is that the generic notion of

composite in the Dexter Model should be refined in a

number of “typical” possible structures, with the

specification of their own navigation and synchronizationfeatures. Navigation and synchronization should be

explicitly taken into consideration (i.e., supported) in the

runtime layer.

Our specific main point is that collections are fundamental

in many applications, therefore they should be explicitly

acknowledged as one of the typical composite structures.

Our second point is that collections create new links

among nodes, not well represented by the storage layer of

the Dexter Model. The third point is that the rnntime layer

of the Dexter Model should also include a precise

definition of the semantics for collection navigation, and

its interplay with link navigation. The fourth point is that

coupling collections with the multimedia extensions,

already proposed by other authors, will allow to define and

implemented sophisticated hypermedia applications, with a

pwerful interactive control and well-defined consistent

semantics.

We are now in the position to make more precise bridges

between our approach and the work of other researchers.

Our interpretation of the roles of collections within

applications, is exactly what was envisioned by V. Bush: to

provide trails across large applications.

Trigg’s guided tours [25] can be viewed as a special case of

our collections. The main differences lay in the fact that we

explicitly define the collection node (with additional

information associated to it), we define a variety of

authoring mechanisms, we have analyzed the interplay

between standard link navigation and collection

navigation, we include extensions to active media, and,

finally, we clarifying the notion of context dependent links(i.e. collection links).

Zellweger’s scripted documents have motivations very

close to our collections; the main difference is that we

provide structural primitives, trying to identify predefine

patterns of behaviour. Zellweger, instead, leaves the role of

defining the behaviour to scripts, which have the power

and the arbitrariness of general programs.


K. Gr$nbaek and R. Trigg, in [13], advocate the use of

composite in hypermedia application their proposal,

however does not precisely specify navigation (or

synchronization) features associated to these composites;

nor the application roles for such composite, with the

exception of “link browser”.

Previous works on active media synchronization by

Hardman et al. [17, 18, 19], and Buchanan et al. [1, 2], can

be taken as a basis, and adapted to provide the primitives

for collection synchronization that satisfy the requirements

we have discussed in the previous section.

With respect to the typical usage of collections in Data

Bases, our collections exhibit several difference~ an inner

structurq navigation capabilities; relaxation of the

constraint of homogeneity a variety of creation

mechanisms. What we borrow from the Data Base

approach is the idea that queries operate within collections

and also are an important mechanism to create other

collections.

Let us now briefly describe our current and future work inthis area.

In several applications we have implemented the run-time

support for a primitive version of collection navigation and

synchronization, as described in this paper. We are

currently working at the implementation of a generic (i.e.,

application independent) run-time engine to support the

most general version of collections. We are also defining

an abstract model for it, in order to provide a clear and

consistent semantics [11].

As far as authoring of collections is concerned, in most

cases we have basically been using built-in, pick-up and

intentional (query-based) definitions. In the context of a

specific project [21], we have implemented also all the

other ways to create collections. We are currently working

to implement a generic version for this more general

authoring environment,

ACKNOWLEDGEMENTS

This work has been partially supported by the Commission

of the European Communities within the ESPRIT projects

HIFI and MINERS. We are grateful to the partners of these

project and to all the members of the Hypermedia

Laboratory at Politecnico di Milano.

REFERENCES

[1] Buchanan M.C., Zellweger P., “Specifying Temporar

Behaviour in hypermedia Documents”. In Proc. ACM

ECHT’92, MihrIo, I, Dec. 1992

[2] Buchanan M.C., Z.ellweger P., “Automatic Temporal

Lay-out Mechanisms”. In Proc. ACM Multimedia’93,

Anaheim, Ca, 1993

[3] Bush V. “As We May Think”. In The Atlantic

Monthly, July 1945

[4]

[51

[a

[7]

[8]

[9]

Cavallaro U., Garzotto F., Paolini P., Totaro D.

“HIFT Hypertext Interface for Information Systems”.

In IEEE Sojhvare, Nov. 1993

De Mey V., Gibbs S., “A Multimedia Component

Kit”, In Proc. ACM Multimedia”93, Anaheim, Ca,

1993

Garzotto F,, Paolini P., Schwabe D. “HDM - A Model

for the Design of Hypertext Applications”. In”

Proceedings ACM Hypertext ’91 (S. Antonio, TX,

Dec. 1991)

Garzotto F., Paolini P., Schwabe D. “HDM - A Model

Based Approach to Hypermedia Application Design”

In ACM Trans. Ofl. Znjl Syst., 11 (l), Jan. 1993

Garzotto F., Mainetti L., Paolini P, “Navigation

patterns in Hypermedia Data Bases”, In Proc, 26th

IEEE Int’1. Con. on System Sciences, Maui - USA,

Jan. 1993

Garzotto F., Mainetti L., Paolini P., “HDM2

Extending the E-R Approach to Hypermedia

Application Design”. In Proc.12th Int’1 Conf on the

Entity-Relationship Approach, Arlington, Tx, Dec.

1993

[10] Garzotto F., Mainetti L., Paolini P., “Navigation in

Hypermedia Application Modelling and Semantics”,

In Journal of Organizational Computing -to appear

[11] Garzotto F., Mainetti L., Paolini P., “A Run-Time

Engine for Collection Based Navigation in

Hypermedia Applications” - in preparation

[12] Gibbs S., Breiteneder C., Tsichritzis D., “Data

Modeliig of Visual Objects”, In Visual Objects,

Tsichritzis D. (cd.), University’ de Genbve, 1993

[13] Gronbaek K., Trigg R.H., “Design Issues for a

Dexter-Based Hypermedia System”, In Comm, ACM,

37(2), Feb. 1994

[14] Halatz F., Schwartz M. “The Dexter Hypertext

Reference Model”. In Cornm. ACM, 37 (2), Feb. 1994

[15] Hannond N, Hallison L, “Travels Around a Learning

Support Environment Rambling, Orienteering, or

Touring”. In Proc. ACM CHI+HZ C’orf, Toronto,

Apr. 1988

[16] Hamaka R., Rekimoto J., “Object Composition and

Playback Models for Handling Multimedia Data”. In

Proc. ACM Multimedia’93, Anaheim, Ca, 1993

[17] Hardman L,, Bulterman D.C.A., Van Rossum G.,

“The Amsterdam Hypermedia Model: Extending

Hypertext to Support Real Multimedia”. InHypermedia, 5 (l), 1993

[18] Hardman L., Bulterman D.C.A., and Van Rossum G.,

“Links in Hypermedkx the Requirement for Context”.

In Proc, ACM Hypertext’93, Seattle, Wa, 1993

[19] Hardman L., Bulterman D.C,A., Van Rossum G.,

“Adding Time and Content to the Dexter Model”. In

Comm. ACM, 37 (2), Feb. 1994

[20] Marshall C,, “Guided Tours and On-LinePresentations: How Authors Make Existing Hypertext


Intelligible for Readers”. In Proc. ACM Hypertext’89,

Pittsburgh, PN, NOV. 1989

[21] MINERS Project ESPRIT P6552 “MINERS: An

Editorial Platform for Electronic and Traditional

Publishing”, Technical Annex, 1991

[22] Ogawa R., Harada H., Keneto A., “Scenario-based

Hypermedk A Model and a Systems”, in Hypertext:

Concepts, Systems, and Applications, Rizk A, Streitz

N, and Andre’ J. (eds.), Cambridge University Press,

1990

[23] Prabhakaran B., Rahavan S.V., “Synchronization

Models for Multimedia Presentation with User

Participation”. In Proc. ACM Multimedia’93,

Anaheim, Ca, 1993

[24] Trigg R.H., Weiser M., “TEXTNET A Network-

Based Approach to Text Handling”. In ACM Trans.

Off. Inf Syst., 4 (l), 1986[25] Trigg R.H., “Guided Tours and Tabletops: Tools for

Communicating in a Hypertext Environment”. In

ACM Trans. Of. Infi Syst. 6 (4), 1988

[26] Van Dyke Parunak H. “Don’t Link Me In: Set Based

Hypermedia for Taxonomic Reasoning”. In Proc.

ACM Hypertext’91, S. Antonio, TX, Dee. 1991

[27] Van Dyke Parunak H., “Hypercubes Grow on Trees

(and Other Observations from the Land of

Hypersets)”. In Proc. ACM Hypertext’93, Seattle,Wa,

Nov.1993

[28] Zdonik S.B., Maier D. (eds), “Reading in Object

Oriented Database Systems”, Introduction paper,

Morgan Kaufmann Publishing, 1990, S.Mateo, CA

[29] Zellweger P., “Scripted Documents: A Hypermedia

Path Mechanism”. In Proc. ACM Hypertext”89,

Pittsburgh, PN, NOV. 1989

ECHT ’94 Proceedings - 80 September 1994

Adding multimedia collections to the Dexter Model

Documents

Transcript of Adding multimedia collections to the Dexter Model