Re: summary so far.

Pat Hayes wrote:
> 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. 

This appears to be what the tabulator does as well "smushing"

Received on Saturday, 5 March 2011 13:11:48 UTC