Re: semantics of daml:equivalentTo [was: Comments on Annotated DAML 1.6]

From: Jeff Heflin <heflin@cs.umd.edu>
Subject: Re: semantics of daml:equivalentTo [was: Comments on Annotated  DAML   1.6]
Date: Thu, 12 Oct 2000 15:29:56 -0400

> I'd just like to elaborate on Jim's message. I believe that equivalentTo
> is the DAML version of the SHOE <DEF-RENAME> element. In SHOE,
> DEF-RENAME allows an ontology to provide an alias for a term defined
> elsewhere. Essentially, it means that both terms reference the same
> concept, and thus any assertion that is made using one term is also true
> if the other term was substituted in its place. This is really easy to
> implement: you keep a hash table that matches aliases with the base
> terms (used in the original definitions) that they renamed, and upon
> parsing a document or issuing a query you can perform the necessary
> substitutions to rephrase it in only base terms.
> 
> Because of the confusion that equivalentTo has caused on this list,
> perhaps "renames" or "aliasOf" are better choices for the propery name?
> 
> Jeff

OK, here is where I feel that I must put in a scream for formality, or at
least clarity.

What does it matter whether the name is equivalentTo, renames, aliasOf, or
frobaz?  What matters, as far as I can see, is what the meaning of
"equivalentTo" is.

From

<Property ID="equivalentTo"> <!-- equals? equiv? renames? -->
  <comment>for equivalentTo(X, Y), read X is an equivalent term to Y.
  </comment>

	<!--@@RDF specs prohibits cycles, but I don't buy it. -->
  <subPropertyOf resource="#subPropertyOf"/>
  <subPropertyOf resource="#subClassOf"/>
</Property>

I can make many choices, ranging from 

A/ Whatever the meanings of X and Y are (and they could have complex,
   precisely defined meanings), these meanings are asserted to be the same.

to

B/ X cannot have its meaning specified or constrained (or ...) in any way
   whatsoever except by this statement except in ways that also do exactly
   the same to Y.  X is given a meaning that is the same as the meaning of
   Y and it will forever track the (changing) meaning of Y.  (The reason
   for all this handwaving is that, as Jim stated, we are in an
   environment, where we cannot make the assumption that there is a unique
   defining statement for every class.  Systems like SHOE or CLASSIC seem
   to be designed with this ``unique definition'' assumption.)

Using choice A/, I could create an ontology with no individuals at all
via

 <Class about="Nothing">
  <equivalentTo resource="Thing">
 </Class>

Choice B/ does not have this kind of import, but, of course, it has an
extremely strange non-syntactic side condition that may be impossible to
verify.

So my plea here is that we get some better notion of the meaning of the
various constructs in DAML-ONT.  If this is not forthcoming, then how can
we determine how to use DAML-ONT and how can we argue about what needs to
be changed in DAML-ONT.

Peter Patel-Schneider

Received on Thursday, 12 October 2000 16:12:01 UTC