Re: summary so far.

On Mar 4, 2011, at 2:40 PM, David Booth wrote:

> On Wed, 2011-03-02 at 12:28 -0600, Pat Hayes wrote:
>> On Mar 2, 2011, at 11:30 AM, Nathan wrote:
>> 
>>> Jonathan Rees wrote:
> [ . . . ]
>>>> On Wed, Mar 2, 2011 at 5:49 AM, Nathan <nathan@webr3.org> wrote:
>>>>> Jonathan Rees wrote:
>>>>> now this is interesting, and I'm unsure exactly how to say it, but if we
>>>>> work from HTTP Resource upwards to URI, such that we consider an HTTP
>>>>> Resource as being a distinct object for which all URIs used to refer to it
>>>>> are bound to that HTTP Resource (the URIs are a property of the HTTP
>>>>> Resource), then we come to the wrong conclusions, and things break.
>>>> No. Only TimBL's requirement that these be distinct breaks. (Maybe
>>>> that's what you mean by "things" but you need to be more specific.)
>>> 
>>> and RDF's requirement, in fact URIs is it not, that two different
>> URIs refer to two different things unless explicitly stated that they
>> refer to the same thing?
>> 
>> No. RDF (and RDFS, OWL etc.) make no assumptions about unique naming.
>> Any two different URIs might or might not refer to the same thing. 
> 
> I hope this doesn't cause confusion, because the bottom line
> semantically is what Pat and Jonathan said.  But . . .
> 
> In practice almost everyone makes some degree of unique naming
> assumption at one point or another.  After all, when you merge two
> graphs containing bnodes, and you try to collapse some of those bnodes,
> but you *don't* try to collapse other URIs, then you're effectively
> making a kind of unique name assumption on the other URIs.

Delicate point. Not really. What you are being is name-agnostic. The different names *might* co-refer, but they *might* not. If we merge them, we are assuming that they co-refer (and erasing any trace which would enable someone to correct us if we are wrong), so the only safe thing to do is not merge them. This is OK if they don't co-refer, and still OK if they do, because someone might put an owl:sameAs link from one to the other.  You might call this a unique name bias. But this is not really making a unique name assumption (UNA). The UNA amounts to concluding that two distinct names cannot *possibly* co-refer just *because* the names are different. You might capture the force of the UNA if you were to say that all owl:sameAs assertions or links between different URIs were at one stroke declared to be errors, for example. 

My esteemed friend Bill Andersen, who Im CCing on this reply, has a system which uses what one might call a flexible UNA. It assumes that two different names do not co-refer, ie the UNA applies, as a kind of working hypothesis or default assumption.  But if you tell it that two of them do, or if it discovers a sameAs for itself, then instead of protesting or declaring an error or an inconsistency, it just chooses one of the names and substitutes for the other one throughout its (enormous) database, thereby 'repairing' the Kbase and restoring the UNA property once more. Although this is not sanctioned by any textbook logical system, it seems to be the most rational approach to handling vast amounts of information like the Web, where if you choose two names at random, the odds are that they name different things; but still, co-reference is undoubtedly possible. 

However, it is non-monotonic, which is a problem.

Pat


>  Or when you
> mint your own URIs that you use within a graph, but you then merge in
> some other RDF data from some other source -- say DBpedia -- and you try
> to collapse some of the DBpedia URIs into your own URIs, but you do
> *not* bother to try to collapse your own URIs into other of your own
> URIs, then you are again making a kind of unique name assumption on your
> own URIs: you knew that they represented distinct entities when you
> minted them, so you didn't bother trying to collapse them.
> 
> Another way to put it is to say that in practice, applications
> internally make the unique name assumption unless they have evidence (or
> are told) that they can merge nodes.
> 
> Anyway, if this comment causes confusion, just ignore it.  The semantics
> are what Pat and Jonathan said.
> 
> 
> 
> -- 
> 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

Received on Friday, 4 March 2011 22:16:18 UTC