There are two kinds of cardinality restrictions: qualified and unqualified. This page explains both kinds, but we must consider the following setup model. Setup ModelTo 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.
In order to follow the rest of the explanation, set your OWL export syntax to OWL Functional as shown below. |
Excerpt of the OWL ontologyThe 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 RestrictionFrom 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 RestrictionFrom 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.
|