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

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

From: Andrea Splendiani <andrea.splendiani@deri.org>
Date: Sun, 17 Mar 2013 14:05:56 +0000
Cc: (wrong string) žİMžEK <s.umutcan@gmail.com>, Kingsley Idehen <kidehen@openlinksw.com>, "w3c semweb HCLS" <public-semweb-lifesci@w3.org>
Message-Id: <5F842204-8C02-4A89-B776-FADF8A8FCD5D@deri.org>
To: Jim McCusker <mccusj@rpi.edu>
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, 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.
Received on Sunday, 17 March 2013 14:06:22 UTC

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