W3C home > Mailing lists > Public > public-rdf-comments@w3.org > April 2013

Re: Fwd: RDF/JSON

From: Peter Ansell <ansell.peter@gmail.com>
Date: Wed, 1 May 2013 09:21:11 +1000
Message-ID: <CAGYFOCTPr7cGq=tDLjuQW=HU7Rfg2UMc48PNdBQC1pCMEX3L8w@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: Martin Nally <martin.nally@gmail.com>, public-rdf-comments@w3.org
On 1 May 2013 07:23, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 04/30/2013 01:37 PM, Martin Nally wrote:
> > Based on our experience implementing applications, this is the
> > advice I am giving people at IBM, and anyone else who asks me.
>
> How many production systems have you deployed using JSON-LD vs. RDF/JSON?
>
>
Personally I have been using RDF/JSON for the past 2 years, as it has been
production ready for at least that amount of time.


> > 1) If you are writing RDF-aware clients and servers, and you are
> > looking for a data format for the interface between them, use
> > RDF/JSON.
>
> Why not just TURTLE or N-Triples? What are the benefits of JSON if you
> have RDF-aware clients/servers?
>
>
JSON parsers are readily available, and with RDF/JSON you can query the
resulting in-memory object straight after you run any JSON parser on it.


> > This is true whether or not you were previously interested in JSON.
> > Think of RDF/JSON as the natural way for RDF-aware programs to talk
> > to each other, regardless of other technology choices - it's the RDF
> > format for programmers.
>
> Why? What makes it the 'natural way'? Why is RDF/JSON the 'format for
> programmers'?
>
>
Because it reflects the underlying structure directly, IMO.


> > 2) If you have an existing JSON format, and you want to extend it so
> > it is more self-describing for RDF-aware clients, consider using
> > JSON-LD. An alternative is to offer two different media types - your
> > current one and RDF/JSON
>
> Our experience has shown us that most Web developers don't care about
> RDF. They care about data structures that are easy to work with,
> specifically, JSON is really nice. RDF/JSON is a bit of a nightmare to
> work with for a large subset of Web developers.
>
>
As long as they realise that they are not really producing Linked Data if
they are actually labelling their resources with blank nodes then it is
fine to us JSON-LD. With RDF/JSON they are forced to name their resources,
or use blank nodes that are clearly not resolvable.


> > 3) If you are designing a new RDF-aware server and you want to
> > expose it to both RDF-aware and RDF-unaware clients, offer two
> > different media types - RDF/JSON plus "web JSON". Offering JSON-LD
> > will not be popular with either the web crowd or the RDF crowd, both
> > of whom will view it as unnecessarily complex from their point of
> > view.
>
> JSON-LD is more concerned about the "Web crowd" than the "RDF crowd".
> The "RDF crowd" has never had a problem with consuming and publishing
> RDF. However, the RDF crowd has stayed very small over the past decade
> due to the lack of a good data format that is useful to the broader
> programming community.
>
>
Does the Web crowd actually want to give names to resources? Is JSON-LD
little more than a specialised JSON format, rather than an RDF format, if
the Web crowd do not actually want to use RDF and they could care less
whether their resources can consistently be translated to RDF triples?


> JSON-LD's approach is to embrace what's currently working on the Web
> (JSON), and augment it such that it's not changed into something that
> Web developers won't recognize (RDF/JSON). We expect that most useful
> JSON-LD will end up looking like this:
>
> {
>   "@context": "http://example.com/context.jsonld",
>   "key1": "value1",
>   "key2": "value2"
> }
>
> The document above is far more useful to a regular Web developer than
> its RDF/JSON counterpart:
>
>
That is your opinion.


> {
>   "_:bnode1": {
>     "http://example.com/vocab#key1": {
>       "value": "value1"
>       "type": "literal"
>     },
>     "http://example.com/vocab#key2": {
>       "value": "value2"
>       "type": "literal"
>     }
>   }
> }
>
>
The authors of these interfaces will still need to know that when they are
using JSON-LD that they are relying on blank nodes to identify their
resources, otherwise they really won't be part of the Linked Data crowd.


> > It is possible I will change my mind as I learn more
>
> I hope you do as the opinion you have expressed is very much in the
> minority based on the feedback we've received from developers. I think
> you might be conflating a good dump format (like N-Triples and RDF/JSON)
> with something that developers would like to use (like JSON / JSON-LD).
> You may want to watch this to get an idea of why Web developers prefer
> simple key-value data structures vs. the SPO data structures of RDF:
>
>
I am amazed that the JSON-LD developers feel threatened enough by RDF/JSON
to be putting up a fuss about it possibly being a recognised format by the
W3C. If True Web developers prefer JSON-LD then they can start off by using
that once it gets out their, but it shouldn't stop the standardisation of
Yet Another RDF Format just because it can be parsed using the same family
of parsers.

Luckily RDF/JSON is already complete enough (and simple to understand for
people wanting to work with RDF triples) that it can be useful for groups
of developers whether the W3C decides to push it through or not.

Cheers,

Peter
Received on Tuesday, 30 April 2013 23:21:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:32 UTC