Re: [ALL] editors draft of simple part-whole note ready for review

> Is ready for review.  Guus and Bill had volunteered to review it.

Alan, Chris,

Even though I haven't signed up to review the part-of note, I've done 
the review anyway and have a bunch of comments. Mike may have set a 
dangerous precedent with OEP notes: my review may turn out to be 
comparable in length to the note itself :)

Let me first say that I think it is a very useful note and covers most 
of the bases very well. I do have some concerns and suggestions though.


First, buried deep in the note is a statement that it deals only with 
cases when you don't have instances and want to represent everything as 
classes. I would think that for a "simple" part-of note, having a 
pattern that "simply" represents part-of for instances is important. In 
fact, I would start with that and then go into all the more complex 
patterns. If you'd like, I can take an action to write such a pattern 
for this note. It would be something very simple, most probably with 
little or no OWL at all, and just RDFS. Something that has your class 
Item, property partOf (or partOf_directly) with domain and range of an 
Item, and individual Motor123 that is part of Car123, or some such.

By the way, such a pattern would address another concern: describing 
how to do  this in RDF, not just OWL.

In my experience, when people ask how to represent "part-of" (because 
they are surprised not to find anything inherent in the language for 
such representation), what they often (not always) need is this very 
simple case. Basically, they just need to be told that you can use 
part-of similarly to any other domain property and here is an example. 
In fact, this simple information is completely missing from the 

To sum up here, it seems that the document needs a simple "pattern 1" 
for instances, basically with  the message that you can "just do it".


On pattern 1, I wonder if using partOf rather than hasPart for the car 
example is a good idea. You mention yourself (albeit at the very end of 
the discussion for the pattern, and in more detail closer to the end of 
the whole note) that this pattern actually says that each motor MUST be 
a part of some car, which is of course not true. Using partOf made more 
sense when the example was medical (heart is part of body), but seems 
counter-intuitive and counter-productive for parts of car.

I would suggest using hasPart in this pattern. Or, if you want to keep 
the pattern as is, the "health warning" that this pattern defines the 
item as necessarily a part of something else must go in the very 
beginning, not at the end of the discussion. Somewhere close to the 
enumerated list that you have at the beginning of the pattern.

In general, it is not clear from the text what is the point of pattern 
1. Perhaps, if we were to include the simple instance-oriented pattern 
that I suggested earlier, one could say that the current pattern 1 
explains how to represent similar information with classes, rather than 
instances, putting restrictions at each class, etc. So, a preamble to 
this pattern could be something like:

We can represent that motors are parts of cars, crankcases are parts of 
motors, etc. without using individuals and by expressing the 
constraints at the class level. In this pattern, we say that every 
motor is a part of some car (assuming it is true. for the sake of the 
example), every crankcase is a part of some motor, etc. To do that, we 
perform the following steps:
<your steps for pattern 1 here>

These two above are probably my most general comments. The rest go 
through the document in order and vary in how serious I feel a 
problem/question is ...


At the end of the first paragraph in "Transitive relations -- parts and 
direct parts," you say

"If we define a property, say partOf, to be transitive, then any 
reasoner conformant with OWL will draw the conclusions that the parts 
of C include both A and B. "

Two questions here:
- What is the semantics of "parts of C include both A and B"? Should it 
be "Both A and B are parts of C"?
- Is it required that any reasoner draws this conclusion? Do all 
current "conformant" reasoners do? I don't actually know the answer, 
but would like a positive confirmation on both


Second paragraph in "Transitive relations -- parts and direct parts": 
The example in the beginning of the paragraph refers to "direct parts", 
but the "solution" at the end of the paragraph is partOf, rather than 
hasPart. Seems inconsistent.

In general I am a little bothered by the discussion of the "next level 
breakdown" -- it is clearly subjective and depends on your level of 
detail, doesn't it? I can always say that a motor is part of a 
powertrain, which is part of a car. At the very least, you may want to 
acknowledge this fact here.

Also, this paragraph refers to "property hierarchy" -- perhaps should 
explicitly refer to using rdfs:subProperty (and link to its 
definition). Perhaps


In "Choosing whether to use partOf or hasPart", you say "Almost always 
it is preferable to use partOf because the most common queries and 
class definitions are for the parts of things, e.g. the class of all 
parts of a car."

This statement seems rather unsubstantiated. In fact, the car example  
if not refutes, certainly doesn't support this point (motors sit on 
shelves in mechanics' shops, etc...). I must be missing a reason for 
this suggestion, but I think the text should either explain what the 
reason is in a more substantiated way, or get rid of it.


In "Choosing whether to use partOf or hasPart", it would be useful to 
have a hyperlink on the first time you use inverse to point to 
something like


Also, in "Choosing whether to use partOf or hasPart", you say

"Therefore, if we want to say both that "all As are parts of Bs" and 
"all Bs have part some A""...

missing SOME in "all As are parts of SOME Bs" above


I would move the "Use cases" section earlier, right after the "General 
Issues" (before Transitivity)  -- it's important to know what the big 
deal is before you get into transitivity, inverses, etc.

Also on "Use cases": what do you mean by  "explosion" in the first item 
there? (There are other references to "explosion" further on, which are 
at the very least obscure). This really needs to be explained in a 
sentence or two, or an example. I can't even suggest an alternative 
wording here since I don't quite understand what it means myself.


Pattern 1.

Enumerated list at the beginning, item 5: 	"Express the part-whole 
relations amongst classes using hasSomeValuesFrom() with 

It took me a while to figure this one out. Perhaps with the preamble I 
suggested above, it would be more clear. Or perhaps, it is worth 
reiterating here; something like:
5. Express the part-whole relation among classes using someValuesFrom 
restriction with partOf_directly by expressing that individuals in one 
class (e.g., Motor) are necessarily parts of individuals in another 
class (e.g., Car)

Also, remove has from hasSomeValuesFrom


In Examples, you have "Consider a (over simplified) catalog of Vehicle 
parts, all subsumed by the class Item". What does "subsumed" mean here? 
Perhaps something more precise, like:

"Consider a (over simplified) catalog of Car parts. All classes of 
parts and the class Car itself are all subclasses of a class Item"

Replace Vehicle with Car since you are talking only about Cars 


Right before N3 for the example in Pattern 1, it is worth noting that 
transitivity is not inherited to subproperties:

"We define partOf as a transitive property and partOf_directly as its 
non-transitive subproperty. Note that ini OWL transitivity is not 
inherited to subproperties"


Discussion for pattern 1.

I felt that the discussion was trying to make 3-4 points, all 
intertwined, and jumping from one to another and back. I would suggest 
re-organizing the discussion text to make the points more clearly.  One 
suggested line of thought could be as follows (for many of these, I am 
just re-using your text):

1. "When considering restrictions on the partOf_directly property for 
different kinds of parts, the issue of using a universal 
(owl:allValuesFrom) vs. an existential restriction arises. Many 
different kinds of things have motors (boats, planes, etc.), and in 
fact even car motors can exist without being part of a car: a motor for 
a 1969 Porsche 911E is generally considered a "car part" regardless of 
whether it is in a car or not (it may be for sale). This indicates 
that, ontologically, the existential restriction is simply not true." 
We use existential restriction here because ....  I don't have a good 
explanation, but one is needed, and, whatever it is,  this point should 
come first, it seems.

2. Cardinality discussion -- you are talking about three different 
things at once: (1) we can express semantics more precisely by adding 
maxCardinality restriction on partOf_directly. (2) Putting the 
maxCardinality on partOf_directly would be correct, but classifiers 
don't like that and (3) putting any cardinality constraints on partOf 
(the transitive variant) is a bad thing to do for many reasons. Perhaps 
the following re-organization/rewording would make these points a bit 
more clearly.

"The definition of Crankcase above specifies that a crankcase is a 
direct part of at least one Motor. In fact, a crankcase cannot be part 
of more than one motor. We can specify this additional constraint by 
adding a cardinality restriction  on partOf_directly  to the definition 
of crankcase: maxCardinality 1. A single crankcase cannot be a direct 
part of more than one motor, a motor cannot be a direct part of more 
than one car, etc., so in these cases a maxCardinality restriction 
would make the semantics more clear.

Adding a cardinality restriction on all the partOf_directly will make 
reasoning less efficient. One must consider precisely what the ontology 
will be used for to determine which is more important (enforcing 
semantic constraints vs. classification). [Note, however, my next point 

We may also be tempted to add a cardinality restriction (e.g. 
maxCardinality 1) on (the transitive) partOf to the definition of 
crankcase, but this would be a mistake; since partOf is transitive, a 
crankcase is also part of the car the motor is part of.  Note also that 
OWL-DL does not allow transitive properties to have any cardinality 


Also in Discussion for pattern 1.

I am a bit confused (ok, very confused)  by the following argument in 
the discussion "there is always a tradeoff when employing a reasoner 
between how precise your semantics are and how much information the 
reasoner has to consider.  In this case, adding a cardinality 
restriction on all the partOf_directly properties would significantly 
increase the amount of information handed to a reasoner."

First, this seems like a sweeping statement that suggests that the best 
thing from the reasoner point of view is not to give the reasoner any 
information at all. Surely, that's not what you were suggesting, but I 
am not clear what is the point you are making here. Second, is it even 
true that the more information you give the reasoner, the slower it is? 
It seems that it fact having maxCardinality 1 constraint can actually 
make things easier for a reasoner, no? It can immediately infer what 
the class for the individual in the property value is? Since I am not 
sure what is the point you are making, I can't suggest an alternative.

Resolution of this issue affects the statement that follows the excerpt 
above: "One must consider precisely what the ontology will be used for 
to determine which is more important (enforcing semantic constraints 
vs. classification)"


Also in Discussion for pattern 1:

If we include an instance-oriented pattern upfront, you can remove the 
sentence that "The examples in this note are aimed primarily at 
use-cases in which no instances of the classes are present."


Pattern 2. Discussion.

You say "These classes exemplify one of the main reasons to choose 
existential restrictions on the direct part properties over universal 
restrictions (as discussed in the previous pattern).  A classifier 
would not be able to infer the hierarchy above using universal 
restrictions on the partOf_direct property in the first pattern, unless 
there were minimum cardinality restrictions on the property as well."

 From the point of view of best practices, do we really want to 
recommend that people use the pattern that is "wrong" from the modeling 
point of view, as in this example, just to have the classifier being 
able to infer good things for us. What's the point? We feed it with bad 
information, it infers something that looks plausible but is also 
wrong. I am really bothered by the paragraph above as a "best practice" 
suggestion. Ontologically, it just seems like exactly the wrong thing 
to do. Perhaps, what you can say instead is something like:

"If our model does not allow us to use existential restrictions (e.g., 
we cannot define motors as necessarily being part of some car), we will 
not be able to have a classifier infer that for example Motor is a  
subclass of CarPart"


Also in Discussion on pattern 2:

You have: "Ontologically, these classes by themselves are reasonable, a 
"car part" is indeed anything that is part of a car, however when 
combined with the existential restrictions on the direct properties, a 
classifier would infer the hierarchy above. "

I am not sure I understand at all what this sentence means. Could you 

And following it:
"These kinds of hierarchies seem harmless at first glance, but in some 
contexts are completely wrong: not all motors are car parts, some are 
boat motors, etc.  On the other hand, a motor for a 1969 Porsche 911E 
is generally considered a "car part" regardless of whether it is in a 
car or not (it may be for sale)."
This belongs in the discussion for pattern 1

Finally, you conclude:
"When this is not obvious from the scope of the ontology, it is good 
practice to reflect these issues in the names of the class, e.g. 

When what is not obvious? Also, CarMotor can still sit on a shelf in a 
mechanic's shop. I am not sure what this sentence suggests? If it is a 
naming convention in general and has nothing to do with  part-whole, 
why is it even here?


Pattern 3.

Section on "Distinguishing parts from kinds"
This section is very important, but I am not sure why it is buried in 
pattern 3. It seems that a more appropriate place for it would be along 
with other "general" section (transitivity, etc.) before pattern 1.

Also, at the very end of this subsection, you say:
"Such hierarchies serve well for navigation, however they are not in 
general true. " It's part of cleaning up the note vis-a-vis 
terminology, but what does it mean for a hierarchy to be "true"? 
Perhaps you meant semantically consistent, using the same parent-child 
relation throughout, etc.?


Pattern 3. Examples

You start the examples section by saying that "such hierarchies do need 
to be recreated in situations that obey the rule "A fault of the part 
is a kind of fault of the whole" Here, I assume, you refer to the 
hierarchy in the section on  "Distinguishing parts from kinds" (which 
I've suggested moving outside of this pattern anyway). I think this is 
incorrect: the hierarchy that you will be re-creating in this pattern 
includes only (faults in) cars, not (faults in) vehicles, as your 
hierarchy in the Example section suggests


Pattern 4.

You start  by saying "Classically, the part-of relation is reflexive" I 
think Bill was bothered by this as well -- "Classically" seems like too 
strong a word here. In fact, most people may NOT think of part-of as 


Considerations section

You say:
" It is possible to approximate a tree by making the partOf_directly 
subproperty non-transitive and functional, with a local range 
restriction (owl:allValuesFrom) to the "next larger" class of parts."

I am not sure I understand what exactly you mean by this or why do we 
want this.


Section "Other relations that follow the same pattern as faults"

I would elaborate the purchase example a bit (I had to stop and think 
for a while before the point became clear), by adding something like: 
We can purchase an apartment in a building without purchasing the whole 


In section "Relation to clasic Mereology", you say " OWL does have 
built-in primitives for antisymmetric or reflexive properties" -- 
missing NOT: "OWL does NOT have ..."


I think that's it :) Probably more than you wanted. Naturally, it would 
have been much easier if I'd read the note a week earlier, before the 
three of us where in the same room together last week and could have 
discussed it by saving lots of typing for everyone. oh well..... I 
guess I didn't expect to have that many comments.

Also, at a later point, the note needs to be read for 
typos/inconsistency in terminology, etc. I've noticed a bunch of those, 
but haven't kept track.


Received on Wednesday, 30 March 2005 01:02:02 UTC