Re: Qualified Cardinality Restrictions: Comments

Alan Rector wrote:

> Guus, All
> 
> Apologies for the delay in responding.  My mailer initially misfiled the email and then... and then...

Alan,

Thanks for the detailed review. I'l work this week on a revised version. 
I would appreciate it if you would consider co-editing this note.

Guus


> 
> Overall, I am happy with this.  Five suggestions and a few typos and a question:
> 
> Question:: Why are qualified cardinality restrictions any more qualified than any other restrictions.  As you point out, ordinary existential restrictions are just a special case of min-cardinality.  (Likewise, universal restrictions are just a special case of  "restriction p not C  max-cardinality(0).  Assuming that it does need a different name because it is nonstandard, then...
> 
> i) I would prefer to see the cardinality() clause before rather than after the valuesFrom() clause.  See the final example of this note for a case where the given order means that the cardinality restriction gets separated so far from the thing it restricts that it is human unreadable.
> 
> ii)    This ought to link to the n-ary relations note.  One of the prime uses for qualified cardinality restrictions is for representing relations and classes, e.g.
> 
>     subclassOf(Person, hasQuality exactly-1 HeightFeature)
>     subclassOf(Person, hasQuality exactly-1 BodyTemperature)
>     etc.
> 
> or in the notation used
> 
>     subclassOf (Person, qualifiedRestriction(hasQuality valuesFrom(HeightFeature) cardinality(1))
>     subclassOf (Person, qualifiedRestriction(hasQuality valuesFrom(BodyTemperatureFeature) cardinality(1))
>     etc.
> 
> 
> 
> (or if you prefer PersonAtTime - but I would avoid that complication for now)
> 
> iii)    I think the limitations of the work around should be pointed out.
> 
> If we want a super property to subsume the individual properties so that we can ask questions except by very awkward disjunctions, then there are problems.  For example we might want to have
> 
> subpropertyOf(hasStarter, hasCourse)
> subpropetyOf(hasMainCourse, hasCourse)
> subpropertyOf(hasDesert, hasCouse).
> 
> class(CoursesOfItalianDinner complete
>       restriction( isCourseOf someValuesFrom ItalianDinner))
> 
> There is no way of restricting the parent property, e.g. hasCourse,  without restricting the subproperties.  Therefore there is no way to constrain users to use the subproperties.  The following would be a legal class of MinimalItalianDinner:
> 
> class(MinimalItalianDinnerPlus
>    subclass_of(Restriction(hasStarter someValuesFrom Salad))
>    subclass_of (Restriction(hasMainCourse someValuesfrom Cannelloni)
>    subclass_of(Restriction(hasDesert someValuesFrom Taramasu))
>    subclass_of(Restrtiction(hasCourse someValuesFrom Chocolate_torte))
> 
> Furthermore, we might want to leave it open that there course be some additional courses, e.g.
> 
>    subclass_of(Restriction(hasCourse someValuesFrom Capucino))
> 
> To avoid this would require a convention for annotating properties such as hasCourse as not to be used with values of certain types. It must be an annotation because if it were a universal restriction it would apply to the subproperties, e.g. for the above:
> 
>     property hasCourse annotation(not_to_be_used_with (StarterDish OR MainCouseDish OR DesertDish)
> 
> This could provide tools with the necessary information to enforce the requirement.  The limitation would apply only to definitions  - i.e. (equivalentClassTo and class(...complete...)  axioms --  and not to additional necessary statements -- i.e. subclassOf(restrction(...) or class(...partial...restriction(...)) .   Otherwise it would be impossible to ask the generic question of what courses did this meal consist or to describe easily "vegetarian meals" in which all courses had to be vegetarian.
> 
> In examples of the disadvantages, the fifth bullet point use case should be pointed out.  This one just cannot be coped with by the workaround in any plausible way, since the whole point is that the nature of the combination regimes (i.e. combination drugs) are not known in advance and CNS depressant is likely not to be a primary classification but one arrived at by the classifier.
> 
> 
> iv) Under Approach 3, I think one of the examples should be of a min or max cardinality, e.g. the medical oversight committee example in the bullets.
> 
> v) I would also consider pointing out that there are things that cannot be expressed, e.g.  The following mahy be a step to far, but it is a real example from a real system.
> 
> subclassOf(LegalRegime
>       qualifiedRestriction(includes valuesFrom(
>                      Preparation AND
>                       restrction(contains someValuesFrom(
>                                          Drug AND
>                                          restriction(hasEffect someValuesFrom( CNS_Depression)))
>                        maxCardinalithy(1)))
> 
> This illustrates why it would be a better order to make the ordering:
> 
> subclassOf(LegalRegime
>       qualifiedRestriction(includes maxCardinality(1) valuesFrom(
>                       Preparation AND
>                       restrction(contains someValuesFrom(
>                                        Drug AND
>                                         restriction(hasEffect someValuesFrom(CNS_Depression)))))
> 
> 
> The second is reasonably understandable.  The first is not, except with very careful formatting and even then with difficulty.
> 
> 
> (This is, I assure you, a perfectly reasonable and basic restriction for something such as the drug ontology)
> 
> 
> 
> Typos etc.
> 
> Final page: bottom in NOTE: "...when an unendorsed OWL vocabulary..."
> Acknowledgements: noet --> note
> 
> Regards
> 
> Alan
> 
> 
> 
> 
> --
> Alan L Rector
> Professor of Medical Informatics
> Department of Computer Science
> University of Manchester
> Manchester M13 9PL, UK
> TEL: +44-161-275-6188/6149/7183
> FAX: +44-161-275-6236/6204
> Room: 2.88a, Kilburn Building
> email: rector@cs.man.ac.uk
> web: www.cs.man.ac.uk/mig
>         www.opengalen.org
>         www.clinical-escience.org
>         www.co-ode.org
> 
> 
> 

-- 
Free University Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
Tel: +31 20 444 7739/7718
E-mail: schreiber@cs.vu.nl
Home page: http://www.cs.vu.nl/~guus/

Received on Tuesday, 24 August 2004 15:22:22 UTC