Link Search Menu Expand Document
Start for Free

OWL Constraint Examples

This page contains OWL constraint examples to aid you in writing your own data quality constraints.

Page Contents
  1. Subsumption Constraints
  2. Domain-Range Constraints
  3. Participation Constraints
  4. Cardinality Constraints
  5. Property Constraints
  6. Complex Constraints

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.

UML schema

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 property works_on
  • it is related to an instance j via the property supervises and j is an instance of Employee and is also related to some instance of Project via the property works_on
  • it is related to an instance of Department via the property manages.

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 property nationality.

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!