Ontology Representation
Design Patterns and Ontologies that Make Sense
Rinke Hoekstra

SIKS Dissertation Series No. 2009-15
The research reported in this thesis has been carried out under the auspices of SIKS, the Dutch Research School
for Information and Knowledge Systems.

ONTOLOGY REPRESENTATION
Design Patterns and Ontologies that Make Sense
ACADEMISCH PROEFSCHRIFT
ter verkrijging van de graad van doctor
aan de Universiteit van Amsterdam
op gezag van de Rector Magnificus
prof. dr. D.C. van den Boom
ten overstaan van een door het college voor promoties
ingestelde commissie,
in het openbaar te verdedigen in de Agnietenkapel
op vrijdag 18 september 2009, te 12:00 uur
door
Rinke Jan Hoekstra
geboren te Zaanstad

Promotiecommissie
Promotor: prof. dr. J.A.P.J. Breuker
Copromotores: prof. dr. T.M. van Engers
dr. R.G.F. Winkels
Overige leden: prof. dr. F. van Harmelen
prof. dr. E. Motta
prof. dr. F.J.M.M. Veltman
prof. dr. B.J. Wielinga
dr. B. Bredeweg
Faculteit der Rechtsgeleerdheid

To Eefje and Lieve

Contents
1 Introduction 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Contribution and Overview . . . . . . . . . . . . . . . . . . . . . 6
2 Knowledge Representation 8
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Two Schools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Intelligence by First Principles . . . . . . . . . . . . . . . 10
2.2.2 Production Systems . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Semantic Networks . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.5 Frame Languages . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Epistemology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Knowledge and Representation . . . . . . . . . . . . . . . 20
2.3.2 Representation and Language . . . . . . . . . . . . . . . . 22
2.3.3 Adequacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Components of a Knowledge Based System . . . . . . . . . . . . 28
2.4.1 Modelling Principles . . . . . . . . . . . . . . . . . . . . . 28
2.5 Knowledge Representation . . . . . . . . . . . . . . . . . . . . . 32
2.5.1 Description Logics . . . . . . . . . . . . . . . . . . . . . . 33
2.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3 Semantic Web 39
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.1 The Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Groundwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Lightweight Semantics . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.1 RDF: The Resource Description Framework . . . . . . . . 44
3.3.2 The RDF Schema Vocabulary Description Language . . . 47
3.4 Requirements for Web-Based Knowledge Representation . . . . 50
3.5 The Web Ontology Language . . . . . . . . . . . . . . . . . . . . 52
3.5.1 OWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5.2 OWL 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Contents v
4 Ontologies 66
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2 Ontologies as Artefacts . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3 Ontology in Philosophy . . . . . . . . . . . . . . . . . . . . . . . 73
4.3.1 Problems in Formal Ontology: Semantics and Syntax . . 74
4.4 Two Kinds of Ontologies . . . . . . . . . . . . . . . . . . . . . . . 76
4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5 Ontology Engineering 82
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2 Criteria and Methodology . . . . . . . . . . . . . . . . . . . . . . 83
5.2.1 A Social Activity? . . . . . . . . . . . . . . . . . . . . . . . 86
5.3 Categories and Structure . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.1 A Basic Level? . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.2 Beyond Categories . . . . . . . . . . . . . . . . . . . . . . 91
5.4 Ontology Integration . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.4.1 Types of Ontologies: Limits to Reuse . . . . . . . . . . . . 94
5.4.2 Safe Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4.3 Possibilities for Reuse . . . . . . . . . . . . . . . . . . . . 101
5.5 Ontological Principles . . . . . . . . . . . . . . . . . . . . . . . . 102
5.5.1 OntoClean . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.5.2 Frameworks and Ontologies . . . . . . . . . . . . . . . . 106
5.6 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.6.1 Patterns and Metaphors . . . . . . . . . . . . . . . . . . . 112
5.6.2 Patterns in Ontology Engineering . . . . . . . . . . . . . 113
5.6.3 Knowledge Patterns . . . . . . . . . . . . . . . . . . . . . 114
5.6.4 Ontology Design Patterns . . . . . . . . . . . . . . . . . . 115
5.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6 Commonsense Ontology 120
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.1.1 A Functional View . . . . . . . . . . . . . . . . . . . . . . 122
6.1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.2 Developing a Core Ontology . . . . . . . . . . . . . . . . . . . . 127
6.2.1 Ontology Integration . . . . . . . . . . . . . . . . . . . . . 127
6.2.2 Ontology Reuse . . . . . . . . . . . . . . . . . . . . . . . . 130
6.2.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.3 Ontology Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.3.1 First Things First: The top-level . . . . . . . . . . . . . . . 137
6.3.2 The Intentional Level . . . . . . . . . . . . . . . . . . . . . 139
6.3.3 The Legal Level . . . . . . . . . . . . . . . . . . . . . . . . 142
6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7 Design Patterns 146
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
7.1.1 Dealing with Models . . . . . . . . . . . . . . . . . . . . . 147
7.1.2 Structured Concepts . . . . . . . . . . . . . . . . . . . . . 150
7.1.3 Three Patterns . . . . . . . . . . . . . . . . . . . . . . . . . 151
7.2 Grasping the Diamond: The Reciprocity of Exchange . . . . . . . . 152
7.2.1 Representing Transaction . . . . . . . . . . . . . . . . . . 154

7.2.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.3 Reification and Summarisation: Relations and Social Reality . . . 159
7.3.1 N-Ary Relations . . . . . . . . . . . . . . . . . . . . . . . 159
7.3.2 Social Reality . . . . . . . . . . . . . . . . . . . . . . . . . 162
7.3.3 Representing Summarisation . . . . . . . . . . . . . . . . 164
7.3.4 Discussion and Examples . . . . . . . . . . . . . . . . . . 169
7.4 Sequences: Change and Causation . . . . . . . . . . . . . . . . . . 175
7.4.1 Causation . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
7.4.2 Representing Causal Change . . . . . . . . . . . . . . . . 180
7.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
7.5 Patterns in Practice: Action! . . . . . . . . . . . . . . . . . . . . . 189
7.5.1 Representing Action . . . . . . . . . . . . . . . . . . . . . 190
7.5.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
7.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
8 Conclusion 198
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
8.2 Compatibility of Ontologies . . . . . . . . . . . . . . . . . . . . . 199
8.3 Quality and Design . . . . . . . . . . . . . . . . . . . . . . . . . . 202
8.4 Rationale and Expressiveness of OWL 2 . . . . . . . . . . . . . . 204
8.5 Closing Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Bibliography 208

1.1. Introduction 2
tiny required from the people that actually build the models.2 Furthermore,
both the E-POWER and KDE projects (Jansweijer et al., 2001) made it acutely
clear how important the language is in which the model is expressed.3 Coming
from academia, it was puzzling to see how easily one defaults to inexpressive
but intuitive languages (or even just database tables), rather than well-wrought
languages that support reasoning. What is more, it was very difficult to defend
a more principled approach as available languages did not have widespread
tool support (yet), nor did they offer even the trivial reasoning capabilities our
users were interested in: then what makes them ‘better’ languages? Was I a
puritan?
When I first set out to work on this book the objective was to investigate a
formal representation of physical causation for the purposes of automatic at-
tribution of liability in legal cases. It was the natural follow-up on the work
of Lehmann (2003), who gave an overview of the different forms of causation
involved in liability and responsibility attribution. Our approach, described in
Breuker and Hoekstra (2004b); Hoekstra and Breuker (2007), was based on the
hypothesis that legal causation (which is a form of liability) can only be estab-
lished given full knowledge of the chain of events leading from some initial
event (an action) to an undesirable state (some damage).
This approach turned out to be problematic for two reasons. First of all, the
subject of causation – and legal causation and liability in particular – plays a
prominent role in philosophy and legal theory. One cannot present a formal,
computational representation of causation without taking a stance in this dis-
cussion. Perhaps this is because a necessary step for automated reasoning,
namely the construction of a computational model of a theory, may be confused
with the presentation of a formal theory. As no established theory on causation
directly fit our needs, there was no escaping: even though we did not purport
to present a new theory on causation, our model was considered as such.
The second problem was more practical: the representation of even a very
simplistic model of physical causation turned out to be quite difficult (though
not entirely impossible, see Section 7.4). The heart of the problem was our re-
quirement that the existence of a causal relation was to be inferred on the basis
of a description of multiple successive situations and the changes between
them, rather than only from other causal relations. An event (and consequently
causes) is then classified by recognising the two situations between which it oc-
curs. First we used the Web Ontology Language (OWL, Bechhofer et al. (2004)),
a language optimised for classification, but its expressiveness was too limited
to enforce relations between the two situations. For instance, it is impossible
to express that a change occurs to two states of a single object instead of to two
different ones (Hoekstra et al., 2006). We were able to express these restrictions
using the Prolog language; but it required the implementation of a custom clas-
sifier. Clearly, that was not the solution either.
The ESTRELLA project brought the development of a legal knowledge in-
terchange language (LKIF, Boer et al. (2007a)) and a core ontology for the legal
domain (LKIF Core, see Hoekstra et al. (2008) and Chapter 6).4 An important
2E-POWER, European Program for an Ontology based Working Environment for Regulations
and Legislation, IST-2000-28125.
3KDE, Knowledge Desktop Environment, Esprit Project 28678.
4ESTRELLA, European project for Standardized Transparent Representations in order to Extend
Legal Accessibility, IST-2004-027655.

1.2. Questions 3
role of this ontology is to provide the conceptual basis for more expressive and
elaborate models that can be used to provide complex reasoning services. In
practice, this meant a revisiting of the problems I faced in my work on caus-
ation. For, how to combine representations in OWL with highly expressive
languages that have a direct correspondence with legal theory? Secondly, to
allow for intelligent reasoning, the OWL definitions in the ontology had to be
extended to more intricate descriptions: the language was pushed to its limits.5
1.2 Questions
These experiences expose several interesting questions pertaining to the rep-
resentation of human knowledge in a computer model. I briefly discuss the
five most prominent ones here:
How can the quality of models be ensured? Evaluating the quality of a
model depends on the criteria used in its evaluation. What quality criteria and
requirements apply to representations of knowledge, and how do they inter-
act? To what extent do design principles, methods, and the choice of language
contribute to the quality of our models?
Can the design of models be facilitated, or made easier? Building a formal
computational model is both difficult and a lot of work, while the possible
pay-off is not always immediately clear. What solutions have been proposed
to lower this threshold, and how do they perform in practice?
To what extent do theory and practice go hand in hand? Formal theories can
be said to reflect a profound understanding of a domain; but are they adequate
computer models? To what extent can and should criteria that hold for formal
theories be applied to models designed to be used in an intelligent system?
What is the rationale behind representation languages? The field of artificial
intelligence boasts a large number of languages that can be used to construct
models. Although these languages can be very different, each has been de-
signed with a specific purpose in mind. The question is, how does one know
which language is appropriate for the purpose at hand?
How do limitations in expressiveness affect models of a concrete domain?
Every formal language distinguishes itself by offering a different set of primit-
ives that can be used to construct models. The choice for a language is therefore
a commitment to the limitations of that set of primitives. What does this com-
mitment mean in practice, for a concrete domain?
In this book I report on my quest to find answers to each of these questions.
Instead of treating each question in turn, they are rather used as background
against which the following chapters unfold. Chapter 2 presents the base line
5For examples of some of the problems we faced, see Breuker et al. (2007); Hoekstra (2008);
Klarman et al. (2008); van de Ven et al. (2008b); Hoekstra and Breuker (2008); Hoekstra et al. (2008),
and Chapter 7.

1.3. Ontologies 4
for answering all five questions. Chapter 5 has a strong focus on the first two
questions, while Chapter 4 is primarily concerned with the issue raised in the
third question. Chapter 3 elaborates on the second chapter to improve a better
understanding of the fourth and fifth question. Chapters 6 and 7 present the
consequences of the discussion in the preceding chapters for the case of a con-
crete domain. Chapter 6 emphasises the first and third question, and Chapter 7
focuses on the second, fourth and last question.
1.3 Ontologies
The following chapters discuss the questions introduced in the previous sec-
tion in the context of a particular type of computer model: ontologies. This
section explains what makes the design of ontologies such a suitable domain
for this investigation.
‘Ontology’ is a term that people who have come across the subject of the
Semantic Web will be familiar with: the two go hand in hand. The use of on-
tologies is widespread; their utility is universally acknowledged and they are
the talk of the town at many conferences. However, it is quite hard to find out
what exactly ontologies are, and why they play such a prominent role. The
term ‘ontology’ is clearly overloaded, bringing together insights from philo-
sophy, artificial intelligence, systems engineering, information management,
computational linguistics, and cognitive psychology. The cacophony of voices
resulting from this interdisciplinary interest leads to heated and interesting de-
bates but can be quite bewildering to the ingenuous newcomer who simply
wants to use the technology.
In answering their principal question – what is an ontology – experts are
implicitly biased with respect to their own perspective. As I will discuss, the in-
terplay between abstract, theoretical considerations and practical requirements
render it impossible provide a single correct answer. This book attempts to
elucidate the different perspectives, and emphasises one interpretation, that of
knowledge representation. Knowledge representation is a field of artificial intel-
ligence that tries to deal with the problems surrounding the design and use of
formal languages suitable for capturing human knowledge. The ultimate goal
of this formal representation is to enable intelligent automated reasoning on
the basis of that knowledge. This knowledge-based reasoning takes place within
systems that are designed, as a whole, to perform tasks which are normally
carried out by human experts. These tasks typically require the consideration
of large amounts of data, e.g. where human reasoning is error prone, or just
tedious. Analogous to software engineering, knowledge engineering is the field
that concerns itself with the specification and design of such systems. It is
an important aspect of knowledge acquisition, the general problem of how to
extract and organise knowledge from human experts in such a way that it is
implementable in a reusable manner.
The design of ontologies plays a prominent role in both knowledge repres-
entation and engineering. The field of ontology engineering has brought forth
numerous methodologies and design principles on the subject of ontology con-
struction. The Web Ontology Language (OWL) is a prominent member of the
knowledge representation languages family, designed specifically for the rep-
resentation of ontologies. Its expressiveness is restricted to guarantee favour-

1.4. Contribution and Overview 6
domain (question five) may provide better understanding of the issues
involved than a separate consideration would.
1.4 Contribution and Overview
The following chapters explore the topics introduced in this chapter as follows:
Chapter 2 – Knowledge Representation gives a historical overview of the
field of knowledge representation and acquisition. It discusses the quest for a
knowledge representation language that has a clearly understood status with
respect to the knowledge that it can represent. Important in this light are issues
of maintenance and reusability of knowledge based systems. These require-
ments show that a knowledge representation language is not ‘just’ a generic
formal language. This chapter presents arguments for a language that has well-
defined computational properties and can be used to build task independent
knowledge system components.
Chapter 3 – Semantic Web introduces the ideas underlying the Semantic
Web, the Web Ontology Language, and in particular its successor OWL 2.
Both highly expressive web-based knowledge representation languages. The
chapter shows how the requirements formulated in Chapter 2 interact with
the open nature of the web, and explains the rationale and limitations of the
primitives available in OWL 2. This language is selected as base line for the
discussion of ontologies, methodologies and design patterns in the subsequent
chapters.
Chapter 4 – Ontologies discusses the widely varying conceptions of what
(an) ontology is, paying attention mainly to its use in philosophy and in know-
ledge representation. This discussion makes clear that a lot of the confusion
surrounding ontologies stems from an obfuscation of the two perspectives,
and proposes a more crisp distinction between different types of ontologies.
The role of ontologies that are expressed using knowledge representation lan-
guages is explained and adopted as central to the task of ontology engineering
discussed in the subsequent chapters.
Chapter 5 – Ontology Engineering presents an overview of methodological
approaches to building ontologies. It highlights several design principles for
ontology construction. In particular, the role of ontologies as reusable know-
ledge components leads to a number of restrictions both with respect to what
an ontology contains, and as to how it may be reused. For each of these topics,
this chapter discusses whether and how these can be reconciled with the know-
ledge representation perspective on ontologies described in Chapter 4. Fur-
thermore, the chapter proposes a refinement of current views on reuse, design
patterns, and of the kind of knowledge expressed in ontologies.
Chapter 6 – Commonsense Ontology applies the insights of the preceding
chapters to the construction of a core ontology for the legal domain: LKIF Core.
This ontology is designed to support the reasoning task of a knowledge based

2.2. Two Schools 10
First Order Logic
Theorem Provers
(exhaustive, combinatorial)
Semantic Nets,
Frames, (Rules)
Problem Solvers
(goal directed, rational)
Rules Expert Systems
Semantics
(Epistemological Adequacy)
Reasoning
(Heuristic Adequacy)
Philosophy
Psychology
Practice
Table 2.1: Schools and systems in Knowledge Representation
intelligence systems should attain a balance between both epistemological ad-
equacy and heuristic adequacy.
The distinction between these approaches was very much evident in AI
research in the seventies. Mylopoulos (1981) organised the schools in a tax-
onomy; KR languages can first of all be divided into procedural and declar-
ative ones. The first is aimed at attaining heuristic adequacy, the second has
an epistemological perspective. The declarative languages can be further sub-
divided into logic-based and semantic network ones, see Table 2.1. It wasn’t
until the end of the seventies that so-called hybrid systems attempted to com-
bine declarative and procedural views (see Figure 2.1).
2.2.1 Intelligence by First Principles
The idea of automated intelligent reasoning has been around for a long time,
and can be traced back to ancient Greece. Aristotle’s syllogisms are often seen
as the first example of a formalisation of valid reasoning. With the separation
of mind and body in the 17th century by Descartes, and in common sense, the
road was opened up to apply newly found mathematical insights to model and
imitate parts of human thought as mechanistic processes. Perhaps the most ap-
pealing examples are Pascal’s arithmetic machine for addition and subtraction,
and Leibniz’ improvements to it to support multiplication, division and com-
puting the square root.
In the mean time other great minds, such as John Wilkins (the first secretary
of the Royal Society) were busy working on a systematic account of all of hu-
man knowledge using his Real Character. The real character encoded words in
such a way that each had a unique non-arbitrary name. For this, Wilkins used
a three-layered tree structure. All concepts are distributed over forty Genuses;
these in turn are divided into Differences which are separated as Species. Each
of these layers adds one or more letters, such that any path through the tree
can be represented as a unique four-letter word.
More influential, however was Leibniz’ invention of the binary system of
numbers that lies at the heart of his calculator. He entertained the thought of
encoding ‘notions’ as unique binary encoded numbers. Using a simple method

2.2. Two Schools 13
Systems that follow the IPS architecture of Newell and Simon are gener-
ally a type of production system (Buchanan and Shortliffe, 1984). These systems
were first conceived of as a general computational mechanism by Post (1943),
used to describe the manipulation of logical symbols. In its simplest form, a
production rule consists of a left hand side (condition) and a right hand side
(action), usually in the form of an if ...then ... statement. A production
rule is essentially the operationalisation of a reasoning step (i.e. an eip) in an
IPS: given some input structure of symbols, the rule produces a new (modi-
fied) structure of symbols. An interpreter iteratively evaluates all productions
in the system until it finds one that matches one or more symbols stored in
memory. This evaluation of the condition of rules is a passive operation that
has no impact on those symbols. When the interpreter evaluates some input to
the conditions of a rule, it is said to ‘fire’, and performs the operations specified
on the right hand side on relevant symbols in memory. Because of its depend-
ency on the order in which the interpreter carries out evaluation, a production
is not applied in the same way as the full combinatorics of logical implication.
Where the consequent of an implication necessarily holds at all times – all in-
formation implicit in the knowledge base holds at all times – the consequent of
a production rule only comes into effect after the rule has fired.
Production rules were (and still are) used for a wide variety of applications.
They can be categorised according to two views: as a means for psychological
modelling on the one hand (as in IPS), and for expert systems on the other. In
cognitive psychology, production rule systems were part of an effort to create
programs that capture human performance of simple tasks. This performance
includes typical human treats such as forgetting, mistakes etc. and rules were
a promising paradigm for capturing heuristics in human problem solving. For
these scruffies, human intelligence was rather a “particular variety of human
behaviour” (Davis et al., 1993, p.10); the ‘intelligence’ of reasoning can only be
assessed by virtue of its correspondence to human intelligence, and not neces-
sarily by whether it is clean and logical. To them, production systems provided
a clear formal way to represent the basic symbol processing acts of information
processing psychology (Davis and King, 1984). The production rule semantics
allowed an escape from the nothing-or-all inferences of theorem proving, and
could be used to capture the local, rational control of problem solving.
During the eighties, rule-based knowledge representation was applied in a
number of large scale projects, and found its way into many enterprise indus-
trial and government applications. Because of their rather practical, applica-
tion oriented perspective, focus shifted from a cognitive perspective to build-
ing large knowledge-based systems, and creating and maintaining elaborate
models that capture expert knowledge. Knowledge-based expert systems, em-
phasise problem-solving performance at the cost of psychological plausibility.
Production rules are used to capture expert knowledge about a particular task
or domain, and enable the system to support, augment or even surpass human
problem solving. Production rules can be modified and extended relatively
easily, which makes them a convenient paradigm for incremental system de-
velopment. A well known example of such a system is is the MYCIN expert
system for medical diagnosis (Buchanan and Shortliffe, 1984). Rather than at-
tempting to simulate diagnosis by human experts, it captures and formalises
the (often implicit) knowledge, i.e. the ‘rules of thumb’ used by those experts,
into the form of production rules. Because of the emphasis on performance,

2.2. Two Schools 15
“His intent was to capture in a formal representation the ‘objective’ part of the
meanings of words so that ‘humanlike use of those meanings’ would become
possible”
(Brachman, 1979, p. 5)
Underpinning the cognitive perspective of this approach, was his later re-
search using reaction time in assessing the factual truth of statements (Collins
and Quillian, 1969, semantic verification) to test the psychological plausibil-
ity of semantic network models. Of particular interest was the question as
to whether the retrieval of inferred property values (over the subclass rela-
tion) would take more time than directly represented property values. The fact
that indeed this was the case provided backing for property inheritance over a
superclass-subclass taxonomic hierarchy in semantic network representations
of human semantic memory. Furthermore, he intended his model to be suit-
able for automatic inference, allowing for querying information implicit in the
model. Effectively turning the semantic network paradigm into not only a rep-
resentation but a simulation of human memory.
The expressive power of the original semantic networks soon became too
restricted, and a number of innovations and extensions followed. Quillian’s
original set of five link types turned out to be insufficient, and was superseded
by the ability to type pointers using named attributes, i.e. a means to use a token
to point to a type. Furthermore, a distinction was introduced between concepts
and examples (later instances), in Carbonell (1970). These innovations led to a
plethora of widely variant, rather unprincipled, semantic network ‘languages’.
Many of which applied the technique to domains other than psychology.
A true show-stopper, however, was that new link types, and even concept
types, were not explained and the interpretation of semantic networks was left
to the ‘intuition’ of the reader (Brachman, 1979): semantic networks did not
really have semantics. For instance, both the concept–instance distinction and
the type–token distinction were obfuscated by the use of the infamous ‘IS-A’
link (Woods, 1975; Brachman, 1983).
Perhaps most manifest to current readers was the critique that the networks
made no distinction between domain level constructs – conceptual relations in
the domain – and knowledge structuring principles such as the subclass rela-
tion. As semantic networks relied heavily on graphical notation, this is most
apparent in the uniformity of presentations. Woods stressed the importance of
considering the semantics of the representation itself.
To summarise, semantic networks were developed as part of an effort in
psychology to represent human semantic memory. Although they have been
successful in many ways, they suffered from lack of proper semantics: “The
‘semanticness’ of semantic nets lies in their being used in attempts to represent
the semantics of English words.” (Brachman, 1979, p. 26).
2.2.4 Frames
The semantic network model received criticism from cognitive science itself
as well. Most notable in this respect is Minsky (1975),1 who argued against
1Though, as is common his ideas had been brooding in the community, cf. Schank and Abelson
(1975); Woods (1975)

2.2. Two Schools 17
2.2.5 Frame Languages
Research in the late seventies produced a number of – what in retrospect could
be called – frame based KR languages. Not because they were explicitly de-
veloped to define Minsky’s original frames (they were not), but because they
share its emphasis on interrelated, internally structured concepts as primary
language primitive.
Knowledge Representation Language (KRL) The Knowledge Representa-
tion Language (KRL), developed by Bobrow and Winograd (1976), was built
on the idea that knowledge is organised around conceptual entities with as-
sociated descriptions and procedures. In their view, a KR language should be
independent from the processing strategies or representations of a particular
domain. It must provide a flexible set of underlying tools.
KRL descriptions represent partial knowledge about an entity, and can con-
sist of multiple descriptors that can be grouped to capture differing viewpoints
on the entity. KRL’s descriptions are by comparison to a known entity (the pro-
totype), extended with a further specification of the described entity. The pro-
totype provides a perspective from which to view the object being described.
The description of a concept entity can combine different modes of description
(Bobrow and Winograd, 1976, p. 6), such as category membership, stating a
relationship, or role in a complex object or event etc.
Reasoning in KRL is done by way of a process of recognition where newly
introduced objects are compared to stored sets of prototypes. Specialised reas-
oning strategies can be attached to these prototypes in the form of procedural
attachments. These procedures could be called depending various triggers (on
classes) or traps (on objects) such as goal directed procedure calls (servant pro-
cedures) and side-effects of system actions (demon procedures). Such proced-
ural attachments are coined procedural properties, as opposed to declarative
properties.
Bobrow and Winograd make a strong claim that “it is quite possible . . .
for an object to be represented in a knowledge system only through a set of
such comparisons” between prototypes (Bobrow and Winograd, 1976, p.7).
The definition of an object is wholly contained within the system, but also
functionally complete with respect to that definition as the system can an-
swer any relevant query about it. This represents a fundamental difference
in spirit between the KRL notion of representation and standard logical repres-
entations. Because the definition of an object is in terms of other objects, and
vice versa, and its position within that network of comparisons is determined
by a standard inference mechanism, it is the inference mechanism that determ-
ines the meaning of an object.
Structured Inheritance Networks (SI-Nets) Another frame-like language,
the Structured Inheritance Networks (SI-Nets) of Brachman (1979) were an at-
tempt to define an epistemologically well-founded class of KR languages (see
Section 2.3.2): granted that we distinguish concepts and relations, how can we
account for the apparent meaning of concepts that determines their position
within a network? The most prominent of these languages, KL-ONE (Brach-
man, 1979; Brachman and Schmolze, 1985), is organised around concepts. Con-
cepts are intensional, and can represent objects, attributes and relations in a

2.3. Epistemology 19
focus on structured concepts, which are defined by simple or very elaborate
structural or procedural descriptions in terms of other concepts. Concepts are
either generic or individual, and are clearly distinguished from their real world
counterparts. The meaning of a concept is determined by its position within
the network of other concepts, which is enforced by a standard inference mech-
anism based on the descriptions of the concept. Because of the combination of
conceptual and procedural (production rule-like) primitives, languages such
as KL-ONE and KRL are sometimes called hybrid systems.
2.3 Epistemology
“One man’s ceiling is another man’s floor”
Paul Simon, 1973
Frame based languages proved to be a significant improvement over other se-
mantic networks.3 They fixed a paradigm which was more rigourous and bet-
ter suited for representing knowledge. The development of these languages
was not only given in by the cognitive psychology argument of Minsky (1975),
but also (and perhaps more importantly) by the growing awareness of the need
to have a clear definition of what a knowledge representation is.
The interaction between psychological insights and knowledge representa-
tion practice led to two fundamental questions:
1. What is the relation between a machine representation and the thing (do-
main, body of knowledge) it denotes? and,
2. How does the representation language relate to the representation itself?
So, while at first developers of both semantic and procedural knowledge rep-
resentations were primarily concerned with the psychological plausibility of their
models, the proliferation of semantic nets and frame based languages sparkled
growing concern about the epistemological status of knowledge, representation,
and the KR languages themselves.
In his 1980 inaugural presidential address to the AAAI4 Newell (1982) dis-
cussed exactly this topic: the nature of knowledge, and in particular the re-
lation between knowledge and representation. In his view, the latter is used
precisely and clearly in computer science while the former is often used in-
formally. He identifies a problem with representation, in that it is attributed a
‘somewhat magical’ role.
“What is indicative of underlying difficulties is our inclination to treat repres-
entation like a homunculus as the locus of real intelligence.”
(Newell, 1982, p.90)
3The above quote was taken from Brachman (1979).
4American Association of Artificial Intelligence

2.3. Epistemology 20
Table 2.2: Computer System Levels (Newell, 1982)
Level Description
Knowledge Level Knowledge and rationality
Symbol Level Symbols and operations (also program
level)
Logic Level Boolean logic switches (e.g.
AND/OR/XOR gates, consists of the
register-transfer sublevel and logic circuit
sublevel)
Circuit Level Circuits, connections, currents
Device Level Physical description
The most salient task in AI is identifying the proper representation of a
problem. It can make the difference between combinatorial and directed prob-
lem solving: “... the crux for AI is that no one has been able to formulate in a
reasonable way the problem of finding the good representation, so that it can
be tackled by an AI system.” (Newell, 1982, p.3). The capability to find the
proper representation apparently requires some special kind of intelligence.
What epistemological adequacy is, turned out to differ widely, as we have
seen in the previous section. McCarthy and Hayes propose to construct a prac-
tical philosophical system, based on our common sense understanding of the
world. For semantic network-adepts, epistemological adequacy equates to
psychological plausibility. But even the criterion of psychological plausibil-
ity is not suitably specific to distinguish between production systems and net-
work representations. All three proposals, the logic-based, production-based
and network approach, aim to answer the two fundamental questions raised
at the start of this section. Although they formulate some description on what
a knowledge representation should contain and how it relates to the world
it represents, this description remains vague: none of them clearly defines a
framework for this relation. And secondly, they do not give an answer to how
knowledge relates to the language it is represented in: what are the primitives
of knowledge representation?
2.3.1 Knowledge and Representation
In his discussion on the nature of knowledge, Newell (1982) presented the
knowledge level as a computer system level. The execution of computer pro-
gram code is made possible by its translation to physical operations on a circuit
board. This translation passes through a number of steps, or ‘levels’ at which
the program can be expressed (e.g. from java code at the symbol level, to java
byte code to processor instructions etc.), see Table 2.2. Levels have a medium,
the system it is used to express, primitive processing components and guidelines
for their composition, and a definition of how system behaviour depends on the
behaviour and structure of components.
Every computer system level can be defined autonomously – without refer-
ence to another level – and is reducible to a lower level. Because a description
of a system at some level does not imply a description at a higher level, these

2.3. Epistemology 22
GC
k
IC
k
IO
instantiation
individuation
denotation
MC
r
GC
r
inst
ind
den
IC
r
inst
ind
den
GC
l
IC
l
inst
ind
den
inst
den
Knowledge
Representation
Language
Knowledge
Representation
Knowledge Reality
Figure 2.5: Relation between a representation and the world.
as we understand it, there is no more useful and well-tuned proxy than the
mental models of reality we use and live by every day.
2.3.2 Representation and Language
The introduction of the knowledge level helps us to put the representation of
knowledge into perspective, but does not address the suitability issue of the
knowledge representation languages of Section 2.2.
Levels In his review of lessons learned in semantic nets, Brachman (1979)
identified five distinct groups of primitive types used in these languages. He
considered each of these groups to stand for a particular viewpoint, or concep-
tual ‘level’. Any network, he argued, can be “analysed in terms of any of the
levels” (p.27). In other words, a concept expressed in a language at one level,
can be understood and expressed at all other levels as well. On the other hand,
an interpreter usually commits to support only one of these sets.
At the implementational level, semantic nets are mere graphs, data struc-
tures where links are pointers and nodes are destinations for links. The logical
level emerged in reaction to criticism that semantic nets did not have formal
semantics. It perceives semantic nets as a convenient depiction of predicates or
propositions (the nodes) and the logical relationships between them (the links).
Originally, however, semantic nets were meant to capture the meaning of word
concepts. At this conceptual level, links are case relations between nodes rep-

2.3. Epistemology 23
Table 2.3: Levels of Semantic Networks (Brachman, 1979)
Level Primitives
Implementational Atoms, pointers
Logical? Propositions, predicates, logical
operators
Epistemological Concept types, conceptual sub
pieces, inheritance and structur-
ing relations
Conceptual Semantic or conceptual relations
(cases), primitive objects and ac-
tions
Linguistic Arbitrary concepts, words, ex-
pressions
? Note that the logical Level of Brachman is not the same as Newell’s Logic Level
resenting word senses. Here, the primitives are less neutral, and encompass
conceptual elements and relations, such as action types and cases (thematic
roles) respectively. Not always are these primitives explicitly defined as part of
the semantic net language, but on the whole the relations do have this flavour.
One level higher, nodes and links are language dependent. Linguistic level net-
works are composed of arbitrary relations and nodes that exist in a domain.
Each consecutive level adds a commitment to a particular interpretation of the
structure of the world.
In line with the criticism of Woods (1975), who urged the consideration of
the semantics of KR languages, and Minsky (1975), who argued for structured
concepts, Brachman postulates that part of the promiscuity of semantic net-
work languages lies in the absence of an intermediate level between the logical
and conceptual levels. He proposed the introduction of an epistemological level
which allows the definition of knowledge-structuring primitives as opposed to
knowledge primitives:
“The formal structure of conceptual units and their interrelationships as concep-
tual units (independent of any knowledge expressed therein) forms what could
be called an epistemology.”
(Brachman, 1979, p.30)
To illustrate, even while we can argue about which properties exist, we can
still agree that properties exist. See table 2.3 for an overview of Brachman’s
levels. Perhaps his levels are best understood as levels of detail or abstraction.
When regarding a linguistic level representation, using plain English words
etc., we can zoom in to see the case structure and concepts that underlie the
language. If we then zoom in again, we can view the internal structure of
these concepts and what makes that they can be related in certain ways. Not
very surprisingly, his KL-ONE is designed for representing knowledge at the
epistemological level.
We must be careful, however, not to misinterpret the analysis Brachman
made as a deconstruction of layers in semantic-network based knowledge rep-

2.3. Epistemology 24
resentation only. In fact, it remains rather unclear what Brachman believes to
be at a level. His description leaves room for the following alternative inter-
pretations:
Language
A KR language can be designed to be adequate for the representation of
knowledge using primitives at a particular level.
Knowledge
The knowledge represented using a KR language can be of a type corres-
ponding to one of the levels. For instance, it is quite common to describe
concepts using some form of logic, but we can just as readily represent
logical primitives as concepts.
In the first sense, the knowledge primitives determine the level of a lan-
guage; where in the second sense the level describes the kind of knowledge
expressed in a model. The two interpretations of the levels are not wholly un-
related, and Brachman formulates a number of requirements for KR languages
to adequately support the representation of knowledge at a particular level.
Firstly, a language should be neutral with respect to knowledge at the level
above it. Secondly, it should be adequate for supporting the level above it, i.e.
it should be expressive enough to account for knowledge at that higher level.
And thirdly, it should have well defined semantics: it should prescribe legal
operations, and provide a formal definition of its primitives.
Types For a long time, the expert systems field seemed to steer clear of the
epistemological crisis of declarative knowledge representation. And indeed,
the levels presented in the previous section do not particularly fit the heuristic
perspective of production systems. Although the PSI architecture includes a
‘memory’ in which knowledge of the world is stored declaratively, these sym-
bol structures are usually very simple hierarchies with limited semantics, and
were used chiefly as database-like place holders for instance data.
All of this changed when it became clear that production rule systems were
not particularly usable in settings other than which they were designed for.
This realisation emerged when Clancey (1983) attempted to use MYCIN rules
in the GUIDON tutoring program, i.e. to “transfer back” expert knowledge
from a rule base. The idea was to use the rules to explain each step in the
diagnostic reasoning process. As the original design goal of MYCIN was for
it to be built using a simple mechanism for representing heuristics that would
support explanations and advice, it seemed at first that this educational use
would be relatively straightforward. It turned out not to be. Merely using
MYCIN’s built in explanation facility did not work as expected. GUIDON was
incapable of explaining many rules because of insufficient information about
the way the rule base was structured. In order to support a tutoring setting, it
is necessary to extract this “compiled knowledge”(Clancey, 1983).
Rules in MYCIN, but in other systems as well, implicitly encode the design
rationale behind the way rules are fitted together. Clancey clarifies the different
ways in which design knowledge is lost when building rules by distinguishing
between goals, hypotheses and rules. These three categories are organised in a
network of dependencies (see Figure 2.6). Goals are formulated as questions

2.3. Epistemology 25
Goal
Hypothesis
Rule
Hypothesis
Goal
What cause of infection? What therapy?
e.coli cryptococcus ... ...
rule 643 rule 636
meningitis bacterial steroids alcoholic
What infection?What kind of meningitis? Steroids? Alcoholic?
...
Figure 2.6: Network of goals, hypotheses and rules, adapted from Clancey
(1983)
that need to be answered for the system to solve a problem (e.g. making a
diagnostic decision). Hypotheses are potential answers to the questions, and
are ascertained by rules that have the hypothesis as their consequent. Rules
fire, i.e. make their consequent hold, when their antecedent is satisfied. This
antecedent is composed of other hypotheses that answer some goal.
The decomposition gives insight in the way the different categories interact
when MYCIN traverses the search space. For instance, when it tries to satisfy
e.g. the “meningitis” hypothesis, MYCIN will in fact consider all related hypo-
theses that answer the more general goal “what infection?”. The links between
these categories are the ‘points of flexibility’ in a rule representation.
A problem solving strategy can be conveyed by making explicit the rationale
behind the order of premises in a rule as this affects the order in which goals
and hypotheses are pursued. A decision to determine the ordering of hypo-
theses in a particular way is a strategic decision, which can be stated in relatively
domain-independent terms. The example given by Clancey is “consider differ-
ential broadening factors”. Also some level of structural knowledge is neces-
sary to “make contact with knowledge of the domain”, it provides a “handle”
by which a strategy can be applied. For instance, it seems reasonable to invest-
igate common causes of a disease before considering unusual ones.
The justification for a rule is captured by the rationale for the connection
between the conclusion in the consequent and hypotheses in the antecedent.
Justification depends on knowledge of the domain. Clancey (1983) identifies
four different types of justification, and consequently four different types of
rules (the domain theory):
 Identification rules use properties of an object to identify it, e.g. “if it walks
like a duck and talks like a duck, it is a duck”.

2.4. Components of a Knowledge Based System 30
complaint
cover hypothesis
select
verify
specify
finding
result
hypothesis observable
obtain
Figure 2.9: The standard diagnosis PSM, from Schreiber et al. (2000).
also because expertise domains in general are very large and complex. Skeletal
models do not only help to reduce the amount of specification needed, but
provide guidance with respect to the knowledge needed to build a KBS as well:
they ensure coverage.
To enable knowledge level reuse, the roles played by elements in a model
should be identified (Clancey, 1983; Bylander and Chandrasekaran, 1987). Ap-
proaches based on role limiting facilitate reuse by indexing symbol level repres-
entations – executable models – to types of knowledge at the knowledge level
(Valente et al., 1998). These models are detailed blueprints for implementation
in a system. Other approaches, such as KADS, rather took skeletal models to
be sketches of models and provided no direct connection to implementation.
The models in KADS supported reuse of ‘understanding’.
Role limiting and knowledge typing are accomplished firstly by the separ-
ation between heuristics and epistemology.7 For instance, KADS categorises
elements as a type of control knowledge or as part of a domain theory (See also
Figure 2.7). Control knowledge is the knowledge regarding how a system ob-
tains it goals and solves problems. The CommonKADS approach distinguished
two types of control knowledge in expertise models (van Heijst et al., 1997;
Valente et al., 1998; Schreiber et al., 2000):
Task Knowledge
is a abstract high level description of the decomposition of the goals
within a KBS that must be achieved by problem solving.
Inference Knowledge
An inference is an primitive problem solving step which is solely defined
in terms of its input/output signature. Its internal workings cannot be
meaningfully expressed at the knowledge level even though they can
perform very complex operations. Inferences can be combined in infer-
ence structures.
Tasks and inferences are combined in problem solving methods (PSM); these
are descriptions of a particular way to perform some task: a PSM expresses a
strategy, and reflects the “competence to decompose a task” (Valente et al.,
7Note that at the knowledge level, this does not correspond to a distinction between procedural
vs. declarative: everything specified at the knowledge level is declarative.

2.5. Knowledge Representation 35
C
I
C
Individuation
rdf:type
Denotation
.
I
Instantiation
owl:Class
owl:Individual
o
o
I
Denotation
.
I
K
∆
I
Figure 2.11: Instantiation, individuation and denotation in DL
or by 2) explicit assertions about individuals that relate directly to individual
objects in the domain. Whether the latter relation holds or not is up to an
observer external to the knowledge base. Related to this, is the fact that DLs
do not necessarily adopt the unique name assumption, the assumption that an
individual object is denoted by exactly one individual in the knowledge base:
any number of individuals may share the same model.
As discussed earlier, the balance between computational complexity and
decidability on the one hand, and expressiveness on the other plays a promin-
ent role in description logics research (Baader et al., 2003). As a result, various
description logics can be constructed out of several basic building blocks, for
which the effect on combinations is well known.11 These building blocks each
have an associated letter, the combination of which gives the name of a par-
ticular description logic (see Table 2.4). For example, the DL SHIQ(d) is the
attributive language with complex concept negation, transitive properties, in-
verse properties, qualified cardinality restrictions and datatype properties.
The emphasis on computational efficiency has furthermore lead to a dis-
tinction between axioms in the terminological, role and assertional boxes:
Terminological Box (TBox)
Contains class axioms, the generic concepts of Brachman (1979).
Role Box (RBox)
Contains descriptions of the characteristics of properties and the relations
between them.
11See e.g. the Description Logics Complexity Navigator at http://www.cs.man.ac.uk/
~ezolin/dl/.

2.6. Discussion 38
Table 2.4: DL abbreviations
Abbreviation Description
AL Attributive Language:
 Atomic negation (negation of concepts that do
not appear on the left hand side of axioms)
 Concept intersection
 Universal restrictions
 Limited existential quantification (restrictions
that only have fillers of owl:Thing)
FL_ A sub-language of AL, without atomic negation
FLo A sub-language of FL
_, without limited existential
quantification
C Complex concept negation
S AL and C with transitive properties. In SROIQ:
some additional features related to the RBox
H Role hierarchy (subproperties)
R Limited complex role inclusion axioms; reflexivity
and irreflexivity; role disjointness.
O Nominals, i.e. enumerated classes and object value
restrictions
I Inverse properties
N Cardinality restrictions
Q Qualified cardinality restrctions
F Functional properties
E Full existential quantification
U Concept union
(D) Datatype properties, data values and datatypes
Source: http://en.wikipedia.org/wiki/Description_logic

Chapter 3
Semantic Web
“He could spell his own name WOL, and he could spell Tuesday
so that you knew it wasn’t Wednesday but his spelling goes all
to pieces over delicate words like measles and buttered toast.”
About Owl, in ‘Winnie the Pooh’ by A.A.Milne
3.1 Introduction
In November 2001, the WebOnt working group set out to develop a new Web
Ontology Language (OWL, Bechhofer et al. (2004)) to be used for knowledge
representation in a form that it could be shared across the web.1 The working
group was tasked with the development of:2
“A Web ontology language, that builds on current Web languages that allow
the specification of classes and subclasses, properties and subproperties (such
as RDFS), but which extends these constructs to allow more complex relation-
ships between entities including: means to limit the properties of classes with
respect to number and type, means to infer that items with various properties
are members of a particular class, a well-defined model of property inheritance,
and similar semantic extensions to the base languages.”
WebOnt WG Charter
The Web Ontology Language is tightly interwoven with the development of
the semantic web, first described in Berners-Lee (1999); Berners-Lee et al. (2001).
The purpose of the Semantic Web is to advance the machine interpretability
1The working group disliked the proper acronym “WOL” and decided to call the language
“OWL”. This decision was backed by the extraordinary abilities of the wise friend of Winnie the
Pooh: Owl.
2http://www.w3.org/2002/11/swv2/charters/WebOntologyCharter
39

3.1. Introduction 40
of information stored on the web. Not just for improving the accessibility and
communication of this information to humans, but primarily for knowledge ex-
change between automated web services. More importantly, semantic web tech-
nology should enable open and unattended sharing of this knowledge. A web-
based knowledge representation language should take into account the distrib-
uted nature of the web, and is necessarily subject to other constraints than a
language that is not exposed in that way: how does this trade off work out in
practice?
In this chapter I give an overview of the technical characteristics of semantic
web languages, and the trade-offs they imply for web-based knowledge rep-
resentation. Central to this discussion is the Web Ontology Language, which
is in many ways a natural step up the evolutionary ladder for the termino-
logical knowledge representation languages of the 80’s and 90’s. Although
it can be said that a significant body of documentation on OWL already ex-
ists, this has either the nature of reference guide or overview (Bechhofer et al.,
2004; McGuinness and van Harmelen, 2004), a technical specification (Patel-
Schneider et al., 2004) or rather entry-level guides and walkthroughs (Anto-
niou and van Harmelen, 2004; Smith et al., 2004; Horridge et al., 2007). This
chapter aims to lay bare the rationale and limitations of the language features
of OWL, both practical (Antoniou and van Harmelen, 2003) and theoretical
(Horrocks and Patel-Schneider, 2003). This view plays a central role in the de-
scription of design patterns in Chapter 7.
The fact that OWL is called a web ontology language, obfuscates rather than
emphasises its main character as a highly expressive description logic. For all
practical purposes, this chapter will simply use the term ‘ontology’ to denote a
terminological knowledge representation (or domain theory) expressed using
the web ontology language. Chapter 4 discusses the ambiguity of the term
‘ontology’, and sheds light on the historical reasons for giving this language
the name “OWL”.
3.1.1 The Web
The web as it exists from roughly 1993 on is not much more than a network of
inter linked pages. For sure, its success is very much based on this lightweight
approach: it uses a simple, networked architecture which is easily extensible
and immune to incorrect or incomplete data, links and mark-up. Information is
presented in a human understandable way: by means of texts, pictures, layout
etc. Legacy web languages such as HTML3 and CSS4 are specifically targeted to
facilitate the disclosure of information in a way suitable for human consump-
tion. In a way, more recent developments such as Ajax5 take this approach
even further by making web pages more responsive to human interaction.
The primary means of navigating the web is by following hyperlinks be-
tween pages, form filling and the use of search engines such as Google and
Yahoo Search. These search engines use a combination of natural language
processing (NLP), network analysis and hit-counts to determine the rank of
a page in search results. Nonetheless, still even the best engines suffer from
3Hypertext Markup Language, http://www.w3.org/html/
4Cascading Style Sheets, http://www.w3.org/Style/CSS/
5Asynchronous Javascript and XML

3.2. Groundwork 42
Character Encoding
Characters should be encoded in a uniform way in order for strings to be in-
terpreted the same way across the globe. This holds for presentation-oriented
mechanisms – e.g. browsers should be able to display both chinese and west-
ern characters – and extensive data manipulation mechanisms alike. Unicode7
is a standard adopted by industry that enables computers to consistently rep-
resent and manipulate text expressed using a wide range of writing systems.
Amongst others, it defines several mappings from (subsets of) some 100k char-
acters onto various encodings using the Unicode Transformation Format (UTF).
The most well-known of these is UTF-8, an 8 bit encoding with variable-width
that is backwards compatible with the older ASCII format.8
Identification
By adopting Universal Resource Identifiers (URIs)9 as means for unique identific-
ation of resources on the web, anyone can make statements about other state-
ments similar to the way in which one can now hyperlink from one HTML
page to another using a Universal Resource Location (URL). In fact, every URL
is also a URI (but not vice versa):10 a URL is a URI used as a location. Al-
ternatively a URI can be used as a Universal Resource Name (URN).11 Note that
URI’s, including URN’s, attach a meaningful machine interpretable identifier to
resources on the web. They are explicitly not intended to be used as human
readable names. URI’s are structured as follows:
URI = scheme ":" hier-part [ "?" query ] [ "#" profile ]
Namespaces
A resource on the web is often specified ‘within’ a namespace. A namespace is
essentially a collection of URI’s in which every resource name is locally unique.
The URI of a namespaced resource is composed of a namespace name, and a
local name. Usually, the profile part of a URI is used to contain the local name
and the composition of scheme and hier-part is used to denote the namespace
name. This mechanism can be used to provide authority to a namespace, as
namespace names can correspond to domain names on the internet. This is
a loosely coupled form of ‘trust’, as the only way to enforce this authority is
by dereference-ability of URI’s to a location. Namespaces can be abbreviated
using so-called namespace prefixes, which typically abbreviate the scheme and
hier-part to an intelligible shorthand.
7See http://www.unicode.org/
8ASCII: American Standard Code for Information Interchange
9The URI specification is defined in RFC 3986, see http://gbiv.com/protocols/uri/
rfc/rfc3986.html
10This simple relation has been the source of much confusion, as many treat URI’s as URL’s, i.e.
by dereferencing from a URI to a URL.
11It is often thought that URN’s should always use the ‘urn’ scheme, where syntactic parts of the
name are delimited by colons. In fact, any URI can be interpreted as either a name or a location, it
is the interpretation that turns a URI into a URN or a URL respectively. However, URN’s specified
using a ‘urn’ scheme cannot be dereferenced to a URL without a defined mapping.

3.3. Lightweight Semantics 43
Structured Data
The Extensible Markup Language (XML)12 is a flexible way to explicitly encode
data in a nested datastructure. It is a subset of SGML,13 an industry stand-
ard meta language for defining exchangeable machine processable document
formats. XML diverges from SGML in general by its orientation towards the
exchange of data on the web, and was designed to be compatible with HTML,
e.g. XHTML 1.0 Strict is an XML version of HTML and supersedes older ver-
sions. Extensibility of XML is provided by the XML Schema14 language that
can be used to describe restrictions on the structure of XML encoded data
within a particular namespace; XML Schema is itself an XML dialect. It provides
a fixed set of datatypes, such as integers, strings, date, that can be used by XML
parsers when interpreting a document.
Important to note, however, is the fact that although the structure of some
data can be expressed in XML according to some schema, the way in which
this data should be interpreted, i.e. its semantics, is externally defined (if at
all). Even when we do commit to a particular interpretation of the nested struc-
ture of XML, the least we can say is that it does not convey very expressive
semantics.
3.3 Lightweight Semantics
“A little semantics goes a long way”
James Hendler
The first step towards the Semantic Web is the specification of a way to add
simple, relatively lightweight metadata to documents on the web. Currently,
the de facto metadata representation languages on the semantic web are the
Resource Description Framework (RDF) and the RDF Schema vocabulary de-
scription language extension to RDF. Contrary to other knowledge structuring
languages, such as Topic Maps (Biezunski et al., 1999)15 or even UML, which
have XML syntaxes and can thus be used to publish metadata on the web, RDF
and RDF Schema are web languages. That is, the structure of the RDF language
is designed to mimic the way in which information is stored on the web. This
way, metadata can be distributed across multiple documents or locations; and
is extensible as any RDF resource can point directly to other RDF resources in
the same way that HTML documents can.
RDF is often criticised as being too technical, having unwieldy semantics
and verbose syntax, and at the same time providing only a limited vocabu-
lary of primitives for (lexical) knowledge organisation. These attributes would
12See http://www.w3.org/TR/xml/
13SGML: Standard Generalized Markup Language
14See http://www.w3.org/TR/xmlschema-1/ (structure) and http://www.w3.org/TR/
xmlschema-2/ (datatypes)
15See http://www.topicmaps.org/, the XML syntax for Topic Maps is XTM, http://www.
topicmaps.org/xtm/index.html

3.3. Lightweight Semantics 45
http://www.uva.nl/people#breuker http://www.uva.nl/people#hoekstra
http://www.uva.nl/people#supervises
http://www.uva.nl/people#breuker-hoekstra-supervision
rdf:subject
rdf:predicate
rdf:object
rdf:Statement
rdf:type
rdf:Property
rdf:type
"Joost Breuker" "Rinke Hoekstra"
http://www.uva.nl/people#name
http://www.uva.nl/people#name
Figure 3.2: An RDF graph representation of the phrase “Joost Breuker super-
vises Rinke Hoekstra”
“Rinke Hoekstra” are literal values, connected to resources that are the respect-
ive persons. These resources are identified by URI’s in the http://www.uva.
nl/people namespace: the URI http://www.uva.nl/people#breuker
denotes Joost Breuker, the actual person. In the following I will abbreviate
URIs in the http://www.uva.nl/people namespace using the prefix ‘uva’.
The supervision relation is denoted by the predicate uva:supervises that holds
between the two persons. Not only can this predicate itself be addressed as
a resource, as in uva:supervises rdf:type rdf:Property, but any triple as a whole
can be reified, and explicitly named. In RDF, reification is expressed using the
rdf:Statement construct. A resource of type rdf:Statement can explicitly refer to
the subject, predicate and object of some property relation using the rdf:subject,
rdf:predicate and rdf:object properties, respectively. For instance, the resource
uva:breuker-hoekstra-supervision in Figure 3.2 reifies the uva:supervises relation
by explicitly pointing to its relata. Note, however, that although the exist-
ence of a relation indicates the existence of its reification, an rdf:Statement by
itself does not mean that the corresponding relation holds as well (see also
Section 7.3.3). In the current example, the assertion of the uva:breuker-hoekstra-
supervision statement and its relata does allow us to infer the triple uva:breuker
uva:supervises uva:hoekstra.
RDF graphs can be stored in different formats. Most commonly this will
be some plain text file, which means that the graph needs to be serialised, i.e.
‘flattened’ or deflated to fit the a sequential order of characters in a file. RDF
serialisations are order independent because the order in which triples are ad-
ded to a file depends on an arbitrary choice for which node is serialised first.
There exist three official serialisation syntaxes for RDF: RDF/XML, N-Triple
and more recently the Terse RDF Triple Language (Turtle).18
18See http://www.w3.org/TR/rdf-syntax-grammar/, http://www.w3.org/

3.3. Lightweight Semantics 46
The RDF/XML syntax has the advantage of being a native XML format,
though parsing it can be hard as the native order-dependent tree model of XML
documents gets in the way of the RDF graph model. Secondly, this makes
the syntax notoriously verbose. For instance, the RDF graph of Figure 3.2 is
serialised in RDF/XML as follows:19
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:uva="http://www.uva.nl/people#"
xml:base="http://www.uva.nl/people">
<rdf:Property rdf:ID="supervises"/>
<rdf:Property rdf:ID="name"/>
<rdf:Description rdf:about="#breuker" >
<uva:supervises rdf:resource="#hoekstra"/>
<uva:name>"Joost Breuker"</uva:name>
</rdf:Description>
<rdf:Description rdf:about="#hoekstra" >
<uva:name>"Rinke Hoekstra"</uva:name>
</rdf:Description>
<rdf:Statement rdf:ID="breuker-hoekstra-supervision">
<rdf:subject rdf:resource="#breuker"/>
<rdf:predicate rdf:resource="#supervises"/>
<rdf:object rdf:resource="#hoekstra"/>
</rdf:Statement>
</rdf:RDF>
RDF/XML uses the rdf:about property to state that some rdf:Description con-
cerns the resource indicated by the URI reference. The rdf:resource property
connects the predicate of a relation to its object, e.g. the object of the rdf:subject
relation in the statement uva:breuker- hoekstra- supervision is the resource uva:
breuker.20 Provided that the type of some resource is known, as is the case
with the uva:supervises and uva:name properties, we can directly state the prop-
erties of that resource under an element of its type and a rdf:ID attribute that
gives the resource’s URI. For instance, the serialisation above states that the
uva:supervises resource is of type rdf:Property. An equivalent serialisation that
does not explicitly introduce the resource, but rather adds information about it,
is:
TR/2004/REC-rdf-testcases-20040210/#ntriples and http://www.w3.org/
TeamSubmission/turtle/, respectively.
19Note that the xml:base attribute is used to abbreviate some of the URIs.
20Namespace abbreviation can be a bit confusing because of the intermixed use of RDF URI
references and xml:ID datatypes for the identifiers. The rdf:ID attribute is an xml:ID and its value is
automatically interpreted by an XML parser as an identifier within the base (or default) namespace.
This means that an RDF parser does not have to deal with whether an rdf:ID is a full URI or just
the fragment, as it will be presented as a full URI of the form <namespace>+#+<local name>. The
rdf:about and rdf:resource properties, on the other hand, do not specify the identity of the XML
element they are located at, but rather point towards some other resource. If the URI reference is not
fully specified, an RDF parser will have to resolve the URI, and it does this by simply concatenating
the value of the xml:base attribute and the URI fragment identifier: xml:base+<fragment identifier>.
Hence the necessity to prefix the name with a pound character (#).

3.3. Lightweight Semantics 47
<rdf:Description rdf:about="#supervises">
<rdf:type
rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
</rdf:Description>
Turtle was developed as a subset of the N3 language,21 and has a much
more readable syntax than RDF/XML. It is similar to N-Triple, in which all
triples in the graph are spelled-out, but it allows several shorthand notations.
For instance, the omission of the object of a triple in several consecutive state-
ments that are separated by semicolons, and the reserved word a that replaces
rdf:type. The Turtle serialisation of the RDF graph in Figure 3.2 is as follows:
@prefix uva: <http://www.uva.nl/people#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
uva:breuker
uva:name "\"Joost Breuker\"" ;
uva:supervises uva:hoekstra .
uva:breuker-hoekstra-supervision
a rdf:Statement ;
rdf:object uva:hoekstra ;
rdf:predicate uva:supervises ;
rdf:subject uva:breuker .
uva:hoekstra
uva:name "\"Rinke Hoekstra\"" .
uva:name
a rdf:Property .
uva:supervises
a rdf:Property .
3.3.2 The RDF Schema Vocabulary Description Language
Although RDF can already be used to describe quite complex graph structures,
it provides little in the way of semantics and automatic inferencing. For in-
stance, there is no standard way to say that both uva:breuker and uva:hoekstra
are persons, or that the uva:supervises relation is a relation only between per-
sons. RDF Schema (RDFS) extends RDF with basic primitives that do allow us
to express such more generic knowledge.
In fact, most of these primitives are already commonplace in the semantic
networks of the 1970s. RDFS introduces the notion of classes (rdfs:Class) and
transitive subclass relations (rdfs:subClassOf) which allow to describe taxonom-
ies. Individual resources can be said to belong to a class using the rdf:type
property. Under RDFS semantics, the type of a resource is inherited over the
rdfs:subClassOf relation: resources belonging to a class belong to all its super
21See http://www.w3.org/DesignIssues/Notation3.html. N3 allows for several non-
RDF constructs such as a forAll loop, rules and paths.

3.5. The Web Ontology Language 53
OWL Full ontology is valid RDFS and vice versa. This means, amongst others,
that in OWL Full the primitives of the language (i.e. the meta logical sym-
bols) are part of the domain. However, as proved by Motik (2007), this mixing
of logical and metalogical symbols in OWL Full leads to undecidability (see
Section 3.3.2).
The second species, OWL DL, is a syntactic subset of OWL Full, but lim-
its the semantics to the SHOIN (D) description logic (see Table 2.4). At the
time this language was the maximally expressive, decidable description logic
for which efficient algorithms were known and use cases existed. To retain de-
cidability, the compatibility with RDFS is restricted to a specific subset of that
language. This means that although every OWL DL ontology is valid OWL
Full and thus RDFS, this does not hold the other way around. However, be-
cause any conclusion given the OWL DL semantics is a valid conclusion in
OWL Full, the RDFS interpretation of an OWL DL ontology is consistent with
its DL entailments.
Because SHOIN (D) is very expressive, it allows the construction of ex-
ceedingly complex expressions which can be quite hard to grasp for an on-
tology engineer. Furthermore, reasoning with this logic is computationally ex-
pensive and intractable. The third species, OWL Lite, is meant to alleviate some
of the problems of its bigger brother. It is a syntactic subset of OWL DL, where
the semantics is designed to be limited to the SHIF(D) description logic. Sim-
ilar to OWL DL, any OWL Lite conclusion is a valid OWL DL conclusion, and
the RDFS interpretation of an OWL Lite ontology is therefore consistent with
its DL entailments. Unfortunately it soon turned out that the syntactic limit-
ations imposed on OWL Lite did not, in fact, limit it to SHIF(D), and most
of the semantics of OWL DL can be expressed using elaborate combinations of
OWL Lite constructs.
OWL follows the distinctions of DL between class axioms, property axioms
and individual assertions. Figure 2.11 shows how the OWL DL constructs owl:
Class and owl:Individual map onto their corresponding DL constructs.
Class Axioms Since not all RDFS classes are valid OWL DL and OWL Lite
classes, OWL introduces the owl:Class which is the rdfs:subClassOf rdfs:Class
consisting of all valid OWL classes. Because in OWL Full all RDFS classes
are valid, owl:Class is equivalent to rdfs:Class under OWL Full semantics.
Just as in RDFS, owl:Classes can be related using rdfs:subClassOf properties.
All OWL classes are a subclass of the class owl:Thing – which in OWL DL is
equivalent to >. The class owl:Nothing represents the empty class – in OWL DL
equivalent to⊥ – and is defined as the complement of :owl:Thing. In OWL Full
owl:Thing is equivalent to rdfs:Resource.
Two classes that are the rdfs:subClassOf each other, are equivalent, which can
be directly expressed using the owl:equivalentClass property. An owl:Class is
either named or anonymous. A named class is defined using class axioms that
restrict it to be disjoint with, equivalent to or the subclass of one or more other
classes. Disjointness of two classes means that the intersection of both is the
empty set. There are three types of anonymous classes:
 Nominals are defined by exhaustively enumerating all individual class
members, for instance:28
28The _:x in the example is a blank node, an RDF resource without a URI. This blank node can

3.5. The Web Ontology Language 60
Annotation properties cannot be used in class restrictions, e.g. to define the set
of all persons with more than one rdfs:label name. And they cannot be used on
class restrictions either. Especially this last restriction was considered an unne-
cessary shortcoming, and OWL 2 DL extends OWL with axiom annotations, that
is any axiom (such as a class restriction) can be annotated.
Furthermore, OWL 2 extends the annotation system with rdfs:subPropertyOf
relations, and the specification of domain and range for annotation properties.
Under DL semantics these do not carry semantics, but the extension allows a
larger portion of OWL Full ontologies to be valid in OWL 2 DL as well. Ways
are currently being investigated to allow rich annotations which can be used to
attach information to axioms that is interpretable by extensions of OWL reason-
ers.36 For instance, PRONTO37 extends the Pellet reasoner with a probabilistic
reasoning engine that uses annotations on rdfs:subClassOf to assert the probab-
ility of that relation to hold between two classes.
Another area where OWL 1 was significantly underdeveloped is its means
to resolve owl:import relations between ontologies. In OWL 1, the owl:import
property is simply defined as a transitive property that holds between two
ontologies, i.e. the domain and range of owl:import is owl:Ontology. How-
ever, because the specification is silent on how ontologies are to be identified
on the web, there is no standard means by which the import mechanism can
be used. This weak definition was a relatively late addition to the language,
resulting from a compromise between the ontology-as-theory and ontology-
as-document perspectives. Regardless of its ambiguous definition, it turned
out that this owl:import property was widely used. The OWL 2 specification
(Motik et al., 2009) is therefore much more explicit in this respect, and recom-
mends a method that combines the imports mechanism with simple version-
ing. OWL 1 defines several ontology properties for versioning (owl:priorVersion,
owl:backwardCompatibleWith and owl:incompatibleWith) but again, these do not
have a prescribed normative, nor recommended, effect on the semantics of im-
ports. Because there was no recipe for importing a particular version of an
ontology, each OWL tool used its own particular way to deal with versions
and perform resolution of ontology URI’s to ontology documents.
In a nutshell, the mechanism in OWL 2 works as follows. If an OWL 2
ontology imports another ontology, this is done from the URL dereferenced
(in the standard way) by the URI value of the owl:imports property. The im-
ported ontology should have either that URI as the value of its ontology URI
(i.e. the URI of the owl:Ontology element), or as the value of its owl:versionInfo
property. Because user agents, such as ontology editing tools may specify their
own method for resolving URI’s to locations, the ontologies need not necessar-
ily be published on the web, but may be accessed from ontology repositories
or a local file system. If an ontology is imported by another ontology, then
its import closure becomes part of the import closure of the importing onto-
logy. The axiom closure of an ontology is the smallest set that contains all
axioms from all ontologies in its import closure.38 The versioning properties
from OWL 1 may be used by user agents to raise a flag when e.g. the value
of an owl:incompatibleWith property corresponds with a owl:versionInfo or onto-
36See http://www.w3.org/2007/OWL/wiki/Annotation_System
37See http://clarkparsia.com/weblog/2007/09/27/introducing-pronto/
38See also definitions 5.4.2 and 5.4.3 in Section 5.4 for a more formal discussion.

3.5. The Web Ontology Language 62
the ability to reason in polytime on ontologies with large TBoxes, and was de-
signed to cover the expressive power of several existing large-scale ontologies,
such as
SNOMED-CTr
is a large-scale commercial ontology that defines the international stand-
ardised terminology of the IHTSDO,40 which is used in the health care
systems of both the US and the UK. It consists of about 500k named class
definitions.41
Gene Ontology
is an ontology of 25 thousand terms related to genes and gene proper-
ties.42
GALEN
About 95% of this closely interlinked multi-lingual ontology of medical
terms is covered by EL++. The GALEN ontology contains about a thou-
sand class definitions.43
Where EL supports conjunction and existential restrictions, EL + + extends
this with nominals and role inclusions. It is lightweight and supports sound
and complete reasoning in polynomial time. The most significant difference
with OWL 2 DL (SROIQ) is that it drops the owl:allValuesFrom restriction,
though it does support rdfs:range restrictions on properties, which can have
a similar effect. EL+ + is not a profile of OWL 1 DL as it supports the complex
role inclusion axioms of OWL 2, and it is more expressive than OWL 1 Lite in
that it allows for existential owl:someValuesFrom where OWL 1 Lite doesn’t.
OWL 2 QL Reasoners developed for OWL DL 1.0 and 1.1 are optimised for
reasoning on TBox axioms, and are relatively inefficient when dealing with
ontologies that have relatively uncomplicated class definitions, but contain a
large number of ABox assertions. The QL profile of OWL 2 was developed to
efficiently handle query answering on such ontologies, and adopts technolo-
gies form relational database management. It is based on the DL-Lite descrip-
tion logic of Calvanese et al. (2005). By itself DL-Lite is a very restricted a pro-
file of both OWL 2 DL and OWL 1 DL but the QL fragment of OWL 2 extends
DL-Lite with more expressive features such as the property inclusion axioms,
i.e. owl:subPropertyOf, and functional and inverse-functional object properties
of OWL 1. However, it also includes the top and bottom roles of OWL 2, which
adds expressiveness beyond that of OWL 1 DL.
OWL 2 RL The OWL 2 RL profile is based on so-called Description Logic
Programs (Grosof et al., 2003), which is a subset of OWL DL 1.0 and the Horn
profile of First Order Logic (FOL) (see Figure 3.5). DLP enables the interaction
40International Health Terminology Standards Development Organisation, see http://www.
ihtsdo.org
41Systematized Nomenclature of Medicine, Clinical Terms, see http://www.snomed.org
42See http://www.geneontology.org/
43Generalised Architecture for Languages, Encyclopaedias and Nomenclatures in medicine, see
http://www.openclinical.org/prj_galen.html

3.6. Discussion 64
i
2
i
3
i
1
i
4
i
2
i
3
i
1
i
4
i
5
Figure 3.6: Diamond vs. tree model
tion for the now standard representation language OWL. The representation of
knowledge on the web posed several requirements for this language in addi-
tion to those outlined in Chapter 2, with respect to both semantics and syntax.
On the one hand, compatibility of its syntax and semantics with the lower lay-
ers in the cake, RDF and RDFS, had to be ensured. On the other hand, it should
fit the tradition in knowledge representation, and description logics in partic-
ular. Inference on the axioms in ontologies expressed in OWL is monotonic to
remain unaffected by the addition of new information. OWL therefore adopts
the open world assumption. Lastly, efficient algorithms for the language have
been shown to exist, i.e. it is decidable, and have been implemented in several
reasoners.
The above aspects of the web ontology language are a consequence of the
way it deals with several trade-offs (Horrocks et al., 2003). The most import-
ant of these is perhaps the one between decidability and expressiveness. In this
respect, the development of OWL has been, and still is a cautious one: new
features are only added to the language provided that some suitably efficient
algorithm is known. Decidability of OWL, as a fragment of first order logic,
was therefore only possible by sacrificing expressiveness.
The most prominent hiatus in expressiveness lies exactly where rule based
formalisms find their strength. As most decidable description logics, SROIQ
has the tree-model property, i.e. every concept in the logic has a model only if
it has a tree-shaped model. In a tree-shaped model the interpretation of prop-
erties defines a tree shaped directed graph. In its simplest form, the problem is
that class descriptions cannot be used to distinguish between the two patterns
of individuals in Figure 3.6, i.e. a class description cannot enforce the exist-
ence of an owl:sameAs relation between individuals i4 and i5. In short this also
means that defining the pattern of Figure 7.4 is theoretically impossible in this
language.
Although several decidable fragments of logic programming languages such
as Datalog exist that can express diamond-shaped models, these are exten-
sions of first order logic which operate under the closed world assumption
and thus do not meet the requirement of monotonicity. Furthermore, the de-
velopment of web-based rule languages has proven to be slow going because
of the enormous range of different rule-based languages on the market today.
After its start in 2005, the Rule Interchange Format (RIF) working group has
only released its first public working drafts in 2008 (including a specification

3.6. Discussion 65
of its interoperability with OWL).46
In general it can be said that any knowledge representation language inten-
ded to be used for reasoning necessarily must find a balance between express-
iveness and computational complexity: the trade-off is inevitable. In Chapter 7
I discuss the theoretical considerations and practical limitations of this trade-
off in more detail. However, whether what can be expressed is sufficient or not
depends on what should be represented.
Despite the occasional drop of the ‘O’ word, inevitable in discussing a web
ontology language, this chapter steered clear of any of the pitfalls surround-
ing the term ‘ontology’. Although OWL was presented as a web-based know-
ledge representation language, the fact that it is called an ontology language
is not immediately obvious. The next chapters approach this confusion head-
on. Chapter 4 elucidates the different interpretations of the term (and there
are a couple), leading to the idea of an ontology as knowledge representation
artefact that can be built. Nonetheless, an ontology remains a special breed,
which becomes evident in the discussion of the issues surrounding ontology
construction in Chapter 5.
46See http://www.w3.org/2005/rules/wiki/RIF_Working_Group.

Chapter 4
Ontologies
“We now begin the science of the properties of all things in gen-
eral, which is called ontology. (. . . ) One easily comprehends that
it will contain nothing but all basic concepts and basic proposi-
tions of our a priory cognition in general: for if it is to consider
the properties of all things, then is has as an object nothing but a
thing in general, i.e. every object of thought, thus no determinate
object.”
M. Immanuel Kant (1782–1783)
4.1 Introduction
In Chapter 2, the term ‘ontology’ was introduced as a moniker for the domain
theory of an expert system (Davis et al., 1993, and Section 2.3.2). The func-
tional approach of Levesque (1984) brought us to consider description logics
languages as ideal candidates for the representation of these domain theories
(Section 2.5.1), and Chapter 3 described a particular member of this language
family, the Web Ontology Language, for representing knowledge on the Se-
mantic Web.
For the sake of simplicity, we assumed that the notions of domain theory
and ontology stand in direct correspondence. However, this is not the case and
despite its success, the term ‘ontology’ has remained a rather ungainly char-
acterisation of the things it is used to denote. A large number of academic
publications revolve around a particular ontology, some ontology language, a
methodology for ontology building or a discussion of different kinds of ontolo-
gies. An invariably significant portion of these papers include some definition
of what (an) ontology is. Most cited in this context is the definition of Gruber
(1993, 1994):
66

4.2. Ontologies as Artefacts 71
2003, and Section 2.5.1). In this view, the DL language family was thus not
just meant for terminological knowledge representation, but for ontology rep-
resentation as well.
Ontologies specified in DL are knowledge representations and can be dir-
ectly used as knowledge components. At first sight this seems to conflict with
the idea that an ontology should be part of the knowledge level specification of
a knowledge based system (c.f the quote of Schreiber et al. (1995) on page 67).
However, the notion of an ontology as knowledge base does not necessarily
imply that it should be incorporated in a knowledge based system as is.4 The
knowledge acquisition community was well aware of the developments with
respect to description logics, and these languages were certainly not shunned
by the more formal minded.
Knowledge Management Ontologies
The knowledge acquisition and knowledge management communities, on the
other hand, emphasised a software engineering perspective and adopted the
schematic diagrams of object-oriented modelling and design, and later the in-
dustry standard Unified Modelling Language (UML), to express and specify onto-
logies. In this view, ontologies are primarily meant for human consumption as
part of the design of large scale systems. The CommonKADS methodology used
UML-like diagrams extensively for describing task decompositions, problem
solving methods and ontologies alike (Schreiber et al., 2000). This approach has
been very successful, as for the first time expertise within organisations could
be charted and organised in an intuitive manner. The influence of knowledge
management during the nineties has certainly contributed to the increasing
popularity of ontologies to describe the domain knowledge of experts.
The Conceptual Modelling Language of Schreiber et al. (1994, CML) and
(ML)2 (van Harmelen and Balder, 1992) were proposals for structured lan-
guages that could be used for the specification of CommonKADS models. Con-
trary to (ML)2, CML did not have a formal semantics, but only provided a
structured textual notation and a diagrammatic notation for concepts. How-
ever, as knowledge management does not require a full specification of an
ontology and ontologies could well be just lists of agreed upon keywords or
hierarchies of terms, these languages were only spuriously used.
An important application area for knowledge management is to help organ-
isations deal with the enormous amount of information stored across computer
systems. At the end of the nineties, ontologies started to become used to phys-
ically index the information within organisations. Employees were equipped
with user profiles that expressed their area of expertise in terms of an ontology.
Relevant information that matches the profile could then be brought to the at-
tention of the employee. Because indexing documents by hand is an arduous
task, data mining and natural language processing technologies were applied
to perform automatic ontology extraction and ontology learning.
4In fact, there are several reasons why this is can be technically problematic, cf. Section 7.2

4.2. Ontologies as Artefacts 72
Ontology Meets the Web
Ontologies were increasingly specified using specialised ontology develop-
ment tools. Knowledge acquisition tools such as Protégé (Puerta et al., 1992)
were adapted for the specification and documentation of taxonomies. As a
result, the language in which an ontology was expressed depended more and
more on tools. Also, automatically extracted knowledge management ontolo-
gies were stored in relatively closed legacy database systems. This turned out
to be a significant impediment to reuse, especially considering the growing
need for information exchange between distributed information sources over
the web.
Most existing initiatives to develop an interchange language for ontologies
preceded the development of the web. They were based on the (then prevail-
ing) conception of the web as a relatively slow, but huge local area network,
and not the efficient, social, and uncontrollable means for human computer
interaction it is today. The growing interest in ontologies sparked a renewed
interest in interchange languages, in particular given the possibilities of a new,
versatile syntax offered by XML. The SHOE language (Heflin et al., 1999) can
be regarded in this light: a simple, frame-based syntactic interchange language
for ontologies. Similar lightweight approaches are RDFS and the current SKOS.
The DAML-ONT and OIL languages, on the other hand, were more directly in-
fluenced by the knowledge representation perspective on ontologies.
The DAML+OIL member submission to the W3C5 in 2001 was in many
ways a package deal that could not be scorned. It offered a full-blown know-
ledge representation language in the guise of a web-based ontology exchange
language. Berners-Lee (1999)’s ideal of a Semantic Web was brought a sig-
nificant step closer, and once OWL became a W3C recommendation in 2004
it became the de facto representation language for ontologies. However, for
those primarily interested in the knowledge management aspect of ontologies,
the resulting OWL language was somewhat like a Trojan horse: a relatively
heavyweight formal language sneaked in via the back door.
Nonetheless, the more informal use of ontologies persists until today, such
as in the widespread use of folksonomies, and – quite detached from the web –
as standard vocabularies for governments and communities of practice. Many
of these lightweight knowledge management ontologies are represented using
the relatively inexpressive RDFS or SKOS, but a surprisingly large number are
in OWL Full as well (though often by accident, Wang and Parsia (2007)).
Since McCarthy (1980) and Davis et al. (1993) borrowed the term ‘ontology’
from philosophy, the interpretation of the term in AI has shifted from an essen-
tial part of the specification of knowledge based systems, to standard vocab-
ularies and full-blown terminological knowledge bases on the web, or even –
as we did in Chapter 3 – any OWL file. Nonetheless, not all has been said,
as philosophy certainly did not stand by idly while a centuries-old tradition
was hijacked by a bunch of computer enthusiasts. The next section describes
Ontology as conceived of in philosophy, and Section 4.4 discusses the main
differences between the the two views.
5See http://www.w3.org/Submission/2001/12/

4.3. Ontology in Philosophy 73
4.3 Ontology in Philosophy
In philosophy, the term Ontology is used in the context of the analysis of the
fundamental building blocks of reality, the metaphysical study of existence by
first principles: what makes that some thing exists, and how can we ascertain
the existence of some thing? As Leibniz put it:
“Ontology or the science of something and of nothing, of being and not-being,
of the thing and the mode of the thing, of substance and accident.”
Gottfried W. Leibniz, in (Leibniz, 1903, p.512)
Ontology thus concerns the top-down deconstruction of reality as we per-
ceive it: eliminate its accidental appearance and reduce it to its very bare bones.
If we look at Kant’s description of the ‘science of ontology’, we can conclude
that the method adopted in philosophical ontology is to focus primarily on
those things objects in the world have in common:
“. . . ontology, the science, namely, which is concerned with the more general
properties of all things.”
Immanuel Kant, in Kant (1997)
It is the commonalities (and disparities) that are the subject of ontological
study, and which are used to construct a comprehensive representation of real-
ity. Important also is that it is the study of general properties that all things
have in common, and not of ad-hoc categories. It identifies elements in general
which can be applied to account for differences in particular. Ontology oper-
ates on a meta level with respect to the things in the domain of discourse. For
example, instead of studying the properties that make physical entities differ
from mental entities, ontology studies what properties are by themselves. This
in line with Aristotle’s description of Ontology, which, in his sense, tries to an-
swer the question “What is being?”, or as Guarino (1997) rephrases it, “What
are the features common to all beings?”:
Ontology is the science of being as such: unlike the other sciences, each of which
investigates a class of beings and their determinations. Ontology regards “all
the species of being qua being and the attributes which belong to it qua being”.
Aristotle, Metaphysics, IV, 1, from Guarino (1997)
Instead of specifying a vocabulary, Ontology thus tries to pinpoint the vocab-
ulary used to describe things in the world; it usually adopts realism, i.e. the be-
lief that reality exists independently of human observers. It assumes (or even
requires) a direct correspondence between the elements in the ontology and
entities ‘out there’; and is focused at the primitives of being. Consequently, an
ontology is to capture directly the domain of discourse.6 The high level of ab-
straction enables a philosopher to reason a priori with respect to the elements
6Usually life, the universe and everything

4.3. Ontology in Philosophy 75
progress is measured “by the degree to which one can ‘explain away’ appar-
ent philosophical givens in terms of less controversial entities”. According to
Smith, this perversion leads to a simplification of the world – the subject matter
of Ontology. Not as an inevitable by-product of the use of a formal language,
but rather due to the application of an overly simple mathematical formalisa-
tion. For, what evidence is there to expect that the logical constructs devised
by Frege to explain and define mathematical theory are equally well suited to
capture ontological theory?
Smith illustrates this practice by positing a school of thought by the name
of ‘fantology’, the idea that ontological form corresponds to one and two-placed
predicates of the form Fa and Rab (Smith, 2005). This view confounds the first
role of formal Ontology – to capture ontological theory in a formal language
– with the study of ‘forms of being’, by equating ontological form to logical
form. Arguably this is problematic, as this conflation allows the application
of common operators of logic such as the Boolean and and or, to ontological
categories: ontological truth becomes equivalent to logical truth.
In this conception, the predicate F carries the meaning, whereas the sub-
ject a is a ‘mere meaningless name, a matter of pure denotation’ (Smith, 2005).
Although nothing in logic prevents us to ascribe meaning to the subject of a
predicate, the prevailing philosophical interpretation is that they refer only
to individual objects. Furthermore, the predicates themselves are not ontolo-
gically neutral (Smith, 2004). For example, the relations is_narrower_than and
part_of are certainly not of the same type. Where the former expresses a rela-
tion between meanings, the latter expresses a structural tie between universals.
Smith argues for a system where not the predicates, but indeed the subjects
of those predicates carry meaning. The predicates themselves ‘do not repres-
ent’, but rather are what link together variable and constant terms. In this
proposal Smith eliminates unary predicates altogether, and restricts the num-
ber of allowed relational predicates to a fixed set, containing amongst others
subsumption, parthood and dependency relations. A restriction that was also
advocated by Breuker and Wielinga (1987). Recall that in the 1970’s semantic
networks were criticised because their structure was too generic and semantic-
ally unclear (cf. Section 2.2.3). The solution was to develop languages that
contained a fixed set of knowledge structuring primitives. Though given by
different reasons, the proposal by Smith is in fact analogous to this solution.
Guarino (1994) takes a different approach, and proposes to limit the scope
of predicates by formulating semantic constraints. These can be used to ex-
press the difference between e.g. sortals and non sortals, i.e. predicates that are
substantial, e.g. whether some entity is an apple, apple(x), and those that ex-
press a mere characterisation, such as red(x).8 This way, it is thought, a rigour-
ous ontological foundation of the primitives in some knowledge representation
language can guarantee a consistent interpretation of theories across different
domains.
However, from a knowledge representation perspective, it is unclear how
such a priori distinction between predicates on entities is possible. Or at least,
how it is different from any other restriction posed in a knowledge base itself
– and not in an ontological layer incorporated in the representation language.
8Guarino (1994) also introduces rigidity. See the discussion on the ONTOCLEAN methodology
in Section 5.5.1 for a more in depth discussion of this notion.

4.4. Two Kinds of Ontologies 78
Generic Concept Universal
ParticularIndividual Concept
denotation
denotation
i
n
s
t
a
n
t
i
a
t
i
o
n
i
n
d
i
v
i
d
u
a
t
i
o
n
Figure 4.1: Ontological relations in Realism
existence of elements in the ontology. The ontology specifies that which a sys-
tem ‘knows’ about:
An (AI-) ontology is a theory of what entities can exist in the mind of a know-
ledgeable agent.
Wielinga and Schreiber (1993)
In other words, the ontology prescribes what entities can be distinguished,
or rather individuated inside a knowledge base: an ontology encompasses its
generic concepts. Recall the relation between a knowledge representation and
entities in reality in Brachman’s meaning triangle of Figure 2.4.10 Admittedly,
both generic and individual concepts in a knowledge representation can be
related to some entity (individual object) in reality through instantiation and
denotation, respectively. It is the ontological status and strength of these re-
lations as to which philosophy and AI differ. Firstly, in AI, denotation is a
correspondence relation between a concept in a knowledge base and some en-
tity in reality. It is generally true that an individual will only be asserted into a
knowledge base given some corresponding entity, but this is not enforced. In
fact, individuals are often asserted for purely practical reasons, as mere data-
base keys. Secondly, instantiation of a generic concept by an entity is an even
weaker relation in the ontological sense: the entity merely exemplifies the gen-
eric concept.
These are considerable weaker versions of their philosophical interpreta-
tions, especially in comparison to the position of realism. Realism holds the
existence of universals, properties such as ‘’being an apple’ that hold in multiple
places, or rather are instantiated by multiple particulars. Using KR wording,
realism essentially adopts the stance that reality contains properties (entities)
denoted by generic concepts (see Figure 4.1). As AI makes no such claims, pro-
posals for definitions of ‘ontology’ are often accused of adopting the opposite
position of nominalism, which holds that universals only hold as names.
However, this is a false accusation as has been made clear by more philo-
sophically aware AI researchers. For instance, Genesereth and Nilsson (1987)
who coined the word ‘conceptualisation’ on which Gruber’s definition is based,
10Keep in mind that Brachman did not distinguish symbol level and knowledge level represent-
ation.

4.5. Discussion 81
Although the ontology types and languages do not correspond directly,
confusion may arise when one of the language paradigms is applied in the
representation of a different ontology type. The following chapter outlines re-
quirements and methodological guidelines for the construction of ontologies
needed to ensure both their reusability and ontological nature. Chapter 6 de-
scribes the construction of a core ontology for the legal domain that aims to
maximise these factors.

Chapter 5
Ontology Engineering
A common mistake that people make when trying to design
something completely foolproof is to underestimate the ingenu-
ity of complete fools.
Douglas Adams
5.1 Introduction
Over the years several design principles have been cast in ontology engineer-
ing methodologies to improve the quality of ontology development. And for-
tunately, ontologies are not necessarily drafted from scratch. The widespread
availability of ontologies on the web has opened the door to the adoption of
pre-existing general ontologies. By providing an initial structure and a set of
basic concepts and relations, these ontologies can be a valuable jump start for
more specific ontology development.
On the other hand, an ontology is not just any terminological knowledge
base, but rather embodies a specific definitional perspective. Where the repres-
entation of terminological knowledge is based on Minsky’s notion of a frame
– concepts are defined by the typical context in which they occur – an on-
tology refines this notion and needs to distinguish between the inherent and
accidental properties of concepts (Breuker and Hoekstra, 2004c; Guarino and
Welty, 2002; Bodenreider et al., 2004). Although a typical property such as
‘position’ is clearly relevant from a knowledge engineering perspective, onto-
logically speaking it is usually a side issue: changing the position of an object
does not make it intrinsically different. This epistemological promiscuity of ter-
minological knowledge representation has led to the formulation of several
design principles, such as in ONTOCLEAN (Guarino and Welty, 2002, 2004) and
in Breuker and Hoekstra (2004c); Breuker et al. (2004); Hoekstra et al. (2008).
82

5.2. Criteria and Methodology 83
A more recent development is the identification of design patterns that are
meant to overcome some of the limitations in the reuse of existing ontologies
and the application of design principles. Where the former are frequently quite
large and heavyweight, and are therefore hard to mould and extend to a us-
able domain ontology, the latter are quite abstract and difficult to translate into
concrete definitions in the ontology. Design patterns offer a middle ground
between the two, where the methodological principles are made concrete in
manageable ‘bite-sized’ chunks (Gangemi, 2005, a.o.). Furthermore, these pat-
terns can assist in tackling problems related to the ontology representation lan-
guage of choice (Hoekstra and Breuker, 2008, a.o.).
This chapter gives an overview of each of these four approaches and dis-
cusses their strong points and weaknesses.
5.2 Criteria and Methodology
During the mid-nineties, experience in several large scale ontologies led to a
widespread consensus that the ontology engineering field was in need of meth-
odological grounding. Independently, the design principles and experience of
several ontology efforts were put to paper. Most influential, in this respect are
the experiences of the TOVE (Grüninger and Fox, 1995, TOronto Virtual En-
terprise) and Enterprise ontologies (Uschold and King, 1995). Both ontologies
were developed to enable the specification and sharing of descriptions of busi-
ness processes. On the basis of experiences in ontology development for the
Ontolingua system in Gruber (1993), Gruber identified a trade off between five
design criteria (Gruber, 1994):
Clarity
An ontology should effectively communicate the intended meaning of
defined terms. Definitions should be objective, formal (if possible), and
documented with natural language.
Coherence
An ontology should sanction inferences that are consistent with the defin-
itions.
Extensibility
An ontology should be structured such that it can be extended and spe-
cialised monotonically, i.e. without needing to change the ontology itself.
Minimal encoding bias
The conceptualisation should be specified at the knowledge level, without
depending on a particular symbol level encoding, e.g. constructions for
convenience of notation or implementation.
Minimal ontological commitment
An ontology should only enforce the minimal commitment necessary to
support the intended knowledge sharing activities.
The trade-off lies in the fact that these criteria cannot be considered inde-
pendently. The clarity and coherence of an ontology benefits from a formal
specification. But every formal specification involves an inherent concession

5.2. Criteria and Methodology 85
In the second phase, purpose and scope of the ontology are identified. Hav-
ing a clear understanding of why the ontology is developed, its possible use
and users, gives a handle on the design decisions necessary in consecutive
phases. Grüninger and Fox (1995) advocate the description of motivating scen-
arios that explain possible use of the ontology and use these to formulate a set
of competency questions that should be answerable given the terminology to
be defined in the ontology. The purpose of an ontology should not be conflated
with the task-dependence of knowledge based system development. In prin-
ciple an ontology does not sanction a particular use of its contents, but it may
be designed to fit a purpose as a whole, i.e. how the ontology is used in relation
to other knowledge components. The scope of an ontology is its maximal po-
tential coverage in a domain, that is all knowledge inferable from its axioms.
Scope therefore only partly relates to the size of the ontology.
Ontology building is the next phase and consists of an interplay between
three closely related tasks: capture, coding and integration. Ontology capture
is the identification of key concepts and relations, the production of precise
definitions in natural language, and the important task of choosing the proper
term to refer to these ontology elements. Natural language definitions are in
fact the primary source of documentation for people unacquainted with the
resulting ontology. Ontology browsers such as Ontolingua and the more re-
cent TONES Repository browser,2 as well as the mainstream ontology editors
Protégé and TopBraid present axioms and local annotations in the same view.
Once the main concepts and relations have been identified and described,
they are to be represented in some language. Ontology coding thus naturally
involves a commitment to a particular knowledge representation formalism; a
commitment that needs to be well motivated because the level of formality has
a direct effect on the diligence required of the ontology engineer. The choice
for a particular knowledge representation language involves two important
commitments (see Chapter 4):
 A direct ontological commitment to the structure imposed on the world
by the primitives and semantics of that language, and secondly,
 a more formal definition of a concept implies a stronger commitment to a
particular interpretation.
The most suitable level of formality is determined by the purpose of the
ontology. A knowledge representation ontology that is to play a part in reason-
ing requires a more limited formal language than a formal ontology in philo-
sophy, see Section 4.2. Similarly, a knowledge management ontology that is
merely used to annotate resources for the purposes of lightweight information
retrieval inspires less concern for logical consequence, but still calls for ma-
chine interpretability. The developer of an ontology that merely expresses an
agreed upon vocabulary to be used within a community of practice might even
skip the coding step entirely and suffice with a list of definitions in natural lan-
guage only. For example, it may not be very useful for languages such as the
Dublin Core metadata initiative3, FOAF4 and RSS5 to include exact ontologic-
2See http://owl.cs.manchester.ac.uk/repository/browser
3See http://dublincore.org/documents/dces/
4Friend Of A Friend, see http://www.foaf-project.org/
5RDF Site Summary, see http://en.wikipedia.org/wiki/RSS_(file_format). RSS
currently has various dialects.

5.2. Criteria and Methodology 86
ally concise, rigourous formal definition of the exact meaning of concepts such
as ‘author’, ‘friend’ or ‘news’. On the other hand, a formally specified biomed-
ical ontology may be used in conjunction with a standard reasoning engine to
automatically classify proteins into functional classes (cf. Section 7.4).
The third task in the building phase is to take advantage of knowledge re-
use by integrating the ontology with already existing ontologies. A natural
step, it may seem, but in practice this can be quite demanding. First of all, it
requires a thorough understanding of the imported ontology. This is because
importing another ontology does put a strain on the principle of minimal on-
tological commitment: it may significantly extend the size of your ontology.
The mere fact that some other ontology contains a proper definition of some
concept that is within scope, is often not enough reason to include it. Are the
other concepts in the imported ontology within scope, and does the imported
ontology support our purpose? It should be clear what the assumptions under-
lying the other ontology are. Secondly, if formally specified, the imported onto-
logy must at least be formally compatible with the knowledge representation
formalism selected in the coding task. Arguably, as Uschold and Grüninger
(1996) point out, the three tasks should not be performed in sequence. The
choice for a particular formalism in part depends on the availability of suitably
specified other ontologies.
In the final phase the ontology is evaluated with respect to the requirements
specified earlier. If a formal language is used, the competency questions can
be reformulated in this language to check compliance and coverage. Secondly,
if deviations from the initial outset become clear, it should be checked whether
these are well motivated.
5.2.1 A Social Activity?
Most methodologies followed in the footsteps of earlier experiences in know-
ledge acquisition, such as the CommonKADS approach of Schreiber et al. (2000).
The methodologies of Uschold and King (1995); Fernández et al. (1997) in-
variably adopt a typical knowledge acquisition approach aimed at maximising
coverage. Expert interviews, brainstorming sessions and text analysis are used
to gather as much information about the domain as possible. This information
is then used as the resource material for the actual construction of the ontology.
However, inspiration to reach a mature ontology engineering methodology
was sought in adjacent engineering fields in computer science as well. The
METHONTOLOGY methodology of Fernández et al. (1997); Fernández-López
and Gómez-Pérez (2002) incorporated best practices from software engineer-
ing methodologies. In particular, Fernández-López and Gómez-Pérez (2002)
regard ontology engineering as a software development process, and intro-
duces the notion of an ontology development lifecycle: rather than building on-
tologies from scratch, it emphasises development as a continuous refactoring
of already existing ontologies.
When Gruber formulated his criteria, the most prominent use case for on-
tologies was the ability to share and reuse knowledge across both systems and
communities. The prevalent expectation was therefore that ontologies would
be large scale and built by many different people in concert. Since ontologies are
intended to capture a shared view on some domain, their development is much

5.3. Categories and Structure 88
On Weak Hearted Surgeons
To recapitulate, the emphasis on standardisation did not have the expected
result. True, several ontologies are currently used as standard vocabularies,
but these were not developed through a process of standardisation, rather they
were adopted as standards or reflect an already existing standard. It is further-
more unclear whether ontology engineering as social activity has any benefi-
cial effect on the quality of the resulting ontology. Are ontologies based on
consensus ‘better’ ontologies? Experience shows that this is not necessarily the
case, if only because different parties may not even agree on the purpose of
the ontology. For instance, if the ontology is to “facilitate knowledge exchange
between applications” this may be interpreted as “the ontology should cover
the knowledge expressed by my application” by individual contributors. The
result is that politics get in the way of quality, and definitions are tweaked for
the sake of consensus. This is evident in e.g. FOAF which includes a wide
range of properties to refer to the name of persons: foaf:name, foaf:givenname,
foaf:firstName, foaf:family_name and foaf:surname. But it was also what even-
tually stopped SUO progress; a consensus ontology was drafted which was
deemed unacceptable by some on theoretical grounds.
A second impediment to ontology construction as social activity, is that con-
trary to standardisation in general, we are not dealing with a level playing
field. The formal definition of terms is often quite technical, which means that
not every interested party can fully participate in the definition process. Who
would like to confront a subject matter experts with the intricacies of the in-
teraction between global domain and range restrictions and existential restric-
tions on classes? Furthermore, the activity is otherwise constrained as well: a
formal representation language typically puts limitations on what can be ex-
pressed, the most general restriction being consistency. For a long time it was
held that ontology engineering required ontologies to be specified at the know-
ledge level, rather than directly in a representation formalism. Of course, the
knowledge management view of ontology is compatible with this perspective,
and most ontology engineering methodologies do not really pay much atten-
tion to this language bias. However, they do take into account the effects of
order dependence in taxonomy construction.
5.3 Categories and Structure
Building an ontology starts from a general idea of its purpose and scope. The
way in which this overview is translated into a concrete set of concept defini-
tions is not trivial. In particular, the process is order dependent and traditional
top-down and bottom-up approaches introduce a bias. Working top-down by
starting with a set of general terms, as traditionally practised in metaphysics,
risks imprecision or rework: more specific concepts may not directly fit the
general ones and provide an almost unlimited source for revisions to the top
level. On the other hand, naïve bottom-up specification risks the definition of
many detailed concepts that turn out to be unimportant, or incompatible at a
later stage.
Hayes (1985) proposes an approach to the development of a large-scale
knowledge base of naive physics. He rejects top-down construction in favour

5.4. Ontology Integration 91
representation. But it turns out that this drawback is only partially lifted by
the middle-out approach. Basic level concepts introduce a similar bias as they
too can only be defined in context with other concepts. This context is largely
implicit and inaccessible because of the cognitive primitive nature of the basic
level.
In short, basic concepts cannot be defined prior to other concepts as the
middle-out approach suggests. It is rather the other way around. Basic level
concepts give a ‘feel’ of relatedness and context. They are an ideal entry point
to carve up the domain into relatively independent clusters, and play an im-
portant role in the definition of less basic notions. Lakoff’s basic concepts
should therefore be seen as being at the core of Schank and Abelson’s scripts
and Minsky’s frames (Section 2.2.4). Regarded as independent entities they are
atomic. They do not carry any meaning, but rather function as meaning pro-
viders to surrounding notions. Their own meaning, however, can only really
emerge through their use in other definitions.
5.3.2 Beyond Categories
To be frank, this is as far as ontology engineering methodologies go. They
do not really venture beyond well-meant, but gratuitous advice such as ‘be
sure of what you want before you start’, ‘document your decisions well, you
might forget them later’ and ‘if the problem is too big, chop it up into smaller
chunks’. The decomposition into various phases therefore plays the role of the
user manual no-one ever reads.
Admittedly, several suggestions are genuinely helpful and convey a deeper
understanding of what knowledge engineering entails. Ontology engineer-
ing is often called an art or craft, rather than a science or proper engineer-
ing field such as mechanical engineering or software engineering (Fernández-
López and Gómez-Pérez, 2002). Although this claim is often cited, it is never
really substantiated. What it does hint at, however, is that somewhere along the
line something magical happens. Apparently some inaccessible mental skill
only found in an experienced knowledge engineer can turn some bit of know-
ledge into an adequate representation. The adoption of Lakoff’s basic level
by Uschold and King was a conscious move to apply insights from cognitive
science to lay bare a part of this process.
We have seen that basic level concepts can help in the formation of clusters
and the construction of definitions of non basic concepts without the strait-
jacket of top-down and anarchy of bottom-up development. However, there is
no methodological support for the way in which the definitions in an ontology
are specified in practice. Ontology construction is to proceed ‘upward’ and
‘downward’ from the basic level, but how?
5.4 Ontology Integration
Ontologies are rarely constructed without at least a pre-existing conception
of that which is to be represented. They can be meant to directly express an
existing theory, as we have seen in the biomedical domain, or capture some
body of expert knowledge. Even in the least restricted case, where an ontology
is meant to represent common knowledge, that which is to be represented is