Re: [JSON] Classifying the use cases

On 24 Mar 2011, at 08:05, Ivan Herman wrote:
>> 1 Add (some of) the benefits of RDF to existing JSON services
>> 
>> A service operator who currently runs a JSON API
>> wants to add some RDF-like features, to allow clients
>> to reap some of the benefits of RDF, without forcing
>> complete re-tooling on the client or server side.
>> (4 use cases)
>> 
>> 2 Use JSON syntax to interact with a SPARQL store (or other RDF backend)
>> 
>> We assume a client-side developer who is familiar with
>> RDF. She wants to access some sort of RDF back-end, for
>> example a SPARQL store, perhaps both for reading and for
>> writing. In certain situations, a JSON-based representation
>> of RDF graphs would be the most convenient way of
>> communicating with such an RDF back-end. (4 use cases)
> 
> Just trying to understand here. This community knows RDF and if happy to use it. Hence the question (eg, asked by Zhe): why is it important to have JSON at this point? The client is probably happy to use an RDF API in Javascript (let us say that is there) and such an API would have a 'parse' to incorporate any RDF graph from anywhere into its virtual triple store and the API would have access to that. What does JSON bring here?

I'll avoid a direct answer and just point out that a large number of SPARQL stores already are able to answer JSON results for SELECT and AKS queries, supposedly due to user demand. I take this as solid evidence that this group of developers (who know SPARQL/RDF and want to consume SPARQL results in JSON) exists.

> Trying to answer my own question, actually: maybe it is a matter of efficiency. For more complex applications the API (ie, library) approach is fine, but for simpler applications getting back the results in JSON might be more efficient because it can be parsed without additional libraries.

Another factor is simply developer convenience. Not needing to hunt down, install and learn another library or JS API is a value in itself, especially for small and quick applications.

>> 3 Publish idiomatic, developer-friendly JSON from the RDF data model
>> 
>> The publisher already has RDF (or knows how her data
>> would map to RDF). Now she wants to have an idiomatic
>> JSON API that looks familiar to developers who are not
>> familiar with RDF. Turning the JSON back into RDF is
>> not a concern. (2 use cases)
> 
> I must admit I do not see a major difference between this category and #1. If there is a format that satisfies this category, surely that format can be applied to #1, too?
> 
> (Maybe #3 allows lossy encoding of RDF. Is that the difference?)

On a technical level, the difference is that in #3, the publisher provides just JSON to its clients, and doesn't assume that there are any clients interested in getting RDF out of the JSON. So the RDF is hidden under the hood; the published API is just JSON.

In #1, I suppose the API *can* be used simply as JSON if one ignores the extra bits, but it *can* also be parsed, at least partially, as RDF.

More important however is another aspect. There is another goal in #1: It's a bit of a trojan horse. It's an easy migration path that allows publishers to sprinkle in a bit of RDF into their existing JSON APIs *if* they want. And consumers can use a bit of RDF *if* they want. And hopefully it might get more and more over time.

#3 has nothing of this; RDF is only used by the publisher, and the client is shielded from it. (The publisher may of course offer other, more traditional, ways of providing RDF to clients who want that. Content negotiation between Turtle and pure JSON, for example.)

I think this is why Manu so strongly argues for #1: It's the option with the largest potential for changing the Web -- if done right.

>> a) #4 feels clearly out of scope. Perhaps #1 and #3 as well. Or not?
> 
> I would agree with #4. It is some sort of a GRDDL-JSON stuff, and I think solving this would go way beyond what we ought to do. 
> 
> I do not see why #1/#3 would be out of the charter. 

Ok.

Best,
Richard

Received on Thursday, 24 March 2011 20:42:37 UTC