- From: Guus Schreiber <schreiber@cs.vu.nl>
- Date: Tue, 22 Apr 2003 08:26:12 +0100
- To: Jim Hendler <hendler@cs.umd.edu>, WebOnt WG <www-webont-wg@w3.org>
[chair hat off] Some considerations with respect to the qualified cardinality restrictions (QCRS). 1. Rector's use cases QCRs typically come up in part-of relations. The majority of the use cases is of this type. The standard woraround, as mentioned by Rector (see use case g), is to introduece a subproperty for which the restriction cane be formuletaed as isolated cardinality and value restrictions. E.g.: "The normal hand has five fingers of which one is the thumb" Property hasFinger Property hasThumb subPropertyOf hasFinger Class NormalHand Restriction onProperty hasFinger: cardinality = 5 Restriction onProperty hasThumb: cardinality = 1 Restriction onProperty hasThimb: allValuesFrom Thumb I think the woraraound is OK for simple cases, such as his use case e). Note that (as Pat also pointed out) OWL already contains a construct for qualified cardinality restriction of the "1 or more" type, namely "somValuesFrom". Rector's use case c) is actually not a problem in OWL: one can just add the restriction, that the property HasParent should have "someValuesFrom" BritishCitizen. The workaraound really becomes problematic in cases where complicated part-of relations dominate the ontology. I think the examples under b) are the most compelling from this perspective. Introducing subporprty relations for all the variants is a nightmare. Use cases g) nad h} both introuce some form of metamodelling (hasComponent -> hasLeg; Feature -> BodyTemperature). This will always be cumbersome in a stratified language like OWL DL and can be handled in OWL Full with an explcit metamodel (using classes-as-instances). Although I like the sophistication of these examples, I therefore find them less compelling. In summary, I think domains with complex part-of relations (use cases a+b) provide strong use cases for introducing QCR. 2. QCR language constructs: I guess one can take two position wrt. introducing QCRs into OWL: a) It requires four additional constructs (hasClassQ/valuesFrom plus the three cardinality variants). This seems a lot for one new feature. b) Our current restrictions are in fact all special cases of QCRs (see Pts's message), which implies that introducing a general QCR might actually be better. 3. Explainability Gieven the current state of our documents and provided we select appropriate labels for the QCR constructs I think we can explain it reasonably well to users. It will be antoher burden on the OWL learning curve, but that has nothing to do with QCR in itself. Guus -- NOTE: new affiliation per April 1, 2003 Free University Amsterdam, Computer Science De Boelelaan 1081a, 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 Tuesday, 22 April 2003 03:26:03 UTC