Qualified Cardinality Restrictions

(Abstract) Syntax
=================

I was thinking a bit more about what would be required in order to add
QCRs to the spec. One thing that occurred to me is that it might be
better/clearer to extend the someValuesFrom restriction rather than
cardinality restrictions. I.e., in the abstract syntax, we would have:

objectRestrictionComponent ::= 'allValuesFrom(' description ')'
            | 'someValuesFrom(' description ')'
            | 'minValuesFrom(' description non-negative-integer ')'
            | 'maxValuesFrom(' description non-negative-integer ')'
            | 'valuesFrom(' description non-negative-integer ')'
            | 'value(' individualID ')'
            | cardinality 

(and similarly for dataRestrictionComponent).

The advantage with this is that it seems clearer to explain the
connection with someValuesFrom than the connection with
cardinality. I.e., after someValuesFrom has been introduced, it seems
quite natural to explain that instances of

restriction(P someValuesFrom(C))

must be related at least one object of type C via property P, and that
in some cases finer control may be required, e.g., using the
restriction

restriction(P valuesFrom(C 3))

instances of which must be related to exactly 3 instances of C via
property P. This also makes it clear that someValuesFrom is just a
special case, i.e.,

restriction(P someValuesFrom(C)) == restriction(P minValuesFrom(C 1))


Semantics
=========

The semantics is also a simple extension of the someValuesFrom semantics:

restriction(p minValuesFrom(e n))  {x \in R | card({<x,y> \in ER(p) ^ y \in EC(e)}) >= n

restriction(p maxValuesFrom(e n))  {x \in R | card({<x,y> \in ER(p) ^ y \in EC(e)}) <= n

restriction(p valuesFrom(e n))  {x \in R | card({<x,y> \in ER(p) ^ y \in EC(e)}) = n


RDF Graphs
==========

Again, the obvious solution seems to be to combine some values from
and cardinality into a single mapping. Simple cardinality constraints
can then use the same mapping with the qualifying class set to
owl:Thing, while someValuesFrom can use the minValuesFrom mapping with
the cardinality set to 1. There are two obvious possibilities for the
mapping, i.e., attaching the min/max/blank to the valuesFrom property
name or to the cardinality property name. The first of these seems
more consistent with the above abstract syntax.

E.g., minVaulesFrom using the valuesFrom property to indicate the "min":

restriction(ID minValuesFrom(required min))   _:x rdf:type owl:Restriction .
_:x rdf:type owl:Class . [opt]
_:x rdf:type rdfs:Class . [opt]
_:x owl:onProperty T(ID) .
_:x owl:minValuesFrom T(required) .
_:x owl:cardinality "min"^^xsd:nonNegativeInteger .

or using the cardinality property to indicate the "min":

restriction(ID valuesFrom(required min))   _:x rdf:type owl:Restriction .
_:x rdf:type owl:Class . [opt]
_:x rdf:type rdfs:Class . [opt]
_:x owl:onProperty T(ID) .
_:x owl:valuesFrom T(required) .
_:x owl:minCardinality "min"^^xsd:nonNegativeInteger .


Reference
=========

Changes to reference would be relatively minor and could follow the
scheme outlined above. E.g.:

The following example defines a class of individuals which have at
least two siblings who are physicians:

<owl:Restriction>
  <owl:onProperty rdf:resource="#hasSibling" />
  <owl:minValuesFrom rdf:resource="#Physician" />
  <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:maxCardinality>
</owl:Restriction>


*OR* using the cardinality property to indicate the "min":

<owl:Restriction>
  <owl:onProperty rdf:resource="#hasSibling" />
  <owl:valuesFrom rdf:resource="#Physician" />
  <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:maxCardinality>
</owl:Restriction>


Guide
=====

Devising food examples should be straightforward - I believe that
several people (including Alan Rector) are working on that.


Test
====

Several of the "hard" reasoning tests that I provided are designed to
test reasoning about QCRs. They could easily be added to the test
cases.


Regards, 

Ian

Received on Monday, 28 April 2003 05:26:20 UTC