W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: [JSON] Modularization and JSON-LD

From: Steve Harris <steve.harris@garlik.com>
Date: Wed, 6 Apr 2011 12:50:06 +0100
Cc: RDF Working Group <public-rdf-wg@w3.org>
Message-Id: <772A76CE-5B7A-4C52-96BC-FF0AFAEECD25@garlik.com>
To: Manu Sporny <msporny@digitalbazaar.com>
On 2011-04-06, at 01:26, Manu Sporny wrote:

> Hey folks,
> Nathan had asked this question on the telecon a few weeks ago and I
> wanted to make sure to flag it up to the group before it was lost in the
> shuffle.
> He asked whether or not JSON-LD was designed to be a kitchen-sink
> specification - that is, it seems to try to support everything - a full
> RDF serialization in/on/with JSON.
> I attempted to clarify by saying that the only reason it seems like it
> is trying to support everything is because we wanted to have a number of
> object-based solutions ready when this working group started. We thought
> that we could save some time in this WG by doing due diligence on a
> complete, object-based representation of RDF in/on/with JSON.

So, I'm still a little confused about what the use-case is for this style of RDF serialisation.

As a company that uses a lot of JSON and RDF, we ought to be square in the target audience (shouldn't we?), but I just don't see how it helps us.

The goal seems to be some kind of duality where "Javascript people" can consume it natively as JSON, and "RDF people" can consume it as triples, but I'm not clear on how either part wins over what we have now. Wouldn't it be better for everyone if the people publishing data offered Turtle as well as JSON for their results? A bit like Twitter for e.g. offers XML, RSS, and Atom as well as JSON. I'd rather see http://api.twitter.com/1/statuses/public_timeline.ttl, than http://api.twitter.com/1/statuses/public_timeline.json being bloated with a load of RDF-y annotations.

To be honest, even if there was a .ttl, we'd still get the JSON. It's more convenient for what we need - which is to process it with other data, and turn it into RDF against the schemas we use (FOAF, SOIC, DC etc.).

As far as I can tell, it's not possible to make an easy-to-consume serialisation from RDF you hold now, it has to be hand-templated in order to make it pleasant to consume in Javascript. That's the same problem as RDF/XML, and XML parsers.

Forgive the cynicism but it seems like all these proposals give you either confusing, and ugly JSON, or inconvenient, and cutdown RDF subsets. We don't have a use for either of those.

- Steve

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 Wednesday, 6 April 2011 11:50:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:58 UTC