- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 28 Jun 2011 09:19:55 +0100
- To: public-linked-json@w3.org
On 6/28/11 1:53 AM, David I. Lehn wrote: > On Mon, Jun 27, 2011 at 4:26 PM, Kingsley Idehen<kidehen@openlinksw.com> wrote: >> On 6/27/11 6:41 PM, David I. Lehn wrote: >>> On Mon, Jun 27, 2011 at 12:52 PM, Kingsley Idehen >>> <kidehen@openlinksw.com> wrote: >>>> The day we separate RDF and the basic concept of Linked Data is the day >>>> rapid adoption resumes. >>>> >>> "RDF" vs "Linked Data" with a bias against RDF has come up in many of >>> your posts. >> Please, what do you mean by "bias against RDF" ? That's utterly false, and >> if you don't know that to be the case, please provide an example. >> >>> Could you please explain your view on the differences and >>> why you are against RDF? >> ... >> > Let me rephrase. In the context of the JSON-LD discussion, which > parts of RDF and Linked Data do you think should be included in a > JSON-based spec, and which parts should be left out? > > -dave > > Dave, I just want a spec that enables people to construct resources bearing (carrying) SPO/EAV based graphs using JSON. RDF != the only way the above is achieved. The use of Identifiers in the S(E), P(A), and O(V) slots of a 3-tuple isn't unique to RDF. RDF has been evolving (as it should) so has the scope of its application. In the beginning it was solely about Metadata construction for Resources, hence the name: Resource Description Framework. Around 2005-2006 it evolved to into a mechanism for "whole data representation" courtesy of TimBL's meme re. Linked Data. The problem is that "whole data representation" and metadata representation aren't the same thing. When dealing with "whole data representation" there are some new issues that creep into the game such as: 1. URI based Names that Resolve to representations of their Referents 2. Disambiguation of Names and Addresses 3. Distinguishing a Resource that bears (carries) a description (representation) of a Description (or Observation) Subject from the Subject itself. RDF's scope has been evolving over the years, it used to be solely about descriptions of Web Resources (data containers or documents at Web Addresses). It's now about what was classed as Distributed Object Technology in the CORBA era, but without the fatal flaw inherent in CORBA where Data Objects and Object Oriented Programming Languages inextricably bound. There isn't a bias against RDF, there is a desire to decouple RDF from Linked Data since it isn't the sole option for achieving Linked Data's fundamental goal which is: fine-grained structured data, in distributed data object form, at InterWeb scales. As was the case with the initial boostrap of the WWW, success depends on the "deceptively simple" principle whereby creating a Linked Data bearing Resource is at least superficially dead easy. Unfortunately, RDF isn't dead easy, at least not to the majority of Web developers and end-users many of us have encountered in our travels over the years. IMHO. the reason for this simply boils down to the context for RDF appreciation not really being in place, there has to be a global structured data substrate in place first, before the semantic fidelity of RDF becomes comprehensible and ultimately appreciated. RDF is still very much a Prescription rather than a Cure. Unfortunately for RDF, the target audience is Human and we Humans (sadly) prefer Cures. Believe it or not, I want RDF to succeed, but I am also experienced enough to know that adding an RDF tax to the Linked Data meme only serves to impede manifestation of the WWW's extremely powerful Data Space dimension. Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Received on Tuesday, 28 June 2011 08:20:24 UTC