Notes
2025/11/16
When we think of hypertext, we usually think of the “jump links” of the web. These act like bridges, connecting two separate documents through an explicitly constructed link that then jumps to the other document. The two documents being linked might not share any content, it is only the link that forms an explicit connection.
Another way to build hypertext is through transclusion: A part or all of a document is included in a different document, which implicitly links the two documents together by sharing the same partial content. Transcluded content is like a hub in a subway network: Multiple lines include the same stop as part of their linear route, with hubs acting as the points that allow you to navigate from line to line (document to document).
Building hypertext through hubs in the form of shared content can often lead to a more fine-grained notion of hypertext: It is easy to just reuse snippets (such as paragraphs of text) in another document and have the documents be implicitly linked at exactly that point, whereas a bridge in the form of a jump link usually points to an entire document, either by using an explicit URI or the title of the page. Linking to a part within a document is much more cumbersome because it either requires a sub-document-level identifier (such as an explicit element id) or basically boils down to specifying the entire chunk of content (which is then practically transclusion).
Another disadvantage of bridges compared to hubs is that explicit jump links are assumed to have a single target, which means that the target of a link needs to be uniquely addressed. This either requires a unique resource identifier or full control over the entire system (so that documents can be unambiguously referred to by their title).
While a bridge always connects exactly two documents, a hub can be included in more than two documents, since blocks of content can be naturally transcluded in as many documents as necessary. The actual links (as in UI elements that take you to another document) aren't explicitly constructed, they are implicitly shown as part of the hypertext system.
Sometimes it's nice to have bridge-like behavior in a hypertext system that is built around hubs. Hubs easily support that, by treating unambiguous references to entire documents like jump links.
For example, a syntax such as [[Ludwig Wittgenstein]] can be understood as the transclusion of the 1-paragraph text snippet Ludwig Wittgenstein, which can be displayed as a good old jump link if there is exactly one document in the system that is titled Ludwig Wittgenstein (in other words, a document containing the snippet Ludwig Wittgenstein as its first paragraph).
As soon as another document with Ludwig Wittgenstein as the title / first paragraph is added to the system, the [[Ludwig Wittgenstein]] link would gracefully transition to being displayed as links to several different documents (for example, by displaying previews of these documents under the paragraph containing the link).
Hubs can deal better than bridges with hypertext structures that lack unambiguous references, which can make hubs a better choice for hypertext systems that are not controlled or managed by a single author or entity.
Lastly, viewing hypertext through the lens of shared hubs can also be extended to cover fuzzy relationships that go beyond exact transclusion. For example, a textual similarity search (either using purely syntactic word-based overlap or using a more semantic model based on LLMs) could establish implicit links between blocks of content that are not exactly the same but somewhat similar.
This could arguably be done even in a bridge-like system using jump links (and the usual caveats of drowning in a sea of unimportant associations applies in both cases), but hubs make it less awkward:
The bridge model assumes a world of stable, centrally-managed content with unambiguous identifiers. Hubs offer a different foundation: They embrace ambiguity rather than fighting it, they scale naturally from precise references to fuzzy associations, and they allow connections to emerge organically from shared content rather than requiring explicit maintenance. If we want hypertext systems that can grow and evolve without constant curation, we should be building hubs, not bridges.