W3C home > Mailing lists > Public > public-lod@w3.org > December 2009

Re: Creating JSON from RDF

From: Jeni Tennison <jeni@jenitennison.com>
Date: Sun, 13 Dec 2009 13:59:39 +0000
Cc: Mark Birbeck <mark.birbeck@webbackplane.com>, John Sheridan <John.Sheridan@nationalarchives.gsi.gov.uk>, Danny Ayers <danny.ayers@gmail.com>
Message-Id: <84B15C2E-9DAF-451D-A89E-E2680C4F72CE@jenitennison.com>
To: public-lod@w3.org
On 12 Dec 2009, at 22:27, Danny Ayers wrote:
> I can't offer any real practical suggestions right away (a lot to
> digest here!) but one question I think right away may some
> significance: you want this to be friendly to normal developers - what
> kind of things are they actually used to? Do you have any examples of
> existing JSON serializations of relatively complex data structures -
> something to give an idea of the target.
> While it's a bit apples and oranges, there presumably are plenty of
> systems now pushing out JSON rather than the XML they would a few
> years ago - is there anything to be learnt from that scenario that can
> be exploited for RDF?

Great idea to look at what currently exists. Let's see.

The flickr API [1] is notable in that the JSON is a direct mapping  
from the XML API. From what I can tell they don't even try to use  
values that are anything other than strings, and they have a  
moderately ugly "_content" property for when elements in the XML API  
have content (though it mostly uses attributes, from what I can tell).

The Twitter API [2] provides JSON and XML (Atom) formats. There are a  
whole bunch of different queries you can do, most of which contain  
nested objects etc. Interestingly, the JSON that you get back from a  
search does contain metadata about the search and a 'results' property  
that holds an array of the results. So that could be a relevant model  
for SPARQL results formats.

CouchDB [3] is a purely JSON API which has to be very generic (since  
CouchDB can be used to contain anything). It uses reserved property  
names like "_id" (this and "_content" in the flickr API make me think  
that a leading underscore is the expected way to create reserved  
property names).

Yahoo! [4] have a JSON API that is again based on an XML API with a  
straight-forward mapping from the XML to the JSON.

The Google Data Protocol [5] uses JSON that is generated from the  
equivalent Atom feed. Interestingly, they provide support for  
namespaces by having "xmlns" properties (with "$" used instead of ":"  
in any qualified names). Unlike the other APIs, they do use  
namespaces, but only a handful. I strongly doubt that any developer  
using it would actually resolve "openSearch$startIndex" by looking at  
the "xmlns$openSearch" property.

Is that enough of an idea to be getting on with?

It's worth noting that most of these APIs support a callback=  
parameter that makes the API return Javascript containing a function  
call rather than simply the JSON itself. I regard this as an  
unquestionably essential part of a JSON API, whether it uses RDF/JSON  
or RDFj or irJSON or whatever, in order to make the JSON usable cross- 



[1]: http://www.flickr.com/services/api/response.json.html
[2]: http://apiwiki.twitter.com/Twitter-API-Documentation
[3]: http://wiki.apache.org/couchdb/HTTP_Document_API
[4]: http://developer.yahoo.com/common/json.html
[5]: http://code.google.com/apis/gdata/docs/json.html
Jeni Tennison
Received on Sunday, 13 December 2009 14:00:07 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:46 UTC