- From: Guus Schreiber <schreiber@cs.vu.nl>
- Date: Wed, 16 Apr 2003 11:33:26 +0100
- To: Alan Rector <rector@cs.man.ac.uk>
- CC: public-webont-comments@w3.org
Aan, Thanks very much for your elaborate comment. The working group will discuss this and will get back to you in due course. Guus Schreiber WOWG co-chair Alan Rector wrote: > 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 > > -- NOTE: new affiliation per April 1, 2003 Free University Amsterdam, Computer Science De Boelelaan 1018a, 1081 HV Amsterdam, The Netherlands Tel: +31 20 444 7739/7718 E-mail: schreiber@cs.vu.nl Home page: http://www.cs.vu.nl/~guus/ [under construction]
Received on Wednesday, 16 April 2003 06:33:58 UTC