W3C home > Mailing lists > Public > public-lod@w3.org > December 2009

Re: Creating JSON from RDF

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Mon, 14 Dec 2009 11:17:40 +0000
Message-ID: <640dd5060912140317s111134b5q43d16de833723519@mail.gmail.com>
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

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:


(It's using named graphs to query the Twitter API, based on data
provided by RDFa.)



Mark Birbeck, webBackplane



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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:46 UTC