Re: [JSON] Initial comments

On Thu, Feb 24, 2011 at 03:24:51AM +0000, Nathan wrote:
> 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.

+1 on the latter - JSON is indeed relatively fast to parse, but if you're encoding full RDF in JSON, you are introducing a significant overhead on top of simple JSON parsing, and you might be losing this advantage.

The format we come up with, imho, should only be seen as RDF if you put certain goggles on - GRDDL for JSON? The simplest I can think of would be an extra "uri" key, mapping a JSON object to an RDF resource with a given URI (if not set the resource will be a blank node), and a set of URI mappings for keys and values.

Cheers,
y

> 
> 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 10:56:21 UTC