Re: equivalentTo

From: Jeff Heflin (
Date: 03/22/01

I have a strong objection to removing equivalentTo from the language. In
an earlier telecon, I had suggested that equivalentTo could be given the
semantics of saying that two resources were equivalent. Since in RDF,
classes and properties are resources, this does not conflict with the
subProperties of equivalentTo called sameClassAs and samePropertyAs.
However, some people were uncomfortable with this idea, and I didn't
dissent with the suggestion to create a sameIndividualAs property,
thinking it was only a trivial addition to the language. If I had
thought that someone would later suggest removing equivalentTo, I would
have made a stronger argument for saying that the semantics of
equivalentTo were exactly those that were being proposed for

I think that the fact that the Model Theoretic Semantics does not define
semantics for equivalentTo is a deficiency in those semantics, not in
the equivalentTo construct. In fact the Axiomatic Semantics provides
intuitive semantics for equivalentTo:

%% An object Y is a value of ?equivalentTo? for an object X if and 
%% only if X is equal to Y.  (I.e., saying that objects X and Y are 
%% ?equivalentTo? is logically equivalent to saying that X and Y
%% denote the same object.)
Ax69.    (<=> (PropertyValue equivalentTo ?x ?y) (= ?x ?y))

I'd also like to briefly talk about why I originally wanted equivalentTo
in the DAML language. In SHOE, we have a DEF-RENAME construct that let's
you provide an alias for another term, whether it be a class, predicate,
or constant value. This feature is useful because you could state that
terms used in the vocabularies of two different domains were synonyms,
something that is essential to dealing with a Web in which ontologies
will be created by autonomous individuals as opposed to a single
centralized authority. You don't need to use a different variation of
DEF-RENAME for each kind (class, predicate, etc.) of semantic primitive,
because by stating that some new term was an alias of an existing term,
it was possible to infer that the alias must be the same kind of
semantic primitive. When supporting equivalentTo in the early days, I
saw it as a slightly more powerful version of SHOE's DEF-RENAME.

One final note on the ontologies Jim mentioned: these ontologies were
automatically generated from SHOE ontologies which use the DEF-RENAME
feature. Although I could change the ontologies to use samePropertyAs
(or sameClassAs) without changing the meaning, this makes things more
complex (because I'm taking one semantic primitive and translating it
into three). But why bother when equivlaentTo works perfectly well?

Jim Hendler wrote:
> I guess I would suggest looking at the usage of equivalento -- and
> particularly I would want Jeff Heflin to weigh in on this issue
> because he uses it extensively in his ontologies, which are currently
> among the most used in the DAML repository.  He does a lot of this
> sort of thing
> (from
> ><Property ID="addressCity">
> >   <equivalentTo
> >resource="
> >l#addressCity" />
> ></Property>
> >
> ><Property ID="emailAddress">
> >   <equivalentTo
> >resource="
> >l#emailAddress" />
> ></Property>
> which lets him create new ontologies that explicitly refer to old
> ones and then extend them.  This has been useful in usage of SHOE.
> Jeff, perhaps you can comment on this issue.
> Also, although I shudder to mention this, on rdfig (see
> the term from DAML they're all most
> interested in is "equivalentTO" precisely because it maps to its
> English equivalent so well.  I suspect we should just keep things the
> way they are -- The semantics of equivalentto can be defined such
> that making things of different category (i.e. class, property,
> individual, etc.) equivalentto is not allowed (I.e. if I say
> damloil:equivalentTO #pfps daml:person) the DAML+OIL validator should
> come back and complain (bitterly)
>   -JH
> Dr. James Hendler     
> Chief Scientist, DARPA/ISO      703-696-2238 (phone)
> 3701 N. Fairfax Dr.             703-696-2201 (Fax)
> Arlington, VA 22203   

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