[JSON] Initial comments

Hi All,

To get some discussion going, here are my own personal views on JSON and 
RDF.

I see two distinct needs here:

One is to create a JSON serialization of RDF, capable of serializing all 
the RDF concepts (anything Turtle will be able to), an optimized machine 
to machine RDF transportation format. Most languages support JSON 
parsing now, and that parsing is very quick compared to XML and formats 
which require a custom parser (like turtle). Personally I see this as an 
easy hit, feel it would be well worth doing, and to be totally

The second need is much more complex, to create a JSON format which 
allows people to publish and work with linked/web data easily.

The distinction between the two is that the first is RDF serialized in 
JSON, the second is JSON which can be viewed as RDF when you put certain 
goggles.

I'm personally convinced that if we try to mix the two we'll be here for 
years and tbh, we'll simply fail. So, my first request would for people 
to either agree or disagree with what I've said above, put it to a vote 
and move on with doing the two distinct things.

 From here on (in this mail), I'll concentrate on the second need, a 
friendly linked data JSON format, and try not to get in to technical 
details and nits.

JSON is so popular because it's focussed on simple key/value objects, 
with limited value types, essentially a JSON object is as simple as:

   { "name": "nathan", "gender": "unknown" }

and people can work with that data by doing:

   print( obj.name );
   obj.gender = "male";

I'd place that as a constraint, that if we make it any more complicated 
than that, people simply won't use it.

 From a linked/web data angle, the most critical parts are to give 
things IRIs as identifiers, and to have a shared understanding of 
properties, perhaps better said as use IRIs to name properties.

At the bare minimum that's all we need to get by, thus I'd also place 
these constraints on what we do, that those two needs must be fulfilled.

To me, the above simply points to needing a way to specify @id's and 
some kind of data transformation map for these objects, essentially a 
simple map from property name to property URI

   "name" -> "http://xmlns.com/foaf/0.1/name"
   "gender" -> "http://xmlns.com/foaf/0.1/gender"

The next question is whether that map needs to be in with the JSON, or 
outwith it (in an external document) - again this seems like an easy 
design trade-off to make, just as with CSS for HTML an external document 
makes a lot of sense, especially when you consider the common JSON 
use-cases (like twitter api), and it also allows bootstrapping on to 
existing data sources via a Link header or suchlike.

Additionally, there is often a need to provide custom datatypes and to 
place restrictions on values for validation and the like, as with xsd 
and owl, which imho points to the need for something like JSON-Schema.

That's about it I'm afraid, something to discuss.

Best,

Nathan

Received on Thursday, 24 February 2011 03:25:53 UTC