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


Reply via email to