- From: Peter Ansell <ansell.peter@gmail.com>
- Date: Sun, 28 Apr 2013 09:42:35 +1000
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: Arnaud Le Hors <lehors@us.ibm.com>, public-rdf-comments@w3.org, Martin Nally <martin.nally@gmail.com>, Joshua Shinavier <josh@fortytwo.net>
- Message-ID: <CAGYFOCSyoQur8V4iKvPvqN+88D-UQWrfYNpceEohVobLh=WnTw@mail.gmail.com>
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
Received on Saturday, 27 April 2013 23:43:02 UTC