Re: [JSON] A starting point...

On 07/04/11 03:00, Manu Sporny wrote:
> On 04/06/2011 03:14 PM, Andy Seaborne wrote:
>> I don't quite understand how this list of questions arises as being the
>> key questions, or maybe just I don't know which user segments we are
>> addressing.
>>
>> If it's 3/4/5+C, that segment assumes a library, and we have two forms
>> of that: a one step specific-parser to produce a JS structure that the
>> app can use, or a full-blown library where access is always via a
>> library call. Either way the format on-the-wire isn't directly visible
>> to the application.
>
> We are interested in that segment,

"we" being?

> but we are attempting to reach a
> broader audience. That is - we can do almost anything with a library so
> the on-the-wire format doesn't matter.

But it does need defining.

> I'm trying to draw us toward the use cases where the on-the-wire format
> does matter - for people that just have JSON.parse(). If we can cover
> those people, we automatically cover 3/4/5+C... thus we reach a broader
> audience with the proposal.
>
>> Which is this addressing?  On-the-wire or JS structure?  I'd answer the
>> questions differently for these 2 cases.
>
> If I understand your question correctly, I believe its the "on-the-wire"
> format. Something a regular JSON developer can run JSON.parse() on and
> get a JavaScript object that they can work with without needing any
> fancy RDF/JSON libraries.
>
> -- manu
>

OK - this is "JSON as RDF" - annotate the JSON to make it interpretable 
as RDF for those that want to.  The annotations can be ignored to leave 
"standard" JSON.

"JSON as RDF" assumes there will be uptake (a plausible belief, but a 
belief) and is speculative.

Targeting the no-library-at-all case does not automatically come up with 
a good solution for the library case.

It's not good for the RDF publisher - for example, the annotations are 
designed for the typical data but an RDF publishing system has a graph, 
no other information, and wants the export RDF in JSON.  Where does the 
@context/@vocab come from?  It's not going to look like if it's 
synthetically generated, and so it will not meet the expectations of the 
group a consumers.

Just don't call "JSON as RDF" "application/rdf+json" because it's not. 
Why it's not in the RDF web application WG is another question - won't 
the get the right people involved? And align it to the RDF API?

If there is sufficient interest in an JSON serialization of RDF then 
maybe we split the TF into two - "JSON as RDF" and "RDF in JSON".  "RDF 
in JSON" targets 3/4/5/..C, maybe 6B but that depends on the priorities 
of the green solution.  A starting point can be whatever is most 
commonly used and deployed currently.  We can get information on that 
from Misha's survey or a step after that,

This is more cautious - there are RDF systems using JSON serializations 
so we have experiences to draw on.  Downside is that there is a conflict 
of TC time.  I'm note sure it actually splits WG resources - for myself, 
I will review any "JSON as RDF" work with great interest but I haven't 
got much to contribute to its creation.

I hope the outcome of the F2F will be a decision on what is the target 
and who is interested.  Jumping to a starting point is jumping that 
decision.

 Andy

Received on Thursday, 7 April 2011 12:16:54 UTC