What Does Point Number 3 of TimBL's Linked Data Mean?


Situation Analysis (for additional context):

There are two versions of Design Issues documents [1][2] from TimBL 
where the primary topic is Linked Data. Both documents a comprised of 
four bullet points that outline a principled approach to document 
content production and publication en route to a Web of Data.

Naturally, for a majority of folks, TimBL's design issue memes 
(irrespective of their clearly stated disclaimers) are deemed 
authoritative with regards to matters relating to Web Architecture and 
best practices.

Current Problem:

The fundamental meaning of point three in both Linked Data memes has 
*inadvertently* lead to very strong differences of opinion, with regards 
to interpretation. Here are the two interpretations (that I know of) 
which stand out the most:

1. RDF and SPARQL are implementation details
2. RDF and SPARQL aren't implementation details -- basically, you can't 
produce Linked Data without knowledge and/or a commitment to either.

Why do we need to resolve this matter?

It has become a distraction at every level, it is basically leading to 
fragmentation where there should be common understanding. For example, 
some of us are more comfortable with RDF and SPARQL as implementation 
details while others aren't (it seems!). This difference of 
interpretation appears insignificant at first blush, but as you 
drill-down into the many threads about this matter we also hit the key 
issues of *tolerance* vs *dogma*.

What do I mean by RDF and SPARQL are Linked Data implementation details?

They are W3C standards that aid the process of building Linked Data (as 
outlined in the TimBL's revised meme). That said, it doesn't mean that 
you cannot take other paths to Linked Data while remaining 100% 
compliant with the essence of TimBL's original Linked Data meme.


DBpedia (and other LInked Data endeavors that leverage Virtuoso or tools 
like Pubby) apply point number three (either meme version) as follows:

1. use HTTP re-write rules to generate SPARQL Protocol URLs
2. use content negotiation to align SPARQL protocol URLs with the 
content types requested by an HTTP user agent.

The net effect of the above is as follows:

1. HTML browsers become Linked Data Browsers -- including IE6 (you can 
follow-your-nose to wherever curiosity takes you without exiting HTML)
2. CSV Browsers become Linked Data Browsers -- I've demonstrated this 
using SPARQL-FED based SPARQL protocol URLs that simply return CSV output
3. RDF processors are exposed to the expanse of Linked Data -- i.e., 
they have wider access to entities enhanced with an understanding of 
their relationship semantics
4. OWL processors are exposed to the expanse of Linked Data -- ditto ++.


1. http://bit.ly/14gE7wQ -- TimBL's original Linked Data meme
2. http://bit.ly/NvbPLF -- TimBL's revised Linked Data meme
3. http://dbpedia.org/resource/Linked_data -- DBpedia URI for the Linked 
Data concept
4. http://bit.ly/13lcdAM -- Vapor (Linked Data verification utility) 
report for <http://dbpedia.org/resource/Linked_data>
5. http://bit.ly/16EVFVG -- Venn diagram illustrating how some of us see 
the relationship between Linked Data, RDF, and Identifiers.



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Friday, 21 June 2013 17:07:08 UTC