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