RE: Qualified Cardinality Constraints

Alan,

This is an impressive list of reasons why you need qualified cardinality constraints. 
Part of your tone suggests you still want them added to the language, but that is presumably out of scope for the SWBPD group. So what do you wish for from this group? To advise on the existence of the problem and recommend the best workarounds? Or something else?

Also, I presume you can get qualified cardinality constraints by using OWL-Full, is that not correct?

Mike


 -----Original Message-----
From: 	public-swbp-wg-request@w3.org [mailto:public-swbp-wg-request@w3.org]  On Behalf Of Alan Rector
Sent:	Wednesday, March 10, 2004 1:29 AM
To:	best-practice
Subject:	Qualified Cardinality Constraints


Apologies for cross posting. But I think this is also of interest to the SWBP members.

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 QCRs - 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 Wednesday, 10 March 2004 20:16:16 UTC