Re: Ambiguity (was: Comments on "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs")

On Mar 20, 2011, at 5:10 PM, Graham Klyne wrote:

> It seems to me that the goal here is not so much unambiguity of reference, but reliablility of prediction (or inference).
> 
> My reading of model theory and interpretations, etc., is that by proving that some conclusion holds under all possible satisfying interpretations of an expression, then it must also hold true for some particular satisfying interpretation that one may have in mind all along.
> 
> So, while we as (non-logical) observers may usefully (and incorrectly) believe that some term refers unamibiguously to some thing, the logic may not support this, but ultimately it doesn't matter because the answers that the logic may yield are still correct.

True. 

> 
> (If we were able a priori to prescribe a particular domain of discourse, is it still not possible for logic to constrain terms unambiguously within that domain?)

Yes, it is possible. But the constraints have to come from some common ground of mutual understanding that the participants in the 'conversation' have established. For example, take the integers. Goedel showed that no formal system can fully capture all the truths of arithmetic. But hardly anyone would conclude that decimal notation was therefore ambiguous. We all rely on a robust intuition that we all know what the natural numbers really are, and that our formalisms will never be able to fully capture this Platonic reality. I am quite happy to go along with conventions like this. But to say that URIs refer unambiguously *as an architectural imperative* (as TImBL seems to be saying) is crazy. Surely a fiction cannot be of *architectural* importance. Particularly when the semantic web is rife with cases where two URIs seem upon casual inspection to co-refer and even have owl:sameAs assertions made about them (eg the names of the chemical elements in Cyc and DBPedia) but in fact, when one examines their publishers' definitions, seem that they must refer to different entities. (Cyc says an element is a class of physical objects, DBPedia says they are individuals, not classes; OWL-DL says they must be different.)

> 
> Thus, I think it's a useful fiction to think of the terms as unambiguous (at least in the scope of some discourse), even when this cannot be proven or enforced.

I think it is a dangerous fiction, which leads to unnecessary problems and in any case is obscuring the work that really needs to be done here.

Pat 


> 
> #g
> --
> 
> 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. 
>>>> 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
> 
> 
> 

------------------------------------------------------------
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

Received on Monday, 21 March 2011 19:53:55 UTC