Added unfinished draft of hypertext post
Getty Ritter
9 years ago
| 1 | \meta{("some-hypertext-features" | |
| 2 | "beyond wikis: hypertext stuff" | |
| 3 | ("hypertext"))} | |
| 4 | ||
| 5 | For many people, the word 'hypertext' brings to mind HTML and | |
| 6 | wikis. Hypertext encompasses a wide range of systems, artifacts, | |
| 7 | and approaches, from choose-your-own-adventure books to experimental | |
| 8 | literature, from Twine games to HyperCard, and so forth. But—for | |
| 9 | very good reason—HTML has become ubiquitous, and with it, its | |
| 10 | approach to hypertext. | |
| 11 | ||
| 12 | On the other hand: previous decades included a lot of experimental | |
| 13 | hypertext systems which pushed out into interesting different | |
| 14 | directions that aren't as common in modern hypertext systems. | |
| 15 | ||
| 16 | Here are just a handful of features of older hypertext systems: | |
| 17 | ||
| 18 | \h2{Typed Nodes} | |
| 19 | ||
| 20 | In HTML, every page is a soup of information. Pages are structured | |
| 21 | from the point of view of the \em{markup}, but not really from | |
| 22 | the hypertext-level view of the page: an HTML page can be edited | |
| 23 | to include more information or less information, and there isn't | |
| 24 | really a way of distinguishing them. | |
| 25 | ||
| 26 | Some other systems distinguish nodes based on what "type" of node | |
| 27 | they are, which often gives them more structure: for example, | |
| 28 | we could build up a hypertext system for describing places | |
| 29 | in which there is a specific sort of node that describes a "city". | |
| 30 | Instead of \em{just} being a mass of formatted text and links, it | |
| 31 | would have a set of specific fields: the name of the city, | |
| 32 | the population, its area, its location, and so forth. | |
| 33 | ||
| 34 | Some values of these fields could be links, but those links | |
| 35 | could also stipulate the sort of thing they link to: a city | |
| 36 | might have a field telling us what country it is in, and our | |
| 37 | system could prevent us from accidentally filling in that field | |
| 38 | with anything other than a country. | |
| 39 | ||
| 40 | Certain historical hypertext systems used nodes of this type: | |
| 41 | for example, | |
| 42 | \link{http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.438.8515&rep=rep1&type=pdf|Aquanet} | |
| 43 | took its node descriptions directly from Common Lisp descriptions | |
| 44 | of objects, so that each field corresponded to an instance | |
| 45 | variable (or \em{slot}, in Common Lisp parlance) of an object. | |
| 46 | ||
| 47 | \h2{Typed Links} | |
| 48 | ||
| 49 | In HTML, a hyperlink usually doesn't mean anything in particular | |
| 50 | to a computer. It usually means something to a \em{reader}, but | |
| 51 | the semantics aren't necessarily conveyed in a machine-readable | |
| 52 | way. | |
| 53 | ||
| 54 | This isn't always true: for example, some hyperlinks are annotated | |
| 55 | to let the computer know that \em{this} link is to the next page | |
| 56 | in a sequence, while \em{this} link is to the previous, or other | |
| 57 | roles. But some other hypertext systems took that notion even | |
| 58 | further, allowing for documents that conveyed more | |
| 59 | precise information about their hypertext structure. | |
| 60 | ||
| 61 | For example, you can imagine a hypertext system which describes | |
| 62 | places, and has links with specific geographical and spatial | |
| 63 | connotations: a link could specify in a machine-readable way | |
| 64 | that a given place \em{contains} another place, and use | |
| 65 | this link to link the \em{Italy} node to the \em{Rome} node, | |
| 66 | and in turn the \em{Rome} node to the \em{Coliseum} node. | |
| 67 | ||
| 68 | In doing so, you not only build up a hypertext structure with | |
| 69 | richer affordances for navigation, but also with richer affordances | |
| 70 | for \em{automated reasoning}. I could, for example, query my | |
| 71 | hypertext system by asking, "What are other places that are | |
| 72 | contained within the same place that contains the Coliseum?" | |
| 73 | ||
| 74 | Numerous old papers on hypertext systems consider the problem of | |
| 75 | attempting to build and reason about arguments, and usually | |
| 76 | start from the | |
| 77 | \link{https://en.wikipedia.org/wiki/Toulmin_method|Toulmin model of reasoning}. | |
| 78 | Systems that include typed links could represent relationships | |
| 79 | like \em{is-a-fact-that-supports} directly as links, so a user | |
| 80 | could query the system by asking, "What are all the nodes that | |
| 81 | are supporting facts for this thesis?" | |
| 82 | ||
| 83 | \h2{Link Arity And Direction} | |
| 84 | ||
| 85 | In HTML, a link is one-way: if I include a link in document A which | |
| 86 | leads to document B, I won't necessarily have a link back. There | |
| 87 | are various ways of synthesizing backward edges: by including | |
| 88 | smarts in the browser (e.g. the 'back' button) or in particular | |
| 89 | applications (e.g. a wiki's 'what links here' feature) or by | |
| 90 | cross-application mechanisms (e.g. 'pingbacks' in WordPress or | |
| 91 | other CMS systems), but none of these are inherent in the HTML | |
| 92 | mode. | |
| 93 | ||
| 94 | Some other hypertext systems include links that are \em{inherently} | |
| 95 | two-directional. These systems build up stronger interconnectedness | |
| 96 | between nodes, because there are no "dead-end" paths: you can always | |
| 97 | at least move back the way you came, and creating a new node | |
| 98 | also creates a backwards path. In a system with typed links, this | |
| 99 | also means you can have links with swapped semantics: creating | |
| 100 | a \em{contains} link from \em{Italy} to \em{Rome} is the same | |
| 101 | operation as creating a \em{is-contained-in} link from \em{Rome} to | |
| 102 | \em{Italy}. | |
| 103 | ||
| 104 | Even more extreme, some hypertext systems include links that | |
| 105 | join together more than two nodes. This doesn't make a whole lot | |
| 106 | of sense in something like HTML, where a link doesn't necessarily | |
| 107 | connote any particular "meaning", but in a system with typed | |
| 108 | links, we can imagine a link that brings together multiple nodes | |
| 109 | with a different denotation for each: in our hypothetical | |
| 110 | geographic system, we could have a ternary link that represents | |
| 111 | \em{is directly between x and y}. | |
| 112 | ||
| 113 | In the most extreme, you could imagine a system that treats | |
| 114 | n-ary links as n-ary predicates. | |
| 115 | ||
| 116 | The aforementioned Aquanet system contained not just typed nodes but | |
| 117 | also typed n-ary links, which were there called \em{relations}. | |
| 118 | ||
| 119 | \h2{Spatial Hypertext} | |
| 120 | ||
| 121 | In HTML, pages are identified by names. Organization is largely | |
| 122 | done by creating other pages that name things together. For | |
| 123 | example, I could create a web site in which I build up index | |
| 124 | pages that describe how I structure my site. URLs originally | |
| 125 | also mapped to hierarchical folder structures, and it's common | |
| 126 | for people to treat them in a similar way today, but by no | |
| 127 | means is that obligatory on the modern web. | |
| 128 | ||
| 129 | Some historical hypertext systems took a different approach: each | |
| 130 | node was identified with a location in a spatial field, so navigating | |
| 131 | a piece of hypertext could involve not just links that 'took you' | |
| 132 | to other nodes, but also following spatial paths which connected | |
| 133 | nodes positioned on or along those paths. | |
| 134 | ||
| 135 | Different spatial hypertext systems took different approaches to | |
| 136 | this: some of them allowed the user to move nodes around, which | |
| 137 | could be useful in editing the document. Others took the conceptual | |
| 138 | relationship between nodes as expressed in the hypertext and | |
| 139 | extracted a spatial system from that, building up 'maps' to | |
| 140 | help a reader navigate an otherwise abstract structure. | |
| 141 | ||
| 142 | Some | |
| 143 | systems would even work in the opposite way: allowing the users | |
| 144 | to position nodes spatially, and then inferring information | |
| 145 | about the conceptual structure of those nodes from the common | |
| 146 | spatial patterns produced by users. This was the approach | |
| 147 | of the | |
| 148 | \link{http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.76.5062&rep=rep1&type=pdf|Viki} | |
| 149 | system. | |
| 150 | ||
| 151 | There's actually a very good example of a modern spatial hypertext | |
| 152 | editing system: \link{|Twine} | |
| 153 | ||
| 154 | \hr{} | |
| 155 | ||
| 156 | Many of the features I've described are structural, and it's pretty | |
| 157 | obvious in retrospect that HTML and Wikis impose far less structure | |
| 158 | than many other hypertext systems. In many ways, this is to their | |
| 159 | advantage: an HTML page can mean anything you want it to, and an | |
| 160 | HTML link can also be used for any purpose. | |
| 161 | ||
| 162 | On the other hand, this also makes certain operations infeasible or | |
| 163 | even nonsensical: a more structured hypertext system can perform | |
| 164 | operations by looking at the shape or structure of a collection of | |
| 165 | nodes or links, and can perform computer-aided reasoning. This is | |
| 166 | one of the reason why the Toulmin method showed up so often in | |
| 167 | past hypertext research: you were building up relationships between | |
| 168 | data in ways that you \em{and your system} could both reason about. | |
| 169 |