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

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.

> 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.)

> Jonathan

peter

Received on Tuesday, 23 April 2002 05:09:33 UTC