Hypertext development using a model base (1)

HDM - A Model for the Design of
Hypertext Applications
Franca

Garzotto,

Paolo

Paolinil

Dipartimento di Elet.tmnica,
Politecnico di Milano,
Piazza Lemardo da Vinci, 32,
Mihno 20133, Italy

Daniel

Schwabe2

Department of Informatics,
Pontificia Universidade Catdlica,

R. M. de S. Vicente, 225
22453 Rio de Janeiro, Brazil

ABSTRACT
We present the latest developments of HDM, a design model for Hypertext Applications.
The basic features of HDM are the representation of applications through several design
primitives: typed entities composed of hierarchies of component
different perspectives
for each componen~
units corresponding
to component-perspective
pairs; bodies
representing the actual content of the units; structural links, binding together components
or sub-entities of the same entity; typed application
links, interconnecting
components
belonging to different entities; and a spccitlc browsing semantics based on anchors, as a
way to activate many different link types from within a unit.
The development
of HDM is part of the HYTEA project, carried on by a European

consortium, aiming at the development of a set of authoring tools for an “engineered
development of Hypertext-Hypermedia
applications. A HYTEA application is made by an
HDM schema and an HDM Hyperbase (i.e., a set of instances). The basic HDM has
already been shown to be translatable, either manually or through a compiler, into a nodeand-link model (“a la DEXTER model”); the translated application can be targeted on
several implementation
tools (i.e., standard Hypertext tools already available on the
market). HDM has already been used to develop a (small number) of applications, and to
describe preexisting
applications.
These experiments
have shown the need for
improvements that are discussed in the papec aggregate entities; sharing of components;
is-a relationships and inheritance between entity types; sharing of bodies; structured access
and “guided tours”; use of active media (animations and video-clips).

lE-mail:relett34@

imipoli.bitnet

2Daniel Schwabe developed this work while on sabbatical
supported by CNPq-Brasil). E-maih schwabe@inf.puc-rio.br
Hypertext ’91 Proceedings

313

leave during

1990 (partially

December 1991

1

INTRODUCTION

Many hypertext applications
deal with very complex application domains (legislation,
engineering, etc.), that may get even more complex when multinational,
multilingual

and
cross-cultural
aspects also must be considered. This is particularly
true for corporate
applications,
where the complexity
is increased with additional
consistency demands
arising from the different parts of the corporation and of its operating environment.
Successful
hypertext
authors directly
interconnect
meaningful
parts of the information
base, to convey
natural way. The appropriate choice of which links to
crucial design step. For this purpose, node-and-link level
too low-level, being more oriented toward implementation

only the most important
and
the overall meaning in a more
include, and which to omit is a
models [Hzdasz 90, Garg 88] are
than toward design.

We are concerned with authoring-in-the-large:
defining the topology of the hypertext.
During the design of an application, authoring-in-the-large
concerns are more important,
as they will ultimately determine the navigation patterns available for readers.
Authoring-in-the-small
(i.e., filling
in the contents of nodes and determining
their
appearance to readers) is also very important, but it is a different activity that we claim
can (and should) be dealt with separately. This view is based on the belief that systematic
and rational structural decisions about the hypertext should be made before the actual
hypertext is ever written, so that coherent and expressive hypertext webs can be designedin instead of added-on. The extent of this top-down approach has not yet been determined,

and many authors would disagree with such a strict top-down stance. Even though we
firmly believe it to be almost mandatory for the class of applications
mentioned in
beginning
of this section, having a design model still brings many advantages
independently of development method, as discussed next
A model for authoring-in-the-large
should provide the primitives that rdlow the author to
describe the hypertext application in a more concise and clear manner than by simply
building a skeleton of that application
in a given hypertext system; furthermore,
this
description should be as much system-independent
as possible. We propose a design
model, Hypermedia
Design Model, (HDM)
whose specifications
can be translated
automatically
into a lower-level node-and-links

specification, giving the topology of the
actual implementation.
This specification can then be targeted toward standard hypertext
tools, applying authoring-in-the-small
design steps. This process essentially provides a
way to describe a complete hypertext application
in a system independent manner. A
discussion of current tools for authors, and examples of HDM modeling can be found in
[Garzotto 9 1].
Before describing HDM, it is interesting to summarize the major advantages in having a
design model; some are true of any kind of model, others are more specific to hypertext
design models. Regardless of the way an hypertext application is developed (using a topdown approach or not), authors can benefit from these properties.
Design models provide a language in which an application analyst can specify a given
application
helping the communication
between the analyst and the end user (i.e., the

31n this paper we use the terms hypertext application
and hypertext to denote online
documents made up of a web of interlinked pages. We will use the term hypertext system

for software tools used to create a hypertext. Notecards, KMS, Intermedia, Hypergate are
examples of hypertext systems. Note that a single hypertext might be published in
several editions, each using a different hypertext system.
Hypertext

’91 Proceedings

314

December 1991

client, usually); between the analyst and system designer; and between the system
designer and implementor, when they are different persons. They can be used to documen(
the application, providing support for users of the application and for maintenance of the
system; it also serves as a common language in which to compare (discussing the
similarities and differences of) applications.
Design models provide a framework in which the authors of hypermedia applications can
develop,
analyze and compare
design

methodologies
and rhetorical
styles of
“hyperauthoring”,
at a high level of abstraction. This analysis can be done without having
to resort to looking at particular visualizations
(screen formats and appearances, button
functionalities
and the such) or to the detailed contents of units of information.
At this
level, it is possible to analyze the “conceptual”
organization
of the application
domain
knowledge rcpmented, and examine its adequacy for the intended uses.
An interesting related aspect, that has received little attention in the research literature, is
the task of proofreading a hypertext [Brown 90]. Clearly, proofreaders need to check links
as well as text, since spurious or accidental links can be as embarrassing
(or even
damaging) as more conventional typographic errors. This task should be greatly helped by

the availability of a specification language.
Design models can be used by Design Tools, much in the same way as application
generators are based on languages to specify classes of applications, or as CASE tools
have specification languages to describe software (at various levels of abstraction).
An additional expectation is that applications developed according to a model will result
in a very predictable representation structure. Consequently, the navigation environment
for
readers
should
also
be predictable,
thereby
reducing
the so-called
“disorientation/cognitive
overhead” problem.
The remainder of this paper is organized as follows. Section 2 presents a summary of the
current version of HDM and a small exampl~ section 3 discusses extensions to the basic
model being developed; and section 4 draws some conclusions.

2

THE HYPERMEDIA

DESIGN MODEL4

According to HDM, an application domain is composed of Entities, which in turn are
formed out of hierarchies of Components.
Entities belong to a Type. Entities can be
connected to other Entities or Components by Links that can be either Structural
or
Application
links. Structural
links reflect the hierarchical
structure
of entities;
Application
links connect Entities or Component to other Entities or Components to
reflect application
domain relations. Components can be instantiated by one or more
contained in
Perspectives into Units. Units provide a reference context to information,
their Bodies.
An HDM Schema is then a set of Entity and Application
Link type
definitions.
An HDM Schema Instance is a particular set of entities and links defined
according to a given schema.
Once a Schema Instance has been defined, it can be operationalized via the specification of
a particular Browsing
Semantics, that gives the runtime behavior of the application.
in which
to specify
such Browsing
Although HDM does not provide so far primitives
Semantics, there is a default Browsing Semantics that is compatible
with most cardoriented hypertext systems.

4 This section contains a summary of HDM and of an example taken from [Garzotto 90].
Hypertext ’91 Proceedings

315

December 1991

2.1

HDM Primitives

2.1.1 Entities

and Components

We refer to an Entity as a concrete or conceptual real world object in the domain that is
relevant for the application. Typically,
an entity will denote something quite complex,
whose internal structure may be further decomposed. An entity in its whole can be
represented through several individual, smaller-graincd pieces of information, that we call
Components.
Examples of entities are “Law 19/8/89”,
Dante’s “Divine
Comedy”,
Gershwins’s “An American in Paris”.
A Component is
grouped into an
entity. Examples
examples above)
Movement” (“An

a piece of information
describing a part of an Entity. Components are
arbitrary, application dependent, hierarchy to form the corresponding
of possible components
(with the corresponding
entity from the
are “Article 1“ (“Law 19/8/89”), “Paradise” ~’Divine Comedy”), “First
American in Paris”).

HDM Entities fill the role of “composite objects” (with the inclusion relation) described
by Halasz in [Halasz 88], with the restriction
that all components of an entity are
homogeneous with respect to their perspectives (see. next subsection). We have chosen
hierarchies as the structure of Entities because they area frequently occurring structure,
useful in specific contexts. Many authors have also observed that hierarchies are very
useful to help user orientation when navigating in hyperdocuments
[Akscyn 88, Brown
89].
2.1.3

Perspectives

and Units

Components
describe pieces of information.
Due to the richness of most hypertext
reading environments, information
may be presented in many different ways. A natural
abstraction that can be made in these situations is to allow an author to refer (and think)
about the concept that is being represented by a Component independently from the way
it is described. In other words, the concept can be thought of as having several
“perspectives”.
HDM helps this abstraction by having Perspectives
for Components.
By the term
Perspective we mean the appearance of a piece of information.
The description
of a
component according to a given perspective is called a Unit, which has a body containing
the information
itself. HDM says nothing about bodies, as it is interested in talking
about hypertext structure.
A Component may have, therefore, one or more Units (corresponding
to Perspectives).
has perspectives
“Official
Text” and
For example, assume that entity type “Law”
“Description”.
If we structure an entity of type “Law” so that each component corresponds
to an article, then we may say that for each article (component) of an entity of type “Law”
there will be one unit whose body is its “Official
Text” and another whose body is its
“Description”.
These units provide a context in which to refer to (the text or description
of) the article as part of the “Law”.
2.1.4

Entity Types

A common abstraction found in most data models is the notion of type. An Entity Type
groups entities having common properties, namely “using the same set of perspectives”,
“being broken into components according to the same criteria”, and “being related to
of entity types (with the
entities
of other types in the same way”. Examples
corresponding
entity from previous examples) are “Law”
(“Law 19/8/89”),
“Poem”
(“Divine Comedy”), “Symphony”
(“An American in Paris”).
Hypertext

’91 Proceedings

316

December 1991

In HDM the
perspectives
Perspective.
type have at

set of perspectives associated to an entity type is indicative only of possible
for its entities, so that it is necessary to have the notion of a Default
The intended meaning of the default perspective is that all entities of this
least this perspective% further significance of this concept will be shown

when we discuss the process of mapping into node-and-link structures.
2.1.5

Links and Link Types

The major advantage of the hypertext model is the organization of an information base in
a non-linear fashion. This means, loosely speaking, that pieces of information
can be
related to each other through links associated to them. The more the “meaning” of a link
approximates the relationships
in the application domain, the more the user will be at
ease in “using”
the corresponding
hyperdocument,
since links will evoke familiar
associations.
HDM differentiates between thnx kinds of links: Structural, Application,
and Perspective.
Structured Links connect components belonging to the same hierarchy. Entities provide a
navigation context, so following
structural links allows the reader to examine different
parts of the same “thing”. For example, in the Oxford English Dictionary lllaymond 88],
if an entity type is “Entry”, each sense could be a component and structural links would
connect all senses of the same entry, allowing navigation among them.
Whereas structural links capture rather “standard” semantics (structure, or the inclusion
relation of Halasz composite objects [Halasz 88]), Application
Links embody semantic
relationships in the domain. That is, they represent some (arbitrary) relationship between
entities that the author deems meaningful, in the sense that this relationship evokes some
association between concepts useful to the user of the hyperdocument.
By providing an
application
link, the author will be making it “natural”
to the user to access some
information
that is “related” to the information
being read at that point - it suffices to
traverse that link.
Given that Components stand for an abstraction of several Perspectives of the same
subject, Perspective links allow the reader to move between different Perspectives (i.e.,
Units) of the same Component.
To be consistent with the notions of Entity and Entity Types, HDM defines Application
Link Types as a set of links instances whose source and destination entities are of the
same entity type, respectively. For example, the author may specify that a link of type
“Is-author-of”
can connect entities of type “Book”
to entities of type “Person”: this
means that in principle all instances of “Book” (e.g., “Hamlet”, “Illiad”,
etc.) may have a
link to a corresponding
“Person” (e.g., “Shakespeare”, “Homer”) that is its author.

2.1.6

Derivation of Links

Having hierarchies as primitive concepts suggests that, at design level, an author needs to
specify only a minimal set of structural links - those necessary tQ define the structure of
an entity (“parent” and “next sibling”) - from which many other implicit structural links
(such as parent-child, to-top, etc.) maybe derived if desired.
Derivation rules can exist for application links too, if we regard them as relations between
entities (components). Properties of these relations, such as symmetry and transitivity,
when present, can be used to derive other links. Link derivation becomes particularly
powerful when used in conjunction with composition of relations, and in fact defining
which links are actually derived, for a given application, is a full fledged design step.

Hypertext ’91 Proceedings

317

December 1991

So far HDM does not itself include a language to specify such derivation
rules (for
application
links), but it is possible to have such a language in a formalism
outside
HDM. Given such a language, the use of HDM provides a great amount of conciseness to
the model specification - the author needs to provide a much smaller amount of links than
the number of links that will actually be present both at conceptual level and at concrete
level.

2.1.7 Schema and Schema Instance
A class of hypertext applications in a given domain can be characterized via the notion of
Schema, defined as a set of entity type and link type definitions. A schema characterizes
classes of application
because it does not specify actual entities and links, but rather
general properties of potential entities, and potential links between them. Entity type
definitions
in the schema include derivation rules for structural links; application
link
types will allow inclusion of derivation rules when a language for such rules is defined.
A particular application in a given domain is specified by instantiating
a schema, i.e., by
giving entities and links as instances of the types defined in the schema. Tle notion of
schema and schema instance allows, sometimes, the reutilization
of the same schema for
different applications
in the same domain. These applications
should share the same
global structure, but differ in the particular
instances that are actually present. A further
level of reutilization
maybe obtained when new applications preserve the local structure
(structural links inside entities and application links between them) in a schema instance,
but redefine the bodies of the units.
A schema instance characterizes the “static” aspects of a specific application. To specify
the “dynamic”
(runtime) behavior of an application, one must add a particular browsing
semantics, as will be discussed in the next section. This again adds another reuse
dimension, in which the same static specification is maintained, but a different browsing
semantics is used, generating a different running application.
By varying the browsing
semantics, it is possible to have the same conceptual application, whose running versions
are implemented in several different hypertext systems.

2.1.8

Browsing Semantics

The visualization
and dynamic properties of hypertext
are defined by its browsing
semantics [Stotts 89]. In HDM browsing semantics will determine three further kinds of
design choices for authoring-in-the-large
1) What are the objects for “human consumption”;
in HDM terms, what can the user
perceive: Entities, Compnents,
or Units? How are these objects perceived?
2) What are the perceived links between objects: in HDM
are links visible (navigable)?

terms. which links, and how,

3) What is the behavior when links are activate~
activates a one-to-many

in HDM terms, what happens when one
link? What is the “state” of the source and destination objects?

HDM, as discussed so far, does not specify any particular
browsing
semantics for
hypertext
specified with it. Work on providing primitives
for defining such browsing
semantics is at a preliminary
stage, but simple browsing semantics can be specified with
formalisms such as Petri-Nets (see [Stotts 89]). Other aspects of the browsing activity,
such as the actual appearance of screens and icons, and other authoring-in-the-small
concerns me not addressed at all.
It should be noted that, given a particular browsing semantics, it is possible to translate
an HDM specification
into the implementation
structures of some running hypertext
Hypertext

’91 Proceedings

318

December 1991

system; this translation process actually introduces another design dimension. Each choice
made when deciding how to translate HDM links into concrete links affects the final
hypertext the user will see. Thus, it is quite natural to think that these choices should be
made according to certain user profiles, therefore allowing the same hypertext design to be
compiled for different classes of users. Reference [Schwabe 90] describes a prototype
compiler that allows the translation of an HDM schema instance into HyperCard, using a
relational database representation.
We have defined a simple default browsing semantics that is compatible with systems at
the node-and-links
level found in many card-oriented hypertext systems, discussed next.
Reference [Garzotto 90] contains the formal definition of this browsing semantics using a
Petri-net-based formalism.
In this class of browsing semantics, we assume that no abstract objects (entities and
components) are directly visible - only units (corresponding to the usual hypertext notion
of node) can be perceived by the readers as concrete objects. In consequence, readers can
see links only among units and so, in the end, actual connections must be established
among units. Also, assume that only one node is active at any time, and only one link
can be traversed at arty time. We will call concrete links the connections among units, as
distinguished from abstract links, which are defined among entities or components. It is
necessary then to specify how concrete links can be obtained from abstract links.
Structural link translation obeys the following rule Links between components should be
translated into links between the corresponding units in the same perspective. This rule
expresses a kind of stability criterion w.r.t. the use of perspectives - if the reader is
looking, say, at the “Text” perspective of an article of a law, and follows the structural
link “next article”, she will see the “Text” perspective of the destination component, as
opposed, say, to the “Graphic” perspective, which might be the default.
Application
links are mapped using the default representative, defined for each abstract
object (component or entity). The default representative for a component is its unit in the
default perspective of its type. The default representative
for an entity is the default
representative of its root component. This corresponds to saying that the root component
of an entity (in its default perspective) “stands” for that entity. Given this notion, entityto-entity abstract links translate into concrete links between their representatives.
Component-to-component
application
links are mapped using the rule whereby each
abstract link corresponds to a set of concrete links connecting each unit of the source
component to the default perspective unit of the target component.
In hypertext, connections among pieces of information
are usually visualized through
“anchors” (or “buttons”). Anchors are well identifiable areas on the screen that signal the
existence of a connection, and can be selected by the reader to get into the link target(s).
Anchor types provide a mechanism for the author to present groups of link types
together, also renaming or hiding them as well, as desired. By assigning a set of link
types to each anchor type, the author can control link visibility.
Consider for example, that entity “procedure”
has a link of type “Formal
Legal
Justification”
to a “Law” and a link of type “Informal
Justification”
to an “Informal
Regulation”.

The author

might

want

to provide

the user with

a single

reading

link,

maybe

labeled “Justification”,
since the distinction might not be important for the reader. This
cart be achieved by specifying the anchor type “Justification”
to be the union of link types
“Formal Legal Justification”
and “Informal
Justification”.
The anchor mechanism also
allows the author to hide selectively some links for some perspectives.

Hypertext ’91 Proceedings

319

December 1991

Activating an HDM anchor can activate several possible destination nodes, and therefore
the result of this activation must be defined. Clearly, this is a part of the particular
browsing semantics being used, which in turn is partially dependent on the particular
system being used to implement the hypertext. If it supports multiple active windows,
for instance, a possible choice may simply be to show all destinations, each in a separate
window.
Still, this solution is often not acceptable or not even possible in many
systems.
An alternate approach to deal with this situation is to introduce the notion of chooser, A
chooser is a mechanism asswiated with a single-source-multiple-target
anchor that allows
the selection of one of the multiple
targets of the anchor. As such, choosers are
implementation
structures that can be generated automatically
from the specification of
the hypertext,
using any available
mechanisms
present in the implementation
environment (e.g., menus).
2.2

Example

This example describes the information
handled by a credit organization. The goal is to
have an organized way to access and refer to a large set of information
of vastly different
(but inter-related)
nature. This organization
manipulates
Documents
according to
Procedures.
The reasons why Documents and Procedures are the way they are can be
explained by looking at Laws, Regulations
and Informal
Norms; the state of affairs is
captured in the schema described in figure 1, where Entity Types and Application
Link
Types have been specified.

mcmwted

by/

mcwabon

fcf

Laws

poducad

I

bfldciwments

Figure 1. Schema of Entity Types and Application

rwcassafy

im

Link Types for a Banking Application.

5For simplicity,
since relations in this examples are symmetric,
we have drawn bidirectional arrows instead of two separate ones. The labels indicate relations and their
inverses.
Hypertext ’91 Proceedings

32o

December 1991

mar
-

WPERB4NK

—.
!—

I
OpmlkJK4
km In
-i=Reqmtvelnmral
lb Elii

I wl’””m~fi /
I

‘=--

\ ,+

/’

\

\hiiiiiw

‘..—

I

)“’I’Y

. . .... .

‘

i

\

Data
Enhv

//y

‘igure 2. Instance of Schema in Fig. 1.
Zach of these Entity Types has a set of Perspectives associated to it. We do not enumerate
them all here, but give a few examples
yrspeetive):
“ Laws and Regulations

have Structure*

●

Documents

have Structure*,

●

Procedures have Flow Diagrams*

(the one marked

and Oficial

with

a ““”

is the default

TexC

O@cial Text and Description;
and Description

Let us look now at a fragment of an instance of the schema above, depicted in figure 2. In
the figure,
detailed.

shaded areas denote entity instances whose internal

structure has been further

There is an entity of type Procedure named Mortgage Loan Procedure, which is made up
of several steps. The first step is named Preliminaries,
and one of the intermediate steps is
named Request Acceptance and Entry. This step is, in its turn, also made of several steps,
the seeond being named Ver@cation of Request and the third being named Request Data
Loan Procedure
is really a hierarchy of subEntry. As we can see, the Mortgage
procedures, each represented by a component.
Another entity present is Circular
HyperBank 21/10/89 of type Regulation made up of four components: Units Involved,
Subject, Operational
Norms in Request Verification,
and Data Entry Rules. These last
two components represent information that respectively affect the way the procedure (sub)
steps Verification
of Request and Loading Request Data are performed
therefore, an
application
link of type has-effects-on
is present between them. Circular HyperBank
21/10/89, in turn, is motivated-by
Law 19/8/89.

Hypertext ’91 Proceedings

321

December 1991

●** CIKUMR
LOCAL

INsls

-~

N. 1723 &t.

218t 1989

● “*

INVOLVEO

UWATlffi

WR.T. THE VALtE

1

TIE
OF THI

ALLOWEO I’M3NTSAGE LOAN AIWllMT
tSN?TSAGE HMRAN7V

~OFIERATIIMALNORtlS IN LOANREOUESTVERIFICATION

I

Dwaipam

(XMa2

Td

MeHvatlons

Figure 3. Structure perspective

I
i

I

BEru2s

I

of a Regulation.

In figure 3, the user is looking at the “Structure”
perspective of the Regulation instance
“Circular HyperBank 21/10/89”. Notice that all the links of type “Justified by” have been
To change perspectives and look at the
grouped under the anchor (button) “Motivations”.
“Official
Text”, the user presses the button with the same name (in this case), seeing the
screen shown in figure 4. Besides the anchors corresponding to the application relations
(“Effects”, “Motivations”)
and the perspective links, all at the bottom of the screen, there
are other anchors on the sides, some corresponding to other structural links (e.g., “Top”),
others corresponding to functions of the system (i.e., are not associated with any link),
such as” Mark” and “Trace” at the top left hand.

B
t

: LmL

CIWJLAR

“w’

IffPERSANK

flMMERS,

N 1723-

Oct. 21*

19e9

CLIINT SENVICE2 Department

UPDATIW THEALLOWEDf“ORTOACELMNMDUN7
MORTGAGE
WIANN

Subjti.

G
:=

=7S%
??J
—

fWMOENS

E

W.R.T. THE VALUEOFTHE

e inform that th
existi rq rules, to h be adopted by the loc$l units,
regwdi rq
MORTWE
LOAN REQUEST VERIFICATION snd MDRTOAOE LDANCOWESSION,
h9V0
bwn extendul 83 follow

w
ii!

if ths purw
ef tho Iom IS tln purchw.
or ths r.atructurinq
oftbbar.mm.g
pmtyw
le.mllu&clar8S
rwlttw?x,
tlmn tlm higtwt
lmnwnountthoi
an be prwi.w
is ttm
must bo, aa uwdatho
cmtunw
,*
oftlnvslw
of ttm gwrtfitg;
ttw
eqollv declared residence
; Ma rule holh far AW wamw
cctqary

qimr.ntg

a

~

n
z

Figure

3

4, Official

RECENT

text

perspective

the

DEVELOPMENTS

Regulation

in Fig, 3,

IN HDM

We have used HDM for the past 18 months to develop several applications
- three
textbooks; two document management systems in the banking industry and a multimedia
database documenting
a painter’s
work and related documents.
Several existing
applications
were also described using HDM. The model has shown to be powerful
enough to represent most of the applicative
situations encountered, but still several
improvements have become necessary, briefly summarized next.

Hypertext

’91 Proceedings

322

December 1991

3.1

Application

structuring

A more careful analysis of existing and planned applications has shown that, in general,
applications are made of two components: the Hyperbasc and its Access Mechanisms. The
Hyperbase is structured information
space (in the sense of [Streitz 89]), which can be
described via the standard HDM primitives (including some extensions mentioned in this
section), making up the core of the application.
The Access Mechanisms provide a way to “get into” the Hyperbase and to start navigating
there. We have classified four different types of access mechanisms (evidently, not all are
present or fully developed in each application):
●

Path Mechanisms,
such as Guided Tours [Marshall
89] and Scripted Documents
[Zellweger
89], that provide a set of guidelines allowing access, in a prescribed
sequence(s), to units of the Hyperbase. The basic navigation paradigm is the ordered
sequence (typically provided with next and previous buttons).

c Indexes allow the reader to select the topics of her interest through a series of (topical)
indexes, typically organized hierarchically. The result of the selection could be either
a single entity or a limited linear path.
●

●

Queries allow the reader to specify her interest(s) through a precise formulation using
“keywords”
or “attributes”
previously
associated with entities (or components),
analogously to query mechanisms for databases.These mechanisms need formatted
information
(“attributes”)
to be attached to entities
(or components)
to be
implemented. The result of executing such a query is typically a linear guided tour,
which has been assembled dynamically during query evaluation.
Associa five access is similar to queries, the difference
being that the desired
information
is specified using patterns on the contents of entities or components, or
on structural properties of the hyperbase. The advantage is greater flexibility;
the
disadvantage is an inherent minor precision in identifying
the desired information.
Several different pattern matching mechanisms can be used.

The main concern of HDM so far has been the definition of the Hyperbase, which anyhow
represents the core of any application. Some of the HDM primitives can be used to model
access mechanisms such as indexes and some types of guided tours, but in a rather
artificial
way. We are now considering the addition of specific mechanisms to model
access, following the classification above.
3.2

Aggregate

Entities

In the original HDM model entities had a tree-like homogeneous structure, in the sense
that they were made of components of the same nature (same type), from the application
modeling point of view. The partitioning
of an entity into components was essentially a
refinement process, in a similar way to what is done when it is said that a chapter is made
of sections, a section is made of paragraphs, ete.
There are many situations in which an entity is made up of components, but these are not
necessarily homogeneous, such as, for example, the specification of an “electric device” as
consisting
of a “generic
description”,
“electric
characteristics”
and “magnetic
characteristics”.
With
the current
HDM
primitives,
it is possible
to represent this
situation in various ways - one entity type being the “generic description”
having
application links linking it to “electric characteristics” and to “magnetic characteristics”
entity types; or one entity type and three perspectives.
Both models are possible but basically incorrect for two reasons: misuse of the modeling
primitives and artificialness of the definition,
Application
links are intended to connect
Hypertext ’91 Proceedings

323

December 1991

truly independent entities, and the example shows entities that are not really independent,
since “electric characteristics”
do not make any sense disconnected from the “generic
description”
of the device. On the other hand, perspectives are intended to represent the
same information in different manner (different medium, rhetoric style or language). In the
example, instead, the information being represented in each case is intrinsically
different,
and not “perspectives” of the same “thing”.
We have therefore decided to add the notion of aggregate entity types. An aggregate entity
type is made of several component subentities. Each component subentity has a name and
a type (which could be again an aggregate ore a homogeneous hierarchy). Aggregate
entities are closer to the composite objects in the sense of [Halasz 88], where a type
mechanism has been superimposed on the elements of the composition.
We were aware from the beginning of the need for aggregates entities. We were reluctant
to introduce them in the first version, since we were afraid that they could be misused as
replacement for application links and perspectives. We feel HDM is now at a point where
they can be introduced, together with a set of style guidelines to provide indications about
how the different modeling alternatives should be used.

3.3

Structure

of types

The current HDM type structure is flat, both for entities and for links: each type is
independently defined. Similarly to what is proposed by current object-oriented paradigms,
we have encountered several “natural hierarchies” of types. For instance, in an application
for lecture notes in electrical engineering, there is an entity type for “electric device”, and
four different refinements of that type.
We are adding to HDM the primitives
to deal with hierarchies of entity types, and
consequent inheritance of properties. If an entity type T is defined, an entity type T’=
reJ”inenzent-o~(T) inherits all the properties of T, with possible additions in terms of
components (for aggregate entity types), perspectives and link types (either incoming or
outgoing).
Although
similar inheritance
mechanisms for link types are conceptually
interesting, we have not found it useful in the applications considered so far.
3.4

Sharing

An attraction of the whole hypertext paradigm is the potential for sharing information.
This is especially important for large corporate applications, which are the main target for
the HYTEA effort, ~YTEA
90] and for HDM in particular.
The current version of HDM allows only the sharing of bodies of units - the unit provides
the reference context (since it is a perspective of a component inside an entity), and the
body contains the actual information.
Consider, for example, the case in where two
different pieces of equipment use the same electric device. Each piece would be an instance
of an entity type, with its internal structure; the structural description
of the electric
device should be duplicated for each instance (as a subtree), and the actual content (i.e.,
text, pictures, etc.) would be shared. This solution is very flexible and safe for the
system, but it puts a heavy burden on authors. It duplicates crucial information
and
creates maintenance problems - for example, if the structural description of the device
changes, all copies that are part of the description of other pieces must also be updated.
Sharing becomes particularly relevant with the notion of aggregate entities. In the basic
HDM model, without aggregate entities, an alternative way to model the example above
would have the two pieces having their own structure, with an application
link binding
each to the shared electric device description (which would be a third entity). Having
aggregate entities as proposed in section 3.2, we would have the electric device as a
Hypertext ’91 Proceedings

324

December 1991

component of the entities describing of each piece. In this situation,
each piece would share the deviee description with the other piece.

the description

of

A second level would be structural sharing: the components of the electric device, their
bodies and, more importantly, the structural links, are shared. Application
links, possibly
connecting components of the eleetric device to other entities (for example, safety rules,
legislation about quality control, assembly procedures, ete.), must be duplicated. There is
less burden on the author and better control on the consistency of the application,
but
there is also more cumbersome bookkeeping,
as well as possible ambiguity
in the
treatment of application links (it is not always clear when they should be shared).
The liberal approach is to allow the sharing of everything, i.e., sharing of components,
bodies, structural
links and application
links. This may create very complicated
situations, and seems to be counter a “principled design” philosophy. Although we do not
have a definitive opinion, it seems that different schemes for sharing should be allowed,
providing the authors a fine grain control about the end result The danger is, clearly, the
possibility that too many options may make the model too complex and unwieldy. From
a technical point of view most of the problems are similar to the problem of sharing of
objects in object oriented approaches, and we will likely borrow the more typical
solutions.
3.5

Active

media

Multimedia
has not been very much considered in the current HDM where text and still
pictures are the basic concern; only recently we gave a closer look at the problem of
incorporating
other media such as animations,
soundtracks and videoelips.
A full
discussion requires a full paper of its own and is beyond the scope of this paper, (see
Paolini 91]) so we will comment briefly.
The basic difference between these new media and the old ones is that they are active, in
the sense that the contents perceived by the reader changes without her intervention.
A
simple way to deal with active media in HDM is to consider them as new types of bodies,
without
modifying
anything
else. With this solution,
for example,
one of the
perspectives
of an entity describing
a repair procedure could show a video clip,
synchronized with a sound track. From the Hypertext point of view the movement of the
video clip, with possible interactions of the user (e.g., the usual manual controls of a
VCR) would be invisible. In other words the actions of the video would be considered as
happening “in the small”, and therefore not a concern of HDM. This solution, which
satisfies the requirements of many applications, does not require any major modifications
of HDM.
Still, there are applications where a more sophisticated solution must be found. Consider
a typical “musical”
application:
a sound track is associated to several chunks of text,
describing musical notation, critical comments, historical notes, etc. Typically the reader
can look at a piece of text, and cause the associated piece of music to be played. This can
be easily described with the previous simple solution.
The reader, however, can also play the music, stop it at an arbitrary
at the corre~ponding

chunks

of text.

The

text

to

be

shown

point, and take a look

changes

according

to

position where the music was stopped. What has happened is that the active medium
changed the “locus of activity” in the hyperbase.

the

has

To model these types of applications,
introducing
the minimum
amount of ncw
primitives,
we are taking the following
approach. The bodies of active media units are
deseribed abstractly (for example, as objects); I+DM should not be conccmcd with the
editing of active media objects, which belongs in the realm of authorirtg-in-the-small.
The
Hypertext ’91 Proceedings

325

December 1991

dynamic behavior of an active media unit can be mapped to a guided tour, which has been
“automated”:
the tour advances automatically,
without reader requests. Every advance of
the guided tour changes the relevant position in the hyperbas~ when the user issues some
request (presses some button), the tour is interrupted, and the context is switched - the
reader is placed in the hypertext environment associated to the point of the guided tour,
and the usual navigation operations become available.

4

CONCLUSIONS

We are aware of several other improvements in HDM, which will be addressed in the near
future we mention them briefly. It is useful to be able to specify, at the schema level,
some overall structural pattern that entity type instances must follow (a la SGML, for
instance). For example, it might be useful to say that “Law” entity type instances all
have a common format, for example, that the first component sub-tree is always of type
“Introduction”,
followed by a variable number of sub-trees, of type “Section”. Allowing
such distinctions permits for example automatic generation of navigation links such as
“link first the Introduction, then each Section”.
Different hyperviews of the same hyperbase can allow the adaptation of the application to
particular situations (user profiles, tasks, etc.). We have implemented
them in several
applications, but we do not have yet a good model to describe them in a general fashion,
independent from specific applicative situations.
Our approach assumes that the problem of controlling
in detail the layout should be left
to targeting activity, i.e., the tailoring of an application to a specific target environment.
There are several reasons for this, among which the fact that the actual alternatives are
very much dictated by the software and hardware
technology
available
for the
implementation.
There are nevertheless conceptual issues about the layout (i.e., what
must be displayed in parallel, which anchors should be perceived by the reader and how),
that probably should be incorporated in the HDM description.
HDM is an evolving
model, requiring
experimentation
with a large number of
applications before reaching maturity. Although still in its infancy, it has been used to
model several existing applications, as well as to develop several new ones. It has proved
to be adequate for most cases, and has&n
adopted as a communication
language among
members of the HYTEA project for describing applications.
When used by computerilliterate persons, it has greatly enhanced their ability to generate successful hypertext
applications, according to their own observations.
HDM provides a model in which to describe hypertext applications, and also induces a
methodology for hypertext design, based on a top-town, model-based approach. Even if
this methodology is not followed, HDM can still be used. Practical experience has shown
that (as occurs in “structured programming”),
development proceeds mostly top down, but
at certain points bottom up steps are performed, occasionally requiring revision of (topdown) design steps. For example, sometimes unforeseen application link types spring up
at the authoring-in-the-small
phase, requiring
changes in the HDM schema, so
development ends up being an alternation of authoring-in-the-large
and authoring-in-thesmall. This is regarded as a natural and desired occurrence of the design process, and in no
way “contradicts” the HDM philosophy.
Clearly, HDM is not in competition with any of the current Hypertext tools, but rather a
complement that should allow a more effective use of them. We would like to move into
the much needed discussion on modeling and style issues for hypertext applications, and
HDM is a first step in this direction.

Hypertext

’91 Proceedings

326

December 1991

ACKNOWLEDGEMENTS
Many ideas described here benefited from discussions with Mark Bernstein of Eastgate
Systems, Inc., with Norman Meyrowitz
of IRIS, Brown University,
and with John
Mylopolous,
Computer Science Dept., University of Toronto. Norbert Streitz of GMD,
Germany, suggested the global structuring of applications.
As part of the group that
developed HDM, we also acknowledge
the contributions
of Andrea Caloini, Stefano
Mainett.i, and Sergio Danieluzzi. The HYTEA consortium has made many suggestions for
improvemen~,
it is formed by: Siemens (Munich, Germany) - prime contracto~ GMD IPSI (Darmstadt, Germany); Epsilon (Athens, Greece); Systems & Management
and
Politecnico di Milano (Milano, Italy); and Olivetti (Pk. Italy).

REFERENCES
[Akscyn

88]

[Brown

89]

Brown, P.J.; “Do we need maps to navigate round hypertext documents?”,
Electronic Publishing - origination,
Dissemination
and Design 2,2 (July
89).

[Brown

90]

Brown, P.J.; “Assessing the quality of hypertext documents”, in A. Rizk,
N. Streitz, J.Andrt$, eds, Hypertext: Concepts, Systems and Applications
- Proceedings
of the First European Hypertext
Conference,
INRIA
(France), Cambridge University Press, 1990.

[Garg 88]

Garg P.K., “Abstraction
(7), July 88.

mechanisms

in Hypertext”,

Comm.

ACM,

31

[Garzotto

90]

Garzotto F.; Paolini P.; Schwabe, D.; “HDM - A Model Based Approach
to Hypermedia
Application
Design”.
Technical
Report
90-75,
Dipartimento
di Elettronica,
Politecnico
di Milano,
Nov.
1990.
Submitted for publication to ACM - TOIS.

[Garzotto

91]

Garzotto
F.; Paolini
P.; Schwabe, D.; Bernstein,
M.; “Tools
Designing
Hyperdocuments”,
Chap.
13, Hypertext/Hypermedia
Handbook, J. Devlin, E. Berk, eds., McGraw Hill, 1991.

for

[Halasz 88]

Halasz F., “Reflections
on NoteCards:
Seven issues for the next
generation of hypertext systems”, Comm. ACM, 31 (7), July 88.

[Halasz 90]

Halasz F., Schwartz M, “The Dexter Reference Model”,
Hypertext
Standardization
NIST Workshop,
Gaithersburg,
1990.

Proc. First
MD, Jan.

[HYTEA

90]

HYTEA

III.

[Marshall

89]

Marshall, C. C.; Irish, P.M, “Guided Tours and On-line Presentations:
How Authors Make Existing Hypertext Intelligible
for Readers”, Proc.
Hypertext ’89, ACM, Baltimore, 1989.

[Paolini

Hypertext ’91 Proceedings

D. L. Yoder, E. A.; “KMS:
A Distributed
Akscyn, R.; McCracken,
Hypertext System for Managing Knowledge in Organizations”,
Comm.
ACM, 31 (7), July 88.

91]

Technical

Annex, Esprit II Project P-5252, CEE-DG

Paolini, P.; Garzotto, F.; Caloini, A.; “Active Media in HDM”, technical
Report 91-18, Dipartimento
di Elettronica, Politecnico
di Milano, Mar.
91.
327

December 1991

88] Raymond, D.R; Tompa, F. Wm., “Hypertext
Dictionary”,
Comm. ACM, 31 (7), July 1988.

maymond

Schwabe,
D.; Caloini,
A.; Garzotto,
F.; Paolini,
P., “Hypertext
development using a model-based approach”, Technical Report 90-74,
Dipartimento
di Elettronica, Politecnico di Milano, Nov. 90. Submitted
for publication to Software, Practice& Experience.

[Stotts

Stotts, P.D.; Furuta, R., “Petri-Net-Based
Hypertext
Document Structure
with Browsing Semantics”, ACM Transactions on Office and Information
Systems, 7(l), January 1989.

89]

89]

[Zellweger

Permission
direct

to

commercial

title

of the

that

copying

without

@ 1991

ACM

Streitz, N.A.; Hannemann, J.; Thtiring, M.; “From Ideas and Arguments
to Hyperdocuments:
Traveling
through Activity
Spaces”, Proceedings
Hypertext’89,
1989.
89] Zellwerger,
Mechanism”,

all or part

of this

are not made

the ACM

and its date

is by permission

specific

fee

the copies

advantage,

To copy

and/or

Hypertext

that

publication

Machinery.

View publication stats

copy

provided

English

[Schwabe 90]

[Streitz

granted

and the Oxford

and

of the Association

otherwise,

material

or distributed

copyright

appear,

P. T., �