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

Re: [JSON] Initial comments

From: Nathan <nathan@webr3.org>
Date: Thu, 24 Feb 2011 23:21:29 +0000
Message-ID: <4D66E7F9.3070702@webr3.org>
To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
CC: Thomas Steiner <tomac@google.com>, RDF WG <public-rdf-wg@w3.org>
Pierre-Antoine Champin wrote:
> My guess is that the human-oriented JSON syntax should aim at making it 
> easy to produce.
> 
> To make RDF easy to consume, we don't need syntaxes (we already have a 
> dead-simple syntax: N-Triples), what we need is APIs.

That could be where there is a difference in opinions, many would like 
developers to be able to consume and work with data without an API (as 
simple key/value objects) whilst still providing a set of goggles 
through which they can view that data as RDF (and then work with it 
through an API). Others I have spoken to would like to see RDF in JSON 
that is easy to work with without an API, and yet others would like to 
see a machine optimized RDF in JSON which they can work with via an API.

Does anybody actually want to write RDF, by hand, in JSON? Up till now 
I'd always seen JSON as something produced by machines (by some data 
providing process, or by JSON.stringify'ing some object structure) and 
something which people just JSON.parse'd back in to an object structure 
to work with that data as simple object/array structure; where the most 
important aspect for all was always simplicity of the data structure.

Working up the levels, the distinction I'm seeing here is that the 
current RDF publishing culture is to take data from an RDBMS or from 
Class instances, map that to RDF, and then publish/expose the RDF (this 
would require RDF in JSON) whereas most uses of JSON in the wild is 
about taking the data from a row in an RDBMS or a Class instance and 
simply dumping that existing structure out in JSON and 
publishing/exposing that, to tie in with this way of working would 
require providing a way to view that data as RDF, rather than publishing 
that data as RDF.

So, do we focus on giving people a way to view simple objects as RDF, or 
focus on trying to get them to forget simple objects and work with RDF 
via APIs, or try and provide RDF in such a way that you don't always 
need APIs and can work with it as if it's objects?

My general contention is that only the first two of those options will 
lead to any measurable success / adoption, and I'm reading that you're 
suggesting the third option (?)

Best,

Nathan
Received on Thursday, 24 February 2011 23:22:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:38 GMT