Disjointness Between Classes in an Ontology

Overview

This KBlog describes disjointness in ontologies. The KBlog says what it is; says why you want it and describes how you get it.

In brief, a disjointness axiom about two classes states that an element cannot be an instance of both classes, i.e., that the extensions of both classes are always necessarily disjoint. Stating explicitly that an individual is an instance of two disjoint classes thus makes the ontology inconsistent. Disjointness has both a role in representing the knowledge of a domain and in enabling a lot of inference on an ontology.

We describe different ways of making classes disjoint, illustrated with examples, and explain the consequences of doing so.

The Authors

Robert Stevens and Uli Sattler
BioHealth Informatics and Information Management Groups
School of Computer Science
University of Manchester
Oxford Road
Manchester
United Kingdom
M13 9PL
robert.stevens@Manchester.ac.uk and Ulrike.Sattler@Manchester.ac.uk

What is Disjointness?

Two classes in an ontology are disjoint if they cannot share an instance, regardless of how the classes are interpreted.

For example:

1. There can be no animal (or anything else) that can be both an Elephant and a Newt.
2. If we said that the individual tiny is both a type of Elephant and a type of Newt and that Elephant and Newt are disjoint, then we would have an inconsistent ontology, i.e., one that can never be realised in a model.
3. Also, if we made a class ElephantNewt to be both a subclass of Elephant and a subclass of Newt (with the parents being disjoint), then we would have an unsatisfiable class ElephantNewt, i.e., in each of the ontology’s models, there is never an instance of ElephantNewt (as it would have to be an instance of both Elephant and Newt, which isn’t possible).
4. Similarly, if we say Elephant SubClassOf: Animal and then Elephant DisjointWith: Animal, then Elephant is unsatisfiable: all elephants are animals and no elephants are animals, a straight-forward contradiction, and thus there cannot be any Elephant.

Now, in OWL, classes are not disjoint unless we somehow say that they are. That is, classes potentially overlap in their extents – unless stated otherwise, and there are many ways in which we can make a disjointness statement.

Why do we care about Disjointness?

1. Because it is “true” (or it is what we want to say about entities in our field of interest); there is a simple knowledge representation requirement to be able to say that an individual cannot be instances of two classes. One important role of an ontology is to make domain knowledge explicit and disjointness makes this explicit for humans and computers.
2. Also, disjointness has far-reaching effects on entailments. Ontologies are used as part of applications in which queries are made, or where inferred class hierarchies are considered and individuals realised into classes. Disjointness has an important role in causing entailments. In other words, not making classes disjoint that we consider as being disjoint will then lead us to find that we don’t get the entailments we were expecting.

Let’s discuss this second point with the help of some examples. Before we do so, let us point out that, in OWL, if we have an ontology where we declare two classes A and B, and say nothing more about them, then any model of our ontology can interpret these classes in any way it likes: as empty sets, one contained in the other, intersecting, or as disjoint sets. Adding axioms about A and B restricts possibilities that models of our ontology have to interpret them. In particular, a disjointness axiom between A and B restricts models to those that interpret A and B and disjoint sets.

For example, assume that all we know about Elephant and Newt is that they are subclasses of Animal, and consider the following statements:

Individual: Finknotle
        Types:
                Person,
                owns some Newt,
                owns some Elephant

If we now ask for people that own at least two animals, we won’t get Finknotle, as we don’t know that the owned instance of a newt isn’t also an elephant: as it is possible that Finknotle only owns a single animal that happens to be both a newt and an elephant, Finknotle isn’t necessarily an instance of Person and atleast 2 owns Animal. If, on the other hand, if the classes Elephant and Newt are disjoint, then it is no longer possible that Finknotle only owns a single animal that happens to be both a newt and an elephant. And thus we know that Finknotle has at least two animals and therefor would be an instance of Person and at least 2 owns Animal. As he may have even more pets, he would not be an instance of Person and exactly 2 owns Animal…but this is part of another discussion.

Similarly, but slightly more involved, assume that we say the following:

Class: PProtein

        SubClassOf:  Protein ,
                hasPart some Alpha-helix,
                hasPart only Alpha-helix

Moreover, assume that we hadn’t made Alpha-helix and Beta-sheet disjoint. Then asking for a protein without beta-sheet (i.e., instances of Protein and hasPart only not beta-sheet) would not return PProtein. Our domain knowledge tells us that nothing can be both a beta-sheet and an alpha-helix, but the automated reasoner can’t know this: we need to say explicitly that alpha-helix and beta-sheet are disjoint. If we do this, then PProtein is returned as expected.

Next, consider the following example:

Class: NewtOwner

        EquivalentTo: owns only Newt

Class: ElephantOwner

        EquivalentTo: owns only elephant

One might assume that NewtOwner and ElephantOwner are disjoint if Newt and Elephant are disjoint. This is, however, not the case since someone who owns nothing is an instance of both: if somebody is not owns-related to anything, then it is vacuously the case that all its owns-successors are instances of every class, in particular instances of Newt and of Elephant. Hence such a have-not would be both a NewtOwner and an ElephantOwner.

If we make, additionally, NewtOwner and ElephantOwner own something, then indeed NewtOwner and ElephantOwner are disjoint if Newt and Elephant are:

Owner

  EquivalentTo: Person and owns some OwlThing

NewtOwner

  EquivalentTo: Owner and owns only Newt

ElephantOwner

  EquivalentTo: Owner and owns only elephant

How to Make Classes Disjoint

The most common way of expressing disjointness is with a disjointness axiom:

Elephant

DisjointWith: Newt

This just says directly that nothing can be both a type of Elephant and a type of Newt, and it applies to both named classes and unnamed ones.

Now disjointness statements aren’t restricted to named classes: we can also state that class expressions have to be interpreted as disjoint sets, e.g., as follows:

(isPartOf some Nucleus)

DisjointWith: (isPartOf some Mitochondrion)

As a consequence of the above axiom, elements cannot be both part of the nucleus and part of the mitochondrion; a rather strong statement (though now it’s explicit, it can be examined – the KR argument given above).

Additionally, there are several other ways to explicitly state disjointness, and it is also possible to imply disjointness – or both at the same time. We will now discuss some of these.

First, as an alternative to the above disjointness axiom on elephants and newts, we can say the following:

Elephant

SubClassOf: not Newt

This has exactly the same meaning and thus the same consequences as the first disjointness statement.

Next, we observe that, if we have two subclassses of our disjoint classes, then they are also disjoint: for example, Indian Elephant and Great Crested Newt will be disjoint when added to our animal ontology.

However, when we state that African Elephant and Indian Elephant are subclasses of Elephant, then they are not automatically disjoint; this has to be asserted or implied in some way.

As mentioned above, disjointness can be stated explicitly or implicitly, and we next discuss some simple ways of implicitly making classes disjoint. Take the classes

Class: Helium

SubClassOf: hasPart exactly 2 Proton

Class: Lithium

SubClassOf: hasPart exactly 3 Proton

As each and every Helium must have exactly two protons (no more and no less) and each and every Lithium must have exactly 3 protons, an atom cannot be both helium and lithium at the same time. Hence any explicit disjointness axiom on atoms is redundant if we model them in this way – and this safes us roughly 10K disjointness axioms in the 100 or so types of atom!

Similarly, if we have classes with the axioms

Class: A

hasPart at most 3  C

Class: B

SubClassOf: hasPart at least 4 C

then A and B are disjoint as there is no way an individual can fulfill both these criteria without contradiction. The next example is a non-obvious case of this situation:

Class: G

        SubClassOf: hasPart some  C

Class: H

        SubClassOf: hasPart only not C

Observe that hasPart some C means has at least one part that is a C and hasPart only not C means has only parts that are not Cs, which in turns means has none/zero parts that are a C. Hence the above two axioms also imply disjointness between G and H.

Finally, we want to mention that OWL 2 provides us with short-cuts in the forms of the AllDisjoint axiom and the DisjointUnion axiom. The latter makes a list of classes subclasses of the class on its left-hand-side, makes all classes in the list pairwise disjoint, and adds in a covering axiom for the left-hand-side being covered by the right-hand-side. For example,

Class: AminoAcid

        DisjointUnion Alanine, Cysteine, Aspartate, Glutamate,
        Phenylalanine, Glycine, Histidine, Isoleucine, Lysine,
        Leucine, Methionine, Asparagine, Proline, Glutamine, Arginine,
        Serine, Threonine, Valine, Tryptophan, Tyrosine

means that AminoAcid has all the subclasses listed, and that those subclasses are all disjoint. Also, and importantly, the listed amino acids are covering for AminoAcid (that is, any given amino acid must be an instance of one of the classes in the list).

Making Individuals Different

We can have a similar discussion about equality of individuals. Individuals may be the same unless we say or imply that they are different. We can do this, for example, with a DifferentIndividuals axiom and, as with disjointness, this will lead to expected but also possibly unexpected answers. Take the following example:

Individual: Harry

        Facts:

    hasFather Charles,

    hasFather James

If hasFather is stated to be functional, any individual may only hold one of this property to a distinct individual. However, without a different individuals axiom on James and Charles (or something implying it), they may or may not be identical, and thus the axioms above won’t lead to an inconsistency. Adding a different individuals axiom on James and Charles (or something implying it) leads to an inconsistency.

Warm Words

So, disjointness is important both as a means to describe the world as we see it, and also to get the inferences we expect. We have just seen a number of ways to make classes disjoint, and some of the consequences of doing so. This is well exemplified in ontology design patterns like normalisation: this pattern uses a tree of asserted primitive classes with all sibling classes being pair-wise disjoint. Defined classes then use this foundation upon which to build the polyhierarchy desired for knowledge representation etc. This use touches both the KR and inference point outlined above.

So, disjointness is a basic part of ontology building and inference. We hope you enjoyed the trip and will fly with us again.