- From: Nathan <nathan@webr3.org>
- Date: Thu, 24 Feb 2011 23:21:29 +0000
- 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 UTC