Re: [JSON] Initial comments

Agreed that there's two (somewhat) different usecases, but phrases like "if X people simply won't use it" fill me with scepticism. People are already using it, so that's clearly not true. I might buy into an opinion like "more people will use it if X", but I'd need to see real-world usecases, and examples before that would be convincing.

The idea of external mapping documents seams antithetical to the way people currently use JSON data, but maybe a real example would make it clearer.

Your examples below only encode key/value pairs and it's not obvious, to me at least, how you would extend that to graphs.

Regards,
   Steve

On 2011-02-24, at 03:24, 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.
> 
> 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
> 

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Thursday, 24 February 2011 07:22:37 UTC