- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Mon, 14 Dec 2009 11:17:40 +0000
- To: Richard Light <richard@light.demon.co.uk>
- Cc: Dan Brickley <danbri@danbri.org>, "Hammond, Tony" <t.hammond@nature.com>, Jeni Tennison <jeni@jenitennison.com>, public-lod@w3.org, John Sheridan <John.Sheridan@nationalarchives.gsi.gov.uk>
Hi Richard, > Despite the "Bah, Humbug!" tone of my previous mail, I am actually in favour > too. I just want to tease out the extent to which we would be giving > developers what they say they want, rather than what they could actually > use. > > The value of JSON is surely that JSON support is widespread across a wide > range of programming environments[1], rather than that JSON is a "simple" > format. Would the alternative formats being discussed offer as much, in > terms of their practical implementation for a wide range of languages? I'm speaking for myself here, but going on her first email, I'm pretty sure that Jeni is taking the same approach. The goal is to make it easy for web programmers to get RDF data directly into their applications. So although it's true that JSON is a general-purpose format, our interest here is more specific, in that it easy to get JSON data directly into web applications. For those who don't do a lot of JavaScript programming, I should point out a subtlety here that might be being missed; although modern web apps make extensive use of XMLHttpRequest objects to retrieve data, in ordinary circumstances it is not possible to use XHR to get data from a different domain to the one hosting HTML document. However, HTML /does/ allow the <script> element to pull scripts from any location, in just the same way that it is possible to pull images in from any location. This is how things like Google Maps work, for example. This means that if we want to achieve a model where a web app pulls in RDF from many different places, that data will almost certainly need to be brought in via the <script> tag. This in turn will require that the data being imported is JSON (or more precisely, JSONP). As you can see then, the goal is to give JavaScript programmers RDF data, rather than to come up with another serialisation of RDF just for the sake of it. (Just in passing, I should say that on most browsers, <iframe>s suffer the same problem. Before I devised RDFj, I was importing HTML+RDFa by using a hidden <iframe> and then running the RDFa parser on it, but the problem remains that although it works for same-domain data, it doesn't work across domains.) Here's a very simple example of the kinds of things that can be done when you combine RDFj and RDFa: <http://backplanejs.appspot.com/samples/rdfa/blog-twitter.html> (It's using named graphs to query the Twitter API, based on data provided by RDFa.) Regards, Mark -- Mark Birbeck, webBackplane mark.birbeck@webBackplane.com http://webBackplane.com/mark-birbeck webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR)
Received on Monday, 14 December 2009 11:18:24 UTC