W3C home > Mailing lists > Public > public-swbp-wg@w3.org > January to March 2004

Re: Qualified Cardinality Constraints

From: Christopher Welty <welty@us.ibm.com>
Date: Wed, 10 Mar 2004 15:44:17 -0500
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Cc: best-practice <public-swbp-wg@w3.org>, public-swbp-wg-request@w3.org, Alan Rector <rector@cs.man.ac.uk>
Message-ID: <OFFE5AA8D8.F8E07082-ON85256E53.0071D598-85256E53.0071EBA6@us.ibm.com>
I agree that we shouldn't be making or considering changes to OWL in this 
WG, however it is important to point out representational limitations of 
OWL and how (when possible) to work around them - agreed?

Dr. Christopher A. Welty, Knowledge Structures Group
IBM Watson Research Center, 19 Skyline Dr., Hawthorne, NY  10532     USA   
 
Voice: +1 914.784.7055,  IBM T/L: 863.7055, Fax: +1 914.784.7455
Email: welty@watson.ibm.com, Web: 
http://www.research.ibm.com/people/w/welty/



Jeremy Carroll <jjc@hplb.hpl.hp.com> 
Sent by: public-swbp-wg-request@w3.org
03/10/2004 05:35 AM

To
Alan Rector <rector@cs.man.ac.uk>
cc
best-practice <public-swbp-wg@w3.org>
Subject
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 15:46:49 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 10 March 2004 15:46:59 EST