Linked Data nuances, exemplified

On 2/18/13 3:13 PM, Michael Hackett wrote:
> It was only when this debate erupted a few months ago, leading me to 
> read some of the materials referenced in the posts, that I started to 
> understand their purpose. To tell the truth, there are still some 
> points that I'm a little unclear on, but this probably isn't the forum 
> to delve into them.

Here is a simple example based on URI used in a response I received from 
Henry i.e., <> .

On the surface:

Paste that URI into the address bar of your browser and you end up with 
data (in HTML format) that describes <>.

What does that mean? Superficially, you might assume that 
<> and 
<> denote the same entity. In 
reality they don't, since <> is 
really <> due to your browser only 
processing <>.

Thus far, my claim can be verified by asking for a description of each 
of the following from DBpedia using the following URL pattern:{DBpedia-Entity-URI> .

Example: .


DBpedia already has a massive collection of hashless HTTP URIs that 
denote entities derived from its extraction and processing of content 
from Wikipedia. It already denotes an entity using 
<>, so if 
<> denoted the same thing you 
should be able to obtain a description of said entity from DBpedia using 
one the following methods:

1. go to, click on the "Entity URI Lookup" tab 
and then paste in: .

2. you can also lookup this SPARQL URL: 

As you can see <> doesn't denote 
the same entity denoted by <> . 
Basically, I can't effectively use 
<> and 
<> as co-references for the same 
entity. Of course, if I generate a batch of owl:sameAs relations across 
the DBpedia quad store I could end up with a functional co-reference 
that would be understood by an inference engine that understood OWL 

You can denote a Web Resource using URI or URL i.e., Name / Address 
ambiguity inherent in HTTP URIs doesn't have an adverse effect on either 
role. You can't denote real world entities (or resources not of the Web) 
which such Name / Address ambiguity -- hence the need for mechanism that 
maps the HTTP URI to Name function to a Resource Address function via a 
form of indirection such that a Name or Address ultimately gets you to 
the same data in the format you desire (typically HTML at first blush).

Excerpt from a note about this by Pat Hayes and Harry Haplin:

"/The end result of this saga of URNs and URLs merging into URIs is that 
on the Web there is a single universal identification scheme for both 
identifying accessible and non-accessible resources. In this regard the 
Web is radically different from previous identification schemes. In 
programming languages, an identifier translates into the identity of 
some block of memory, even if there is no code that runs at that 
location. In other hypertext systems, one assumed that the unique 
identifiers were allowing links between accessible documents or some 
sort of file. Yet on the Web one can have a URI for the "Eiffel Tower in 
itself," such as This 
brings up a new type of problem for users, for if they access that URI, 
how do they know it identifies the Eiffel Tower itself and not just a 
Web page about the Eiffel Tower?  Assuming it is useful to identify 
non-accessible things on the Web using URIs, should we distinguish 
between these two types of things and if so, how? Should a URI for "The 
Eiffel Tower itself" bear some special marking that makes it different 
from a URI that lets one access Web pages about the Eiffel Tower? /"


1. -- recent post about SPARQL based reasoning 
based on DBpedia .
-- about HTTP URI ambiguity .



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

Received on Monday, 18 February 2013 21:01:00 UTC