Re: Fwd: RDF/JSON

On 1 May 2013 13:25, Dave Longley <dlongley@digitalbazaar.com> wrote:

>  On 04/30/2013 10:37 PM, Peter Ansell wrote:
>
> 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.
>
>
> 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.
>
>
JSON-LD will have its day in the Web Developer community. Whether it gets a
following in the RDF community is a different story. It would, I think, be
a shame if the format was let down by a lack of standardisation about what
was expected of producers and consumers with regard to supporting different
profiles.

It should be entirely possible for Web developers to expose their data in
different RDF Formats if they are already using a JSON-LD library. The
obsession with having web services return a single format whose structure
is semantically important to the developer and their users is not healthy
for the web in general, even if it is the norm and is expected, and it is
definitely not a requirement of the Linked Data goals.


>
>
> 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.
>
>
>
There is a small difference between making Linked Data an option and
requiring that anyone who finds JSON-LD documents with external contexts in
the future must necessarily have access to the internet, and have access to
that particular context in its original form to be able to interpret the
data the same way as anyone else who found that document in the past.


>  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.
>
>
I do understand that JSON-LD is meant to be more than an RDF format, but it
would be a shame for both RDF and Semantic Web if it fell through because
it had too much leeway in trying to be everything to everyone.


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

Even with tool support JSON-LD still has more processing overhead (in terms
of synchronising/retrieving resources from different places) and is more
complex to process in a broader workflow than the other RDF formats.

As you say, the format and structure of the document is important to Web
developers, so they may never see the resulting triples and may never
bother to verify that the triples are what they intended. They may also be
less likely to integrate their data with other JSON-LD datasources if the
other datasources do not provide data in the JSON-LD profile that they
statically/solely know how to process in their application, as they would
need to know in each case how to normalise data from a particular provider
to their preferred JSON-LD. Then they may never integrate with non-JSON-LD
datasources that may not include namespace (ie, N-Triples / RDF/JSON /
N-Quads) where they would have full URIs exposed in any JSON-LD documents
they produce integrating that data, and they may not be able to normalise
to their profile without autogenerated prefixes that did not represent
something meaningful to them and may have them enquiring about RDF triples.

When I say that I have tool support for RDF/JSON, I don't imply that I
don't have support for other formats. I just mean that I know my
webservices provide RDF/JSON as one of the content negotiated formats
(something the cool Web developers have never got working), so I wrote
clients up to process RDF/JSON to RDF triples which I can then query in a
standard way. In my workflow there is no attachment to the document format,
and I am not convinced that there needs to be in a clean multi-format RDF
workflow. You may hear this alot (or you may not), but it feels like you
are going backwards by putting emphasis on the document structure when I am
able to enable all of my web services with another format by importing
another module, and anyone that understands that format can then access it,
JSON-LD inclusive.

The main difference with JSON-LD is that the resulting documents may not
actually match what people expect to see if they (legitimately according to
the spec) only understand a subset of the language that does not include
the closest thing the server was able to provide for them using its
RDF-to-JSON-LD algorithm. It may be as small an issue as that it did not
include the same prefix conventions as their application was hardcoded to
expect (something that would not deter an RDF client), but in doing so, it
would be a backwards step for Linked Data that is designed to be
interoperable and format-agnostic. If one cannot export data to another
format, including processing it as arbitrary RDF triples outside of the
JSON-LD model, for fear that they may not be able to submit the changes
back to the original producer to get data quality issues fixed there, then
they may be stuck at 1-2 star Linked Data essentially as it may as well be
proprietary at that point.

Cheers,

Peter