From: Peter F. Patel-Schneider ([email protected])
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