[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]