W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

Re: [JSON] Classifying the use cases

From: Richard Cyganiak <richard@cyganiak.de>
Date: Fri, 25 Mar 2011 11:33:39 +0000
Cc: RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <22262BD5-51AA-469E-8794-86EF4AC684B0@cyganiak.de>
To: Ivan Herman <ivan@w3.org>
On 25 Mar 2011, at 08:50, Ivan Herman wrote:
>> On a technical level, the difference is that in #3, the publisher provides just JSON to its clients, and doesn't assume that there are any clients interested in getting RDF out of the JSON. So the RDF is hidden under the hood; the published API is just JSON.
>> In #1, I suppose the API *can* be used simply as JSON if one ignores the extra bits, but it *can* also be parsed, at least partially, as RDF.
>> More important however is another aspect. There is another goal in #1: It's a bit of a trojan horse. It's an easy migration path that allows publishers to sprinkle in a bit of RDF into their existing JSON APIs *if* they want. And consumers can use a bit of RDF *if* they want. And hopefully it might get more and more over time.
>> #3 has nothing of this; RDF is only used by the publisher, and the client is shielded from it. (The publisher may of course offer other, more traditional, ways of providing RDF to clients who want that. Content negotiation between Turtle and pure JSON, for example.)
> I understand every word you say:-), but it is still not clear in my mind whether any solution in this space would really differentiate strongly between #1 and #3. But that may only be me...

It's well possible that a solution for #1 would also address #3. A solution designed purely to satisfy #3 would obviously not satisfy #1 because it can't be consumed as RDF.

Received on Friday, 25 March 2011 11:34:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC