From: Frank van Harmelen (Frank.van.Harmelen@cs.vu.nl)
Date: 12/27/00
Ian, Thanks for your comments. > 1. I notice that you didn't change the domain restriction on "height" > (currently "Person"). I think that this is a mistake because, as I > showed in Washington, skyscrapers end up being either inconsistent (if > Building and Person are disjoint) or a sub-class of Person. At the > very least the property should be renamed to something like > personHeight. To reassure everyone: the current example is not inconconsistent, but only becomes inconsistent when extended in a "natural" way (adding the class buildings, with subclass skyscrapers that has the restriction that their height must be tall). I've simply removed the domain restriction on height, which was not required for anything in particular. > 2. As I already mentioned to you, the "spouse" example is a bad one > because it implies that persons can have many spouses, provided that > only one of them is a Person. It is hard to come up with good examples > of cardinalityQ constraints - how about a structural example such as > "a person can have at most 2 limbs of type Leg"? Another possibility > would be to have a Class "FullTimeOccupation" and state that a person > can have at most one FullTimeOccupation (but maybe several part time > jobs). I like your FullTimeOccupation example. I've now used "spouse" as an example of a maxcardinality constraint (person has max 1 spouse) and illustrated the qualified cardinality constraint by following your suggestion that a person may have at most one job of type FullTimeOccupation. > 3. About UnambiguousProperty. We could of course infer that the > inverse of a UniqueProperty must be an UnambiguousProperty (in fact > having both kinds of property is redundant). Maybe we should mention > this. Maybe we should use an example where the UnambiguousProperty > statement isn't redundant (because we don't already know that the > inverse is Unique). I've added the remark that the inverse of any UniqueProperty is an UnambigousProperty, and have left out any illustration of the latter. The textual explanation will do the job. Thanks for your comments, Frank. ----
This archive was generated by hypermail 2.1.4 : 04/02/02 EST