The Green Green Grass of OWL

Overview

We are going to discuss various options for modelling properties or qualities of objects, using colour as an example. We try to compare the different options with respect to what they allow us to distinguish and query.

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
sattler@cs.man.ac.uk and robert.stevens@Manchester.ac.uk

Characterising classes

Assume we want to model some concepts, like toys, ideas, or plants, in an OWL ontology, e.g., Ball, Plan, or Rose. Of course we will fix, in this ontology, a vocabulary (a set of terms) for these concepts, and arrange it in a subclass hierarchy using SubClassOf axioms. But we also want to describe their relevant characteristics, i.e., the things for which we use adjectives, as in “red Ball”, “cunning Plan”, or “thorny Rose”.

OWL affords several modelling options for this very common situation. Some work better than others and the various options can be useful in describing various things about OWL. In particular, options will differ with respect to the questions we can ask in our ontology – and get answered via a reasoner. This modelling situation and what OWL can offer is also a useful place to discuss those modelling options.

isGreen as an object property

Following a pattern we see frequently, we could use an object property isGreen, restrict its range to true and false: we introduce a Class TruthValues and make true and false its only instances. Furthermore, we can restrict its domain to Physical objects, and state that isGreen is functional. Thus, a physical object can hold only one isGreen object property which is filled by either true or false and this would appear to capture all the situations we need for saying whether or not an object is green.

While we may not find this style of modelling pretty, it allows us to retrieve all green things by asking for instances of isGreen value True. Or we can introduce a class GreenObjects as equivalent to PhysicalObject and (isGreen value True).

Why would we consider this first approach to be not well modelled?

Firstly, we use abstract objects for the Boolean values true and false. As a consequence, we need to state explicitly that they are different, to ensure, for example, that (isGreen value True) and (isGreen value False), when appearing on the same object, is indeed inconsistent. We would usually do this by making the individuals true and false different, using DifferentFrom.

We would also need to decide where these abstract objects true and false “live”, i.e., do we have a suitable superclass of TruthValues? And should we introduce other ways of writing them, like “0” and “1”?

Of course not: for cases like this, OWL has data properties and XML Schema datatypes: if we really like this modelling style, at least we should use a (functional) data property isGreen whose range is Boolean.

Now is there anything else wrong with this style? Yes: assume we want to introduce another colour (i.e., data property), isLightGreen, and another class LightGreenObjects, following the same scheme. Then we would expect the reasoner to infer that LightGreenObjects is a subclass of GreenObjects, i.e., that everything that is light green is also green – but of course this is not entailed by our ontology! To fix this, we could try to make isLightGreen a sub (data)property of isGreen – but this will not have the desired effect: it will work fine in the case that, say, MyBall isLightGreen true because then our ontology entails that MyBall isGreen true. Unfortunately, an analogous yet unwanted behaviour will take place if MyBall isLightGreen false, i.e., our ontology would then entail that MyBall isGreen false which would lead to a contradiction in the case that MyBall is dark green!

So, I think we can safely consider this modelling approach to be unsuitable.

Class: Green as the class of green things

Next, let us consider another very simple approach: let’s introduce a class Green and make MyBall an instance of it, i.e., the class Green really stands for “the green things”. We can then introduce a subclass LightGreen of Green, and entailments work in the right way: light green things will be entailed to be green, whereas green things are simply green (i.e., we don’t know whether they are light green as well).

So, we can clearly say that this approach is superior – but we will soon see its limitations if we consider another colour, say Red. Of course, red isn’t green, and so we should make Red and Green disjoint. But what if MyBall is green with red dots? If I make MyBall an instance of both Red and Green, my ontology will be inconsistent! Similarly, we could not write a definition for things with more than one colour – other than by enumerating all possible colour choices, which clearly is not evolvable at all, since it requires major reworkings each time we add a new colour or change the name of a colour.

Green as a subclass of colour

What the previous approach has shown us is that we should distinguish between a colour and things that have this colour. That is, let’s introduce a class Colour with subclasses Red and Green, with the latter having a subclass LightGreen. We can again state that Red and Green are disjoint. And let’s introduce a property hasColour with domain PhysicalObject and range Colour. Of course we won’t make this property functional so that MyBall can be an instance of hasColour some Red and hasColour some LightGreen.

Things work much better in this modelling approach than they did before:

• the ontology is consistent,
• MyBall is now also an instance of hasColour some Green – because LightGreen is a subclass of Green, and
• MyBall is an instance of multi-coloured things, i.e., of (atleast 2 hasColour Colour)$ – because Red and Green are disjoint, and
• we don’t need to change the definition of multi-coloured things when we add a new colour.

So, is this the best we can do?

Green as an instance vs a class

You may wonder whether we shouldn’t make LightGreen an instance of the class Colour? After all, isn’t light green is a colour?! We may think so today – but tomorrow we may want to distinguish different kinds of light green, like lime green: if we want that limet green things are also light green things, then we should better make both classes and the latter a subclass of the former – so that we could also consider lime green as a subclass of light green (we have written a blog on the question “instances versus classes” earlier).

Defining Colour

As an alternative or extension to the above naive model of colour, we can use well-established models of colour such as RGB or CMYK or such like. Choosing RGB as an example, we can define a colour as a (visual perceptual) property that has three numerical values associated with it, adapting one of the standard coding schemes, e.g.,

Class: Colour
        EquivalentTo:
(hasRValue some nonNegativeInteger) and
(hasGValue some nonNegativeInteger) and
(hasBValue some nonNegativeInteger)

DataProperty:  hasRValue
Domain: Colour
Range: xsd:nonNegativeInteger[<= "255"^^nonNegativeInteger]

DataProperty:  hasGValue
...

In this way, we can specify specific colour instances, e.g.,

Individual: limegreen
Facts:
        hasRValue "50"^^nonNegativeInteger,
        hasGValue "205"^^nonNegativeInteger,
        hasBValue "50"^^nonNegativeInteger

and we can try to (!) define colour classes, e.g.,

Class: Green
        EquivalentTo  :
(hasRValue some nonNegativeInteger[<= "100"^^nonNegativeInteger]) and
(hasGValue some nonNegativeInteger[>= "150"^^nonNegativeInteger]) and
(hasBValue some nonNegativeInteger[<= "100"^^nonNegativeInteger])

although the above is not really a good definition of Green in this way: we would need to compare the values of hasRvalue, hasGvalue, and hasBvalue, which requires data range extensions. So, while this approach would allow us to hold, in our ontology, the exact colour(s) of things – which we could then use to, say, render their graphical representation – it has its limitations w.r.t. how we can define classes. We could consider a hybrid approach whereby we keep the RGB values of our objects, but also add suitable symbolic names for their colours; the latter could be done automatically.

Is Colour different from other characteristics

For this blog, we chose the example of colour. Of course, you may need to model, in your ontology, other characteristics such as texture, shape, taste, etc. While these characteristics differ, the general approach of modelling these, and of evaluating the fitness of a model 😉 are similar: can I refine my model easily? Do I get the expected entailments? Can I define interesting classes or query for instances that share the same property?

Summary

We hope we have (a) shown you various ways in which a property of an entity (a quality) can be modelled, and (b) the effects they have on what we can define or query in these different approaches, and how robust they are wrt future extensions. The penultimate option (having a Colour class with an object property hasColour with objects that have that colour at the left-hand-side) is the one usually followed for describing qualities in an OWL ontology; here the dependant thing (the adjective or modifier) is separated from the independant thing (the object to which the characteristic, adjective, quality, …) is applied. This is a typical separation of concerns type approach. Most top ontologies will make this separation in some form Whilst we’ve not explicitly used a top ontology in the Entity hasColour some Colour pattern above, we have implicitly done so (10.1007/978-3-540-87696-0_4). It should also be pointed out that modelling colour is a tricky one (10.1371/journal.pone.0012258), but it is a good example to bring up this common modelling situation and some options for doing so in OWL that highlights some aspects of how OWL works.

Bibliography