- 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