Re: Qualified Cardinality Constraints

I am uncomfortable with the idea that the SWBPD group is an appropriate 
forum for revisiting language design issues.

For example, I am looking at some of the RDF design issues in the 
*interest* group, with an expectation that if successful these explorations 
might hit the standards track in a number of years ...

I also suspect that we can get a wider uptake of SemWeb technology my 
focusing on easy cases to do with correct use of RDF and RDFS rather than 
spending too much time and effort on more sophisticated aspects of the best 
use of OWL. I suspect there is a lot of common ground in best practice 
across the range of SW technologies.


My view is that the QCC issue is best left until an OWL2 WG, which will be 
much more likely if the SWBPD WG succeeds in getting OWL and RDF to be 
widely adopted.

Jeremy



Alan Rector wrote:

> 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 05:36:17 UTC