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

Re: Can JSON-LD cater for Talis' RDF/JSON design goals?

From: Thomas Steiner <tomac@google.com>
Date: Fri, 26 Aug 2011 11:32:14 +0200
Message-ID: <CALgRrLknyX8AJCUJaXEaO9No9aPY-=NjWWPthyNi+JcwaD+w5w@mail.gmail.com>
To: Ian Davis <ian.davis@talis.com>
Cc: RDF WG <public-rdf-wg@w3.org>
Hi Ian, all,

> 1. Serializes entire RDF model
One can clearly see that.

> 2. Regular, predictable structure, one way to write any given graph
Yepp.

> 3. No parsing beyond eval of JSON (i.e. no client dependencies)
JSON.parse and you're done, just as with all JSON.

> 4. Usable without a client library, i.e. just an addressable data
> structure that lets you quickly answer "what is the label of thing
> with URI x"
Well, you always have to check for the type of the object, and if it's
literal, then use the value. Plus you have to check before if the
required value array of the object is exactly one element long. Note,
I'm _not_ at all saying that it's necessarily easier with JSON-LD,
just pointing out the necessary steps. JSON-LD allows for simple
defaults (e.g., no required object value array), but complexer object
structures can occur at any time, so the data always needs to be
interpreted with care... JSON people are used to that.

> People familiar with RDF/JSON will spot some similarities. The chief
> differences are the subjects being values of a @subject key rather
> than being keys into another object. That makes it a lot harder to
> find the foaf:name of a given subject without using a parser for this
> format. But that aside, this looks like it almost satisfies all my
> design goals, with 4 being partially satisfied.
I fully agree with your conclusion. From a JSON point of view, some of
your @literal-s without neither of @language or @datatype could be
simplified to just the literal value as the object value. In JSON, you
would simply nest the whole object structure rather than referencing
to different nodes, but of course this is a result from the
RDF-to-JSON nature of your example. In practice, hopefully, the issue
of @subject values rather than direct subject keys does not occur too
often, but I might be overly simplifying here.

> This gives me hope that there could be a way forward to produce only a
> single JSON spec.
I think this is the most important part of your email :-) Me too, I
strongly believe in the fact that both needs (RDF geek's, Web
developer's) can be addressed by one spec.

Best,
Tom

-- 
Thomas Steiner, Research Scientist, Google Inc.
http://blog.tomayac.com, http://twitter.com/tomayac
Received on Friday, 26 August 2011 09:33:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:44 GMT