[OEP] Part Whole Note: comments on pattern 3

For various reasons, I propose to replace the current discussion section
with a new version below:
Most of the content is the same, but I have used a different 'story' to
include it. I also got rid of the most contentious statement.
===
This approach achieves the goal of letting the automated reasoner will
do the work of building a taxonomy of different kinds of parts, that
reflects the explicitly defined part hierarchy.   This alleviates the
need to make explicit statements like the following to declare that
Headlight (or any other part) is a subclass of CarPart:  
 Class(Headlight partial CarPart
  restriction(part:partOf someValuesFrom(ex2:Car)))
Instead the reasoner infers this information, resulting in a more
compact representation of the ontology. It has been argued that such an
approach increases maintainability and modularity [R-NORM
<http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/index.html>
]. 
The inference works properly with the existential restrictions on the
direct part properties as shown. To get a classifier to infer the above
hierarchy using universal restrictions on the partOf_direct property in
the first pattern, there would also have to be minimum cardinality
restrictions on the property.  This is one reason that existential
restrictions are often chosen in these circumstances.
[MFU comment: this seems odd; I would think that choosing between
existential and universal should be based on what is most accurate and
complete, or what is necessary to get the right inferencing, not whether
or not cardinality constraints are necessary. And, what is the problem
with having cardinality constraints? Is it a matter of convenience?
Correctness? efficiency? Does the argument above about problems with
cardinality constraints apply here?]
Note that we have chosen this representation primarily to facilitate the
use of inference to produce a part class taxonomy from an explicit
representation of a part whole hierarchy. This approach seems harmless
at first glance, but there are some caveats.  What this representation
is literally saying is that all engines are car parts, and that all car
parts are parts of actual cars.  Strictly, this is not true. Some
engines are boat engines, and an engine for a 1969 Porsche 911E is
generally considered a "car part" regardless of whether or not it is in
a car (it may be for sale).
The right choice depends on what is needed in a particular situation. To
the extent that the following are true, this approach may be the right
one to meet your needs:
	*	there is a pressing need to have the kind of inferencing
required 
	*	if you have a single local application, and the
assumptions are clearly stated (even if strictly false).  
	*	if the scope of the application only includes cars and
car parts, in which case boat engines are irrelevant. 
	*	you don't need to distinguish between being an actual
part of an actual car, vs. or being a part intended for use in some
[unspecified] car
	*	if there is no need to interoperate, or if all
interoperating applications make the same assumption. 
Conversely, it may be the wrong choice if the above things are not true.
Of particular importance is the case when you wish for your ontology to
be re-used for a wide variety of contexts and shared in a broader
community. That is when making assumptions that are strictly false can
create problems.
===

I chose to throw out the contentious and confusion-inducing statement:
"Recall again, however, that the intent here is to create an intuitive
model of what "whole cars" are made of, not a schema for concrete
instances of these classes."
Is there anything that you (ChrisW) intended by this statement that
still needs to go back in?
--
NB: this is also included (deeply buried) in a more detailed review of
the note. I am sending a separate message so it is more likely to get
looked at.

============================================
Mike Uschold
Mathematics and Computing Technology -- Phantom Works;
Tel: 425 865-3605              Fax: 425 865-2965
Building: 3307 Cube: 33D3      
============================================

Received on Wednesday, 14 September 2005 01:25:04 UTC