RE: sameAs - Is it used in a right way?

Alan,

 

In this example, the referent and the context is still the same – it’s the relationship between you and Danny defining him as your Dad although you may have a different view of him as a 10-year old and now; I think this example is tangential to the problem of the URI for Dad.

 

Independently, I think this is a very good discussion to have, and there is reason for seeing all viewpoints to this as it had caused a lot of confusion in the past, and, clearly, still is something we all have opinions on based on our experiences working with different datasets where the lines sometimes are blurred.

Cordially, as always,

 

Erich

 

From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com] 
Sent: Saturday, March 16, 2013 9:51 PM
To: Erich Gombocz
Cc: Jim McCusker; David Booth; Jeremy J Carroll; Umutcan ŞİMŞEK; Kingsley Idehen; w3c semweb HCLS
Subject: owl:sameAs - Is it used in a right way?

 

My dad's name is Danny. I've known him a Long time, during which he's changed a lot. Am I supposed to stop calling him dad because he's not precisely the same as he was when I was 10?

-Alan


On Sunday, March 17, 2013, Erich Gombocz wrote:

Observing this discussions for quite a while, I have to say that I fully agree with Jim’s comments - unless you can assert that the referent is the same AND the contextual scope is the same, it should not have the same URI as it does not precisely describe the same thing.

 

Cordially,

Erich

 

From: Jim McCusker [mailto:mccusj@rpi.edu] 
Sent: Saturday, March 16, 2013 9:35 PM
To: David Booth
Cc: Jeremy J Carroll; Umutcan ŞİMŞEK; Kingsley Idehen; w3c semweb HCLS
Subject: Re: owl:sameAs - Is it used in a right way?

 

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 definiti