- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Sun, 13 Dec 2009 13:59:39 +0000
- To: public-lod@w3.org
- Cc: Mark Birbeck <mark.birbeck@webbackplane.com>, John Sheridan <John.Sheridan@nationalarchives.gsi.gov.uk>, Danny Ayers <danny.ayers@gmail.com>
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- site. Cheers, Jeni [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 http://www.jenitennison.com
Received on Sunday, 13 December 2009 14:00:07 UTC