\meta{("some-hypertext-features"
       "beyond wikis: hypertext stuff"
       ("hypertext"))}

For many people, the word 'hypertext' brings to mind HTML and wikis. Hypertext encompasses a wide range of systems, artifacts, and approaches, from choose-your-own-adventure books to experimental literature, from Twine games to HyperCard, and so forth. But—for good reason!—HTML has become ubiquitous, and with it, its approach to hypertext.

On the other hand: previous decades included a lot of experimental hypertext systems which pushed out into interesting different directions that aren't as common in modern hypertext systems.

What follows are just a handful of interesting features of older hypertext systems that are mostly or completely lacking in modern HTML.

\h2{Typed Nodes}

In raw HTML, pages are, for the most part, amorphous, unstructured information soup. Pages are structured in the sense of having \em{markup}, but that markup is for people. Web designers often try to structure HTML in a way that's more meaningful to a computer—for example, with structure-indicating tags like \tt{<header>}, or with efforts like the \link{https://www.w3.org/standards/semanticweb/|Semantic Web} or \link{http://microformats.org/wiki/Main_Page|Microformats}—but that's not obligatory, and a given page in an HTML system could have a structure understood by machines, or it could be nothing but markup and links.

In contrast, some other hypertext systems distinguish nodes based on what "type" of node they are, which can have ramifications for the structure of the node: for example, we could build up a hypertext system for describing places in which there is a specific "type" of node for describing city. Instead of \em{just} being a mass of formatted text and links, like an HTML page, it would have a set of specific fields: the name of the city, the population, its area, its location, and so forth.

Some values of these fields could be links, but those links could also stipulate the sort of thing they link to: a city might have a field telling us what country it is in, and our system could prevent us from accidentally filling in that field with anything other than a country.

Certain historical hypertext systems used nodes of this type: for example, \link{http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.438.8515&rep=rep1&type=pdf|Aquanet} took its node "types" directly from Common Lisp class definitions, so that each field of a page corresponded to an instance variable (or \em{slot}, in Common Lisp parlance) of an object.

\h2{Typed Links}

In HTML, a hyperlink usually doesn't \em{mean} something to a computer beyond providing an affordance to . It usually means something to a \em{reader}, but the semantics aren't necessarily conveyed in a machine-readable way.

This isn't always true: for example, some HTML hyperlinks are annotated to let the computer know that \em{this} link is to the next page in a sequence, while \em{this} link is to the previous, or other roles. But some other hypertext systems took that notion even further, allowing for documents that conveyed more precise information about their hypertext structure.

For example, you can imagine a hypertext system which describes places, and has links with specific geographical and spatial connotations: a link could specify in a machine-readable way that a given place \em{contains} another place, and use this link to link the \em{Italy} node to the \em{Rome} node, and in turn the \em{Rome} node to the \em{Coliseum} node.

In doing so, you not only build up a hypertext structure with richer affordances for navigation, but also with richer affordances for \em{automated reasoning}. I could, for example, query my hypertext system by asking, "What are other places that are contained within the same place that contains the Coliseum?"

Numerous old papers on hypertext systems consider the problem of attempting to build and reason about arguments, and usually start from the \link{https://en.wikipedia.org/wiki/Toulmin_method|Toulmin model of reasoning}. Systems that include typed links could represent relationships like \em{is-a-fact-that-supports} directly as links, so a user could query the system by asking, "What are all the nodes that are supporting facts for this thesis?"

\h2{Link Arity And Direction}

In HTML, a link is one-way: if I include a link in document A which leads to document B, I won't necessarily have a link back. There are various ways of synthesizing backward edges: by including smarts in the browser (e.g. the 'back' button) or in particular applications (e.g. a wiki's 'what links here' feature) or by cross-application mechanisms (e.g. 'pingbacks' in WordPress or other CMS systems), but none of these are inherent in the HTML
mode.

Some other hypertext systems include links that are \em{inherently} two-directional. These systems build up stronger interconnectedness between nodes, because there are no "dead-end" paths: you can always at least move back the way you came, and creating a new node also creates a backwards path. In a system with typed links, this also means you can have links with swapped semantics: creating a \em{contains} link from \em{Italy} to \em{Rome} is the same operation as creating a \em{is-contained-in} link from \em{Rome} to \em{Italy}.

Even more extreme, some hypertext systems include links that join together more than two nodes. This doesn't make a whole lot of sense in something like HTML, where a link doesn't necessarily connote any particular "meaning", but in a system with typed links, we can imagine a link that brings together multiple nodes with a different denotation for each: in our hypothetical geographic system, we could have a ternary link that represents \em{is directly between x and y}.

In the most extreme, you could imagine a system that treats n-ary links as n-ary predicates.

The aforementioned Aquanet system contained not just typed nodes but also typed n-ary links, which were there called \em{relations}.

\h2{Spatial Hypertext}

In HTML, pages are identified by names. Organization is largely done by creating other pages that name things together. For example, I could create a web site in which I build up index pages that describe how I structure my site. URLs originally also mapped to hierarchical folder structures, and it's common for people to treat them in a similar way today, but by no means is that obligatory on the modern web.

Some historical hypertext systems took a different approach: each node was identified with a location in a spatial field, so navigating a piece of hypertext could involve not just links that 'took you' to other nodes, but also following spatial paths which connected nodes positioned on or along those paths.

Different spatial hypertext systems took different approaches to this: some of them allowed the user to move nodes around, which could be useful in editing the document. Others took the conceptual relationship between nodes as expressed in the hypertext and extracted a spatial system from that, building up 'maps' to help a reader navigate an otherwise abstract structure.

Some systems would even work in the opposite way: allowing the users to position nodes spatially, and then inferring information about the conceptual structure of those nodes from the common spatial patterns produced by users. This was the approach of the \link{http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.76.5062&rep=rep1&type=pdf|Viki} system.

There's actually a very good example of a modern spatial hypertext editing system: \link{|Twine}

\hr{}

Many of the features I've described are structural, and it's pretty obvious in retrospect that HTML and Wikis impose far less structure than many other hypertext systems. In many ways, this is to their advantage: an HTML page can mean anything you want it to, and an HTML link can also be used for any purpose.

On the other hand, this also makes certain operations infeasible or even nonsensical: a more structured hypertext system can perform operations by looking at the shape or structure of a collection of nodes or links, and can perform computer-aided reasoning. This is one of the reason why the Toulmin method showed up so often in past hypertext research: you were building up relationships between data in ways that you \em{and your system} could both reason about.