Re: RDF/JSON

On 28 April 2013 02:03, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On 04/17/2013 12:21 PM, Martin Nally wrote:
> I acknowledge that RDF/JSON is much simpler because it has much fewer
> features but is that really an advantage in this case?
>
>
I have found it to be an advantage in dealing with arbitrary triples using
RDF/JSON. JSON-LD is great for annotating fixed structures if you have a
relatively fixed JSON API and you want to access it directly using JSON
without modifying it too much, where RDF/JSON can represent any triples
without relying on different methods for slightly different use cases.


> Does the statement "we would rather point to a specification" mean that you
> wanna propose to put RDF/JSON on the REC track?
>
>
Before RDF/JSON goes too much further I would like to propose an addition
to make it optionally a quads format. Joshua Shinavier extended the
RDF/JSON format when it was implemented for SesameTools a while back to
include an extra optional graph element attached to each object, and it has
been working well for me, and as of Sesame-2.7.0 there is a parser and
writer that both use this extended graph-aware RDF/JSON format.

I have also developed, and am willing to contribute to W3C, a small initial
compliance test suite for RDF/JSON in order to verify the Sesame
implementation if/when it gets more attention from the RDF workgroup.


> > I hope this helps explain our usage of RDF/JSON and JSON-LD and our
> > experiences with them.
>
> Yes, it definitely helped me to understand some of the challenges you have
> to deal with. But nevertheless, it didn't convince me that there's need for
> a second format. I would much rather hope that all RDF/Linked Data in JSON
> converges to JSON-LD. It has a higher initial cost but having a single
> format for which tools and libraries are being developed will pay of in the
> long term.
>
>
RDF/JSON has a very small initial cost for existing RDF developers, and it
may actually help new RDF developers understand the graph model underlying
RDF.

JSON-LD has a high initial cost for both existing and new RDF developers,
although once you get to using it, and you can easily merge the context
into a document in your head, then you may find it useful.

It is mainly for those reasons I doubt that RDF/JSON is going away anytime
soon for users who want to serialise arbitrary RDF graphs to JSON. For
those that want to make or annotate existing JSON APIs JSON-LD is the
solution to their problems, but it isn't a very clean generic solution in
terms of RDF.

Can all JSON-LD documents can be parsed consistently to RDF triples without
having to retrieve a context document from the internet to parse along with
an existing document?

None of the things you described is a fundamental problem IMO. I certainly
> don't wanna belittle the challenges you had to deal with and also
> understand
> that for certain, very specific use cases RDF/JSON is a better fit. You
> will
> find a slightly better solution for almost every use case that is specific
> enough. The important thing is that we have a format which is able to
> address all use cases. It is also critical that it feels "native" for Web
> developers - RDF/JSON certainly does not.
>
>
That is one usecase. I think RDF/JSON and JSON-LD can work well for RDF
developers and traditional web developers respectively, without being
biased to one just because it uses the same base language. I completely
disagree with your assertion that it is important that a single JSON RDF
serialisation needs to fit with everyones usecases, as it encourages
complexity, which can only be a bad thing in the long term.


> Having a single format obviously means that it can't be the most efficient
> for all scenarios. I'm convinced that tooling will be build to address
> those
> "shortcomings" in the future. Framing [4] is already a first step in that
> direction. Let's try to not divide the community by having to competing
> standards.. we are still developers.. so having to write a few lines of
> code
> more in certain scenarios isn't that much of a problem. I'm sure libraries
> will emerge that do that for you very soon.
>
>
One of the issues for me is that JSON-LD can be represented in so many ways
that it is difficult to easily process any one of the serialisations. Is
there a quick and/or standard way of identifying which version/profile of
JSON-LD you are looking at? The multiplicity may be an advantage for JSON
API authors to fit with as many of their existing models as possible, but
it may also turn out like RDF/XML where there are many different ways to
represent the same RDF triples.

Arguing that JSON-LD will be able to be parsed as RDF triples by a select
number of highly developed libraries kind of defeats the point of the
argument for it as *the* universal, easy to use, JSON serialisation of RDF.
An RDF/JSON parser is massively simpler than a JSON-LD parser, and can be
written in a few lines of javascript on the fly if necessary. For that
matter, all of the other JSON RDF serialisations that have been proposed
can be parsed in a few lines of javascript, or in some cases using SPARQL
Results JSON parsers.

Cheers,

Peter