Re: [JSON] Survey for design requirements

On 07/03/11 04:45, Manu Sporny wrote:
> On 03/06/2011 04:05 PM, Richard Cyganiak wrote:
>> I'm sorry if I missed anything, I didn't follow [JSON] too closely,
>> but has there been any discussion/writeup on use cases for
>> RDF-in-JSON?
>
> I took a quick first-hack at it here:
>
> http://www.w3.org/2011/rdf-wg/wiki/TF-JSON#RDF_in_JSON_Use_Cases
>
> Anyone that is interested should feel free to add their use cases to the
> use cases section of the wiki linked to above.

-- Use cases:

I've added a more specialized version of the REST one - using the SPARQL 
HTTP Protocol.


--- Requirements:

=== The serialization SHOULD provide an API

Should this be reworded as
"The serialization SHOULD assume working with a JavaScript RDF API"
as the text implies everything is via an API at least via .parse().

How is this different from human-friendly vs machine-friendly?  If the 
format is never seen by people (you debug by looking at TCP packets? :) 
because it's via an API why is human-friendly so important (you might 
argue teaching).


----

I've added some requirements as well: feel free to reword or merge into 
others as they are trying to extract what we're really about here:

== The design target is small snippets of RDF Data

This is to try to make it clear whether the design is focused around 
large-scale processing.  "small" might be less that 1 million triples, 
not 10.

== Design target: graphs or resources

A human friendly JSON format can be designed more towards graphs 
(multiple subjects) or more targeted on just describing one resource 
(subject). This is not to exclude one possibility over the other - this 
is to decide the focus.

Related to "disjoint/unconnected graphs", I think, but I'm not sure. I 
didn't know if that was about multiple graphs or multiple components of 
a graph.

 Andy

Received on Monday, 7 March 2011 09:34:56 UTC