HDM â A Model-Based Approach to Hypertext Application Design . 3 too much regard to âimplementation detailsâ; and it can be used as a communication.
HDM — A Model-Based Approach to Hypertext Application Design FRANCA GARZOTTO, Politecnico
PAOLO PAOLINI,
di Milano
and DANIEL SCHWABE Pontiffcia Universidade
Hypertext the
development
case
of large
suggests
the
overall without
should
and
notion
classes
Cat61ica do Rio de Janeiro
much
concern
with
model
for authoring-in-the-large.
HDM
access
links)
specifications for
different
and
of existing designing
advantages
the
definition level
Categories
and
Subject
Applications]:
roles;
of HDM
the
The
purpose
are: the notion
links,
application
distinction
of
applications
a general
of
links,
hyperbase
between
structure
of a hypertext
As an implementation
can be derived
and
Office
the
application
development. of hypertext
device, One
from
it is the
of the
applications
automatically
central
is that
the
a conceptual-design
are also included.
H.2. 1 [Database
Storage
description manner.
defining
(structural
integrating
construction
of HDM
Descriptors:
[Information
Systems
of links
of usage
the
of complex
features
of links
applications. support
and practical
number
allows
in
HDM can be used in different manners: as a modehng As a modeling device, it supports producing high level
directly
in the design
Examples
models; H.3.4 tion
that
of a significant
description.
semantics. device.
development
in a system-independent
innovative
of easily
especially
to hypertext rge
step towards
representational
possibility
development,
structures
and
a first
categories
or to-be-developed
tools
of HDM
details,
Some of the most
with
structures;
navigational
Model),
of different
application with its browsing device or as an implementation basis
Design
approach
Authoring-in-the-la and
implementation
(Hypertext
structured
A structured
elements
the identification
perspective
and
a systematic,
of authoring-in-the-large.
presents
and
from
applications.
of information
paper
perspective;
benefit
complex
Management]:
Retrieval]:
Automation;
Systems 1.7.;
[Text
and
Logical Software;
Design—data H.4. 1 [Informa-
Processing]:
Miscellaneous—
hypertext General
Terms:
Additional
Key
applications,
This
Design, Words
work
Project leave
addresses:
Piazza
Leonardo
email:
garzotto@iipmel
form~tica,
from
de
not made
HDM,
by the Commission
Hypertext
design
supported
and P. Paolini,
l.polimi.it; Universidade Brasil.
Milano,
Department
Italy.
paolini@ipmell. Cat61ica Phone:
of the European
II Program.
and was partially
32,20133
Janeiro,
links,
of the ESPRIT
F. Garzotto
da Vinci
pucrjditi!inf.puc-rio. Permission
PUC
Derived
models,
Hypertext
models
in part
(P 5252)
Pontificia Rio
Phrases:
structures,
was sponsored
on sabbatical
22453,
and
Hypertext
of the HYTEA Authors’
Languages
Phone: polimi.it;
do Rio
developed
in the scope this
work
while
by CNPq-Brasil. of Electronics,
Politecnico
+ 39-2-23993520; D.
de Janeiro,
+ 55-21-274
Communities,
D. Schwabe
4449;
fax:
Schwabe: R. M. fax:
di Milano,
+ 39-2-23993411;
Departamento
de S. Vicente, + 55-21-274
de In225,
4546;
CEP email:
br.
to copy without or distributed
of the publication and its Association for Computing specific
permission.
01993
ACM
fee all or part
for direct
date appear, Machinery.
1046-8188/93/0100-0001 ACM Transactions
of this
commercial
material
is granted
advantage,
the ACM
provided copyright
and notice is given that copying To copy otherwise, or to republish,
that notice
the copies
are
and the title
is by permission of the requires a fee and/or
$01.50 on Information
Systems,
Vol. 11, IWO. 1, January
1993, Pages 1-26.
F
2.
Garzotto
et al.
1. INTRODUCTION 1.1 Background The
degree
author’s matter
of success
ability
of a hypertext
to capture
in such
a way
and
application
organize
as to render
the
it clear
is directly
related
structure
of a complex
and accessible
to a wide
to the subject
audience.
To control the potential explosion of the number of links, a hypertext application does not really interconnect everything, but rather tries to directly interconnect only the most important and meaningful parts of the information so as to convey the overall meaning in a more natural In a rational design approach, a hypertext application least
two
different
such
as defining
(but
strongly
overall
correlated)
classes
task
way. developer
categories:
of information
elements
faces
“global” and
at
tasks,
navigational
structures of applications, and “local” tasks, such as filling in contents of nodes. This is very similar to what happens when developing a highly modular software system: designing the topology and the interconnections among modules is different from writing the code for the content of modules themselves. By analogy with software engineering, we use following terminology: authoring-in-the-large, to refer to the specification design of global and structural aspects of the hypertext application, authoring-in-the-small,
refer
to
nodes [16, 17]. Authoring-in-the-small area,
while
different is
to the
is very
much
authoring-in-the-large
applications
strongly
in a given
dependent
on
the
development
has
related
tools
to
common
application used
of the
specific
characteristics
domain. for
the
contents
the the and and
of the
application across
many
Authoring-in-the-small
implementation
and
on
the
medium used for storing information (e.g., putting the text in a node is much different than putting an animation, or a sound, or a picture). Authoring-inthe-large can be at some extent independent from these aspects. However, authoring-in-the-large and authoring-in-the-small are typically very interwoven,
and
influence
each
other,
much
more
than
programming-in-the-large
and in-the-small in the current software engineering practice. This paper presents a model for authoring-in-the-large, named Hypertext application
HDM—
Design Model [16, 17, 18, 36]. HDM prescribes the definition of an schema, which describes overall classes of information elements
in terms of their common presentation characteristics, their internal organization structure, and the types of their mutual interconnections. A schema, therefore, captures semantic and structural regularities in the representation structures for a given class of applications. Once a schema has been specified, the model also allows it to define a particular application, by providing primitives to describe a schema instance, i.e., actual instances of information classes and of connection types. In defining a schema instance, a significant number derived HDM
of connections can be left implicit, since they can be automatically from a conceptual-design level description. is mainly a modeling device. It provides ways of describing, concisely
and in a system independent manner, existing applications; it helps the author to conceptualize ACM
Transactions
on Information
Systems,
Vol
or to-be-developed a given application
11, No. 1, January
1993
hypertext without
HDM — A Model-Based Approach to Hypertext Application Design too much
regard
communication Additionally, hypertext
to
“implementation
language HDM
between
can be used
applications
step towards
[26,
36].
the development
details”; designers,
and
to generate
From
it
can
implementors, perspecl;ive,
of application
generators,
specifies
properties
dynamic
behavior HDM
and visualization
is not
closed
semantics. So far, we have suitable for relatively simple
1.2 Current Approaches In
the
crucial
very
closely
related
as means (“logical”
data
base
the
hypertext
semantics tion is
structures
storing,
and
express
as
representa-
particular
browsing more
Design
design
field,
models task
from
inconsistent) activity into becoming on well defined design methods [46].
field,
some
have
played
being
a “hand-
a
a structured and Database models
reflect
tool
for
retrieving
domains
such “deep”
exploratory the
attempt
semantics.
amount design
to explicitly
by adopting
policy
large
of a system
semantics of its domain process and by providing
and “semantic” data models [6, 211). (e.g., the role of links, the complexity the navigation paradigm, etc.) require specific for peculiar features of hyper-
approaches
application
which
the rationale
way
to define useful abstractions on large amounts of raw data models) and to express the intrinsic application
of specific
a hypertext
of
Implementation semantics, which
of HDM
to any
base development
oriented data semantics (“conceptual” However, the peculiarities of hypertext of structures, the multimedia facility, the development of brand new models, text. In
a
is a first
specified a default browsing semantics, card-oriented classes olf systems.
the data
(and sometime process, based
were born information
respect
to Hypertext Application
role in changing
crafted” rational
with
model
in a similar
environments. of a browsing
structures.
as
implementations the
CASE tools are used in software engineering of an HDM application requires the definition tion
used
3
and users.
running
this
be
.
g-IBIS
discussion. of informal
process.
by assuming a well a set of specific node
model
predefine
g-IBIS
[11], It
for example,
helps
capturing,
information explicitly
defined theory and link types
the
representa-
which
models
the
of the design that represent
conceptual objects in the domain model. Thus g-IBIS encourages model while seeking to discourage less disciplined argumentation
to share this modes.
Other works should be regarded more as “system” oriented models than as application oriented design models. They are attempts to define in an unambiguous, rigorous way some important abstractions found in a wide range of existing (and future) systems rather tions. The goal of the Dexter Hypertext standard against which to compare structures
and the functionalities
blocks
defining
for
the
static
than of existing (and future) applicaReference Model [20] is to serve as a and contrast the static information
of different aspects
hypertext
of a hypertext
systems. system
Its building are
low
level
objects: nodes, links, and anchors. The Dexter model purposefully does not model the content and structure within the components of hypertext netproperties, as works. It treats them, as well as their layout and visualization being outside the model per se. Garg’s set-theoretical model [14] is a formalization of hypertext networks viewed as static, syntactic structures, and ACM TransactIons
on Information
Systems,
Vol. 11, No. 1, January
1993.
F, Garzotto et al,
4.
provides
a mathematical
to describe
or derive
model
other
(as
framework static
similar
to define
syntactic ones
abstraction
properties
[35])
mechanisms
useftd
networks.
Garg’s
of hypertext
assumes
low
level
objects
as building
blocks, such as nodes (and even node components), and node-to-node links. The Trellis model [39] is mainly a “behavioral” model for hypertext. Hypertext networks are modeled as Petri nets, and various browsing semantics (that is, how information computations. Tompa
[41]
adopts
is to be visited) a hypergraph
are discussed
formalism
in terms
to model
of Petri
generic
nets
hypertext
structures, to formalize identification of commonalties in these structures, and to directly refer to “groups of nodes” having a common link semantics. A dynamic behavior is also specified through the notion of node markings, with an end result Other,
much
similar
less formal,
to the Trellis
approaches
model.
emphasize
preferred
topological
structures
as building blocks to create the structure of hypertext networks. This requirement is often embodied in a concrete system implementation, and enforced by the editing tools the system provides. In Hypercard [3], for example, linear structures ily linked
play a central organization role. Even if each card can be arbitrarto any other card, each Hypercard node must belong to a sequence
(“stack”) of cards, and links to the successor node, to the first and the last node in the sequence are automatically provided by the system. Guide [7] also prescribes
the extensive
hyperdocuments. tures
use of linear
KMS
to organize
[2] prescribes
information,
design of hyperdocuments. hierarchy; however, KMS cal and induce Several generate authors number
a more
existing hypertext to create of common
require
[19].
to clarify
in order
the organization
use of hierarchical
to encourage
a top-down,
complex
topology provide
on the network “template”
step-wise
of nodes.
facilities
to help
designers
structures more easily and systematically, by allowing multiple copies of individual structures all sharing a properties. HyperCard, for example, has “backgrounds” template. and shared
The lay-out and button properties by all the different nodes sharing
NoteCards’ notion of (hierarchy of) node types create as many instances of a class of hypertext Object
of
struc-
Each KMS node (frame) belongs to a single also allows “special links” that are cross-hierarchi-
approaches
as the lay-out and linking background are inherited background. lets writers
structures
the extensive
Lens
[28]
encourages
a similar
style
of a that
and link types nodes as they
of node
creation,
by
providing an object-oriented environment which allows definition of templates corresponding to high-level abstractions in an application domain. IDE [27],
an
extension
of
NoteCards,
is
an
interactive
design
and
development
system which assists designers with the process of creating complex hypertext material, mainly (but not only) for instruction purposes. IDE provides built-in representation primitives for describing the substance of a course and the rationale for the course design in terms of hypertext structures. IDE moreover, provides a number accelerators”) that facilitate work patterns in hypertext nodes ACM
and links
Transactions
in a single on Information
of domain independent the rapid and accurate by permitting authors operation.
Systems,
Vol
The template 11. No. 1, January
mechanisms (“structure creation of regular netto create entire webs of facility 1993
in Intermedia
[38,
HDM —A Model-Based Approach to Hypertext Application 48]
a similar
role
introduce
plays
the
of style
browsing
Trellis-based
different elements
notion
structure
templates
hypertext.
accelerators.
to denote
Different
Stotts
styles
style
.
et
al.
of structuring
templates
5 [40] and
correspond
to
translations from generic authoring notations of hypertext content and linkages into structured Trellis documents with a specific
browsing behavior. mars (the authoring Trellis
as IDE
Design
Translations are basically mappings from language) to graph grammars (the abstract
string-gramlanguage for
documents).
Other material.
approaches help Trigg’s Guided
extensions
of NoteCards
to organize and modularize existing hypertext Tours and Tabletops [29, 42], for instance, are
which
help
designers
hypertext material in a way that it reader, and to provide preferred paths The remainder
of the
article
is divided
advantages of the model-based presents HDM in detail; Section
to groulp
is more through
and visualize
appropriate a hyperbase.
as follows:
for
Section
existing
a particular
2 discusses
the
approach to authoring in the large and 3 gives an example of HDM use in hypertext
application design; Section 4 draws the conclusions, by comparing HDM to other approaches, by evaluating the model’s utility on the basis of a number of experiences
done so far,
2. A MODEL-BASED
and by outlining
APPROACH
our future
work.
TO AUTHORING-IN-THE-LARGE
2.1 Motivations There tions,
are many which
advantages
Improvement which Thus
of
it facilitates the
a design
A
by an application and
the
design
analyst
the communication
analyst
model
for hypertext
mode-l
provides
applica-
here.
communication.
can be used
between
in having
we summarize
between
system
to specify
a given
the analyst
designer;
and
a language application.
and the end user;
between
the
system
designer and the implementor. At the very least, a basis for discussing the similarities of hypertext applications exists. To paraphrase Halasz et al. [20]: Hypertext Application Models can be regarded as an attempt to provide a principled
basis
for answering
questions
tions such as Voyager’s Beethoven’s Perseus [30], ACM’s compilation Elections
of 1912
[4], have
Development of design els provide a framework
such as “what
9th Symphony Hypertext for
in common?”
methodologies in which the
“How
do hypertext
do they
differ?”
and of rhetorical styles. Design authors of hypertext applications
develop, analyze, and compare methodologies and rhetorical styles authoring”, at a high level of abstraction, without having to resort at the detailed izations. Reusability. paves
the way
contents
of units
As a matter for (partial) ACM
of information
of fact, reuse
or at their
the
availability
of the
back-bone
Transactions
applica-
[47], Harvard University’s Hypertext [37], Eastgate’s
on Information
particular
of a modeling structure
Systems,
modcan
of “hyperto looking visual-
language
of applications,
Vol. 11, No. 1, January
1993.
6.
F, Garzotto et al.
since model-based
specifications
tions, and can therefore similar enough. Providing that
consistent
tools
for
structural tion
and
specifying
to a model
structures.
the semantics
predictable
result
[8],
in very
a consequence,
predictable, thereby ing the disorientation
reading
semantics”
can
help
and that
consistent
It
environments
clear
to
applications
complex
are
is
authors
avoid
developed
and predictable
navigation
helping readers to master problem [31, 33, 43].
of applica-
of two applications
en vironrnents.
structures
and mistakes
will
As
the “essential
when
hypertext
inconsistencies
according
capture
be reused
representawill
documents
also
be
and reduc-
Use b-v design tools. Design models are the basis for the development of Design Tools [45] that support a systematic, structured development process, allow
the
designer
to work
application domain, and implementation level.
at a level provide
of abstraction
a systematic
which
is closer
translation
to the
process
to
the
2.2 HDM Primitives HDM
is
a model
to
describe
hypertext
applications.
It
has
a number
of
peculiarities that make it overall different from other models, but at the same time borrows many of its detail features from existing models. From a terminological set
point
of brand
new
of view, terms
for
we had
two
all
features
the
extreme
choices:
of the
either
model,
to create
or to use
a
only
preexisting terms (and concepts), perhaps reassembled in a novel fashion. We have chosen a compromise course: some of the terms are new, others are taken from preexisting models in the database or hypertext field. Preexisting terms
should
be understood
assume
that
already
aware
An HDM
with
our use of the term
the
caveat
exactly
that
corresponds
the
reader
should
to the notion
never
that
he is
of.
application
consists
of sizeable
called entities. An entity denotes domain. Entities are grouped in
structures
of information
chunks
a physical or conceptual object of the entity types. An entity is the smallest
“autonomous” piece of information which can be introduced or removed from an application. In this context, “autonomous” piece of information means that its existence is not conditioned by the existence of other information objects. In HDM, only entities are autonomous, while components and units (see below) are not, as discussed in the following sections. Components are in turn made of An entity is an hierarchy of components. units. Each unit shows the content of a component under a particular perspective (see proper subsection for details and examples). Entities therefore derive their information content from their components, which in turn derive it from their units. Units are the smallest chunks of information which can be visualized in an HDM application, and they have a lot in common with the standard notions of hypertext “nodes.” HDM information structures can be interconnected by links. HDM distinguishes ACM
among
Transactions
three
categories
on Informatmn
Systems,
of links.
Structural
Vol. 11, No. 1, January
links 1993.
connect
together
HDM —A Model-Based Approach to Hypertext Application Design components
belonging
the different denote
units
to the same
that
arbitrary,
entity.
correspond
domain
Perspective
links
connect
to the same component.
dependent
relationships
. together
Application
and connect
7
links
together
com-
ponents and entities, of the same or different types, in arbitrary patterns set up by the author. Application links are grouped in link types. All perspective links,
and most
author,
structural
since they
links,
do not
can be deriued
need
to be defined
automatically
from
explicitly
the structure
by the
of entities.
Some application links can be derived by exploiting semantic properties (e.g., symmetry and transitive closure) of the corresponding domain relationships. As any other design notion of schema and collection
of type
model, HDM makes a clear distinction between the notion of instance of a schema. A schema
definitions
that
describe
an instance of a schema is a collection links that satisfy the definitions of the tures,
provide
structures A
reader-oriented
in an instance
browsing
entry
an application
at the
global
points
to
directly
access
information
of a schema.
semantics
has
the
purpose
of
specifying
how
different browsing semantics however could be defined, sophisticated visualization effects for applications specified
2.2.1
Entities
and Entity
domain;
which
a law
Traviata”),
(say
a piece
entities. Entities
Types.
represents “Law
of the real
information
grouped world.
The
most
and
the
notion
as a suitable popular several
of entity
We should
other
of the
a musical
Opera
(say
model,
engine”)
types,
“Musical related the
could
which
Opera”
notion
to model
related
and entity
warn
the
notion
design
olbject
in entity
“Law”,
derived
of entity
from
structure
Verdi’s
type)
in the
of
to classes could
is commonly
data
(E-R) it,
“La
be examples
correspond
information
more
application
and “Equipment”
Entity-Relationship
models
large)
world
(say “electric
across them. as built-in;
to describe with HDM.
is a (relatively
real
19/8/89”),
be examples of entity types. The notion of entity (and recognized
An entity some
of equipment
are naturally
of objects
level;
of entities, components, units, and schema. Outlines, i.e., access struc-
structures are visualized to the reader, and how he can navigate HDM provides a relatively simple default browsing semantics
of information
the is a
base field. model
are based
upon
[10], the
class.
the reader,
however,
that
although
we have kept
the term
and the basic nature of the concept of Entity, in practice HDM entities are very different from E-R entities. For example, HDM entities have complex inner structures (with links inside, see Subsection 2.2 .7), while E-R entities are essentially flat; HDM entities have a (default) browsing semantics associated with application those
2.2.2
them (see Subsection links (see Subsection
allowed
by relationships
Components.
in a tree-like
fashion
via than
in the E-R model.
An HDM (ordered
2.4. 1); HDM entities can be interwoven, 2.2.8), in patterns much more complex
entity
is a collection
hierarchy).
ACM TransactIons
of components
A component
on Information
Systems.
arranged
is an abstraction Vol. 11, No. 1, January
for a 1993.
F. Garzotto et al
8. set of units
(see Subsection
tion, and hierarchy, siblings for the tity
2.2.4),
which
are the actual containers of informabeing part of a its units 1. A component, (but for the root component), a number of
derives its content from in general has a parent
(which are arranged in a linear leaf components). Components
and
can
only
exist
as part
order) and a number of children “inherit” their type from their
of an
entity;
in
this
sense,
they
(but en-
are
not
autonomous. Examples of components, for the entities introduced in the previous subsection, could be “Article 1“ (component of “Law 19/8/89”), “Article l—Subsection
1.2”
(child
of “Article
Traviata”), “condenser” Many authors have orientation
when
1“ component),
“Ouverture”
(component of “electric observed that hierarchies
navigating
in a hypertext
(component
engine”). are very
[1, 7]. HDM
useful
of “La
to help
recognizes
user
this
via
the notion of entities made up of components organized into hierarchies. Hierarchies can be induced by many semantic criteria (i.e., domain relations). The “Is-part-of” relation, for example, is one of the most commonly used. HDM, however, ture of different In HDM, regular
does not acknowledge the (possibly) hierarchies, since it is not intended
a hierarchy building
is a purely
blocks
within
syntactical
device
a (possibly
large)
different semantic nato be a semantic model.
to organize
information
in
application.
2.2.3 Perspectives. In hypertext applications it is often the case that the same topic must be presented in several alternate ways. There are several different reasons why this need may arise. In multinational applications, for example, the same topic must be represented with different languages (e.g., Italian, Portuguese, English, etc.). In educational applications, it may be useful to present the same topic using different rhetorical styles (e. g., discursive, synthetic, schematic, . . . ), according to different needs of the readers. In recent applications, very often different media can be used for presenting the same piece of information In HDM
this
is captured perspectives components
notion
(text, of having
graphics,
image,
different
presentations
by the concept of perspective. (say “Italian” and “English”, belonging to it also have two
perspectives are shared at entity type level. Perspectives are just
video,
sound,
etc.).
for the same content,
If an entity has two possible or “Score” and “Sound’), all the possible perspectives. The set of
by all entities
of a given
a syntactical
device
entity
to organize
type,
and are defined
information.
HDM
does not acknowledge any predefine semantics behind this concept, and does of not interpret it. Tbe author has to decide when and how to use the notion perspective, and what is its intended meaning. HDM only prescribes consistency in using the same type.
the different
ways
for presenting
information
in entities
.— 1 For model entities
ACM
slmphclty,
cannot
TransactIons
be used
and
also because
as components
on Information
we have of other
Systems,
Vol.
verified
that
so far we do not need the feature,
entities
11, No
1, January
1993
of
HDM —A Model-Based 2.2.4
Units.
perspective. Bodies
of units
is filled ata”), “Law
A unit A unit
corresponds
in. “Ouverture/sound”,
English-text”,
“assembly
roughly
notions
the actual
(its
to relate
speaking,
of “nodes”.
entity
may
(of the
This
can be created
HDM
units
in the
are
to traditional
“La
instruc-
examples
true;
are
the
is purposefully
border-line
outside
between
standard
for example,
(of components
the
scope of HDM.
and
Therefore
authoring-in-the-large
and
of
notions,
to the
entities,
under the proper perspectives), and arbitrary nodes are not allowed Filling in a body, corresponds to authoring-in-the-small (in our ogy), which
Travi-
hypertext
completely
context
a body.
application
entity
Engine”),
is not
proper
9
Text” (of the entity “assembly instruction/
as corresponding
correspondence
only
a specific
and
“assembly
“Electric
be thought
with
of an HDM
instruction/Italian-graphics”, the
.
identifier)
content
“ Ouverture/score”
(of
Design
associated
by a name
I/Official Text”, “Article I\Annotated “assembly instruction/Italian-text”,
tion/ English-~aphics” units. If the reader tries units,
toacomponent
is characterized
are the place where
“Article 19/8/89”),
units
Approach to Hypertext Application
in HDM. terminol-
HDM
units
authoring-in-the-
small: identifying the units and putting them in the proper context belongs to authoring-in-the-large; filling the bodies of units with actual content is authoring-in-the-small. In HDM, different units are allowed to share their body. This is, methodologically that
the
speaking, same
contexts, tionally, often,
and
have
simplify expense
2.2.8).
is a typical verified Still
acknowledged
in HDM;
can be accessed
a poor design
Subsection we
this
we have from
not encouraged
content
source
that
the
that,
for
sharing the
some
applications,
the application specification of clarity for the reader).
of bodies
mutually
for
the
notion
for the
reader.
Addi-
of bodies
arises,
quite
of body
designer
implies
exclusive)
and a bad use of application
introduced in
(not
of disorientation need
of the schema we have
in fact, sharing
in different
links
sharing
a good
use
(but
at the
(see since
of it
can
possible
2.2.5 Links in General. Links in hypertext have a twofold role: a representational role (i.e., capturing domain relations) and a navigational role (i.e., capturing navigation patterns). Sometimes these two different purposes are consistent that
domain
tion
patterns
with
each
relations that
other,
sometimes
are not suitable
are not relevant
they
can be at odds.
for navigation,
for an
i.e., they
aPPliCatbIIl,
while,
It may
happen
induce
naviga-
on the contrary,
useful navigational links may have vague semantic meaning. Definition of links is therefore a trade-off between representational and navigational goals. However, the more the meaning of a link is made explicit and approximates a relationship of the application domain that a reader is aware of, the more the same reader will be at ease in using the hypertext, since links will evoke familiar associations. HDM is not intended to be a semantic model. However, HDM acknowledges three categories of links: perspective links, structural links, and application links. The distinction among the three classes simplifies the job of the
ACM
TransactIons
on Information
Systems,
Vol. 11, No. 1, January
1993.
10
.
F. Garzotto et al.
application
designer,
predictable additional definition
induces
a consistent
2.2.6 Perspective Links. ing to the same component. units
“assembly
graphics”,
activating attention)
allowing operation links are
2.2.7 Structural
link
There to
leaves
links,
creates
more
child
the current
links different
induced links
the text
description
topic
(i.e., the reader’s
connect
components
structural
by
the
are “Up”,
belonging
links,
ordered
each
tree
connecting
focus of
to
of them
structure
a component
of to its
a component to its children, “Down-l”, connectchild, “Next-sibling”, connecting a component to
of the same father,
root of the tree, and so on. Structural links can be used belonging
instruction/Italian-
from
(in Italian) that schematizes it. very simple for the reader, since
several
connecting to its first
interconnect units correspondwill connect, for instance, the
to switch
Structural are
of structural
parent, “Down”, ing a component
information
reader
a relationship
Examples
the following
links links
to the picture navigationally
Links.
entity.
corresponding entities.
of most
and “assembly
an Italian
a perspective unchanged.
same
Perspective Perspective
instruction/Italian-text”
thus
of an assembly Perspective
the
use
navigation patterns, and finally makes it possible to introduce features such as derivation of links (see Subsection 2.3) and of a default browsing semantics (see Subsection 2.4.1).
to the
“Root”,
by the
same
connecting
reader
entity.
a component
to navigate
among
Navigationally,
they
to the
chunks are
of
a little
more complex than perspective links, but they are still quite simple, since they leave the reader inside the same information context, i.e., the same entity, with limited danger of getting lost. In the worst case the “Root” link can always
2.2.8 most
take
the reader
Application
expressive
dependent
Links portion
to a safe point and Link
(i.e., the root
Types.
of any non trivial
relationships
among
entities,
ships are chosen by the author relevant. Application links are organized
into
Application hypertext;
or their
as both
of the entity). links
they
components.
navigationally
types.
An
represent
represent These and
application
link
the
domain relation-
semantically type, or link
type for short, is specified in HDM by a name, a set of source and target entity types, and a symmetry attribute, which can assume two values—symmetric or asymmetric. Source and target entity types define what can be linked to what. Once a link type has been defined as having source entity link type are allowed to type A and target entity type B, instances of this connect entities or components of type A to entities or components of type B only.
The
symmetry
type—whether
or
attribute not
each
property can be exploited for Subsection 2.3). An example of application connect entities or components of type ACM
“Musical
TransactIons
Opera”.
on Information
defines link
of
a
that
automatic
semantic type
derivation
has
property an
inverse
of application
of
the link. links
link This (see
link type is “is-author-of”, whose instances of type “Composer” to entities or components
Another Systems,
example
is
Vol. 11, No. 1, January
“is-justified-by”, 1993.
whose
in-
HDM —A Model-Based stances
connect
components The
entities
of type
semantic
given
law
or components or arbitrariness
is particularly
relevant
is completely
left
an “is-author-of’
From that
since
point when
his information
examining
link the truth,
link
to the
link
a navigational
troublesome,
.
11
to entities
If establishing matter-of-fact
for a (portion
judgement. of application
or
he
links
application
is abruptly
While
is
may
of an that a
express
placement the
Opera”
application
traversing
the
can vary,
an
of their
specification
of
type definition, HDM only enforces would not allow, for example, to
a “Musical
of view,
context
a contract.
from
and
By requiring
type
composer deciding
of) contract,
types
author.
source and target entity types in the link syntactic consistency, and therefore it establish
of “Contract”,
of an application
author’s responsibility. to expressing a purely
arbitrary and debatable In HDM, the choice instances
of type
Design
“Law”.
depth
and is left to the opera corresponds
Approach to Hypertext Application
to a “Law”. are typically
links
changed.
the
Assume
navigating
among
the most
reader that
its
perceives
the reader
different
is
parts
(following structural or perspective links), he is always within the same familiar information context. If now he follows an application link of type “is-justified-by”, he will find himself looking at an article of a law and not at the clause of a contract. After having followed a number of application links, the reader might get disoriented by the different information contexts (i.e., entities of different types) he has traversed. We can now reexamine the notion of entity 2.2.9 Entity Types Revisited. type and characterize it in a more precise fashion. All the entities belonging to the same
type
entity
(2) the
type;
body of their application 2.2.10 consists definition
have
units)
certain
features
set of perspectives is presented;
in common:
(1) the name
under
which
(3) the types
of their
their
of the their
content
outgoing
(i.e.,
the
and incoming
links. HDM Schema. An HDM specification of a hypertext of a schema definition and a set of instances definitions. specifies a set of entity types and link types. Instances
to be inserted
in the application
only if they
obey the constraints
application A schema are allowed specified
by
the schema. The
notion
obviously
of schema
derived
schemas started structures, that
from
is relatively the
current
new practice
in
the
hypertext
in the
(in the early sixties) as simple allowed generic operations such
field,
dlatabase
field.
but
it
is
Database
templates, describing file as “find” or “search” to be
performed, independently from structural and implementation details of files. With time these file descriptors have become more complex, incorporating more semantic features. In the hypertext field the evolution seems to start following the same course; developers of applications, who need to perform several times the same operations on complex node/link structures, “templates’’-descriptors of network patterns—are to ensure text,
consistency
however,
[27, 38]. Most
are defined ACM
essentially Transactions
existing
lhave acknowledged useful to save effort
template
on a syntactic on Information
mechanisms basis.
Systems,
Taking
that and
in hyperadvantage
Vol. 11, No. 1, January
1993.
12
F, Garzotto et al.
.
of the
historical
directly
to an
semantic
experience advanced
of the
notion
features
of hypertext
Outlines.
Data
Base
of Schema
field,
that
HDM
is able
applications,
as well
According
to the HDM
terminology,
speaking,
divided
attempts
to go
to represent
as to exploit
some
syntactical
regularities.
2.2.11 tion
can be, roughly
of access structures. The hyperbase represents elements defined in the links of all the categories
the
a hypertext
in two portions:
core of the
applica-
a hyperbase
and a set
it consists
of all the
application;
previous sections: entities, components, units, previously discussed—structural, perspective,
application links. The reader can explore the links defined there. Before he can start this navigation, however,
hyperbase the
and and
by traversing
reader
must
the
have
entry
points to get a view of what the hyperbase is about, and to locate the most convenient starting point. Access structures have the purpose of allowing the reader to properly select the entry points for further navigation. In
HDM,
hyperbase,
so far, which
we have
mainly
represents
access structures,
focused
the most
at the moment,
our
relevant
we provide
attention
portion a unique
explained below. In the Conclusions (Subsection enhancement of this part of HDM is described. Outlines a number
are structurally of restrictions
links.
Differently
have
links
from for
a number
hyperbase.
entities,
nonleaf
however,
components;
of outgoing
Outlines
the For
primitive,
4.4)
current
quite similar to hyperbase entities, and peculiarities that make them
different from entities. An outline is an ordered component (but for leaf components) is connected its siblings, and to its parent (but for the root incoming
on modeling
of any hypertext.
(untyped)
are not typed
outline, for
the
but they have substantially
tree of components. Each to its child components, to component), via structural
these
are
additionally, links
the work
the
only
leaf
components
to entities
outgoing
or components
and are not specified
or m z{st
of the
in the schema—they
can be freely added or modified, at will, in an application, in order to provide the appropriate entry points for the reader. An outline for applications in the legal field, for example, provides an Laws”, or “National access to “European Laws” in the root component. Selecting “National Laws” corresponds to traversing a link to a component where a further choice is presented among different categories of national laws—say, for example, “Laws concerning real estate sale”, “Laws concerning etc. There is an outgoing link for each of the above categories of donation”, laws;
each one of these
links
of links to specific entities example, “Law 10/21/87”,
2.3
Derived
Links
One of the central tion ACM
of hypertext Transactions
points
and Derived advantages applications
on Information
to a leaf component,
which
of type “Law” of the selected “Law 3/5/75”).
has a number
subcategory
(say, for
Link Types of HDM is that
Systems,
Vol
in the design defining
and practical
a significant
11, No. 1, January
1993,
number
construcof links
HDM —A Model-Based can
be
left
Approach to Hypertext Application
implicit—being
model—or
can be defined
conceptual
level,
induced
from
intentionally
the author
structural
and
needs to provide
automatically
from
the
schema definitions. All perspective links can be left from the definition of components “score” will
and “sound”
are defined
be generated
connecting the under “sound inverse
for
each
unit of the perspective
design
.
properties
algorithmically
derived.
a much
number
smaller
than the number of links that will actually be present the proper interpreter is provided, all implicit or generated
Design
level
of
the
At
the
of links
in the application; once derivable links can be
description,
by
using
an entity
minimal
set
ordered
implicit and can be automatically derived and units. For example, if perspectives
for entity
type
component
“Opelra”,
of an
two perspective
entity
of this
component under “score” of the same component;
type:
links
the
first
perspective to the unit the second being the
is equivalent
of “basic”
hierarchy
to defining
structural
links
relationship
on the
a set of components
that set
are
necessary
plus
to
of components:
(nonleafl component to its first child, and links from next child of the same parent. A large number of other
child;
“down’’-connecting
“up” —connecting nent to the root Derived
structural
link
“inversion
“, “composition
“transitive instances
closure”, of derived
from
basic
the
a parent
a component of the entity. types
to its
links
structural
links,
by
link
types
that
have
defined
to the can be
2.2.8), the corresponding inverse link inversion operator, and their instances
For
examto its
children;
of operators
links.
any
a compo-
composition,
interpreter
to application
been
its
such
links. All computed
“executing”
the
example,
from
as “symmetric”
(see Section
types can be specified by using the can be automatically generated. As a
more sophisticated case, we can specify derivation rules application link type, if an instance of it exists between
such as: “given two components
different
is derived
entities,
then
an instance
of the
the roots of the corresponding entities.” Assume for example that a component “section
1. 1“ of a contract
“X,
as
N times),
to basic structural can be automatically
a proper
corresponding derivation clauses. A similar approach can be applied application
in terms
N )“ (repeated
and “closure’’-applied structural link types
all
“to-top’’-connecting
can be defined
“, “composition
to
an
from
any component structural links
component
parent;
the
induce
defined intensionally, and can be computed, from the basic ones. For ple: “down(N)” (N positive integer) —connecting a component directly
—say
the
of the first.
Defining
Nth
13
same
link. type
of an entity has been
of type “legal
connected
by the
an of
between
document” author
to a
component of an entity of type “law’’-say type “justified-by” (see Figure 1). Then represent also the fact that, at a different
“Article 2“ of law “Y-by assume that the author level of detail, the whole
“is-justified” by the whole law Y. This fact the root of contract “X” (which is intended and the root of law “Y” (which is intended This link can be derived by composing the
can be expressed by a link between to represent the whole entity “X) to represent the whole entity “Y). inverse of link “to-top’’-outgoing
ACM
TransactIons
on Information
Systems,
a link wants contract
Vol. 11, No. 1. January
of to X
1993.
14
.
F. Garzotto et al.
der]ved appllca[fon
app!lcat)on Fig.
from the
component same
outgoing
[39],
“section
Example
from
actual
of derwed
1. 1“-with
component—and
2.4 Browsing The
1,
then
component
application
the link composing
“Article
link
hnk.
“is-justified-by’’—outgoing the
result
with
the
from link
“to-top”
2“.
Semantics use of a hypertext
which
will
consumption” components,
determine
is largely what
the
defined
by its
information
browsing
objects
are
(in HDM terms, entity types, link types, or units), what the perceived links between
and what
the behavior
Given
the specification
when
links
are activated
of a particular
semantics for
“human
entities, outlines, these objects are,
is.
browsing
semantics
compatible
with
a given target hypertext systems, it becomes possible to translate HDM application specifications into running applications, once the mapping from HDM primitives into implementation structures of the target environment has been provided. By applying different browsing semantics to the same HDM static specifications, it is possible to deliver the same HDM application under different versions, each one characterized in different and dynamic behaviors, or running lar
The particular browsing hypertext development
semantics will system being
by different hypertext
visual
features
systems.
be closely dependent on the particuused for implementation. HDM, as
discussed so far, does not prescribe a priori any specific browsing semantics for hypertexts specified with it, nor does it include any high level primitive for defining browsing semantics. However, we have defined a minimal browsing semantics, compatible with plain nodes-and-links structures found in most hypertext systems, and we have adopted it for our experiments on automatic translation of HDM specifications into running applications (see ACM
Transactions
on Information
Systems,
Vol. 11, No
1, January
1993
HDM — A Model-Based Approach to Hypertext Apphcatlon Design Section
4.3).
default
browsing
For
the
moment,
semantics
this
browsing
semantics
.
is considered
15 as the
for HDiM.2
2.4.1 Default Browsing Semantics. HDM default browsing semantics assumes that only units can be perceived by the readers as standard “nodes”, i.e., “loci of navigation control”, and that only one node is active at any time. As a consequence, readers can perceive links only among units, and so, in the end, actual,
connections
must
be established
among
in HDM
only
perspective
links
connect
while
application
links
are
established
among
latter
be properly
Since
navigable
must
stract”
the
links
unit-to-unit
translated
among
into
units,
components unit-to-unit
components
and/or
units. structural
or/and links.
entities,
and
entities,
We will and
call
the “ab-
“concrete”
the
links.
2.4.1.1 From Abstract to Concrete Links. HDM default rules for translating abstract links into concrete links are based cm the idea of having a default representative for each abstract object (component or entity). Defining default representatives of entities and components is done by introducing a default perspective for each entity type, and then assuming that the default representative for a component is its unit under the default perspective and the
default
root
representative
component.
entity,
This
in its default
Given
this
notion,
for
perspective,
source
component
is the
to saying “stands”
entity-to-entity
links between their default application link is translated of the
an entity
corresponds
default
that
for that
application
representative
the
root
of its
component
of an
entity.
links
translate
into
concrete
representatives. Each component-to-component into a set of concrete links connecting each unit
to the
default
representative
of the
target
compo-
nent. To illustrate this rule, consider hypermedia music listening guide; entity “La nent (root
Traviata” of entity
application
link.
of type “Verdi”
Consider
the “La
“Musical of type
following situation Traviata-Ouverture”
occurring in a component (of
Work), is linked to “Verdi- 1“ compo“Author”), through a “Composer of”
furthermore
that
“Author”
entity
type has perspec-
tives “Picture” while “Musical
(showing the person) and “Text” (with a textual description), Work” has “Text” (with the music sccme) and “Music” perspec-
tives.
is the default
“Picture”
In the
above
case, the
perspective
actual
for entity
concrete
links
type
“Author”.
corresponding
to the
abstract
link connecting the two components, will connect both “La Traviata-Ouverture: Text” unit and “La Traviata-Ouverture: Music” unit to “Verdi-l: Picture” unit. This is an example where one link at the abstract level corresponds Figure 2.
2 The
default
relational
browsing
database
can be imported detail
to two
into
concrete
semantics
description Hypercard
navigable
has of HDM
been
links.
The
implemented
specifications,
and manipulated
using
situation
in a prototype and
generates
Hypertalk.
is illustrated
system,
a tabular
This
prototype
which
in
uses
description
a
that
is described
in
in [36]. ACM Transactmns
on Information
Systems,
Vol. 11, No
1, January
1993.
16
.
F. Garzotto et al,
Commxer
Component “La Traviata Ouverture ‘f
is
2.
The
default
rule
the
following:
if
then,
“Verdi
Example
2.4.1.2
from
abstract
of C2 having
among
the
same
of Links:
(or “buttons”).
structural
links
Anchors
of
information
Anchors
link
of C 1 having
perspective.
N concrete level.
pieces
toconcretellnks
C 1 has a structural
P, each unit
are link
this
Therefore,
correspond
and
that
represent
links
perspective
C2,
is linked
in an entity
Types.
usually
place-holders
of the same type,
translation
of type
to each structural
Anchor are
links
to a component
In
perceived that
of connection in nodes, and can be selected (“clicked”) to get into the link target(s). An anchor type specifies
anchors
-l”
Links
for component-to-component
Perception
“anchors” tence order
oftranslation
a component
T having N perspectives, defined at the conceptual
connections
Link
Component
for each perspective
to the unit
Application
-
Concret& Fig.
A&trect
of
or of a group
show
link
hypertext, through the
exis-
by the reader the properties of link
in of
types.
Consider for example, that a “Procedure” entity type has an outgoing link to a “Law” and an outgoing link type type “Formal-Legal-Justif ication” “Informal-Justification” to an “Informal-Regulation”. The author might want to provide to certain classes of users a single reading link, simply labelled since the distinction between formal and informal justifica“Justification”, tions
might
not be important
for readers
of that
class.
This
can be achieved
by specifying the anchor type “Justification” to be the union of application Zink t,ypes “Formal-Legal-Justification” and “Informal-Justification”. Another design requirement of the author might be to hide links of a given type for a specific application (since they might be relevant at design and specification level but not at reader level). This can be achieved by simply not assigning any anchor type to that link type. Anchor types, therefore, provide a mechanism for the author to present groups of link types together, also renaming or hiding them, as desired. When an anchor actually refers to several possible destination nodes, the HDM ACM
default Transactions
browsing on Information
semantics Systems,
has the notion Vol
11, No. 1, January
of CAooser, 1993
i.e., a structure
HDM —A Model-Based Approach to Hypertext Application that
is associated
the multiple
with
targets
an anchor
OF HYPERTEXT
This
will
section
via a “menus”,
describe
MODELING
a hypertext
of a larger prototype Dictionary [15] which
to select
according
application
designed
Regulations, and control
times laws are too broad, issued by some authority,
Entity
types
are sketched associated and
of vastly different but A credit organization
to Procedures.
regulations are Informal Norms,
Documents
with
with
have
Structure*,
have
Flow
it, which
way to access
interrelated manipulates
Procedures
nature Docu-
are defined
ac-
Norms. Laws are issued by the and taking activity. Most of the
an organization with the addition valid only for that organization.
types
of these
are omitted
Structure*
Official
model types
for lack
and
Text,
shows
an entity
of type
up of a root
components
Structure”
that entity
and
Official
the above state
of affairs
has a set of perspectives
of space. Text
Description
of
For
example:
perspectives; perspectives;
Laws
Documents Procedures
for short) and Description perAll application spectives. The perspective marked with a “*” is the default. link types are “symmetric” (see Section 2.2.8), i.e., they represent a relation and its inverse. Thus we have drawn link types only once, but we assume that for each application link type, there is a derivable link type that corresponds to its inverse. A fragment of an instance of the schema above is depicted in Figure 4. It made
Diagram
link
3. Each
have
HDM—a
and must be made more specific by Regulations on the basis of the text of the law. Finally, these
and application in Figure
and
and Informal credit granting
interpreted within which are of course
Regulations
one of
application for banking environment named has been developed by ARG SpA and Politecnico
to a large set of information handled by credit organizations. cording to Laws, state to discipline
17
WITH HDM
di Milano within the European Esprit project SUPERDOC. The goal of the Expert Dictionary is to provide an organized
ments
.
of the anchor.3
3. EXAMPLE
subset Expert
and allows,
Design
Procedure
component
denoting
(“Structure”
named
introducing
subprocedures
Mortgage
Loan
the whole
Procedure,
entity
or subprocedure
which
and several
steps.
Another
is
other
entity
is
Circular HyperBank 21 / 10/89 of type Regulation, which is made up of a root and four components: Units Involved, Subject, Operational Norms in Request Verification, and Data Entry Rules. These last two components represent
information
that
steps Request Verification application links of type Bank
21 /10/
3 Choosers hypertext
can
89,
in
be generated
respectively
and Request has-effects-on
turn,
is
affect
motivated-by
automatically
from
the
way
the
procedure
(sub)
Data Entry are performed; therefore, are included. Entity Circular Hyper-
the
entities
specification
Law
of the
19/8/89
concrete
and
links
in
the
application. ACM TransactIons
on Information
Systems,
Vol. 11, No. 1, January
1993.
18
F. Garzotto et al.
.
/—————_—————.. motwded motwwon
byl for
produced byldocuments
Rg
3.
Schema
of entity
Administrative
Council
the
right-hand
side
Client
Information,
Loan
types
and apphcat~on
Deliberation
of the
picture which
necessa~
link
types
fol
of the Expert
20 / 9 / 89. The small is an outline allows
named
us to directly
black Access
rectangle
on
to Mortgage
access entities
ing documents needed for the compilation of a Mortgage Loan picture, Mortgage Loan Request Form and Notary Statement). The following figures show HDM units of the appropriate tion of the Expert Dictionary,
Dictionary
Request
describ(in the
a few examples of screens (corresponding to components) from the Hypercard implementawhich was generated adopting the default
browsing semantics described in Section 2.4.1. The same application, with the same browsing semantics, has been implemented also in Hyperpad. Figure 5 shows the “Structure” perspective of a component of entity “Circular HyperBank 21/10/89” of type Regulation. Notice that all the links of type “Justified by” have been grouped under the anchor (button) “Motivations”. Figure 6 shows the same component under the perspective “Official Text”. Anchors corresponding to application links (“Effects”, “Motivations”) and perspective links (“Description” and “Official Text” in Figure 5, and “Structure” and “Description” in Figure 6) are at the bottom of the screen. If the user is interested in seeing, for example, the effects of the regulation shown in Figures 5 and 6, he can click on the anchor “Effects”. Since this in reality groups several outgoing links, a chooser is activated; from it, the user can select which of the possible destinations he wishes to go to. ACM
TransactIons
on Information
Systems,
Vol.
11, No. 1, January
1993
HDM —A Model-Based
Regulation
Approach to Hypertext Apphcation
Motivated BY Circular HYPERBANK 21/1 0/89
w
Admlnistr ouncil Delib. 28/9/89
Informal Norm
19
Procedure
orfgage Loan Q rocedure
~
.
J
Units
Involved
=
.
Design
Request Acceptance
&
(- and Entry
Subject
. =
/.
, ,“.-
,;,
...
,
~(?
f
l\
Operational ‘
\7--
\—
u
/1
Law 19/8/89 -*
Documents Necessary For
Documents Necessary For )
DOc”mg; Notary Statement
‘--=& Access to Motiage Loan Client Information
Fig. 4.
Instance
of Expert
Dictionary
schema
in Figure
3.
4. CONCLUSIONS 4.1 HDM
Comparison shares
model [10]. Additionally,
with Other some
However, HDM
apparent
Works similarities
with
the
Entity
Relationship
there is no E-R notion equivalent to HDM Entities are much more structured than
(E-R)
perspectives. E-R entities,
which are essentially flat and do not have structural links. Most importantly, whereas in the E-R model relations are included for representational reasons, HDM links are included also with the goal of providing navigation paths. HDM differs from g-IBIS [11] in the fact that it does not freeze, a priori, the application
domain,
and
therefore
ACM TransactIons
its
representation
on Information
Systems,
primitives
are
Vol. 11, No. 1, January
more 1993.
20
.
F Garzotto et al.
mu LOCAL UNITS INVOLVEO
w In
=.
SU&fELT
UPDATING THE ALLOWED MORTGAGE LOAN AMOUNT
W R.T THE VALUE OF THE PIORTGAGE GUARANW
LAST
‘;
h -
‘6
OPERATIONAL NORMS IN LOAN REQUEST VERIFICATION :: RULES FOR LOAN REQUE5r DATA ENTRV
OaXnpum
Otfmal
Fig. 5.
Text
“Structure”
perspective
CIRCULAR HYPERLMNKN
!723-Ott
[
of a Regulation.
,;.
Jg
21st 1989
~
s“b],ct uPD~TINL 7HEALLOWED MORTGALE LOANAFIOUNT W
+ 7
M“”’’’’’’’”’’’” z
;ZT &
Effects
t. 10C&L LINITr1~MkGcP3,cLl~NT5[PYlC[S D6Ph RTtlfNTM6NAGER5
.
—
P
Motwatmm
,. ..;,,
Hl~_ I-u k
[i
RT THE VdLUEOf
THE D
We , “form that the ex,, t,”g ,“1,,, to be be ,do Pted by the ),,,1 “,, t,, rqard)”q I1OPTGAGELOAN REQUESTVERIFICATION and MORTGAGi LObN CONCESSION, have been e.tended m follow,
n9.f~h,
lr{he Purw$eof theoan IS the Purch,$e.rthe re$tructur, b.rro*t.g pariy$ lega)lgdec18 red rcsldence, then the hlghe$t loan, mount thatcen be Pro)lded ,$ the 75X orthe value Ofthe guaranty, 1hewar8ntq must bc, m USWI the costumer s I,wIIY declared resldt”ce Th13 rule holds ror ANf customer mtqory
Fig. 6.
: H qm?f x ]
1
Dr M 81a”ch) Cl, ent Serwce$ EMpt D, rector
II Stmcfme
~
I “Official
~ptiml text”
Mot!uat!ons
perspective
Eff&ts
of the Regulation
in Figure
I
5.
“general”, oriented towards allowing the design of hypertext applications in most domains. HDM philosophy shares with IDE [27] the aim of supporting representation tasks in hypertext and of encouraging the creation of regular and consistent network structures. IDE has surely anticipated a number of concepts exploited in HDM. However, IDE is basically a development tool, while HDM is also a conceptual design device which can be useful even without an implementation of its primitives. Moreover, HDM provides richer modeling primitives—the notion of perspective, the distinction between different categories of links, the separation between hyperbase and access structures, and between authoring structures and reading structures (i. e., browsing semantics). Object Lens [28] classes resemble somewhat HDM entity ACM
types. TransactIons
Object
Lens,
on Information
however, Systems,
does not impose Vol.
11, No. 1, January
any constraint 1993
on possi-
HDM — A Model-Based ble connections instances With
between
Approach to Hypertext Application
object
class instances
and no real
Design
discipline
respect
to other
hypertext
allowed to contain arbitrarily from HDM, however, these
models
between
authoring
system independent browsing semantics with
respect
for specifying
discussed
in
Section
language,
for
manner, and is concerned, to HDM,
patterns
to HDM,
whose
defining
browsing the work
by providing
of visual
major
1.2,
complex information structures. models are more concerned with
hypertext
semantics presented
HDM
behaviors
focus for the moment
Differently behavioral
on representaof disting-uish-
structures
in
a
language. As far as in [40] goes a step
a graph-grammar
and dynamic
general techniques for translating generic authoring ically structured hypertext. In this sense, this work tary
on actual
at modeling applications rather than model [39] and Tompa’s model [41] the and structure of the “nodes”, which are
aspects of hypertext, or with operational features, rather than tional issues. The approach introduced in [40] shares with HDM the idea
ahead
21
creation.
differs in the fact that it is aimed systems. HDM shares with the Trellis idea of abstracting from the contents
ing
.
based
(style
language
templates),
and
notations into systematis somehow complemen-
is on static
representational
aspects.
Evaluation,
4.2
The HDM
Experiences,
model
can be used in different
an implementation and
concise
device.
already
A number
device,
of applications
developed,
as an implementation effort by HDM related of experiences
and speed of the whole
manners:
As a modeling
specifications
applications HDM ment
and Feedback
in
to
a.s a modeling it allows
be developed,
a system
device
or
independent
have
shown
that
of application
significant
gains
development
to
clear
describe
manner.
device, means to directly support tools, as described in Section 4.3.
process
or as
to lay down
Using
the
develop-
in the
quality
can be achieved
by
using HDM as modeling device. In particular, we have observed that HDM is especially suitable for applications where regularity, organization, modularization,
and
consistency
are
important
factors.
Typical
applications are, for example, technical documentation, tion [12, 27], audi’ting systems [13], and in general, corporate where (e.g., than HDM.
environments.
the author inventing planning Our
tends
It is therefore to follow
new nodes and his exercise in
conjecture
(not
yet
true
his feelings
that
examples
of such
training and educalarge applications for
“creative”
in a somehow
applications unpredictable
[5], way
new navigation patterns on the fly) rather advance, are not conveniently modeled by fully
tested)
is that
most
of the
intensively
used, existing or future, hypertext applications are unlikely to be of the “creative” kind, but rather they are planned, cohesive, and carefully organized. As a modeling device, HDM has been successfully used several times. Beside the authors, several different research groups in four different countries are using HDM in a significant number of different which range from administration and technical manuals, ACM
TransactIons
on Information
Systems,
application to university
Vol. 11, No. 1, January
fields, class 1993.
22
F. Garzotto et al.
.
notes, literature, philosophy encyclopedias, art collections, and exhibitions [9, 23, 24, 25, 34]. All of them have reported that the model can be relatively easily grasped both by the users and by designers, and that a more productive cooperation can be achieved application development—analysts mentors, design
different of the
among the persons involved in the process of and domain experts, analysts and imple-
implementors.
application
Domain
in HDM
experts
terms,
and
are
able
to
discuss
the
modify
and
to autonomously
improve it. This implies a tremendous gain in the efficiency and quality of knowledge and requirement analysis processes. Members of the implementation
team
deep
are able
and
precise
to discuss
the need of prototyping tasks among different implementors
are guided
effect HDM
extensive
time
use
the
analysts
and to get a
of their
work
without
the implementation applications. Since
specifications,
arbitrariness
is
HDM
in team
work
has been
the
as a modeling
device,
tend
to invest
a quite
“organization
organizing a set of information, links versus application links, the overall ing, groups
and precise
of using
in discussing
with
requirements
makes it possible to split still obtaining consistent
by clear
that
who
application of the
it. This persons,
virtually eliminated. An interesting side people
the
understanding
style”
issues
the choice between etc.). These discussions
fact
(e.g., the best way
of
establishing perspective are extremely effective:
quality of applications improves, in general, tend to develop a common, consistent design
and, more intereststyle across different
application domains. Additionally, HDM and related tools have been shown to be quite useful in making the development of the same application in different versions easier, by “switching”
from
one environment
to another.
been Hypercard, Supercard, Hyperpad, animations embedded in Hypercard-based
Target
Toolbook, hypertext).
systems,
Director
so far, have
(the
latter
for
4.3 Tools and Implementation We have developed so far a number of elementary HDM-tools to speed up the development of our applications. For the time being, these tools perform the following
operations:
—automatic suggestion the schema);
of application
—automatic
of some
derivation
defined application links, rule exemplified in Figure —automatic —maintenance link types);
derivation of link
links
(out
application
links
and the root-to-root l—Subsection 4.3):
of structural tables
of link (the
describe
descriptions
inverses
derived
and perspective
(which
type
links
in
of authorbased
on the
links;
the extensions
corresponding
to
—automatic derivation of a class of outlines—those allowing to enter the hyperbase by first selecting the entity types of interest, and then choosing the desired entity within the list of all entities of the selected type; —automatic creation the schema); ACM
TransactIons
of entity
on Information
templates
Systems,
Vol.
(out
of entity
11, No. 1, January
1993.
type
descriptions
in
HDM —A Model-Based —automatic
creation
anchors For
Approach to Hypertext Application
of visual
and association
implementation
of anchors
purposes,
ciently large scale; the initial in their rudimentary stage increased
the effectiveness
we have achieved in an educational types,
six hundred templates and
understand
4.4
to link
HDM
nodes,
including
has
not
of our development,
units
(“nodes”),
nodes
of the
80%
of the
link
this
happens;
been
yet
thousand
different
types
instances
of visual templates, above all, automatic
have
think
including generation
of
tested
of four
link
have been
of the
on a suffiEven greatly
to one, and
For example, eighteen link
instances,
been
all the
automatically
derived.
It
effectiveness
is easy
to
of automatic
anchors and their of derived links.
associations
to
Further Developments
All the above tools, well defined HYTEA [1],
although
consistent within the
effective
in their
development CEC ESPRIT
own respect,
do not constitute
environment. The research program, is currently aiming
development of a full size HDM-based development environment text applications. The project involves four different companies research
institutions,
Within
the
and
HYTEA
“transferred”
into
application
is
scheduled
project, the
definition language is more a reference
the
concrete
primitives
be
syntax
completed
primitives
of a language,
In the
final
HYTEA
is already
modify
access structures
named
in progress.
to define
precisely
environment,
rather objects
for hyperand two
March have
1993. been
HDL—HDM
A reference the
semantics
the model currently
according provided
language
is still
of the interactive
to the new emerging by HDM
authoring
in HDM
than on traditional programcorresponding to HDM design
offered by the HDM authoring environment. HDM is, obviously, an evolving model: as we gain we will
by
of HDM
a
project at the
[22], which has been omitted here for lack of space. HDL language than a language which will be directly used by
designers.
in order
to
modeling
will be based on visual programming, ming. Some work on defining visual ever,
23
placement
encouraging. tools have
by a ratio
and four
just
.
instances.
results, however, are quite of development, the above
for
why
generation links, and,
for
enormous savings in the development effort. application based on six entity types and
visual
generated,
templates
Design
applicative needs.
are restricted
useful,
how-
operations experience, In particular,
to the relatively
unsophisticated notion of outline, which has been proved to be too limited. Looking at complex corporate environments, we found out that a typical situation is to have several different categories of readers using the same hyperbase. Each category of users naturally perceives the organization of the material according to its needs. From this observation, we came to the conclusion that access structures should evolve from just providing entry points to the hyperbase to becoming something like “hypertext views”, i.e., ways of presenting “fictitious” hypertext environments, specifically tailored for a class of readers. “Fictitious” means that these environments are not implemented on their own, but are rather “simulated” by a suitable mapping on the underlying hyperbase. For this purpose, the notions we are working on ACM
Transactions
on Information
Systems,
Vol. 11, No. 1, January
1993.
24
F. Garzotto
.
et al.
are “derived entities” (i.e., entities assembled out of pieces of other, ing, entities), “user-derived” links (i.e., links derived only within reading environment), “parametric guided tours” (i.e., intensionally guided
tours),
currently images,
and others
working animation,
in-the-small entities
process.
of type
We have
“history”
and each history can choose,
of a similar
kind.
Another
important
on is multimediality. In the or video clips can be introduced
note
according
a prototype
are made
either
for
notes”
has two perspectives—text to his interest,
aspect
we are
current version of HDM, as part of the authoring-
application,
of “history
preexista given defined
example,
(as their
and animation.
to read
where
components), The reader
the textual
description
of
an historical event or to watch the animated version of the same event. This approach works fine for simple applications, where multimedia has the limited role of presenting small chunks of information with a different perspective. In other applications, however, multimedia may have a larger role. A video showing a maintenance procedure, for example, touches different
subjects;
it
would
be artificial
associated to a single component. that “active” information objects the role of “automated” cally take hyperbase,
guided
(and
ineffective)
tours
the reader along different and are “synchronized”
it
as a unit
working around the idea or videoclips could play
[32, 42, 44], i.e., devices
which
automati-
active information units of an underlying with interlinked chunks of static informa-
tion. We are currently developing a large-scale idea. On the basis of the forthcoming results extensions
to model
We are currently such as animation
application [34] we will introduce
around this the proper
to HDM.
ACKNOWLEDGMENTS
The ideas
that
originated
the HDM
of an ESPRIT
project,
SpA.
acknowledge
We must
work
SUPERDOC, the
were
first
developed
led by ~G—Applied
technical
in the context Research
contribution
of the
ARG
Group team
in
general, and Cristina Borelli, Many of the ideas described Bernstein, Norman Meyrowitz,
SUPERDOC Project Leader, in particular. here benefited from discussions with Mark John Mylopolous, and the members of the
HYTEA
Caloini
Project
Team,
Andrea
and
Luca
Mainetti
in particular.
We
are grateful to the TOIS Associate Editor, Polle Zellweger, and to the TOIS anonymous reviewers for their extraordinarily helpful comments on previous versions of this paper. REFERENCES 1. ARG-APPLIEI) 5252 2
RESEARCH GROUP S~A.
(HYTEA),
AKSCYN,
R.,
managing
W.
Cupertino,
D.,
ACM
AND YODER,
in orgamzations.
HyperCard.
In
E.
KMS:
Corrzmurz,
Software
M., AND SWF,EN~Y, E,
Systems
Inc,
Watertown
5. BOLTER, J. D., AND JOYCE, M text
Techmcal
Annex.
Tech.
Rep.,
ESPRIT
project
A
ACM
for
Macintosh
The Electum
of 1912,
dmtributed
hypertext
31, 7 (1988), Computers
system
for
820–835. Apple
Computer
Co,
1987.
4, BERNST~lN, Eastgate
MCCRACKEN,
knowledge
3. ATKINSON,
HYTEA
1990.
’87 (Chapel
Transactions
Hill,
13-15,
Systems,
Hypertext
for IVfac[ntosh
Computers.
1989.
Hypertext
N. C., Nov.
on Information
Mass.,
and 1987),
Vol.
creative pp
11, No
writing,
In
41–50, 1, January
1993
Proceedings
ACiVf Hyper-
HDM — A Model-Based Approach to Hypertext Application Design 6. BRODIE, M., MYLOPOLOUS, from
Artificial
7. BROWN, P. J. Hypertext
P.
Systems
J.
Hill,
Assessing
A.,
Politecnico
The
Database
12. CRANE, G.
Znf.
Syst.
From
the
Proceedings YOUNG,
L.
and
old to the
lahoma,
Workshop
in 5-8,
1989),
6-9,
the
The
Eds.,
experience
of
in Education
pp.
P.,
18. GARZOTTO, F., PAOLINI,
pp.
and
ACM
Trans.
policy
discussion,
traditional
13-15,
domain.
scholarship.
1987),
In
In
pp. 51-59.
Proceedings
of ACM
169-180. Commun. Knowledge
environments.
ACM
31, 7 (1988),
based
In
Applications
tools
for
Proceedings
of Al
and
862-870. explanation
of the
Expert
2nd
ACM
Systems
(Tul-
157-169.
and
Authoring-in-the-large: In
Proceedings
Design
SCHWABE,
Handbook,
into
dictionaries:
design.
Specification
PAOLINI
of data.
for exploratory
in hypertext.
Engineering
application
Hypertext/Hypermedia
Concepts,
and J. Andrc$,
notes:
view
N. C., Nov.
auditing
P., AND SCHWABE, D.
hypertext
tool
hypertext Hill,
1989),
application
June
F.,
Hypertext.:
on Hypertext
a unified
A hypertext
Integrating
Expert
and
on Software
17. GARZOmO,
P.
of complex
for
course
Conference
Toward
’87 (Chapel
mechanisms
16. GARZOTTO, F., PAOLINI, techniques
new:
challenges
Industrial
Term.,
In
N. Streitz,
1984.
of the ACM
303-331.
Pa.j Nov.
Abstraction
on
gIBIS:
Hypertext
Hypertext
maintenance
Proceedings
1-12.
Hypermedia
approach:
M. L.
15. GARZOTTO F., AND PAOLINI Conference
Verlag,
9-36.
’89 (Pittsburgh,
14. GARG, P. K.
pp.
of the Italian
6, 4 (1988),
of the ACM
Hypertext
documents.
Perspectives
Springer
In
25
pp. 35-42.
J.j AND BEGEMAN,
Trans.
P.
system.
‘90), A. Rizk,
1990,
AND PAOLINI,
1 (1976),
1,
hypertext
of ECHT
Cambridge,
entity-relationship
Syst.
11. CONKUN,
pp. 33-40.
Modelling:
Languages.
Guide
of
In Proceedings
1991),
The
N. C., 1987),
GARZOTTO F.,
(Torino,
P.
products:
quality
On Conceptual
Programming
the
Press,
di Milano.
Research 10. CHEN,
into
and
( Proceedings
University
9. CALOINI,
13. DE
ideas
and Applications
Cambridge
ACM
Databases
Turmng
’87 (Chapel
8. BROWN,
J., AND SCHMIDT, J., EDS.
Intelligence,
.
D.,
E. Berk,
(Como,
AND
P., AND SCHWABE, D.
’91 (San
M.
Eds.,
HDM—A
applications. In Proceedings ACM Hypertext
6th
engineering
IEEE
International
2!5-26, 1991), pp. 87-98.
Oct.
BERSTEIN,
and J. Devlin,
Software
of the
Tools
McGraw
model
for
Antonio,
for Hill,
the
Tex.,
designer. 1991,
design
Dec.
In
179-207.
of hypertext
15– 18, 1991),
pp.
313-328. 19. HALASZ,
F.
systems.
Reflections
Commun,
20. HALASZ,
F.,
Hypertext
ACM
on NoteCards:
Seven
31, 7 (1988),
836–851.
AND SCHWARTZ, M.
NIST
The
Standardczatzon
issues
Dexter
for
the
reference
Workshop
next
model.
(Gaithersburg,
generation
In
Md.,
of hypertext
Proceedings Jan.
of
16-18,
the
1990),
1st pp.
95-133. 21. HULL,
P., AND KING,
issues.
ACM
22. HYTEA
Semantic
Suru,
PROJECT.
(HYTEA),
PROJECT.
Siemens-SIFORM. 24. HYTEA
definition
Hypermedia
technical
Tech.
PROJECT.
25. HYTEA
Tech.
IDE.
In
P5252
Proceedings
28. LAI K. Y., MALONE, Trans.
29. MARSHALL, burgh,
Inf.
5252
applications,
and
Rep. D2, ESPRIT
(HYTEA),
research
Project
5252
Syst.
6, 4 (1988),
C. C., AND IRISH, P. M.
existing
hypertext
Pa., Nov.
5-8,
intelligible 1989), ACM
processing
system
1992.
for
IVECO-FIAT
workshops.
applications:
HYTEA
Greek
5252 tools:
Modern
(HYTEA),
1992.
Specification
and
Painting design.
between Tech.
Rep.
1992. the
Hypertext
T. W., AND Yu
forms
(HYTEA),
1992.
Project
Facilitating
ACM
for the
5252
documentation
for cultural
Rep. D5, ESPRIT
D.
Project
@IYTEA),
Authoring/delivery
Project
27. JORDAN, D., AND RUSSEL,
make
Tech.
documentation
technical
Project Hypermedia
wars.
PROJECT.
2, ESPRIT
ACM
Survey,
language.
Rep. D4. 1, ESPRIT
Hypermedia
PROJECT. world
26. HYTEA
with
modelling
201–260.
HDL—HDM
Rep. D4.2-ESPRIT
the two
database
19, 3 ( 1987),
1991.
23. HYTEA
Tech.
R.
Comput.
development
’89 (Pittsburgh,
K. C.
Object
lens:
of representations Pa.., Nov.
5–8,
A spreadsheet
1989),
in hypertext pp. 93– 104.
for cooperative
work.
332-353. Guided for
tours
readers.
and In
on-line
Proceedings
presentations: ACM
Hypertext
How
authors
’89 (Pitts-
pp. 15-26. Transactions
on Information
Systelms, Vol. 11, No. 1, January
1993.
26
F. Garzotto
.
30. MYLONAS, Perseus
et al.
E., AND HEATH, Project.
‘90), A. Rizk.
In
S.
Hypertext
Hypertext.
N. Streitz,
from
Concepts,
and J. Andr6,
the
data
Systems
Eds.,
point
and
of view:
Paths
Apphcations
Cambridge
and hnks
(Proceedings
University
Press,
in the
of ECHT
Cambridge,
1990,
pp. 324-336, 31. NIELSEN,
The art of navigating
J
through
hypertext.
32. PAOLINI P., CALOINI, A., AND GARZOTTO, F. Dep.
of Electronics,
Politecnico
di Milano,
Hypertext
topologies
33. PARUNAK, H. V. D.. text
’87 (Chapel
34. RAI-RADIO Rep , Dept
Hill,
NC.,
NOV. 13-15,
TELEVISION
ITALL4NA. and Education,
Techniques
et Sctences
36. ScHWA~~,
D.,
approach.
37. SHNEIDERMAN, ACM
Press.
Quelques
A.,
B. (ED.)
and user
RAI,
idiies
Hypertext
pour
39
ACM
D., AND
ing semantics.
Hypertext FURUTA, R.
ACM
for a structured
Trans
1990,
41. TOMPA, F. (1990),
A. Rizk, 180-193.
A data
model
Guided
ACM
43. UTTIN~, Trans.
Trans.
K,, Inf.
Database
Syst.
Hyper-
of philosophy.
des syst~mes
Tech.
hypertextes.
Hypertext
development
using
a
937–962. and
Hypermedia
Antonio,
Tex.,
Electronic
Streitz,
Product
Series,
composition,
for flexible
J
Document scrlptmg
Systems
Andr6,
hypertext
An
author’s
tools.
pp. 147-160. structure
with
brows-
3–29.
Concepts
and
templates:
1991),
hypertext:
1 (1989),
7,
Hypertext:
(1988),
7,
P. T.
H.vpertext
45. WALKER,
tours Znf.
and
Syst.
tabletops:
Eds.,
languages,
and
systems.
and translators
APPILcatzons
Cambridge
database
1 (1989)
(proceedings
University ACM
Press,
Trans.
Inf.
Syst.
Cam7, 1
N
Scripted
Context
documents:
Supporting
for
communicating
in hypertext
envn-on-
398–414. and
orientation
in
hypertext
networks
ACM
58-84
’89 (Pittsburgh,
J. H.
Tools
6, 4 (1988),
AND YANKRLOWCH, Syst.
44. ZELLWEGER,
A hypermedia
Pa., Nov. document
5-8,
1989),
path
mechanism.
In
proceedings
pp. 1-14.
development
with
Concordla.
IEEE
Computer
21,
1
48-59.
46. WIEDERHOLD, 47’. WINTER, Voyager
G.
R. T.
Database Luduzg
Company,
48. YAN~ELOVICH, concept
and
(1988),
91-96
ACM
ACM
85-100.
ments.
Recewed
P.
on Hypertext.
Hierarchy,
In N.
pp.
42. TRIGG, R. H
ACM
Proceedings
505-514.
11(1992),
Petri-net-based
Inf.
hypertext.
’90),
bridge,
In
encyclopedia
22,
Exper.
’91 (San
40. STOTTS, P. D., AND FURUTA, R. of ECHT
296-310.
Rep. 78-91,
1988
F’roceedmgs
ST’OTTS, P
navigation.
une modelizatlon
38. SMITH, C. K., GARRET, L. N., AND LAUHARD, J. A. In
Tech.
1991.
9, 6 (1990),
Pratt.
33, 3 (1990), tours.
PP. 43-50.
GARZOTTO. F., AND PAOLINI,
Softw.
ACM
and gmded
The multimedia
Informcs@ues.
CALOINI,
model-based
Commun.
media
1991. 1987),
of Scholarship
35. RICHARD, G., AND RI.ZK, A.
Active
January
TransactIons
N.
Design
Van
McGraw
Beethouen
Hill,
1983.
Symphony
Number
9. CD
Companions
Series,
The
1989 HAAN,
B
construction
1991;
revised
on Information
J
MEYROWITZ,
of a seamless
April
1992;
Systems,
N.
K.,
AND DRUCKER,
information
accepted
July
envmonment.
1992
Vol. 11, No. 1, January
1993.
S
M.
Intermedla:
IEEE
Compater
The 21,
1
