- From: Jim McCusker <mccusj@rpi.edu>
- Date: Sun, 17 Mar 2013 18:54:27 -0400
- To: Andrea Splendiani <andrea.splendiani@deri.org>
- Cc: David Booth <david@dbooth.org>, Jeremy J Carroll <jjc@syapse.com>, Umutcan ŞİMŞEK <s.umutcan@gmail.com>, Kingsley Idehen <kidehen@openlinksw.com>, w3c semweb HCLS <public-semweb-lifesci@w3.org>
- Message-ID: <CAAtgn=SdX370OdYBoZFURink2TzrtDeMexShFidNKHj6m15xeA@mail.gmail.com>
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. Jim 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 http://krauthammerlab.med.yale.edu PhD Student Tetherless World Constellation Rensselaer Polytechnic Institute mccusj@cs.rpi.edu http://tw.rpi.edu
Received on Sunday, 17 March 2013 22:55:11 UTC