Qualified Cardinality Constraints

Jim, Guus, all


Firstly congratulations on getting the recommendation through.

Secondly, now that it is through at this stage, I would like to see a timely return to the issue of qualified cardinality restrictions.

I have been putting together a list of patterns, best practices, etc. and working on various alternative templates for different applications.  Almost without exception, the ontologies which aim for non-trivial re-use require qualified cardinality restrictions, most commonly to be able to say that something can have one of each of a series of values.

Without qualified cardinality restrictions one has a choice: a) ignore the cardinality constraint altogether; b) create an extra property which mirrors the classes in the ontology, so that one ends up with dozens of subproperties whose sole purpose is to limit cardinality. Furthermore, b) still does not capture the notion correctly because the parent property still does not carry the cardinality restriction. Therefore one has to implement things in tools and do complex translations.

It also comes out repeatedly in teaching cases in responses to questions from students.

Furthermore, if it isn't in the standards soon, implementations won't include them.  Already this is presenting problems.

All my previous arguments apply, but I include a list of recently encountered examples below.

There has just been a "Best Practices" initiative launched.  It would be unfortunate if there were not a pronouncement on this issue in time for at least some comment in a best practice document.  Otherwise, many "best practices" will have to be seriously compromised.

I would like to point out that those  concerned about the removal of qualified cardinality restrictions withdrew our objects reluctantly in order to allow the standard to be approved quickly but on the understanding that this issue would be addressed speedily once the standard was adopted.  It now has been adopted.

I would therefore like to ask formally how the  issue of qualified cardinality restrictions is to be addressed and when.

Thanks for your help.

Regards

Alan


A few examples (We can work up more, and more formally, but I hope these suffice.):

1) In an ontology meant to help with the HL7 (Medical Standards Bodies) Archetypes, we need to say that a test battery – e.g. blood pressure – contains exactly one of each test e.g. systolic_blood_pressure, diastolic_blood_pressure.  Informally:

 Blood_pressure_battery à includes cardinality 1 Diastolic_BP
                                                        includes cardinality 1 Diastolic_BP

There are hundreds of such batteries linking to thousands of observations.  To require a separate subproperty of includes for each is, to say the least, unparsimonious and an invitation to error.  (I can produce dozens of related examples from conversions from UML which does support what we call QNRs – i.e. the same relation can have different cardinalities on its links to different entities.)

2) The Gene Ontology – a number of structures contain exactly n groups of a particular type – example from Chris Wroe  -
I have stated (in DAML+OIL):

TricarboxylicAcid definedAs
        ( OrganicAcid hasStructuralComponent 3 CarboxylicAcidGroup).

I can then use DL reasoning to infer which of the specific classes of
Organic Acids referenced in biological pathways should be classified as a
kind of TricarboxylicAcid. The tricarboxylic acid cycle (Krebs Cycle) is the
first biological pathway taught at high school/ undergraduate level, so not
being able to model it cleanly is quite embarrassing.

The work around using a special variant of has3StructuralComponents isn’t really satisfactory.  It leads to a proliferation of subtypes and cannot be enforced by the logic and doesn’t capture the relations of ‘at least 3’, at most 3’, ‘exactly 3’.

3) The Foundational Model of Anatomy – or any other anatomy – There are thousands of parts each of which occurs a specific number of times.  The number of times should be in the restrictions, not the properties.

4)  Medical example – multiple injuries.  There may be arguments about what the threshold should be.  But if we say three, there is just no other way to express it cleanly: something like:

 Accident and causes min-cardinality 3 Trauma

5)   Organisational.  A chair of a committee with two chairs is a co-chair

           (I'll grant you that's a bit recondite, but it came up.  The obvious solution doesn't work because of the lack of 'same-as' or role-value maps, even for functional properties, but with QCRs you can capture it. )

6)  A marriage is a relation between exactly two people.  I would argue there is a good argument for avoiding a special is_spouse_in relation.  But even more clearly, and topically, how to distinguish a marriage with one male and one female partner from a marriage with two same-sex partners (conveniently this one doesn't require 'same-as' if you define just two sexes).   Again, duplicating the information in the property and the class is obviously error prone and doesn't actually capture the intent.

7) Generic top ontology.  A general mechanism for reifying functional properties, i.e.
 converting from

  Person hasTemperature some Elevated
 to
  Person hasQuality some Temperature hasState some Elevated

Assuming we want people to be able to have any number of Qualities but only one of each, then we have to say that Person hasQuality exactly 1 Temperature.

I could go on.  But the loss in generality and usefulness by not having qualified cardinality restrictions is serious

--
Alan L Rector
Professor of Medical Informatics
Department of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL: +44-161-275-6188/6239/7183
FAX: +44-161-275-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

Received on Tuesday, 9 March 2004 18:49:15 UTC