Being complex on the left-hand-side: General Concept Inclusions

Overview

The over-whelming majority of axioms in an ontology written in OWL have an atomic class on the left-hand-side. This, however, need not be the case; it is possible to have a complex class expression on the left-hand-side of an axiom. When this is the case we are in the realm of general concept inclusions (GCI). In this kblog we talk about GCI, what they are, how they can be used and what they offer to an ontology author.

The Authors

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

Introduction

When people think about OWL class-level axioms, they often do so in terms of class definitions, either exact as in

HeartDisease EquivalentTo: Disease and hasLocation some Heart

or

HeartValve SubClassOf: Bodypart and partOf some Heart.

In both axioms we have a named class (or class name) on the LHS and an anonymous class (or complex class expression) on the RHS. The expression Disease and hasLocation some Heart describes a set of instances — namely those things that are diseases located in the heart — but it has no name.

Nearly all class-level axioms we see are of this form: in particular, tools such as Protégé 4 steer ontology designers towards writing axioms with a single named class on the LHS. There are, however, other kinds of axioms, in particular disjointness axioms and GCIs. We have discussed the former at length in our KBlog on disjointness (http://ontogenesis.knowledgeblog.org/1260), and we will concentrate here on GCI.

A GCI is of the same form as our first two example axioms, but it can have a complex class expression on the RHS and/or the LHS of the axiom. In a nutshell, a GCI allows us to say things about complex descriptions of entities that we don’t necessarily want to name. In this KBog, we discuss situations where GCIs can be useful.

GCIs: what they are and when to use them

Consider the following statement:

(HeartDisease and hasLocation some HeartValve) SubClassOf: CriticalDisease

It is a GCI, and it says that, if something is a heart disease located in a valve, then it is a critical disease. That means that, if we retrieve instances of CriticalDisease from an ontology that contains assertions such as

Individual: h1
  Type: HeartDisease
  Fact: hasLocationb3

  Individual b3
  Type HeartValve

we will correctly retrieve h1 without h1 having been made explicitly an instance of CriticalDisease. This kind of modelling can be quite flexible: it allows us to add, later, other GCIs such as

(Disease and hasLocation some Brain) SubClassOf: CriticalDisease

Rather than having to think of, at the creation of CriticalDisease, a suitable definition of this term, we can add step by step GCIs to constrain its meaning. Here, we have given two sufficient conditions to be an instance of CriticalDisease, but no necessary conditions. Also, we didn’t have to think of and introduce a (class) name for the LHS (Disease and hasLocation some Brain): of course, we could have added

HeartValveDisease EquivalentTo: (HeartDisease and hasLocation some HeartValve)

and then simply written

HeartValveDisease SubClassOf: CriticalDisease

but this would lead to ever more complex class names that clutter up the class hierarchy.

This described a rather straightforward and common pattern. There are others: e.g.,

Disease and (causedBy some X) SubClassOf: (hasLocation some Y)

states that diseases caused by X can only be located in Y. This is another typical kind of background knowledge one might want to formulate (again, without having to introduce names). Finally, let us point out that the above axiom is logically equivalent to the following one

owl:Thing SubClassOf: not(Disease and (causedBy some X)) or (hasLocation some Y)

which says that everything – i.e., all instances of owl:Thing, which is all elements in any model – is either not a disease in X or located in Y, i.e., the same as the original axiom, but in a more convoluted way.

A word of warning: GCIs with owl:Thing on its LHS such as the above one are highly questionable. For example, consider the following example:

owl:Thing SubClassOf: (hasId some string)

This says that everything has a string-valued Id, which may be a reasonable statement to make locally, but not globally, in particular if your ontology may be imported by others: your constraint that everything has a string-valued Id may easily clash with other constraints in importing ontologies, e.g.,

InAnimae SubClassOf: (hasId only owl:Nothing)

So, if everything described in your ontology has a string-valued Id and you want to express this, we suggest you give a name to the things described in your ontology, e.g., DomainConcept, and then state the following:

DomainConcept SubClassOf: (hasId some string)

Then your ontology won’t clash with one where InAnimae doesn’t have any hasId axioms.

Doing it in Protégé 4

Protégé 4 steers the ontology author towards using simple LHSs, but coding GCIs is possible in Protégé 4. Under “Active Ontology”, you will find a tab “General Axioms”, where you can add, delete, and edit general class axioms, with the usual auto-completion and syntax highlighting. Below is a screenshot of one of our running example GCIs in Protégé 4. It is treated, internally, as any other axiom, and taken into account when classifying the ontology.

Note that the Manchester Syntax used in Protégé for GCI is not “proper” Manchester Syntax. The OWL API allows this local variant or extension so that GCI can be formed and used with a Manchester style of syntax.

Summary

We have seen that GCIs are (sub-class or equivalent-class) axioms with a complex class expression on their LHS. We have discussed how this can help us add background knowledge to our ontology which allows us to get inferences w.r.t. that background knowledge without having to invent new class names that would only end up cluttering up the class hierarchy.

This possibility in OWL is closely related to post-coordination, another juicy bit of OWL we will write about in another KBlog.

Bibliography