Comments on Simple Part-Whole Relations

Below are some thoughts about the Note "Simple Part-Whole Relations in OWL
Ontologies" published 24 Mar 2005. Comments are directed by the Note to this
John McClure

1. The design patterns could perhaps include another

Ontologies may package the qualities that are had by a class of objects
separately from the class itself, and then the class inherits the quality-class.
This design pattern differs fundamentally by the choice of predicate(s)
applicable to the solution domain -- the "Part" aspect of "hasPart" has been
promoted to be a DirectObject (where a DirectObject is a subclass of
ObjectProperty and of Class), while 'has' is the only predicate verb defined.

For example, a Car 'has' an ability (a quality) to be operated, encapsulated as
quality-class 'Operability'.  Its subclasses 'Operable' and 'InOperable' are
associated with instances of a Car either (a) using rdf:type or (b) through
property "OperabilityStatus" whose values are either 'Operable' or
'InOperable'... Better yet, a 'Mechanism' class inherits from 'Operability' and
'Product', and Car inherits from Mechanism.

Another quality of a Car is that it is 'Constructable', that is, it can be
constructed from parts (separate items or sub-assemblies). Properties of
'Constructable' would likely include 'ComponentPart' which, by means of
metaclasses, is indicated to be both an instance property and a class property.
In other words, a Car class could have its own set of ComponentPart instances
distinct from those associated with a Car instance, that is, those reflecting
car parts actually installed. The 'ComponentPart' property is a
TransitiveProperty. The 'InOperable' class has a property 'InoperablePart' which
can be about either a part defined in the context of a class of Car, or about a
specific part defined in the context of an instance of a Car.

The 'Operable' and 'InOperable' markers could be associated with the parts
specified in the Car instance's inventory of ComponentParts. Further, a quality
'Importance' could be established having a subclass called 'Critical' which can
identify those ComponentParts whose inoperability (whose 'failure') renders a
larger assembly inoperable -- this quality can be associated with any of the car
parts associated with the class Car.

2. "Pattern 3 ... Distinguishing parts from kinds" has a wholly erroneous
subclassing structure. As implied in the text, a Wheel CANNOT be a subClassOf a
Car because it would be contrary to the RDFS definition for a subclass: every
Wheel cannot equivalently be said to be a Car. Generally, it's confusing to a
reader when an invalid assumption is used as the basis for ensuing discussion.
Subclasses of Car would be 'Van', 'Sedan' and so on, not 'Wheel' !

Received on Saturday, 9 July 2005 23:05:12 UTC