Is Idiomatic JSON for RDF Desirable?
221 March 2011 by Ian Davis
The RDF Working Group seems to be making some useful progress in many areas. However, they are circling around the JSON serialisation a bit. Lee Feigenbaum asked on twitter:
#RDF WG #JSON task force — should the group focus on RDF serializations in JSON, or bridging the worlds of (normal) JSON and RDF?
Here’s what I wrote in email when David Wood asked my opinion on it a few weeks back:
I wouldn’t underestimate the trivial use case that JSON is a convenient data format for parsing and most languages have extremely fast JSON parsers. It’s certainly much simpler to parse than XML (only one character encoding). It’s also extremely compact, with a low syntax to content ratio (unlike XML again). This is the use case the Talis RDF/JSON serialisation is targetted at.
The main problem I see with the “idiomatic JSON” use case is that although it’s much more usable by the average web author, it’s always going to butt up against various mismatches in model: graphs vs trees, URIs vs shortnames, literals/languages/datatypes vs strings, repeated properties vs simple values, blank nodes, lists/collections vs arrays/dictionaries.
The blunt truth is all of those things make RDF an unfriendly model to web authors and I think it will be very hard, or impossible, to develop an idiomatic JSON serialisation that web authors will care about.
I also tend to agree with Leigh Dodds that what we really want is a standardised Javascript API for RDF.
Note: The Talis RDF/JSON serialisation can now be found at http://docs.api.talis.com/platform-api/output-types/rdf-json. Redirect should be in place soon.
The distinction for me is ‘context’. What the WG is describing as ‘normal’ JSON is JSON aimed at a specific use/context and is optimised for that. This is the difficulty with most APIs, wether on the web or not. If the designer of the API and the consumer both share the same intended use the the API works well; but fails badly if you want to do something different.
As an illustration, imagine a transport api where there is a service that will tell you when the next train is due at a particular station – that’s all good for the common case, but what if I want to build on that further…
What if I want to able to recognise the train that left Manchester for London at 6.15am this morning and find out where it stops next so that I can more reliably retrieve the laptop I left on-board? This was not a use predicted by the API author and is therefor not possible.
If we want emergent behaviour from Linked Data then we need approaches that do not exclude unpredicted uses unnecessarily. Of course, that’s a tradeoff and many people will conclude that excluding the emergent case to optimise for the obvious ones is a price worth paying.
rob
Requests to the old URL for the Talis RDF/JSON specification redirect to the new location.
curl -I http://n2.talis.com/wiki/RDF_JSON_Specification
HTTP/1.1 301 Moved Permanently
Location: http://docs.api.talis.com/platform-api/output-types/rdf-json