- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Tue, 30 Apr 2013 21:36:00 -0400
- 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
CTO
Digital Bazaar, Inc.
Received on Wednesday, 1 May 2013 01:36:25 UTC