From: Ian Horrocks ([email protected])
Date: 07/12/01
On July 12, pat hayes writes: > >On July 9, pat hayes writes: > > > >On Mon, 9 Jul 2001, Jeff Heflin wrote: > > > > > > > > > Ian Horrocks wrote: > > > > > > > > > > > > On July 7, Dan Brickley writes: > > > > > > > > > > > > > > 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 think the definition for equivalentTo should say that "X is an > > > > > equivalent resource to Y," where resource is as defined in RDF. Since > > > > > RDF resources can be classes, properties or anything else given a URI, > > > > > this is compatible with the various subproperties of equivalentTo. > > > > > sameIndividualAs is different from equivalentTo because the set of DAML > > > > > individuals do not include classes or properties. > > > > > > > >Aha! That's it. From reading the spec, it wasn't entirely clear to me > > > >what DAML+OIL terms individuals. The schema definition suggests its a > > > >synonym for 'thing': > > > > > > > > <Property rdf:ID="sameIndividualAs"> > > > > <rdfs:label>sameIndividualAs</rdfs:label> > > > > <rdfs:comment> > > > > for sameIndividualAs(a, b), read a is the same individual as b. > > > > </rdfs:comment> > > > > <rdfs:subPropertyOf rdf:resource="#equivalentTo"/> > > > > <rdfs:domain rdf:resource="#Thing"/> > > > > <rdfs:range rdf:resource="#Thing"/> > > > > </Property> > > > > > > > >Could someone explain to me which things precisely are considered > > > >individuals? I gather properties and classes are out of the > > > >picture. Any others? > > > > > > My understanding is that 'individual' is synonymous with 'DAML+OIL > > > object' and simply means anything in the semantic domain. The use of > > > 'individual' for anything in the domain of quantification is a > > > familiar convention in logic, but maybe it needs to be spelled out > > > for a wider audience. > > > >I don't believe this is quite correct. As far as I am concerned, the > >denotation of an individual is an object in the domain of discourse, > >and there is nothing to prevent two individuals from denoting the same > >object (this is what sameIndividualAs asserts). > > So you are using 'individual' to refer to a *syntactic* entity, ie a > name of some kind? That is a very unusual usage, but we can go that > way if people want to. However we then probably should rename > 'sameIndividualAs' to 'sameObjectAs', since there would be little > point in asserting it only of the same name used twice. I think we are just mis-communicating here, and it is probably my fault! I take e.g. "person" to be the name of a class; its denotation is a set of elements in the domain of discourse. When I say (sameClassAs person human) I am asserting that person and human denote the same set. I take e.g. "ian" to be the name of an individual; its denotation is a single element in the domain of discourse. When I say (sameIndividualAs ian ihorrocks) I am asserting that ian and ihorrocks denote the same element. These two usages seem pretty consistent. We could quite reasonably call the element in the domain of discourse that is denoted by ian an individual. This can get a bit confusing, however, (as in this case) because I/we are often a bit lazy and refer to "ian" as an individual rather than the name of an individual (and to person as a class rather than the name of a class). For this reason I usually refer to the elements of the domain of discourse simply as "objects". This has the added advantage that it also works in the datatype domain, where the elements are not denotations of individual names. Ian
This archive was generated by hypermail 2.1.4 : 04/02/02 EST