Henriette's Notes

Home » Semantic technologies » OWL » A Common Misconception regarding OWL Properties

A Common Misconception regarding OWL Properties

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

  1. I explain how this misconception fails,
  2. I explain what is the meaning of OWL properties, and
  3. 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:

  1. 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 Employer ontology with something nonsensical like
    Class: Cheese
    Class: Fridge
    
    Individual: companyFridge 
        Types: Fridge
        
    Individual: blueCheese
       Types: Cheese
       Facts: employs companyFridge
    

    the reasoner will indicate that our ontology is inconsistent because the individual blueCheese is not of type Employer and neither is the individual companyFridge an instance of Employee. However, this is not the case. This ontology is in fact consistent because domain and range axioms do not behave as constraints.

  2. 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 Employer ontology it means that instances of the Employer class must necessarily be linked via the employs property to an instance (or instances?) of Employee. Thus, the expectation is that if we have an instance Employer that is not linked to an instance of Employee via the employs property, 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:

DomainRangeAxiom whereTopis the set representing the application domain. An object property r between instances a and b is expressed as a role assertion
RoleAssertion 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.


5 Comments

  1. Sabina says:

    Excellent explanation, thank you!

  2. Mark Wallace says:

    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.

      • Mark Wallace says:

        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 .

  3. 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

Leave a Reply to Sabina Cancel reply