Thoughts on serialization (AD3, JSON-LD, JSON-AD)

[joepio]

The AtomicData Triples (AD3) format (described here) is inspired by hextuples - which is designed to be more performant than other existing RDF serialization formats. But I'm not entirely sold on the idea of having that as the standard way to serialize Atomic Data:

• It's hard to read
• It has a lot of duplication (subjects appear more than once), because it does not allow for nesting
• NDJSON is unconventional
• It cannot be navigated using thing.property.otherproperty[5] syntax (i.e. it's not json)

Atomic Data, however, is bit different from RDF. For one, Subject-property uniqueness means that we can use key-value stores and plain JSON objects without having key collisions. However, like RDF, Atomic Data uses URLs for keys (Properties / Predicates). Because these URLs are prone to typos and take too long to type, Atomic Data introduces the Shortname property, which means that these shortnames could be used as keys in serialization formats. This is what I've used in Atomic-Server for JSON-LD serialization - the keys are nice and short, while the long URLs are available in the @context object. This gives regular JSON users a familiar ORM-style syntax, whilst retaining a way to find out more about the properties.

But... Parsing JSON-LD is slow, if you want to actually use the linked data URLs and parse it as RDF. Using it as JSON with some embedded documentation is just fine, though.

So let's explore some serialization ideas. I think taking JSON as a strating point makes a ton of sense. It has awesome support, it has highly performant optimized parsers, and developers are familiar with it.

URLs as keys, first key as Subject URL

{
  "https://example.com/someResource": {
    "https://example.com/somePropString": "someval",
    "https://example.com/somePropBool": true,
    "https://example.com/somePropThatLinksToANestedResource": {
      "https://example.com/somePropString": "some nested value",
    }
  }
}

• Allows for multiple resources in a single object - both anonymous nested resources, as included resources with @id
• Intuitive, maps well to data model of Atomic Data
• Not great to use as plain json - keys are long, easy to mess up, hard to autocomplete.
• Might feel redundant when fetching single resources, where the fetched URL equals the first key in the JSON object.
• It seems like it can almost be parsed as JSON-LD, but it still misses some things. All URLs should be denoted in nested @id objects, all lists need @list objects... Can't say I like that. The alternative, adding an @context object, also seems like a suboptimal way of doing things.

[joepio]

I've opted for the JSON-AD approach, and built a first front-end / browser app in typescript. Choosing JSON-AD made parsing trivial, and keeps performance as high as possible. I've updated all the docs. Closing for now.