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 leave during 1990 (partially

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

December 1991

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.

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
and Components

2.1.1 Entities

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, Dantes Divine Comedy, Gershwinss 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 mcwabon

by/ fcf

Laws

poducad

bfldciwments

rwcassafy

im

Figure 1. Schema of Entity Types and Application

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 wlm~fi /
I \hiiiiiw

i
//y

)IY

a is the default

Data Enhv

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
q

(the one marked

with

have Structure*

and Oficial

TexC

Documents

have Structure*,

O@cial Text and Description; and Description

Procedures have Flow Diagrams*

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

q** CIKUMR LOCAL

N. 1723 &t. INVOLVEO

218t 1989

q *

INsls

1
ALLOWEO IM3NTSAGE LOAN AIWllMT tSN?TSAGE HMRAN7V

-~

UWATlffi

TIE OF THI

WR.T. THE VALtE

I
i

~OFIERATIIMALNORtlS IN LOANREOUEST VERIFICATION

Dwaipam

(XMa2

Td

MeHvatlons

BEru2s

Figure 3. Structure perspective

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
Subjti. G := =7S% ??J n z

CIWJLAR

IffPERSANK

N 1723-

Oct. 21*

19e9 fWMOENS W.R.T. THE VALUEOFTHE ii!

a

flMMERS,

CLIINT SENVICE2 Department

E w

UPDATIW THEALLOWEDfORTOACE LMNMDUN7 MORTGAGE WIANN

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

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

Figure

4, Official

text

perspective

the

Regulation

in Fig, 3,

RECENT

DEVELOPMENTS

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 painters 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):
q

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.
q

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= reJinenzent-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

according to the

changes

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

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.

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] D. L. Yoder, E. A.; KMS: A Distributed Akscyn, R.; McCracken, Hypertext System for Managing Knowledge in Organizations, Comm. ACM, 31 (7), July 88. Brown, P.J.; Do we need maps to navigate round hypertext documents?, Electronic Publishing - origination, Dissemination and Design 2,2 (July 89). 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 P.K., Abstraction (7), July 88. 90] mechanisms in Hypertext, Comm. ACM, 31

[Brown

89]

[Brown

90]

[Garg 88]

[Garzotto

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 F.; Paolini P.; Schwabe, D.; Bernstein, M.; Tools Designing Hyperdocuments, Chap. 13, Hypertext/Hypermedia Handbook, J. Devlin, E. Berk, eds., McGraw Hill, 1991. for

[Garzotto

91]

[Halasz 88]

Halasz F., Reflections on NoteCards: Seven issues for the next generation of hypertext systems, Comm. ACM, 31 (7), July 88. Halasz F., Schwartz M, The Dexter Reference Model, Hypertext Standardization NIST Workshop, Gaithersburg, 1990. HYTEA Technical Annex, Esprit II Project P-5252, CEE-DG Proc. First MD, Jan.

[Halasz 90]

[HYTEA [Marshall

90] 89]

III.

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, P.; Garzotto, F.; Caloini, A.; Active Media in HDM, technical Report 91-18, Dipartimento di Elettronica, Politecnico di Milano, Mar. 91. 327 December 1991

[Paolini

91]

Hypertext 91 Proceedings

maymond

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

and the Oxford

English

[Schwabe 90]

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, P.D.; Furuta, R., Petri-Net-Based Hypertext Document Structure with Browsing Semantics, ACM Transactions on Office and Information Systems, 7(l), January 1989. Streitz, N.A.; Hannemann, J.; Thtiring, M.; From Ideas and Arguments to Hyperdocuments: Traveling through Activity Spaces, Proceedings Hypertext89, 1989.

[Stotts

89]

[Streitz

89]

[Zellweger

89] Zellwerger, Mechanism,

P. T., Scripted Documents: Proceedings Hypertext89, 1989.

Hypermedia

Path

Permission granted direct title that

to

copy that

without

fee

all or part are not made

of this

material

is for

provided commercial

the copies

or distributed notice notice

advantage,

the ACM

copyright and

and the is given a fee

of the copying

publication To copy 0-89791

and its date otherwise, -461 -9/91

appear,

is by permission permission.

of the Association or to republish, /0012 /0328 . ..$l

for Computing requires .50

Machinery. and/or @ 1991 specific ACM

Hypertext

91 Proceedings

328

December 1991