W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2013

Re: RDF-ISSUE-148: LC Comment: IRIs do *not* always denote the same resource [RDF Concepts]

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 3 Oct 2013 03:36:24 -0500
Message-Id: <2D88DF6A-CF2F-4AA3-8CD6-031E7156BA54@ihmc.us>
To: RDF Working Group <public-rdf-wg@w3.org>
This issue requires a more careful response than the others. Here is my initial 2c to what is likely to be a slightly extended process. 


On Oct 2, 2013, at 5:43 AM, RDF Working Group Issue Tracker wrote:

> RDF-ISSUE-148: LC Comment: IRIs do *not* always denote the same resource [RDF Concepts]
> 
> http://www.w3.org/2011/rdf-wg/track/issues/148
> 
> Raised by: Guus Schreiber
> On product: RDF Concepts
> 
> LC Comment  by David Booth
> http://lists.w3.org/Archives/Public/public-rdf-comments/2013Oct/0008.html
> 
> In https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html
> I see this statement:
> 
>   "IRIs have global scope: Two different appearances of an IRI
>   denote the same resource."
> 
> This is wrong.  If it were true then there could never be a URI Collision
> http://www.w3.org/TR/webarch/#URI-collision
> and there would be no point in the AWWW discussing it or admonishing 
> against it.

First, the AWWW is talking about identification rather than denotation, although it does use the "denote" language at one point. But I don't expect David to buy this, given his other comments. So, second, the point is that even if this can happen in the real world, it is a pathological situation, and produces errors and confusions, and standards are designed to prevent it happening. So for example, one way one might detect a URI collision might be to discover a formal inconsistency between two pieces of RDF, each using the same IRI to mean different things and therefore making mutually inconsistent statements. BUT....

> 
> An IRI can and often does denote different resources in different 
> *interpretations*.

THAT is irrelevant to the point being made just previously. 

>  And this, in practice, means that an IRI often 
> denotes different resources in different *graphs*

No, it does not mean that. In fact, that usage "denote...in different graphs" is meaningless. The phrase "denote in a graph" is not used anywhere in the RDF specification nor in any other literature on related topics, such as logical textbooks on semantics. Denotation is defined relative to an interpretation, not relative to a graph or a sentence. 

> , because any graph has 
> a set of satisfying interpretations, and different graphs may have 
> different sets of satisfying interpretations.

That is true, of course, but it does not have the consequence that David seems to be claiming that it has. 

>  For example, suppose 
> graphs g1 and g2 have sets of satisfying interpretations s1 and s2, 
> respectively, and those sets may be disjoint.

So that g1 and g2 are together unsatisfiable, ie no interpretation makes them both true. 

>  Then colloquially (and 
> technically) we can say that an IRI may map to one resource in g1 (i.e., 
> in some interpretation in s1) and a different resource in g2 (i.e., in 
> some interpretation in s2).

No, we may not. Technically, the IRI will typically map to a different resource in each different interpretation (not each graph), and may map to different resources in the various interpretations which satisfy the graph, so the locution "map to a resource in a graph" is meaningless. Colloquially, the only way to make sense of this kind of a case is to speak of what we can infer from assuming that a graph is true, ie that the actual world or situation is one of those which satisfy the graph. 

> 
> This requires thinking about graphs in terms of sets of satisfying 
> interpretations -- an important and valid perspective -- rather than 
> assuming that one looks at them only through the lens of a single 
> interpretation.

This is just confused. Of course we think about graphs in terms of the sets of interpretations which satisfy them. That is what model-theoretic semantics is about. 

> 
> As a simple example of how a URI can denote different things in 
> different graphs, suppose Alice sends this graph G1 from her smart phone 
> to her home computer to turn *on* her porch light

First, note in passing that this is not a typical or intended use of RDF, to be a command or scripting language for devices. But in any case:

> (assuming the usual 
> URI prefix definitions):
> 
> G1: {  @prefix db: <http://dbooth.org/>
>        ex:alicePorchLight rdf:value db:x .
>        db:x owl:sameAs ex:on .
>        ex:on owl:differentFrom ex:off . }
> 
> and her light turns on.

Why would that be? According to the RDF semantics, this is an assertion about the state of the light. Why would that make the light come on? (Does the light have a desire to make any RDF it sees be true, maybe?) 

But in case, we can say that in all interpretations which satisfy G1, db:x and ex:on co-refer but ex:on and ex:off don't. Which I think is the point. 

> 
> In contrast, Bob sends this graph G2 from his smart phone to his home 
> computer to turn *off* his oven:
> 
> G2: {  ex:bobOven rdf:value db:x .
>        db:x owl:sameAs ex:off .
>        ex:on owl:differentFrom ex:off . }
> 
> and his oven turns off.

In all interpretations which satisfy G2, db:x and ex:off co-refer, but ex:on and ex:off don't. 

> 
> It is perfectly reasonable and natural to ask "What resource does db:x 
> denote in G1?", and it is reasonable and natural to ask the same of G2. 

It is incorrect (and meaningless) to ask this question as posed. The way it is worded here is confused, and invites a confused answer. 

>  The RDF Semantics (along with OWL) tells us that in G1 db:x denotes 
> whatever ex:on denotes, whereas in G2 db:x denotes whatever ex:off 
> denotes.

No, it does not. What RDF and OWL tell us is, that any interpretation which satisfies G1 will not satisfy G2, and vice versa. So no interpretation satisfies both of them. So they are inconsistent. 

>   That is useful!  Furthermore, the semantics tells us that if 
> we merge those graphs then we have a contradiction -- there are no 
> satisfying interpretations for the merge

Yes, it tells us that, indeed. 

> -- and that is useful to know 
> also, because it means that Alice and Bob's graphs **cannot be used 
> together**.

Well, they are inconsistent. Maybe you have some way to handle inconsistency. But OK, the point is taken. 

> 
> Furthermore, the RDF Semantics notion of an interpretation maps well to 
> real life applications: in effect, an application chooses a particular 
> interpretation when it processes RDF data.

I have no idea what this even means. I suspect it is meaningless. 

>  This is a very useful aspect 
> of the model theoretic style of the semantics.  In this example, Alice's 
> home control app interpreted db:x to denote "on" and Bob's home control 
> app interpreted it to denote "off".  And *both* were correct (in 
> isolation): they both did The Right Thing.

No, they were not both correct. Their doing the "right thing" in this inappropriate scenario is irrelevant. If they were both published as data on the open web, then the inconsistency would be rapidly clear to basic RDF/OWL engines. And such open publication is the intended use case for RDF, not private, idiosyncratic uses in point-to-point command transactions. 

OK, thats my initial 2c.

Pat

> 
> In short, I think the above statement needs to be qualified somehow, 
> such as:
> 
>   "IRIs are *intended* to have global scope: Two different
>   appearances of an IRI are *intended* to denote the same resource."
>   (However, the RDF Semantics explains how an IRI may denote
>   different resources in different interpretations.)
> 
> David
> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 home
40 South Alcaniz St.            (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile (preferred)
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Thursday, 3 October 2013 08:36:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:33 UTC