Dataspace – Page 3

Dataspace 4: The Term-inator

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.

Before we can build such a system, we have to settle on a data model. The logic programming language Prolog gives us a potentially useful universal data model – term structure – but we don’t get the most out of it unless we express it in Lisp-style S-expressions, which reveal hidden semantics that even the formal logic and logic programming communities didn’t catch up with until 1989. But S-expressions also introduce ambiguity that wasn’t there in the original Prolog term structure.

There is a very simple way forward from here, and it’s one that I haven’t seen described before. I think it has potential as a fundamental data semantics for building very large or very small distributed systems.

Continue reading “Dataspace 4: The Term-inator”

Dataspace 3: It Came from the S-Expressions

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

The Prolog data model – based on logical terms , which are very similar to SQL relations, but can be nested and computed like functions – looks useful, but still has a few rough edges because it was built in 1972 and hasn’t changed much since.

For one thing, a Prolog term looks like a C function call

funny(cats)

but that syntax is rather irregular. Can we come up with a simpler syntax, that gives us more options for how we organise data?

Yes. Yes we can. But there’s a price to pay.

Continue reading “Dataspace 3: It Came from the S-Expressions”

Dataspace 2: Revenge of the Data Model

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

But to even begin we need a data model that allows us to point at small pieces of data. This turns out, surprisingly, to be harder than it looks. The data models in common use that we’ve looked at and rejected so far are:

Filesystems (as in Unix or the Web – the end-point components are too big)
Object-oriented programming (objects are fragmented, ill-defined and too complex)
Dictionaries (promising, but don’t let us have multiple values per key)
Relational databases (our data is not structured in fixed-length tuples)
Graphs made of triples (they’re neither homoiconic nor recursively structured)

So are we out of options? Not quite. There’s one weird old trick we haven’t looked at. #6 may surprise you.

Continue reading “Dataspace 2: Revenge of the Data Model”

Dataspace 1: In Search of a Data Model

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

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.

Continue reading “Dataspace 1: In Search of a Data Model”

Dataspace 0: Those Memex Dreams Again

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

Computing in the Internet age has a number of inspiring visions: legendary systems, some of which got built, some of which remained hypothetical, “dream machines”. Among them are: Vannevar Bush’s Memex (1945). Ted Nelsen’s Xanadu (1960). J R Licklider’s Intergalactic Computer Network (1963). Douglas Engelbart’s NLS (1968) and Alan Kay’s Dynabook (also 1968). William Gibson’s Cyberspace (1982).

These visions serve to anchor our ideas about what’s possible and how we might achieve it.

This is not one of those.

It is, however, a very rough sketch of an idea about what a future computing system might look like. I don’t know how to get from here to there, or even if ‘there’ is entirely satisfactory. But I feel that a ‘there’ roughly in this vicinity is somewhere we should be heading towards.

Let’s start with what the ‘here’ is that is less satisfactory.

Continue reading “Dataspace 0: Those Memex Dreams Again”