Re: Official response to RDF-ISSUE-132: JSON-LD/RDF Alignment

On 9 June 2013 04:30, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> Hi Sven,
>
> thanks for your mail.
>
>
> On Saturday, June 08, 2013 5:13 PM, Sven R. Kunze wrote:
> > Hi,
> >
> > maybe, the perspective of a potential user helps:
>
> It always helps to hear more opinions.
>
>
> > First, I thought, hmmm, what's this all about, yet another
> > serialization for RDF? Something even better?
> > To be honest, I didn't spent to much time on the intro as they are
> > always quite superficial; especiall when it comes to buzz words like
> > Linked Data.
>
> :-)
>
>
> > I read the syntax part and thought, okay, yet another serialization
> > for RDF, quite verbose with all this JSON []s and {}s, acceptable for
> > Web clients as they already have JSON parsers. But no mentioning of
> > RDF so far.
>
> Well, that part is describing the syntax :-P
>
>
> > BUT the "JSON-LD data model" has been mentioned. Whoooops, now, I was
> > confused because RDF is a data model.
> > So, I read part "data model" and the part "relationship JSON-LD to RDF"
> > Again, I became more and more confused.
>
> So the following sentence wasn't clear enough?
>
>    The RDF data model, as outlined in [RDF11-CONCEPTS], is an abstract
>    syntax for representing a directed graph of information. It is a
>    subset of JSON-LD's data model with a few additional constraints.
>    The differences between the two data models are: ...
>
>
> > My preliminary conclusion: <<<It's just the same as we can do the same
> > with both.>>>
> > Correct me if I am wrong but having "native literals" does not make
> > any difference as most RDF tools and JSON-LD tools will give me a
> > variable filled with a datatype specific to the programming language I
> > use.
>
> Well, you might not care, but other people care :-P JSON-LD has e.g.
> native numbers and (probably more interesting) lists. In RDF everything is
> a opaque string that can only be interpreted, i.e., converted to a number
> in your programming language, if you understand the data type. So to speak,
> JSON-LD has a built-in data type for numbers.
>
>
I think you are not fully comprehending the importance of numeric precision
for an RDF-compatible data format if you are referring to this as a
feature. If the JSON numeric datatypes were compatible with the XMLSchema
numeric datatypes then there would be no issue, but supporting this just to
save a few quotes is not going to help in the long term. All of the main
programming models, except notably Javascript/JSON, understands the
XMLSchema numeric datatypes.


>
> > I really do not care of the serialization as the work on the data
> > is done in code.
> > So, it gives me the impression that JSON-LD is just another
> > serialization for RDF... But why a different data model?
>
> Because it allows things that RDF (currently) doesn't, i.e., blank nodes
> as graph names and predicates.
>
>
For what it is worth, if blank node predicates were useful, then they would
have made it into RDF in the past. They are too fragile, in terms of
consistent data interpretation for round-tripping and merging, to be widely
deployed, and creating a new format just to allow them and a few other
syntactic sugars is not going to help Linked Data, as the entire concept is
based around interoperability. If you can't reliably merge and manipulate
Linked Data from different locations then your Linked Data is sub-optimal.

Blank nodes as graph names are neither here nor there, as they haven't
actually been widely used for anything other than backups or trivial
purposes so far, as RDF so far allows their removal or modification without
consequence. There are in an entirely different situation to blank node
predicates that must be reliably round-tripped for the entire RDF Abstract
Model to be consistently used.


> > > We added the Data Model section since the RDF WG asked us to do so. I
> > > don't see compelling reasons to revisit that decision.
> >
> > I do not question the decision of the RDF WG but for me as a user it's
> > quite confusing as it does not contribute any significant advantage
> > (at least for me and my understanding of the spec). It in fact
> > introduce a steeper learning curve figuring out the differences of
> > both data models but from a practical point of view do not exist.
>
> To be honest, you are not really the target group since you are coming
> from an RDF background. Most people won't have that background knowledge so
> they do not have to compare anything but just to understand the data model
> the syntax is able to serialize.
>
>
Then why did the JSON-LD authors choose the RDF working group? If it is
infact creating a new JSON-LD-only ecosystem then it should not be
published here.

The draft of the Web Payments specification, where a single JSON-LD profile
forms the only possible serialisation and all of the transformations are
defined on the JSON graph, and not on the RDF Abstract Model, seems to make
it quite clear that JSON-LD is destined to be its own ecosystem and
compatibility with RDF is only intended to be for migration. Requiring Web
Payments JSON-LD documents to have a specific standard @context, and
specific key names, also makes it quite clear that to be compatible with a
JSON-LD API, developers will need to program and store data based on the
JSON abstract model, and serialise to match the destination, which is
definitely a good idea for an interoperable Linked Data Web, even if it is
the best that popular web developers have come up with so far. If the
JSON-LD group were serious about RDF compatibility, they would at require
that any valid JSON-LD document be accepted by Web Payments (and future
standards) for them to be able to reuse the specification in another W3C
publication. The ideal would be to allow any RDF serialisation, based on
content negotiation.


>
> > > JSON-LD is not RDF. Turtle is neither. Both are serialization formats
> > > with a mapping to RDF, an abstract data model.
> >
> > Thank you for that clarification!!! Finally, I got it. But why the
> > heck isn't the spec mentioning it?
>
> Quoting the spec (Relationship to RDF):
>
>    Summarized these differences mean that JSON-LD is capable of serializing
>    any RDF graph or dataset and most, but not all, JSON-LD documents can be
>    directly transformed to RDF.
>
> Isn't that saying exactly the same?
>

I think you underestimate the number of documents that will have issues
translating JSON numeric datatypes to RDF and back. Considering that the
first specification to reuse JSON-LD is the very number-sensitive Web
Payments draft, it seems a little naive to be brushing off that issue.


> > But as long as am I not able to make clear
> > statements of how everything fits together, I feel like an idiot
> > talking drivel.
>
> The goal of standardization is to find a compromise that can be accepted
> by all involved participants. We worked long and hard on this and I think
> we found a compromise which overall makes all of us equally happy (or
> unhappy for that matter).
>
>
The compromise so far seems to be heading towards JSON-LD not being
released by the W3C RDF Working Group as the authors have not committed to
conforming with the main abstract specification produced by the working
group, and they have not conformed to the charter of the working group to
create "a JSON serialisation of the RDF Abstract Model".


> What we are doing right now is minor-wordsmithing without any technical
> result at the end of a very long process. It is important to have these
> discussions but at some point it just doesn't make much sense anymore to
> rehash the same discussions over and over again. It just has to be accepted
> that there are different opinions.
>
>
Different opinions are what makes workable long-term standards more useful
than the results of a typical committee driven process. If there are
continued discussions without suitable conclusions then it may mean there
is an underlying issue.


> People are waiting for this technology to become a proper standard. Some
> are waiting for a long time and I think most of us deeply involved in this
> standardization process are exhausted after all the hard work we've done
> over the years. It's time to ship.
>
>
If you can't ship your product before the W3C RDF Working Group rubber
stamps this particular format then you are in trouble and your business
model is flawed. If on the other hand you had defined your application
directly on RDF you would not have this delay, as users would have a number
of stable, well-defined, backup formats to communicate using both now, and
in the future when JSON-LD stabilises as "the JSON serialisation of RDF".

I am not saying that JSON-LD is a bad standard, but relating it to RDF
(even non-normatively as it is currently in the main JSON-LD specification)
brings with its a responsibility to maintain the existing community. Even
more so since you chose to promote and develop it so close to the RDF
specificiation. If it were any other format developed outside of the RDF
working group, and specifically to not be an RDF serialisation then we
wouldn't be commenting this way, as it would have its own ecosystem and
that would be fine. We may even promote the mapping of JSON-LD back to the
abstract RDF model with partial interoperability instead of criticising it
for not even having the goal of reasonable interoperability.

Peter