Re: [JSON] Some general serialization "things"

On Mar 23, 2011, at 10:14, Sandro Hawke wrote:

> On Wed, 2011-03-23 at 13:44 +0000, Nathan wrote
>> Just a note to say that there are many weird and wonderful options...
> 
> Indeed, and it reminded be of the big divide between Group C (who uses
> libraries) and Groups A and B (who do not).   
> 
> Group C doesn't care as much about what the json looks like as Groups A
> and B, but I'm sure they do care.  They want it to be (1) small, (2)
> fast, and (3) easy to read by humans, for those rare times when they
> need to think about what it actually looks like, eg in debugging [which
> is rare, of course :-) ].    Your examples seem to suggest we can find
> nice ways to optimize among these trade-offs.
> 
> In contrast, while Groups A and B do care about the above, they care
> much more about how easy it is to write code to deal with this data.
> 
> Of course, you know this, Nathan -- you once went through and wrote
> javascript snippets of how to do things with RDF in various styles,
> which alas I can't find -- but I did want to point it out for the group.
> 
> In looking for that post of yours, I came across Jeni's great post [1]
> where she quotes you as saying:
> 
>        You can’t shoe horn RDF in to JSON, no matter how hard you try -
>        well, you can, but you loose all the benefits of JSON in the
>        first place, because the data is RDF, triples and not objects,
>        rdf nodes and not simple values


Leigh Dodds made similar points at:
  http://www.ldodds.com/blog/2010/12/rdf-and-json-a-clash-of-model-and-syntax/

Specifically, "JSON is a tree; so we have the same variety of potential options for serializing any given graph. The data types are also still different: key-value pairs, hashes, lists, strings, dates (of a form!), etc. versus resource, properties, literals, etc. While there is potential to use more native datatypes, the practical issues of repeatable properties, blank nodes, etc mean that a 1:1 mapping isn’t feasible."

I wonder whether we would be having this discussion if libraries for all common languages provided fast and efficient Turtle parsing and access.


> 
> and then paraphrases it herself, as:
> 
>        In other words, using JSON as the basis for an RDF syntax
>        doesn’t actually win you anything in terms of the ease of
>        processing of that RDF. In fact, I’ll go further and say it has
>        exactly the same bad qualities as RDF/XML.
> 
> ... which several people in this WG have pointed out.  I wonder if we as
> a group have consensus on this view, or there are other angles.
> 
> I think Manu disagrees, focusing on the greenbox and the trick of using
> external mapping information.  The job of the shoehorn is much easier
> when there are extra secret storage compartments.   (or maybe: stretchy
> shoes.)
> 
> My vague sense is that we'll get the most benefit focusing on giving
> json folks SPARQL results instead of RDF per se.  I think that addresses
> most of the use cases more simply.   (And that may be out of scope for
> this WG, but let's come back to that after we've figured what technology
> standards would actually really help folks here.)


Ian Davis has questioned why the "semweb community is so keen on a join based approach to query the web of data even as facebook and google abandon it" (in personal email).  Specifically, he was referring to the noSQL movement growing out of the sharding practices of the dominant Web companies as they attempted to scale.  Follow-your-nose architecture is the obvious rejoinder because it is a parallel approach to SPARQL for reaching SemWeb data.

So, it might be helpful to provide SPARQL query results to Web authors, but I'm not sure it would be helpful to force them into a SPARQL-only route to using SemWeb data (not that you necessarily suggested that).

Regards,
Dave



> 
>     -- Sandro
> 
> [1] http://www.jenitennison.com/blog/node/149
> 
>

Received on Wednesday, 23 March 2011 14:37:50 UTC