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

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

From: Peter Ansell <ansell.peter@gmail.com>
Date: Sun, 17 Mar 2013 19:41:33 +1000
Message-ID: <CAGYFOCS9wd9URTwdmW3WoiCP39dLC97v_65MUetpQHqA-sgrFA@mail.gmail.com>
To: Jim McCusker <mccusj@rpi.edu>
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>
On 17 March 2013 14:34, Jim McCusker <mccusj@rpi.edu> wrote:
> 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).

The devil is always in the detail of course... "kind of" needs to be
good enough for scientists while they iterate over the possible

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

If you know every statement currently about a resource is consistent
with your desired meaning you would be insane to create a new URI for
everything to attach your statements to it, just incase the other URI
is ever used in a different way. You could go so far as to say that
every new non-trivial statement using the URI after you use it could
in some way affect your choice to use use the URI, and you would have
no control over the way the interpretation is used, if there is only
one Giant Global RDF Graph.

Scientists reuse current knowledge as much as possible, and this is
reflected in their ambivalence about the exact truth of everything
they ever say. This includes the option to completely revoke the truth
of past statements, without deleting the statements from the
scientific record. Having a strict segregation of statements based on
who makes the statement, as you envisage, will not fix the ultimate
dilemna that a scientist may need to reference a past statement
without deleting it, in order to contrast the points of view that gave
the statements context.

Even if every scientist assigned new URIs to everything (just incase)
and they never changed their mind about the essential meaning of their
RDF statements, and hence their altOf/specOf assertions were always
consistent as the knowledge matures over time, they may still have the
issue that they agree with everything except anothers altOf/specOf
statements. They may need to utilise all of anothers knowledge about
their URI, but assign a different merging algorithm to combine your
knowledge with theirs (which, since the SPARQL workgroup rejected the
idea that users could intelligently specify algorithms for DESCRIBE,
is a non-trivial task).

If one agrees that statements can be accepted, rejected, or filtered,
based on the context (ie, RDF graph) that they were asserted in, then
the resolutions to the various ambigutities are failry simple, and may
be less likely to occur than we make out here. As long as users can
reuse merging algorithms easily, then they may be able to define rules
based on the origins of RDF Quads (even though we only currently deal
with Triples in most cases). One benefit of that strategy is that
users do not always have to create new URIs and assert specific,
non-completely-owl-sameas-equivalency to every other similar URI, as
they are partially insulated from the effects of other statements by
the plausible deniability that they agreed with something which they
did not assert.

In cases where they are clearly sure that they do not want to reuse a
URI, altOf and specOf are great and would make it very easy to specify
merging algorithms. The real complexity with them only comes when you
also need to specify the other 2 ( or more) common contextual layers
defined by provenance experts.


Received on Sunday, 17 March 2013 09:41:59 UTC

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