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.
Uli Sattler and Robert Stevens
Information Management and BioHealth Informatics Groups
School of Computer Science
University of Manchester
firstname.lastname@example.org and robert.stevens@Manchester.ac.uk
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.
Following a pattern we see frequently, we could use an object property
isGreen, restrict its range to
false: we introduce a Class
TruthValues and make
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
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
false different, using
We would also need to decide where these abstract objects
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.
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
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
Green disjoint. But what if
MyBall is green with red dots? If I make
MyBall an instance of both
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.
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
Green, with the latter having a subclass
LightGreen. We can again state that
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:
MyBallis now also an instance of
hasColour some Green– because
LightGreenis a subclass of
MyBallis an instance of multi-coloured things, i.e., of
(atleast 2 hasColour Colour)$– because
Greenare disjoint, and
So, is this the best we can do?
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).
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
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.
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?
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 . It should also be pointed out that modelling colour is a tricky one , 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.