- From: Alan Rector <rector@cs.man.ac.uk>
- Date: Tue, 17 Jun 2003 09:07:42 +0100
- To: Jim Hendler <hendler@cs.umd.edu>
- Cc: public-webont-comments@w3.org
Jim
As I said in the informal discussions. I accept the practical difficulties; this is probably the least bad short term solution.
I would be very concerned if the postponement were prolonged. We are unable to migrate key applications from DAML+OIL to OWL without QCRs. I am also reluctant to encourage my colleagues who want to start working on Anatomy to use something which is obviously flawed for their requirements and requires awkward work-arounds.
In short, I accept the proposal, reluctantly, but urge the Committee to make the postponement as brief as possible. The longer the delay, the greater the pain when the change is made.
I will read the proposals carefully and comment in due course.
As for QCRs not having been needed in Protege, I suspect this is due to a combination of three factors a) It being being less of a problem in a less expressive language with less inferential power so that the defects in the work arounds are less apparent b) the use of alternatives such as PAL constraints which are not available in OWL; c) just accepting that the only way to do it is to to create multiple slots to carry the load. We know from experience that this solution scales badly and is difficult to understand once you add a classifier.
(BTW I understand that Holger Knublauch at Stanford's implementation of an OWL plugin for Protege has made provisions in the design for extension to QCRs when available.)
Regards
Alan
Jim Hendler wrote:
> Dear Alan:
>
> Let me start by thanking you for your comments -- this commented
> generated much discussion in the working group, all available in the
> public archives of www-webont-wg. I will try to summarize the
> discussion and results here, you are, of course, welcome to explore
> the public archives - some pointers will be provided to make this
> easier.
>
> Briefly, DAML+OIL had a relatively ad hoc mechanism for representing
> Qualified Cardinalities. The WG observed that this was a rarely
> used, and hard to describe, feature (not necessarily the notion of
> QCRs, but the odd language features needed to implement them). We
> thus had decided to remove this feature.
>
> Based on your Last Call comment, we reopened and reconsidered this
> issue. As you can see from [1], it became clear to the group that we
> needed a better mechanism than what was in DAML+OIL to handle this
> issue (and also to handle some other aspects of qualification, for
> example see [2] which discusses the need to also qualify functional
> restrictions). A better mechanism than the one in DAML+OIL for
> representing QCRs was suggested [3], but unfortunately it became
> clear to the group that this would be a major change to the language.
> We therefore decided to reopen the issue of Qualified Cardinality
> Restrictions, and then to POSTPONE this issue with a pointer to Guus'
> proposal. The specific decision to postpone is recorded in [4], the
> rationale accepted by the group, and recorded in ourissues document
> [5] is summarized as:
>
> The Working Group decided 25 Apr 2002 to remove qualified
> cardinality constraints. The issue was reopened due to new
> information Apr 2003 from Alan Rector. In the 8 May 2003
> teleconference, the WG resolved ... to POSTPONE this issue for
> the following reasons:
> * OWL already contains one QCR construct: owl:someValuesFrom (QCR
> with minimal cardinality of 1) which covers some frequent-occurring
> cases of QCRs.
> * There are some workarounds for QCRs, using the rdfs:subPropertyOf
> construct. These can be used in simple cases, such as the example in
> the Guide below. The WG agrees that these workarounds are more
> problematic for complex part-of relations such as pointed out by Alan
> Rector in his use cases a) and b).
> * The evidence on whether users need this is mixed. Rector's use
> cases are compelling, but Protege (which has a large user community)
> has not reported user requests for this feature.
> * Inclusion of this feature will put additional burden on
> implementations. For example, it is nontrivial to add this to
> Protege. The Working Group therefore POSTPONES the full treatment
> of QCRs, while considering possibilities for making idioms or other
> guidelines for QCRs available to the community.
>
> We hope that eventual follow on activities to our working group,,
> will include a general mechanism for handling qualification.
> However, adding these to OWL at this time would be a major step, and
> would require significant effort as, in some cases, there is no
> obvious implementation of these properties that can work with the
> current OWL design.
>
> Please let us know if this decision to (a) acknowledge that our
> design is lacking, but (b) postpone further design work to a future
> version is acceptable.
> -Jim Hendler
>
> [1] http://lists.w3.org/Archives/Public/www-webont-wg/2003Apr/0176.html
> [2]
> http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0074.html
> [3]
> http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0072.html
> [4]
> http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0120.html
> [5]
> http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I3.2-Qualified-Restrictions
> [6]
> http://www.w3.org/TR/webont-req/
>
> At 9:43 AM +0100 4/16/03, 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
>
> --
> 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-277-3388 (Cell)
> http://www.cs.umd.edu/users/hendler *** NOTE CHANGED CELL NUMBER ***
--
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 Tuesday, 17 June 2003 04:46:00 UTC