There are two kinds of cardinality restrictions: qualified and unqualified. This page explains both kinds, but we must consider the following setup model.
Setup Model
To set up the case for qualified and/or unqualified cardinality restrictions
- Create four classes and two unidirectional object properties such that it looks as shown below.
- Drag and drop the top has pet property onto the bottom has pet property until you see the Create subproperty text.
- Once you drop the property, the following menu will appear. Select the highlighted option.
- The result should look as shown below. Notice the restriction {subset has pet}.
- Now, we export to OWL.
OWL Functional
In order to follow the rest of the explanation, set your OWL export syntax to OWL Functional as shown below.
Excerpt of the OWL ontology
The following code block shows an excerpt of the OWL ontology that marks the distinction between qualified and unqualified cardinality restrictions.
# Class: :CatOwner (Cat Owner) AnnotationAssertion(rdfs:label :CatOwner "Cat Owner"^^xsd:string) SubClassOf(:CatOwner ObjectMinCardinality(2 :hasPet :Cat)) SubClassOf(:CatOwner ObjectMaxCardinality(3 :hasPet :Cat)) # Class: :Person (:Person) SubClassOf(:Person ObjectMinCardinality(2 :hasPet))
Unqualified Cardinality Restriction
From the OWL ontology excerpt above, line 9 shows an unqualified cardinality restriction. It is an unqualified cardinality restriction because the property's type emanating from Person, Pet with cardinality of 2..* does not specify the Pet, such as Cat, that the Person could have.
Qualified Cardinality Restriction
From the OWL ontology excerpt above, line 4 shows a qualified cardinality restriction. It is a qualified cardinality restriction because the property's type emanating from Cat Owner, Cat with cardinality 2..3 specifies the pet, Cat, and the restriction actually says
:Cat. In other words, the restriction in line 4 is more specific than the restriction in line 9; that's why the cardinality restriction in line 4 is qualified.
Related Pages