Re: [JSON] Classifying the use cases

Thanks Richard, that's my action done :D

comments in-line:

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

Agree #4 is potentially out of scope (unless by some miracle we define 
some external mapping jiggery-pokery)

#1 & #3 appear to me like they could be addressed by a single solution.

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

Faster to parse using heavily optimized c parsers provided with runtimes 
is a big win

> 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.

Yes :) one thing with 2 sides, we get more triples and can do more data 
meshing, they get their feet wet in a pleasant simple way with barely 
any cost.

Good write up, thanks.

Nathan

Received on Wednesday, 23 March 2011 20:56:01 UTC