KMS Document - CiteSeerX

HB1: Initial Design and Implementation of a Hyperbase Management System John L. Schnase John J. Leggett David L. Hicks

Hypermedia Research Lab OCTOBER 1991 TAMU-HRL 91-003

HB1: Initial Design and Implementation of a Hyperbase Management System

Table of Contents 1.

INTRODUCTION

1

2.

HYPERMEDIA CONCEPTS

3

3.

THE HYPERTEXT RESEARCH LABORATORY PERSPECTIVE

3

4.

HB1 DESIGN AND IMPLEMENTATION 4.1 Storage Manager 4.2 Object Manager 4.3 Association Set Manager 4.4 HB1 Operation 4.5 Implementation 4.6 Summary

5 6 7 8 10 11 11

5.

DISCUSSION 5.1 HB1 Data Model 5.2 HB1 Architecture

12 12 14

6.

RELATED WORK 6.1 Related Work in Hypermedia 6.2 Related Work in Database

15 15 18

7.

FUTURE WORK

19

8.

SUMMARY

20

ACKNOWLEDGMENTS

20

REFERENCES

21

APPENDIX: HB1 SPECIFICATION

28

i


HB1: Initial Design and Implementation of a Hyperbase Management System JOHN L. SCHNASE JOHN J. LEGGETT DAVID L. HICKS

1.

INTRODUCTION

Hypermedia systems handle interconnected information residing within a potentially wide range of data types, including text, graphics, animations, and digitized sound and images.

HB1 is a

prototype database management system (DBMS) designed to meet the storage needs of next-generation hypermedia system architectures. We refer to HB1 as a hyperbase management system (HBMS) because it supports not only the storage and manipulation of hypermedia information, but the storage and manipulation of connectivity data as well. In this paper, we present a snapshot of the current system and discuss its capabilities. We also identify some of the important issues that must be addressed by future research in this emerging area. Hypermedia systems allow users to personalize an information space by forging arbitrary connections, or links, among pieces of information. These links generally tie together concepts that have a natural association in the mind of the person creating the links. Subsequent access to connected information is then obtained through an active process of navigation. With the aid of a high-resolution, bit-mapped display and a pointing device, users typically move through a hypermedia hyperbase by traversing links, or browsing, rather than by traditional query mechanisms. For this future to be realized, however, two things are clear. Effective database support for these new environments is essential, and, in order to be effective, they must provide a variety of capabilities that are not offered by the current generation of DBMSs [30, 42, 53, 57, 75]. In addition to the usual requirement for permanence of data, controlled sharing, and backup and recovery, HBMSs must be capable of modeling complex interrelationships and providing direct support for novel data types. They must also be able to handle lengthy transactions, transactions

Hypertext Research Lab • Texas A&M University

1

HB1: Initial Design and Implementation of a Hyperbase Management System that are unique to hypermedia, massive distribution of functionality, extensibility, and versioning of both the data and structure of hypermedia. HB1 is our first HBMS prototype and represents an initial effort to implement some of these features.

HB1 was designed with a very specific goal in mind. It is intended to support an extensible, object-based system architecture for distributed, inter-application linking. A system based on such an architecture is currently being developed in the Hypertext Research Laboratory at Texas A&M University, and HB1 is its backend. This hypermedia system, referred to as System Prototype 1, or SP1, will be described briefly in this paper in order to clarify some of HB1’s operations. A more detailed description, however, can be found in [29] and a forthcoming publication. As shown in Fig. 1, HB1 is implemented on top of the Unix filesystem and is composed of three distinct subsystems: the Object Manager (OM), Association Set Manager (ASM), and Storage Manager (SM). OM implements the notion of a large, shared repository of simple, unstructured objects, and ASM provides persistent and sharable storage for the hypermedia connections that exist in the database. Together OM and ASM implement HB1’s data model, which, as we will show, satisfies the requirements of our hypermedia system architecture in a clean and simple way. SM maps HB1’s data model into physical storage and is currently a semantic network database management system. Heterogeneous distribution of OM and ASM functionality across a range of platforms is achieved by a client/server model using X Window System’s interprocess communication (IPC) facilities.

In its overall organization, HB1 follows a recent trend in

object-oriented database design in that it reflects an integration of behavioral and structural modeling techniques [10, 28, 42, 63]. We continue our introduction in Section 2 by commenting briefly on basic hypermedia concepts. Section 3 presents our perspective on hypermedia. Section 4 describes the design, implementation, and operation of HB1. In Section 5, we discuss the advantages of the approach we are taking and, in Section 6, show how it relates to other research appearing in the database and hypermedia literature. Section 7 identifies significant issues that must be addressed by future research in this area, and Section 8 summarizes the major points of the paper.


2

HB1: Initial Design and Implementation of a Hyperbase Management System 2.

HYPERMEDIA CONCEPTS

The basic concepts underlying hypermedia have been described in several places [2, 3, 4, 5, 20, 45, 62, 64]. Simply put, hypermedia systems allow networks of linked information to be created and manipulated. By definition, this information can potentially reside within vastly different media types. For example, in Fig. 2, a portion of the digitized image of a bird in a multimedia document has been linked to a paragraph of related information in a text object. A typical system would provide the necessary mechanisms to display images and text, author links, and highlight in some way information that is linked. The system would also allow a user to access connected information by traversing links. This browsing activity would generally be carried out by mouse selections on highlighted information that cause information on the other side of the selections’ links to be displayed. It is this ability to author and browse arbitrary connections among information that distinguishes hypermedia systems from other types of multimedia systems.

Beyond these basic notions, the abstractions, interfaces, functionality, and terminology presented by the current generation of hypermedia systems differ widely. Despite the variation one sees in existing hypermedia systems, however, virtually all have one critical architectural feature in common: they are monolithic, stand-alone applications. The behaviors that make them distinctive are encapsulated within each system. The hypermedia structures that they manipulate cannot be shared, and the infomation they manage is relatively isolated from other applications. In short, existing hypermedia systems lack the architectural framework required for integration into advanced computing environments of the future.

3.

THE HYPERTEXT RESEARCH LABORATORY PERSPECTIVE

Our work focuses on software architectures to support next-generation hypermedia functionality. In particular, we are interested in integrative approaches that accommodate extensibility, distribution, and inter-application linking. Over the past several years, we have evolved a perspective that fulfills these requirements. Fig. 3 shows our conceptual model of hypermedia. The model consists of six principle elements, the first three of which are: applications, components, and persistent selections. Applications are


3

HB1: Initial Design and Implementation of a Hyperbase Management System simply programs.

Components are the data or information manipulated by applications.

For

example, text editor applications typically manipulate ASCII components. Persistent selections are selections within components that, in contrast to the usual implementation, persist between application sessions and can be accessed at a later time. This functionality is implemented by applications maintaining persistent selection data structures for components (Fig. 4). Within our conceptual framework, hypermedia results from connections forged among persistent selections. The remaining three components of our model are essential for hypermedia functionality. They are: anchors, links, and associations. As shown in Fig. 3, anchors are associated with persistent selections. Links join anchors, thereby completing connections among persistent selections. The relationships between these elements, depicted as arcs in Fig. 3, are associations. The critical and distinguishing features of the model are: (1) anchors and links are processes in our model − behavioral entities capable of arbitrarily complex computations, (2) associations are structural entities, and (3) anchors, links, and associations all have first class status. It is clear that we have a distinctly computational perspective on hypermedia. Anchors and links, for example, can be arbitrarily powerful agents. In addition, we make a strong distinction between structure and behavior.

This is intended to encourage implementation approaches that avoid

encapsulating structural aspects of hypermedia with structure-independent functionality. Precisely what is meant by this will become clear in the next section. For now, though, it is enough to see how our perspective can influence the overall organization of hypermedia systems. A general system architecture implemented along these lines allows the integration of diverse applications under a common hypermedia model. Specifically, non-monolithic, inter-application linking can be realized by moving hypermedia data and functionality into a distinct "link services" subsystem of a computing environment (Fig. 3). Services can then be provided to participating applications through interprocess communication (IPC). extensibility by allowing new functionality − i.e.

Such an approach accommodates

new anchor and link processes − to be

incorporated at any time without affecting the underlying structure of hypermedia.

Massive

distribution of functionality is accommodated since application, anchor, and link processes, as well as processes affecting associations, can conceptually reside anywhere within the IPC domain of the architecture. Simply put, the model provides a powerful framework for building the next generation of hypermedia systems. Hypertext Research Lab • Texas A&M University

4

HB1: Initial Design and Implementation of a Hyperbase Management System It should be noted that many of the central concepts found in current monolithic hypermedia systems do not carry over to a non-monolithic, link services world. For example, the concept of node essentially goes away, and the semantics of authoring and browsing become the shared responsibility of applications and the link services subsystem. Connections, in a sense, exist only from information to information. The traditional notion of anchor corresponds most closely to our persistent selection, which is managed entirely by applications rather than link services. There are other important differences, and we will consider some of them later in the paper. First, however, we look at a prototypic instantiation of this model.

4.

HB1 DESIGN AND IMPLEMENTATION

The HB1 hyperbase management system is intended to satisfy the storage requirements of a system architecture based on our model of hypermedia. As shown in Fig. 5, HB1 is built on top of the Unix file system and is composed of three distinct subsystems: the Object Manager (OM), Association Set Manager (ASM), and Storage Manager (SM). OM and ASM are both server processes accessible to distributed client processes via IPC interfaces. OM is an object server. ASM manages structural data applicable to objects within OM’s repository that are involved in hypermedia connections. Together, these two components implement HB1’s data model. Physical storage is managed by SM which is currently a semantic network database system. OM and ASM bind to SM’s library routines which, in turn, provide an interface to the underlying Unix file system. As we have indicated, HB1 backends a hypermedia system prototype under development in the Hypertext Research Laboratory. We call the prototype System Prototype 1 or SP1. Both HB1 and SP1 are at an early stage of their evolution, and, in this Section, we describe their design and implementation up to now. We begin by describing HB1’s Storage Manager. Next, the design, data model, and operation of HB1’s Object Manager and Association Set Manager are explained. We then briefly describe HB1’s operation within SP1.

The Section closes with comments on

implementation and a summary.


5

HB1: Initial Design and Implementation of a Hyperbase Management System 4.1

Storage Manager

HB1’s Storage Manager is a prototypic semantic network database system under development by IBM called Saberel1. Saberel was chosen because it allows unstructured objects to be stored, manipulated, and accessed by way of conveniently defined inter-object relationships. Traditionally, Saberel has been used for CAD and VLSI design applications, but we are extending and modifying this storage system to better support distribution, large object size, and hypermedia transactions. We elaborate on our experiences with the semantic modeling of hypermedia associations in [66]. Before describing Saberel further, we quickly review the major distinctions between semantic and traditional database approaches.

4.1.1 Semantic Database Models. Traditional database management approaches tend to emphasize information structures that promote efficient storage and retrieval of fixed information structures. For example, the relational, hierarchical, and network models use a simple record-based format. These approaches generally lack direct support for relationships, data abstraction, inheritance, constraints, and unstructured objects [40, 48].

In the past several years, however, greater

consideration has been given to the user’s perception of data rather than its physical representation. This has resulted in a requirement for richer, more expressive data structuring capabilities and has led to a renewed interest in semantic data models. Semantic models attempt to provide more powerful abstractions for structuring complex objects than are supported by traditional models. Although a detailed consideration of semantic modeling is beyond the scope of this paper, excellent reviews can be found in [43, 59, 60].

4.1.2 Saberel. The Saberel Semantic Network Database System is representative of a family of "binary" semantic models [1, 12, 24, 37, 68], all of which represent data using two primary constructions: entity sets and binary relationships. As we will show later on, schemas of these models generally consist of labeled nodes for entity sets and labeled arcs corresponding to binary relationships between them.

1

Saberel is not a product.


6

HB1: Initial Design and Implementation of a Hyperbase Management System Saberel supports atomic objects, called subjects. Subjects can carry a printable name and any arbitrary size string of data, referred to as a user managed string or UMS. Virtually all of Saberel’s higher-level abstractions are derived from subjects. For example, entity sets, or categories are themselves subjects as are relationship names. As a result, the semantic distinction between objects, types, and attributes is not directly enforced by Saberel’s modeling primitives. Each binary relation is viewed as an inverse pair of single-valued functions. Saberel subjects are stored in a repository and can be partitioned among any number of lockable areas.

Repositories and areas are

implemented as Unix files, and, while they assist the user in organizing a Saberel database, they do not participate as abstractions in Saberel’s semantic model. Saberel does not support type constructors, ISA relationships, or derived schema components and enforces few combining restrictions or integrity constraints. The philosophical approach of Saberel, and similar models, is to provide a small, universal set of constructs that can be used to build more powerful structures [34, 35]. These models tend to be "minimalist" in the sense that they require the database designer to understand fewer constructs [43]. The benefit to us has been that such an approach makes it relatively easy to add behavioral layers to an essentially structural database of information. Saberel has two programming interfaces: a low-level procedural interface to the library routines that implement a Saberel database and a declarative, high-level language that can be precompiled into C applications. Up to now, Saberel applications have required little sharing of data. Consequently, the system has not supported distribution or transaction management at the database level. One of our objectives has been to extend Saberel functionality by creating a network-accessible server interface to the system. HB1’s Object Manager and Association Set Manager subsystems are the first two such interfaces we have developed. We comment further on our use of Saberel in [66].

4.2

Object Manager

HB1’s Object Manager is a server process that provides persistent and sharable storage for applications. As shown in Fig. 5, OM is built on top of HB1’s Storage Manager and provides an IPC interface to clients. OM, in effect, manages an IDEA repository of unstructured objects.


7

HB1: Initial Design and Implementation of a Hyperbase Management System 4.2.1 OM Data Model. HB1 objects are simple.

They are arbitrary size byte strings having

unique identity and optional type and name attributes. We avoided implementing objects with execution semantics because we wanted our server to be lightweight and general [57]. HB1 objects have no class structure, methods, or inheritance, but these mechanisms could readily be built on top of OM. Each object in the database has a unique, 32-bit identifier (OID). OIDs are sequentially allocated by the server upon request from clients creating objects. The OIDs of deleted objects are not reused since references to the objects may remain in the database. Applications use objects by copying them from the server into the virtual memory space of their own processes where they are manipulated locally and written back to the server. At the present time, only basic back-end operations such as create, delete, store, retrieve, and attribute operations are implemented. OM, at this point, does not support transaction management, concurrency control, ownership or access control, or assure database integrity in the event of failures.

4.2.2 Semantic Modeling of OM Data. Fig. 6 shows the way Object Manager data are modeled by the Storage Manager.

Three subject categories are explicitly represented in the database:

OBJECT, NAME, and TYPE. The chunks of memory that constitute objects in our system are members of the OBJECT category. Ovals in Fig. 6 represent Saberel subjects, and, in this instance schema, we show the binary relationships that exist between example subjects in each category.

4.3

Association Set Manager

The Association Set Manager is a server process that provides persistent and sharable storage for Associations and manages their run-time representation in support of a link services subsystem. To clarify what is meant by this, we must first explain ASM’s data model. In the Appendix, we present a formal definition for Association. Here, we provide an informal description along with an example. ASM manages the structural or connectivity data applicable to those objects within OM’s repository that are involved in hypermedia associations. In a sense, it manages the static, backing store representation of hypermedia. ASM is built on top of HB1’s Storage Manager and provides its own IPC interface to clients (Fig. 5).


8

HB1: Initial Design and Implementation of a Hyperbase Management System 4.3.1 ASM Data Model.

In Fig. 7, we present an example of inter-application linking. Here, a

hypermedia connection exists between persistent selections in two different components each of which is handled by a different application. The persistent selections, components, and applications all have unique IDs. AppIDs and CompIDs correspond to the OIDs for these objects on backing store. That is to say, these identifiers are generated and maintained by HB1’s Object Manager, and the objects are stored in the Storage Manager’s repository. Like AppIDs and CompIDs, AnchorIDs and LinkIDs correspond to the OIDs for these executable objects. PSIDs are generated and managed by applications, and the scope of their uniqueness extends only to the components in which they reside. The other IDs are unique across the world served by HB1. To represent the structural information involved in such a connection, ASM’s data model defines three collections of IDs: Bridges, Sides, and Associations (Fig. 7). A Bridge consists of a {PSID, CompID, AppID} triple and imparts global uniqueness to a PSID. It is a bridging collection of IDs in the sense that the triple spans the distinct address domains managed by HB1 and individual applications. An AnchorID associated with one or more Bridge triples forms a Side. Finally, the connection is completed by a LinkID being associated with two or more Sides. This is called an Association. The set of associations available at a given moment defines a context, hence the server’s name. Notice that our definition allows inter-application linking to occur at the level of anchors and at the level of links. For example, Fig. 8 shows a more complex association that is readily supported by HB1.

4.3.2 Semantic Modeling of ASM Data. Fig. 9 is a semantic schema showing how Association Set Manager data are modeled by the Storage Manager. It is important to understand that the OM and ASM operate on the same Saberel repository, although OM objects reside in a different area than ASM’s data. Fig. 9 is a complete instance schema for the simple linking example of Fig. 7. The shaded area in Fig. 9 corresponds to the OM schema in Fig. 6, and the subjects and relations lying outside the shaded region are the part of the schema manipulated by ASM. This example shows quite graphically how information, structure, and behavior have been separated in HB1. The OBJECT category in Fig. 9 contains applications, components, links and anchors as well as other objects handled by OM. In addition, ASM uses the categories PSID, BRIDGE, SIDE, and


9

HB1: Initial Design and Implementation of a Hyperbase Management System ASSOCIATION. ASM stores any PSIDs involved in connections in the PSID category. Subjects in the BRIDGE category tie together objects identified by {PsID, CompID, AppID} triples. Subjects in the SIDE category reference BRIDGEs that have been grouped together by anchor attachment, and ASSOCIATION subjects join SIDEs that have been grouped by link attachment. It is important to notice that the Storage Manager, by virtue of its underlying semantic database, directly represents associations among linked objects in our system. Or, said another way, the collection of IDs that define BRIDGE, SIDE, and ASSOCIATION entities need not be repeated in the database because these Saberel subjects have relationships that point directly to the objects involved.

The

connectivity information maintained by the Association Set Manager, in effect, overlays the object structure maintained by the Object Manager. At the present time, only basic operations such as attach and detach anchor and link are supported by ASM. In addition, a follow link operation accepts a {PSID, CompID, AppID} triple and returns the identifiers of all objects that are reachable from the input triple. This query supports traversal operations.

ASM, like OM, does not currently support transaction management, concurrency

control, ownership or access control, or assure database integrity in the event of failures. Next, we give an example of how HB1 might be used.

4.4

HB1 Operation

HB1 currently backends the SP1 hypermedia system prototype. SP1 allows hypermedia connections to be forged among applications that are able to participate in our distributed link services protocol. Its functional capabilities are realized by client/server relationships among Participating Applications, the Link Services Manager, and HB1’s Object Manager and Association Set Manager servers (Fig. 5). The Link Services Manager (LSM) is a server process that provides run-time support for inter-application linking. Specifically, it coordinates the interprocess communication required to implement the hypermedia functionality of Participating Applications.

Participation, in short,

requires that applications be able to handle persistent selection and respond appropriately to messages from the LSM. A more complete description of the SP1 prototype and its Participating Applications can be found in [29] and a forthcoming publication.


10

HB1: Initial Design and Implementation of a Hyperbase Management System Although the details of SP1’s overall behavior is beyond the scope of this paper, the basic notion is that hypermedia connections can be authored and browsed through coordinated events between Participating Applications and the Link Services Manager. As shown in Fig. 5, Participating Applications communicate with HB1’s Object Manager and the LSM, and the LSM communicates with HB1’s Object Manager and Association Set Manager. The messages that pass among the various components of the architecture essentially consist of type information and IDs.

4.5

Implementation

The software components in HB1 and SP1 are written in C. The Link Services Manager and Participating Applications port to Unix variants on a range of platforms. We presently have versions running under IBM AIX on RS/6000 workstations and under SunOS on a variety of Sun 4 workstations. LSM is a decentralized server and can be allocated to any physical processor in our LAN as can Participating Application processes. HB1’s Object Manager and Storage Manager are implemented as independent processes, however, they are centralized to a dedicated RS/6000 node on which the Storage Manager’s Saberel repository resides. In order to achieve heterogeneous distribution across a wide range of platforms, a suite of message passing IPC protocols were implemented using X Window System interclient communication facilities. It is possible for client processes on other networked workstations to access LSM and HB1 servers by using these protocols. All messaging is bidirectional and synchronous. To facilitate construction of the various client and server modules, we developed the X Link Services (Xlt) Toolkit. As shown in Fig. 5, processes that wish to communicate with one another bind liaison procedures from the Xlt Toolkit into their virtual memory space. Clients then make calls on these routines in order to communicate with servers and servers, in turn, use Xlt routines to reply [29]. These liaison procedures provide functional interfaces that abstract from details of the underlying communication protocol.

4.6

Summary

In this Section, we have shown how the HB1 hyperbase management system supports inter-application linking within a non-monolithic, distributed hypermedia system architecture.


11

HB1: Initial Design and Implementation of a Hyperbase Management System Rudimentary object serving is provided by HB1’s Object Manager. The Association Set Manager serves connectivity information to specialized clients such as a Link Services Manager. The Storage Manager is a semantic network database system which, among other things, facilitates HB1’s management of structural relationships among objects. HB1 is providing effective support for the SP1 prototype which instantiates several next-generation hypermedia system features.

5.

DISCUSSION

HB1 and SP1 represent significant departures from the way hypermedia systems are currently conceived and implemented. In this Section, we take a closer look at some of the features that make our approach distinctive.

5.1

HB1 Data Model

HB1’s data model can be distinguished from current hypermedia models by three interrelated characteristics: (1) it defines a distinctly computational view of hypermedia, (2) it has a strong notion of both anchor and link, and (3) it makes a sharp distinction between structure and behavior. Recall that in HB1 anchors and links are processes that implement behaviors, associations are structural entitites that capture connectivity, and all three − anchors, links, and associations − have first class status. We comment on anchors first. Only a few existing systems incorporate a notion of anchor, and Intermedia [77] typifies the view. Here, anchors are essentially data structures that specify the endpoint of a link. While these endpoints can be many things including a span of text, coordinate locations, a series of animation or video frames, or even bytes in a sound buffer, anchors in Intermedia are essentially addresses or parameters [58, 69, 77]. Several recently proposed data models also include a concept of anchor. The Dexter hypertext reference model [39] and the data models of Lange [50] and Afrati and Koutras [6] − all of which have not yet been implemented − propose anchors very much like those found in Intermedia. Anchors, as perceived by most people today, correspond closely to persistent selections in HB1’s model.


12

HB1: Initial Design and Implementation of a Hyperbase Management System Our rationale for a strong, computational view of anchors will be elaborated in a future publication. Simply put, we believe anchors are an appropriate locus for several classes of behaviors that are only indirectly related to traversal. For example, anchors can cooperate with application processes to customize views, filter information, coordinate searches, or even monitor events that may happen in the future. Since they are arbitrary processes, anchors can do simple tasks or be as complex as a database system, expert system, or other specialized class of system. HB1’s data model is also distinctive in the way it abstracts the behavioral aspects of hypermedia from structure. Until now, advanced designs have tended to focus on abstracting structure from information. They have done so in order to achieve architectural advantages such as the ability to implement contexts [69, 77]. Since these designs have typically been translated into monolithic applications, it has generally been the case that behaviors become encapsulated within the systems themselves. For example, Intermedia separates connectivity data from information, but traversal behaviors are implemented within Intermedia’s applications [69, 77].

Among emerging data

models, those of the Dexter group [39], Lange [50], Afrati and Kourtas [6], Schutt and Streitz [67], and Wiil and Osterbye [74] all abstract structure from information but do not explicitly abstract structure from behavior. There is an important rationale for removing addressing data from anchors and links: doing so supports the massive distribution of hypermedia functionality and, more importantly, facilitates the implementation of operations that are essentially structural. A number of these operations − such as computing virtual structures, constructing graphical overviews, and performing structural searches − are recognized to be crucial next-generation features [38]. Current models are often inclined toward monolithic implementation. As a consequence, the global structure of hypermedia tends to be relatively inaccessible and behaviors are not easily modified or extended [66]. Our data model is intended to encourage implementation approaches that avoid encapsulating structural information with structure-independent behaviors. It is also intended to promote extensibility of hypermedia functionality. Finally, a comment on our computational bias. When anchors and links become arbitrary processes in a hypermedia architecture the potential of these systems is enormously increased. It moves hypermedia systems from the class of "interesting" applications toward operating systems and other


13

HB1: Initial Design and Implementation of a Hyperbase Management System software in the class of systems support. In fact, we see computation as ultimately allowing hypermedia systems to achieve their potential as a new operating paradigm for computing.

5.2

HB1 Architecture

HB1’s architecture reflects the structure/behavior separation present in the data model it instantiates. The Object Manager contains the executable objects that implement anchor and link behaviors as well as other types of objects. The Association Set Manager, on the other hand, only manages operations affecting structure.

These two subsystems are built on top of a semantic network

database Storage Manager that is able to satisfy their respective requirements for unstructured objects and inter-object relationships. We designed HB1 to be modular at the subsystem level. The Association Set Manager process, for example, could ultimately be designed to run on hardware specialized to accommodate its structure processing needs. Currently, we are using a semantic database system as our Storage Manager. Since semantic modeling is particularly well suited for capturing structural information, it is not surprising that we have found it useful for representing hypermedia connections. However, this component could easily be replaced by a relational, object-oriented, or perhaps even a heterogeneous DBMS. As configured, HB1 is storing both objects and connectivity information. We have done this in order to simplify the problem of referential integrity − the Object Manager and Association Set Manager can cooperate in maintaining a consistent database. It would be entirely possible to configure the system to manage only connectivity data and use the underlying Unix file system or some other DBMS to store objects. Fig. 10 illustrates some of the alternative ways connectivity information could be managed by HB1. The ease with which HB1 can be modified makes it a particularly useful vehicle for research on HBMS organization.


14


RELATED WORK

There is increasing interest in the issue of providing effective database support for hypermedia. In this Section, we show how the work we are doing relates to research appearing in the hypermedia and database literature.

6.1

Related Work in Hypermedia

It is probably fair to say that work on hyperbases began with the Hypertext Abstract Machine (HAM). HAM is a general-purpose, transaction-based, multi-user server for a hypermedia storage system [14]. It has been used as a backend to the Neptune system [25]. From what we can infer from the literature, its low-level storage system is equivalent in many respects to the Saberel Semantic Network Database System we have used as HB1’s Storage Manager.

HAM’s data model is based on five objects: graphs, contexts, nodes, links, and attributes. Nodes are usually text but can be arbitrary strings of information such as digitized sound or graphics. Links connect nodes to form graphs. Attributes can be attached to nodes and links thereby allowing HAM to perform operations on uniquely identifiable subgraphs or contexts. The system maintains history for these objects, allows selective access through filtering, and implements a data security mechanism. HAM performs many of the same operations implemented by HB1’s servers. There are, however, several subtle but important differences. For the most part, these reflect differences in the intended use of the two systems. HAM was designed to support monolithic, hypermedia-based CAD and CASE applications.

As a result, its data model corresponds to the hypermedia abstractions

envisioned in these applications, and it does not make an explicit structure/behavior distinction. It would be difficult, for example, to capture HB1’s computational notion of hypermedia using HAM’s abstractions which are primarily structural. HAM’s monolithic orientation, however, has an even more important effect. It influences the way functionality is partitioned between applications and the database server. For example, HAM’s link objects store internal addressing information about the nodes they reference. A byte address within


15

HB1: Initial Design and Implementation of a Hyperbase Management System a text node can be a link point. Moreover, the HAM server is able to interpret this information when, for example, it performs a "linearize" operation. This is a query in which a depth-first ordering of nodes is obtained given some input starting node. Such an operation is useful for generating printed output, however, implementing it in HAM forces the server to know about application-level abstractions. This would be equivalent to HB1 storing and being able to interpret persistent selection data structures. While the semantics of linearizing text are rather straightforward, it is less clear how they might generalize to multimedia objects such as sound or animation. An important design goal in HB1 was determining the appropriate place to draw the line between application functionality and hyperbase functionality.

In our view, applications are best suited to manipulate the abstractions they

implement. This includes "internal" abstractions such as persistent selection. In HB1, we have partitioned functionality in a way that promotes system-level integration of backend functionality at the expense of being able to perform certain types of operations at the hyperbase level. We see our approach as being more general. This is not to diminish HAM which provides effective support in its intended domain and is clearly the most mature and full-featured HBMS implemented thus far. In addition to HAM, there are two prominent hyperbase projects whose systems carry identical names. The University of Aalborg’s [73, 74] HyperBase is similar to HAM, although it instantiates a simpler data model. In HyperBase, nodes are arbitrary byte strings containing references to link objects which, in turn, reference nodes. Currently, the system provides basic backend services such as storing nodes and links, providing multi-user control, locking, and event handling. Like HB1, it is built on a client/server model and its architecture is intended to be a general foundation upon which a wide variety of hypermedia applications can be built. A special emphasis in this HyperBase project has been database support for collaborative work [74]. Schutt and Streitz’ [67] HyperBase is built on top of the Sybase relational DBMS. In its present form, HyperBase essentially defines an application-independent interface to Sybase. Its data model is organized around nodes, links, and composite objects. Their concept of node and link is similar to that of Wiil and Osterbye’s. Composite objects are arbitrary collections of other HyberBase objects. Object-oriented modeling techniques were used to implement HyperBase, and there are plans to eventually replace Sybase with an object-oriented DBMS. Neither HyperBase system interprets the


16

HB1: Initial Design and Implementation of a Hyperbase Management System internal structures of their node objects. Additionally, neither support a concept of inter-application linking. Beyond these three projects, database research in the hypermedia community appears to be less focused. This is due in part to the wide range of interests motivating research in the field. We begin this part of our summary by returning to Intermedia. Most current generation hypermedia systems implement backend functionality themselves without the support of a commerical DBMS [45]. Intermedia is a notable exception [69, 77]. Earlier versions of Intermedia were implemented on top of the INGRES relational DBMS [70]. In fact, one of the important contributions of the IRIS/Intermedia project has been an analysis of the applicability of relational and object-oriented (OO) methods to hypermedia databases.

They

concluded that an OO approach would provide a better facility for modeling complex structures [69]. As part of this work, an OO database schema for Intermedia was developed, however, the transition to an OO DBMS never occurred. Similarly, work on formal models is contributing to hyperbase design.

Lange’s [50] formal

specification of an object-oriented model of hypermedia is being used to develop a hyperbase. Here, three main abstractions are defined: nodes, networks, and structures. Nodes are units of information, networks link nodes together, and structures organize nodes and links into unique ordered collections. These abstract data types are being incorporated into the object-oriented database paradigm to create an object-oriented hyperbase. Tompa [71], on the other hand, has proposed a hypergraph data model for maintaining page-oriented databases. The model is organized in such a way that some of the functionality traditionally provided by database schemas can be extended to hypertext databases. Although this approach has not been implemented, Tompa [71] outlines an efficient representation for the model. Bellcore’s Telesophy system has focused on providing network transparent access to distributed, multimedia objects [15]. Telesophy is a hypermedia system used to integrate information imported from sources such as the New York Times, AP Wire Service, Usenet, Internet newsgroups, and Bellcore internal information. Objects stored on multiple servers are used to represent, query, display, and edit information. Network access to these objects is mediated by indexing servers


17

HB1: Initial Design and Implementation of a Hyperbase Management System layered on top of Telesophy’s storage system. This project represents one of the largest scale applications of hypermedia system technology to date, and it has revealed several important requirements for distributed, object-based system architectures. Curiously, many important hyperbase requirements have been identified in research that has focused primarily on database performance evaluation.

The HyperModel Benchmark [11] is an

application-oriented approach to evaluating and benchmarking object-oriented DBMSs aimed at engineering environments. Hypermedia was chosen as the basis for the evaluation strategy because the requirements it places on a DBMS are similar to other kinds of engineering applications. Employing the HyperModel Benchmark to evaluate hyperbase performance is an obvious use that has yet to be explored.

So far, it seems that the greatest amount of database-related work appearing in the hypermedia literature pertains to the issue of data access. Several research projects are extending information retrieval techniques to hypermedia [13, 19, 22, 23, 31, 32, 51, 52].

Others are developing

formalisms to support structural queries [6, 9, 21]. Finally, there is a contingent examining ways of effectively combining traditional querying with the type of user-directed browsing that characterizes data access in hypermedia systems [18, 33, 72].

6.2

Related Work in Database

Fortunately, this does not represent the sum of work relating to hyperbases. In the database area, several advancing fronts will undoubtedly shape the future design of these systems. Research on object-oriented databases, multimedia information systems, and the development of semantic object-oriented databases seem particularly relevant. Here, we comment briefly on work that has influenced our thinking in the design of HB1. The object paradigm is currently of enormous interest to the database community. For a discussion of issues and research efforts pertaining to object-oriented database systems, see [36, 49]. Of particular relevance to us has been work on the data modeling and access requirements of multimedia applications [17, 75, 76]. In addition, the problems posed by transaction management and version control in VLSI CAD and CASE environments appear to be similar to those in


18

HB1: Initial Design and Implementation of a Hyperbase Management System hypermedia systems [7, 46, 47, 53, 54]. Other object-oriented database implementations designed to support extensibility are described in [8, 16, 55], and issues relating to object-based system architectures are considered in [26, 44, 57, 61]. Perhaps most important to us, however, is the recent trend toward integrating behavioral and structural modeling techniques in the design of object-oriented databases. Semantic models attempt to provide structural abstractions; object-oriented models provide behavioral abstractions. In HB1, the Association Set Manager is, in effect, a behavioral layer that has been applied to structure. We feel that few applications are better able to realize the natural synergy that exists between semantic and object-oriented paradigms than hypermedia. An overview of existing object-oriented databases is presented in [27, 40]. Semantic models are described in [43, 56, 59, 60]. Finally, integrated structural object-oriented systems are described in [10, 27, 41, 42, 63].

7.

FUTURE WORK

Advanced hypermedia environments pose several unique data management problems. As a result, hyperbases are emerging as an important new area of research. Our work represents an initial effort to address some of these problems, and significant additions and refinements are clearly required before either SP1 or HB1 become practical. Mature hyperbase management systems must, of course, provide for permanence of data across a wide range of data types. In addition, they must be able to manage the information contained in hypermedia as well as the connectivity data that gives it its structure. For each of these domains, HBMSs must implement an appropriate notion of transaction, controlled sharing, versioning, context, distribution, query, extensibility, performance, and backup and recovery. Ideally, HBMSs should be portable across a wide range of systems and should provide an effective platform for further research. HB1 lacks much of the above functionality. Future work will be directed toward addressing the system’s current shortcomings. In particular, we are interested in examining how existing database techniques could apply to the data management problems of hypermedia systems if suitably adapted.


19


SUMMARY

The unique data management requirements of advanced hypermedia systems require capabilities that are not generally provided by the current generation of database management systems. In this paper, we have described the initial design and prototypic implementation of a hyperbase management system intended to address some of these needs.

The prototype, HB1, implements several

distinguishing features. For example, the system: • • • • •

meets the storage requirements of an extensible, object-based system architecture for distributed, inter-application linking; makes a sharp distinction between structure and behavior; is composed of two network-accessible server processes: one providing object management, the other managing hypermedia connectivity information; uses a semantic network database system to manage physical storage; is a useful vehicle for general research on HBMS organization.

HB1 is demonstrating its effectiveness by providing backend services to an advanced hypermedia system prototype currently under development in the Hypertext Research Laboratory at Texas A&M University. Experiences gained so far in this work have been used to identify several important issues to be addressed in future HBMS research. These include adapting existing techniques for transaction management, sharing, and versioning to the management of hypermedia information and connectivity data.

ACKNOWLEDGMENTS The authors would like to thank the team that constructed the software described in this paper: Ron Szabo, Peter Nuernberg, Doug Miller, Joe Drufke, Don Dylla, and Tim Roden. Thanks also to Ed Cunnius for help with figures and to Cindy Kunz for help preparing the manuscript. Bob Griffith, Jeff Barber, and Ken Briskey provided valuable assistance in our work with Saberel.


20

HB1: Initial Design and Implementation of a Hyperbase Management System REFERENCES 1.

Abrial, J. R. Data semantics. In Data Base Management, J. W. Klimbie and K. L. Koffemen, (Eds.), North-Holland, Amsterdam, (1974), pp. 1-59.

2.

ACM. Proceedings of the Hypertext ’87 Conference, (Chapel Hill, NC), (Nov. 1987).

3.

ACM. Special Issue on Hypertext. CACM 31, 7 (July 1988).

4.

ACM. Proceedings of the Hypertext ’89 Conference, (Pittsburgh, PA), (Nov. 1989).

5.

ACM. Special Issue on Hypertext. ACM Trans. Off. Inf. Syst. 7, 1 (Jan. 1989).

6.

Afrati, F., and Koutras, C. A hypertext model supporting query mechanisms. In Hypertext: Concepts, Systems, and Applications. Proceedings of the European Conference on Hypertext, (France), A. Rizk, N. Streitz, and J. Andre, (Eds.), Cambridge University Press, Cambridge, U.K., (Nov. 1990), pp. 52−66.

7.

Batory, D., and Kim, W. Modeling concepts for VLSI CAD objects. ACM Trans. Database Syst. 10, 3 (Sept. 1985), 322−346.

8.

Batory. D. S., Barnett, J. R., Garza, F. F., Smith, K. P., Tsukauda, K., Twichell, B. D., and Wise, T.E. GENESIS: A reconfigurable database management system. IEEE Trans. Softw. Eng., (Nov. 1990), 1258-1272.

9.

Beeri, C., and Kornatzky, Y. A logical query language for hypertext systems. In Hypertext: Concepts, Systems, and Applications. Proceedings of the European Conference on Hypertext, (France), A. Rizk, N. Streitz, and J. Andre, (Eds.), Cambridge University Press, Cambridge, U.K., (Nov. 1990), pp. 67-80.

10.

Berre, A. J. SOOM and Tornado-*: Experience with database support for object-oriented applications. In Advances in Object-Oriented Database Systems: Proceedings of the 2nd International Conference on Object-Oriented Database Systems, K. Dittrich, (Ed.), Springer-Verlag, New York, (Sept. 1988), pp. 104-109.

11.

Berre, A. J., and Anderson, T. L. The hypermodel benchmark. In Object-Oriented Databases with Applications to CASE, Networks, and VLSI CAD, R. Gupta and E. Horowitz, (Eds.), Prentice-Hall, Englewood Cliffs, NJ, (1991), 75−91.


21


12.

Bracchi, G., Paolini, P., and Pelagatti, G. Binary logical associations in data modelling. In Modelling in Data Base Management Systems, North Holland, Amsterdam, (1976), pp. 125-148.

13.

Bruza, P. D. Hyperindices: A novel aid for searching in hypermedia. In Hypertext: Concepts, Systems, and Applications. Proceedings of the European Conference on Hypertext, (France), A. Rizk, N. Streitz, and J. Andre, (Eds.), Cambridge University Press, Cambridge, U.K., (Nov. 1990), pp. 109-122.

14.

Campbell, B., and Goodman, J. HAM: A general-purpose hypertext abstract machine. Commun. ACM 31, 7 (July 1988), 856-861.

15.

Caplinger, M. An information system based on distributed objects. OOPSLA ’87 Conference, (October 1987), pp. 126-137.

16.

Carey, M., DeWitt, D., Richardson, J., and Shekita, E. Object and file management in the EXODUS extensible database system. Proceedings of the Twelfth International Conference on Very Large Data Bases, (Kyoto, Japan), (August 1986), pp. 91-100.

17.

Christodoulakis, S., Theodoridou, M., Ho, F., Papa, M., and Pathria, A. Multimedia document presentation, information extraction, and document formation in MINOS: A model and a system. ACM Tran. Off. Inf. Syst. 4, 4 (October 1986), 345-383.

18.

Clifton, C., and Garcia-Molina, H. Indexing in a hypertext database. Proceedings of the 16th Conference on Very Large Data Bases, (Brisbane, Australia), (August 1990), pp. 36-49.

19.

Clitherow, P., Riecken, D., and Muller, M. VISAR: A system for inference and navigation of hypertext. Proceedings of the Hypertext ’89 Conference, (Pittsburgh, Pa.), (November 1989), pp. 293-304.

20.

Conklin, J. Hypertext: An introduction and survey. Computer 20, 9 (Sept. 1987), 17-41.

21.

Consens, M. P., and Mendelzon, A. O. Expressing structural hypertext queries in GraphLog. Proceedings of the Hypertext ’89 Conference, (Pittsburgh, Pa.), (Nov. 1989), pp. 269-292.

22.

Croft, W. B., and Turtle, H. A retrieval model incorporating hypertext links. Proceedings of the Hypertext ’89 Conference, (Pittsburgh, Pa.), (Nov. 1989), pp. 213-224.


Proceedings of the

22


23.

Crouch, D. B., Crouch, C. J., and Andreas, G. The use of cluster hierarchies in hypertext information retrieval. Proceedings of the Hypertext ’89 Conference, (Pittsburgh, Pa.), (Nov. 1989), pp. 225-237.

24.

Deheneffee, C., Hennebert, H., and Paulus, W. Relational model for a database. Proceedings of the IFIP Congress, (1974), pp. 1022-1025.

25.

Delisle, N., and Schwartz, M. Neptune: A hypertext system for CAD applications. Proceedings of the ACM International Conference on the Management of Data (SIGMOD), (1986), pp. 132-143.

26.

DeWitt, D. J., Futtersack, P., Maier, D., and Velez, F. A study of three alternative workstation-server architectures for object oriented database systems. Proceedings of the 16th International Conference on Very Large Data Bases, (Brisbane, Australia), (August 1990), pp. 107-121.

27.

Dittrich, K., and Dayal, U. (Eds.). Proceedings of the International Workshop on Object-Oriented Database Systems, (Pacific Grove, CA), (Sept. 1986).

28.

Dittrich, K. R., Gotthard, W., and Lockemann, P. C. DAMOKLES − A database system for software engineering environments. In Proceedings of the IFIP Workshop on Advanced Programming Environments, (Trondheim, Norway), R. Conradi, R. M. Didriksen, and D. H. Wanvik, (Eds.), Springer-Verlag, New York, (June 1986), pp. 353-371.

29.

Drufke, J. E., Leggett, J. J., Hicks, D. L., Schnase, J. L. 1991. The derivation of a hypertext widget class from the Athena text widget. Department of Computer Science Technical Report No. TAMU 91-002, Texas A&M University, College Station, TX, (1991).

30.

Fishman, D., Beech, D., Cate, H., Chow, E., Connors, T., Davis, J., Derrett, N., Hoch, C., Kent, W., Lyngbaek, P., Mahbod, B., Neimat, M., Ryan, T., and Shan, M. IRIS: An object-oriented database management system. ACM Trans. Off. Inf. Syst., 5, 1 (January 1987), 48-69.

31.

Frisse, M. Searching for information in a hypertext medical handbook. Commun. ACM 31, 7 (July 1988), 880-886.

32.

Frisse, M. E., and Cousins, S. B. Information retrieval from hypertext: Update on the dynamic medical handbook project. Proceedings of the Hypertext ’89 Conference, (Pittsburgh, Pa.), (Nov. 1989), pp. 199-212.


23


33.

Gallagher, L., Furuta, R., and Stotts, P. David. Increasing the power of hypertext search with relational queries. Hypermedia 2, 1 (1990), 1-14.

34.

Griffith, R. L. 1982. Three principles of representation for semantic networks. ACM Trans. Database Syst. 7, 3 (Sept. 1982), 417-442.

35.

Griffith, R. L. 1989. Semantic-network databases for VLSI design. Proceedings of the Seventh British National Conference on Databases (BNCOD 7), (Heriot-Watt University), M. H. Williams, (Ed.), Cambridge University Press, Cambridge, U.K., (July 1989), pp. 5-36.

36.

Gupta, R., and Horowitz, E. Object-Oriented Databases with Applications to CASE, Networks, and VLSI CAD. Prentice-Hall, Englewood Cliffs, NJ, (1991).

37.

Hainaut, J. L., and Lecharlier, B. An extensible semantic model of database and its data language. Proceedings of the IFIP Congress, (1974), pp. 1026-1030.

38.

Halasz, F. Reflections on NoteCards: Seven issues for the next generation of hypermedia systems. Commun. ACM 31, 7 (July 1988), 836-852.

39.

Halasz, F., and Schwartz, M. The Dexter hypertext reference model. In Proceedings of the NIST Hypertext Standardization Workshop, NIST, Gaithersburg, MD, (1990), pp. 95−133.

40.

Horowitz, E., and Wan, Q. An overview of existing object-oriented database systems. In Object-Oriented Databases with Applications to CASE, Networks, and VLSI CAD, R. Gupta and E. Horowitz, (Eds.), Prentice-Hall, Englewood Cliffs, NJ, (1991), pp. 101−116.

41.

Hudson, S. E., and King, R. The Cactis project: Database support for software environments. IEEE Trans. Softw. Eng. 14, 6 (June 1988), 709−719.

42.

Hudson, S. E., and King, R. Cactis: A self-adaptive, concurrent implementation of an object-oriented database management system. ACM Trans. Database Syst. 14, 3 (Sept. 1989), 291-321.

43.

Hull, R., and King, R. Semantic database modeling: Survey, applications, and research issues. ACM Computing Surveys 19, 3 (Sept. 1987), 201-260.

44.

Jazayeri, M. Objects for distributed systems. In Proceedings of the ACM SIGPLAN Workshop on Object-Based Concurrent Programming (San Diego), G. Agha, P. Wegner, and A. Yonezawa, (Eds.), SIGPLAN Notices 24, 4 (April 1989), pp. 117−119.


24


45.

Kacmar, C. J., Leggett, J., Schnase, J. L., and Boyle, C. Data management facilities of existing hypertext systems. Department of Computer Science Technical Report No. TAMU 88-018, Texas A&M University, College Station, TX, (1988).

46.

Katz, R. H. Computer-aided design databases. In New Directions for Database Systems, G. Ariav and J. Clifford, (Eds.), Ablex Publishing Co., Norwood, NJ, (1986), 110-123.

47.

Katz, R. H. Toward a unified framework for version modeling in engineering databases. ACM Computing Surveys 22, 4 (Dec. 1990), 375-408.

48.

Kent, W. Limitations of record-oriented information models. ACM Trans. Database Syst. 4, 1 (March 1979), 107−131.

49.

Kim, W., and Lochovsky, F. Object-Oriented Concepts, Databases, and Applications. ACM Press/Addison-Wesley, Inc., New York, NY, (1989).

50.

Lange, D. A formal model for hypertext. In Proceedings of the NIST Hypertext Standardization Workshop, NIST, Gaithersburg, MD, (1990), pp. 145−166.

51.

Lesk, M. What to do when there’s too much information. Proceedings of the Hypertext ’89 Conference, (Pittsburgh, Pa.), (Nov. 1989), pp. 305-318.

52.

Lucarella, D. A model for hypertext-based information retrieval. Hypertext: Concepts, Systems, and Applications. Proceedings of the European Conference on Hypertext, (France), A. Rizk, N. Streitz, and J. Andre, (Eds.), Cambridge University Press, Cambridge, U.K., (Nov. 1990), pp. 81-94.

53.

Maier, D., Stein, J., Otis, A., and Purdy, A. Development of an object-oriented DBMS. Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), (Sept. 1986), pp. 472-482.

54.

Maier, D. Making database systems fast enough for CAD applications. In Object-Oriented Concepts, Databases, and Applications, W. Kim and F. H. Lochovsky, (Eds.), Addison-Wesley Publishing Co., Reading, MA, (1989), pp. 573−582.

55.

Manola, F., and Dayal, U. PDM: An object-oriented data model. Proceedings of the International Workshop on Object-Oriented Database Systems, (Pacific Grove, CA), (Sept. 1986), pp. 18-25.


25


56.

McLeod, D. A perspective on object-oriented and semantic database models and systems. In Object-Oriented Databases with Applications to CASE, Networks, and VLSI CAD, R. Gupta and E. Horowitz, (Eds.), Prentice -Hall, Englewood Cliffs, NJ, (1991), pp. 12−25.

57.

Moss, J. E. B. Design of the Mneme persistent object store. ACM Trans. Off. Inf. Syst. 8, 2 (April 1990), 103-139.

58.

Palaniappan, M., Yankelovich, N., and Sawtelle, M. Linking active anchors: A stage in the evolution of hypermedia. Hypermedia 2, 1 (Jan. 1990), 47−66.

59.

Peckham, J., and Maryanski, F. Semantic data models. ACM Computing Surveys 20, 3 (Sept. 1988), 153-189.

60.

Potter, W., and Trueblood, R. Traditional, semantic, and hyper-semantic approaches to data modeling. IEEE Computer 21, 6 (June 1988), 53-63.

61.

Purdy, A., Schuchardt, B., and Maier, D. Integrating an object server with other worlds. In Object-Oriented Databases with Applications to CASE, Networks, and VLSI CAD, R. Gupta and E. Horowitz, (Eds.), Prentice-Hall, Englewood Cliffs, NJ, (1991), pp. 216−236.

62.

Rizk, A., Streitz, N., and Andre, J. (Eds.), Hypertext: Concepts, Systems, and Applications. Proceedings of the European Conference on Hypertext, (France), Cambridge University Press, Cambridge, U.K., (Nov. 1990).

63.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. Object-Oriented Modeling and System Design. Prentice-Hall, Englewood Cliffs, NJ, (1990).

64.

Schnase, J. L., Leggett, J., Kacmar, C. J., and Boyle, C. A comparison of hypertext systems. Department of Computer Science Technical Report No. TAMU 88-017, Texas A&M University, College Station, TX, (1988).

65.

Schnase, J. L., Leggett, J. J., and Hicks, D. L. HB1: Initial design and implementation of a hyperbase management system. Department of Computer Science Technical Report No. TAMU-HRL 91-003, Texas A&M University, College Station, TX, (1991).

66.

Schnase, J. L., Leggett, J. J., Hicks, D. L., and Szabo, R. L. Semantic data modeling of hypermedia associations. Department of Computer Science Technical Report No. TAMU-HRL 91-005, Texas A&M University, College Station, TX, (1991).


26


67.

Schutt, H. A., and Streitz, N. A. Hyperbase: A hypermedia engine based on a relational database management system. In Hypertext: Concepts, Systems, and Applications. Proceedings of the European Conference on Hypertext, (France), A. Rizk, N. Streitz, and J. Andre, (Eds)., Cambridge University Press, Cambridge, U.K., (Nov. 1990), pp. 95−108.

68.

Senko, M. Information systems: Records, relations, sets, entities, and things. Inf. Syst. 1, (1975), 3-13.

69.

Smith, K., and Zdonik, S. Intermedia: A case study of the differences between relational and object-oriented database systems. In Proceedings of the ACM OOPSLA ’87 Conference, ACM, New York, (1987), pp. 452−465.

70.

Stonebraker, M., Wong, E., Kreps, P. and Held. G. The design and implementation of INGRES. ACM Trans. Database Syst. 1, 3 (Sept. 1976), 189-222.

71.

Tompa, F. W. A data model for flexible hypertext database systems. ACM Trans. Off. Inf. Syst. 7, 1 (Jan. 1989), 85-100.

72.

Watters, C., and Shepherd, M. A. A transient hypergraph-based model for data access. ACM Trans. Inf. Syst. 8, 2 (April 1990), 77-102.

73.

Wiil, U. K. Design and implementation of a hyperbase. Department of Mathematics and Computer, Institute for Electronic Systems Technical Report No. IR 90-03, The University of Aalborg, Aalborg, Denmark, (1990).

74.

Wiil, U. K., and Osterbye, K. Experiences with HyperBase − A multi-user back-end for hypertext applications with emphasis on collaboration support. Department of Mathematics and Computer, Institute for Electronic Systems Technical Report No. IR 90-38, The University of Aalborg, Aalborg, Denmark, (1990).

75.

Woelk, D., Kim, W., and Luther, W. An object-oriented approach to multimedia databases. Proceedings of the ACM International Conference on Management of Data (SIGMOD), (Washington, DC), (May 1986), pp. 311-325.

76.

Woelk, D., and Kim, W. Multimedia information management in an object-oriented database system. Proceedings of the Thirteenth International Conference on Very Large Data Bases, (Brighton, England), (1987), pp. 319-329.

77.

Yankelovich, N., Haan, B., Meyrowitz, N., and Drucker, S. Intermedia: The concept and the construction of a seamless information environment. Computer 21, 1 (Jan. 1988), 81-96.


27

HB1: Initial Design and Implementation of a Hyperbase Management System APPENDIX: HB1 SPECIFICATION In this Appendix, we formalize the data model underlying HB1 by showing its high-level type structure. Our notation generally follows the Vienna Development Method (VDM) where data types are modeled as sets [Jones 1986*]. If we let A and B be sets, then A × B denotes the Cartesian product of A and B. The suffix "-set" appended to a set name creates the powerset for that type. That is, the set of all the sets, including the null set, that could be constructed using elements of the finite base set. The notation "(_×_×_× _)" refers to an ordered n-tuple, and "A | B" means A or B. To simplify the presentation, we show only type clauses for function specifications. These state the types of the input and output parameters and have the following form: functionName: operand1 × operand2 × ... × operandn → result0 × result1 × result2 × ... × resultm where n ≥ 1 and m ≥ 0, and each operandi and resultj has a type. Result0 is implicit in all operations and returns a Boolean value of either True or False to indicate whether the operation was successful. A.1 HB1 Types A.1.1 Object Manager Simple Types 1.0

Object

An arbitrary size string of bytes.

2.0

OID

Unique identifier for an Object.1

3.0

Type

Type attribute of an Object.

4.0

Name

Name attribute of an Object.

A.1.2 Association Set Manager Simple Types 5.0

Persistent Selection

An element of information, such as text, an image, sound, etc., that is distinguished in such a way that it can be accessed at another time.

6.0

PSID

Unique identifier for a Persistent Selection.2

7.0

Component

Generally thought of as a non-executable entity, such as text or a bitmap, that may be acted upon by Applications, such as a text or bitmap editor.

8.0

CompID

Unique identifier for a Component.3

9.0

Application

An executable entity, such as a program.


28


10.0 AppID

Unique identifier for an Application.3

11.0 Anchor

An executable entity that implements Anchor behaviors.

12.0 AnchorID

Unique identifier for an Anchor.3

13.0 Link

An executable entity that implements Link behaviors.

14.0 LinkID

Unique identifier for a Link.3

A.1.3 Association Set Manager Structured Types 15.0 Bridge

:: ( PsID × AppID × CompID ) ⏐ ( PsID × AppID ) A Bridge is an ordered 3-tuple or 2-tuple of identifiers that projects global uniqueness onto a PSID. Applications that either manage CompIDs themselves or compute PSIDs in the absense of Components may need only a {PsID, AppID} double to uniquely identify Persistent Selections.

16.0 Side

:: Bridge × Bridge-set × AnchorID An AnchorID associated with one or more Bridges forms a Side of an Association.

17.0 Association

:: Side × Side × Side-set × LinkID A LinkID associated with two or more Sides forms an Association.

18.0 Context

= Association-set. A Context is some subset of all Associations.

A.2 HB1 Functions A.2.1 Object Manager Functions 19.0 createObject: Object × Name × Type → OID Creates a new object on backing store. All input parameters are optional. If no object is provided with the call, then the function simply returns a new OID.


29


20.0 deleteObject OID → Deletes an existing object from backing store. 21.0 retrieveObject OID → Object Retrieves an object from backing store. 22.0 storeObject Object × OID → Replaces the existing backing store image of an object with Object. 23.0 getName OID → Name Retrieve the value of an object’s Name attribute. 24.0 setName Name × OID → Set the value of an object’s Name attribute 25.0 getType OID → Type Retrieve the value of an object’s Type attribute. 26.0 setType Type × OID → Set the value of an object’s Type attribute. A.2.2 Association Set Manager Functions 27.0 attachAnchor: Bridge × Bridge-set × AnchorID → Side The attachAnchor operation causes one or more Bridge triples (or doubles) to be associated with an AnchorID. The collection of IDs forms a Side. 28.0 attachLink: Side × Side × Side-set × LinkID → Association The attachLink operation causes two or more Sides to be associated with a LinkID. The collection of IDs forms an Association. 29.0 detachAnchor: Bridge × Bridge-set → Bridge-set 30.0 detachLink: Bridge × Bridge-set → Bridge-set The detach operations undo the effects of their respective counterparts. Both are similar in that one or more input Bridges are used to identify the Sides to be deleted. These operations assure that no incomplete Sides or Associations remain in the database. Both operations return zero or more Bridges that have been unanchored and/or unlinked.


30


31.0 followLink:

Bridge → Link × Side × Side-set

The followLink operation supports browsing functionality. An input Bridge is used as a starting point for a search. The search returns the LinkID of the Link reachable from the input Bridge as well as AnchorIDs and Bridges on any "other" Sides of the Link. This function, in effect, determines what is reachable in the hypermedia from some input {PSID, CompID, AppID} triple or {PSID, AppID} double.

1 In HB1, this ID is generated by the Object Manager, and the scope of its uniqueness extends to the world that is known to HB1. 2

PSIDs are generated by the Applications that operate on the Components in which the PSIDs reside. The scope of their uniqueness extends locally to those Components. 3

In HB1, Applications, Components, Anchors, and Links have unique object identity on backing store. AppIDs, CompIDs, AnchorIDs, and LinkIDs are the respective objects’ OIDs.

* Jones, C. B. 1986. Systematic Software Development Using VDM. Prentice-Hall, Englewood Cliffs, NJ.


31

©1991. Hypertext Research Lab.

Association Set Manager (ASM)

Figure 1. HB1 hyperbase system architecture.

UNIX File System

Storage Manager (SM)

Object Manager (OM)

The HB1 Hyperbase Management System


In Cassin’s Sparrow, territorial defense is the responsibility of the male and primarily involves the allocation of energy resources with little associated risk. Egg production, requiring energy, and incubation, requiring time, are done entirely by the female. Feeding of offspring demands time and energy and appears to be skewed toward the female during both the nestling and fledgling care phases.

-0.67d

86.59

1 + 19.1 e-0.67{d-1}

⎫ ⎭

-1 − ⎯⎯⎯⎯⎯⎯⎯ ÷ 0.75 ÷ 1440 kJ⋅min

(16)

Table 10 presents results of simulating the nestling model for 1 chick over the nesting phase’s 9-day duration. Assuming an average clutch size of 2.2 (13 fledglings ÷ 6 males), an additional 716 kJ (325 kJ × 2.2) was required for nestling development. This translates into an arthropod requirement of 158 g. Over the same 9-day period, a female would require a total of 117 g of arthropods for her own energetic needs. Therefore, if females were entirely responsible for feeding young, it was necessary for them to augment their foraging an average of 135% ((117 + 158) ÷ 117), considerably more than the 87% increase observed in Savannah Sparrow where both sexes participate in the feeding effort (Williams, 1987).

86.59 ⎧⎯⎯⎯⎯⎯⎯ ⎩ 1 + 19.1 e

H′p(d) =

Assuming a production efficiency of 75% (Ricklefs, 1974), the rate of production (H′p ) per min at age d is:

(3) How much additional food was required to raise young?

Figure 2. A simple linking example.

Figure 1. Cassin’s Sparrow fledgling foraging in a Honey mesquite tree (Prosopis glandulosa).

xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx

Parental investment may be defined as "any investment by the parent of an individual offspring that increases the offspring’s chance of surviving at the cost of the parent’s ability to invest in other offspring (Trivers, 1972). Although it is difficult to distill a single metric to represent the time, energy, and risk associated with parental investment, a rough estimate can be obtained by considering the combined qualitative and energetic contributions of parents to the reproductive effort (Biedenweg, 1983).


Component

Figure 3. Conceptual model of hypermedia underlying HB1.

Component


xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx

xxxxxxx xxxxxxx xxxxxxx


Application

Participating Applications

Link Services Subsystem

Anchor

Application

Anchor

Association

Link


12FA:008C

00000004

0000:0000

0

•••

1

1

0

Figure 4. Component and persistent selection data structure. In this case, we see a Persistent Selection Table.

Figure 1. Cassin’s Sparrow fledgling foraging in a Honey mesquite tree (Prosopis glandulosa).

xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx

the cost of the parent’s ability to invest in other offspring (Trivers, 1972). Although it is difficult to distill a single metric to represent the time, xxxxxxxxxxxxxxx energy, and risk associated withxxxxxxxxxxxxxxx parental investment, a rough estimate xxxxxxxxxxxxxxx can be obtained by considering the combined qualitative and energetic contributions of parents to the reproductive effort (Biedenweg, 1983). In Cassin’s Sparrow, territorial defense is the responsibility of the male and primarily involves the allocation of energy resources with little associated risk. Egg production, requiring energy, and incubation, requiring time, are done entirely by the female. Feeding of offspring demands time and energy and appears to be skewed toward the female during both the nestling and fledgling care phases.

0

1

•••

xxxxxxxxxxxxxx xxxxxxxxxxxxxx Parental investment may be defined as "any investment by the parent of xxxxxxxxxxxxxx an individual offspring that increases the offspring’s chance of surviving at

n

•••

RasterSelect(fig1,x,y,001B)

00000003

•••

014A:0013

00000002 1

1

1 1

0

0

0000:0013

Link Bit

0021:0003

Anchor Bit

00000001

PS Value

00000000

PS ID


Motif

Xlib Interface

X Toolkit

xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx

Xlt_ASM Liaison Functions

xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx

Xlt_ASM Liaison Functions


xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx

Association Set Manager (ASM)

The HB1 Hyperbase Management System

Storage Manager (SM)

xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx

Object Manager (OM)

xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx Xlt_OM xxxxxxxxxxxx Liaison Functions xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx

Figure 5. System architecture for the SP1 hypermedia system prototype.

X Network Protocol & Base Window System

xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx

UNIX Operating System

Front-end

Xlt_LSM Liaison Functions

Xlt_OM Liaison Functions

Participating Applications

xxx xxx Xlt_LSM xxx xxx Liaison Functions xxx xxx xxx Xlt_OM xxx Liaison Functions xxx xxx xxxxxxxxxxxx xxx xxxxxxxxxxxx xxxxxxxxxxxx xxx xxx

Link Services Manager (LSM)


HasType IsTypeOf

HasName IsNameOf

Wanda

NAME

Text

Executable

Bitmap

Graphics

TYPE

Figure 6. An instance schema showing how Object Manager objects are modeled by HB1’s Storage Manager.

00000004

00000003

00000002

00000001

HasMember IsMemberOf

OBJECT

Bridge


Side

CompID 4

Figure 7. Simple example of inter-application linking showing ASM‘s 3 major abstractions.

CompID 1

PSID 28


xxxxxxx xxxxxxx xxxxxxx PSID 3

AppID 3

AnchorID 5

AppID 2

AnchorID 5

LinkID 6

Association

Bridge

Side


AppID 2

CompID 5

PSID C

xxxxxxxx xxxxxxxx xxxxxxxx

PSID B

xxxxx xxxxx xxxxx

CompID 6

PSID A


AppID 3

AnchorID 9

LinkID 10

CompID 7

PSID A


AppID 4

AnchorID 8

Figure 8. Complex example of inter-application linking.

CompID 5

PSID A

xxxxxx xxxxxx

AppID 1

AnchorID 8

HasLink IsLinkOf

HasAssociation IsAssociationOf

ASSOCIATION

Figure 9. An instance schema showing how Association Set Manager data are modeled by HB1’s Storage Manager. The schema corresponds to the inter-application linking example in Fig. 7.

HasPSID IsPSIDOf

SIDE

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx OBJECT xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx NAME xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx HasName xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx TYPE IsNameOf xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 00000001 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Wanda xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx HasType xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx IsTypeOf xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 00000002 Graphics xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 00000003 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx HasApplication Bitmap xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx IsApplicationOf xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 00000004 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Executable HasComponent xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx IsComponentOf xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Text xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Simple xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx HRL Anchor 00000005 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx HasAnchor Anchor xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx IsAnchorOf xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Reference xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 00000006 HRL Link xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Link xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


28

3

PSID

BRIDGE

HasSide IsSideOf

HasPSID IsPSIDOf

A


HasCompID IsCompIDOf

HasPSID IsPSIDOf

B

Object Manager Domain

xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx OBJECT xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx 00000003 xxxxxxxxxxxxxxxxxxxxx HasApplication xxxxxxxxxxxxxxxxxxxxx IsApplicationOf xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx 00000005 xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx 00000006 xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx

Association Set Manager Domain

00000004

CompID

28

PSID

BRIDGE

HasAppID IsAppIDOf

HasCompID IsCompIDOf

HasPSID IsPSIDOf


00000003

AppID

00000004

CompID

28

PSID

BRIDGE

Figure 10. Alternative ways of managing connectivity information in HB1.


xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx OBJECT xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx 00000003 HasApplication xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx IsApplicationOf xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx 00000004 xxxxxxxxxxxxxxxxxxxxx HasComponent xxxxxxxxxxxxxxxxxxxxx IsComponentOf xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx 00000005 xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx 00000006 xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx


28

PSID

BRIDGE


xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx OBJECT xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx 00000005 xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx 00000006 xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxx

C

KMS Document - CiteSeerX

KMS Document - CiteSeerX

Suggest Documents