A Vision for Open Hypermedia Systems Nürnberg and Leggett

3.2.1 Open Structure Abstractions
The structure abstractions that comprise hypertext (i.e., the essence of the definition of hypertext) are the cause of some disagreement, as was discussed in Section 2.1. Nearly all OHS's provide some notion of link that connects one or more locations. Links express relationships between objects or parts of objects. The terminology for these links, objects, object parts, etc., varies widely, but this is not the real cause of difficulty. If we could all agree on the abstractions, the names would be largely irrelevant.

The more difficult complications come in deciding the right set of abstractions. Sufficiency is an insufficient criterion for judging whether or not a particular set of abstractions should be adopted to model something (a process, an object, etc.) Our community has recognized that convenience and efficiency are two other important criteria.

The convenience criterion can be illustrated by the observation that most programming languages have the same modeling power (i.e., they are Turing complete), but all programmers have not simply uniformly adopted one of these languages for all uses. Different languages are better for different tasks, because they may provide more natural abstractions for the particular task. An example of a convenience (or naturalness) based argument for a set of abstractions is that made in [Trigg and Grønbæk 1997] in favor of composites. Although it is clear that composites can be modeled by links, Trigg and Grønbæk discuss important reasons why this may not be natural.

The efficiency criterion can be illustrated by the observation that it is sometimes easier to describe the method for generating items than enumerating the items themselves. For example, the set of odd integers can be described by (2*i)+1 (where i is an integer), which is simpler (more efficient with respect to space, time, etc.) to communicate than an enumeration of odd integers. An example of such abstractions in an OHS are the Microcosm generic links [Davis et al. 1992], that compute structures (connections between data) when needed. Although possible, it would be inefficient (in the extreme) to store all possible generic links as actual link objects in a hyperbase.

If we accept that we cannot simply provide a sufficiently powerful set of abstractions to OHS clients, the question arises as to what are convenient and/or natural structural abstractions. It seems that all OHSWG members would agree that links are such. At least some agree that composites and generic links are such. The taxonomic and spatial scenarios summarized in Section 3.1 show that there are even more structural abstractions that people have found useful in our own research community. Although links can model taxonomic structure, and (dynamic) composites can model spatial hypertext structure, these points, for the reasons described above, are insufficient. Taxonomic and spatial hypertext require structural abstractions tailored to these domains. This argument is easily extended to show that any closed set of abstractions cannot be guaranteed to be useful in a practical sense (i.e., convenient and efficient) for all possible applications. Only an open set of structure abstractions can meet this requirement.

One could argue that it is not the domain of the OHSWG to support "odd" hypertext systems that manipulate taxonomic or spatial hypertext. There are two reasons we believe that such an objection would be misguided.

Firstly, it may in fact be no more difficult to support an open set of abstractions than a closed one. Suppose that some closed set of abstractions is adopted by the OHSWG. There are two approaches to the management of these abstractions. If they are all handled independently by the system, then functionality like version control, notification control, concurrency control, etc., must be re-implemented for each abstraction. If, on the other hand, all abstractions served to clients are "translated" into some common structure format by the OHSWG server, such functionality need only be implemented once for the common format. (Note that this translation to a common format does not violate the convenience and efficiency arguments made above, since these arguments only pertain to clients of the system and are independent of storage and other issues internal to the server.) This "common structure" approach is evidenced most prominently in systems like HyperDisco (in which functionality is implemented in base classes and different structure abstractions are then subclassed from these base classes) and HOSS (in which the Structure Base provides common structure object facilities to individual Sprocs, that then tailor these objects to abstractions suited to particular domains). Allowing an open set of structure abstractions does not require that all possible structure abstractions be implemented (of course). In practice, it calls for a "common" structure format to be handled internally by the OHSWG server, which then should provide an open set of ways in which to tailor and extend this common format to the particular needs of clients (such as taxonomic, spatial, or navigational applications).

Secondly, providing more general support for "odd" forms of hypertext will expand our base of potential users significantly. For example, consider the number of systems presented at the last few ACM Hypertext conferences that require only links and perhaps generic links and composites. If that number were truly large, we would witness more people using OHS's to develop hypertext applications. Instead, nearly all of the "literati" works, as well as other applications that receive a non-trivial amount of attention at these conferences (such as spatial hypertext), require more than just these basic abstractions which the systems community in general (and the OHSWG in particular) spends so much time discussing. In a very real sense, OHS developers design hypermedia infrastructure. We should at least aim to make this infrastructure usable by the majority of our own research community.

Our architecture proposal is based on the premise that we should deliver an open set of structural abstractions to OHSWG clients. We believe that this does not add any requirements to systems that wish to be OHSWG compliant, while allowing a natural way for systems to provide extensions for supporting additional structural abstractions. Our protocol proposal reflects the open nature of the set of structural abstractions served to OHSWG clients by specifying multiple layers of protocol to describe client-server interactions. The lower layers provide a common syntactic model for these messages, while the upper (open) layer allows tailoring of messages to fit the particular structure abstractions served by a given server.

Contents

Peter J. Nürnberg, John J. Leggett
HRL, CSDL, Texas A&M
original page URL: http://jodi.ecs.soton.ac.uk/Articles/v01/i02/Nurnberg/scen_impl_open.html