Re: Important Question re. WebID Verifiers & Linked Data

On 12/21/11 3:45 PM, Patrick Logan wrote:
> See below...
> On Wed, Dec 21, 2011 at 8:27 AM, Henry Story < 
> <>> wrote:
>     On 21 Dec 2011, at 14:58, Kingsley Idehen wrote:
>     >
>     > Please understand that RDF != Linked Data. It's just one of the
>     options for creating and publishing Linked Data.
>     I think it would be very nice to have a formal spec on what Linked
>     Data is. We do have a few for
>     RDF.
> Yes, please. I understand the RDF-related specifications. And I 
> understand the general notion of "linked data". I am someone following 
> the WebID effort, and who is contemplating the costs and benefits of 
> supporting it in my products at some point.
> Unless I see a WebID specification (or a more general "world-wide 
> linked data specification") for how to support linked data beyond RDF, 
> how can I estimate the costs and benefits of supporting linked data 
> beyond RDF?
> Please understand that "publishing and consuming any and all possible 
> interpretations of 'linked data'" is probably impossible.
> So what are the specific requirements?
> -Patrick

Here are the fundamental requirements:

1. a Data Item (Object or Entity) is uniquely identified by a URI based Name
2. use de-referencable URIs as Names that resolve to *descriptor* 
documents (resources) that describe the URI's referent
3. descriptor documents (resources) should *consist* or *bear* 
structured data in the form of eav/spo triples (or 3-tuples) statements 
that collectively form a directed graph pictorial that coalesces around 
the description subject's URI .

You can make statements eav/spo statements using a variety of syntaxes.
You can serialize eav/spo bearing resources across the wire using a 
variety of data serialization formats.
You can leverage HTTP as a low cost and effective mechanism for:

1. de-referencable URI based Names
2. negotiation of data serialization formats between servers and clients 
(user agents).

The WebID spec can require or suggest a number of common formats for 
eav/spo triple transmission as the basis for effective bootstrap.
The WebID spec should never (overtly or covertly) be a tool for fighting 
or prolonging  syntax of format wars re. eav/spo triples.
The WebID spec should never leak the abstraction inherent in URIs by 
mandating http: scheme URIs.
The WebID spec should never compromise the fidelity of Linked Data by 
favoring a particular style of de-referencable URI.
The WebID spec is a spec. It shouldn't attempt to teaching software 

All of the above is possible without adversely affecting WebID. In 
short, all of this will make WebID attractive to much broader developer 
profiles that extend beyond the RDF based Semantic Web community.

What's the difference between RDF and EAV?

RDF explicitly (via spec) requires the use of URIs in S, P, and O 
(optionally) slots of triple statements. It also handles typed literals 
and language tags. Basically, it caters for locale issues and i18n.

EAV isn't as specific as RDF with regards to the items above. At the 
same time EAV is well known, and doesn't carry the political baggage of 

What's the difference between RDF and Linked Data?
There is nothing in the RDF spec (even as I write) that specifies the 
behavior of URIs used in SPO triples. For instance RDF doesn't 
explicitly distinguish between a URI that serves as a Name and a URI 
that serves as a Resource Locator (Address).

Linked Data is very specific about URI behavior. It expects URI based 
Names and Addresses to be distinct.  This is why it's always problematic 
to infer (overtly or covertly) that RDF == Linked Data. The *truth* of 
the matter is that RDF is one approach to constructing directed graph 
based descriptor resources (comprised of eav/spo triples) that result in 
Linked Data at various scales (local area network or wide area network 
e.g., the InterWeb).


Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:

Received on Thursday, 22 December 2011 03:43:11 UTC