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:
- Discussions over future status of QCRs with in the course of any
revision of the OWL standard
- General references to QCRs in the Description Logic literature
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
Basics
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:
Class(Minimal_Italian_Dinner,
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:
- The dinner must include exactly one "antipasto" (starter)
- The dinner must include exactly one "dolce" (desert)
- The dinner must include exactly one of either "primo piatoo"
(first dish) or "secondo piatoo" (second dish)
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.
- Anatomy:
- "The normal hand has exactly five fingers of which one is a
thumb."
- "The heart has four chambers: two atria and two ventricles."
- Bio-ontologies and chemistry:
- "Tricarboxylic acid contains exactly three carboxyl groups and
opne acidic group."
- "Haemoglobin consists of four subunits, each of which contains
exactly one haem group, each of which contains exactly one iron ion."
- Many legal strictures, e.g.
the British Nationality Act:
- An important concept in the act is of a "Person who has at least
one parent who is a British citizen".
- Administrative structures:
- "A medical oversight committee must consist of at least five
members of which two must be medically qualified, one a manager, and
two members of the public."
- Drug interactions:
- "A legal drug regimen must not contain more than one Central
Nervous System depressant, although it may contain any number of drugs
in total."
- N-ary relations - see SWBP draft note.
- "A person may have any number of 'features' or 'qualities', but
(at a given time) only one of each: e.g.
one 'height', one 'weight', one 'body temperature', etc.
each of which can have a value, an undertainty on that value, and a
measure of its change or trend."
- "An employee may have many relationships with other employees,
but only one lline manager relationship."
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
intersectionOf(Person,
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:
has_part
has_finger
has_thumb
We could then represent the "normal hand" by:
Class(Normal_hand partial
intersectionOf(
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(Course)
Class(Starter partial Course)
Class(Main_course partial Course)
Class(Desert partial Course)
ObjectProperty(has_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
intersectionOf(
Restriction(
has_starter cardinality(1) ))
Restriction( has_main_course cardinality(1) ))
Restriction(
has_desert cardinality(1) )) ))
Discussion
This pattern suffices for simple cases but presents several problems:
- 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.
- 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.
- 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
owl:onProperty, pointing to the property concerned- 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
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
intersectionOf(
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
intersectionOf(
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
intersectionOf(
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
intersectionOf(
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
intersectionOf(
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.
Discussion
- 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]
- The intended semantics fully capture the intent of the use cases
given.
- Simple cardinalty restrictions can be taken as a special case of
Qualified Cardinality Restrictions where qualifying argument is
valuesFrom(owl:Thing).
Notes
[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
- Reformatted and restructured
- Examples and use cases extended
- Ordering of named arguments in abstract syntax modified for
improved readability