Re: semantics of daml:equivalentTo

The differences between the various readings of equivalentTo have less to
do with semantics than with with what can be said and what cannot be said.


Suppose you say

SomeRichFriend = (all friend Rich)

[where the above is a macro that expands to the DAML-ONT statments that are
required to make the class SomeRichFriend be precisely those individuals
that have at least one friend that belongs to Rich]

and

<equivalentTo resource="#AllRichFriends" resource="#SomeRichFriend">

are you now (also) allowed to say

<Class about="#AllRichFriends">
  <restrictedBy>
    <Restriction>
      <onProperty resource="#friend"/>
      <toClass resource="#Rich"/>
    </Restriction>
  </restrictedBy>
</Class>

[here I don't need to have a defined class, so I'm giving the straight
DAML-ONT statement]?

If so, then you have a very powerful, but clean, semantic primitive in
equivalentTo.   In this example you would get the ``rule'' that anyone
whose friends are all rich has at least one rich friend, i.e., everyone has
to have a friend.

If not, then you have something that is much less powerful and
it may be possible that ``A <DEF-RENAME> .... can be ignored for the
logical theory''
[http://www.cs.umd.edu/projects/plus/SHOE/pubs/aaai2000.pdf, section 2.2]. 

In both cases, you certainly would not want to have an individual that
belongs to SomeRichFriend but not to AllRichFriends, so it is true that the
``semantic import'' of equivalentTo is that the two classes end up with the 
same meaning.

Peter Patel-Schneider


PS:  A simpler example that shows some of the differences is

	(equivalentTo resource="#Thing" resource="#Nothing")

Does this mean that there can be no individuals?