Re: Fwd: RDF/JSON

On 1 May 2013 11:36, Dave Longley <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.

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. 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.

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.

Peter