Re: Creating JSON from RDF

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

Received on Monday, 14 December 2009 15:46:19 UTC