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

Natasha,

There is a new editors draft available at 
[http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/index.html]

You will have to dig deep into the long-term memory to recall this, but 
here are comments on your comments:

Natasha wrote on 03/29/2005 08:01:55 PM:
> =================
> 
> 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 
> document.
> 
> 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".

OK, you did this and I included it with many changes, please review.  It 
is the new "pattern 1".

> 
> ==============
> 
> 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>

done.

> 
> =========
> 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"?

fixed

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

Any OWL reasoner, yes.  There are no "conformant" OWL reasoners at this 
time, but all the reasoners I know of (racer, fact, pellet) do it.

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

fixed

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

done

> 
> Also, this paragraph refers to "property hierarchy" -- perhaps should 
> explicitly refer to using rdfs:subProperty (and link to its 
> definition). Perhaps
> http://www.w3.org/TR/rdf-schema/#ch_subpropertyof

done, though I made no attempt to do this consistently.  Way too much 
work.

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

Toned it down.

> 
> =============
> 
> 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 http://www.w3.org/TR/owl-ref/#inverseOf-def

done.

> 
> ===========
> 
> 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

fixed

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

done

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

done

> 
> ============
> 
> Pattern 1.
> 
> Enumerated list at the beginning, item 5:    "Express the part-whole 
> relations amongst classes using hasSomeValuesFrom() with 
> partOf_directly"
> 
> 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)

slight rewording

> 
> Also, remove has from hasSomeValuesFrom

fixed

> 
> ============
> 
> 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 
> throughout

fixed.

> 
> ===========
> 
> 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"

Things got moved around, and I'm not sure where to put this.  Is it really 
needed?

> 
> ===========
> 
> 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 
> below]
> 
> 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 
> restrictions."

OK, I tried to reword it a little bit, I didn't find your rewording fixed 
anything significant.

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

This is, in general, what "tradeoff" conveys - that when you give a little 
on one, you take from the other.

> 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? 

Yes.

> It seems that it fact having maxCardinality 1 constraint can actually 
> make things easier for a reasoner, no?

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

This is just a fact of life using reasoners.  The more information you 
give it the slower it will be.  I think it's important to make this point 
here.

> 
> ============
> 
> 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."

done.

> 
> =========
> 
> 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"

This is unresolved.  We should talk about it with Alan.  I started 
rewording things a little to reflect the fact that the ontology models a 
"whole car", as opposed to creating a schema for actual instances.  This 
needs to be made more consistent.

> 
> ============
> 
> 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 
> explain?
> 
> 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. 
> CarHeadlight."
> 
> 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?
> 

Reworded a little, some more needed.  As above, need to talk about it with 
Alan.

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

Well, I agree it's important and I understand the request to move it, but 
it does fit there in terms of the "story" of the evolving example and it's 
too much to rework it.

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

fixed.


> 
> ============
> 
> 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

fixed.

> 
> ============
> 
> 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 
> reflexive.

Most people don't listen to classical music, that doesn't change the fact 
that its classical.  These are the axioms of classical mereology, 
regardless of what most people think.

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

reworded

> ==========
> 
> 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 
> building.

added an example.

> 
> ===========
> 
> 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 ..."

fixed.

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

Thanks for the work.

-Chris

Received on Friday, 12 August 2005 03:16:14 UTC