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

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

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 21 Mar 2013 12:02:35 -0500
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>
Message-Id: <A9D3AC18-ED37-4016-87C8-D56A8A9ABDE5@ihmc.us>
To: David Booth <david@dbooth.org>

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:
> [ . . . ]
>>>>> Read the spec: http://www.w3.org/TR/rdf-mt/
>>>> Indeed. Section 1.2, first paragraph: "... the semantics simply
>>>> assumes that ... a single URI reference can be taken to have the
>>>> same meaning wherever it occurs. Similarly, the semantics has no
>>>> special provision for tracking temporal changes. It assumes,
>>>> implicitly, that URI references have the same meaning whenever
>>>> they occur."
> [ . . .]
>>> But presumably that passage from Section 1.2 means ". . . whenever
>>> they occur _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. 

>  But as you clearly admit below, "there can be many of these interpretations", and each interpretation could map the URI to a *different* resource.

Each interpretation can map the URI to a different resource, yes. But interpretations apply across all graphs. No interpretation maps two occurences of the same URi, in different graphs, to different resources. There are many interpretations, but each of them is a total mapping **on names**. Just names, not occurrences of names in graphs, or names in a context.  So the very definition of an interpretation embodies the presumption that each name denotes something, and that this name-denoting applies to *all* occurences of that name, in *every* graph. And that is true for *all* interpretations. 

> Thus, to be very clear, under the existing RDF Semantics specification, a given URI does *not* necessarily map to only one resource.

True, but you keep confusing two questions. 
1. Can a given URI denote different things, in different interpretations? Yes.
2. Can two occurrences of a single URI denote different things? No. No interpretation of RDF allows this. Reference is not graph-dependent.

> So, returning to my point made many messages ago, the idea that a URI denotes only one resource is a good architectural goal, but it is *not* required under existing RDF Semantics.
> It is important that we avoid slipping into the trap of assuming that there is only one interpretation.

I assure you, I am not slipping into that trap. But if something is true in all interpretations, then it is simply true. And it is true in all interpretations, that a given URI - all occurrences, all tokens, of that URI - denote one thing in that interpretation, What the one thing is might vary from one interpretation to another, but that there is only one thing does not. URIs cannot simultaneously denote more than one thing, in *any* interpretation. 

> [The rest of my response is mostly nitpicking, so readers who only want to read the main point may safely stop reading here.]
>>> since the spec would be meaningless if it were predicated on the
>>> assumption that a URI always has the same meaning everywhere:
>> It had better not be, as it is predicated upon that assumption :-)
>>> 1. If a URI always denoted the same resource then there would be no
>>> need in the RDF Semantics for multiple interpretations that map URI
>>> references to different resources, because every interpretation
>>> would necessarily map a URI to the exact same resource.
>> No. Lets make sure we are speaking very carefully here. An
>> interpretation is a mapping from names (URIrefs - now called IRIs -
>> and literals) to things in a universe. Each such mapping is from the
>> names to what they are being interpreted, in this interpretation, to
>> name. (In the RDF 1.1 spec just being written, by the way, every
>> interpretation mapping is a mapping on *all* names, not just a
>> 'vocabulary V' of names.) So each interpretaton is a decision about
>> what the names mean.
>> But of course there can be many of these interpretations.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Exactly.
>> One of them
>> might map "ex:PatHayes" to me, considered as a continuant, and
>> another might map it to the number 37.5, and yet another to my cat's
>> right front paw. But each of the many (maybe uncountably many)
>> interpretation mappings maps each *name* to some thing, and it
>> applies to *all occurrences* of that name. There is no such thing as
>> an RDF interpretation which maps an URI in one graph to one thing and
>> the same URI in a different graph to something else.
>>> The RDF Semantics would need only one, unique  global mapping!  But
>>> as we know (and Section 1.3 states): "there is no such thing as
>>> 'the' unique interpretation of an RDF graph".  Presumably these
>>> non-unique interpretations can and do map the same URI to different
>>> resources, do they not?
>> DIfferent interpretations map the same URI to different resources,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Ah-ha!  The smoking gun!  :)

The fact that you consider this to be in support of your thesis suggests to me that you have not actually fully understood how model theory works.

>> yes. But each interpretation fixes that resource for each URI, and it
>> applies to every occurrence of the URI.
> Yes, exactly.

But this is exactly what you are denying. 

>>> 2. As we know, a false assumption entails everything.  If I were a
>>> drug dealer, I could one week declare to my co-conspirators that
>>> this week, http://dbooth.org/x means heroin, and next week it means
>>> morphine.
>> True, but you and your evil henchmen would then be using RDF in a
>> noncompliant way which does not fit with the normative specs. (People
>> do do such things, of course; but specifications do not cease to be
>> normative when people fail to conform to them.)
>>> In which case, that URI clearly would *not* have the same meaning
>>> whenever it occurs.  So if the RDF Semantics were predicated on the
>>> false assumption that it does, the RDF Semantics would be
>>> meaningless.
>> No, it would have the consequence that if someone were to follow the
>> RDF specs in this case, they would get into trouble. That often
>> happens to people who believe the specs and try to act on them, when
>> other people don't follow the specs. Still, that distasteful fact
>> about the dirty real world does not make normative specifications
>> meaningless.
>>> In short, I can only see how the RDF Semantics could possibly make
>>> sense if the idea that "URI references have the same meaning
>>> whenever they occur" is talking about a *single* interpretation.
>> Yes, it is talking about a single **interpretation**. See above.
>> Whatever each URI means - we might not know what it means, hence the
>> need to consider alternative interpretations, but whatever it
>> actually means - every occurrence of it means that. It means what it
>> means globally.
>>> Have I completely misunderstood something fundamental here?
>> Possibly. I'm not sure. Do my answers make sense to you?
> They do make sense.   You have confirmed my previous understanding of the RDF Semantics.
>>>>> The RDF semantics is only defined for a *given* RDF graph.  It
>>>>> does not constrain a URI's resource identity across *different*
>>>>> graphs.
>>>> No, it does so constrain what URIs mean.  It presumes that a
>>>> given URI denotes some single thing, wherever it occurs. The
>>>> interpretation mappings are defined as mappings upon URIs. not
>>>> upon occurences of a URI token in a particular graph; and the
>>>> semantics does not mention contexts or any other mechanism which
>>>> would allow a URI in one place to denote differently from the
>>>> same URI in another place (or at another time, cf the above
>>>> quote.)
>>> The RDF Semantics spec defines a procedure
>> Well, not actually a *procedure*. It is not required to be
>> computable. But OK, leave that aside for now...
>>> that is *parameterized* by a given interpretation (called "I"), and
>>> a given RDF graph or piece thereof (called "E").
>> No, it defines an interpretation mapping and explains how to *apply*
>> that mapping to a graph E.
> It certainly does *not* define interpretation I.  "I" can be *any* interpretation.  It is universally quantified.
> If I say "For any dog D, if D is black then D is a poodle", that does *not* define D.

Sorry. It defines what an interpretation mapping is, I should have said. 

>> E is an argument, not a parameter.
> Uh . . . no.  Perhaps we have a clash of terminology here, between mathematicians and computer scientists, but please look up the difference between "parameter" and "argument":
> http://en.wikipedia.org/wiki/Parameter_%28computer_programming%29#Parameters_and_arguments
> The two terms are often used interchangeably, but (at least in computer science) if a distinction is made, E would be called a *parameter* -- not an argument. Perhaps it's different in mathematics?  Clearer terms are "formal parameter" and "actual parameter", in which case "E" is the formal parameter.  An actual parameter would be a piece of RDF syntax, such as a URI, triple or graph.

'E' is, I guess, a parameter of the definition you cited. E is an argument of the interpretation function, in that definition. 

>>> The spec is riddled with references to those parameters, and
>>> semantic rules are written in terms of them.  A typical example
>>> from Section 1.4 reads:
>>> "if E is a ground RDF graph then I(E) = false if I(E') = false for
>>> some triple E' in E, otherwise I(E) =true."
>>> How could this procedure possibly define the semantics of a graph
>>> that it has not been given -- i.e., a graph that is not E?
>> E can be *any* ground graph. The symbol "E" in this text is not the
>> name of a particular graph, it is a universally quantified varaible
>> ranging over all ground graphs. ALL of them.
>>> Of course one may choose any graph to consider, so any graph *may*
>>> be considered E, in which case the procedure tells you the
>>> semantics *of* *that* *graph*.
>> Yes, exactly.
>>> But AFAICT, there is no way around *first* deciding what RDF graph
>>> and interpretation you wish to consider, and *then* the procedure
>>> defined in the RDF Semantics will tell you the truth value of
>>> *that* graph relative to *that* interpretation.
>> This is mathematics, not an algorithm. There is no first/then
>> involved.
>>> AFAICT, it says nothing about any other RDF graph that is not under
>>> consideration.
>> It says something about all (ground) graphs, and it does not mention
>> being "under consideration", whatever that means.
>>> I see no requirement in the RDF Semantics that interpretation "I"
>>> be the *same* interpretation for every graph "E" to which this
>>> procedure is applied.
>> There is none, of course. The semantic definitions you are citing
>> here apply to all interpretations and all graphs. (I really don't
>> understand what point you are making here, to be honest.)
> The point that I attempted to make was that a URI *can* and often *does* denote different resources, in full conformance with the current RDF Semantics specification.  As we have now so laboriously agreed, the RDF Semantics only requires that a URI always map to the same resource within a *single* interpretation.  But it permits many interpretations.  Ergo my point.

But that is not the point that you keep making. You apparently want a (single) URI to have a meaning which depends upon the *graph* it is in: it means (refers to) one thing in this graph and a different thing in that graph. That is not the point you have agreed to above. One URI can mean many things, of course: but that statement is about *all occurrences* of the actual URI. It is not saying that one occurrence can have one meaning and a different occurrence, in a different graph, can have a different meaning. And you need the latter to get "context" effects. 

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

>> But we are not in doubt that they do actually, or
>> are intended to actually, refer to something, and that **what they
>> refer to is not dependent on where they occur**: a given URI in one
>> graph refers to the same thing as it does in another graph, which is
>> why we can glean RDF from many sources and mash it together to draw
>> inferences.
> Except that we can't.  Because in reality, what those URIs refer to *does* sometimes depend on where they occur, since people with different perspectives *do* make different assumptions in different graphs.

That second point does not imply the first. People make different assumptions about what the URI denotes, yes. But the fact that it is the same URI, means that it is the same thing they are making those assumptions about, and which licences an RDF reasoner to put their assumptions (graphs) together to draw conclusions. If the URI in one graph could denote something different from the same URI in the other graph, then merging would no longer be a valid RDF entailment and their combination would be meaningless. 

Now, I think I know how you are reasoning here. You observe that, given some RDF in a graph, we do not know what the referents of the URIs are. There are many possible intepretations of the RDF, and hence many possible referents for the URIs, given that we only know that the graph is true. And, if we take a different graph, the range of what might called out referential ignorance changes, depending upon the graph: each graph rules out a different set of interpretations. And if we take both graphs together, the range of our referential ignorance is restricted by both of them. All true, but nothing to do with contexts, at least as that term is widely understood when talking about context logics (which is how you seem to be using it in these emails.)

>  Thus, to correctly interpret those graphs, different interpretations sometimes *should* be used.

No. DIfferent *sets* of satisfying interpretations are determined by the two graphs, and their merge determines the intersection of those sets. That is the basic insight of model theory. But operationally, we don't consider interpretations at all: we simply apply valid rules to assertions. Merging two RDF graphs is a valid rule, for example. 

>  And the existing RDF Semantics works just fine for this, until you try to merge those graphs, at which point the semantics would have to be extended to handle contexts.

No, the sematnics is non-contextual from the ground up. If you want contexts in RDF, you need to adjust the rules in the basic truth-conditions for simple RDF interpretations, to allow different occurrences of a single URI to denote differently in different contexts. (In particular, the rule for the truth of a triple in an interpretation.) In the current spec, RDF graphs are not contexts, and it is a violation of the RDF specs to treat them as being contexts. 


> David
>> The RDF semantics is predicated on this assumption. And a
>> context version of RDF would not assume this: it would allow a single
>> URI to mean one thing in one graph and a different thing in another
>> graph, consistently, in a *single* interpretation.
>>> Am I right, or have I completely misunderstood something
>>> fundamental?
>>>> Entailment, for example, is defined upon *sets* of RDF graphs,
>>>> and the definition of merging makes sense only if the URIs in
>>>> these various graphs all denote in the same way.
>>> [Side note: As discussed above, surely you mean that "merging makes
>>> sense only if the URIs in these various graphs all denote in the
>>> same way" *in* a given interpretation.  Right?
>> In *all* interpretations, but yes, OK.
>>> ]
>>> Of course, but again, merging is defined on a *given* set S of RDF
>>> graphs.
>> It is defined on sets of graphs. Being "given" is not a meaningful
>> mathematical term, AFAIK.
>>> Once the user of the RDF Semantics spec has *chosen* S, the spec
>>> defines entailment upon *that* S -- not on some other, unspecified
>>> set.  Is that correct
>> No. Entailment is a relation between sets of graphs, and graphs. No
>> choosing involved.
>>> , or have I completely misunderstood the spec?
>>>>> And here is a trivial existence proof that demonstrates that a
>>>>> URI does *not* necessarily denote the same resource in
>>>>> different graphs.
>>>>> Graph 1 (assuming standard owl: prefix):
>>>>> <http://example/h> a <http://example/WhiteHorse> .
>>>>> <http://example/WhiteHorse> owl:disjointWith
>>>>> <http://example/BlackHorse> .
>>>>> Graph 2:
>>>>> <http://example/h> a <http://example/BlackHorse> .
>>>>> <http://example/WhiteHorse> owl:disjointWith
>>>>> <http://example/BlackHorse> .
>>>>> Each graph (by itself) has satisfying interpretations per
>>>>> standard RDF (and OWL) semantics.  And <http://example/h>
>>>>> denotes a resource in each graph.  But clearly it denotes a
>>>>> *different* resource in each graph.
>>>> The conclusion you should draw here is that these graphs cannot
>>>> both be true. And indeed, if you merge those graphs into one,
>>>> then that merged graph is owl-inconsistent. But that does not
>>>> mean that the URIs denote differently in the two graphs. What it
>>>> does reflect is the fact that no interpretation of names will
>>>> make a contradiction true.
>>> Of course both graph 1 and graph 2 can both be true!  They are just
>>> true under different interpretations!
>> There is no interpretation that makes them both true. That is the
>> precise way to say that they cannot both be true.
>>> And in this case, those interpretations will necessarily map
>>> http://example/h to different resources.
>> Well, they might interpret http://example/WhiteHorse and
>> http://example/BlackHorse differently. But I expect this is
>> nit-picking.
>>> On the other hand, the merge of graphs 1 and 2 is necessarily false
>>> under any interpretation.
>> Right.
>>> Unless I am terribly mistaken, the RDF Semantics spec does not
>>> mandate the use of a single, a unique interpretation that must be
>>> applied to every RDF graph.
>> It does not mandate a single interpretation, of course, But it does
>> presume that each interpretation determines the truthvalue of every
>> graph.
>>> Indeed, to my mind the main value of the RDF Semantics is that,
>>> given an RDF graph, it allows one to determine the range of
>>> possible interpretations under which that graph is true.
>> Yes. And it does that for *every* graph :-)
>>>>>> that does not concur with either the web specifications
>>>>> Correct.  As I pointed out, the AWWW's statement that "a URI
>>>>> identifies one resource" is a good goal, but it does not
>>>>> concur with standard RDF semantics.
>>>> It is quite consistent with, indeed presupposed by, RDF
>>>> semantics. As to whether it is really the case, that is a whole
>>>> more complicated question. But note that when AWWW says
>>>> "identify", it apparently does not always mean what RDF semantics
>>>> means by "denote". There is no assumption in RDF theory or
>>>> practice that a URI must denote what it 'dereferences' to using
>>>> http.
>>> Right, that's a different question.
>>> It might well be the case that
>>>> awww-identification is unique even while denotation is not.
>>>>> nor the goals they were built to satisfy. Caveat emptor.
>>>>> Not true!  As I said before, I *agree* with the goal stated in
>>>>> the AWWW, that a URI should denote one resource!  But that does
>>>>> not change the reality: that a URI does *not* necessarily
>>>>> denote only one resource.
>>>> You are probably right, but to the extent that they do not, then
>>>> meaningful communication fails. So communication usually
>>>> presumes that they do, until circumstances force this assumption
>>>> to be revisited.
>>> I think that is overly pessimistic.  I think useful communication
>>> can still be achieved, provided that the ambiguity is bounded.
>> Ah, we in fact agree here, but your way of phrasing it led me astray.
>> OK.
>> Pat
>>> And when URI definitions are shared, the RDF Semantics (and its
>>> semantic extensions) provide a very neat way to bound that
>>> ambiguity.
>>> David
>> ------------------------------------------------------------ IHMC
>> (850)434 8903 or (650)494 3973 40 South Alcaniz St.
>> (850)202 4416   office Pensacola                            (850)202
>> 4440   fax FL 32502                              (850)291 0667
>> mobile phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Thursday, 21 March 2013 17:03:06 UTC

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