W3C home > Mailing lists > Public > public-rdf-comments@w3.org > May 2013


From: Dave Longley <dlongley@digitalbazaar.com>
Date: Tue, 30 Apr 2013 21:36:00 -0400
Message-ID: <51807180.50500@digitalbazaar.com>
To: Martin Nally <martin.nally@gmail.com>
CC: Manu Sporny <msporny@digitalbazaar.com>, public-rdf-comments@w3.org
On 04/30/2013 07:12 PM, Martin Nally wrote:
> For RDF-aware people, JSON-LD is also annoying - it is much more 
> difficult to parse than simple RDF/JSON. If every programming language 
> had a JSON-LD library that had no bugs, loaded in zero time, took zero 
> space and had an API everyone loved, this might not be an issue, but 
> those things are not true.

That sounds like any unreasonable list of requirements for any technology.

Also, keep in mind that parsing RDF/JSON is not as simple as 
JSON.parse(). That doesn't necessarily yield valid RDF/JSON, for 
instance: JSON.parse({"i": {"am": "invalid RDF/JSON"}}). You'll need 
some validation code somewhere. Does every programming language have an 
RDF/JSON validation library that has no bugs, loads in zero time, takes 
zero space, and has an API that everyone loves? Did you check Sartre? :)

Instead, maybe all you need is a decent RDF/JSON validation library for 
every programming language that your system is using or intends to 
(reasonably) interoperate with. Even that might not be necessary, if you 
have clients that only transmit data and deal with HTTP response status 
codes. Of course, if you were in this position, then you could use any 
serialization format that met these same requirements. The only question 
is what you get for free and what you don't (and how important those 
things are) -- and that may just be determined by how you decide to 
model your data.

Since this is your system, you can also decide what restrictions you 
want to place on the data. For instance, if you did use JSON-LD, maybe 
you'd only accept flattened form. Then you could use a validator for 
that instead of RDF/JSON. Any data you exported would still be fully 
interoperable with anyone who could accept JSON-LD. You'd have the same 
restrictions your system has right now with RDF/JSON -- in that that's 
the only thing you can accept (JSON formatted in a specific way). You 
could also model your data using JSON-LD's @index feature or create 
simple subject maps for your data when it's received, if that's 
something you want.

Anyway, my point is that some of what you said came across as a bit 
hyperbolic; I don't think using JSON-LD instead of RDF/JSON is actually 
as annoying as you make it out to be. From my perspective it seems more 
like this sort of feeling: "Bummer, I wanted the data keyed by subject. 
Now I'll have to write a function or use a common-place tool or a 
feature of JSON-LD to do that for me."

I've had that same thought and have had to do it in practice. It wasn't 
that bad. Plus, when I wanted to, I got to use all of the JSON-LD 
features that make programming against generic in-memory objects *far* 
more natural, like using dot-notation, short keys, and arrays instead of 
bracket-syntax, IRIs, and linked lists.

Dave Longley
Digital Bazaar, Inc.
Received on Wednesday, 1 May 2013 01:36:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:33 UTC