Re: [JSON] Some general serialization "things"

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

I share Dave (and Ian's) reservation.  SPARQL is *a* way of accessing 
data.  GET IRI is another.

GET IRI?xyz is very useful.  It can be defined in terms of SPARQL, or 
not, but the app does not see SPARQL, nor does the implementation need 
to be SPARQL.  An obvious one (to me) is a KV store, key-as-subject, 
query=property+value condition, V being all properties/values with that 
subject (i.e. a small graph).

	Andy

Received on Wednesday, 23 March 2011 14:55:43 UTC