Re: Comments on "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"

On Sat, 2011-03-19 at 07:49 +0530, Tim Berners-Lee wrote:
> On 2011-03 -19, at 02:21, Nathan wrote:
[ . . . ]
> > So perhaps the question being answered is, can we feasibly carry out
> > a conversation where we refer to both a birth certificate and a red
> > lightbulb by a single ambiguous name? using RDF?
> > 
> > Possibly, but why even try?
> 
> Seeing that without having caught up on the thread,
> No, I really do not want to go down that route, of trying that.

But you have no choice.  It is *impossible* to define something in a way
that is universally unambiguous (except perhaps in vanishingly few
cases).  Granted, the example of the birth certificate and lightbulb is
rather extreme.  But once you admit this fundamental limitation, it is
merely a question of where and when you run into this issue -- not
*whether* you will run into it.

For example, suppose instead of birth certificates and lightbulbs we
were talking about LED lightbulbs versus filament lightbulbs.  Clearly
one could imagine an application in which "we refer to both [an LED
lightbulb] and [a filament lightbulb] by a single ambiguous name", and
the application may work just fine, because it has no *need* to
distinguish between LED and filament bulbs.  But to a different
application the distinction between LED bulbs and filament bulbs may be
as critical as the difference between birth certificates and lightbulbs
is to an application that computes power consumption.

> It is a fundamental architectural principle that a URI can be taken
> out of context
> an needs no other context to figure out what it identifies.

Yes, I agree with that.  And I'm going to assume that the way the
identity is figured out is from some sort of definition, since otherwise
we would have chaos.  (My preference is that the definition be findable
via the URI, as described in "Cool URIs for the Semantic Web", but
that's a somewhat orthogonal issue.)

BUT -- and this is a key "but" -- there are limits to how *precisely*
you can figure out what it identifies, no matter how good the definition
is.  If the definition is precise enough for your application, then
you're in luck -- the identity is unambiguous *for* *that*
*application*.  But it is *always* possible to come up with another
application that requires finer distinctions.  And for those
applications, the identity will be ambiguous.

The point is that there is no such thing as a universally unambiguous
URI identity.  The ambiguity or uniqueness of the URI's identity is
*relative* to an application.  However, the degree of ambiguity can be
precisely *bounded* by associating the URI with a universally accepted
definition, such as one that is provided in a document that is findable
via the URI.  And, in my view, this is a key thing that semantic web
architecture should support.

> So if I say for URI x  "x expires on 2015-01-01" I must be able to know 
> whether the lightbulb or the certificate expires.

No, that does not follow at all.  Only applications that *distinguish*
between lightbulbs and birth certificates will need to know which it is
that expires.  An application that only cares about granting access to a
storage bin may only need to know whether Alice owns it or Bob owns
it.  

> 
> We have a huge linked data infrastructure based in this
> architecture which I do not want to start again.

I agree, and I certainly do not advocate starting again.  But as a
community we must refine our understanding of how resource identity
works, and get over the notion that the ambiguity or uniqueness of a
URI's identity is universal.  Its ambiguity may be precisely *bounded*,
but the identity will always be ambiguous to some applications even as
it is unique to others.

Just as the speed of an object is relative to the observer, the
ambiguity/uniqueness of a URI's identity is *relative* to the
application.



-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Sunday, 20 March 2011 02:32:13 UTC