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

Re: RDF Concepts - IRIs do *not* always denote the same resource (ISSUE-148)

From: Guus Schreiber <guus.schreiber@vu.nl>
Date: Wed, 2 Oct 2013 13:23:45 +0200
Message-ID: <524C0241.8010507@vu.nl>
To: David Booth <david@dbooth.org>
CC: public-rdf-comments <public-rdf-comments@w3.org>
Dear David,

Thanks for your comment. We have raised an issue for tracking your 
comment [1]. We will get back to you on this.

Best,
Guus, on behalf of the RDF WG

[1] https://www.w3.org/2011/rdf-wg/track/issues/148

On 02-10-13 07:05, David Booth wrote:
> 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.
>
> An IRI can and often does denote different resources in different
> *interpretations*.  And this, in practice, means that an IRI often
> denotes different resources in different *graphs*, because any graph has
> a set of satisfying interpretations, and different graphs may have
> different sets of satisfying interpretations.  For example, suppose
> graphs g1 and g2 have sets of satisfying interpretations s1 and s2,
> respectively, and those sets may be disjoint.  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).
>
> 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.
>
> 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 (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.
>
> 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.
>
> 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.
>   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.   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 -- and that is useful to know
> also, because it means that Alice and Bob's graphs **cannot be used
> together**.
>
> 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.  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.
>
> 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
>
Received on Wednesday, 2 October 2013 11:24:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:58 UTC