Re: equivalentTo

From: Peter F. Patel-Schneider (pfps@research.bell-labs.com)
Date: 03/22/01


The reason I brought it up was that ``equivalentTo'' still exists in the
DAML+OIL specification.  I thought that we should have some debate if it is
to be removed.

Reasons for removing it:

R1/ The model-theoretic semantics gives it no meaning, so equivalentTo
    doesn't tell you anything.  
R2/ There are other relationships that should be used instead, namely
    sameClassAs, samePropertyAs, and sameIndividualAs.
R3/ Stating that a class is equivalentTo a property is probably not what you
    mean.

(By the way, the reason that the model-theoretic semantics does not give
equivalentTo any meaning is that this would then make same...As be the same
as equivalentTo.)

Reasons for not removing it:

N1/ People might be using it, and would not be happy if equivalentTo had no
    meaning.
N2/ It has a nice name.
N3/ There would be a common mechanism for asserting equivalence of any two
   things.

In my view, the current situation is not desirable (due to the first part
of N1 above).


There are two basic approaches, with some options:

1/ Leave equivalentTo in, and give it semantics.
   1A/ Make same...As subproperties of equivalentTo, with no extra
       semantics (except for domain and range restrictions, maybe).  [This
       is probably what many people think the current situation is.]  This
       has the problem that sameClassAs also makes things be the same
       property and the same individual, and similarly for the other two
       same...As's.	
   1B/ Make equivalentTo be a subproperty of the three same...As's.  You
       don't get the problem above.  However, it does mean that classes and
       properties cannot be disjoint if you want to use equivalentTo (and I
       seem to remember some RDF(S) discussion about them being disjoint.)

2/ Remove equivalentTo.  This is conceptually clean, and doesn't have any
technical problems.


I initially had very strong feelings against 1A, because of the redundancy
and over-reach of the same...As in this approach.  In preparing this
message I have somewhat moderated my views.

Comments?

peter


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