From: Ian Horrocks (horrocks@cs.man.ac.uk)
Date: 07/09/01
Dan, On July 7, Dan Brickley writes: > > Hi > > (I'm unlurking; as RDF Core WG work on RDF Schema is starting up, I'm > hoping to have more time to spend on DAML+OIL stuff too) > > So I'm looking at some of the DAML+OIL definitions, while preparing a > new draft of RDF Schema for the RDF Core WG. Reviewing the equivalentTo / > sameClassAs machinery: > > DAML+OIL says... (larger excerpt coped below) > > for equivalentTo(X, Y), read X is an equivalent term to Y. > and > for sameClassAs(X, Y), read X is an equivalent class to Y. > cf OIL Equivalent > > > The axiomatic semantics tells us "sameClassAs is equivalentTo for > classes", yet the two textual definitions differ: the first seems to be > couched as a relationship between _terms_ (that denote the same thing), > whereas the second seems to be couched as a relationship between the > things that terms denote. Given that the latter relation is based on the > former, this seems quirky. In DAML+OIL, equivalentTo is provided as a "catch-all" equivalence property that can be used to state equivalence between any two "things" (terms may be a bad choice here, but things is a problem too as we use Thing to denote the most general DAML+OIL class). However, DAML+OIL only provides a semantic interpretation for equivalentTo when the "terms" are pairs of DAML+OIL classes, properties or individuals. > Following the definitional style of equivalentTo, one might expect to > see something like "X _denotes_ an equivalent class to Y"? I don't think we really want to talk about classes (because X and Y might not be classes), but we could perhaps have said that X has the same denotation as Y. The only trouble with that is it implies a denotational semantics for equivalentTo which we are only able to provide in some cases (e.g., equivalent DAML+OIL classes). > I suspect DAML+OIL inherits some murkiness from RDF here, ie. RDF > mumbles about whether we're describing relationships between pairs of > URI names, or whether between the things those URI names denote. But > whichever way we jump, I'd have expected these two definitions to adopt > the same style. We usually rely on RDF to provide top level murky/semantic-free terms that we can specialise, but as there wasn't one for equivalence we decided to add one of our own. > I was concerned mostly with the classes case as I'm thinking about the > subClassOf cycles issue. Reading on, same goes for samePropertyAs, > sameIndividualAs; it seems equivalentTo is the odd one out, by talking > about 'terms'. You are reading more into the use of "terms" than was intended. It is just an attempt to be vague/general w.r.t. the kinds of thing that are being stated to be equivalent. > I can't see any interesting difference between > sameIndividualAs and equivalentTo (since everything's a daml:Thing, and > being one-and-the-same-thing-as doesn't really come in multiple > flavours). (I remember seeing discussion on this point before; forgive > me if I'm poking at a recently closed issue). Am I missing something > or could these two be folded together, so that samePropertyAs and > sameClassAs would be defined in terms of sameIndividualAs? The difference is that sameIndividualAs describes the specific case where the "terms" are individuals. > http://www.daml.org/2001/03/reference.html > [[ > To state that objects are the same, a daml:sameIndividualAs element is > used. (Note that daml:equivalentTo can be also used here, but > daml:sameIndividual is preferred. To state that objects are distinct, a > daml:differentIndividualFrom element is used. The situation is different > for datatype values, where XML SchemaDatatype identity is used. > ]] > > Some editorial comments: > > - it would be helpful here to say _why_ daml:sameIndividualAs is > preferred. Does it convey more information? Yes - it says that the two objects are individuals with the same denotation. If you use equivalentTo, you have to figure out what kind of thing the two "terms" are before determining what semantics, if any, you can give to the statement. > - typo: "daml:sameIndividual" instead of "daml:sameIndividualAs" > > - ommission: http://www.daml.org/2001/03/axiomatic-semantics.html > doesn't assign semantics to (or mention) daml:sameIndividual(As) > > I also notice sameIndividualAs has domain and range constraints defined > whereas equivalentTo doesn't (is this something to do with datatypes / > literals?): > > <rdfs:domain rdf:resource="#Thing"/> > <rdfs:range rdf:resource="#Thing"/> > > ...but I'm still having trouble seeing the need for both the > sameIndividualAs and the equivalentTo construct. Because of its generality, equivalentTo has no range and domain. The special cases, like sameIndividualAs, have appropriate ranges and domains. Regards, Ian > > cheers, > > --danbri > > > > > Excerpted from http://www.daml.org/2001/03/daml+oil.daml > > <Property rdf:ID="equivalentTo"> <!-- equals? equiv? renames? --> > <rdfs:label>equivalentTo</rdfs:label> > <comment> > for equivalentTo(X, Y), read X is an equivalent term to Y. > </comment> > </Property> > > <Property rdf:ID="sameClassAs"> > <rdfs:label>sameClassAs</rdfs:label> > <comment> > for sameClassAs(X, Y), read X is an equivalent class to Y. > cf OIL Equivalent > </comment> > <rdfs:subPropertyOf rdf:resource="#equivalentTo"/> > <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#subClassOf"/> > <rdfs:domain rdf:resource="#Class"/> > <rdfs:range rdf:resource="#Class"/> > </Property> >
This archive was generated by hypermail 2.1.4 : 04/02/02 EST