Re: [JSON] Classifying the use cases

Hey Richard,

thanks for this

On Mar 23, 2011, at 21:42 , Richard Cyganiak wrote:

> I moved the JSON use cases to a separate page:
> http://www.w3.org/2011/rdf-wg/wiki/TF-JSON-UC
> 
> In light of recent discussions, I thought it would be easy to classify them into a few main groups, so I had a go at it. Here are the groups:
> 
> 
> 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?

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.

(Caveat: I am not a Javascript/JSON programmer, hence these questions.)


> 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?)


> 
> 4 View arbitrary JSON as RDF
> 
>  A client wants to be able to treat any arbitrary JSON
>  as RDF, so that RDF tooling can be used. The publisher
>  of the JSON doesn't do anything and doesn't need to be
>  aware of this. (1 use case)
> 
> 
> These four categories map approximately to the four colored boxes on the User Segments page:
> http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments
> 
> The main questions that arose from the exercise for me are:
> 
> 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. 

> 
> b) For the #2 use cases, it's often not really clear whether use of a library would be acceptable. I suppose if a library is acceptable, then couldn't we just as well send Turtle over the wire? Why do client-side RDF developers prefer their RDF in raw unwieldy JSON?

Heh, I should have read this before asking the same question above:-) But I decided to keep it that way!

Ivan


> 
> c) #1 ultimately seems to be about one thing only, namely creating a migration path or gateway drug that allows existing JSON providers to get their feet wet with RDF. Is this what we want? If so, then shouldn't we talk more about how clients can benefit from those bits of magic '#' goodness that's sprinkled into JSON? The use cases don't say much about that.
> 
> Best,
> Richard


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf