- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Wed, 16 Apr 2003 14:44:34 -0400
- 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. -JH [1] http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0040.html 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) [62.31.16.92] >X-Authenticated-From: Alan.L.Rector@man.ac.uk >X-Spam-Score: -5.7 (-----) >X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) >*195iUS-000Nrw-2i*lLssentK1Eo* >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/> >List-Unsubscribe: ><mailto:public-webont-comments-request@w3.org?subject=unsubscribe> >X-Spam-Status: No, hits=0.0 required=5.0 > tests=SPAM_PHRASE_00_01,SUPERLONG_LINE,USER_AGENT_MOZILLA_XM, > X_ACCEPT_LANG,X_LOOP,X_MAILING_LIST > version=2.43 >X-Spam-Level: >Status: U > > >All > >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 >applications. > >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 >appreciated.. > >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 >uniform. > >I therefore wish to propose that qualified cardinality >restrictions be re-instated, possibly using an amended syntax for >clarity. > >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. > >DISCUSSION: > >The original reasons as quoted on the Issues page were: > >VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV >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 >restrictions:: > > <owl:Restriction> > <owl:onProperty rdf:resource="#exampleProp"/> > <owl:maxCardinality >rdf:datatype="&xsd;nonNegativeInteger">2</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 >classifiers/reasoners. > >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 4.1.2.2 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 4.1.2.2 could easily be >modified extended to cope with this case: > ><owl:Restriction> > <owl:onProperty rdf:resource="#hasParent" /> > <owl:minCardinality >rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality> > <owl:hasClassQ rdf:resource="#BritishCitizen"/> ></owl:Restriction> > >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 >rdf:datatype="&xsd;nonNegativeInteger">4</owl:maxCardinality/> > </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 >rdf:datatype="&xsd;nonNegativeInteger">4</owl:maxCardinality/> > <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, >etc.) > >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** >Unreified: > > <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> > > >Reified: ><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 >rdf:resource="#hasTrend"/> > <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> ></owl:Class> > > >*** > >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. > > >Regards > >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) http://www.cs.umd.edu/users/hendler
Received on Wednesday, 16 April 2003 14:44:47 UTC