Qualified cardinality restrictions (QCRs):  Constraining the number of values of a particular type for a property

W3C Editor's Draft 02 November 2005

This version:
Latest version:
Previous versions:
<>Alan Rector, University of Manchester
Guus Schreiber
IBM Research

Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.


It is often useful to express constraints such as "has exactly four parts that are legs", "has at least two groups that are  phosphate groups", "has exactly one feature that is temperature", etc.  In each of these cases, we want to constrain not the total number of values for a property, but rather the number of values of a given type.  Such restrictions are called "qualified cardinality restrictions" ("QCRs") because they are "qualified" by the type of the value.  They are supported in most modern description logics but were omitted from the final version of the OWL standard.  This note discusses the uses of such constraints, a partial "work around" within the OWL standard, and a natural extension to the OWL standard to allow it to express QCRs correctly.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document will be a part of a larger document that will provide an introduction and overview of all ontology design patterns produced by the Semantic Web Best Practices and Deployment Working Group.

This document is a W3C Working Draft and is expected to change. The SWBPD WG does not expect this document to become a Recommendation. Rather, after further development, review and refinement, it will be published and maintained as a WG Note.

As a candidate Public Editors Draft, we encourage public comments. Please send comments to public-swbp-wg@w3.org

Open issues, todo items:

Publication as a draft does not imply endorsement by the W3C Membership. This document is a draft and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to cite this document as other than work in progress.

General issues


Cardinality restrictions are commonly used to constrain the number of values of a particular property, irrespective of the value type.  For example, we can state that a "Minimal Italian Dinner" contains exactly three courses:

     subClassOf( Restriction( has_course, cardinality(3) )))

(NOTE: Some Italian restaurants in the US consider you a dummy when you skip either primo or secondo, but it is quite common in contemporary Italy)

However, suppose we wanted to add the following constraints for minimal Italian dinners:
To express these constraints we need a way to restrict the valujes of a particular type (e.g. starters) to a particular value (e.g. 1).   We call such constraints "qualified cardinality restrictions", where the term "qualified" indicates that they apply only to a specific type of value rather than to the property overall.

Use cases

Rector [1] mentions a number of use cases, and others have arisen in the course of developing ontologies for various communities.  In general the use cases occur where there are many different kinds of parts, features, chemical groups, legal statuses, qualities, etc.  In such cases defining a separate property or 'slot' for each is cumbersome at best and difficult to extend. 
  1. Anatomy:
  1. Bio-ontologies and chemistry:
  1. Many legal strictures, e.g. the British Nationality Act:
  1. Administrative structures:
  1. Drug interactions:
  1. N-ary relations - see SWBP draft note

Representation Pattern 1: Use owl:someValuesFrom

The OWL construct someValuesFrom is actually a qualified restriction in disguise.  It is equivalent to a qualified cardinality restriction with a minimum cardinality of 1:  i.e. "this property must have at least one value of this type."

The someValuesFrom constructor can be used to constrain an Italian dinner to have at least one antipasto:

Class(Italian_Dinner partial
      Restriction( has_course, someValuesFrom (AntiPasto) ))

The example in use case 3 above could also be expressed simply using someValuesfrom:

Class(Person_with_British_parent partial
                     Restriction( has_parent someValuesFrom(British_Citizen) )))

However, this approach is not useful for values other than "at least one" or for imposing maximum cardinalities.  It therefore cannot deal with the other uses cases or generalisations of 3 such as "at least two grandparents who were British citizens".

Representation Pattern 2: 'Work around" using subPropertyOf

A common 'work around' to deal with other cardinalities is to introduce a subproperty of the primary property and then to introduce an unqualified cardinality restriction on that subproperty.

For example, we might represent the "normal hand" example from use case 1 by:

Class(Finger partial Body_part)
Class(Thumb partial Finger)

ObjectProperty(has_part                     range(Body_part))
ObjectProperty(has_finger super(has_part)   range(Finger))
ObjectProperty(has_thumb  super(has_finger) range(Thumb))

We would then hve the property hierarchy:


We could then represent the "normal hand" by:

Class(Normal_hand partial
      Restriction( has_finger cardinality(5))
      Restriction( has_thumb cardinality(1)) ))

This workaround can also be used to represent the constraints on "Minimal Italian Dinners"

Class(Starter partial Course)
Class(Main_course partial Course)
Class(Desert partial Course)

ObjectProperty(has_starter    super(has_couse)  range(Starter))
ObjectProperty(has_main_couse super(has_course) range(Main_course))
ObjectProperty(has_desert,    super(has_course) range(Desert))

Class(Minimal_Italian_Dinner partial
     Restriction( has_starter     cardinality(1) ))
     Restriction( has_main_course cardinality(1) ))
     Restriction( has_desert      cardinality(1) )) ))


This pattern suffices for simple cases but presents several problems:
  1. The constraints are incomplete because the range of the super property must subsume the ranges of the subproperties.  Therefore, there is no way to prevent the use of the parent property inappropriately.  For example, we could add another desert to the "Minimal Italian Dinner"
              restriction( has_dessert someValuesFrom(Tiramasu_course)))
    restriction( has_course someValuesFrom(IceCream_course)))

    Assuming that IceCream_course is a kind of Desert is a kind of Course, this is legal according to the OWL constraints but not their intent, which was to restrict the "minimal" dinner to exactly one each of starter, main, and desert.  There is no way to constrain the range of the property has_course without that constraint also applying to its subproperties, so there is no way around this problem except to use tools to impose additional constraints based on annotations or meta properties which are outside the OWL syntax.

  2. In cases where there are many different kinds of things to be constrained, this pattern gives rise to vast numbers of subproperties.  For example, for the anatomy example, there would have to be one subproperty for each kind of body part.  And again, the parent property cannot be constrained so that there is no way of preventing expressions analogous to the extra desert in 1 above.

  3. In the case of n-ary relations, a separate property is similarly required for each feature type, which similarly gives rise to vast numbers of properties, e.g. has_temperature_feature, has_height_feature, etc.  

Representation Pattern 3: Use a non-endorsed OWL extension

The Web Ontology Working Group has postponed the issue of full representation of QCR [2], but has at the same time already suggestd an OWL representation for them [3]. It is not unlikely that this extension will be incoporatd into a future version of the language.  OWL users who require QCRs for use cases not well served by the work around in Representation 2 may want to use this extension, even though they are not yet endorsed. (At least one widely used tool already supports QCRs as do many of the widely used classifiers.)

The syntax looks like this [3].  Qualified restrictions resemble regular restrictions but contain one extra triple in the RDF representation and an extra argument in the abstract syntax.

In the RDF a simple cardinality constraint contains just two triples
  1. owl:onProperty, pointing to the property concerned
  2. a cardinality constraint (owl:cardinality, owl:minCardinality or owl:maxCardinality), which restricts the number of values the property can take.
To this a qualified cardinality constraint need only add a third triple
  1. owl:valuesFrom, pointing to the value type being restricted.
In the abstract syntax, we need only add an additional argument to the cardinality restrictions, e.g.

restriction(ACardinality(n) valuesFrom(AClass))

where ACardinality can be any of minCardinality, maxCardinality or Cardinality and AClass is the class being restricted.   For example the exampoleof minimal italilan dinner might be represented as:

Class(Minimal_Italian_Dinner partial

    Restriction( has_course cardinality(3))
    Restriction( has_course cardinality(1) valuesFrom(Starter))
    Restriction( has_course cardinality(1) valuesFrom(Main_course))
    Restriction( has_course cardianlity(1) valuesFrom(Desert)) ))

The normal hand example can be expressed in a similar way:

Class(Normal_hand partial

     Restriction( has_part cardinality(5) valuesFrom(Finger))
     Restriction( has_part cardinality(1) valuesFrom(Thumb)) ))

In this representation the  pattern for many n-ary relations (use case 6) is illustrated by:

Class(Patient partial
   Restriction(has_feature cardinality(1) valuesFrom(Body_temperature))
   Restriction(has_feature cardinality(1) valuesFrom(Pulse_rate)) ))

Class(Body_temperature partial Feature)
Class(Pulse_rate partial Feature)
Class(Feature partial

    restriction(has_level someValueFrom(LevelValue))
    restriction(has_trend someValueFrom(TrendValue)) ))

where has_level and has_trend are functional properties but has_feature is not functional.   Hence any patient might have many features (of which just two are shown here), but each  Feature could have just one level and one trend.

A still more complex case, illustrated by use case 4 would be:

Class(Medical_oversight_committee partial Committee
    Restriction(has_member minCardinality(5))
    Restriction(has_member minCardinality(2) valuesFrom(Medical_staff))
    Restriction(has_member minCardinality(1) valuesFrom(Manager_staff))
    Restriction(has_member minCardinality(2) valuesFrom(Member_of_public)) ))

Expressing this complex constraint using the work around in Representation Pattern 2 would require defining three separate subproperties of has_member and would still not fully capture the constraints required.


  1. This represtation will be legal in OWL Full according to the current standard.  According to the OWL Reference, RDF/OWL parsers should produce a warning message when non-endorsed OWL vocabulary is used, but should otherwise proceed normally.  However, the semantics will only be treated correctly by parsers and classifiers which are 'QCR aware'. [Note 4]

  2. The intended semantics fully capture the intent of the use cases given.

  3. Simple cardinalty restrictions can be taken as a special case of Qualified Cardinality Restrictions where qualifying argument is valuesFrom(owl:Thing).


[1]  As of the time of writing, Racer is known to support QCRs and FaCT++ is expected to do so shortly.  Protege-OWL and the CO-ODE plugins provide syntactic and user interface support for  an extension to OWL including QCRs.


[1] http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0040.html
[2] http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I3.2-Qualified-Restrictions
[3] http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0072.html