Re: Fwd: RDF/JSON

On 04/30/2013 10:37 PM, Peter Ansell wrote:
> On 1 May 2013 11:36, Dave Longley <dlongley@digitalbazaar.com 
> <mailto:dlongley@digitalbazaar.com>> wrote:
>
>     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.
>
>
>     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.
>
>
> This may also be the downfall for JSON-LD in practice. If people 
> decide they are only going to accept particular profiles, and reject 
> all other profiles, and only provide documents to others in their 
> version of one of the profiles, then the *ecosystem will not 
> function*, as it would if everyone at least provided a range of RDF 
> formats that others are likely to be able to parse to RDF triples. The 
> True Web Developer may only accept a compact JSON-LD profile and 
> reject an otherwise valid document just because it is structurally 
> very different and they would then need a JSON-LD library to use it. 
> Not enforcing mandatory support for all of the basic profiles on every 
> JSON-LD provider and consumer will force people back to the bad old 
> days where the structure of a document actually mattered and not just 
> the RDF triples that would be generated from that or any other 
> equivalent RDF document.

The structure of a document *does* matter to many Web developers. They 
*want* it to matter. With JSON-LD, you can decide whether or not you 
want it to matter; it will work for you either way. Yes, that may 
require a JSON-LD library, but I don't think that's an unreasonable 
expectation for a solution that makes it possible to convert existing 
JSON-based closed data silos to Linked Data with relative ease and, at 
the same time, support existing RDF-based applications. JSON-LD may very 
well be the catalyst for breaking RDF out of the fairly limited box it 
has been stuck in for some time. I don't think RDF/JSON will be, as it's 
just more of the same. It's just another serialization format, it isn't 
primarily designed to bring new audiences to RDF. The technologies have 
different goals. However, JSON-LD, I believe, adequately covers the main 
goal of RDF/JSON (to create a JSON serialization of RDF) and more.

>
> In RDF/JSON there is a single profile (ignoring graphs that are 
> optional and backwards compatible) meaning that they can directly 
> interact with any RDF/JSON document or in-memory structure in the same 
> way. Attaching URIs in the correct positions and making sure that each 
> literal has the correct annotations attached to it is a very small 
> function. Implementing it and verifying that it is correct and 
> interoperable for RDF/JSON is much simpler in theory than knowing 
> whether a particular value in some profiles of JSON-LD should be 
> interpreted as a URI or a literal that just looks like a URI, for 
> example. You may not even be able to generate a consistent RDF triple 
> model once you have an arbitrary JSON-LD document in memory if you 
> have not also successfully retrieved the context documents, assuming 
> that you want to be able to accept a wide variety of JSON-LD documents 
> that people may send you to encourage interoperability.
>
> In my opinion encouraging people to drop essential information from 
> their documents is dangerous for the future of Linked Data and RDF. 
> Requiring them to all have internet access to successfully look for 
> the context, and requiring producers to continually provide access to 
> the context for the foreseeable future is an additional hurdle for a 
> Linked Data web which is already fragile and prone to failures.

JSON-LD is designed to express Linked Data. I don't think it's too much 
to suggest that an application that is consuming Linked Data should have 
access to the Internet and that URLs should be dereferencable. Anything 
less might be considered absurd, actually. Even so, if you want to use 
JSON-LD as a simple RDF transport on a closed network (or no network at 
all) you can still do that. Again, in those limited circumstances, if 
you must, use expanded and flattened form and/or embed your contexts. 
Or, if you're assuming all of the data uses the same context because 
your network really is that closed, just assume a default context and 
don't worry about attaching a context anywhere until the data leaves 
that network and heads off to the Web.

> The only JSON-LD alternative for people who want to work with RDF 
> triples easily and consistently that is being put forward is 
> restricting everything in practice to the flattened profile, after 
> which point it has no distinct advantage over RDF/JSON or N-Triples, IMO.

JSON-LD doesn't have any real distinct advantages over RDF/JSON or 
N-Triples if you were to just use flattened form all the time. That's 
correct. I think it's fair to say that flattened JSON-LD, RDF/JSON, and 
N-Triples, if you're just going to be working with triples all the time, 
all function the same way. Any one of them will get the job done; you're 
not getting much by choosing one over the other. Especially if you're 
going to argue that structure shouldn't be relevant in any way. But this 
is really the point; if you're not trying to change the status quo and 
get RDF or Linked Data adopted by a larger audience, then just stick 
with N-Triples. If your applications and services are already RDF-aware 
and dependent on RDF APIs, etc., then your serialization format doesn't 
really matter. JSON-LD was designed to ensure that use case was covered, 
but it is also much more than that.

>
> Users would always have to assume the lowest common denominator when 
> crafting their JSON-LD documents if they didn't know where the 
> document was going to be sent. The massive complexity in the JSON-LD 
> specification would be for nothing in practice as the lowest common 
> denominator, by definition, would need to be flattened, not the highly 
> optimised structures that require further operations before 
> interpreting the results to consistent models. Further to that, I 
> could imagine some JSON-LD consumers only accepting JSON-LD documents 
> if they import specific named contexts, just because they can, and the 
> specification says nothing about mandatory acceptance of particular 
> profiles. The user would then need to customise the *syntax* of their 
> document to match it to a particular server API, which seems to be 
> what True Web Developers want. The RDF community will see that as 
> insane given the overwhelming support for the RDF *abstract* model as 
> the basis for Linked Data so far (even if there are people who are 
> experimenting with non-RDF Linked Data, which is a discussion from 
> another concurrent thread).
>
> In practice if Martin is going to recommend that internal developers 
> accept JSON-LD it would be non-sensical to tell them that they need to 
> accept all of the profiles, some of which may not even look consistent 
> based on potentially unintuitive definition changes in the context 
> document.
>
> There is tool support out there for RDF/JSON by the way. I have been 
> using rdfquery.js in the browser with SesameTools/Sesame RDF/JSON 
> writer/parsers on the server in Java for the past 2 years. I can 
> imagine that if there is not support in other languages, as I haven't 
> looked for it, then it would definitely not be hard to implement given 
> the clarity and simplicity of the single algorithm that backs the 
> draft RDF/JSON specification.

As soon as the argument becomes: "If there's support in the language, 
then it doesn't really matter", JSON-LD does gain a distinct advantage 
over the other options simply because it covers the same use cases the 
other options do... and more. The "and more" was the focus in designing 
JSON-LD, as that is where Linked Data/RDF penetration has been limited 
in the past.

-- 
Dave Longley
CTO
Digital Bazaar, Inc.