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
list.
Regards,
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