Unwalled.Garden

Status: DRAFT. Part of the upcoming Beaker Browser 0.9 release.

Why not RDF?

Schemas should be human-readable, easy to build with, and unambiguous.

Our solution is to use a standard type field which is a URL. We use a URL because:

  1. It’s an unambiguous global namespace, and
  2. Developers can easily find the documentation.

Here’s an example Unwalled.Garden object:

{
  "type": "unwalled.garden/comment",
  "topic": "dat://unwalled.garden",
  "body": "Why didn't you use RDF!?",
  "createdAt": "2018-12-07T04:15:44.722Z"
}

We dislike RDF because of its complexity. Its data model is unusual: a triples-based graph with URLs as the attribute names.

Consider the following example JSON-LD schema:

{
  "@context": {
    "web": "dat://websites.com/manifest#",
    "social": "dat://social.com/"
  },
  "web:title": "Paul Frazee",
  "web:description": "Beaker guy",
  "social:follows": [
    "dat://alice.com",
    "dat://bob.com"
  ]
}

That object is a shorthand for this:

{
  "dat://websites.com/manifest#title": "Paul Frazee",
  "dat://websites.com/manifest#description": "Beaker guy",
  "dat://social.com/follows": ["dat://alice.com", "dat://bob.com"]
}

Both forms are difficult to read and author:

paul['web:title'] = 'Paul Frazee'
// or
paul['dat://websites.com/manifest#title'] = 'Paul Frazee'

Programmers have to work with schemas! They should be simple and friendly to use. If we think in terms of records instead of graphs, we end up with objects that are much nicer to use.

{
  "type": "websites.com/manifest",
  "title": "Paul Frazee",
  "description": "Beaker guy"
}

Which makes our code much cleaner:

paul.title = 'Paul Frazee'
paul.description = 'Beaker guy'

If schemas must be combined, only then might we use URL keys (see How to extend the schemas):

{
  "type": "websites.com/manifest",
  "title": "Paul Frazee",
  "description": "Beaker guy",
  "ext": {
    "social.com/follows": {
      "urls": ["dat://alice.com", "dat://bob.com"]
    }
  }
}

The Unwalled.Garden philosophy about RDF is YAGNI (You Ain’t Gonna Need It). We see RDF’s complexity as a turn-off to developers and something we should try to avoid if we can.