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

On 03/20/2011 04:02 AM, Pat Hayes wrote:
> 
> On Mar 19, 2011, at 9:31 PM, 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.
> 
> David is exactly right. Here is my favorite example. Consider the claim that Everest was climbed by Edmund Hilary. This is probably stated in RDF somewhere by now, using a URi to identify Everest. But what exactly *is* Everest? Is it a geographical place? (What are its boundaries?) Is it a large piece of rock? (What does it weigh?) Maybe it is a 'mountain', but then you can find many definitions of 'mountain', all of them subtly incompatible. Now, of course, none of these questions matter a damn to the truth of, or even the meaning of, that simple sentence; it is not necessary to answer them in order to determine the truth of the sentence. But if we (wrongly) claim that the meaning or truth of sentences depends upon being able to uniquely and unambiguously identify the referents of all terms used in the sentences, then we are forced into focussing upon all such unanswerable and irrelevant details. 
> 
> Even if we could answer them, by the way, this state of grace would only last for a while, since ironically, the very ability to make new ontologies means that formerly unambiguous names can become ambiguous. Science bristles with such cases. Elements are revealed to be mixtures of isotopes. So "carbon" is now, for some purposes, ambiguous: did you mean carbon-12 or carbon-14? Even apparently robust things like personal names become ambiguous when we have rival ontologies of personhood. "Sir Tim Berners-Lee" might refer to the man in the present, or to a temporal continuant, or to a 4-dimensional entity extended in time. You might object that you don't care about such pettifogging obscurantism, and I agree; but this makes exactly our point, since there are those who do care, and in fact there are clashes between internationally accepted and widely used ontology standards which turn on such distinctions. So your proper name, even if it does uniquely "identify" you, is still 
*ontologically* ambiguous, because (I'm sorry to have to be the one to tell you this, but...) *you* are ontologically ambiguous. Ambiguity of reference is inherent in the very act of naming and describing. There is just no way to avoid this fact, no matter how unpalatable you may find it. 

Hi, I have to second that. Good news is our current RDF-based stack
supports that (things can be of many rdf:types), we only need to learn
to work with it (that is the bad news I guess).

IMHO the best way is to think about rdf:type relations as not
identifying a type, but an aspect of a thing. For example lets say there
is a taxi driver Joe. We may feel safe to say that Joe is a taxi driver
and a person and identify both those aspects with one name. However how
shall one interpret statement "Joe expires on 2015-01-01"? Is that a
prediction of Joe's demise or the time Joe's taxi license expiration? Do
not seek further information in the subject or the object, but in the
"expires on" predicate and its rdfs:domain information - the carrier of
the meaning of triples are predicates. My conclusion is we should strive
for not name but rdf property unambiguity.

Jiri

>>> 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.
> 
> If this were true, then the Web would not work. The web does work (after a fashion.) Ergo, this cannot be true.  Unless, of course, by "identifies" you mean something other than 'names' or 'refers to'. 
> 
> Pat Hayes
> 
>>
>> 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.
>>
>>
>>
> 
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973   
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> 
> 
> 
> 
> 
>