From: Jeff Heflin (heflin@cs.umd.edu)
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 sameIndividualAs. 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? Jeff 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 http://www.cs.umd.edu/projects/plus/DAML/onts/personal1.0.daml > > ><Property ID="addressCity"> > > <equivalentTo > >resource="http://www.cs.umd.edu/projects/plus/DAML/onts/general1.0.dam > >l#addressCity" /> > ></Property> > > > ><Property ID="emailAddress"> > > <equivalentTo > >resource="http://www.cs.umd.edu/projects/plus/DAML/onts/general1.0.dam > >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 > http://rdfig.xmlhack.com) 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 jhendler@darpa.mil > Chief Scientist, DARPA/ISO 703-696-2238 (phone) > 3701 N. Fairfax Dr. 703-696-2201 (Fax) > Arlington, VA 22203 http://www.cs.umd.edu/~hendler
This archive was generated by hypermail 2.1.4 : 04/02/02 EST