Re: Managing Co-reference (Was: A Semantic Elephant?)

On 16/05/2008 01:11, "Harry Halpin" <hhalpin@ibiblio.org> wrote:

...
>> I use owl:sameAs to do the former when
>> the properties are all going to be relevant to both, but the two URI's
>> still don't necessarily match a given whole-world OWL structure.
>>
> Trying to get to the practical ramifications of the argument, so feel
> free to help me here if I've misinterpreted thigns. I think the real
> issue here is one again, not of resolving co-reference on some sort of
> "deep" level, but that of when to import descriptions, which on the
> Semantic Web are triples. In essence owl:sameAs is rather strong since
> for URI_1 owl:sameAs URI_2, every triple that  applies to URI_1 must
> also apply to URI_2 and vice versa. So, in essence, all these triples
> must be imported, no?
No.
No more than I need to find out what everyone else in the world understands
by the word "blue" before I can do stuff with it.
So I thought I was going to have a big disagreement about closed world, but
then you go on to say:
>> rdfs:seeAlso has never been a big attraction to me due to its lack of
>> actually saying anything about what you are going to get, possibly due
>> to its colloquial use with FOAF and sending you off to a random foaf
>> file for more information about an, as yet unnamed, entity.
>>
> While rdfs:seeAlso does not have this constraint, i.e. it is just
> another predicate, so it doesn't really state anything. Should it
> followed? Should all triples in seeAlso be added to the graph of an
> agent encountering rdfs:seeAlso? Who knows? It seems "no."
>
> What we seem to want is something like rdfs:seeAlso that forces one to
> import some statements, but not necessarily everything (ala
> owl:sameAs).  Perhaps the real issue is that people want some sort of
> "partial" importing of triples, i.e. a semantics for owl:imports (or
> something similar,). That one can say for URI_1 owl:kindaSameAs URI_2,
> where that means concretely some finite triples that apply to URI_1 also
> apply to URI_2, but not necessarily all . That's usually how humans
> communicate, by sharing "just enough descriptions" to get the job done,
> not necessarily buying everything.  But what would that mean
> implementation-wise? How can one avoid just having to "list" these
> triples and put them in via an owl:imports, but maybe bundle them up in
> some nicer manner?
Yes, I think your analogy with how humans communicate is what we should
learn from.
I happen to like the Chambers dictionary, but am not keen on Webster's, or
even Shorter Oxford (OED is pretty good, but I find Chambers captures
meaning better for me).
What does that mean in the SW?
However, the "forces" makes me uncomfortable again.
Please (as an agent) give me knowledge (about co-reference and other stuff),
and empower me to make the decisions suitable to my situation/context.
I like your use of the word "buying", although I realise you may not have
meant with money. Success in this area may be when I can buy coreference
service from different suppliers for different prices depending on my needs.
Commercial organisations being able to see profit lines in publishing
coreference information would be very exciting, and would suggest our
endeavours had a measure of success.
But if we want to discuss micro-payments for factoids, then we need a new
thread...
>
> Peter Patel-Schneider and Bijan Parsia had a nice paper on owl:imports
> this at IRW2006[2].
>
> Anyways, if any of you are going to be at ESWC2008, remember we'll be
> debating these issues in depth at the IRSW2008 workshop:[3].
>
>                 -harry
>
> [1]http://www.ibiblio.org/hhalpin/homepage/publications/indefenseofambiguity.h
> tml
> (pre-print of article in IJSWIS 4(2) 2008 this year)
> [2]http://www.ibiblio.org/hhalpin/irw2006/bparsia.pdf
> [3]http://www.okkam.org/IRSW2008/
>> Given that you are never sure how someone is going to utilise your OWL
>> structures in future you cannot be held accountable for every
>> statement you make retrospectively, particularly if the dependent
>> vocabularies (or the assumptions of the person utilising the
>> vocabulary) are the cause of the breakage.
>>
>>
>>> Sent from my iPhone
>>>
>>
>> (Cool!)
>>
>> Peter
>>
>>
>
>
>

Received on Friday, 16 May 2008 00:50:55 UTC