W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > March 2013

Re: owl:sameAs - Is it used in a right way?

From: Jim McCusker <mccusj@rpi.edu>
Date: Sun, 17 Mar 2013 18:54:27 -0400
Message-ID: <CAAtgn=SdX370OdYBoZFURink2TzrtDeMexShFidNKHj6m15xeA@mail.gmail.com>
To: Andrea Splendiani <andrea.splendiani@deri.org>
Cc: (wrong string) žİMžEK <s.umutcan@gmail.com>, Kingsley Idehen <kidehen@openlinksw.com>, w3c semweb HCLS <public-semweb-lifesci@w3.org>
If you want to use a common context, use the same URI, but if you don't,
then don't. I have a paper in submission to ICBO about aggregating facts
from specializations, I won't go into details but I can send it along if
anyone's interested.


On Sun, Mar 17, 2013 at 10:05 AM, Andrea Splendiani <
andrea.splendiani@deri.org> wrote:

> HI,
> From what you say, it looks more as if the apple is the same, but
> perspective on the apple are different. So same URI and different graphs
> seem a more clean approach.
> Using different URIs works as well in practice. But I'm a bit confused on
> how you make the generalization step. Who is saying that my apple and your
> apple are all narrower than a generic apple ? (we need this step if we
> don't want an autistic web). Again, it probably depends on a context, which
> leads to having graphs expressing contexts anyway.
> Or how do you reconcile different URIs from different understanding of the
> same thing ?
> Also, it looks to me that it's easy to have a URI explosion, if we choose
> different URIs to identify different perspectives on the same thing.
> Say we have a URI for a person, and to talk about this person when young
> and when old we use two different URIs. But than, when do we stop ? What if
> we have a URI per year ? Per day ? ...
> best,
> Andrea
> Il giorno 17/mar/2013, alle ore 04:34, Jim McCusker <mccusj@rpi.edu>
>  ha scritto:
> Hmm. In the end, all three of them are talking about the same apple.
> Either a) the apple changed (they do that), or b) someone got it wrong (Is
> a McIntosh a red apple or green apple? It's kind of both).
> This of course goes to my general assertion that most of the time,
> disjointness assertions are more likely to be wrong than right, but this
> isn't about that. There is an apple, and all three people agree they are
> talking about the same apple. It may have changed, or someone was color
> blind, or looking at a colorized black and white photo when they decided
> what color it was. This is, more than anything, why, unless you know that
> the referent is that same AND the contextual scope is the same, it's better
> to mint your own URI and link out using altOf and specOf, rather than
> making assertions using someone else's resource.
> Jim
> On Sun, Mar 17, 2013 at 12:20 AM, David Booth <david@dbooth.org> wrote:
>> Hi Jim,
>> On 03/16/2013 12:37 PM, Jim McCusker wrote:
>>> I'm not terribly interested in a Humpty Dumpty interpretation of the web
>>> of data.
>> Well, you'd better get used to it, because that interpretation is
>> standard RDF Semantics.  I don't think it's going away any time soon.
>>  That's part of the motivation for having global identifiers
>>> like URIs/URLs.
>> Exactly!  That's why the idea that "a URI identifies one resource" is "a
>> good goal, and helpful as a guide to URI users", even though it is not
>> actually true.
>>  There's no point in merging ANY graphs under this view,
>>> since you have no way of knowing if the referents are the same.
>> Not true!  Don't throw the baby out with the bath.  When you merge
>> graphs, you force the referents to be the same.  Sometimes the merge works
>> fine, and sometimes the merge becomes inconsistent.  Just because you
>> cannot *always* merge two graphs without causing inconsistency does not
>> mean that merging is pointless.  It just means that *some* graphs can be
>> merged and others cannot.  That is only a problem if your expectations of
>> being able to merge any two graphs are set unrealistically high.
>>  I'm not
>>> saying that people don't denote different things with the same URI, I'm
>>> saying that, by using a URI that someone else controls, you are
>>> accepting their denotation of it.
>> You're preaching to the choir on that one!  I certainly agree with that
>> architecture, but that is only part of the story.  The problem is that
>> there is inherent ambiguity about the resource that a URI denotes.  This is
>> inescapable.  And it means that two different, well-intentioned RDF authors
>> can reasonably interpret a URI's resource identity differently, and those
>> differences can cause conflicts to show up when their graphs are merged.
>> As a simple example, suppose Owen, a URI owner, mints a URI :apple to
>> denote an apple.  As the URI's owner, he defines the URI's resource
>> identity using the following RDF statements:
>>   # Owen's definition of :apple
>>   @prefix : <http://example/owen/> .
>>   :apple a :Apple .
>> Arthur, a URI author, then publishes his own RDF statements about Owen's
>> apple (standard prefix definitions omitted for brevity):
>>   # Arthur's statements about Owen's apple
>>   @prefix : <http://example/owen/> .
>>   :apple a :GreenApple .
>>   :GreenApple rdfs:subClassOf :Apple .
>> Note that Arthur's statements are entirely consistent with Owen's
>> definition of :apple .
>> Now Aster, another URI author, also publishes some RDF statements about
>> Owen's apple.  She also uses Owen's apple definition, but has no knowledge
>> of Arthur's statements.  Aster writes:
>>   # Aster's statements about Owen's apple
>>   @prefix : <http://example/owen/> .
>>   :apple a :RedApple .
>>   :RedApple rdfs:subClassOf :Apple .
>>   :RedApple owl:disjointWith :GreenApple .
>> Note that Aster's statements are also consistent with Owen's definition
>> of :apple.
>> Finally, Connie, an RDF consumer, discovers Arthur and Aster's graphs and
>> wishes to merge them.  Unfortunately, the merge is inconsistent,
>> It is tempting to assume that someone did something "wrong" here.  For
>> example, one might claim that Owen's definition was ambiguous, or that
>> Arthur and Aster should not have made assumptions about the color of Owen's
>> apple if Owen did not state the color in his definition.  Indeed, in this
>> simple example it is easy to see where the conflicting assumptions crept
>> in.  In real life, when you're dealing with thousands or millions of RDF
>> statements, it is usually far more subtle.
>> One might also assume that color is an intrinsic property of the apple,
>> and hence is somehow different from other properties that one might assert.
>>  Imagine instead that Arthur had stated ":apple a :GoodFruit" and Aster had
>> stated ":apple a :BadFruit" (assuming :GoodFruit owl:disjointWith
>> :BadFruit).  The result would have been the same when Connie attempted to
>> merge their graphs.  Since, AFAIK, there is no objective way to distinguish
>> between intrinsic properties and non-intrinsic properties, the color
>> example should suffice.
>> The real problem is that *any* time you make an RDF statement about a
>> resource, and that statement goes beyond what was said in the resource
>> definition, you further constrain the identity of that resource, whether
>> you mean to or not.  I.e., you further constrain the set of satisfying
>> interpretations.
>> I submit that neither Owen nor Arthur nor Aster did anything
>> fundamentally wrong.  Owen was not wrong, because it is fundamentally
>> impossible for Owen to be completely unambiguous about :apple's resource
>> identity.  And Arthur and Aster did nothing fundamentally wrong, because:
>> (a) they simply made statements about :apple ; and (b) AFAICT there is no
>> fundamental difference between statements that constrain a resource's
>> identity and any other statements about that resource.  In RDF semantics,
>> they all simply add constraints to the possible interpretations.
>> The problem is just that Arthur and Aster happened to (unknowingly) make
>> conflicting statements about :apple .  There's no need to cry foul here.
>>  We just have to learn to live with this possibility.  And one good
>> technique is what Jeremy suggested: keep different perspectives in
>> different graphs, and only join them if you need to.
>> David
> --
> Jim McCusker
> Programmer Analyst
> Krauthammer Lab, Pathology Informatics
> Yale School of Medicine
> james.mccusker@yale.edu | (203) 785-4436
> http://krauthammerlab.med.yale.edu
> PhD Student
> Tetherless World Constellation
> Rensselaer Polytechnic Institute
> mccusj@cs.rpi.edu
> http://tw.rpi.edu
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
> we believe but do not warrant that this e-mail and any attachments thereto
> do not contain any viruses. However, you are fully responsible for
> performing any virus scanning.

Jim McCusker
Programmer Analyst
Krauthammer Lab, Pathology Informatics
Yale School of Medicine
james.mccusker@yale.edu | (203) 785-4436

PhD Student
Tetherless World Constellation
Rensselaer Polytechnic Institute
Received on Sunday, 17 March 2013 22:55:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:01 UTC