3.1

If everything is structure, hypertext systems need to be open with respect to both participants in structures and structural abstractions. That is, users of hypertext systems must be able to structure any addressable resource, not just those created in or managed by the hypertext system itself. Users must also be able to define new types of structures.

Early hypertext systems research focused on monolithic, self-contained systems (e.g. [1,7,23]). In such systems, data elements were created or imported and structured according to the abstractions provided by the system itself. The limitations of such systems were quickly apparent. Although well-suited to understanding how users might interact with systems that provided explicit structuring mechanisms to augment implicit structures inherent within data elements, monolithic systems were constrained in ways that hindered widespread adoption.

As an alternative, several members of the hypertext system community first proposed open hypertext systems, or OHSs (e.g. [2,9,12]) to allow users to structure “external” documents; and then later component-based OHSs, or CB-OHSs (e.g. [20,22]) to allow definition of new structural abstractions. Many OHSs were inspired by the flexibility of the Dexter Hypertext Reference Model [10], which specifically addressed hypertext system interoperability and globally addressable “components” (i.e. referents of structural elements). Likewise, CB-OHSs were inspired by the plethora of structural domains (coherent sets of structural abstractions), such as deliberative structures [5] and spatial structures [13], augmenting the navigational or associative structures most commonly associated with hypertext.

Pervasive structure may call for a return to the focus on CB-OHSs, with their ability to allow users to structure arbitrary resources in arbitrary ways. There are many open questions, however, perhaps primary among these being the description and implementation of new hypertext domains. Adding new structural abstractions to CB-OHSs was a systems-level programming exercise. How can hypertext systems be open to defining new structural abstractions and domains in a straightforward and intuitive manner? What interfaces can we present users that allow rigorous definition without unnecessary toil?

3.2

If everything is structure, we need a conceptual model that reflects this. That is, we need an equivalent to a Dexter model that expresses our all-structure understanding of the world.

At least conceptually, the model for navigational hypertext creation can seem like graph definition, especially with the World Wide Web. The world provides us with a sea of “pages” of various types, and we define links between these pages. In this model, the basic operations are:

(i) create a node

(ii) delete a node

(iii) link multiple nodes together

This data-centric model suffers from some obvious drawbacks when trying to capture activities in a hypertext system. Firstly, nodes in the model are atomic. One cannot further break apart a node once created. There may be an “inherent” structure within a node (e.g. HTML that defines a structure of a document or node), but there is no good way to impose further structure upon atoms within a node. (It might be claimed that XSLT allows a restructuring of nodes. However, we feel it is more accurate to consider XSLT as a creator of new nodes than imposing new structure on existing nodes.) Secondly, it is not clear how to impose higher levels of structure upon the created links. Even relatively obscure Web extensions such as XLink [6] provide second-class structuring options.

The EAD model (proposed at ACM Hypertext 2004 [18]) was developed as an alternative to the “data-centric” model of graph creation. In EAD, the basic operations for creating structures are:

(i) elucidate a link

(ii) analogize from an existing structure

(iii) delete a link

There are no “nodes” as such; the world provides us a sea of (perhaps unelucidated) links (the “pages” above.) This sea is also a link in its own right. We can further define structures within existing links with the elucidate operation, and recursively copy existing structures within existing links with the analogize operation.

As well as EAD fits an all-structure perspective for navigational or associative structural abstractions such as link, it was never extended to non-navigational domains. What are the EAD equivalents for spatial hypertext, taxonomic hypertext, deliberative hypertext, or narrative hypertext? How can such EAD extensions motivate new system design and/or interoperability among existing systems?

3.3

If everything is structure, we need to move past simplistic understandings of a singular, privileged structure and embrace outlooks that naturally and gracefully allow multiple structures that co-exist side-by-side. That is, we need a robust model of context.

Although hypertext theoreticians have long extolled the potential for hypertext to accommodate multiple viewpoints (e.g. [4,15,17]), practically, many hypertext systems allow the definition of a single structure. Elements defined by one user are by necessity presented to all other users. Such mono-structural systems fall far short of the vision of the early hypertext community. They are philosophically structuralist in the early to mid 20^thcentury sense, presenting a point-in-time understanding of one author, presupposing its primacy and stability. As such, they are subject to many of the same post-structuralist critiques leveled at structuralism in other fields.

In contrast to this mono-structural viewpoint, the OHS Working Group model defined context (at least in the navigational domain) as a fundamental abstraction [19]. Contexts were intended to allow multiple structures to exist side-by-side, to account for different users, different tasks for the same user(s), or even simply variants over the same task. Hypertext literature researchers, many of whom drew upon or even explicitly cited post-structuralists, played an important part in prior iterations of the hypertext community (e.g. [11,16])

Even accepting the importance of the context abstraction as a way of modeling the ability to support multiple peer structures over the same components, there are many open questions. How should hypertext systems present such an open set of structures to users? What does it mean to “activate” or “deactivate” a context, or is a more appropriate interaction model based on “emphasizing” and “de-emphasizing” contexts? How should temporal evolution or versioning be made available to both producers and consumers of structure?

3.4

If everything is structure, we need to understand how to extend our structuring capabilities to what we previously considered (atomic) data. That is, we need to dissolve the “data border” to allow users to (re-)structure components.3

Current hypertext systems enforce a data border, or floor beneath which structure is either missing or fixed. Linking to a PDF document on the Web, for example, provides us an atom of sorts; a document that has an implicit structure perhaps (maybe sections, paragraphs, etc., of text, figures, tables, etc.) but no opportunity to restructure or further structure its contents.

Structural computing systems [18] were proposed as a structure-first analog to data-first hypertext systems. As such, there was at least thepossibilityof structuring past the data border, or at least a recognition of the fact that the data border is an artifact of system implementation. There is no theoretical limit to the destructuring that could take place within structured items. (There are almost certainly practical limits for any given system implementation, but these are either manifestations of a lack of time/interest/imagination on the part of the user, or a lack of functionality of our systems.) Any document one could reference in such a system would be subject to further interpretation, further structuring, simply by “blowing up” the existing structures. Perhaps sentences, paragraphs, etc., from a text document could be reordered or reused. Images could be decomposed, allowing elements to be recombined in new ways. Videos and audio tracks could be temporally resequenced. This is, in essence, a broadening of the concept of elucidation described above.

Even with this recognition, there are many practical questions. How can systems “disassemble” documents? Should this be fully automatic, partially so, or entirely human-driven? How should systems treat existing implicit structure? Should elements of such implicit structures be “imported” into the hypertext system and managed as first-class abstractions? How can AI be used to help with de-/re-structuring?

4.1

Quoted passage:

Surely, there are “atoms” that are not structures. Consider, for example, a natural number, a musical note, or a fundamental particle such as an electron. These certainly appear to be “irreducible,” data atoms that resist further elucidation. (Or, put differently, an enforcement of a data border.) Electrons are so indistinguishable, it has even been proposed that there is only one electron in the universe!4

Upon further inspection, however, it is not at all clear that any of the examples above, or really any seeming data atom, is truly incapable of further elucidation. A natural number has factors; a musical note has a waveform; an although an electron is a seemingly fundamental particle, the chemical atom itself (a structure in which electrons can participate) was itself seen as irreducible not even 150 years ago. It is probably more accurate to say that whateverappearsto be an irreducible data atom is really a structure with an unexercised potential to be elucidated into a structure in some other context or at a future time.

4.2

Quoted passage:

People have always understood there is structure within data. For example, even very old works such as classical Chinese texts or the Talmud are commonly cited as “non-electronic hypertexts” with rich structures, open-endedness, and non-linearity. An all-structure view may really be nothing new at all. Structure has always been recognized as a critical part of both writing and reading.

However, these structures are oftenimplicitin the systems sense. That is, even if the structures themselves are made explicit in some sense, applications that display or manipulate them may not reify them, meaning from the systems perspective, such structures are implicit. Does anyone consider an application that can view apictureof a page of Talmud marginalia as a hypertext application, simply because it displays structure? The page itself may be hypertextual, but for an application to be considered hypertext-aware, it would need to reify those hypertextual structures. A structure-first perspective is a statement of system architectural intent as well as a philosophical statement.

4.3

Quoted passage:

The calls for context are well-understood and even implemented by modern systems. Even web browsers, considered by some to be a popular but less than fully-functional hypertext systems, can carry out DOM manipulations through XSLT or JavaScript, showing that even embedded HTML structures are provisional. The mono-structural complaint is a strawman.

Claiming that other structures can be derived from some primary structure is hardly the same as supporting multiple peer structures side-by-side. Firstly, such derivations are, as a rule, fairly complex to execute, relegating structure derivation to the domain of specialists. Asserting that it ispossibleto transform arbitrary structures into other arbitrary structures is akin to claiming that all Turing complete programming languages aretechnicallyequivalent—true, but not useful. Secondly, forcing all structures to be defined relative to some ur-structure by definition makes these derivatives secondary. (Secondary) structures with very different purposes from the “source” structure will have correspondingly complex transformational expressions. As a thoughts experiment, define the appropriate DOM manipulation on a slug of HTML that extracts a steganographically encoded message.