Re: Case for Reinstatement of Qualified Cardinality Restrictions

[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