Qualified Cardinality Restrictions: Comments

Guus, All

Apologies for the delay in responding.  My mailer initially misfiled the email and then... and then...

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

Received on Friday, 20 August 2004 17:59:06 UTC