W3C home > Mailing lists > Public > www-webont-wg@w3.org > April 2003

Fwd: Case for Reinstatement of Qualified Cardinality Restrictions

From: Jim Hendler <hendler@cs.umd.edu>
Date: Wed, 16 Apr 2003 14:44:34 -0400
Message-Id: <p05200f15bac35440147a@[]>
To: webont <www-webont-wg@w3.org>

The following long message (from [1]) comes from Alan Rector to our 
comments list, addressing the issue of the qualified constraints - 
basically, he's asking us to reopen issue 3.2 Qualified Cardinality 
constraints.  Guus and I would like to hear the WG's feelings on 
this.  Since there's no specific document addressed (although it 
would require changes in every document), Guus and I will handle this 
email and its response.

Resent-Date: Wed, 16 Apr 2003 04:42:36 -0400 (EDT)
>Date: Wed, 16 Apr 2003 09:43:22 +0100
>From: Alan Rector <rector@cs.man.ac.uk>
>X-Accept-Language: en
>To: public-webont-comments@w3.org
>X-Authenticated-Sender: mbassalr from 
>pc-62-31-16-92-sh.blueyonder.co.uk (cs.man.ac.uk) []
>X-Authenticated-From: Alan.L.Rector@man.ac.uk
>X-Spam-Score: -5.7 (-----)
>X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) 
>Subject: Case for Reinstatement of Qualified Cardinality Restrictions
>X-Archived-At: http://www.w3.org/mid/3E9D17AA.4FDF045B@cs.man.ac.uk
>Resent-From: public-webont-comments@w3.org
>X-Mailing-List: <public-webont-comments@w3.org> archive/latest/191
>X-Loop: public-webont-comments@w3.org
>Sender: public-webont-comments-request@w3.org
>Resent-Sender: public-webont-comments-request@w3.org
>List-Id: <public-webont-comments.w3.org>
>List-Help: <http://www.w3.org/Mail/>
>X-Spam-Status: No, hits=0.0 required=5.0
>	version=2.43
>Status: U
>After a further year's experience modelling in DAML+OIL and fully 
>understanding the consequences, I would like to ask that the issue 
>of qualified cardinality restrictions  be reopened  despite having 
>been formally closed in April 2002 because:
>*    It is now clear that all  five reasons put forward for its 
>removal conflict with  experience
>*    The use cases for the inclusion of qualified cardinality 
>restrictions are compelling.
>*    Failing to include qualified cardinality restrictions will 
>seriously limit OWL's usefulness for applications already in 
>progress using DAML+OIL as an interim measure pending the 
>availability of OWL.  This will cause a serious backwards 
>computability problem and may prevent migration entirely for some 
>Discussion in the broader community was limited at the time of the 
>original  decision. I do not believe the nature and implications of 
>withdrawing qualified cardinality restrictions were widely 
>The change to the syntax would be minimal.  The semantics are 
>already supported by all DL classifiers likely to be used with OWL 
>DL.  The data model for the language would be, if anything, more 
>I therefore wish to propose  that  qualified cardinality 
>restrictions be re-instated, possibly using an amended syntax for 
>Below I discuss in turn each of the original points cited in 
>opposing qualified cardinality restrictions as quoted in the Issues 
>document and then give a set of eight use cases/examples.  Further 
>examples can be made available if needed.
>The original reasons as quoted on the Issues page were:
>3.2 Qualified Restrictions
>          Qualified restrictions (cardinalityQ, etc.). Unaccounted 
>for DAML+OIL feature.
>          Proposed resolution by Jeremy Carrol on 19 Apr 2002. See 
>also Jeremy Carrol email of 24 Apr 2002.
>          At the face2face no one wished to include qualified 
>restrictions in OWL.
>          The qualified restrictions of DAML+OIL:
>               have added to the difficulty of learning the language
>               have not been used in practice
>               are barely understood by the community
>               potentially add to the difficulty of implementing the language
>               have no compelling use cases
>To take the points in order.
>I.) "have added to the difficulty of learning the language".  This 
>is not our experience. After many tutorials by numerous different 
>instructors on DAML+OIL using OilEd at levels ranging from casual 
>users to undergraduate and postgraduate students to practising 
>scientists in a variety of disciplines we have not found this to be 
>the case. The notion that there are three types of restrictions - 
>someValuesFrom, allValuesFrom, at-least n, at-most n, exactly n - 
>causes no difficulty.  The fact that the  cardinality constructs are 
>parallel to "someValuesFrom" and "allValuesFrom" makes them easy to 
>teach and learn.  We believe a seemingly arbitrary difference 
>requiring awkward "workarounds" would actually make the language 
>more difficult to teach. ( The syntactic difference in the XML 
>syntax, can be easily hidden from the user.- or the committee might 
>seek to modify them as suggested below)
>Furthermore, we have extensive experience of teaching and developing 
>ontologies using a language with limitations analogous to the 
>proposed withdrawal of qualified cardinality restrictions, GRAIL. 
>Experience shows that the analogous limitations are are a major 
>impediment to teaching learning.  In GRAIL, working around these 
>limitations tends to lead to a proliferation of special sub 
>properties for special situations.  The use of these subproperties 
>is obscure and a difficult to learn.  We have seen their elimination 
>as one of the major benefits of a switch to OWL.  We see the design 
>decision in to include the analogous limitation in GRAIL as one of 
>our major mistakes in language design. We would not want to see it 
>repeated in OWL.
>II). "have not been used in practice".  We use them extensively in 
>practice in a wide variety of ontologies in a wide variety of 
>disciplines. .  See use cases below.  We believe that biological, 
>medical and organisational ontologies, at least, will be seriously 
>limited if they are removed. However, many of the issues extend well 
>beyond biology and medicine, for example effecting  bench-marks for 
>knowledge based systems such as the British Nationality Act case 
>which have been in use for twenty years or more.
>III.) "Are barely understood by the community".  I would be 
>interested to know the evidence for this statement.  It
>does not fit with our experience - see comments on teaching in I) 
>above.   Furthermore, analogous constructs are available in other 
>formalisms such as UML where the same relation can have different 
>cardinalities when linking one concept to each of two or more 
>concepts.  They appear to cause no confusion in these formalisms. 
>Why is it believed that they will do so in OWL?. If the syntax is 
>obscure, a suggested change is given in IV.
>IV) "potentially add to the difficulty of implementing the language" 
>- this again appears odd.
>a) Syntax: In the XML/RDF form they add little  extra syntactic complexity
>    <owl:Restriction owl:cardinalityQ="1">
>       <owl:onProperty rdf:resource="#exampleProp"/>
>       <owl:hasClassQ rdf:resource="#exampleClass"/>
>    </owl:Restriction>
>It might be argued that the label "hasClassQ" is obscure and might 
>be made more consistent with other notions by
>relabelling it as "valuesFrom", or one might express the structure 
>as three triples with a slight adjustment elsewhere so
>as to achieve something like the following which would have the same 
>effect and some might find clearer in a form such as that given 
>below extending, slightly, the syntax for unqualified number 
>    <owl:Restriction>
>       <owl:onProperty rdf:resource="#exampleProp"/>
>       <owl:maxCardinality 
>       <owl:valuesFrom rdf:resource="#exampleClass"/>
>    </owl:Restriction>
>In either case, the added difficulty in parsing the syntax is minimal.
>b) Semantics: All of the classifiers likely to be used with OWL 
>implement qualified cardinality restrictions.  Therefore,
>the issue of implementation difficulty appears to apply neither to 
>the OWL form nor the implementation of
>c) Data model: with this limitation there are two models for 
>"restrictions", one involving a filler class, the other not. If the 
>limitation is removed there need be only a single model - "class 
>property QuantifierOrCardinality class"
>If the implementation difficulty lies neither in the syntax, nor the 
>semantics, nor the information model, where then does it lie?
>V) "There are no compelling use cases."  To the contrary.  Where 
>cardinality restrictions are required, we have found that it is 
>almost always qualified cardinality restrictions rather than 
>unqualified restrictions which are required.  Consider the following 
>use cases/examples, all of which have arisen in the development of 
>real ontologies for real applications:
>a)    Anatomy:  "The normal hand has exactly five fingers of which 
>one is a thumb"  (It has many other subdivisions
>including the palm, back of the hand, thenar region, etc.so an 
>unqualified restriction on the property has-subdivision
>does not capture the meaning. (innumerable similar examples, e.g. 
>"The heart has four chambers two atria and two
>ventricles", etc.  The number of cases in anatomy is legion.
>b)  Bio-ontologies and chemistry: i) "Tricarboxylic acid contains 
>exactly three carboxyl groups" - but also an acidic
>group.  "GPCRs have exactly seven trans-membrane alpha-helixes" (but 
>many other subunits which distinguish one
>GPCR from another).  (GPCRs are an important class of receptor 
>proteins in cellular control and the subject of virtually an
>entire sub-discpline of molecular biology.) "Haemoglobin consists of 
>four subunits each of which contains exactly one haem group each of 
>which contains exactly one iron ion" - each subunit consists of 
>numerous other groups besides the haeme group and contains many 
>other ions.
>c) Specifying common concepts in well established applications  used 
>to benchmark test knowledge based systems.  The example below is 
>taken from the British Nationality Act system and extends the 
>example under in the OWL Reference. The given restriction 
>limits a person to two  fillers of the relation "hasParent".  An 
>important concept in the British Nationality Act is a "Person who 
>has at least one parent who is a British Citizen"
>The original unqualified restriction in could easily be 
>modified  extended to cope with this case:
>   <owl:onProperty rdf:resource="#hasParent" />
>   <owl:minCardinality 
>   <owl:hasClassQ rdf:resource="#BritishCitizen"/>
>where BritishCitizen is defined elsewhere as a person and citizen of the UK.
>Note that is no satisfactory work around for this case.  Defining a 
>more specific property "#hasParentWithCitizenship" is a poor 
>solution because the information on parentage would not normally be 
>entered in that way.  Not being able to express such notions will 
>markedly reduce the use of OWL to specify ontologies for KBSs. (The 
>British Nationality Act has been usd as a benchmark example for KBSs 
>in the UK since the early 1980s.)
>d)  Specifying common constructs in health records and other data 
>models in ways familiar to data modellers, e.g.:
>"A blood pressure reading consists of exactly one diastolic and one 
>systolic reading" (but may include readings for "third phase" and 
>"fourth phase".)  Again, an unqualified restriction on the 
>'consists-of' property will not work because there can be further 
>fillers of different types.  This pattern is extremely common in 
>models originally presented in UML and familiar to all UML 
>modellers. It will seem  odd to UML modellers not to have access to 
>such constructs.
>e) Representation of administrative structures in the health service 
>and no doubt many other organisations.  For example: "Oversight 
>committees consists of at least 5 members of which two must be 
>medically qualified, one a manager, and two members of the public"
>f) Specification of important named types of interactions for the 
>drug ontology and prescribing e.g. "Regime containing more than one 
>Central Nervous System depressant" (A standard hazard warning 
>class).  The regime of course may consist of any number
>of drugs, the issue is that at least two of them are Central Nervous 
>System Depressants.
>g) To allow abstraction.  (a variation of case c above) Without 
>qualified number restriction, things may have to be expressed with 
>extra properties which are unlikely to be used consistently.  This 
>is particularly important with properties such as hasPart, where 
>there may need to be a complex hierarchy of kinds of part-whole 
>relations - see Odell and Winston.  The example below abstracts the 
>property "hasLegs" to the more general property "hasComponent", a 
>specific subproperty of "hasPart".   Having extra subproperties for 
>each component whose number were to be specified would be cumbersome 
>to say the least.
>**Using unqualified cadinalities:**
>     <owl:Class rdfs:ID="#Chair">
>         <rdfs:subClassOf resource="#PhysicalThing"/>
>         <owl:Restriction>
>                   <owl:onProperty rdf:resource="#hasLeg"/>
>                   <owl:cardinality 
>          </owl:Restriction>
>      </owl:Class>
>which requires in the axiom (or equivalent)::
>       <owl:ObjectProperty rdf:ID="hasLeg">
>            <rdfs:subPropertyOf rdf:resource="#hasComponent"/>
>       </owl:ObjectProperty>
>**Using qualified cardinalities:**
>     <owl:Class rdfs:ID="#Chair">
>         <rdfs:subClassOf resource="#PhysicalThing"/>
>         <owl:Restriction>
>                    <owl:onProperty rdf:resource="#hasComponent"/>
>                   <owl:cardinality 
>                    <owl:hasClassQ rdf:resource="#Leg"/>
>          </owl:Restriction>
>      </owl:Class>
>h) "Reification" of properties as features. (i.e. "nominalising" a 
>relation from a property to a verb - formally replacing a single 
>property by a pair of properties plus a class)  In general it is 
>possible to generalise any schema of the form
>        ObjectClass-property-ValueClass
>to a schema of the form
>         ObjectClass-property1-FeatureRepresentingProperty-property2-ValueClass
>This is a common requirement  to allow the Feature to be further 
>described. It also allows features to be have definitions which can 
>be classified by the classifier to avoid manual maintenance of 
>tangled hierarchies of properties.  (In general, since the 
>classifier works only on classes, it is better to keep the hierarchy 
>of properties relatively simple.)   The specific example below is 
>medical and taken from work by Yuval Shahar at Stanford.  In our 
>experience, however, analogous pattern arises  very commonly as 
>authors  make their ontologies more generic and re-usable..  The 
>advantages of added expressiveness and generality have repeatedly 
>ben found to outweighs the added complexity.
>**Informal Version**
>--Without reification:--
>    FeverishPatient equivalentClass (Patient and (restriction 
>hasBodyTemperature someValuesFrom Elevated))
>--with reification in order to allow us to say that the temperature 
>is elevated but falling.--
>     FeverishPatientGettingBetter equivalentClass
>                 (Patient and (restrction hasFeature someValuesFrom
>                                    (BodyTemperature and 
>(restriction hasLevel (someValuesFromElevated) and
>(restrction hasTrend (someValuesFrom Falling))))
>to make this work we need a high level axiom
>     Patient hasFeature cadinality=1 BodyTemperature.
>A Patient can have many different Features, but only one of type 
>BodyTemperatures.  (Others might be Pulse_rate, White_cell_count, 
>Without qualified number restrictions we are left with unpalatable 
>and unsatisfactory choices.  We can a) use a special 
>hasTemperatureFeature for the property linking to the Feature, but 
>i) this leads to a proliferation of redundant features, something 
>that users of GRAIL have found extremely irritating, and ii) Correct 
>use of the correct subproperty cannot be checked  in OWL because we 
>cannot prevent the use of the hasFeature property instead of the 
>hasTemperatureFeature property. (GRAIL contains a special checking 
>mechanism - sanctions - which makes this possible but we do not 
>suggest importing it to OWL)
>Hence this extremely important general schema - widely used 
>throughout many ontologies - is crippled without qualified 
>cardinality restrictions.
>**Examples in XML syntax**
>      <owl:Class rdf:ID="FeverishPatient">
>       <owl:equivalentClass>
>          <owl:intersectionOf rdfparseType="Collection">
>             <owl:Class rdf:resource="#Patient"/>
>             <owl:Restriction>
>                  <owl:onProperty resource="#hasBodyTemperature"/>
>                  <owl:someValuesFrom source="#elevated"/>
>              </owl:Restrction>
>           </owl:intersectionOf>
>        </owl:equivalentClass>
>    </owl:Class>
><owl:Class rdf:ID="FeverishPatient">
>       <rdfs:equivalentClass>
>          <owl:intersectionOf rdf:parseType="Collection">
>             <owl:Class rdf:resource="#Patient" \>
>             <owl:Restriction>
>                     <owl:onProperty rdf:resource="#hasFeature"/>
>                     <owl:someValuesFrom>
>                         <owl:intersectionOf rdf:parseType="Collection">
>                               <owl:Class rdf:resource="#BodyTemperature"/>
>                               <owl:Restriction>
>                                     <owl:onProperty rdf:resource="#hasLevel"/>
>                                     <owl:someValuesFrom="#Elevated"/>
>                               </owl:Restiction>
>                               <owl:Restriction>
>                                       <owl:onProperty 
>                                       <owl:someValuesFrom="#Falling"/>
>                                </owl:Restriction>
>                            </owl:intersectionOf>
>                         </owl:someValuesFrom>
>               </owl:Restriction>
>          </owl:IntersectionOf>
>        </rdfs:equivalentClass>
>    </owl:Class>
>Auxiliary axiom for reification:
><owl:Class rdf:about="#Patient">
>       <rdfs:subClassOf>
>          <owl:Restriction owl:cardinalityQ="1">
>             <owl:onProperty rdf:resource="#hasFeature"/>
>             <owl:hasClassQ rdf:resource="#BodyTemperature"/>
>         </owl:Restriction>
>      </rdfs:subClassOf>
>I believe the above use cases make a strong case for the 
>re-inclusion of qualified cardinality restrictions, possibly with an 
>altered keyword and syntax (e.g. "valuesFrom" instead of 
>"hasClassQ") to make their meaning clearer.  The  semantics is 
>already supported by all existing classification software for OWL. 
>The change to the syntax and parsing would be minimal. The increase 
>in the range of applications able to use OWL unaltered would be 
>greatly increased.
>Alan Rector
>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
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
Received on Wednesday, 16 April 2003 14:44:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:52 UTC