Links weren't always embedded directly inside texts.

One obvious way around the security risks inherent in allowing other people to install backtrack links (the bi- half of bidirectional links) on your website is to remove hyperlinking from the document level entirely.

HTML links are embedded directly in content. If you peek under the hood, they look like this:

If you were to copy that text, the link would come along with it.

If you've come of age post-web, chances are that the idea of the hyperlink as something that is integrated directly into a text seems natural and obvious. But as George Landow points out, it's actually a pretty big departure from the hyperlink as it was originally understood (link and emphasis added).

The user of the memex, we recall, created trails of associative links on top of already existing texts, saved those trails, and shared them with others. Different readers could create very different collections of links for the same texts. Links, in other words, exist outside the individual lexia in this kind of hypermedia.

Hypertext systems like the one Landow describes did exist, once upon a time. These consisted of a separate database—a link database or linkbase—and a server whose entire job was to store hyperlinks. The linkbase would store anchors from the source file and sets of possible destinations for those links. In this way, different people could create different destinations for the same source anchor.

Storing hyperlinks in a separate database creates all sorts of interesting opportunities. You might, for example:

It's adaptive content at the level of the hyperlink.

Perhaps more pertinent, though, is that a linkbase facilitates online research. Research is about finding the links between texts. Being able to literally document those links would be a useful first step.

Alas, the linkbase—like its even simpler cousin, the link storage service—has mostly died out, swallowed up by the ubiquitous feed.

make-public