ABSTRACT
Aspects of external structure are delineated, including scope, valence, directionality, and behavior specificity. Locality of structure is discussed from several aspects; structures may be composable; composed structures may pose computational difficulties, raising the issue of incomplete structure in the case of interrupts. Structure locality must be semantically relevant. Structure locality may need to be specifically indicated, or to the contrary may need to be discovered by the reader without specific indication. Structure poses its own rendering problems. Scopes, valences, etc. need to be rendered; such rendering may have aesthetic or human factors consequences that conflict with other goals of the hypertext author. Behavior flexibility is required. Representation of structure includes such aspects as collapse/expand and structure filtering. Representation of location within structure must allow for a non-unitary concept of location. Parastructure has its own rendering requirements. Behavior itself is discussed from the standpoint of arbitrary structurality. Pure behavior must be a compatible guest, with behavior that is exportable (e.g. for transition effects.) Behavior associated with structure must allow for pure behavior. Navigation behavior includes such issues as transition effects, flying, zooming, etc. Interface behavior has implications for how one type of structure may be considered to emulate another. Parastructural behavior may be required.

INTRODUCTION
Language is intensely structured. At a fine grain it is structured by syntax; at a still finer grain by phonology; at a coarse grain by such structures as argumentation and rhetoric; at a still coarser grain by plot, narration, etc. Hypertext brings something new to the table: explicit external structure, coupled with interactivity wherein that structure plays itself out. This paper takes as a given the premise that an artistically open hypertextuality must allow its concept of external structure to be as arbitrary as possible, notwithstanding the extent to which highly particular models of structure have become extremely popular. A number of issues will be analyzed from the point of view of openness to arbitrary structure; this analysis will be strictly from a writer’s point of view rather than from a system implementor’s point of view, though of course it is hoped this analysis will be useful to system implementors. In particular we will take no position at all concerning such issues as how structure is managed by a hypertext system (e.g. as an explicit “structure store” layer [16].) We begin with an analysis of what “structure” entails. (To some the idea of what constitutes structure may seem obvious, but it bears investigation.) We will be at great pains to avoid constructing Yet Another Formalism; not because any doubt is being cast on the worthiness of that activity, but because we fear the act of constructing a formalism risks prejudging the outcome of what will constitute structure. Although structure is the subject at hand, a great deal of emphasis in this paper will be placed on behavior, for a number of reasons. It is typically in the area of inflexible behaviors that off-the-shelf hypertext systems most disappoint artistically inclined authors. Moreover it is all too easy to allow behavior to slip still further from view in the rush to place emphasis on structure. From an artistic point of view, the key word is openness: as we explore how to make hypertext open to the widest variety of possible structure, it must also remain open to the widest variety of possible behavior — and the widest variety of relationships between the two. Authors will simply not put up with hypertext systems in which behavior is the poor handmaiden of structure.

EXTERNAL STRUCTURE

Conceptual Overview
In saying that hypertext consists of words (or other media) with an external structure, “external” is meant with respect to the words themselves. While it would be possible to indicate hypertextual structure entirely with words (including numbers) contained in a text — and in fact exactly such analysis is done to situate historical antecedents of hypertext (e.g. [3], see also [14]), typically a hypertext uses means external to the text to contain the structure. This concept of external is not to be confused with an external concept of storage, e.g. an externally maintained linkbase vs. embedded links in the data sense. The most widely discussed structural model is the node-link model, e.g. as elucidated in the Dexter Hypertext Reference Model [7]. Many other modes of structure have been discussed including sets [17], relations [12], Petri Nets [22], simultaneities [18], and piles [13]. Articulation of how elements of the text participate in such a structure is part of The Rendering Problem, which is discussed below. With respect to such structural elements — as rendered — the user performs activities, which result in Behavior — also discussed below. In this section we discuss aspects of structure itself.

Aspects of Structure
Before proceeding to aspects of structure that may be more familiar to those from a systems point of view, it is important to emphasize a particular aspect of structure often important artistically but neglected by many hypertext systems: the Null Structure. In a null structure, elements are presented with no structural relation whatever except that they happen to be juxtaposed. Elements in a null structure are simply there; it may not be pertinent to raise further issues concerning their “thereness”. Similar to the concept of the null structure is Emergent Structure [13]: an informal structure perhaps constructed on a temporary basis which may serve as the basis of a more formal structure to be constructed later. VIKI spatial collections [13] are an example of such a structure.

Let us now look at some specific aspects of structure. While we eschew formalism, the discussion that follows is a kind of informal metalanguage for the type of framework in which a structural description would need to be constructed.

Scope
A structural element may have a specific scope, indicating what other elements in the structure it relates to. An example is a set where the scope indicates which elements are members of the set; another example is a bounded region in a spatial hypertext where the scope is whatever elements fall within the region. Hypertext anchors are often conceived of as such a bounded region.(A set might be indicated as a region, of course, or set membership might need to be specifically designated independent of any presentation issues.) Yet another example is the familiar Dexter concept of composite, whose scope is all the elements contained in the composite. All XML tags are either designated as “point markers” or they have a clearly designated scope.

Some structural elements may be deemed not to have an effective scope. What is the scope of a hypertext link? There is room for considerable divergence of opinion on this. Some may consider the scope of a link to be the lexia or anchors at the two endpoints. Others may conceive of the link as being more like a programming GOTO statement and thus scopeless [4]. Any concept of structure must designate some elements as atomic; these elements may be considered scopeless (or such an element might be considered as having a scope consisting only of itself.)

Valence
The term valence is here borrowed from chemistry. Valence is a schema which represents for a given kind of structural element what must be “plugged into it” to have a valid instance. In many systems the valence of a hypertext link may be described as an ordered pair consisting of a source anchor and a destination anchor; in other systems the link may be much more complicated including perhaps a type (e.g. [15]), a link name, and so on. There may be some overlap between the concepts of scope and valence.

Depending on the structural framework, a valence specification may or may not includetype specificity. E.g. a structural framework may require that only anchors may be attached to a link; a different framework might allow any structural object to be attached to a link. There might be severe restrictions on the type of object that is allowed to be plugged into a link name slot (e.g. practically no hypertext systems allow the name of a link to be a link.)

Directionality
For some structural elements, such as a set, the concept of directionality does not apply; for others it may be extremely important, e.g. the typical unidirectional hypertext link. In other cases directionality may not be formally specified but may be “metaphorically present” — e.g. an Aquanet relation may be deemed to relate its elements “together”, implying an inward directionality toward some center. A structure such as a pile where the elements are so closely spaced that they overlap one another may have an implied outward directionality of all elements to spread themselves out.

Behavior Specificity
Behavior is a large topic, which will be discussed in more depth below. It is included here since a structural description may include behavior differences as the only way that structural elements are differentiated. E.g. in some literary hypertexts, “hot words” may not be graphically differentiated from those which do not serve as link anchors; the only way to tell is to click on the word and see what happens. (E.g. [9]).

The “dimensions” just given provide a kind of micro-language for describing structure; these aspects can be combined in arbitrary ways to describe a vast variety of structural possibilities. Openness to novel ways of combining such aspects is exactly what a hypertextuality of arbitrary structure is about.

Locality / Atomicity of Structure
Hypertext algorithms are typically localized [20]. Localization is also an issue that is important in discussions of structure. We spend much of our time in hypertext talking about highly localized structures, such as links. In fact, these structures are often referred to as if they were atomic, when that may or may not actually be the case [19]. What level of structural locality is really relevant? An example may help to clarify this issue. It is sometimes asserted that Aquanet relations can be expressed in a Dexter formalism as composites [Randy Trigg, personal communication]. Presumably this would work by defining an Aquanet relation as a composite of links. Putting aside the difficult question of whether the behavior would be correct in this “translation” of the relation concept (this question is discussed below), it is important to note that such a composite must function as a complete unit; the individual links in such a composite have no particular meaning with respect to the original abstraction, namely the relation. The “locality” that is significant is the entire composite. Likewise, consider a structure where a link name is associated with its link by a special kind of link. Does this link have any independent existence of its own?

While such questions might seem to be splitting hairs, the same type of issues are considerably more thorny when projected up to higher structural levels. Consider the structural concept of neighborhood. Let’s suppose that neighborhood is defined in graph-theoretical terms based on a node-link framework. E.g. the neighborhood of a node is defined as the set of nodes reachable via one link inbound to a given node. This may be very easy to define, yet difficult or impossible in practice to compute. Consider, for instance, the difficulty of computing neighborhoods where the hypertext system in question is the World Wide Web. In this case there is simply no hope of computing neighborhoods in any reasonable time.

While hypertext authors must be reasonable in the face of computational difficulty, it can be very frustrating for authors to be forced to work in a hypertext system where the system designer’s concept of structure is rigidly local, the author has requirements involving higher-level structural units, and the ability to manipulate such units should be doable but isn’t. Locality is a matter of context.

With this as a backdrop, we can consider some specific aspects of locality particularly as they relate to higher-level structure.

Structures may be composable
Higher level units may be constructed by iterating lower-level units. E.g. the concept of neighborhood above is constructed as iterations of the link. Networks may be composed by joining them with links. Such acts of composition, while they may in the general case produce an unacceptable computational load, may be in fact acceptable in the particular context of interest to a specific author or user. It is a difficult question whether authors need to be “protected from themselves” to be spared such computational minefields. In this author’s opinion, system designers must be prepared to include in their systems structural concepts of unknown computational load; determining whether a structural concept has “hit the limit” of what is computationally reasonable is part of the artistic process in the cyber-arts. In the case where a higher-level structural unit is computationally defined, e.g. by composition, of course the user must have the ability to interrupt the computation.

This results in an interesting question. What should be done with the partially computed structure when a computation is interrupted? There are two obvious possibilities: (1) the interruption should be considered an abort (perhaps a rollback in database transaction terminology) and the resulting structure delivered to the user (if at all) empty. (2) The structure should be delivered to the user in whatever degree of completion was achieved before the interrupt. Both choices pose difficult issues. One can imagine a concept like the neighborhood above where the user places an informal time constraint on the computation time, e.g. “let me see how much of a neighborhood I can construct for this node on the Web by letting this thing run overnight.” In this instance the user is not served by having the interrupt produce nothing, even when (say by consulting numerous search engines) the system did in fact produce a significant number of inbound links. On the other hand, if we accept alternative 2, we are forcing the system designer to include in the system provision for incomplete structures. This could cause significant difficulties if a structural concept has consistency constraints that are not met.

Structure locality must be semantically relevant
Regardless of how the primitive structural concepts of one hypertext system can in principle be represented in the primitives of another hypertext system, this representation must have real meaning. Consider the case dealt with above where Aquanet relations are represented as a composite of links. Does this unit function as a whole in the same way as the Aquanet relation? Does it have some identity distinct from other kinds of composites? Surely this would be required if the representation of relations as composites is more than a technical formalism: the relation concept has a semantic identity in the original hypertext system, and this identity must be preserved in the target hypertext system.

Or, consider an “index” constructed as a simple list of outbound anchors — say in HTML. How does one designate that this list functions as a unit? Such problems are quite easy to solve in XML: one simply invents (or better yet deploys some already agreed-upon convention for) a tag for this unit, and the scope of the tag designates the semantic locality of the structural concept.

Structure locality may need to be designated explicitly
Hypertext systems do not always provide the proper flexibility to do this. Consider a node-link hypertext that allows bi-directional links. What is the scope of a reverse link? Can we assume in all cases that the scope of the reverse link is identical to the anchor of the forward link? Perhaps not. Consider a simple citation link. The anchor for the forward link might be nothing more than the citation notation in the style sheet of the document, e.g. a string that might look like “[47]”. But depending on the circumstance, the scope of the reverse link might be an entire sentence, an entire paragraph, or possibly an entire section of a document. To make that scope identical to the anchor of the forward link might be extremely confusing for readers. In general, there may be no formal way to infer the scope of this reverse link; the author must simply designate it.

Structure locality may need to be discovered
This point is really the opposite of the point above. Discovery of structure by the reader may be an important part of an author’s concept; explicit designation of structure may in fact defeat this purpose, since an author may intend that a multiplicity of possible “derived structures” should be inferable from the author’s material. Structure locality might be defined not by the document author, but by a kind of annotative process by the reader. The hypertext literature is full of discussion of the reader acting as writer (e.g. [10]). Most often this is phrased in terms of the reader authoring hypertext structures, such as links or annotations. But there is no reason to assume the reader might not want to amend an author’s already-existing structures; for instance I might decide I as reader don’t like the scope of an author’s anchor and want to change it.

This raises an odd structural paradox. How is an author to indicate incomplete structure? E.g.: an author wishes to indicate that the scope of a reverse link is to be left to the reader, but within certain boundaries. How should this be notated? What are the interface requirements? Or, a similar example: the indeterminate link. Consider a case where an author wishes to indicate a link, where the target of the link will be determined in the future by some activity of the reader. (This could be based on a computation of which among many alternative lexia the reader visited for the longest time, some explicit action by the reader — say the first among alternative lexia to be bookmarked by the reader — or any number of other possibilities.) One method of handling such concepts of incomplete structure is to not indicate an incomplete structure at all until it is completed. This certainly simplifies the problem: we are now simply faced with a dynamically constructed hypertext. But surely this will not suffice for all authors. Returning to see whether the structure has been completed, and if so what it looks like may be part of an author’s intention; in this case there must be an explicit indication of the incomplete structure.

There is an obvious advantage in indicating incomplete structure to those systems where structure is achieved by some form of formal language, e.g. a markup language; in this case an incomplete structure can be indicated by means of e.g. markup where parameters are missing, or by variables which have not yet received values. This risks, of course, that a parser might return error messages for this incomplete markup. To avoid this problem, incomplete markup would have to be encapsulated in some way so that a parser would ignore it until it was completed. For instance, completions for structural properties might be indicated by a special kind of link; when the markup was completed the link would disappear and the completed structure would replace it.

THE RENDERING PROBLEM
By “the rendering problem” is not meant simply the issue of rendering e.g. text and graphics in the usual sense of say browser rendering engines. Here we are concerned with explicitly structural issues. In the following section we will give a taxonomy of some of those issues.

Participationin Structure
Every user of the Web is familiar with distinct rendering for link anchors (outbound, of course!) Typically an outbound link anchor is underlined. Rendering of structure participation indications for a hypertextuality of arbitrary structure is much more complex. The issues here are related to ones discussed above, e.g.:

Scopes, valences, behavior expectations, etc. need to be explicitly indicated
Aquanet allowed valence to be rendered via explicit diagram concepts; alas this extremely valuable insight has not been carried forward into many current hypertext systems. The idea currently popular in HTML that structure participation can be rendered solely by means of “in-line” text attributes seems particularly shaky. To accommodate arbitrary structure, it is hard to see how we can avoid rendering by some overtly external means.

Rendering of scope is a nasty problem. There are many intuitively straightforward ways of rendering scope — provided we all agree that scopes are nested and don’t overlap. Unfortunately that assumption is simply untenable if we are serious about the word ‘arbitrary’ in speaking of arbitrary structurality; the assumption that all scopes will be nested is just as outrageous as the assumption that all structures will be linear.

One approach to this problem is to have a generic method of rendering structure participation which is not explicit about the structural details. Consider the typical HTML rendering of an outbound link anchor as typographically distinct (in this case by underlining). A hypertext system could have a special typographical rendering that simply means: these words are structural participants. Obtaining the details might be achieved via behavior. For instance, an explicit structure indicator — perhaps an Aquanet-style diagrammatic rendering — might pop up as the cursor is moved over the structure participant, somewhat in the fashion of Zellweger’s fluid links [23]. Scope could be indicated by a simple marker that denotes a scope boundary; the actual extent of the scope could be indicated by behavior.

Rendering behavior has consequences — aesthetic, human factors, etc.
This is a very difficult issue. Regardless of the advances in computing technology of recent decades, certain aspects of the computing environment are still scarce resources, e.g. screen real estate. It is inherent in the nature of hypertext that it allows structures of vastly greater complexity than are easily represented by the geometry of the words themselves; the rendering of this structure has to fit somewhere. There are many conflicting demands upon screen real estate. Among them are:

• Maximizing the amount of “lexia text” which can be displayed readably
• Preserving on-screen informal or implicit structure
• Human-factors concerns regarding intuitive information display
• Aesthetic concerns per se of the author

There are similar issues concerning time as well as space. One method of solving rendering problems is to use animation. (E.g. [23].) However, animation has time consequences: it structures time in a particular way. Depending on the multimedia contents of a hypertext, the time requirements of animations used to render structure participation could conflict with time requirements the author has regarding other issues.

One approach to solving these problems is “pluggable” behaviors: the hypertext system could provide a “construction kit” whereby an author could build rendering behavior from a palette of tools sufficiently rich that conflicts like the ones discussed above could be avoided. This is apparently the suggestion made in the Structural Computing framework of [16]; however that framework leaves a bit vague the relationship between structures and behaviors.

In fact, it has been typical of most hypertext systems that they “hard-wire” many forms of behavior, specifically including the rendering of participation in structure. Hard-wiring behavior is just as restrictive as hard-wiring structure itself; a hypertextuality which is open to arbitrary structure must be open behaviorally as well. Of course this raises the issue of “arbitrary programmability”; for a full discussion of this issue see [20].

Representationof Structure
It goes without saying that a hypertextuality of arbitrary structure must have some way of rendering that structure. Hypertext lends itself quite naturally to very complex structures; it stands to reason that hypertext authors will want the best available techniques for representing complex structures. Ideally, as new techniques evolve, there should be some method of retrofitting them onto existing hypertext systems. [21] describes how multi-focus fisheye views were retrofitted onto VIKI. That experience is, alas, not entirely encouraging for hypertext authors, in that it required the system implementors to do the work that would allow including fisheye views. Ideally such work should be doable by document authors. To allow for this, hypertext systems will have to provide much more open APIs than is customary at present.

Representationof structure has most of the same issues discussed above under participation in structure; there are a few other new issues at this level.

Subsuming (collapse/expand) structural elements
Participants in a structure might be structures themselves; a rendering should allow the reader to subsume such a structure to a single entity and collapse it. Note that this is entirely separate from the kind of rendering behavior that might occur as a result of navigation. (Navigation is discussed below.) Consider a node-link hypertext which is tree structured in the vicinity of a particular node; let’s assume the user is “located” at that node. Without moving from the node, the user might wish to collapse all “child nodes” to a single graphic entity each, regardless of how many “grandchild” nodes (and further generations down) extend from a given child.

More generically:

Rendering of structures may need to include filters
The fisheye view concept [5] may be thought of as a kind of visual filter; others have been proposed. Such filters might have options that govern how distortions are handled. (See [21] for a discussion of of how proximity distortion vs. alignment distortion was handled in fitting fisheye views to VIKI.)

Representation of location within structure
This is, of course, the celebrated navigation problem. A full treatment of this problem is beyond the scope of this paper. Suffice it to say that the level of generality required to support arbitrary structure will require an interdependent methodology for representing location in structure. Beyond the usual issues of navigation, a hypertextuality of arbitrary structure has some special issues pertaining to location:

Location need not be a unitary concept
Most hypertext systems have some kind of concept of “current location”; typically this concept is unitary. I.e. there is just one “current location”. Consider, however, a structure such as a “symmetric” ternary relation. I.e. the structure is a triple, where all three slots are equivalent. One concept of location in this structure would assume that the reader will read the items occupying the three slots in some order, each one in turn; current location is a straightforward concept in this case, designating which of the three slots the user is reading. However, perhaps the author’s concept is that the three elements occupying the relation slots should “play simultaneously”. The concept of current location is now much more complex. Perhaps now all three slots are simultaneously open, and the user is located in all of them: a non-unitary concept of current location.

Many familiar user interfaces open a multi-paned window, or perhaps several windows simultaneously. Today’s user interface may have a unitary bias driven by the fact that there is only a single mouse cursor, but this unitary bias is certainly not logically necessary.

Non-unitary location means rendered objects have dependencies
If the user is “located in” multiple simultaneously open rendered objects (e.g. Windows), it is quite likely that those objects will contain informational dependencies. Thus the hypertext system will have to provide the document author with a method for managing these dependencies. Unfortunately, this is a complex subject. Prior experience with frameworks for dependencies among multiple open objects includes such celebrated cases as the well-known Model View Controller paradigm (MVC) [11]. Experience with MVC is best described as mixed; Smalltalk environments with off-the-shelf classes for MVC have proved a rich ground for experimentation, but MVC has not been popular in commercial systems, to the point that it is probably not an exaggeration to describe MVC as obscure among today’s software developers (never mind users!) Unfortunately, it has not been replaced by a comparable framework. To place the burden of inventing such a framework on today’s system implementors is asking a lot; but it is asking even more to place this burden upon the document author!

Parastructure
As discussed above, arbitrary structure must include informal and emergent structure; among the devices used to represent such structures are proximity, alignment, typographical conventions, and so on. As discussed above, parastructure may act as a constraint on other aspects of a hypertext system, in that structure rendering may need to preserve the parastructure.

THE BEHAVIOR PROBLEM
Behavioral issues have already figured prominently in this discussion; we now discuss behavior directly. The relationship between structure and behavior as it affects hypertext programmability has been discussed in [20]. This discussion will adopt that framework, with a particular emphasis on openness to arbitrary structure.

“Pure Behavior”
Analogous to the null structure discussed above is behavior with no structure at all. (See [20] for references to examples.) Pure behavior is simply “there”; it unfolds like a cinema and has no internal structure that the user can access. An example is an internally undifferentiated multimedia object which simply plays; perhaps it functions as a plug-in, or a guest algorithm in the terminology of [20]. Even though such an object may exist as a node in a larger structural framework, from a structure point of view it exists as an atomic object. Nevertheless, there may be some subtle interactions between such an object and other components that are specifically tied to points in a structure.

A pure behavior player must be a compatible guest
As noted above, arbitrary structure may require a dependency mechanism among “parallel” pieces. A pure behavior piece must be compatible with such a scheme. If it is controlled by a multimedia player object, perhaps that object is sent parameters or signals from other components in the structure. There must be a framework for how this takes place.

Pure behavior must be properly exportable
One of the obligations of a hypertext system is to properly save its state at points where this makes sense — both for reader and writer. A pure behavior object must participate in this. Of course it might be an aesthetic decision on the part of the author that a pure behavior object should replay from the beginning whenever its state is restored, but another author might include behavior objects which take so long to play out that (intentionally) the entirety of the play sequence cannot possibly be completed in a single session; in this case it may be aesthetically important to the author for the object to resume where it left off.

Similarly, a pure behavior object must be able to participate in transitions. Transition behavior will be discussed below; in that context pure behavior is simply a special case.

“Structure behavior” must allow for pure behavior
Many hypertext systems assume that their own “built-in” behavior is the only kind of behavior which will occur. This can pose conflicts if a pure behavior object is inserted into the space. Consider, for instance, a user interface — perhaps one to assist the blind — which relies on sound. A player object has a sound track. What should be the relation between these? Should they play simultaneously? Should the user interface sound interrupt the “pure behavior sound”? Perhaps the user interface sound might behave differently if it knew that a “pure behavior” player object with sound was playing.

Navigation Behavior
Navigation behavior is arguably among the most important kinds of behavior in hypertext. The expectation when a user e.g. clicks on a link is that something will happen. It is typical for hypertext systems to make assumptions about navigation behavior — assumptions with which the document author may not agree. An important issue in a hypertextuality of arbitrary structure is how the document author may create her own effects in navigation behavior. In the literary world we care a very great deal about these matters.

Transition effects
Consider the simple act of following a link in HTML. It is customary for the browser to repaint the screen completely to render the target page. This can cause a noticeable blink if the replacement page is substantially the same — even at a high bandwidth. Environments such as HyperCard [6] allow for explicit transition effects that delineate how the screen will change from one “card” to another. Perhaps the user wants a smooth fade from one screen to another. Note this interacts with the issue of exportable behavior just discussed. If there is to be a smooth transition from a static “structure object” to a dynamic “pure behavior” object, enough of that pure behavior must be exportable to the system to accomplish this. This is a difficult problem if not explicitly designed in to a framework; it is hard to imagine how an arbitrary guest algorithm exports enough of this behavior to allow for transition effects.

Other kinds of transition effects include flying (e.g. Web Squirrel [2]) — navigation in Web Squirrel causes the reader to “fly” over the space to the target object — and zooming (e.g. Pad++ [1]). It took considerable effort to implement the zooming behavior in Pad++. What is the poor author to do if both the kind of zooming behavior implemented in Pad++ and structural concepts not implemented in Pad++ are desired?

Interface behavior
Interface behavior has an intimate relationship to structurality. Consider a structure such as a ternary relation. Such a structure is known in advance to have 3 slots; an authoring system might use this information behaviorally in the case where, for instance, not all of the slots have been completed. E.g. when composing the relation, if the author attempts to “close” the relation in an authoring mode and not all slots have been completed, perhaps a warning dialog should be displayed. A reader would expect such behaviors as: open all slots simultaneously, close all slots simultaneously, display a list of the slots, etc. Some of these behaviors may raise difficult implementation issues in which the author may want to participate. Consider the case of opening all slots of a relation simultaneously. Screen real estate is always in short supply. Something will have to be hidden to open new objects. What should the “hiding policy” be? How can a document author participate in this policy? How can the reader? Let’s suppose further that our ternary relation brings together elements from “distant” places in the hypertext. What should the behavior be when these places are opened? It is exactly issues such as this that raise serious difficulties for the kind of formal “emulation” exemplified by the belief that e.g. Aquanet relations can be modeled as composites of links. If a relation is simply a composite of links, the assumption must be that “opening a relation slot” consists of following one of these links — with whatever behavior is entailed by following a link in the system in question. The idea of opening all the slots simultaneously — in some form of coherent display — is not available. Thus the interface behavior of a relation may not be correctly modeled by the interface behavior of a composite of links.

Parastructural Behavior
Parastructure was discussed above; while parastructure is often associated with issues of spatiality, there are behavioral issues here as well. A simple hypertext link may be thought of as (in some cases at least) an attraction between the linked elements; the opposite concept is also possible, namely a repulsion between elements. An author might want to indicate this parastructure behaviorally, e.g. repelling elements might be actually seen to “fly apart”. Such parastructural behavior is currently rather uncommon, but a framework for arbitrary structurality should provide for it. (For a discussion on the subject of “anti-links” see [8].)

REFERENCES
1. Bederson, Benjamin B. and Hollan, James D., “Pad++: A Zooming Graphical Interface for Exploring Alternative Interface Phsyics”, Proc. ACM UIST’94, ACM, New York, 1994.

2. Bernstein, Mark, “Neighborhoods in Spatial Hypertext”, SIGLINK Bulletin, 1998, to appear.

3. Cortázar, Julio, Hopscotch, trans. Gregory Rabassa, Avon, 1966.

4. DeYoung, Laura, “Linking Considered Harmful”, Proceeds from the European Conference on Hypertext, Versailles, France, 1990, Cambridge University Press, Cambridge, 1990.

5. Furnas, G. W., “Generalized Fisheye Views”, Proceedings of CHI’86, ACM, New York, 1986, pp. 16-23.

6. Goodman, Danny, The Complete HyperCard Handbook, Bantam Books, New York, 1987.

7. Halasz, Frank G., and Schwartz, Mayer, “The Dexter Hypertext Reference Model”, Hypertext Standardization Workshop, NIST, 1990.

8.Thread "Anti-Links?", ht_lit Mailing List, September, 1979, ftp://consecol.org/pub/ht_lit/ht_lit.9709.

9. Joyce, Michael, Afternoon, Eastgate Systems, Watertown, MA, 1990.

10. Joyce, Michael, Of Two Minds: Hypertext Pedagogy and Poetics, The University of Michigan Press, Ann Arbor, 1995.

11. Krasner, G. E., and Pope, S. T., “A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80”, Journal of Object Oriented Programming, August/September, 1988, 26-49.

12. Marshall, Catherine C., Halasz, Frank G., Rogers, Russell A. and Janssen, William C. Jr., “Aquanet: a hypertext tool to hold your knowledge in place”, Proceedings of Hypertext ‘91, ACM, New York, 1991, pp. 261-275.

13. Marshall, Catherine C., Shipman, Frank M. III, and Coombs, James H., “VIKI: Spatial Hypertext Supporting Emergent Structure”, European Conference on Hypermedia Technology 1994 Proceedings, ACM, New York, 1994, pp. 13-23.

14. Moulthrop, Stuart, “Shadow of the Informand: A Rhetorical Experiment in Hypertext”, Perforations 3, Public Domain, Atlanta, GA, 1992.

15. Nanard, Jocelyne, and Nanard, Marc, “Using Structured Types to Incorporate Knowledge in Hypertext”, Proceedings of Hypertext ‘91, ACM, New York, 1991, pp. 329-343.

16. Nürnberg, Peter J., Legget, John J., and Schneider, Erich R., “As We Should Have Thought”, Hypertext 97, ACM, New York, 1997, pp. 96-101.

17. Parunak, H. Van Dyke, “Don’t Link Me In: Set Based Hypermedia for Taxonomic Reasoning”, Proceedings of Hypertext ‘91, ACM, New York, 1991, pp. 233-242.

18. Rosenberg, Jim, “Navigating Nowhere / Hypertext Infrawhere”, SIGLINK Newsletter 3, 3, December 1994, pp. 16-19, http://www.well.com/user/jer/NNHI.html

19. Rosenberg, Jim, “The Structure of Hypertext Activity”, Hypertext ‘96, ACM, New York, 1996, pp. 22-30, http://www.cs.unc.edu/~barman/HT96/P17/SHA_out.html.

20. Rosenberg, Jim, “Locus Looks at the Turing Play: Hypertextuality vs. Full Programmability”, Hypertext 98: The Proceedings of the Ninth ACM Conference on Hypertext and Hypermedia, ACM, New York, 1998, pp. 152-160.

21. Shipman, Frank M., Marshall, Catherine C., and LeMere, Mark, “Beyond Location: Hypertext Workspaces and Non-Linear Views”, Hypertext 99: The Proceedings of the Tenth ACM Conference on Hypertext and Hypermedia, ACM, New York, to appear.

22. Stotts, P. David and Furuta, Richard, “Petri-net based hypertext: Document structure with browsing semantics”, ACM Trans. Off. Inf.Syst., 7, 1, (January), 1989.

23.Zellweger, Polle T., Chang, Bay-Wei, and Mackinlay, Jock D., “Fluid Links for Informed and Incremental Link Transitions”, Hypertext 98: The Proceedings of the Ninth ACM Conference on Hypertext and Hypermedia, ACM, New York, 1998, pp. 50-57.