OWL Constraint Examples
This page contains OWL constraint examples to aid you in writing your own data quality constraints.
Page Contents
Let’s look at some OWL constraint examples that show these constraints work. These examples use OWL 2 Manchester syntax, and they assume a simple data schema, which is available as an OWL ontology and as a UML diagram below.
The examples assume that the default namespace is <http://example.com/company.owl#>
and that xsd:
is bound to the standard, <http://www.w3.org/2001/XMLSchema#>
.
Reference Java code is available for each of the following examples in Github.
Subsumption Constraints
This kind of constraint guarantees certain subclass and superclass (i.e., subsumption) relationships exist between instances.
Managers must be employees.
Constraint
:Manager rdfs:subClassOf :Employee
Database A (invalid)
:Alice a :Manager .
Database B (valid)
:Alice a :Manager , :Employee .
This constraint says that if an RDF individual is an instance of Manager
, then it must also be an instance of Employee
. In A, the only instance of Manager
, namely Alice
, is not an instance of Employee
; therefore, A is invalid. In B, Alice
is an instance of Database both Manager
and Employee
; therefore, B is valid.
Domain-Range Constraints
These constraints control the types of subjects and objects used with a property.
Only project leaders can be responsible for projects
Constraint
:is_responsible_for rdfs:domain :Project_Leader ;
rdfs:range :Project .
Database A (invalid)
:Alice :is_responsible_for :MyProject .
:MyProject a :Project .
Database B (invalid)
:Alice a :Project_Leader ;
:is_responsible_for :MyProject .
Database C (valid)
:Alice a :Project_Leader ;
:is_responsible_for :MyProject .
:MyProject a :Project .
This constraint says that if two RDF instances are related to each other via the property is_responsible_for
, then the subject must be an instance of Project_Leader
and the object must be an instance of Project
. In Database A, there is only one pair of individuals related via is_responsible_for
, namely (Alice, MyProject)
, and MyProject
is an instance of Project
; but Alice
is not an instance of Project_Leader
. Therefore, A is invalid. In B, Alice
is an instance of Project_Leader
, but MyProject
is not an instance of Project
; therefore, B is not valid. In C, Alice
is an instance of Project_Leader
, and MyProject
is an instance of Project
; therefore, C is valid.
Only employees can have an SSN.
Constraint
:ssn rdfs:domain :Employee
Database A (invalid)
:Bob :ssn "123-45-6789" .
Database B (valid)
:Bob a :Employee ;
:ssn "123-45-6789" .
This constraint says that if an RDF instance i
has a data assertion via the the property SSN
, then i
must be an instance of Employee
. In A, Bob
is not an instance of Employee
but has SSN
; therefore, A is invalid. In B, Bob
is an instance of Employee
; therefore, B is valid.
A date of birth must be a date.
Constraint
:dob rdfs:range xsd:date
Database A (invalid)
:Bob :dob "1970-01-01" .
Database B (valid)
:Bob :dob "1970-01-01"^^xsd:date
This constraint says that if an RDF instance i
is related to a literal l
via the data property DOB
, then l
must have the XML Schema type xsd:date
. In A, Bob
is related to the untyped literal "1970-01-01"
via DOB
so A is invalid. In B, the literal "1970-01-01"
is properly typed so it’s valid.
Participation Constraints
These constraints control whether or not an RDF instance participates in some specified relationship.
Each supervisor must supervise at least one employee.
Constraint
:Supervisor rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :supervises ;
owl:someValuesFrom :Employee
] .
Database A (valid)
:Alice a owl:Thing .
Database B (invalid)
:Alice a :Supervisor .
Database C (invalid)
:Alice a :Supervisor ;
:supervises :Bob .
Database D (valid)
:Alice a :Supervisor ;
:supervises :Bob .
:Bob a :Employee
This constraint says that if an RDF instance i
is of type Supervisor
, then i
must be related to an individual j
via the property supervises
and also that j
must be an instance of Employee
. In A, Supervisor
has no instances; therefore, A is trivially valid. In B, the only instance of Supervisor
, namely Alice
, is related to no individual; therefore, B is invalid. In C, Alice
is related to Bob
via supervises
, but Bob
is not an instance of Employee
; therefore, C is invalid. In D, Alice
is related to Bob
via supervises
, and Bob
is an instance of Employee
; hence, D is valid.
Each project must have a valid project number.
Constraint
:Project rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :number ;
owl:someValuesFrom
[ a rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions ([xsd:minInclusive 0] [ xsd:maxExclusive 5000])
]
] .
Database A (valid)
:MyProject a owl:Thing .
Database B (invalid)
:MyProject a :Project
Database C (invalid)
:MyProject a :Project ;
:number "23" .
Database D (invalid)
:MyProject a :Project ;
:number "6000"^^xsd:integer .
Database E (valid)
:MyProject a :Project ;
:number "23"^^xsd:integer .
This constraint says that if an RDF instance i
is of type Project
, then i
must be related via the property number
to an integer between 0
and 5000
(inclusive)—that is, projects have project numbers in a certain range. In A, the individual MyProject
is not known to be an instance of Project
so the constraint does not apply at all and A is valid. In B, MyProject
is an instance of Project
but doesn’t have any data assertions via number
so B is invalid. In C, MyProject
does have a data property assertion via number
but the literal "23"
is untyped–that is, it’s not an integer–therefore, C is invalid. In D, MyProject
is related to an integer via number
but it is out of the range: D is invalid. Finally, in E, MyProject
is related to the integer 23
which is in the range of [0,5000]
so E is valid.
Cardinality Constraints
Employees must not work on more than 3 projects.
Constraint
:Employee rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :works_on;
owl:maxQualifiedCardinality "3"^^xsd:nonNegativeInteger ;
owl:onClass :Project
] .
Database A (valid)
:Bob a owl:Thing.
Database B (valid)
:Bob a :Employee ;
:works_on :MyProject .
:MyProject a :Project .
Database C (invalid)
:Bob a :Employee ;
:works_on :MyProject , :MyProjectFoo , :MyProjectBar , :MyProjectBaz .
:MyProject a :Project .
:MyProjectFoo a :Project .
:MyProjectBar a :Project .
:MyProjectBaz a :Project .
If an RDF instance i
is an Employee
, then i
must not be related via the property works_on
to more than 3 instances of Project
. In A, Bob
is not known to be an instance of Employee
so the constraint does not apply and the A is valid. In B, Bob
is an instance of Employee
but is known to work on only a single project, namely MyProject
, so B is valid. In C, Bob
is related to 4 instances of Project
via works_on
.
Stardog ICV implements a weak form of the unique name assumption, that is, it assumes that things which have different names are, in fact, different things. The standard inference semantics of OWL 2 do not adopt the unique name assumption because, in information integration scenarios, things often have more than one name but that doesn’t mean they are different things. For example, when several databases or other data sources all contain some partial information about, say, an employee, but they each name or identify the employee in different ways. OWL 2 won’t assume these are different employees just because there are several names.
Since Stardog ICV uses closed world (instead of open world) semantics, it assumes that the different projects with different names are, in fact, separate projects, which (in this case) violates the constraint and makes C invalid.
Strictly speaking, this is a bit misleading. Stardog ICV uses both open and closed world semantics: since inferences can violate or satisfy constraints, and Stardog uses open world semantics to calculate inferences, then the ICV process is compatible with open world reasoning, to which it then applies a form of closed world validation, as described in this chapter.
Departments must have at least 2 employees.
Constraint
:Department rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty [owl:inverseOf :works_in] ;
owl:minQualifiedCardinality "2"^^xsd:nonNegativeInteger ;
owl:onClass :Employee
] .
Database A (invalid)
:MyDepartment a owl:NamedIndividual .
Database B (invalid)
:MyDepartment a :Department .
:Bob a :Employee ;
:works_in :MyDepartment .
Database C (valid)
:MyDepartment a :Department .
:Alice a :Employee ;
:works_in :MyDepartment .
:Bob a :Employee ;
:works_in :MyDepartment .
This constraint says that if an RDF instance i
is a Department
, then there should exist at least 2 instances j
and k
of class Employee
which are related to i
via the property works_in
(or, equivalently, i
should be related to them via the inverse of works_in
). In A, MyDepartment
is not known to be an instance of Department
so the constraint does not apply. In B, MyDepartment
is an instance of Department
but only one instance of Employee
, namely Bob
, is known to work in it, so B is invalid. In C, MyDepartment
is related to the individuals Bob
and Alice
, which are both instances of Employee
and (again, due to weak Unique Name Assumption in Stardog ICV), are assumed to be distinct, so C is valid.
Managers must manage exactly 1 department.
Constraint
:Manager rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :manages ;
owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
owl:onClass :Department
] .
Database A (valid)
:Isabella a owl:Thing .
Database B (invalid)
:Isabella a :Manager .
Database C (invalid)
:Isabella a :Manager ;
:manages :MyDepartment .
Database D (valid)
:Isabella a :Manager ;
:manages :MyDepartment .
:MyDepartment a :Department .
Database E (invalid)
:Isabella a :Manager ;
:manages :MyDepartment , :MyDepartment1 .
:MyDepartment a :Department .
:MyDepartment1 a :Department .
This constraint says that if an RDF instance i
is a Manager
, then it must be related to exactly 1 instance of Department
via the property manages
. In A, the individual Isabella
is not known to be an instance of Manager
so the constraint does not apply and A is valid. In B, Isabella
is an instance of Manager
but is not related to any instances of Department
, so B is invalid. In C, Isabella
is related to the individual MyDepartment
via the property manages
but MyDepartment
is not known to be an instance of Department
, so C is invalid. In D, Isabella
is related to exactly one instance of Department
, namely MyDepartment
, so D is valid. Finally, in E, Isabella
is related to two (assumed to be) distinct (again, because of weak UNA) instances of Department
, namely MyDepartment
and MyDepartment1
, so E is invalid.
Entities may have no more than one name.
Constraint
:name a owl:FunctionalProperty .
Database A (valid)
:MyDepartment a owl:Thing .
Database B (valid)
:MyDepartment :name "Human Resources" .
Database C (invalid)
:MyDepartment :name "Human Resources" , "Legal" .
This constraint says that no RDF instance i
can have more than one assertion via the data property name
. In A, MyDepartment
does not have any data property assertions so A is valid. In B, MyDepartment
has a single assertion via name
, so the ontology is also valid. In C, MyDepartment
is related to 2 literals, namely "Human Resources"
and "Legal"
, via name
, so C is invalid.
Property Constraints
These constraints control how instances are related to one another via properties.
The manager of a department must work in that department.
Constraint
:manages rdfs:subPropertyOf :works_in .
Database A (invalid)
:Bob :manages :MyDepartment
Database B (valid)
:Bob :works_in :MyDepartment ;
:manages :MyDepartment .
This constraint says that if an RDF instance i
is related to j
via the property manages
, then i
must also be related to j
via the property works_in
. In A, Bob
is related to MyDepartment
via manages
, but not via works_in
, so A is invalid. In B, Bob
is related to MyDepartment
via both manages
and works_in
, so B is valid.
Department managers must supervise all the department’s employees.
Constraint
:is_supervisor_of owl:propertyChainAxiom (:manages [owl:inverseOf :works_in]) .
Database A (invalid)
:Jose :manages :MyDepartment ;
:is_supervisor_of :Maria .
:Maria :works_in :MyDepartment .
:Diego :works_in :MyDepartment .
Database B (valid)
:Jose :manages :MyDepartment ;
:is_supervisor_of :Maria , :Diego .
:Maria :works_in :MyDepartment .
:Diego :works_in :MyDepartment .
This constraint says that if an RDF instance i
is related to j
via the property manages
and k
is related to j
via the property works_in
, then i
must be related to k
via the property is_supervisor_of
. In A, Jose
is related to MyDepartment
via manages
, Diego
is related to MyDepartment
via works_in
, but Jose
is not related to Diego
via any property, so A is invalid. In B, Jose
is related to Maria
and Diego
- who are both related to MyDepartment
by way of works_in
–via the property is_supervisor_of
, so B is valid.
Complex Constraints
Constrains may be arbitrarily complex and include many conditions.
Each employee works on at least one project, or supervises at least one employee that works on at least one project, or manages at least one department.
Constraint
:Employee rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :works_on ;
owl:someValuesFrom
[ owl:unionOf (:Project
[ a owl:Restriction ;
owl:onProperty :supervises ;
owl:someValuesFrom
[ owl:intersectionOf (:Employee
[ a owl:Restriction ;
owl:onProperty :works_on ;
owl:someValuesFrom :Project
])
]
]
[ a owl:Restriction ;
owl:onProperty :manages ;
owl:someValuesFrom :Department
])
]
] .
Database A (invalid)
:Esteban a :Employee .
Database B (invalid)
:Esteban a :Employee ;
:supervises :Lucinda .
:Lucinda a :Employee .
Database C (valid)
:Esteban a :Employee ;
:supervises :Lucinda .
:Lucinda a :Employee ;
:works_on :MyProject .
:MyProject a :Project .
Database D (valid)
:Esteban a :Employee ;
:manages :MyDepartment .
:MyDepartment a :Department .
Database E (valid)
:Esteban a :Employee ;
:manages :MyDepartment ;
:works_on :MyProject .
:MyDepartment a :Department .
:MyProject a :Project .
This constraint says that if an individual i
is an instance of Employee
, then at least one of three conditions must be met:
- it is related to an instance of
Project
via the propertyworks_on
- it is related to an instance
j
via the propertysupervises
andj
is an instance ofEmployee
and is also related to some instance ofProject
via the propertyworks_on
- it is related to an instance of
Department
via the propertymanages
.
A and B are invalid because none of the conditions are met. C meets the second condition: Esteban
(who is an Employee
) is related to Lucinda
via the property supervises
whereas Lucinda
is both an Employee
and related to MyProject
, which is a Project
, via the property works_on
. D meets the third condition: Esteban
is related to an instance of Department
, namely MyDepartment
, via the property manages
. Finally, E meets the first and the third conditions because in addition to managing a department Esteban
is also related an instance of Project
, namely MyProject
, via the property works_on
.
Only employees who are American citizens can work on a project that receives funds from a US government agency.
Constraint
[ owl:intersectionOf (:Project
[ a owl:Restriction ;
owl:onProperty :receives_funds_from ;
owl:someValuesFrom :US_Government_Agency
]) .
] rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty [owl:inverseOf :works_on] ;
owl:allValuesFrom [ owl:intersectionOf (:Employee
[ a owl:Restriction ;
owl:hasValue "US" ;
owl:onProperty :nationality
])
]
] .
Database A (valid)
:MyProject a :Project ;
:receives_funds_from :NASA .
:NASA a :US_Government_Agency
Database B (invalid)
:MyProject a :Project ;
:receives_funds_from :NASA .
:NASA a :US_Government_Agency .
:Andy a :Employee ;
:works_on :MyProject .
]
Database C (valid)
:MyProject a :Project ;
:receives_funds_from :NASA .
:NASA a :US_Government_Agency .
:Andy a :Employee ;
:works_on :MyProject ;
:nationality "US" .
Database D (invalid)
:MyProject a :Project ;
:receives_funds_from :NASA .
:NASA a :US_Government_Agency .
:Andy a :Employee ;
:works_on :MyProject ;
:nationality "US" .
:Heidi a :Supervisor ;
:works_on :MyProject ;
:nationality "US" .
Database E (valid)
:MyProject a :Project ;
:receives_funds_from :NASA .
:NASA a :US_Government_Agency .
:Andy a :Employee ;
:works_on :MyProject ;
:nationality "US" .
:Heidi a :Supervisor ;
:works_on :MyProject ;
:nationality "US" .
:Supervisor rdfs:subClassOf :Employee .
SubClassOf: Employee
This constraint says that if an individual i
is an instance of Project
and is related to an instance of US_Government_Agency
via the property receives_funds_from
, then any individual j
which is related to i
via the property works_on
must satisfy two conditions:
- it must be an instance of
Employee
- it must not be related to any literal other than
"US"
via the data propertynationality
.
A is valid because there is no individual related to MyProject
via works_on
, so the constraint is trivially satisfied. B is invalid since Andy
is related to MyProject
via works_on
, MyProject
is an instance of Project
and is related to an instance of US_Government_Agency
, that is, NASA
, via receives_funds_from
, but Andy
does not have any data property assertions. C is valid because both conditions are met. D is not valid because Heidi
violated the first condition: she is related to MyProject
via works_on
but is not known to be an instance of Employee
. Finally, this is fixed in E–by way of a handy OWL axiom–which states that every instance of Supervisor
is an instance of Employee
, so Heidi
is inferred to be an instance of Employee
and, consequently, E is valid. This is a good example of open world and closed world reasoning interacting for the win.
If you made it this far, you deserve a drink!