Added unfinished draft of hypertext post
Getty Ritter
8 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 |