Prelude:
Dataspace 0: Those Memex Dreams Again
Dataspace 1: In Search of a Data Model
Dataspace 2: Revenge of the Data Model
Dataspace 3: It Came From The S-Expressions
Dataspace 4: The Term-inator
I want a Memex. Roughly, I want some kind of personal but shareable information desktop where I can enter very small pieces of data, cluster them into large chunks of data, and – most importantly – point to any of these small pieces of data from any of these chunks.
So… like the Web? you say. Just use the Web, it’s been here for 20 years, problem solved, right?
Yes, like the Web. But there’s a slight problem there. The Web is a distributed filesystem – dating back to at least 1969 for Unix – using DNS for the server name, then folders on the server, then finally a file on the server. This gives us a file path. HTTP augments this with an anchor (the thing after a #), which is a single named node inside an HTML file. It then augments this further with query parameters (the things after a ?), which are lists of variables and values, but which don’t relate to a file (what HTTP calls a document) at all. Query parameters are only sensible to a HTTP server. And we’d like to get away entirely from the concept of servers. We want paths that identify a piece of data in a ‘dataspace’, which might be bigger or smaller than a document.
Long story short, HTTP and URLs won’t do it. It’s okay – ish – for large, chunky bits of data (‘web documents’) but not really good enough for small pieces of data. Because the core HTTP data model is not good enough is exactly why we have so many web application server frameworks on the servers and Javascript frameworks on the client – to try to reimplement the pieces that weren’t there in the original HTTP/HTML Web vision.
We need a data model that’s coherent and built for the job of ‘pointing at small pieces of data from anywhere’. So let’s look at some of our options.