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

RE: Qualified Cardinality Constraints

From: Natasha Noy <noy@SMI.Stanford.EDU>
Date: Wed, 10 Mar 2004 18:37:05 -0800
Message-Id: <p06020466bc75809bc796@[]>
To: public-swbp-wg@w3.org


Indeed, while OWL Full does not  explicitly have qualified 
cardinality restrictions, OWL Full can cover many of the cases that 
Alan mentions (though not ideally). Perhaps encoding how to do that 
is a good case for a design pattern? Non-special-purpose reasoners 
probably wouldn't know what to do with them though.

I agree with others who pointed out that the goal of this group is to 
deal with what we have in terms of languages (RDF, OWL). However, 
suggesting to work around some of their limitations is certainly 
within the scope (and should be addressed).

Below are my comments on some of Alan's examples (the list is very 
impressive indeed!)

>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 
>cannot be enforced by the logic and doesn't capture the relations of 
>'at least 3', at most 3', 'exactly 3'.

what about a workaround of creating a property 
hasCarboxylicAcidGroup, a subProperty of hasStructuralComponent, 
cardinality 3 and allValuesFrom CarboxylicAcidGroup. It doesn't 
address the proliferation concern, but seems to deal with all the 
others (assuming you will use this relationships in your definition 
of Krebs Cycle).

>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.

The way the Foundational Model of Anatomy deals with this (or, more 
precisely, a reasonably  accurate translation into OWL of the way FMA 
deals with this, since FMA is not defined in OWL) is by reifying the 
cardinality-value pair. Naturally, only special-purpose reasoners 
will be able to deal with this, and this is very much in OWL Full. 
Also, given the level of detail at which FMA models anatomy, in most 
cases that I've seen (perhaps not all) what you want  for QCRs is 
cardinality 1. In the context of the FMA, these can be handled 
through hasValue restriction (but since values would be classes, it 
is again OWL Full).

>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 
>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.

actually, this one is simple (by virtue of cardinality being 2).
You define cardinality restriction of 2 for spouses property for the 
class Marriage with allValuesFrom (Male OR Female).
Same-sex marriage is a Marriage where (spouse allValuesFrom Male) OR 
(spouse allValuesFrom Female)
"traditional" marriage is a Marriage where (spouse someValuesFrom 
Male) AND (spouse someValuesFrom Female)

Again, not the most straightforward way, but easily handled by OWL 
DL. (After all, we handle all the different marriages pretty easily 
here in the San Francisco area :)

My general point here is that there are ways to deal with these 
(although perhaps it would have been easier if there were QCRs, but 
this is not the forum to discuss pros and cons). And it may indeed be 
a good starting point for some of the design patterns.

Received on Wednesday, 10 March 2004 21:37:09 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 10 March 2004 21:37:13 EST