A misconception w.r.t. OWL properties that I come across from time-to-time is that people mistakenly think that properties express relations between classes rather than relations between individuals. In this post
- I explain how this misconception fails,
- I explain what is the meaning of OWL properties, and
- I explain how you can model relations between classes if that is really what you want to do.
Throughout this post I will refer to object properties only, even though what I say applies to data properties as well, except of course that object properties relate objects to objects whereas data properties relate objects to data type values.
As an example ontology I will use the following:
Class: Employer Class: Employee ObjectProperty: employs Domain: Employer Range: Employee
How thinking that Properties express Relations between Classes fails
Thinking that properties express relations between classes fails in two different ways:
- The first way in which the expectations of users fail under this misconception is that their assumption is that domain and range axioms behave as constraints. That is if we extend our
Employerontology with something nonsensical likeClass: Cheese Class: Fridge Individual: companyFridge Types: Fridge Individual: blueCheese Types: Cheese Facts: employs companyFridgethe reasoner will indicate that our ontology is inconsistent because the individual
blueCheeseis not of typeEmployerand neither is the individualcompanyFridgean instance ofEmployee. However, this is not the case. This ontology is in fact consistent because domain and range axioms do not behave as constraints. - The other way in which the assumption of users is shattered is that they tend to think that domain and range axioms mean that in our
Employerontology it means that instances of theEmployerclass must necessarily be linked via theemploysproperty to an instance (or instances?) ofEmployee. Thus, the expectation is that if we have an instanceEmployerthat is not linked to an instance ofEmployeevia theemploysproperty, the reasoner should give an inconsistency. Again, this is wrong. This ontology will still be consistent.
The Real Meaning of OWL Object Properties
The OWL specification is very explicit about the meaning of object properties. It states:
Object properties connect pairs of individuals.
So what is the meaning of domain and range axioms then? Domain and range axioms are not constraints to be checked, but rather they are axioms from which the reasoner can make inferences. What domain and range axioms state is that whenever two instances are linked via the employs property, for example, it means that the first instance is of type Employer and the second instance is of type Employee. Thus, in our cheese and fridge example, no matter how silly it is, the reasoner will infer that blueCheese is an instance of Employer and companyFridge is an instance of Employee.
Finally, the underlying mathematical formalization of object properties themselves does not enable linking of pairs of classes. An OWL object r is represented as a role r in description logics. Stating that the role r has the domain C and the range D, where C and D are concepts, is achieved through the following axioms:
where
is the set representing the application domain. An object property r between instances a and b is expressed as a role assertion
in description logics. Note that this assertion contains no information regarding description logic concepts (i.e. classes in OWL).
If you really, really want to have a Link between Classes
So if you really, really want to express a relation between classes, how can this be done? For our Employer ontology we can state the following:
Class: Employer SubClassOf: employs some Employee
This states that the Employer class is a subclass of the class consisting of the instances that are linked to at least 1 instance of the Employee class. If we now have an instance of Employer that is not linked via employs to an instance of Employee, the reasoner will find that our ontology is inconsistent. To state that acme is an employer without employees, we state it as follows:
Individual: acme Types: Employer Facts: employs max 0 Employee
Conclusion
In this post I explained that object properties link individuals (not classes!) and that thinking otherwise can lead to various errors when designing an ontology.
Excellent explanation, thank you!
A correction this example:
Class: Employer
SubClassOf: employs some Employee
You wrote:
“If we now have an instance of Employer that is not linked via employs to an instance of Employee, the reasoner will find that our ontology is inconsistent.”
Actually, because of the Open World Assumption, a reasoner will not find the ontology inconsistent. The reasoner would just assume the link to an instance of Employee is currently unstated/unknown, but must exist because of the class definition.
That would true if it was not that the rest of the paragraph states: To state that `acme` is an employer without employees, we state it as follows … which, then goes on to specify explicitly the fact for `acme` as follows: Facts: employs max 0 Employee.
I’m saying you don’t have to change it to use ‘min 0’. Even in the ‘some’ form, the reasoner will not find the ontology inconsistent.
You can verify with the ontology below. Load it into Protege and run the reasoner. It will not determine the ontology to be inconsistent, even though we have an instance of Employer that is not linked via employs to an instance of Employee. This is because of open world reasoning.
@prefix : .
@prefix owl: .
@prefix rdf: .
@prefix rdfs: .
# Concepts
:employs rdf:type owl:ObjectProperty .
:Employee rdf:type owl:Class .
:Employer rdf:type owl:Class ;
rdfs:subClassOf [ rdf:type owl:Restriction ;
owl:onProperty :employs ;
owl:someValuesFrom :Employee
] .
# Instances
:_MyCompany rdf:type :Employer .
Hi there Mark,
Yes, your ontology will be consistent.
However, when you define your _MyCompany individual as follows:
:_MyCompany rdf:type owl:NamedIndividual ,
:Employer ,
[ rdf:type owl:Restriction ;
owl:onProperty :employs ;
owl:maxQualifiedCardinality “0”^^xsd:nonNegativeInteger ;
owl:onClass :Employee
] .
it will give an inconsistency which gives the following explanation for the inconsistency:
_MyCompany Type Employer
Employer SubClassOf employs some Employee
_MyCompany Type employs max 0 Employee
Your ontology as you have it (and the way I have it in the post) states that employers are expected to employ 1 or more employees:
Class: Employer
SubClassOf: employs some Employee
Individual: _MyCompany
Types: Employer
states the that _MyCompany is an employer. Hence, one will expect that _MyCompany will employ at least 1 employee. As it stands, we have no explicit information as to the exact employees working at _MyCompany, because no information is provided.
If we were now to find out that this company has zero employees, we can state this information as:
Individual: _MyCompany
Types: Employer
Facts: employs max 0 Employee
Note the use of “max 0” rather than “min 0” as you stated in your comment.
Adding the fact `employs max 0 Employee` will cause the ontology to be inconsistent, with the explanation as I have given above.
The point I was trying to make in this post is that often people who will like to have a link between 2 classes (like Employer and Employee), are quite disappointed when they the define
Individual: _MyCompany
Types: Employer
without any explicit link to a named individual that their ontology is not inconsistent. This is were you are absolutely correct in that it will not cause an inconsistency exactly because of the open world assumption. The only way to model an instance of Employer that does not have any employees, is to assert the fact explicitly (by for example stating `employs max 0 Employee`).
Keep well,
Henriette