Re: SEM: circular primitive vs. defined was Re: was: comprehensive entailments without dark triples

On April 23, Peter F. Patel-Schneider writes:
> From: "Jonathan Borden" <jonathan@openhealth.org>
> Subject: SEM: circular primitive vs. defined was Re: was: comprehensive entailments without dark triples
> Date: Mon, 22 Apr 2002 17:57:37 -0400
> 
> [...]
> 
> > I don't quite get "primitive" vs. "defined" to be honest. I understand the
> > necessary and sufficient, but for example:
> > 
> > <Restriction rdf:ID="BlueThing">
> >         <onProperty rdf:resource="#color"/>
> >         <toValue>blue</toValue>
> > </Restriction>
> > 
> > That is primitive, right? 
> 
> No.  All restrictions are defined, i.e., they have conditions for
> membership that are both necesary and sufficient.

Writing things like this should be considered "bad practice" as it
contains a "hidden" sameClassAs assertion/axiom. I is much clearer/better
to write:

<Class rdf:ID="BlueThing">
  <sameClassAs>
    <Restriction>
      <onProperty rdf:resource="#color"/>
      <toValue>blue</toValue>
    </Restriction>
  <sameClassAs>
</<daml:Class>

In fact the inability to disallow stuff like <Restriction
rdf:ID="BlueThing"> is one of the complaints I have against the use of
RDF as the "syntax carrier" for DAML+OIL/FOWL - it just isn't possible
to state tight enough restrictions on what constitutes a well formed
DAML+OIL/FOWL statement.

> > I don't get why it would be wrong to label
> > _anything_ which has the property color="blue" as a :BlueThing. I mean
> > anything can have any number of super classes, right? 
> 
> All things with color blue are BlueThings, as given above.
> 
> > Is primitive vs.
> > defined simply an 'implementation' mechanism of reducing the number of
> > classes a thing belongs to? 
> 
> Not at all.
> 
> > i.e. are "defined" classes, classes that you are
> > telling the system that you want it to make inferences on etc.? Otherwise
> > what is the harm of letting things be members of the instance sets of
> > primitive classes?
> 
> The distinction between defined and primitive classes somewhat breaks down
> in DAML+OIL.  Think of defined classes as have a sameclass as relationship
> to a boolean combination of other classes or are DAML restrictions, and
> primitive classes that do not have any sameclass as relationships.  (Yes
> this is not exhaustive.)  It is possible to infer that an individual
> belongs to a defined class without having been explicitly told so.  It is
> not possible to do this for primitive classes.  (Well, these actually might
> not be strictly true for DAML+OIL, but this is the intuitive distinction.)

I would go even further and say that "primitive" and "defined", or
alternative names for the same concepts, are meaningless when applied
to classes in DAML+OIL/FOWL. As Peter says, primitive classes are
generally thought of as being those for which there are no sufficient
conditions for membership (membership cannot be inferred). It is only
meaningful to ASSERT that a class is primitive (i.e., by stating
something like "Defprimclass name description") in VERY restricted
KR languages. RDFS is already too expressive for this due to the
possibility of adding cyclical inclusions and/or range/domain
restrictions. E.g., if I introduce a "primitive" class "C" by saying
something like C subClassOf D, I can later assert C to be the domain
of property P, with the result that I can now infer membership of C
for any individual related to another by property P.

In DAML+OIL/FOWL it only makes sense to talk about different kinds of
assertion/axiom, i.e., subClassOf axioms or sameClassAs
axioms. Primitive/defined are very bad names to give to these axioms
as they carry all the baggage of necessary and sufficient conditions -
just sticking with subClassOf and sameClassAs would be MUCH better.

Ian

> 
> > Jonathan
> 
> peter
>

Received on Tuesday, 23 April 2002 08:11:18 UTC