Re: equivalentTo / sameClassAs / sameIndividualAs puzzle

From: pat hayes (phayes@ai.uwf.edu)
Date: 07/09/01


>Hi
>
>(I'm unlurking; as RDF Core WG work on RDF Schema is starting up, I'm
>hoping to have more time to spend on DAML+OIL stuff too)
>
>So I'm looking at some of the DAML+OIL definitions, while preparing a
>new draft of RDF Schema for the RDF Core WG. Reviewing the equivalentTo /
>sameClassAs machinery:
>
>DAML+OIL says... (larger excerpt coped below)
>
>    for equivalentTo(X, Y), read X is an equivalent term to Y.
>and
>    for sameClassAs(X, Y), read X is an equivalent class to Y.
>    cf OIL Equivalent
>
>
>The axiomatic semantics tells us "sameClassAs is equivalentTo for
>classes", yet the two textual definitions differ: the first seems to be
>couched as a relationship between _terms_ (that denote the same thing),
>whereas the second seems to be couched as a relationship between the
>things that terms denote. Given that the latter relation is based on the
>former, this seems quirky.

Right, this is an unfortunate choioce of words. What it should say, I 
think, is that equivalentTo(X,Y) means that the terms X and Y denote 
the same thing, and that
'sameClassAs' is 'equivalentTo' restricted to DAML classes.

>
>Following the definitional style of equivalentTo, one might expect to
>see something like "X _denotes_ an equivalent class to Y"?

That doesnt seem to make sense to me. What do you mean by "an 
equivalent class to" ? Classes in the domain are just sets, so there 
is no notion of equivalence in the semantics, only identity. Two 
class expressions are equivalent if they denote the same class.

>I suspect DAML+OIL inherits some murkiness from RDF here, ie. RDF
>mumbles about whether we're describing relationships between pairs of
>URI names, or whether between the things those URI names denote. But
>whichever way we jump, I'd have expected these two definitions to adopt
>the same style.

I agree, it would be better if they did. This particular murkiness is 
common in logical texts and mathematics more generally, however, in 
part because the identity relation is a very peculiar relation if 
thought of semantically, in that it doesn't ever hold between two 
things (only the same thing, twice), so it is really rather hard even 
to SAY that A is equal to B in the semantics. One finds oneself 
saying things like 'the relation which holds between a thing and 
itself'.

>I was concerned mostly with the classes case as I'm thinking about the
>subClassOf cycles issue. Reading on, same goes for samePropertyAs,
>sameIndividualAs; it seems equivalentTo is the odd one out, by talking
>about 'terms'.

I think what people had in mind was that DAML might have no idea what 
these terms denote, so it can't claim to be saying anything at all 
about *that*; but it *is* saying something about the terms: that 
whatever they denote, they must denote one of it, ie the terms 
co-denote; and this, in DAML, is a kind of general warning that these 
terms will be taken to be intersubstitutible whever any DAML engine 
might find it convenient to swap one for the other, even if DAML has 
no other semantic claims on their meaning or semantic pretensions to 
know what they refer to.

>I can't see any interesting difference between
>sameIndividualAs and equivalentTo (since everything's a daml:Thing, and
>being one-and-the-same-thing-as doesn't really come in multiple
>flavours). (I remember seeing discussion on this point before; forgive
>me if I'm poking at a recently closed issue). Am I missing something
>or could these two be folded together, so that samePropertyAs and
>sameClassAs would be defined in terms of sameIndividualAs?

I tend to agree with you there, but recall that there was a lively 
discussion about this issue, and deciding that it wasn't worth 
fighting for.

Pat Hayes

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes


This archive was generated by hypermail 2.1.4 : 04/02/02 EST