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

See material (non-role) qua individuals for how contexts work. Roles are a
kind of context. So are time bounds.

Jim-qua-hcls-member

On Sunday, March 17, 2013, Alan Ruttenberg wrote:

> Can someone *please* tell me what a context is??
>
> My null hypothesis is that when someone says "context" they either don't
> know what they are talking about, or are too lazy to say. Both these cases
> are deadly for clear communication on the web.
>
> -Alan
>
> On Sun, Mar 17, 2013 at 6:54 PM, Jim McCusker <mccusj@rpi.edu> wrote:
>
> 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
>
>

-- 
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