fsteeg.com | notes | tags

∞ /notes/one-issue-with-json-ld-that-seems-not-so-pragmatic | 2014-01-28 | programming web

One issue with JSON-LD that seems not so pragmatic

Cross-posted to: https://fsteeg.wordpress.com/2014/01/28/one-issue-with-json-ld-that-seems-not-so-pragmatic/

I originally posted this to my tumblr a few days ago, but decided the format fits better here. For context:

I really like JSON-LD. We've built a linked data API serving JSON-LD at hbz over the last year, and we're really happy with it. For us, it's an awesome bridge from our RDF data to a useful representation on the web. The spirit of JSON-LD really seems all about useful tools that get the job done. And who wouldn't like that? But there's one thing that really seems wrong to me. First, here's some JSON-LD at its best:

http://api.lobid.org/item?id=BT000000079%3AGA+644&format=full

Why at its best? Because it's simply JSON. Just some data, perfectly accessible under some keys. Now check out this:

http://api.lobid.org/organisation?id=DE-605&format=full

What's this? Just some data, perfectly accessible under some keys? Not quite. We have an array under the `@graph` key. In that, we have objects, each with an `@id` key, and some data. Now naturally, we're accessing these objects using their ID when we make use of the data. It's their identifier, after all. To me, the obvious way to do that in JSON would be to have an `@graph` object, with the IDs as keys:

"@graph": {
  "location": {...},
  "address": {...}
}

Instead of:

"@graph": [{
  "@id": "location", ...
},{
  "@id": "address", ...
}]

Because with the latter, if I want one of the objects, I have to filter the objects array and select the one I need by its `@id` value. I just want the `location` object from the graph, but instead of `get("location")` I have to inspect every object.

A similar thing, though probably not as straightforward as the `@id` usage: languages. If I have some label in multiple languages, I naturally will be accessing them by language ('give me the english label'), so why not have:

prefLabel: {
 "de": "Land",
 "en": "Federal State"
}

Instead of:

prefLabel: [{
  @language: "de",
  @value: "Land"
},{
  @language: "en",
  @value: "Federal State"
}]

I'm sure there are reasons for doing it this way, and I didn't dig deeper into the spec, the implementation, etc. Also, of course this has a lot to do with how our original RDF data is modelled. Anyway, I've just been thinking this every time that I've been working with our JSON-LD, mostly when writing code to access these values in the ways I described. I've also bounced these thoughts off some colleagues and didn't hear that I was crazy. So I thought why not share it. Of course, if there's some obvious way to get our JSON-LD into that form within the existing spec I'd love to hear about that.

And I did, which is great:

Fabian Steeg | license: CC BY 4.0 | me on: Orcid, GitHub, GitLab, LinkedIn, Stack Overflow, Wikipedia & Wikidata