Re: [JSON] Classifying the use cases

On 23/03/11 20:55, Nathan wrote:
> 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)

Agree - and I'm not clear why it would not be a 3rd-party enhancement 
service/library, doing JSON -> Turtle.

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

#1 reads to me like getting more use of IRIs in JSON APIs/data, not a 
piece of work on a specific format, although that would address #1 if it 
were accepted by that community.

I'm not sure #3 can addressed by a single solution because the desire 
will be "developer-friendly JSON tuned to the application" i.e. 
'idiomatic' implies application or domain specific, not a single 
presentation of RDF data.  If it's not a fixed RDF->JSON mapping (lossy 
probably), the task needs proper investigation first (XG territory?).

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

Yes - thanks for the work.

	Andy

>
> Nathan
>

Received on Thursday, 24 March 2011 12:21:23 UTC