Jeni Tennison wrote:
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?
Probably, though one additional particularly relevant one is Freebase.
That has a somewhat RDF-like abstract data model but data is both
queried and returned as JSON. A query is a JSON template with nulls and
blank structures where you want details filled in (plus meta properties
for operations like sorting). Everything is identified by an "id" (a
Freebase topic path, pretty much the trailing part of a URI) and/or a
"guid". Freebase is one reason I suggested "id" as a relatively familiar
property label for identifiers.
Cheers,
Dave
[1] http://www.freebase.com/docs/data
[2] http://www.freebase.com/docs/data/first_query
