W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

Re: [JSON] Some general serialization "things"

From: Nathan <nathan@webr3.org>
Date: Wed, 23 Mar 2011 14:52:38 +0000
Message-ID: <4D8A0936.1040105@webr3.org>
To: David Wood <david.wood@talis.com>
CC: Sandro Hawke <sandro@w3.org>, RDF WG <public-rdf-wg@w3.org>
David Wood wrote:
>> 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).

Looking at what people have going on behind the scenes (noSQL, and 
noRDF!) may have significant bearing, if the people don't have RDF 
behind the scenes, no triples, no sparql, then providing them with a 
serialization that requires having rdf/semweb behind the scenes may be a 
pointless waste of time.

Again, this is the distinction I keep trying to make, people who have 
rdf/semweb behind the scenes and want a JSON serialization (triples in 
rdf) and people who don't but want to bring the linked data value 
propositions to their data (simple objects from their k/v stores that 
you can follow your nose to w/ URI ids and w/ shared schemas between 

The SPARQL Results / Linked Data API approach appears to be a third 
case, unsure how it relates to the other two as yet.

Personally, I guess I always see SPARQL as orthogonal, it is what it is, 
and have been focussed on the other two use cases as being most 
important (since SPARQL already works and is developed and has JSON 


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC