Abstract

Recently, a call was made for the hypertext community to “return to its roots” by re-exploring our interdisciplinary nature, renewing the areas of common interest with the diverse set of researchers that comprise this community. In this paper, we lay out a set of research questions inspired by several research threads that were active in prior iterations of the hypertext community, but have recently slipped from our focus. The developments of the intervening years have in many cases added nuance and depth to these open questions, potentially making them of renewed interest to the present community. We present these questions through the lens of a maximalist vision that places structure front and center of our model of the world, relegating data to second-class status. We follow the implications of this vision to recover a set of open questions that once occupied, and may once again occupy, a large portion of the interest of the hypertext community.

The Fallacy of Data

It is a common misconception that hypertext and hypermedia systems1allow the building of structures (possibly non-linearizable) among data. In this view, data are a given—little atoms of meaning constructed “somehow”—while the hypertext structures built among them add additional layers of meaning. We have a scholarly article about a shortbow, and another about the Crusades, and then a clever annotator builds a link between the two to indicate “here’s a relationship not (necessarily) implicit in the articles.” Step 1: add structures. Step 3: profit.

Aside from the fact that we (like the South Park gnomes2) never really nailed Step 2, we have been wrong about the data part of this process the whole time. We do not structure data. We just structure other structures. It really is structure, all the way down.

Structure is Fundamental

If everything is structure, it is helpful to develop a working definition before going any further. Among other definitions, Merriam-Webster gives these definitions that seem to capture much of the intent of the usage of the term in the hypertext literature:

• “the arrangement of particles or parts in a substance or body;”

• “organization of parts as dominated by the general character of the whole;” and,

• “the aggregate of elements of an entity in their relationships to each other [14].”

For purposes of this paper, you should feel free to pick any of these or your own compatible definition. (If your definition of structure is incompatible with the above, we ask you to accept the least offensive version above for the remaining pages.)

One aspect of these definitions (and maybe the most controversial or at least most overlooked aspect within the hypertext community) is the reference to the context within which the structure is located (see “body,” “whole,” and “aggregate,” above.) For example, a link doesn’t (shouldn’t?) exist independent of all else in the world. It has a context, a set of other meaningful links, that together are “a structure.” (Can there be structures comprised of a single link? Certainly, but that may be a special case, and even then, there should be nothing to preclude adding additional links in the future. Structure evolves.)

It may be tempting to place this context (i.e. the structure) as an entity “above” the links (i.e. structural elements) in this case—the structure contains the structural elements—but there are two important observations to make. Firstly, the structure itself is also potentially a structural element, able to be aggregated into other structures (related to the “first-class links” concept [8,13,21].) In the link example, a structure comprised of contexts might represent a viewpoint; a structure comprised of viewpoints might represent a dialectic; etc. Secondly, the things being linked are themselves structures, even if its elements are (as yet) only implied. The article has sections; the text has back- and forward references; it makes citations to other texts, etc. That is, they also have structural elements. They are also structure. In this sense, wherever one apprehends structure, one can also envision the structure(s) in which it participates and the structure(s) it relates. All the way (up and) down.

Implications

Adopting the “no-data” (or “all-structure”) perspective can help us understand hypertext and hypertext systems in a more comprehensive, expanded way. Going all-in on structure can help us reclaim some of the “big vision” of the earliest days of the hypertext community, and helps us remember that hypertext is as much a matter of perspective [3] as a particular technology.

Below, we discuss four implications of an all-structure perspective. For each, we identify areas of research that were once more prominent in the hypertext community, and consider some of the research questions in those areas that are still open.

Systems

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?

Models

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?

Context

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 20thcentury 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?

Components

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?

Answering Potential Critiques

There are a number of potential critiques of an all-structure approach. This section attempts to formulate a response to some such critiques.

Atoms

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.

Implicitness

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.

Primacy

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.

Conclusions

In this paper, we (the authors) presented an “all-structure” view of the world, and followed the implications of such a view to rediscover potentially old research threads in a new context. These threads are not idle curiosities. They all challenge simplifying assumptions the world around us has made about hypertext systems that have resulted in an impoverishment of the original, inspiring vision of early hypertext pioneers.

We (the community) have come to accept an overwhelmingly navigational (node/link) view of hypertext, marginalizing the incredible variety of structures and structural abstractions we find in the real world. We have come to accept a mono-structural world in which one structure is primary and others (if any) are relegated to derivative status, ignoring the decades of philosophy, literary-critical theory and simple lived experience that encourages us to remain open to evolving, competing structures and understandings. We have come to accept data objects as given, relegating mash-ups and reinterpretations to other, non-hypertext tools that generate other, fixed data objects upon which our systems might operate. We were fully aware of these shortcomings in the past. Let us rediscover the depth and breadth of what hypertext systems could and should be.

[^fn3]: 1For the remainder of this paper, we use the term “hypertext” to include hypermedia.

[^fn4]: 2Seehttps://en.wikipedia.org/wiki/Gnomes_(South_Park).

[^fn5]: 3We mean component in the Dexter model sense, i.e. elements that are structured.

[^fn6]: 4Seehttps://en.wikipedia.org/wiki/One-electron_universe.

References

[1]Robert M.Akscyn,Donald L.McCracken, andElise A.Yoder.1988.KMS: a distributed hypermedia system for managing knowledge in organizations.Commun. ACM31,7(1988),820–835.10.1145/48511.48513

[2]Kenneth M.Anderson,Richard N.Taylor, andE. JamesWhitehead.1994.Chimera: hypertext for heterogeneous software environments. InProceedings of the 1994 ACM European Conference on Hypermedia Technology(Edinburgh, Scotland)(ECHT ’94).Association for Computing Machinery,New York, NY, USA,94–107.10.1145/192757.192783

[3]ClausAtzenbeckandPeter J.Nürnberg.2019.Hypertext as Method. InProceedings of the 30th ACM Conference on Hypertext and Social Media (HT ’19).ACM,New York, NY, USA,29–38.10.1145/3342220.3343669

[4]PeterBrusilovsky.2001.Adaptive Hypermedia.User Modeling and User-Adapted Interaction11,1-2(2001),87–110.10.1023/A:1011143116306

[5]JeffConklin,AlbertSelvin,Simon BuckinghamShum, andMaartenSierhuis.2001.Facilitated hypertext for collective sensemaking: 15 years on from gIBIS. InProceedings of the 12th ACM Conference on Hypertext and Hypermedia.ACM,New York, NY, USA,123–124.10.1145/504216.504246

[6]SteveDeRose,EveMaler,DavidOrchard, andNormanWalsh.2010.XML Linking Language (XLink) Version 1.1.Technical Report.W3C.http://www.w3.org/TR/2010/REC-xlink11-20100506/W3C Recommendation 06 May 2010.

[7]Douglas C.Engelbart.1975.NLS Teleconferencing Features: The Journal, and Shared-Screen Telephoning. InProceedings of the CompCon75 Conference.173–176.http://dougengelbart.org/content/view/137/000/

[8]DougEnglebart.1986.The augmented knowledge workshop. InProceedings of the ACM Conference on The History of Personal Workstations(Palo Alto, California, USA)(HPW ’86).Association for Computing Machinery,New York, NY, USA,73–83.10.1145/12178.12184

[9]A.Fountain,W.Hall,I.Heath, andH.Davis.1990.Microcosm: An Open Model for Hypermedia with Dynamic Linking. InHypertext: Concepts, Systems and Applications, Proceedings of ECHT’90, Paris, November 1990,A. Rizk,N. Streitz, andJ. Andre(Eds.).298–311.https://eprints.soton.ac.uk/254308/

[10]Frank G.HalaszandMayerSchwartz.1994.The Dexter Hypertext Reference Model.Commun. ACM37,2(21994),30–39.10.1145/175235.175237

[11]George P.Landow.1987.Relationally encoded links and the rhetoric of hypertext. InProceedings of the ACM Conference on Hypertext(Chapel Hill, North Carolina, USA)(HYPERTEXT ’87).Association for Computing Machinery,New York, NY, USA,331–343.10.1145/317426.317450

[12]John J.LeggettandJohn L.Schnase.1994.Viewing Dexter with open eyes.Commun. ACM37,2(Feb.1994),76–86.10.1145/175235.175241

[13]Catherine C.Marshall,Frank G.Halasz,Russell A.Rogers, andWilliam C.Janssen.1991.Aquanet: a hypertext tool to hold your knowledge in place. InProceedings of the 3rd ACM Conference on Hypertext.ACM,New York, NY, USA,261–275.10.1145/122974.123000

[14]Merriam-Webster.2025.Structure. Retrieved 11 Jun 2025 fromhttps://www.merriam-webster.com/dictionary/structure

[15]NormanMeyrowitz.1986.Intermedia: The architecture and construction of an object-oriented hypemedia system and applications framework.ACM SIGPLAN Notices21,11(1986),186–201.10.1145/960112.28716

[16]S.Moulthrop.1989.Hypertext and “the hyperreal”. InProceedings of the Second Annual ACM Conference on Hypertext(Pittsburgh, Pennsylvania, USA)(HYPERTEXT ’89).Association for Computing Machinery,New York, NY, USA,259–267.10.1145/74224.74246

[17]Theodor HolmNelson.1993.Literary Machines: The report on, and of, Project Xanadu concerning word processing, electronic publishing, hypertext, thinkertoys, tomorrow’s intellectual revolution, and certain other topics including knowledge, education and freedom (93.1 ed.).Mindful Press.

[18]Peter J.Nürnberg,Uffe K.Wiil, andDavid L.Hicks.2004.A Grand Unified Theory for Structural Computing. InProceedings of the International Metainformatics Symposium 2003(Lecture Notes in Computer Science, Vol.3002),David L.Hicks(Ed.).Springer,1–16.10.1007/978-3-540-24647-3_1

[19]SiegfriedReich,UffeWiil,PeterNürnberg,HughDavis,KajGrønbæk,KennethAnderson,DavidMillard, andJoergHaake.1999.Addressing interoperability in open hypermedia: The design of the open hypermedia protocol.The New Review of Hypermedia and Multimedia5(011999),207–248.10.1080/13614569908914714

[20]ManolisTzagarakis,DimitrisAvramidis,MariaKyriakopoulou,Monica M. C.Schraefel,MichalisVaitis, andDimitrisChristodoulakis.2003.Structuring primitives in the Callimachus component-based open hypermedia system.Journal of Network and Computer Applications26,1(2003),139–162.10.1016/S1084-8045(02)00064-4

[21]E. JamesWhitehead.2002.Uniform comparison of data models using containment modeling. InProceedings of the Thirteenth ACM Conference on Hypertext and Hypermedia(College Park, Maryland, USA)(HYPERTEXT ’02).Association for Computing Machinery,New York, NY, USA,182–191.10.1145/513338.513384

[22]Uffe KockWiil.2000.Towards a Proposal for a Standard Component-Based Open Hypermedia System Storage Interface. InOpen Hypermedia Systems and Structural Computing. 6th International Workshop, OHS-6. 2nd International Workshop, SC-2. San Antonio, TX, June 3, 2000(Lecture notes in computer science, Vol.1903),SiegriedReichandKenneth M.Anderson(Eds.).Springer,23–30.http://www.springerlink.com/link.asp?id=gyj9br48n1lky5lx

[23]NicholeYankelovich,Bernard J.Haan,Norman K.Meyrowitz, andSteven M.Drucker.1988.Intermedia: The Concept and the Construction of a Seamless Information Environment.Computer21,1(1988),81–96.10.1109/2.222120