W3C home > Mailing lists > Public > public-linked-json@w3.org > June 2011

Re: Yet another serialization format?

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 28 Jun 2011 09:19:55 +0100
Message-ID: <4E098EAB.3010205@openlinksw.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:34 GMT