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

David Booth wrote:
> 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.

A URI/name can still reference a unique distinct unambiguous thing even 
when the description of that thing leaves much to be desired and is 
extremely ambiguous.

If I create a URI <http://webr3.org/nathans#tv> and publish one triple:
   <http://webr3.org/nathans#tv> :color "black" .
The name is extremely unambiguous, it only refers to a single unique 
thing, the description on the other hand leaves much to be desired.

Does this mean that the name refers to anything which is black in color? 
does it mean I can use the same URI to refer to everything I own that's 
black in color? does it mean that the name is ambiguous?

Would your semantic web machinery be able to tell if I used the name to 
refer to 3 different unique things which were all black? what about if 
other people started using the name to describe those three things? what 
if I fleshed out the description to describe each thing unambiguously 
over time?

Personally, I believe we'd have a big problem on our hands, and that one 
name must only ever be used to refer to one distinct thing. I also that 
our descriptions can be as bare and ambiguous as we like, as they can 
always be improved over time by publishing and linking more data.

Best,

Nathan

Received on Sunday, 20 March 2011 22:32:33 UTC