An Agenda for Open Hypermedia Research

Peter J. Niirnherg

Dept. of Computer Science Aarhus University

Ny Munkegade, Bldg. 540 8000 Arhus C, Denmark

++45 8942 328 1 pnuern@daimi.aau.dk

John J. Leggett

Dept. of Computer Science Texas A&M University

College Station, TX 77843-3 112, USA ++1409 8450298

leggett@csdl.tamu.edu

Ufjre K. Wiil

Center for IT Research Aarhus University

Ny Munkegade, Bldg. 540 8000 Arhus C, Denmark

++45 8942 3358 ukwiil@cit.dk

ABSTRACT INTRODUCTION The historical development of hypermedia systems can be characterized as a series of successive abstractions of functionality away from the “core” hypermedia server, often resulting in a new open layer in the hypermedia environment architecture. Recently, this trend of abstraction has been applied to the hypermedia server itself, replacing the notion of a single, closed hypermedia server with an open layer of structure servers. This newest development brings with it a new set of challenges and research issues for open hypermedia researchers. In this paper, we discuss these issues, review some of our collective applicable experience with contemporary open hypermedia systems and other work, and point out some of the more pressing and intriguing open questions that we feel are facing open hypermedia researchers today. We also examine the “split” in the current hypermedia research community between “system” and “domain” researchers and the still-present need for interoperability among systems, and discuss why any attempt to address the issues we discuss in this paper must account for these observations.

Hypermedia systems have developed over the past several decades from the monolithic systems of Bush and Engelbart to the open hypermedia systems of today. Each development in hypermedia system design has been characterized by increased openness, which in turn led to greater applicability and flexibility. Recently, open hypermedia researchers have started to address opening the hypermedia server itself, discussing hypermedia environments that consist of an open layer of structure servers with their associated servers and clients. This “component-based” hypermedia middleware approach allows us to support a much wider range ol structural abstractions than has been possible with the closed link server layers that are typical in contemporary systems.

With these new hypermedia component-based systems comes a new set of research issues. Although we have little direct experience with many of these new issues, we do have a wealth of related experience upon which we can draw to form initial understandings. In this paper, we present an agenda containing some of the new issues that confront us as we consider the next generation of component-based open hypermedia systems (CB-OHS’s). We also present a framework that allows us to generate and analyze these issues systematically.

KEYWORDS: Open hypermedia system (OHS), component- based open hypermedia system (CB-OHS), structural computing, hypermedia middleware, hyperbase, hypermedia operating system, hypermedia domain research

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. HyperText 98 Pittsburgh PA USA Copyright ACM 1998 O-89791-972-6/98/ 6...$5.00

The remainder of this paper is structured as follows. Firstly, we present the current state of hypermedia research as it applies to CB-OHS’s, This discussion is cast in terms of a “split” in the hypermedia field and the work that has been accomplished within the context of this split. Secondly, we discuss the motivations for the move toward component- based hypermedia middleware, especially with regard to bridging this split. Thirdly, we present and discuss an agenda of research issues that must be addressed by open hypermedia researchers wishing to design and implement a CB-OHS. Fourthly, we describe what we feel are necessary preconditions to any attempt by our field to address the issues on our agenda. Lastly, we present our conclusions based on the work presented here.

198

CONTEXT From its inception. hypermedia research has been concerned with how people use structure, how to present structure to

people, and how to build systems to support people working with structure. Early hypermedia researchers such as Bush addressed all of these concerns. In his seminal article “As We May Think” 161, he noted that people use associative structures in their memories, discussed how these associative structures could be presented to people (trails of associations), and described a system (the Memex) that could support these structures and their navigation.

The hypermedia research field has become partitioned, however, and issues surrounding the design of systems to support people working with structure have become separated from issues surrounding how people use structure in different problem domains and how such structure should be presented. Researchers concerned with the former issues (called system researchers here) have gone on to describe ever more powerful and complex systems, but their prototypes have generally not supported work in more recently described problem domains. Conversely, researchers concerned with the latter issues (called domain researchers here) have gone on to describe new domains and presentations of structure, but their prototypes have generally not used more recent system designs. Below, we briefly describe the work done in each of these “subfields”.

System Research Early hypermedia systems were monolithic (Figure la). A monolithic system is one in which all aspects of the system (e.g., client, store, behavior, etc.) are realiz,ed in a single process. The limitations of monolithic systems were quickly realized and are well documented, and led to a series of improvements. Roughly speaking, the development of hypermedia system architectures occurred in stages [23]. In each stage, some functionality or architectural component was abstracted away from the “core” hypermedia system. Often, each abstraction was tantamount to the replacement of a part of the hypermedia system with an open set of processes that interact with the rest of the hypermedia system environment through some well-defined interface. First, the frontend of the hypermedia system was abstracted to an open set of clients or applications (Figure lb). This led to the “open link service” systems of the late 1980’s and early 1990’s, such as those described in [26]. Next, the backend of the hypermedia system was abstracted and opened, leading to open hyperbase systems (Figure Ic), representative of systems of the early and mid 1990’s (e.g., [321). Then, traversal computations were abstracted and opened, leading to what are today known as open hypermedia systems, or OHS’s (Figure Id). Most contemporary hypermedia system research environments (e.g., Chimera 121, DHM [12], HOSS [22], HyperDisco 1371, and Microcosm [8]) are OHS’s

a) monolithic systems

b) open c) open link service hyperbase systems systems

d) open hypermedia systems

Figure 1: Conceptual architectures of hypermedia systems demonstrating various stages of successive abstraction. Above, “Be” stands for “behavior” (link

traversal computation) and “LS” stands for “Link Server”.

Most OHS’s generally support only the abstractions described by the earliest hypermedia researchers (i.e., the associative structures described by Bush). Few contemporary OHS’s claim to provide support for any other problem domain, much less for the integration of an open set of new domains. Even when some newer abstractions (e.g., “context” and “generic link”) have been adopted by some systems, the focus of these systems has continued to be exclusively navigational. Generally, no attempt has been made to support other problem domains, such as those discussed below.

Domain Research As mentioned above, Bush and other early hypermedia pioneers considered the use and presentation of associative structures, or what could be called the navigation domain of hypermedia. Since then, many researchers have considered different domains, including hypermedia literature [5, 21, 281, argumentation systems [7, 20, 311, spatial hypermedia systems [ 191, hypermedia art [IS, 291, and taxonomic hypermedia systems [22, 24. 2.51. Work in all of these domains addresses how people use structure for various tasks, whether those tasks be writing or reading literature, participating in or reviewing a decision process, etc. Each domain also has its own specialized abstractions, its own terminology, and its own context. We can understand each of these domains as a kind of hypermedia because all share a focus on structure, but we can also understand each of these domains as unique because of their individual characteristics.

Domain researchers have often built systems to test theil ideas about different structure models or presentations. However, these systems have tended to reflect the architectures of the earl&t hypermedia systems, since they are almost always monolithic. None of the systems designed to study domains other than the navigation domain provide the distribution, flexibility, or power of contemporary OHS’s.

199

NEXT GENERATION COMPONENT-BASED OPEN HYPERMEDIA SYSTEMS At the Second Open Hypermedia Systems Workshop [36] held in Washington, DC, in conjunction with the ACM Hypertext ‘96 conference, the Open Hypermedia Systems Working Group (OHSWG) was formed. The OHSWG has met semi-annually and has established a WWW site (http://www.csdl.tamu.edu/ohs/) and several mailing lists to carry out its work. Currently, most major research OHS’s, including all of those mentioned above, are represented in the group.

The main purpose of the group is to foster interoperability between contemporary OHS’s, Initially, the goal was to provide a framework for the definition of a common link (i.e., associative structure) services protocol between link servers and their clients [IO]. To help provide context for this protocol definition, the group adopted a scenario-based design approach. The need for each modification to the protocol was to he demonstrated by a scenario of hypermedia system use.

In its initial work toward defining a standard protocol for associative structure servers, the group encountered the problem that different contemporary OHS’s support different structural abstractions. Although all OHS’s support abstractions such as “link”, other abstractions, such as “context”, “composite”, or “generic link” were only supported by some systems. Scenarios describing the need for these other abstractions were submitted, and it was generally agreed that good cases for the adoption of all of these abstractions could be made. Thus, the draft standard started to reflect a union of all services provided by the representative systems. This made it difficult or impossible for any contemporary system to support this standard fully.

This situation was further aggravated when scenarios were submitted to the group that contained examples of use of hypermedia systems that supported other domains, such as spatial and taxonomic hypermedia. It soon became clear that no one structure server (and therefore no one protocol) could support what seemed to be an open set of structural abstractions. It was equally clear, however, that hypermedia domain research and use scenarios could demonstrate the need for these different structural abstractions.

At the OHSWG’s most recent meeting in Arhus, Denmark, in September 1997 (OHS 3.5), the group adopted a modification to their conceptual reference architecture to address the issue of supporting an open set of structure abstractions. This modification continues the trend of successive abstraction in system development noted above by adopting the abstraction of the link sei-ver itself into an open layer of link service peers, each which serves a particular structural model. An open layer of link server peers (or structure servers) allows the support of an open set of structural abstractions, which in turn allows the support of an open set of hypermedia domains. The resulting component-based open hypermedia system architecture is shown below.

Client I

Backend

Figure 2: Conceptual architecture adopted by the OHSWG. Although strictly speaking, the OHSWG has yet to adopt any particular reference architecture formally, it has been agreed that any such architecture must reflect the need for an open structure server layer. Above, ‘33”

stands for “structure server”.

A HYPERMEDIA RESEARCH AGENDA The successful design and implementation of CB-OHS’s involves addressing many research issues. Some of these are the same or similar to those issues that surround work on contemporary OHS’s, while some are completely new or noticeably more complicated. Since no system based completely on the new CB-OHS architecture and interface specifications of the OHSWG has been developed yet, we have little direct experience on which to draw to even identify what issues should be on our research agenda. However, as a field, we have a wealth of related experience that we can adapt and extend to provide us with some initial insights.

Before we begin discussing issues, however, we want to introduce a framework for organizing these issues. There are undoubtedly many ways in which to describe the research issues surrounding CB-OHS’s, We have chosen to use the new conceptual architecture itself as a framework, examining each layer and interface as well as the system’s users. This framework partitions the problem space into seven areas that serve both to help identify new issues and to organize our thinking about those already identified. The figure below illustrates the resultant arcas of issues as they relate to the CB-OHS conceptual architecture.

Below, we discuss each area separately, starting from the top of Figure 3 and moving downwards. For each area, we begin by considering experiences gained by working with contemporary OHS’s and other hypermedia systems, and how these experiences might be applicable to thinking about CB-OHS’s, We continue by discussing some issues that seem particularly challengin g or interesting to us based on our collective experiences in developing the HOSS [22] and HyperDisco [37] systems over the last seven years.

200

0 +fl

1. Human Layer

2. Client Interface

3. Client Layer

4. SS API

Figure 3: A mapping of the layers and interfaces of the CB-OHS conceptual architecture and its environment to

seven areas of research issues.

Human Layer Experiences. Since all hypermedia domain research is based on observations of people’s use of structure, the hypermedia field as a whole has much experience in considering people’s use of structure. For Bush, the observation of the way in which people’s memories operate led to the definition of the navigation hypermedia domain [6]. We mentioned several other hypermedia domains above. All of these share their beginnings in observation of people’s work practices (e.g., observations of the premature formalization problem that led to spatial hypertext [ 191).

It has always been a concern of domain researchers to find new ways in which people apply different structural abstractions to different problems. As system researchers, we generally have few experiences in this area. We have relied and will continue to rely on domain researchers to identify and describe new domains.

Issues. The issues for domain researchers in this area remain the same despite any changes to system architectures we consider. For us, however, the open structure server layer in CB-OHS’s makes this an area we can no longer ignore. In the past, we have relied nearly exclusively on the initial navigational domain observations made by Bush, occasionally considering new issues or abstractions, but rarely straying too far from this basis to incorporate results from new domains. Now that we are considering systems designed specifically to support multiple hypermedia domains. results from this area are directly applicable to extending our systems.

Client Interface Experiences. There are many examples of hypermedia interface work. A full review is well outside the scope of this paper. Here, WC: mention only a small representative sample of this work.

Domain researchers have much experience with considering the interfaces of hypermedia systems. Even though systems that implement non-navigational hypermedia tend to bc

monolithic, we can still regard the interface of these monolithic systems as conceptual “client interfaces” in our framework, placing experience gained from these systems in this area. The interfaces of many any non-navigational hypermedia systems have received much attention in the literature and have even been a major focus of the work in some domains (e.g., spatial hypermedia system interfaces [331).

System researchers, too, have considered interface issues. This has become especially important when integrating third-party applications into open hypermedia systems. The hypermedia functionality exported to these third-party applications must be realized in the interfaces of these applications. Reports on different designs at this level as well as rationale for these designs are widespread (e.g., [9]). There has been much work on navigational aids as well. Several types of overviews have been proposed and implemented (e.g., fish-eye views [ 111). Even early work on navigational monolithic systems often considered interface aids to offset cognitive disorientation (e.g., [ 11).

Issues. Despite the plethora of interface work, there has been very little consensus on even relatively “old” interface issues such as how best to display link endpoints in data. For example, even considering only textual data, is blue, underlined text really the best way to denote a source anchor? In systems that allow multiple destinations, should a pop-up menu list these destinations after a source has been clicked on or when the mouse passes over the source [38]? Should overview maps of the hyperspace be constructed, and if so, how? How should the rhetorics of arrival and departure be effected [ 16]? How should the user specify structural queries [ I3]?

Furthermore, the interface issues that arise from different hypermedia domains previously could be considered separately. The possibility of clients that present multiple structure models to users simultaneously, however, raises issues of consistency of presentation. For example, consider the HOSS TaxEd, a client of both taxonomic and associative structure servers 1221. In this case, it is not reasonable to consider presentation of taxonomic and associative structures separately since this client must present both. In general, new CB-OHS’s that serve multiple (and even an open set of) structural abstractions and models call for a new, integrative approach to these interface issues.

Client Layer Experiences. The construction of clients from scratch has been the focus of some hypermedia research, especially work in early open navigational systems (e.g., SP2 [30]). In these cases, the job of the client designer was relatively straightforward, apart from the HCI issues discussed above. Some excellent recent work regarding the construction of such clients has been done [3].

Recent system work has tended to focus on integration of third-party applications into open hypermedia environments. Finding appropriate applications has been relatively easy, smce associative hypermedia structures are (ideally)

201

independent of the data types over which they are defined.

Issues. Although no open environments for other hypermedia domains have yet been implemented, some have been contemplated in the literature (e.g., an open spatial hypermedia environment in which arbitrary graphics editors are integrated with the services of a spatial hypermedia structure server [33]). Analogous examples of integration of applications into other environments can also be defined.

Work regarding integration of third-party applications into associative environments has noted that there are different “levels” of integration that can be achieved for different clients [g, 35, 371. Integration into general structural domain environments suggests an extension of this principle. In what ways (i.e., to what levels) can a graphics editor be integrated into a spatial hypermedia environment? What levels of integration arc shared across all structure domains, and which are specific to individual domains? Considering the levels of integration defined by Davis et al. [g], perhaps some of the lower levels of compliance (e.g., “launch only” integrations) arc in fact independent of any particular domain, whereas higher levels of compliance (e.g., “fully integrated”) actually correspond to a semantic “understanding” of the particular abstractions of a given domain and are thus not common across domains.

As with the issue areas above, there are ramifications of applications acting as clients of multiple structure servers simultaneously. Can (or should) a procedure for integration of an application into a given domain environment be defined in a way independent of that application’s participation in other domain environments? Can some of the effort expended in the integration of an application into one domain environment be reused in its integration into other domain environments’?

Finally, there are a series of issues with regard to the recognition and use of advanced backend facilities and the automatic distribution of this new architecture for non- associative clients (or, more commonly, client “parts” of monolithic systems). Most such clients use relatively basic backend functionality. Considering such clients as part of next generation CB-OHS’s allows new kinds of experimentation to occur in these domains. What does versioning allow in taxonomic hypermedia systems‘? How can the collaborative work support of hypermedia system backends be used in a spatial hypermedia system’!

Structure Server API Experiences. Open hypermedia systems are called “open” in part because they publish an API. This public interface allows third-party applications to be integrated or designed to be compliant from the start. All open systems face the problem of how to define their interface. An API should be complete and convenient to use as well as extensible. Once an interface is defined, decisions on the mcans by which it should be served must also be made. Should communication take place over TCP/IP sockets. Apple Events, or RPC, ot- does an existing component framework such as CORBA provide the necessary infrastructure for routing requests and

replies transparently’? All designers of contemporary OHS’s have faced thcsc problems. This experience will serve as a good basis for addressing the issues below.

Issues. An open structure server layer introduces new concerns about compatibility between the different intcrfaccs. It is certainly a requirement that all middlewarc components in a given system share the same mechanisms for communicating client service requests and responses. Additionally, there should be a kind of conceptual harmony among the interfaces at this level. Client designers familiar with one component interface should find it relatively easy to program clients for other intcrfaccs.

Thcrc arc other aspects to the coordination of various structure server interfaces. Names (as well as identifiers, addresses, etc.) of objects and structures valid for one structure server should be valid for all structure servers. Naming has received little explicit attention in hypermedia systems research outside of the WWW to this point. The kind of radical interoperability and openness for which the community is now aiming, however, makes this an issue that must be explicitly addressed.

In addition to object and structure naming, service (or structure server) naming must also be addressed. In contemporary OHS’s in which there exists a single (or closed set of) structure servers, it suffices simply to name a well-known port (or equivalent) for each server and allow clients to hard-wire this information into their communication routines. In CB-OHS’s, with their open set of structure servers, another layer of service naming must be admitted. Clients may still have the notion of a well-known port, but this port must be to a (service) name server that can resolve a given service name to the correct communication address.

It may be argued that the choice of an existing component framework for communication infrastructure allows some oi these concerns to be ignored by system designers. For example, CORBA addresses object and service naming. However, as mentioned above, integration of existing third- party applications is a key concern in CB-OHS’s It is impractical to rcquirc that MS Word, for example, be made CORBA compliant in order to participate in such a system. If a system designer adopts such a component framework, it will still be the case that clients that do not adhere to the standards of that framework will still need to be integrated.

Structure Server Layer Experiences. System researchers clearly have experience in building at least one kind of structure server, namely one that serves associative structure. Another important aspect of this layer is the presence of arbitrary traversal computations, or behaviors. This kind of structural computation has long been acknowledged as a difficult and important issue in hypermedia. Scvcral different kinds of computation have been discussed, includmg traversal computations (or behaviors) [30], “active” hypertexts ] 131, and dynamically defined structures 141.

202

Issues. The construction of structure servers will of course be a major undertaking in the construction of CB-OHS’s While there are clearly important issues in this task. there seem to be many more unresolved and difficult issues surrounding behaviors.

Even in the simple case of contemporary OHS’s with only one structure server, no consensus has been reached as how best to represent behaviors. For example, some systems provide their own scripting language (Multicard [ 27]), some use existing language facilities (HypcrDisco [37]), and some use compiled object code (HOSS 1221). For dynamic structure computations, some systems use link filters (Microcosm [g]) and some systems use arbitrary active information systems [4]. If next generation hypermedia systems are to achieve the degree of interoperability desired, some agreement must be reached on how best to represent these computations.

Considering interoperability between different structure servers (i.e., components serving different structure models) is also interesting. This implies the need for each structure server (or one of its behaviors) to be able to interpret (translate) the structure manipulated by other servers. Is this a realistic or even useful goal?

Without considering the generic case for a moment, it is clear that the ability of one structure server to interpret the structure of another can be useful in certain circumstances. For example, consider an associative structure server that can interpret spatial hypermedia structures. One can imagine a relatively straightforward mapping from spatial structures to associative ones. For example, each structure in the space could correspond to a “document” that contains associative links that lead to the substructures and/or atomic ob.jects that are contained in that spatial structure. Spatial hypermedia systems are used to evolve organizations over time. but if these organizations settle into some configuration, it may be desirable to view this configuration as if it were a set of standard WWW pages, for example.

Clearly, WC cannot yet say that translating from any given structure model to any other is a useful undertaking, but it does seem that at least some of these translations would be useful. How best to define these translations is a difficult problem. The best possible solution to this problem would be a generic one in which only the descriptions of the source and destination structure model could be provided to some algorithm that could generate such a mapping. Less generic but more easily attainable translations could be hand- constructed. Even after translations are derived, there remain many questions. If a set of spatial structures is translated into a set of associative structures, does this imply the creation of a new set of structures, or just a diffcrcnt “view” on an existing one’? How can we (or should we) coordinate changes in one set/view with changes in another? Are different translations best handled by versioning’? While them is some work that may hold promise for mechanism (c.g.. using XML [34] or the Dexter model [I41 as an interchange format, as reported in 1171). no work to date has

focused on the semantic problems raised by such inter- domain translations.

Backend API Experiences. Many contemporary OHS’s consider at least some type of backend distribution or infrastructure support for their link servers. Often, this support has been in the form of structure aware storage engines. Many OHS’s have a hyperbase component that encapsulates and distributes the structure management [ 12. 22, 371. In general, the abstraction of the structure-aware store from the structure server itself has been a positive development for those systems that have implemented it.

Issues. The new OHSWG architecture contains both a structure server layer and a backend layer. The API to the backend layer concerns the support provided to structure servers. It defines the set of services that structure servers (and clients) can expect from the underlying system.

Associative structure scrvcrs have evolved from the “passive storage and retrieval systems” of which Halasz spoke a decade ago [ 131. Even given that no consensus on how to represent behavior in contemporary OHS’s has been reached, as mentioned above, most systems do provide their clients computation facilities. Many systems use dynamic structures and/or provide at least some form of structural query. Should we now consider the support of thcsc advanced features at the backcnd layer as well?

One way to look at this issue is how support for implementing structure servers should be distributed. If structure-aware stores have worked out positively for OHS development, it certainly suggests that, for example, structure-aware computation facilities have similar promise. Thus far, the OHS community has been slow to consider offloading more functionality from structure servers into the backend, despite the fact that such offloading could make structure server construction a simpler task and promote even greater interoperability by removing idiosyncratic features from the structure server layer. Considering the newly opened structure server layer, however, functionality such as general structural computation will be required in an open number of processes. The need for support ol functionality common to all processes in an open layer argues even more strongly for its abstraction.

Backend Layer Experiences. As a community, we have few experiences with backend construction outside of hyperbases. This is not surprising in light of the fact, as mentioned above, that most systems do not even provide a structure-aware backend API. Initial thoughts in this direction, however, were provided in [22]. The potential benefits of structure-aware process management, memory management, protection schemes, etc., have been described. These topics have not been of interest only in the hypermedia community, however. Issues such as semantic locality have been actively researched in the operating systems community as well [I Xl.

Issues. Independent of the level of structure awareness in

203

the interface to the backend, there are potential gains in making the internals of any backend structure-aware.

Traditional operating s ystem design is based on empirical observations of resource use in predominantly monolithic, data-oriented systems. Notions of semantic locality being related to physical locality, for example, are rooted in 1960’s style computing environments. In today’s computing environments, in which hypermedia structures and their resultant “chunking” of information are a reality, and in which Java applet code-on-demand reachable by WWW links is increasingly more common, it is clear that the basic principles underlying many of the algorithms and policies of older operating systems are becoming outdated.

One might argue that these are the concerns of operating systems researchers. This is clearly correct, in the same way as many of the issues in the first several areas discussed above are the concerns of HCI researchers. Hypermedia has always been an interdisciplinary field. Given the development of hypermedia from predominantly frontend phenomenon to inclusion of middleware and backend components, and the changing needs of operating systems design, however, we argue that there are reasons to undertake collaborations with another branch of research to investigate the construction of hypermedia backend (i.e., operating system) internals.

PRECONDITIONS There are a number of ways in which the research issues that surround CB-OHS’s can be addressed. However, we feel that the discussion above points out two necessary preconditions that must be fulfilled by any approach for it to be successful. Both of these preconditions are discussed in more detail below.

Bridging the Gap We noted above a split in the hypermedia field between system and domain researchers. Though there are people who fit into both categories, it still remains true that results from one area are rarely applied in the other. It has been the case that domain researchers have not been able to use many of the system advances because these systems were rarely flexible enough to support non-associative structures. It continues to be the case that such researchers can choose not to develop on any existing infrastructure or experiment with open systems, though there seem clear benefits and new interesting areas available to those domain researchers that want to experiment with the new CB-OHS’s,

It has also been the case that system researchers have been able to ignore many domain research results because of the relatively narrow focus of contemporary OHS’s [23]. It continues to be the case that such researchers can choose to ignore other domains and focus on implementing open sets of structure servers that happen to contain only one component, though whether this is interesting or valuable seems debatable.

The fact is, however, that there are many potential benefits for members of both areas to co-operate and share work and

results with one another. Domain researchers can explore entirely new sets of questions concerning distribution, collaboration and integration of different structure models without having to implement backend (or perhaps even structure server) support. System researchers can gain whole new audiences in which to test designs and implementations. The situation seems laden with exciting possibilities for the hypermedia field. If CB-OHS’s are to realize their full potential, though, the gap between domain and system research must be bridged.

System Interoperability Not only must there be co-operation between system and domain researchers - it must also exist between different system researchers. It has been the case that contemporary OHS’s have been developed independently from one another, with occasional borrowing of ideas or implementations when convenient. However, for several years, the need for (or at least benefits of) some standards among the different OHS’s has been recognized. This need was driven by the recognition that allowing an open set of clients implies the potential for an open set of integrations that must be performed. Implementing an OHS became an open-ended task. If client integration could be performed in a standardized way, it was reasoned, all OHS’s would benefit when a new client was integrated into one OHS.

This need to spread effort and prevent re-implementations and re-integrations is even more acute for CB-OHS’s than for contemporary OHS’s, Until now, only clients of associative structure servers were candidates for integration into a hypermedia environment. Now, we can consider integrations of arbitrary clients and even new structure servers. Also, as mentioned above, CB-OHS’s require a large amount of “infrastructure” support (e.g., naming services, location services, etc.) as well, which suggests further benefits of standards to promote interoperability. Finally, any attempt to convince domain researchers to use CB-OHS’s for experimentation and development must come with some guarantee of stability. Setting standards will help ensure this stability.

CONCLUSIONS The hypermedia field is at an important and interesting time in its development. The system work that has been done over the last decade has reached a level of stability and maturity, embodied in the OHSWG adoption of a CB-OHS conceptual architecture and evidenced by the convergence of functionality of many contemporary systems and the emergence of well-defined standards. It is now time to apply the results of this work to support the domain work that has occurred and continues to occur. This promises new and exciting possibilities for many researchers in the field. Domain researchers can expect easier construction of mom powerful clients and systems for their experiments and work, while system developers can expect a growing number of users with diverse requirements to fuel the improvement of their work.

These developments introduce a new set of issues that must bc confronted by open hypermedia researchers, however.

204

Allowmg the support of’ multiple structure models in the same environment requires new thinking on how to harmonize the presentation of these models to both client programmer and user. The increasing complexity of structure servers coupled with developments in the operating systems field points to new possibilities for collaboration. We feel that open hypermedia researchers must address the issues we discuss above in the coming years if the promise of CB-OHS’s is to be fulfilled.

REFERENCES 1. Akscyn, R., McCracken D., and Yoder, E. 1988. KMS: A

distributed hypermedia system for managing knowledge in organizations. Communications of the ACM 31(7), (Jul), 820-835.

Anderson, K., Taylor, R., and Whitehead, E. J. 1994. Chimera: hypertext for heterogeneous software environments, in Proceedings of the European Conference on Hypertext ‘94 (Edinburgh, Scotland, Sep), 94- 107.

Ashman, H., Bieber, M., and Oinas-Kukkonen, H. (eds). 1997 The Third International Workshop on Incorporating Hypertext Functionality into Sof?ware Systems (HTF ‘97), in conjunction with The Eighth ACM Conference on Hypertext (HT ‘97), (Southampton, England, Apr).

Bieber, M. and Kacmar, C. 199.5. Designing hypertext support for computational applications. Communications of the ACM 38(8), 99-107.

Bolter, J. and Joyce, M. 1987. Hypertext and creative writing, in Proceedings of the Second ACM Conference on Hypertext (HT ‘87), (Chapel Hill, NC, Nov), pp. 41- 50.

6. Bush, V. 1945. As we may think, Atlantic Monthly 176(l) (Jul), 101-108.

7. Conklin, J. and Begeman, M. 1987. gIBIS: A hypertext tool for design deliberation, in Proceedings of the First ACM Conftirence on Hypertext (HT ‘87) (Chapel Hill, NC, Nov), pp. 247-25 1.

8. Davis, H., Hall, W., Heath, I., Hill, G., and Wilkins, R. 1992. Towards an integrated information environment with open hypermedia systems, in Proceedings crf‘ the European Conference on Hypertext ‘92 (Milano, Italy, Dee), 181-190.

9. Davis H., Hall W., and Heath I. 1993. Media integration issues within open hypermedia systems, in Proceedings of IEEE International S~‘mposinm on Multimedia Technologies and Future Applications (Southampton, UK. Apr).

IO. Davis, H., Lewis, A., and Rizk, A. 1996. OHP: A draft proposal for a standard open hypermedia protocol, in Proc,erdirrg.c of‘ the 2nd Workshop on Open Hypermedia

Systems, UCI-ICS Technical Report 96- IO, University of California, Irvine, pp. 27-53.

11. Furnas, G. 1986. Generalized fish-eye views, in Proceedings ofCH1 ‘96 (Boston, MA, Apr), pp. 16-23.

12. Grenbzk, K., and Trigg, R. H. 1994. Design issues for a Dexter-based hypermedia system, in Communications of the ACM 37(2) (Feb), 40-49.

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

14. Halasz, F. and Schwartz, D. 1990. The Dexter hypertext reference model, in Proceedirlgs of the NIST Hypertext Standardization Workshop (Gaithcrsburg, MD, Jan), 95 133.

15. Kinsella, E. 1996. The Intersensory Aesthetics of Hypermedia: Fertile Ground for Integrative and Creative Expression. Ph.D. Dissertation, College of Architecture, Texas A&M University, College Station, TX.

16. Landow, G. 1987. Relationally encoded links and the rhetoric of hypertext. In Proceedings of the Hypertext ‘87 Conference, (Chapel Hill, N.C., Nov), pp. 331-344.

17. Leggett, J. J. and Schnase, J. L. 1994. Viewing Dexter with open eyes. Communications of the ACM 37(2) (Feb), 76-86.

18. Matthews, J., Roselli, D., Costello, A., Wang, R., and Anderson, T. 1997. Improving the performance of log- structured file systems with adaptive methods, in Proceedings of the Sixteenth ACM Symposium on Operating System Principles (Saint Malo, France, Ott).

19. Marshall, C. and Shipman, F. 1995. Spatial hypertext: designing for change. Communications of the ACM 38(8), 88-97.

20. McCall, R., Bennett, P., D’Oronzio, P.. Ostwald. J.. Shipman, F., and Wallace, N. 1990. PHIDiASl Integrating CAD graphics into dynamic hypertext, in Proceedings qf the First European Conference on H)lpertext (ECHT ‘90) (Versailles, France, Nov), pp. 152-165.

21

22

23

Moulthrop, S. 1989. Hypertext and “the hyperreal”, in Proceedings of the Second ACM Conference on HJpertaxt (HT ‘KY) (Pittsburgh, PA, Nov), pp. 259-268.

Niirnberg, P., Lcggett, J., Schneider, E., and Schnase, J. 1996. HOSS: a new paradigm for computing, in Proceedings of the Seventh ACM Conference on Hjjpertext (HT ‘96) (Washington, DC, Mar), 194-202.

Niirnbcrg, P., Leggett, J., and Schneider, E. 1997. As we should have thought, in Proceedings of the Eighth ACM Confbrencc on H>,prrtrxt (HT ‘97) (Southampton, UK,

20.5

Apr), 96- 10 I

24. Parunak, H. 1991. Don’t link me in: set based hypermedia for taxonomic reasoning, in Proceedings of the Third ACM Conference on Hypertext (HT PI) (San Antonio, TX, Dee), pp. 233-242.

UK, pp. 137-151.

32. Schiitt, H. A., and Streitz. N. A. 1990. Hyperbase: A hypermedia engine based on a relational database management system, in Hypertext: Concepts, Systems, and Applications. Proceedings of the European Conference on Hypertext (ECHT PO) (Versailles, France, Nov), A. Rizk, N. Streitz, and J. Andre, Eds. Cambridge University Press, Cambridge, UK, pp. 95 108.

2.5. Parunak, H. 1993. Hypercubes grow on trees (and other observations from the land of hypersets), in Proceedings of‘ the Fifih ACM Conference on Hypertext (HT ‘93) (Seattle, WA, Nov) pp. 73-8 1.

26. Pearl, A. 1989. Sun’s link service: A protocol for open linking, in Proceedings of the Second ACM Cotzference on Hypertext (Hypertext ;89), (Pittsburgh, PA, Nov), pp. 137-146.

27. Rizk, A. and Sauter, L. 1992. Multicard: an open hypermedia system, in Proceedings of the European Conference on Hypertext ‘92 (Milano, Italy, Dee), 4- IO.

28. Rosenberg, J. 1996. Structure of hypertext activity, in Proceedings of the Seventh ACM Conference on Hypertext (HT ‘96) (Washington, DC, Mar), pp. 22-30.

29. Sawhney, N., Balcom, D., and Smith, I. 1996. HyperCafe: narrative and aesthetic properties of hypervideo, in Proceedings of the Seventh ACM Conference on Hypertext (HT ‘96) (Washington, DC, Mar), pp. I - 10.

30. Schnase, J. L., Leggett, J. J., Hicks, D. L., Ni.irnberg, P. J., and Sinchez, J. A. 1994. Open architectures for integrated, hypermedia-based information systems, in Proceedings of the 27”’ Annuul Hawuii International Conference on System Sciences (HICSS-27), (Weilea, HI, Jan), pp. 386-395.

3 I. Schuler, W. and Smith, J. 1990. Author’s Argumentation Assistant (AAA): A hypertext-based authoring tool for argumentative texts, in Proceedings of the First European Conference on Hypertext (ECHT PO) (Versailles, France, Nov), A. Rizk, N. Streitz, and J. Andre, Eds. Cambridge University Press, Cambridge,

33. Shipman, F., Marshall, C., and Moran, T. 1995. Finding and using implicit structure in human-organized spatial layouts of information, in Proceedngs of CH/ ‘95 (Denver, CO, May), 346-353.

34. W3C. 1997. Extensible markup language (XML). Technical report PR-xml-971208, World Wide Web Consortium. Available via http://www.w3.org/TRPR- xml-97 1208.

35. Whitehead, E. J. 1997. An architectural model for application integration in open hypermedia environments, in Proceedings of Hypertext ‘97 (Southampton, UK, Apr), I- 12.

36. Wiil, U. K., and Demeyer, S. (eds.). 1996. Proceedirzgs of the 2nd workshop on open hypermedia systems, Hypertext ‘96. Technical report UCI-ICS 96- 10, University of California, Irvine.

37. Wiil, U. and Leggett, J. 1996. The HyperDisco approach to open hypermedia systems, in Proceedings of Hypertext ‘96 (Washington, DC, Mar), 140-148.

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

206