[JSON] Classifying the use cases

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?

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?

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

Received on Wednesday, 23 March 2011 20:42:45 UTC