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

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

From: David Booth <david@dbooth.org>
Date: Fri, 22 Mar 2013 23:30:09 -0400
Message-ID: <514D21C1.507@dbooth.org>
To: Pat Hayes <phayes@ihmc.us>
CC: Alan Ruttenberg <alanruttenberg@gmail.com>, Jeremy J Carroll <jjc@syapse.com>, Umutcan ŞİMŞEK <s.umutcan@gmail.com>, Kingsley Idehen <kidehen@openlinksw.com>, "public-semweb-lifesci@w3.org" <public-semweb-lifesci@w3.org>
On 03/21/2013 01:02 PM, Pat Hayes wrote:
> On Mar 20, 2013, at 9:58 PM, David Booth wrote:
>> On 03/20/2013 12:04 AM, Pat Hayes wrote:
>>> On Mar 18, 2013, at 4:04 PM, David Booth wrote:
>>>> On 03/17/2013 10:02 PM, Pat Hayes wrote:
>>>>> On Mar 16, 2013, at 11:26 PM, David Booth wrote:
>>>> [ . . . ]
>>>> But presumably that passage from Section 1.2 means ". . .
 >>>> [the semantics simply assumes that ... a single URI reference
 >>>> can be taken to have the same meaning
 >>>> whenever it occurs] _in the *given* graph, i.e., the graph
>>>> whose semantics are being determined_",
>>> No, it means wherever they occur, period. If they occur in
>>> several graphs, they all refer in the same way in all of them.
>> Absolutely not.  That is only true for *one* interpretation.
> Absolutely yes. It is true for all interpretations. There is no
> interpretation which allows a single URI to refer in different ways
> when it occurs in different graphs.

Uh-oh, there's that single-interpretation assumption creeping in again! 
  While it is true that there exists no *single* interpretation that 
allows a single URI to refer in different ways when it occurs in 
different graphs, surely you would agree that under standard RDF Semantics:

   There exist interpretations I1 and I2, RDF graphs G1 and G2,
   URI U and resources R1 and R2, such that I1 maps U to R1,
   I2 maps U to R2, and R1 != R2.

Therefore, under standard RDF Semantics:

   1. A URI can map to *different* resources in *different* graphs.
   (Proof sketch: Use I1 for one graph and I2 for the other.)

   2. A URI can map to *different* resources.
   (Proof sketch: Use different interpretations, I1 and I2.)

Some may claim that this is a misuse of the RDF Semantics -- that there 
really is only one "correct" interpretation, even though we may not know 
which one it is.  (This is the single-interpretation assumption.)  But 
the RDF Semantics makes no such requirement, and to my mind that is part 
of its genius, because the allowance of multiple interpretations is 
valuable!  It lets us better account for the real world use of RDF -- 
**under standard RDF Semantics** -- because in the real world, RDF 
authors *do* make different assumptions in their interpretations of 
URIs, and different RDF consumers *do* apply different interpretations 
to the URIs they encounter.

I have separately tried to point out how the existing RDF Semantics spec 
already supports a poor person's notion of context *because* of its 
allowance of multiple interpretations:

The purpose of a context is to enable the same RDF graph to have 
different truth-values in different contexts.  But this is exactly what 
an interpretation does!  So if you think of an RDF interpretation as a 
context -- which IMO is quite a natural way to think of it -- then 
different RDF graphs can *already* be interpreted in different contexts 
(i.e., according to different RDF interpretations) under the *existing* 
RDF Semantics, because as we have laboriously agreed, **the existing RDF 
Semantics allows different interpretations to be applied to different 
RDF graphs**.

[Actually, to be slightly more technical, in this approach to contexts 
it would be better to view a context as a *set* of interpretations, 
rather than a single interpretation, because it is still useful to talk 
about the set of satisfying interpretations for an RDF graph, subject to 
a particular context.  But that's an unimportant detail at the moment.]

Indeed, people *already* use RDF graphs in this way: intentionally 
keeping graphs separate if they come from different perspectives, 
sources, provenance, etc., *because* the graphs may cause 
inconsistencies or lead to incorrect conclusions if merged 
injudiciously.  Knowingly or not, different interpretations are being 
used for different graphs.

A simple example is Ian Davis's famous toucan-versus-its-web-page example,
in which the same URI "ambiguously" denotes both a toucan and the web 
page describing that toucan.  One RDF graph, Gt, may be written under 
the assumption that the URI denotes the toucan.  Another graph, Gp, may 
be written under the assumption that the URI denotes the toucan's web 
page.  Gt may work perfectly well in an application that merely 
categorizes different animal species -- *unambiguously* interpreting the 
URI as denoting the toucan.  And Gp may work perfectly well in an 
application that merely lists web page authors -- *unambiguously* 
interpreting the URI as denoting the toucan's web page.  In fact, even 
the merge of Gt and Gp may work perfectly well in both applications, 
provided the RDF authors have not asserted that toucans are disjoint 
from web pages!

Applications that consume RDF and faithfully follow the RDF Semantics 
are free to choose their own interpretations, and this is A Good Thing.

On the other hand, an application that needs to distinguish between web 
pages and animal species will find this toucan/webpage URI hopelessly 
ambiguous, and will not be at all happy with the merge of Gt and Gp. 
This is why I have been pointing out (in other conversations) that 
ambiguity is *relative* to the application: a URI may be unambiguous to 
some applications, but ambiguous to others.

But although the existing RDF Semantics does support this simple "poor 
person's" notion of context-as-interpretation (or 
context-as-set-of-interpretations), it does not support other basic 
features that one would expect in a context-aware semantics.  Most 
notably, it does not support the ability to retain contextual 
differences when RDF graphs are merged.  To account for that and a few 
other basic operations, the RDF Semantics would indeed have to be 
extended, as you and a few others have proposed.

[ . . . ]
>>> The semantic rules simply specify when a graph (any graph) is
>>> true in an interpretation (any interpretation). But
>>> interpretations are not defined "on" graphs: they are mappings
>>> from *names* to things. That does not mention graphs at all. So
>>> to then start talking about one graph in one interpretation and
>>> another graph in another interpretation simply misses the point.
>>> The fact that there are many possible interpretations is a
>>> reflection of the fact that we typically are in a state of doubt
>>> about what the names (URIs) actually refer to.
>> That sounds dangerously close to falling into the trap of assuming
>> that there really is only one, global, correct interpretation.  And
>> it is *my* interpretation, of course.  ;)
> It is not anyone's interpretation: it is the fact of the matter. Of
> course, we don't have access to the facts, only our representations
> of them, which allow many interpretations.

I don't see how this "fact of the matter" has any relevance, since: (a) 
the RDF Semantics says nothing about it; and (b) it is an application's 
own business what interpretations it chooses to use.  If that 
application causes some harm by applying the wrong interpretation, then 
the owner may be liable, but that is an entirely separate issue from the 
question of compliance with the RDF Semantics.

Received on Saturday, 23 March 2013 03:30:37 UTC

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