Programming Rational Agents

in Goal
Draft
c _ Koen V. Hindriks
September 29, 2010
2
Contents
Preface 5
1 Rational Agents 7
1.1 What is an Agent? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Applying the Intentional Stance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 What is Common Sense? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 What is Rationality? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2 First-Order and Higher-Order Intentional Systems . . . . . . . . . . . . . . 12
1.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Automated Reasoning and Knowledge Representation 17
2.1 Knowledge Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 First-Order Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 First-Order Languages: Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 First-Order Languages: Semantics . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.3 Reasoning with First-Order Logic: Model-Checking . . . . . . . . . . . . . . 26
2.2.4 Reasoning with First-Order Logic: Resolution-Based Proofs . . . . . . . . . 29
2.2.5 Decidability, Computability, and Fragments of First-Order Logic . . . . . . 33
2.3 Logic Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1 Prolog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 Mental States 37
3.1 Representing Knowledge, Beliefs and Goals . . . . . . . . . . . . . . . . . . . . . . 37
3.1.1 Example Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.2 Mental State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Inspecting an Agents Mental State . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.1 Mental Atoms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.2 Mental State Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4 Actions and Change 51
4.1 Action Specications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1.2 Postconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.3 Updating an Agents Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Built-in Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3
4 CONTENTS
5 GOAL Agent Programs 61
5.1 The Structure of an Agent Program . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 A Hello World Example: The Blocks World . . . . . . . . . . . . . . . . . . . . . 64
5.3 Selecting Actions: Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 Rule Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5 Rules with Composed Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.6 Environments and Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.7 Action versus Percept Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.8 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.9 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6 Modules and Focus of Attention 75
6.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2.1 Module Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2.2 Focus of Attention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.2.3 Reactive and Goal-Based Modules . . . . . . . . . . . . . . . . . . . . . . . 79
6.3 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7 Communicating Rational Agents 81
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2 Multi-Agent Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2.1 Example MAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2.2 MAS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2.3 Automatic agent and me fact generation . . . . . . . . . . . . . . . . . . . 85
7.2.4 Example MAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4 Send Action and Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4.1 The send action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4.2 Mailbox management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.4.3 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.5 Moods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.6 Agent Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.6.1 send action syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.6.2 The agent and me facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.7 send action processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.8.1 Coee domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.9 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.10 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.10.1 Milk cow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.11 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8 Reasoning About Agents 101
8.1 Semantics of Mental States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.2 Semantics of Actions and Action Selection . . . . . . . . . . . . . . . . . . . . . . . 105
8.3 Verication Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
A SWI Prolog Operators in GOAL 113
Preface
The Goal language has developed into an agent programming language with a rich set of pro-
gramming constructs and features to write agent programs. A range of dierent examples have
been provided and used in teaching. The environments used include the classic Blocks World (and
a dynamic variant where users can interfere called the Tower environment), a wumpus world, an
elevator simulator, and, the most challenging environment, Unreal Tournament 2004. This
last environment has been used in a large student project with over 60 students. Students pro-
grammed a Goal multi-agent system to control a team of bots in a capture the ag scenario
that were run against each other in a nal competition. Goal has also been applied to robotics;
it is currently, for example, being used for controlling the academic version of Nao robots from
Aldebaran.
As we are continuously developing Goal, we suggest you regularly check the Goal website:
http://mmi.tudelft.nl/koen/goal. We also appreciate your feedback on this manual
and your experience with working with Goal. You can mail us at: [email protected].
Koen V. Hindriks, Utrecht, 2010
5
6 CONTENTS
Acknowledgements
Getting to where we are now would not have been possible without many others who contributed to
the Goal project. I would like to thank everyone who has contributed to the development of Goal,
by helping to implement the language, developing the theoretical foundations, or contributing to
extensions of Goal. The list of people who have been involved one way or the other in the Goal
story so far, all of which I would like to thank are: Lacramioaria Astefanoaei, Frank de Boer,
Mehdi Dastani, Wiebe van der Hoek, Catholijn Jonker, John-Jules Ch. Meyer, Peter Novak, M.
Birna van Riemsdijk, Tijmen Roberti, Nick Tinnemeier, Wietske Visser, Wouter de Vries. Special
thanks go to Paul Harrenstein, who suggested the acronym Goal to me, and Wouter Pasman,
who did most of the programming of the Goal interpreter.
Chapter 1
Rational Agents
The goal of this book is to introduce a toolbox that is useful to develop rational agents. The toolbox
that we will introduce here is based on the conviction that it is useful to take an engineering stance
based on common sense to develop such agents. The toolbox consists of an agent programming
language that incorporates key concepts derived from common sense, such as beliefs and goals, and
of some of the techniques developed within Articial Intelligence, such as knowledge representation
and planning.
One of the goals of Articial Intelligence, in its early days, has been to create a machine that
like humans is able to use common sense to decide on an action to perform next. Achieving
this goal has been much more dicult than initially conceived
1
and instead of focusing on this
grand vision, research in Articial Intelligence has been mostly concentrated on various subareas
that are related to and seem necessary to achieve this goal, including topics such as knowledge
representation, planning, learning, vision, and, for example, natural language processing. Articial
Intelligence has become more of an engineering discipline aimed at developingsmart applications
than a discipline aimed at implementing machine intelligence. Recently, however, there has been
renewed interest in developing a machine with articial general intelligence [70, 28]. Although
most Articial Intelligence researchers today thus would not consider their work as contributing
directly to the early grand vision, it is interesting to trace some of the early thoughts on creating
such machines. For now, we refer the reader to [62], chapter 1.
One of the key challenges for Articial Intelligence is to actually build rational agents. An
approach is needed that facilitates the construction of such computational entities in a principled
way. Ideally, such an approach is based on a theory of what rational agents are. We believe such
an approach can be provided by providing a programming framework for rational agents, and we
explore some of the ideas that inspire such an approach below. As has been well put in [46],
our concern, however, is not with providing [a cognitively plausible model], but in constructing
simple yet adequate models which will allow eective control of behaviour.
1.1 What is an Agent?
If we want to use the notion of an agent to develop software, it is important to get a clearer
picture of what an agent is exactly. Generally speaking, an agent is anything that can be viewed
as perceiving its environment through sensors and acting upon that environment through actuators
[62]. This denition of an agent is not particular to Articial Intelligence, but it does identify
some of the concerns that need to be dealt with by an agent designer. In order to develop an
agent that will be successful in achieving its design objectives, it will be important to identify
the percepts that the agent may receive and inform it about the current state of its environment
and to identify which actions an agent may perform to change its environment and how these
1
Consider, for example, the early ambitions which clearly speak from such facts as the name General Problem
Solver that Newell and Simon used for their system discussed in [54].
7
8 CHAPTER 1. RATIONAL AGENTS
actions aect the environment.
2
This concept of agent suggests an agent should have some basic
abilities to process percepts and select actions, but does not yet address the fundamental problem
of Articial Intelligence: How to select the right thing to do? The agent itself remains a blackbox
and therefore is too generic to base a theory of agent programming on.
Various other characteristics have been identied to dierentiate software agents from other
types of software programs [73]. Agents are situated in an environment, are reactive in that they
are able to perceive their environment and respond in a timely fashion to perceived changes in their
environment, are proactive in that they are goal-directed and take the initiative by performing
actions that achieve their goals, and, nally, agents are social in that they communicate with
other agents and are part of a multi-agent system. The notion of agency that is dened by these
characteristics has also been labeled the weak notion of agency. Any software program that is
situated, reactive, proactive and social thus would be an agent in this sense. Although we think
these notions are useful to dierentiate agents from non-agents, the notions themselves are too
broad to be of direct use in engineering an agent. Additional explanation is required to clarify
what it means to respond in a timely fashion, and to take the initiative, and how to implement
these characteristics in a software agent.
One notion that has consistently been used by many researchers to dierentiate agents from
other software entities is the notion of autonomy. [73] say that agents that operate without the
intervention of others, and have control over their actions and internal state are autonomous. This
denition of what it means to be autonomous seems inspired by a perceived dierence between the
agent-oriented and object-oriented programming paradigm: whereas objects do not have control
over their states nor actions as methods provided by that object may be called by any other object
that has access to it, this is not the case with agents. Agents supposedly decide on their actions
autonomously. [73] propose autonomy as a dening feature of agents but do not clarify the role
this notion can have in the design of agents. Various attempts to do so have been based on the
idea that autonomy is a gradual notion and that dierent levels of autonomy may be identied.
The idea is that an agent may be autonomous with respect to some decisions but should ask e.g.
a user for assistance if it lacks the authority to decide on its own. Exploring the related issues has
given rise to research on what is called adjustable autonomy.
Other notions of agency have been based on exploiting the common sense notions that Articial
Intelligence in its early days tried to formalize and implement in a machine. The idea has been to
implement agents by explicitly modeling their beliefs, desires, goals, intentions, plans, etc. A key
source of inspiration has been the work of [23] on what he called the intentional stance. The
idea of agents as intentional systems has been picked up by various researchers, some of the more
prominent examples are [65, 66] and [73].
Interestingly, denitions of agency have also been discussed in the context of dynamical systems
theory, which typically is more oriented towards physical and biological systems. Although we are
most interested here in software agents there are clear relations between this type of work and
robotics in Articial Intelligence. An agent is dened in [4] as a system that is a distinct individual
that stands out in its environment and has its own identity, interacts with its environment and
initiates activity, and has goals or norms that are pursued by the system. Dening an agent as an
individual means to set it apart from its environment and other agents. A key aspect of agency
in [4] is the asymmetry between an agent and its environment. [4] assume that an agent always
is coupled with an environment and an agent interacts with its environment. The interaction
between an agent and its environment is asymmetrical, however, as an agent initiates actions
to change its environment but not vice versa. An agent may be characterized as the center of
inuence in the terminology of [4]. In our context, however, interactional asymmetry is described
more fruitfully using intentional terminology than the physical terminology of [4]. Interactional
asymmetry then means that an agent initiates and chooses to perform actions intentionally in its
environment. The environment itself only responds to the agents initiatives but does not itself
2
Note that an environment does not need to be a physical environment. An agent may be a physical robot acting
in a physical environment but may also be an entity that is part of a software environment such as a softbot that
searches the World Wide Web.
1.2. APPLYING THE INTENTIONAL STANCE 9
make such intentional choices.
3
1.2 Applying the Intentional Stance
In Articial Intelligence, various common sense concepts are used to explain some of the core
research areas. For example, planning research develops techniques to construct plans for an
agent to achieve a goal, and work on knowledge representation develops languages to represent
and reason with the knowledge of an agent. Although the intuitions that guide this research are
derived from the everyday, common sense meanings of these concepts, the techniques and languages
developed within Articial Intelligence have produced formal counterparts of these concepts that
are not as rich in meaning and deviate in other ways. Even so, in practice our everyday intuitions
have proven useful for developing specic applications when using these formal notions (cf. [65]).
The key notions to explain what a rational agent are involve precisely these same concepts of
knowledge, belief and goals, and the idea naturally arises that it would be most useful to use these
concepts not only to describe but also to engineer such agents. Engineering agents in terms of the
beliefs and goals they have, and the choice of action they derive from these beliefs and goals may
be advantageous for several reasons. As [48] wrote:
It is useful when the ascription [of intentional notions] helps us understand the structure
of the machine, its past or future behavior, or how to repair or improve it. (p. 1)
The belief and goal structure is likely to be close to the structure the designer of the
program had in mind, and it may be easier to debug the program in terms of this
structure [...]. In fact, it is often possible for someone to correct a fault by reasoning
in general terms about the information in a program or machine, diagnosing what
is wrong as a false belief, and looking at the details of the program or machine only
suciently to determine how the false belief is represented and what mechanism caused
it to arise. (p. 5)
The idea to use common sense notions to build programs can be traced back to the beginnings of
Articial Intelligence. Shoham, who was one of the rst to propose a new programming paradigm
that he called agent-oriented programming, cites McCarthy about the usefulness of ascribing such
notions to machines [48, 66]. One of the rst papers on Articial Intelligence, also written by
McCarthy, is called Programs with Common Sense [47]. It has been realized that in order to have
machines compute with such notions it is imperative to precisely specify their meaning [66]. To
this end, various logical accounts have been proposed, mainly using modal logic, to clarify the
core common sense meaning of these notions [17, 41, 60]. These accounts have aimed to precisely
capture the essence of a conceptual scheme based on common sense that may also be useful and
applicable in specifying rational agent programs. The rst challenge thus is to provide a well-
dened semantics for the notions of belief, goal and action which can also provide a computational
interpretation of these notions useful for programming agents.
One of the dierences between the approach promoted here and earlier attempts to put common
sense concepts to good use in Articial Intelligence is that we take an engineering stance (contrast
[47] and [66]). The concepts are used to introduce a new agent programming language that
provides useful programming constructs to develop agent programs. The second challenge is to
provide agent programming language that is practical, transparent, and useful. It must be practical
in the sense of being easy to use, transparent in the sense of being easy to understand, and useful
in the sense of providing a language that can solve real problems.
What is the intentional stance? According to Dennett, it is a strategy that consists of treating
the object whose behavior you want to predict as a rational agent with beliefs and desires (...)
3
[4] dene interactional asymmetry in terms of structural coupling: An agent is a system that systematically
and repeatedly modulates its structural coupling with the environment. From a software engineering point of view,
this characterization may be too strong however as most agent systems do not dynamically change their coupling
with an environment (if coupled at all).
10 CHAPTER 1. RATIONAL AGENTS
[23].
4
A more detailed description of the strategy is oered by Dennett [23]:
rst you decide to treat the object whose behavior is to be predicted as a rational
agent; then you gure out what beliefs that agent ought to have, given its place in
the world and its purpose. Then you gure out what desires it ought to have, on the
same considerations, and nally you predict that this rational agent will act to further
its goals in the light of its beliefs. A little practical reasoning from the chosen set of
beliefs and desires will in many - but not all - instances yield a decision about what
the agent ought to do
The intentional stance is here promoted as an engineering stance or design stance. We will
label certain parts of programs that implement rational agents knowledge, beliefs, and goals. Of
course, at certain times you may nd yourself wondering and asking yourself: Are these things we
have called beliefs not just statements stored in a database? Are these things that we call goals
not just simple statements in a second database? And, to be as explicit as possible, of course,
you would be right. We have just labelled these databases belief and goal base and the statements
that are stored in these databases beliefs and goals. There is no sense in which we would want
to defend a position that these statements are really beliefs or goals. What we advocate here is a
particular stance, a way of looking at whats inside an agent, by means of concepts such as belief
and goal. In a sense, by taking such a pragmatic stance, one cannot argue then anymore; who
would say we are not allowed to use this mentalistic language if it suits our purposes for describing
agents. Only those apparently oended by it. In reply, we may point out however that we have
only promoted an engineering stance.
Does this leave no room for discussion then? There is, as is apparent from the dierent
approaches that have been proposed and defended within the eld of autonomous agents. The
point is that we still have to at least clarify that our use of mentalistic language matches with
common sense and our basic understanding of these concepts. It simply does not make sense to
label just about anything a goal. Here, we return to the points made above: The use of mentalistic
terminology, from our perspective, should be useful, and we believe it will only be so if there is
a sucientoverlap in our common use of concepts such as beliefs and goals with the way these
concepts are used within agent-oriented programming (and, for that matter, agent technology more
broadly). Achieving this goal is not a simple task, and requires a careful design and explanation
of how we can apply our common sense intuitions to engineer rational agents.
1.3 What is Common Sense?
If we want to use common sense to design and develop agents, we rst need to make more explicit
what we mean by common sense. In a sense, this is clear to all of us, as it is an understanding that
is common to us all. It is useful to make this understanding explicit, however, in order to be able
to discuss which elements are useful as part of a toolbox to develop agents and which elements
are less useful. It turns out that this is harder than expected and to a certain extend an analogy
may be drawn here with explicating the underlying grammar of natural language: Although we
all know how to use natural language, it is not easy at all to explicate the underlying rules of
grammar that determine what is and what is not a meaningful sentence. We somehow learn and
apply the rules of language implicitly, and a similar story applies to the use of common sense
notions such as beliefs, goals, etc. Children of early age, for example, are not able to apply these
concepts adequately, which explains why it is sometimes hard to make sense of their explanations.
The concepts of common sense that we are interested in are often labelled folk psychology
5
We explain what must have gone on in the mind of an agent by means of ascribing it beliefs and
4
Dennett continues to make a claim as to what it is to be a what he calls true believer: it is to be an
intentional system, a system whose behavior is reliably and voluminously predictable via the intentional strategy.
5
It is tempting to use the label rational psychology instead, as [26] does, to emphasize the rationality assumed
within our common sense view of human psychology. However, this label may also easily give rise to confusion as
it may be used to refer to a specic kind of scientic psychology. For example, [24] uses rational psychology to
1.3. WHAT IS COMMON SENSE? 11
goals.
6
Folk psychology assumes that agents are rational in the sense that agents perform actions
to further their goals, taking into account their beliefs about the current state of the world. It is
for this reason that we have used the label rational agent to refer to the computational entities
we want to engineer, and we turn now to exploring this notion in more detail.
1.3.1 What is Rationality?
The use of intentional notions such as beliefs and goals presupposes rationality in the agent that
is so described [23].
The beliefs of an agent, if they are to count as rational, should satisfy a number of conditions.
7
The beliefs that a rational agent maintains should be true. That is, the beliefs of an agent should
reect the actual state of the environment or correspond with the way the world actually is. Using
a bit of formal notation, using p to denote a proposition that may be either true or false in a state
and bel(p) to denote that an agent believes p, ideally it would be the case that whenever bel(p)
then also p.
8
As has been argued by several philosophers, most of our common sense beliefs must
be true (see e.g. [23, 26]), which is not to say that agents may not maintain exotic beliefs that
have little justication such as the belief that pyramids cannot have been built without the help
of extraterrestrial life. The point is rather that most of the beliefs that are common to us all must
be true in order for our explanations of behavior to make sense at all.
There is also sort of a rational pressure on an agent to maintain beliefs that are as complete as
possible. The beliefs of an agent may be said to be complete if an agent has a complete picture
of the state it is in. In general, such a requirement is much too strong, however. We do not expect
an agent to have beliefs with respect to every aspect of its environment, including beliefs about, for
example, a list of all items that are in a fridge. The sense of completeness that is meant here refers
to all relevant beliefs that an agent reasonably can have. This is somewhat vague and depends
heavily on context, but an agent that acts without taking relevant aspects of its environment to
which it has perceptual access into account may be said to be irrational.For example, intuitively,
it would be strange to see an agent that has agreed to meet a person at a certain location go to
this location while seeing the person he is supposed to meet go somewhere else.
Motivational attitudes such as desires and goals are also subject to rational pressures.
9
How-
ever, it also seems obvious that desires or goals are not subject to the same rational pressures as
beliefs. Desires nor goals need to be true or complete in the sense that beliefs should be. Agents
are to a large extent free (autonomous?) to adopt whatever desires or goals they see t.Of course,
there may be pressures to adopt certain goals but for completely dierent reasons. These reasons
include, among others, previous agreements with other agents, the need to comply with certain
norms, and the social organization that an agent is part of. The freedom that an agent is granted
with respect to adopting desires seems almost limitless. An agent may desire to be rich while
simultaneously desiring to be live a solitory live as Robinson Crusoe (which would require little
or no money at all). Although desires may be quite out of touch with reality or even inconsistent,
in contrast the goals that an agent adopts must conform with certain feasibility conditions. These
refer to the study of all possible minds., although, suprisingly, the notion of rationality does not play a role in
the view exposed.
6
Agents may have all kinds of mental attitudes, such as expecting, fearing, etc. However, in the remainder we
will mainly focus on the notions of belief and goal, which seem at the core of our folk psychology and sucient to
develop a theory of rational agents.
7
Rationality associated with beliefs has also been called theoretical rationality [58].
8
It is usual in the logic of knowledge, or epistemic logic, to say in this case that an agent knows that p. Using
know(p) to denote that an agent knows p, knowledge thus is dened by: know(p) i bel(p) and p (cf. [25, 51]).
Such a denition, most would agree, only approximates our common sense notion of knowledge. It lacks, for
example, any notion that an agent should be able to provide adequate justication for the beliefs it maintains.The
latter has been recognized as an important dening criteria for knowledge since Plato, who dened knowledge as
true justied belief. Although this denition for all practical purposes would probably be good enough, there are
still some unresolved problems with this denition.
9
Rationality associated with motivational attitudes is called practical rationality, and, encompasses all aspects
of rationality other than theoretical rationality according to Pollock [58], including rationality of emotions, for
example.
12 CHAPTER 1. RATIONAL AGENTS
conditions include that goals should be consistent in the sense that one goal of agent must not
exclude the accomplishment of another goal. For example, it is not rational for an agent to have a
goal to go to the movies and to nish reading a book tonight if accomplishing both would require
more time than is available. A second condition that goals need to satisfy is that the means should
be available to achieve the goals of the agent. An agent would not be rational when it adopts a
goal to go to the moon, for example.
As argued in [55], goals (and intentions for that matter) should be related in an appropriate
way to aspects of the world that the agent has (at least potentially) some control over. For
example, an agent may wish or desire for a sunny day, but an agent cannot rationally adopt a goal
without the capabilities to control the weather.
Note that this requirement may, from the perspective of the agent, be relativized to the beliefs
that the agent holds. If an agent believes he is able to control the weather as he pleases, that
agent may be said to rationally adopt a goal to change the weather as he sees t. It is kind of hard
to judge such cases, though, since the agent may be accussed of holding irrational beliefs that do
not have any ground in observable facts (statistically, for example, there most likely will not be
any correlation between eorts undertaken by the agent and the weather situation).
1.3.2 First-Order and Higher-Order Intentional Systems
Agents as intentional systems have beliefs and goals to represent their environment and what they
want the environment to be like. An intentional system that only has beliefs and goals about
its environment but no beliefs and goals about beliefs and goals is called a rst-order intentional
system [23]. As observers, looking at such agents from an external perspective, we can represent
the mental content of an agent by sentences that have the logical form:
bel(p) : the agent believes that p (1.1)
goal(p) : the agent has a goal (or wants) that p (1.2)
where p is instantiated with a statement about the environment of the agent. For example, an
agent may believe that there are ice cubes in the fridge and may want some of these ice cubes to
be in his drink. Note that an agent that would describe his own mental state would use sentences
of a similar logical form to do so.
A second-order intentional system can have beliefs and goals about beliefs and goals of itself
and other agents. Here we have to slightly extend our formal notation to include agent names that
refer to the agent that has the beliefs and goals. Sentences to describe the second-order beliefs
and goals of an agent a about the beliefs and goals of an agent b have the logical form:
bel(a, bel(b, p)) : a believes that b believes that p (1.3)
bel(a, goal(b, p)) : a believes that b wants that p (1.4)
goal(a, bel(b, p)) : a wants that b believes that p (1.5)
goal(a, goal(b, p)) : a wants that b wants that p (1.6)
The rst two sentences attribute a belief to agent a about another agent bs beliefs and goals.
The third and fourth sentence express that agent a wants agent b to believe respectively want
that p. The agent names a and b may be identical, and we may have a = b. In that case, the
sentence bel(a, bel(a, p)) attributes to a the belief that the agent itself believes p. Such agents
may be said to introspect, as they have beliefs about their own mental state [48]. Similarly, the
sentence goal(a, bel(a, p)) means that agent a wants to believe (know?) that p. In the latter
case, interestingly, there seems to be a rational pressure to want to know something instead of
just wanting to believe something. I may want to believe that I win the lottery but I would be
rational to act on such a belief only if I know it is true that I will win the lottery. An agent that
simply wants to believe something may engage in wishful thinking. In order to avoid that an agent
fools itself it should want to know what it believes and in order to ensure this a check is needed
that what is believed also is the case.
1.4. NOTES 13
It is clear that one can go on and similarly introduce third-order, fourth-order, etc. intentional
states. For example, agent a may want that agent b believes that agent a wants agent b to
assist him in moving his furniture. This sentence expresses a third-order attitude. Such attitudes
seem relevant, for instance, for establishing cooperation. It also has been argued that third-order
attitudes are required to be able to understand communication between human agents [29, 30].
In the current draft of this book, Goal agents are rst-order intentional system. A rst-order
intentional system has beliefs and goals but no beliefs and goals about beliefs and goals. Using the
formal notation for believe introduced above, this means that bel(p) may be true of a Goal agent
but the operator bel cannot be nested. For example, bel(bel(p)) where denotes negation is
never true of a Goal agent, and such an agent thus is not aware of its own lack of knowledge (in
other words, it does not have any introspective capabilities). This also means that a Goal agent
cannot have beliefs and goals about the beliefs and goals of other agents.
It has been argued by philosophers that the ability to maintain higher-order beliefs and goals
is a mark of intelligence [23],and a prerequisite for being autonomous. The intuition is that an
agent that does not want to want to clean the house cannot be said to be free in its choice of
action, or autonomous. Interestingly, developmental psychologists have contributed a great deal to
demonstrating the importance of second-order intentionality, or the ability to metarepresent [26].
For example, in a well-known experiment called the false belief task children of four have been
shown to be able to represent false beliefs whereas children of age three are not.
10
Finally, it has
also been argued that without addressing the problem of common sense, including in particular the
human ability to metarepresent, or to see one another as minds rather than as bodies, Articial
Intelligence will not be able to come to grips with the notion of intelligence [71]. Intelligence
requires the ability to communicate and cooperate with other agents, which also seems to require
higher-order intentionality.
11
Thus, in a sense, the rational agents discussed here may be compared with three-year olds
that lack some of the mental representation abilities of four-year olds. Some work on extending
Goal agents with the ability to represent the mental states of other agents has been reported in
[39]. One reason for limiting the orders of nesting is related to the computational complexity that
results from allowing arbitrary nesting [25]. Another reason for being cautious about introducing
such nestings concerns the fact that human adults are reported to also have great diculty with
higher-order intentionality, a fact that is, for example, exploited by comedians and in sitcoms.
1.4 Notes
The idea of using the intentional stance to develop rational agents has been proposed in various
papers by Shoham. Shohams view is that agents are formal versions of human agents, for
example, [65].
12
He means that articial agents have formal versions of knowledge and belief,
abilities and choices, and possibly a few other mentalistic-sounding qualities.
Central in the early work on agent-oriented programming by [65] has been speech act theory.
According to [65], AOP too can be viewed as a rigorous implementation of a fragment of direct-
speech-act theory.This theory has initially also played a large role in the design of a generic
communication language for rational agents, see chapter 7 for a more detailed discussion.
10
Children of both ages were asked to indicate where a puppet would look for chocolate in a cabinet with several
drawers after having witnessed the puppet putting the chocolate in a drawer, seeing the puppet leave the room,
and the chocolate being placed in another drawer in the absence of the puppet. Children of age three consistently
predict that upon return the puppet will look in the drawer where the chocolate actually is and has been put after
the puppet left, whereas four-year olds predict the puppet will look in the drawer where it originally placed the
chocolate.
11
[48] writes that [i]n order to program a computer to obtain information and co-operation from people and
other machines, we will have to make it ascribe knowledge, belief, and wants to other machines and people.
12
The title of this book chapter, Implementing the Intentional Stance, does not refer to what we have been after:
a reorientation of the intentional stance to a design stance for developing rational agents. It should not be taken
to mean that we are after an implementation of an agent that is itself able to adopt the intentional stance, which,
as discussed in the main text would at least require higher-order intentionality [26].
14 CHAPTER 1. RATIONAL AGENTS
Our view on designing and programming agents as one particular form of implementing the
intentional stance derives from [65]. The intentional stance has been rst discussed by Daniel
Dennett in [23]. The usefulness of ascribing mental attitudes to machines, however, was already
discussed by McCarthy.
The concept of autonomy, although it has been used to dierentiate agents from other software
entities, is one of the notions in the literature about which there is little consensus. [73] dene
autonomy as the ability of an agent to control its actions and internal state. In [13] autonomy is
dened in terms of the ability and permission to perform actions. The basic intuition is that the
more freedom the agent has in choosing its actions, the more autonomous it is.
1.5 Exercises
1.5.1
An agent in the weak sense is an entity that is situated, reactive, proactive and social. The
text of this chapter claims that these characteristics do not provide support for an agent
designer to develop an agent. Do you agree? Discuss two of these characteristics. and
explain and motivate why you think they are or are not helpful in the agent design process.
1.5.2
Discuss whether the notion of autonomy can have a functional role in the design of agents.
If you think autonomy does have a role to play, explain the role the notion can have in
design and motivate this by providing two reasons that support your point of view. If you
think autonomy does not have a functional role, provide two arguments why this is not the
case.
1.5.3
Discuss whether a rational agent may be expected to satisfy the following axioms:
1. Axiom of positive introspection: if bel(p), then bel(bel(p)).
2. Axiom of negative introspection: if bel(p), then bel(bel(p)).
1.5.4
It has been stated that higher-order beliefs about opponents in games are crucial for good
game play, i.e. winning (see e.g. [26]).What number of nestings do you think are required
for each of the following games?
1. Hide-and-seek
2. Memory
3. Go Fish (kwartetten in Dutch)
4. Chess
1.5.5
Do you think the ability to have second- or higher-order beliefs are a prerequisite for being
able to deceive another agent? Motivate your answer by means of an example.
1.5.6
1.5. EXERCISES 15
The cognitive psychologists Tversky and Kahneman asked participants to read the following
story:
Linda is 31 years old, single, outspoken, and very bright. She majored in philos-
ophy. As a student, she was deeply concerned with issues of discrimination and
social justice, and also participated in anti-nuclear demonstrations.
They were then asked to rank-order a number of possible categories in order of likelihood
that Linda belonged to each. The following three categories were included:
bank teller
feminist
feminist bank teller
Before reading on, you might want to order the categories yourself rst.
Most participants ranked feminist bank teller as more probable than either bank teller or
feminist. This, however, is incorrect, because all feminists bank tellers belong to the larger
categories of feminists and bank tellers! This is one of the examples Tversky and Kahneman
used to demonstrate that humans ask whether people are rational. if so, why, or, why not?
16 CHAPTER 1. RATIONAL AGENTS
Chapter 2
Automated Reasoning and
Knowledge Representation
Rational agents need to represent and reason with their knowledge, beliefs and goals, the actions
that they can perform, and the reasons for performing an action. In this chapter, we discuss the
knowledge representation capabilities that we will need for engineering rational agents that are able
to represent and reason with their knowledge, beliefs and goals. In particular, we will discuss the
use of rst-order languages as knowledge representation languages.
1
Throughout, we presuppose
familiarity with propositional logic but we will present a basic but rigorous introduction to rst-
order logic. In chapter 4 we discuss the actions that an agent can perform and in chapter 3 and 5
we look at the reasons for selecting actions.
2.1 Knowledge Representation
Agents need to be able to represent their knowledge, beliefs and goals. This is one reason for using
a knowledge representation language but there are other capabilities a knowledge representation
language should support to be useful for agents. As these capabilities go beyond the basic func-
tion of using a language to represent the agents environment we will also talk about knowledge
representation technologies.
[22] discuss various roles of knowledge representation technologies, two of which we highlight
here as they are also particularly relevant for engineering rational agents:
2
1. Knowledge technologies provide a fragmentary theory of intelligent reasoning, i.e. a knowl-
edge technology denes a notion of inference that enables drawing conclusions from other
available information represented by means of the same technology, and
2. Knowledge technologies provide a medium for pragmatically ecient computation, i.e. a
knowledge technology provides tools and techniques to compute with (use) the representa-
tions supported by the technology. A key aspect associated with such tools is the computa-
tional eciency to ensure the computation itself remains tractable.
It will be clear that the roles identied here are important for our purpose of engineering
rational agents. Because our aim is to integrate a knowledge technology into such agents, however,
it is also useful to look at knowledge technologies from an agent-oriented point of view. That is,
1
We refer to the language used by an agent as a knowledge representation language because of tradition, but it
should be noted that it is also used to represent the beliefs and the goals of a rational agent.
2
Other roles of knowledge representation technologies discussed in [22] include that a knowledge representation
technology introduces particular ontological commitments and may possibly also be used as a medium of human
expression. As we will mainly be concerned with variants of rst-order logic as a knowledge representation language
here these are less important in this context. It is clear that rst-order languages introduce minimal ontological
commitments [59, 62] and are not particularly suitable as a medium of human expression.
17
18 CHAPTER 2. AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION
we need to look at a knowledge representation technology as an enabling technology for agents
that require tools and techniques to represent, reason, and modify their beliefs about the current
state of the environment. In other words, the agent-oriented perspective looks at a knowledge
representation technology as a tool that provides an agent with a set of capabilities to perform
representational and reasoning functions.
The basic capabilities that we need such a knowledge representation technology to provide are
the capability to (i) represent states of aairs (which is fundamental), (ii) the capability to store
these representations in a storage facility, (iii) the capability to reason with them and (iv) the
capability to change the representations present in a storage. These capabilities are similar to
some of the functions associated with a knowledge technology as discussed in [22].
3
The rst capability to represent states of aairs is realized by means of a language. Taking
an agent-oriented point of view does not introduce very specic requirements dierent from those
more generally considered relevant in the area of knowledge representation. Most importantly
a language should dene what a formula is, that is, make clear how a language can be used to
represent an agents environment. We also will require that it contains a special formula which
denotes the false proposition.
4
In other words, we assume that a language denes the grammar
or syntax of well-formed formulas. We write / to denote that is a formula of language
/; in particular, we have assumed that /. Intuitively, we think of a formula as a sentence
that expresses that a state of aairs is the case (or not) similar to declarative sentences in natural
language. We think of a formula as having a truth value and of a formula being true or false.
5
Other important features that a knowledge representation language should have include the
following:
1. Declarative: It should be possible to use the language to make statements about the domain
(instead of, e.g. exclamations such as Look!). A declarative language ensures that a knowl-
edge base can store facts and rules about the domain that can be true or false. Stating that
a language is declarative is essentially another way of saying that it can be used to represent
environments.
2. Compositional: The meaning of a (set of) expression(s) of the language should be a function
of the meaning of its parts. Compositionality ensures that local changes can be made to a
knowledge base replacing parts of it by other parts without the need to change the knowledge
base globally.
3. Expressive: The language should be expressive enough to provide for an adequate trans-
lation of the relevant knowledge (but not too expressive). Expressiveness ensures that the
knowledge representation language is able to represent the domain under consideration. The
language should t the representational needs in the sense that it should be expressive
enough to represent relevant aspects of an agents environment, but not too expressive since
that would introduce redundancy and most likely additional computational complexity.
6
4. Context-independent: The language should be context-independent in the sense that sen-
tences in the language do not depend for their interpretation on additional information not
represented by the sentence itself (e.g. He gave her yesterday some owers; it is not clear
3
One notable dierence is that a capability to update knowledge or beliefs is not part of the denition provided in
[22]. However, since agents act upon their environment, from an agent-oriented point of view a concept of and tools
for updating a knowledge base to maintain a correspondence with the environment being represented is essential,
which provides our motivation to include them in our denition.
4
An alternative for requiring that is part of the language would be to require that negation is available
(assuming that this is sucient to dene inconsistency), or more generally that the knowledge representation
technology provides the means to dene a notion of consistency. Here we have chosen for the simplest and most
direct approach towards dening (in)consistency.
5
In principle there is no reason why other possible truth values should not be allowed, such as e.g. a value
undened, but here we do not discuss the special issues that would arise from such a choice.
6
A language that is more expressive than another also requires additional inference power to derive answers from
the knowledge represented in that language. In general, adding inference power to a knowledge base is expensive
and should be avoided if it is not required.
2.1. KNOWLEDGE REPRESENTATION 19
to which he, her, and yesterday refer and which owers the sentence is about). Context-
independence ensures that a piece of information can be recovered without the need to store
additional information about the context.
5. Unambiguous: The meaning of the notation introduced by the language must be identical for
everyone. Unambiguity ensures that the knowledge stored in a knowledge base is interpreted
the same by everyone and that everyone will draw the same conclusions from it.
The second capability to store representations is to a large extent an implementation issue that
we will ignore here for the moment.
7
All we need here to formalise the storage capability is the
notion of a set of formulas. Access to such a storage is provided by the element of relation. We
thus abstract from most implementation details typically associated with this capability. As we
will see in the next chapter, the knowledge, belief and goal base may each be represented as a set
of formulas, or, equivalently, as a subset of a language /.
The third capability to reason is realized by requiring that a knowledge technology provides
a consequence relation (also called entailment). A consequence relation denes when a formula
follows from (is a consequence of) a set of formulas. We use [= to denote consequence relations
and write T [= for follows from a set of formulas T. For example, a formula follows from an
agents belief base whenever we have [= . A consequence relation is the formal counterpart
of the reasoning capability of an agent since it may be used to provide an agent to derive and
reason with its knowledge, beliefs, and goals. A knowledge representation technology should allow
an agent to infer answers to a broad range of queries, minimizing the degree of incompleteness
in its inference process (i.e. questions the agent would not be able to answer, assuming it has
the knowledge to do so). This requirement on the inference capability provided by a knowledge
representation technology ensures that an agent is able to answer as many questions as possible
about the agents environment. It should be noted, however, that this requirement always involves
a trade-o between inference power and eciency: in general, the more inference power is present
the less ecient the agent will be.
The fourth and nal capability we need is the capability to update an agents beliefs.
8
In
particular we will need to be able to dene how an agents beliefs change when it performs an
action. This is the topic of chapter 4 and will be discussed in more detail there. Generally speaking,
however, in order to update an agents beliefs an update operator is assumed that updates a
set of formulas T with a formula . That is, T denotes the new set of formulas obtained after
updating T with . See chapter 4 for common and concrete examples of such operators.
There are some other properties and capabilities of knowledge representation technologies that
are important. We mention two here. Ideally, a knowledge representation technology provides
a scalable technology. This means that the performance of an agent that uses the knowledge
representation technology should degrade gracefully as the mental state maintained by the agent
becomes large. A scalable knowledge representation technology ensures that an agent will be able
to derive conclusions eciently even when the agent needs to deal with large sets of knowledge,
beliefs and goals. Although it may be expected that performance will degrade when an agent
stores more information, it should not be the case that the agent displays worst case performance
when a particular size limit is reached. Finally, ideally an agent would be able to explain how
it did derive an answer instead of just giving the answer. The capability to explain ensures that
a user that interacts with an agent can trace how and why the agent did provide a particular
answer. The explanation capability is not required for an agent to operate, however, and may be
said to be a nice to have feature rather than a requirement.
Summarizing this discussion, a knowledge technology may be dened as a language with a
well-dened semantics that comes with an inference relation and procedures to update information
stored in a knowledge base. More formally, a knowledge representation technology should provide
7
Storage and access to stored formulas obviously is a very important issue in any implementation of an agent
as these aspects may have a great impact on how ecient the agent executes.
8
In the setup we use here, we do not need a special capability to update the goal base when an agent comes to
believe it has achieved a goal; in that case we simply remove the goal from the goal base, which is a set-theoretic
operation; see also the chapter 4.
20 CHAPTER 2. AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION
an agent with certain capabilities which can be dened as the triple /, [=, where / is a language
to represent states of aairs in the agents environment, [= is a consequence relation that denes
when a formula follows from a set of formulas, and denes how a set of formulas is updated
with a given formula.
Some typical examples of knowledge representation technologies that t the denition are log-
ical languages such as rst-order logic and description logics such as the Ontology Web Language
(OWL; [1]), Frame languages [52], Prolog [68], Answer Set Programming [3], Constraint Program-
ming [43], relational databases (SQL, Datalog; [14]), and others, such as Bayesian Network also
may t though the notion of an update in Bayesian Networks is rather limited and it is not com-
mon to view a Bayesian network as a database consisting of a set of sentences. In the remainder
we will discuss various variants of rst-order logic.
9
The language of classical logic that is most widely used in the theory of knowledge represen-
tation is the language of rst-order logic [45, 8]. In the remainder of this chapter, we will rst
formally introduce rst-order languages and then continue to discuss how these languages can
be used eectively by a machine to reason. In order to be able to compute with logic, various
restrictions and modications will be discussed such as the well-known closed-word assumption
and domain closure.
2.2 First-Order Logic
Arguably, one of the most useful logics for knowledge representation is rst-order logic. First-
order languages are both simple and expressive. Such languages are relatively simple since they
consist of a limited number of language elements and a relatively straightforward combination
of these elements. That is, the syntax of rst-order languages is easy to dene and sentences in
these languages have a natural reading [8]. Even though syntactically these languages are simple,
they are also very expressive. Most things of interest can be expressed in a rst-order language,
although rst-order logic also has its limitations. Finally, rst-order logic has a number of nice
properties such as that there is a complete inference procedure for the logic. These are very
important reasons that justify the choice of using rst-order logic as a knowledge representation
language.
A formal logic consists of a formal language and reasoning methods that enable the process
of inferring conclusions from a set of initial premisses. In section 2.2.1 the syntax of rst-order
languages is presented. The syntax of the language denes which expressions are well-dened or
grammatical, that is, it denes which expressions are part of the language and which are not.
In section 2.2.2 the semantics of rst-order languages is presented. The semantics denes the
meaning of well-dened expressions of the language. In section 2.2.3 a semantic reasoning method
called model checking is presented. In section 2.2.4 a syntactic reasoning method called resolution
is presented. Finally, in section 2.2.5 some computational issues related to rst-order logic are
discussed.
2.2.1 First-Order Languages: Syntax
A logical language just as a natural language consists of expressions made up of a set of given
symbols. The set of symbols used is also called the alphabet of the language. The symbols of an
alphabet for a rst-order languages can be distinguished according to their dierent functions.
There are symbols to denote objects in an environment, such as blocks in a Blocks World envi-
ronment or elevators and oors in an elevator environment. These symbols are called constants.
In addition, function symbols are used to more indirectly refer to objects, such as a function
lastFloorServed(elevator1) that returns the last oor that has been served by elevator1. A set of
symbols called predicate symbols is used to denote properties of objects, such as that a block is blue
or that the doors of an elevator are open, and relations between objects, such as that one block
9
Integrating other knowledge representation technologies into agent programming remains a research challenge.
See also [21].
2.2. FIRST-ORDER LOGIC 21
is on top of another. Both function and predicate symbols take a nite number of arguments,
which is called the arity of the symbol.
10
Constants, function symbols, and predicate symbols
are called non-logical symbols. Dierent rst-order languages may be obtained by dierent sets
of non-logical symbols. The logical symbols that are part of a rst-order alphabet are xed and
include the usual connectives of propositional logic such as to denote the false proposition, to
denote conjunction, to denote disjunction, to denote negation, and to denote implication,
and the universal quantier and existential quantier which are not present in propositional
languages. Quantiers allow to express statements that, for example, all blocks are on the table.
They are used to bind variables, which are also part of any rst-order alphabet. Expressions
that are constructed using only constants, variables, and function symbols are called terms. In
addition, it is common to introduce the equation symbol = to express that the objects referred to
by two terms is actually one and the same object. Finally, brackets are needed to uniquely x the
compositional structure of a formula.
Denition 2.2.1 (First-Order Alphabet)
An alphabet consists of the following sets of symbols:
A set ( of constants, with typical elements c, d,
A set 1 of variables, with typical elements x, y,
A set T of function symbols, with typical elements f, g,
A set T of predicate symbols, with typical elements p, q,
The propositional connectives , , , , , ,
The universal quantier ,
The existential quantier ,
The equation symbol =, and
The brackets ( and ).
The syntax of a rst-order language denes the expressions that are part of the language. We
provide a Backus-Nauer-Form (BNF) denition of the syntax of rst-order languages. We make
use of the conventions for refering to constants, function symbols, etc. introduced in Denition
2.2.1. Two types of expressions are distinguished in the denition of the syntax: terms, typically
denoted by t, and formulas, typically denoted by .
Denition 2.2.2 (Syntax of /)
Let an alphabet as in Denition 2.2.1 be xed. Then the set of terms T and the set of formulas
/ are dened by:
t T ::= c [ x [ f(t, . . . , t)
/ ::= t = t [ p(t, . . . , t) [ [ ( ) [ ( ) [ [ ( ) [ ( ) [ x [ x
The set / is also called the (rst-order) language. It is usual to identify various specic subsets
of the language. For example, formulas of the form p(t
1
, . . . , t
n
) are called atomic formulas, or
simply atoms. A literal is an atom or an atom preceded by a negation sign. Two literals of the
form P and P are said to be complementary to each other. We will also write Qx : with Qx a
quantier whenever this enhances readability; this will in particular be the case when a quantier
is applied to an atom.
Quantiers and variables distinguish rst-order logic from propositional logic and it is impor-
tant to understand the basic syntactic notions related to quantiers and variables. The scope of
10
Predicate symbols that do not take any arguments, i.e. have an arity of 0, are called propositions. Function
symbols that have arity 0 are constants.
22 CHAPTER 2. AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION
an occurrence of a quantier Qx in a formula is the subformula Qx

to which the quantier

is applied, where Q is either or . The variable that occurs directly after a quantier is called
the quantier variable. Occurrences of a variables x other than quantier variables in a formula
are said to be bound if they occur within the scope of a quantier Qx, that is, if they belong to
a subformula of the form Qx

; otherwise they are said to be free. If at least one occurrence of x

is free in a formula , then we say that x is a free variable of . Note that a formula can contain
both free and bound occurences of the same variable, as in p(x) x : q(x). It is always possible
to avoid formulas that have a variable that has both free and bound occurrences by renaming the
bound occurrences. For example, by renaming the bound occurrence x to y in p(x) x : q(x) we
obtain p(x) y : q(y). Of course, when renaming bound variables the corresponding quantier
variable also needs to be renamed. Both formulas have the same meaning: x has property p,
and there exists an object that has property q. Two formulas that only dier in the names of
bound variables are called variants of each other. A closed formula, or a sentence, is a formula
without free variables; otherwise it is open. A closed formula without quantiers is also said to
be ground. Terms in the set T are also said to be ground if they do not contain any variables.
Finally, the universal closure of a formula is the sentence x
1
. . . x
n
, where x
1
, . . . , x
n
are the
free variables of .
We provide a few examples here to illustrate the expressive power of rst-order logic and
provide an informal translation of the formulas.
x(block(x) y : on(x, y))
there is no block that is on top of all other blocks.
x(block(x) (y(block(y) on(y, x)) y(block(y) on(y, x))))
for an arbitrary block, it is the case that if there is no block on top of it, then all blocks are
not on top of that block.
In proof theory and computational reasoning it is very useful to be able to substitute a term
for a variable. In a proof theory we can only use syntactic concepts such as substitution to derive
one formula from a number of other formulas. To dene substitution in rst-order formulas, we
introduce substitution operators, denoted by [t/x], to substitute terms for variables in terms as
well as formulas. We rst dene substitution of terms for variables in terms and then dene
substitution of terms for (free) variables in formulas.
Denition 2.2.3 (Substitution in terms)
Substituting a term t for a variable x in a term s, denoted by s[t/x], is inductively dened by:
y[t/x] =

y if y ,= x
t if y = x
f(t
1
, . . . , t
n
)[t/x] = f(t
1
[t/x], . . . , t
n
[t/x])
Denition 2.2.4 (Substitution in formulas)
Substituting a term t for a variable x in a formula , denoted by [t/x], is inductively dened by:
[t/x] = ,
p(t
1
, . . . , t
n
)[t/x] = p(t
1
[t/x], . . . , t
n
[t/x]),
(t
1
= t
2
)[t/x] = t
1
[t/x] = t
2
[t/x],
()[t/x] = ([t/x]),
( )[t/x] = [t/x] [t/x],
( )[t/x] = [t/x] [t/x],
( )[t/x] = [t/x] [t/x],
( )[t/x] = [t/x] [t/x],
(y())[t/x] =

y([t/x]) if y ,= x
y() if y = x
2.2. FIRST-ORDER LOGIC 23
(y())[t/x] =

y([t/x]) if y ,= x
y() if y = x
In the denition of [t/x] it is ruled out that t is substituted for a bound variable x to avoid
changing the meaning of . However, the denition still allows for undesired cases of substitution
where variables in t are bound by quantiers in . As an example, consider:
All of the robots that are just as tall as him are faster than him
which we may translate into
x(robot(x) eqtall(x, y)) faster(x, y))
where robot(x) stands for x is a robot, eqtall(x, y) stands for x is just as tall as y and faster(x, y)
stands for x is faster than y. Substitution of x for y is allowed by Denition 2.2.4, but gives:
x((robot(x) eqtall(x, x)) faster(x, x)) which would translate back into: All robots are faster
than themselves since everyone is just as tall as himself. To avoid such undesirable consequences,
we introduce the notion of a term being free for a variable x.
Denition 2.2.5 (Free for x)
A term t is free for x in if:
1. is atomic,
2. is of the form

and t is free for

,
3. is of the form (
1

2
),(
1

2
), (
1

2
), or (
1

2
) and t is free for
1
and
2
,
4. is of the form y

or y

with x ,= y, y does not occur in t and t is free for

.
Using the denition, we can prove that the variables of t are not bound by a quantier in
[t/x] if t is free for x in , and vice versa if t is not free for x. For example, f(y) is free for x in
z : p(x, z). Substitution of f(y) for x results in z : p(f(y), z) and the variable y is not bound
by the quantier z. The term f(y) is not free for x in y : p(x, y), however. Substitution of f(y)
for x would result in y : p(f(y), y) and the quantier y would bind the variable y.
Since we can always rename bound variables of quantiers in a formula without changing
the meaning of because variables are only placeholders, we can always ensure that t is free for
x in some variant of where bound variables have been renamed.
2.2.2 First-Order Languages: Semantics
An important reason for introducing (logical) languages is that they can be used to represent
the state of an environment. Other functions of language are discussed in later chapters (see
also the notes of this chapter). In order to represent the environment, there must be a natural
correspondence between the language and the environment. For example, for a sentence Snow is
white to represent the environment adequately, the environment must be such that snow is white.
That is, Snow is white is true if and only if snow is white. Similarly, The robot is holding the
red block is true if and only if, at this very moment, the robot is holding the red block. Although
these examples may seem quite obvious, it is not always so clear cut whether a statement about
the environment is true. The basic idea introduced here is to dene the meaning of sentences by
dening the truth conditions of sentences.
For our purposes, it is useful to be more precise about the conditions that determine whether
a sentence is true or not. In order to do so, the informal talk about environments needs to be
replaced by a more precise, formal model of environments. We need a rich but also very generic
model of environments. The model needs to be rich enough to be able to distinguish enough
dierent situations in an environment and it must be generic enough to be applicable to arbitrary
environments. We will introduce an abstract mathematical model that can be used to dene truth.
24 CHAPTER 2. AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION
There are several reasons for introducing such models. First, it will allow us to provide proofs later
on. Second, it allows us to precisely characterize the notion of truth. The latter is important when
we want to compute with rst-order logic. For this reason logic has also been labeled mathematical
logic.
The basic idea to dene a rst-order model involves the fact that rst-order languages contain
terms that refer to objects. To be able to interpret terms as objects we need a set of objects
which we will call a domain. A domain can be thought of as the set of all (relevant) objects in
the environment. The second idea involves the fact that rst-order languages allow to impose a
structure on the domain. It allows us to express that certain objects have a particular property
and others do not, and to express that one object is related to another in a particular way.
Often corresponding mathematical structures are introduced to model this structure [19]. Such
structures then can be used to interpret the vocabulary of the language. However, here we present
a slightly more abstract denition and directly interpret the language vocabulary by introducing
an interpretation.
Denition 2.2.6 (First-Order Model)
A model is a pair D, I where:
D is a non-empty set called the domain, and
I is an interpretation that maps:
constants c to D, i.e. I(c) D.
function symbols f with arity n to a mapping D
n
D, i.e. I(f)(d
1
, . . . , d
n
) D.
predicates p with arity n to a mapping D
n
0, 1, i.e. I(p)(d
1
, . . . , d
n
) 0, 1.
Predicates refer to properties of objects and relations between objects. Properties and relations
in an interpretation are identied with the objects or tuples of objects in the domain that have
the property or relation. This type of interpretation is called an extensional interpretation as it
identies properties with the extension (set of objects) that satisfy the property. The meaning of
terms is also dened extensionally and the meaning of a term is identied with the object the term
refers to. This also implies that the meaning of two terms such as for example H
2
O and water are
identied in an extensional interpretation. In contrast, an intensional interpretation would not
identify the meaning of terms or predicates whenever they have the same extension.
In gure 2.1, a (partial) rst-order model is graphically represented. The objects in the domain
are represented by dots in the domain cloud. A set of these objects represents a particular
property denoted by a predicate p. Also, a function has been represented as a mapping from
objects to objects.
11
The formal interpretation of functions dened in 2.2.6 are also indicated.
A domain provides the objects that can be referred to whereas an interpretation xes the
meaning of the vocabulary of the language. This provides the meaning for all symbols in a rst-
order language since the meaning of logical symbols is xed except for the variables. Variables do
not have a xed meaning but function as place-holders similar to pronouns in natural language.
In order to evaluate a formula with free variables we need to assign a meaning to variables as well.
We do so by introducing a valuation, which simply is a mapping from variables to the domain.
As the evaluation of the meaning of formulas with quantiers requires changing the references
of a variable, we also introduce variants of a valuation. Note that a valuation always requires
the availability of a specic domain. As domains are part of a model, valuations should thus be
dened relative to a particular model.
Denition 2.2.7 (Valuation, Variant of a Valuation)
A valuation V for a model M = D, I is a mapping from the set of variables 1 to D.
11
Note that A function in rst-order logic is interpreted as a total function. The oval representing the function
f thus should include a mapping for each object in the domain. For purposes of clarity and readibility, we have
abstained from including all objects.
2.2. FIRST-ORDER LOGIC 25
Figure 2.1: First-Order Model
A variant of a valuation V with respect to variable x is a valuation V

such that V

agrees
with V on all variables except possibly for x; that is, V

(y) = V (y) for all y ,= x, and possibly

V

(x) ,= V (x). If V

(x) = d we also write V [d/x] to denote V

and explicitly indicate that

the value of x has been set to d.
The ingredients for dening the meaning of arbitrary rst-order formulas have now been in-
troduced. The denition of the meaning is inductively dened on the structure of both terms and
formulas as dened in Denition 2.2.2. We rst dene the meaning of terms by extending the
interpretation I of a model to terms. We then dene the truth conditions of arbitrary formulas.
Denition 2.2.8 (Interpretation of terms)
Let M = D, I be a model and V be a valuation function. Then the interpretation I is extended
to a function I
V
that assigns meaning to arbitrary terms inductively as follows:
I
V
(x) = V (x)
I
V
(c) = I(c)
I
V
(f(t
1
, . . . , t
n
)) = I(f)(I
V
(t
1
), . . . , I
V
(t
n
))
Denition 2.2.9 (Truth Conditions)
Let M = D, I be a model and V be a valuation. The truth conditions of a formula are dened
26 CHAPTER 2. AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION
inductively by:
M, V ,[=
M, V [= p(t
1
, . . . , t
n
) i I
V
(t
1
), . . . , I
V
(t
n
) I(p)
M, V [= t = t

i I
V
(t) = I
V
(t

)
M, V [= i M, V ,[=
M, V [=

i M, V [= and M, V [=

M, V [=

i M, V [= or M, V [=

M, V [=

i M, V ,[= or M, V [=

M, V [=

i M, V [= i M, V [=

M, V [= x i M, V [d/x] [= for all d D

M, V [= x i M, V [d/x] [= for some d D
The truth conditions, or meaning, of a formula are dened relative to a model and valuation.
The meaning of sentences, i.e. closed formulas, does not depend on a valuation (see Exercise
2.4.2). It is useful to introduce the notion of truth in a model simpliciter, i.e. without reference
to a valuation.
Denition 2.2.10 (True in a model)
A formula is said to be true in model M, written as M [= , i for all valuations V we have
M, V [= .
If a sentence evaluates to true in a model M we also say that M satises . In line with the
extensional interpretation of predicates, the truth-value of an atom such as p(c) is determined by
verifying whether the object denoted by c is an element of the interpretation of the predicate p (a
set of objects from the domain); if so, p(c) is true, otherwise it is false. The notation M, V ,[=
used to provide the truth conditions for negation means that it is not the case that M, V [= . The
truth conditions for the propositional connectives are straightforward extensions of the classical
propositional semantics for these connectives.
An important property of the semantics for rst-order formulas is that it is compositional.
This means that the meaning of a formula is determined by the meaning of its constituent parts.
Compositionality is not only important for knowledge representation languages, but also for other
languages such as natural and programming languages. The compositionality of a semantics for a
programming language facilitates reasoning about programs in that language.
Denition 2.2.9 provides an interpretation for all and only those rst-order sentences and
formulas dened in 2.2.2. The notion of a syntactically correct sentence (or formula) provided in
denition 2.2.2 thus coincides with the notion of a meaningful rst-order sentence (or formula). It is
an interesting fact of formal languages such as rst-order languages that the meaningful expressions
can be identied by syntax only. This dierentiates such formal languages from natural language,
since to distinguish meaningful expressions in a natural language we not only need syntax but
semantics as well.
2.2.3 Reasoning with First-Order Logic: Model-Checking
Two distinct types of reasoning are supported by rst-order languages. The rst is directly based
on the semantic notions, and proceeds by inspecting classes of models of a formula or set of
formulas, a process also called model checking. The second is based on a purely syntactic notion
of manipulation, given a set of syntactic inference rules that support drawing conclusions from
a given set of formulas. Of course, there needs to be a correspondence in place between such
syntactic inference and semantic denitions of consequence.
Denition 2.2.11 (Satisability)
A formula is satisable if there is a model M such that M [= , and unsatisable otherwise.
Similarly, a set of formulas T is satisable if there is a model M such that M [= for all T.
2.2. FIRST-ORDER LOGIC 27
Note that the denition of satisability trivially gives M [= for all models. A formula or set
of formulas is called consistent if it is satisable, otherwise it is inconsistent.
Denition 2.2.12 (Tautology, Equivalence)
A formula is a tautology if it is true in all models, i.e. we have M [= for all models M.
Two formulas
1
and
2
are (logically) equivalent if
1

2
is a tautology.
An example of a tautology is the formula x(p(x) y p(y)), and an example of two equivalent
formulas is provided by the formulas x(p(x) q(x)) and x(p(x) q(x)). The meaning of a
formula has been dened by means of dening the truth conditions of that formula. Whenever
two formulas are logically equivalent they must have the same truth conditions. This implies that
two formulas that are logically equivalent have the same meaning. The fact that certain formulas
are logically equivalent has also certain syntactic implications that may be exploited to simplify
the writing of formulas. More specically, we may drop brackets in formulas that are logically
equivalent. For example, we may simply write
1

3
since ((
1

2
)
3
) and (
1
(
2

3
))
are equivalent. This fact means that brackets may be added either way to
1

2

3
without
changing the meaning of the formula. In other words, dropping the brackets does not introduce
ambiguity. Whenever this is the case, we will feel free to drop brackets. One should be careful,
however, not to drop brackets when they are needed to determine the meaning of a formula as in

1

2

3
; adding brackets in dierent ways does result in two formulas ((
1

2
)
3
) and
(
1
(
2

3
)) which do have a dierent meaning!
Denition 2.2.13 (Logical Consequence)
A formula is a logical consequence of (or follows from) a set of formulas T if all models of T are
also models of , and we write T [= in that case. That is, we dene:
T [= i for all models M : M [= T M [=
The symbol [= is also called the consequence relation or entailment.
We simply write [= whenever T = . [= means that is true in all models, which is
equivalent to saying that is a tautology. We also write T ,[= whenever it is not the case that
T [= . If T ,[= , then there is a model M such that M [= T but M ,[= . Such a model is called
a counterexample for T [= . Note that the notation [= is used in two dierent senses. In the rst
sense we write M [= , where the rst operand is an interpretation M, and [= is used to express
that formula is true in the interpretation M; we also say that M satises . In the second sense
we write T [= , where the rst operand is a set of formulas T, and [= is used to express that
formula is a logical consequence from T; we also say that T entails .
A basic technique for showing that a formula does not follow from a set of formulas T is to
construct a model in which T is true but is not. Such a model is called a counterexample.
Denition 2.2.14 (Counterexample)
A counterexample for T [= is a model M such that M [= T and M ,[= .
Models that are often used to construct a counterexample are models that have the natural
numbers N as domain, i.e. models of the form M = N, I. Such models often provide natural
counterexamples where an innite domain is needed or useful. Whenever a nite model is needed
to provide a counterexample it suces to restrict the domain a nite subset of N to construct
such a counterexample. In fact, either one of these models is sucient to nd a counterexample
if one exists as there always exists a model isomorphic to a countable model based on the natural
numbers.
12
An important property of the consequence relation is that verifying whether T [= holds is
the same as verifying that T is not satisable, i.e. has no models.
12
It is not always natural or easy to construct a countable model as a counterexample. For example, a natural
counterexample showing that xzy(x < y y < z) is not a tautology is based on the rational or real numbers
rather than the natural numbers. However, in many cases a counterexample based on N can often be constructed.
28 CHAPTER 2. AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION
Proposition 2.2.15 Let be a formula. We have:
T [= i T is unsatisable
Proof. We have:
T [= i
for all models M : M [= T M [= i
for all models M : M [= T M ,[= i
for all models M : M ,[= T or M ,[= i
for all models M : M ,[= T i
there is no model M : M [= T

Another important property of rst-order logic is that implication may be introduced by using
one the premisses as antecedent, or vice versa an implication may be removed by moving the
antecedent to the premises. This is called the deduction theorem.
Theorem 2.2.16 (Deduction Theorem)
Let T be a set of formulas, and and

be formulas. Then we have:

T, [=

i T [=

To present the nal result in this section about rst-order logic, it is useful to introduce the
notion of a theory. A theory consists of all the logical consequences of a given set of sentences.
Denition 2.2.17 (Theory)
Let T be a set of formulas. The theory induced by T, denoted by Th(T), is the set of all logical
consequences of T. That is,
Th(T) = [ T [=
Finally, an important property of rst-order logic is that it is monotonic. This means that the
set of consequences that can be derived from a given set of formulas only grows if we add more
formulas to this initially given set. In other words, the more premisses or information provided
as a starting point, the more conclusions or consequences can be derived from it. Formally, this
monotony property can be represented concisely using the notion of a theory.
Theorem 2.2.18 (Monotony of First-Order Logic)
Let T T

be two sets of formulas. Then we have: Th(T) Th(T

).
Proof. We need to show that [ T [= [ T

[= given that T T

. It thus is sucient
to show that for an arbitrary formula we have T

[= whenever T [= . So, assume that we

have T [= . This means that for all models M such that M [= T we have M [= . Clearly,
any model M

such that M

[= T

also is a model for T as T T

. It follows that an arbitrary

model M

such that M

[= T

also is a model for , i.e. M

[= . This means that we must have

Th(T

), and we are done.

To conclude, we briey make some remarks about automating the search for models in which
a formula is true. This is the same problem as determining whether a formula is satisable. Un-
fortunately, rst-order satisability is a dicult problem. The problem is not even semi-decidable
because certain formulas only have innite models. It thus is impossible to enumerate all models
and search through these until a model that satises a formula is found. Still, automated model
checkers for rst-order logic are available and are useful, for example, to complement rst-order
theorem provers that search for proofs instead of models. Moreover, if it is known that nite
models should exist if a formula is satisable then model checking is a viable alternative as well.
A well-known model checker is the Mace4 model checker (see [49]).
2.2. FIRST-ORDER LOGIC 29
2.2.4 Reasoning with First-Order Logic: Resolution-Based Proofs
In the previous section we looked at semantic reasoning. The basic method introduced is satisa-
bility checking, which involves searching for a counterexample for T [= . If such a counterexample
exists, then the does not follow from T and the claim T [= is refuted. In this section, we
investigate a syntactic method that also involves a search for a refutation of T [= . This method
is called resolution. Various techniques that are needed are introduced, including in particular uni-
cation of formulas using substitution, a procedure for converting arbitrary formulas into so-called
clausal form, and the skolemization technique which is part of this procedure.
Resolution is a very powerful inference rule. It is the only inference rule that we will discuss
here. Many rst-order theorem provers that are able to automatically nd proofs are based on the
resolution principle [2, 45].
13
Resolution is also the basic inference rule used in logic programming,
which we will discuss in section 2.3.
Resolution assumes that formulas have been converted to a particular normal form. The
normal form that is required for resolution to apply is called clausal form. Many rst-order
theorem provers convert a rst-order formula to clausal form before attempting to prove it [45].
Every rst-order formula can be converted to clausal form by a relatively simple procedure, which
can be fully automated, but the details for showing that the procedure is correct are somewhat
involved. The procedure removes all quantiers and essentially converts a rst-order formula to a
set of sets of literals.
Resolution is an inference rule that assumes that formulas are in clausal form. Moreover, it
assumes a procedure called unication. We rst introduce the concept of unication, and then
discuss clausal form and the resolution rule. After introducing the resolution rule we return to
the issue of converting rst-order formulas to the form required.
Unication
Key to the success of resolution-based theorems is the use of unication to guide the search for
proofs.
14
Unication thus is a key component of rst-order inference techniques.
Applied to rst-order languages, unication is a procedure that attempts to produce two iden-
tical expressions from two given expressions by instantiating free variables in the expressions.
For example, two terms closestFloorTo(x, oor2) and closestFloorTo(y, z) can be instantiated
by substituting e.g. oor1 for variables x and y and oor2 for variable z in which case we
obtain a single expression closestFloorTo(oor1, oor2) which instantiates both original expres-
sions. It is not always possible to nd such an instance; for example, there is no instantiation of
closestFloorTo(x, oor2) and closestFloorTo(oor1, x) that yields a single expression because only
a single, unique term may be subtituted for x. Clearly, the notion of a substitution for a variable
plays an important role in the denition of unication.
Denition 2.2.19 (Substitution)
A substitution is a partial function from variables 1 to terms T . The range of a substitution is
the set of variables for which it is dened. We are only interested in substitutions with a nite
range since the expressions of a rst-order language are nite. We also write x
1
/t
1
, . . . , x
n
/t
n

to denote a substitution with (x

i
) = t
i
.
A substitution may be applied to a term t, written t, by simulatenously replacing all
occurrences of any variable x in the range of that occur in term t by (x). A substitution may
also be applied to a formula by simultaneously replacing all free occurrences of a variable x in a
formula by (x) but some care needs to be taken to ensure that variables that are introduced by
13
Resolution is less ecient for nding purely propositional proofs. The DPLL method is more ecient in this
case [45].
14
Theorem provers essentially propositionalize a set of rst-order formulas in order to eciently nd a proof.
The use of unication avoids the need to instantiate universally quantied rst-order sentences with all possible
terms of the language, which greatly enhances the eciency of the proof search. See e.g. [62] for an informal
explanation.
30 CHAPTER 2. AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION
substituting are not bound by quantiers in ; that is, as before a term that is substituted for a
free variable in a formula should be free for that term (see Denition 2.2.5. t and are called
instances of t respectively . The procedure is essentially the same as in Denitions 2.2.3 and
2.2.4, but care should be taken to replace all variables in the range of an expression simultaneously
instead of one after the other. For example, the expression p(x, y) that results from applying the
substitution = x/f(y), y/c to the formula p(x, y) yields p(f(y), c) and not p(f(c), c)!
Two substitutions and may be composed into a new substitution. Of course, we would
expect the resulting substitution to yield the same result as the sequential application of the
substitutions. That is, if is the composition of the substitutions and , we expect that
e = (e) for arbitrary expressions. In order to ensure this, in the denition of the composition
of two substitutions and we need to consider three dierent cases.
Denition 2.2.20 (Composition of Substitutions)
Let and be two substitutions. The composition of and , written as , is the substitution

such that:
1.

(x) = (x), if x is in the range of and (x) ,= x.

2.

(x) is undened, if x is in the range of and (x) = x.

3.

(x) = (x), if x is in the range of but not in the range of .

For example, the composition of the substitutions = x/z, y/f(x, z), z/x and = u/f(x), x/z, y/d, z/x
is the substitution u/f(x), x/z, y/f(z, x). The resulting substitution can also be obtained in
a more procedural way, in a number of steps. Abstractly, let = x
1
/s
1
, . . . , x
m
/s
m
and
= y
1
/t
1
, . . . , y
n
/t
n
. As a rst step, create the set x
1
/s
1
, . . . , x
m
/s
m
, y
1
/t
1
, . . . , y
n
/t
n
.
Then, in a second step, delete all x
i
/s
i
for which x
i
= s
i
. Finally, in a third step, we need
to eliminate multiple mappings from one variable to a term, if these exist from the resulting set
to obtain a substitution (i.e. a function) again. That is, delete all pairs y
i
/t
i
for which in the
remaining set there also is a pair x
j
/s
j
such that x
j
= y
i
and x
j
is in the range of .
By design, we now have the following proposition.
Proposition 2.2.21 Let , and be substitutions.
For arbitrary expressions e, we have (e) = e().
Composition of substitutions is associative, that is: () = ()
Using the notion of a substition, we can dene unication. More precisely, we can dene when
a set of expressions can be unied.
Denition 2.2.22 (Uniable, Unier)
A nite set of expressions e
1
, . . . , e
n
is uniable if there is a substitution such that e
i
= e
j

for arbitrary i, j. In case exists, it is called a unier for the set of expressions.
Finally, we can show that if a set of expressions has a unier then there exists a most general
unier. A most general unier for a set E = e
1
, . . . , e
n
is a substitution such that for any
unier for E there exists a subsitution and = . That is, a most general unier can be rened
by instantiation of the terms to any other arbitrary unier. For example, p(f(x, y)), p(f(g(z), d)
is uniable by = x/g(c), y/d, z/c but = x/g(z), y/d is a more general unier (and actually
the most general unier in this case).
Proposition 2.2.23 If a set of expressions E has a unier, it has a most general unier.
There exist ecient algorithms to compute uniers automatically. We refer the reader to [62]
for an example algorithm.
2.2. FIRST-ORDER LOGIC 31
Resolution Inference Rule
A clause is a special type of rst-order formula: It is a disjunction of literals, where a literal is
either an atom or the negation of an atom. For example, p(x, y) q(z) r(x) p(z, z) is a
clause. Any free variables in a clause are supposed to be universally quantier. That is, the clause
in the example should be understood as equivalent to xyz(p(x, y) q(z) r(x) p(z, z)).
An arbitrary rst-order formula can be converted into a conjunction of clauses.
The resolution rule is a rule for reducing a set of clauses, and replacing two clauses by one new
clause.
Denition 2.2.24 (Resolution Rule)
Let
1
. . .
m
and
m+1
. . .
n
be two clauses that do not have any variables in common,
and let be a substitution. The resolution inference rule is the following rule:

1
. . .
m
,
1
. . .
n
,
i
=
j

1
. . .
i1

i+1
. . .
m

1
. . .
j1

j+1
. . .
n

The resolution inference rule allows to draw a new conclusion from two given premisses, which
all are clauses. The rule eliminates atoms from both clauses that are complementary, thus reducing
the number of atoms in total. For example, given the clauses p(x) q(y), q(c) and p(z), by
applying the resolution rule once to the rst two clauses, we obtain the new clause p(x); in
combination with the third clause this yields the empty clause.
By repeating the application of the resolution rule until no literals remain, i.e. until the
empty clause is derived, it can be shown that a set of clauses is unsatisable, i.e. inconsistent.
The process of applying the resolution rule thus is a process of refutation. A proof is constructed
that shows a set of clauses cannot be true in combination. How can we use this to verify whether
a formula follows from a given set of formulas T? To show this using resolution, the idea is to
rst create a single set of formulas T and to transform this set into clausal form. If by
means of resolution we can reduce this set of clauses to the empty clause, then we have shown
that T is unsatisable. But the latter is by Proposition 2.2.15 equivalent to T [= , and
we have shown what we wanted to show.
It can be shown that this single inference rule is sucient to derive all formulas that logically
follow from a set of formulas. That is, resolution is complete with respect to the consequences of a
set of formulas (see e.g. [2]).
15
Another important property of the resolution inference rule is that
it preserves truth, or is sound. An inference rule is said to be sound if its conclusion is a logical
consequence of its premisses.
Clausal Form
It may appear that the resolution inference rule is quite limited and allows reasoning with only a
particular small subset or fragment of rst-order languages because the rule requires formulas to
be in clausal form. There is a simple method, however, to transform arbitrary rst-order formulas
into such a form.
We briey outline the steps to convert a formula to clausal form, but for details refer the reader
to [62]. First, implications

need to be replaced by

and thereafter negations need

to be pushed inwards to make sure negations only apply to atoms and not to composed formulas.
This can be done by using equivalences such as the De Morgan laws. Variables should be renamed
to ensure that quantiers bind unique variables. Secondly, existential quantiers are eliminated
by a procedure called skolemization. This procedure is more involved and will be discussed more
extensively below, as it is not completely obvious that this procedure preserves satisability.
Third, universal quantiers are moved to the front and subsequently completely removed from the
formula. Finally, the resulting formula should be brought into conjunctive normal form, i.e. into
a form that is a conjunction of clauses.
15
The binary resolution rule that we have introduced above is not complete by itself. Another rule called factoring
for removing literals that are uniable is needed to achieve this, but we do not discuss the details here. See for
example [62].
32 CHAPTER 2. AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION
Skolemization
One of the steps in converting an arbitrary formula to clausal form concerns the elimination
of existential quantiers. The basic idea, which goes back to the logician Thoralf Skolem, is
that whenever an existential statement x is true there must be an object that has property
and we may introduce a new name to refer to this object. For example, if we know that
x : killed(x, mary) we can introduce a new constant, say murderer if that constant does not yet
occur in the language, and write killed(murderer, mary). Of course, in order to preserve truth it is
quite important that the name is chosen such that it does not occur in the rst-order language that
is used. Introducing a new name or constant for some object that is claimed to exist is often more
convenient than reasoning with the existential quantier. Such constants introduced to eliminate
existential quantiers are also called Skolem constants.
The procedure to introduce Skolem constants can be generalized to replace existential quan-
tiers that are preceded by a sequence of universal quantiers. In a formula x
1
. . . x
n
y we
cannot simply eliminate the existential quantier y by substituting a new constant c for y. This
would result in a new formula x
1
. . . x
n
[c/x] that expresses that for arbitrary choices of values
for x
1
, . . . , x
n
there is a single object named c such that [c/x]. This, however, is too strong as it
follows that yx
1
. . . x
n
since we cannot simply reverse the order of universal and existential
quantiers. Although we have yx xy the implication in the other direction does not
hold. For example, although it is true that for every natural number n there is a natural number
m that is greater than n (that is, we have xy : y > x is true on the natural numbers), it is not
true that there exists a single natural number m that is greater than an arbitrary natural number
n (that is, yx : y > x is not true on the natural numbers, because suppose m would be such a
natural number; then take the natural number m+ 1; this is greater than m, a contradiction).
The trick is to introduce a selection function instead of a simple constant that takes the
dependency on the universally quantied variables into account. In our example, there clearly is a
function f(x) that yields a number that is greater than x - simply take e.g. f(x) = x +1, and we
can use this function to eliminate the existential quantier. That is, we eliminate the existential
quantier y in xy : y > x by introducing and substituting f(x) for y which results in a new
formula x : f(x) > x. Of course, again we need to make sure the function f is new and not
yet part of the language. It is easy to generalize this process to arbitrary number of universally
quantied variables: for a formula of the form x
1
, . . . , x
n
y introduce the selection function
f(x
1
, . . . , x
n
). These functions are called Skolem functions.
The following theorem justies the elimination of existential quantiers by the introduction
of Skolem functions. Of course, the set of formulas T

obtained by introducing Skolem functions

instead of existential quantiers is not equivalent to the original set of formulas T but is strictly
stronger. We can, however, show that the new set of formulas T

does not allow to prove anything

essentially new except with respect to formulas that contain the Skolem functions. We say that a
set of formulas T

is a conservative extension over a set of formulas T if whenever T

[= for
without occurrences of skolem functions then we also have that T [= .
Theorem 2.2.25 If T [= x
1
. . . x
n
y, then T

= T x
1
. . . x
n
[f(x
1
, . . . , x
n
)/y], where
f(x
1
, . . . , x
n
) is a Skolem function that is free for y, is a conservative extension over T.
Proof. We refer the reader to [19] for a proof.
This shows that the introduction of skolem functions does not essentially strenghten a given
set of formulas. In practice, in order to avoid having to deal with the condition for introducing
Skolem functions in Theorem 2.2.25 that the function f(x
1
, . . . , x
n
) is free for y, it is useful to
rename all quantier variables such they each quantier is associated with a unique variable. This
ensures there will never be any clashes when a Skolem function is introduced.
Theorem 2.2.26 If T is satisable, and T [= x
1
. . . x
n
y, then T

= Tx
1
. . . x
n
[f(x
1
, . . . , x
n
)/y]
is satisable.
2.2. FIRST-ORDER LOGIC 33
It should be noted that the translation of a formula into clausal form can increase the size by an
exponential amount. Obviously, such exponential growth also makes the process very inecient.
There are, however, techniques to avoid such exponential blowup [45].
2.2.5 Decidability, Computability, and Fragments of First-Order Logic
Thus far we have presented the mathematical semantics and resolution as a formal proof theory
for rst-order logic, but we have not looked at the computational properties of rst-order logic. It
turns out that the problem of determining whether T [= is undecidable. Consequently, we have
to look for alternatives to rst-order logic that behave better from a computational point of view
and to this end we discuss two fragments of rst-order language.
Theorem 2.2.27 (Undecidability of First-Order Logic)
There is no eective procedure for deciding whether T [= for arbitrary rst-order languages.
For a proof of Theorem 2.2.27 we refer the reader to [10] and [50]. Of course, this result is
disappointing from a computational point of view. The theorem does not just state that it is
hard, in the sense of computational complexity theory, to decide whether the problem T [= is a
yes-instance or a no-instance, but actually states it is impossible to construct an algorithm that
would provide the right answer in a nite amount of time. Theorem 2.2.27 thus informs us that
fully automated machine theorem proving is an ideal that cannot be attained for rst-order logic.
On the other hand, the completeness of rst-order logic guarantees that whenever a sentence
follows from a set of sentences T there exists a formal proof that shows this. As it is possible to
search the space of all possible proofs by means of a machine, a machine thus will eventually nd
a proof if it exists. The problem is, however, that if such a proof does not exist the machine may
never terminate. For this reason, the problem of deciding entailment is called semi-decidable.
As we are looking for a suitable language that agents can use to automatically reason about
their environment, we thus have to investigate other possibilities that do ensure an agents reason-
ing process will always terminate. One strategy that we will explore here is to identify fragments
of rst-order logic that are decidable and are suitable from an agent-oriented point of view. There
are a number of requirements that need to be considered when evaluating whether a particular
fragment is suitable or not. These requirements have been discussed in section 2.1 above.
A well-known example of a fragment of rst-order logic that is decidable is the fragment
of languages with only a nite number of one-placed or monadic predicates [10]. For example,
sentences such as xy(p(x)q(y)) are allowed in this fragment, but sentences such as xy : p(x, y)
are not part of the fragment as p(x, y) is a two-placed predicate. This fragment is also called
monadic predicate logic. Intuitively, the reason why this fragment is decidable is that for evaluating
monadic sentences with at most k monadic predicates it is sucient to take into account the 2
k
number of combinations of k properties.
16
We thus have to inspect only a nite number of nite
models. The number of models that we may have to inspect, however, may be exponential in the
length of the input, i.e. a set of sentences.
The monadic fragment facilitates reasoning about sets and basic properties of objects. Histori-
cally, this fragment is important as it formalizes so-called syllogistic reasoning, a form of reasoning
already discussed by Aristotle in the fourth century BC. Syllogistic reasoning concerns a number
of basic reasoning patterns. A classic example is that from the two premisses All man are mortal
and Socrates is a man it follows that Socrates is mortal. Formally, the premisses can be repre-
sented by x(man(x) mortal(x)) and man(s) and the conclusion by mortal(s). This and other
syllogistic reasoning patterns can be completely formalised in monadic rst-order languages.
Evaluating this fragment as a knowledge representation technology by means of the require-
ments listed in section 2.1, however, suggests that monadic predicate logic is not very suitable
for use as a knowledge representation language by agents. Although it inherits most properties
of rst-order logic such as that it is a declarative language, etc. the main issue is the restricted
16
This is the case for the fragment without equality =. The monadic fragment with equality is also decidable
but the models needed are bigger, cf. [10].
34 CHAPTER 2. AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION
expressivity of the fragment. There is, for example, in practice often a need to use binary relations
which cannot be expressed in the monadic fragment.
A second fragment that is more promising as a suitable knowledge representation technology is
the fragment that consists only of so-called Horn clauses. Horn clauses are sentences of the form
(a
1
. . . a
n
) h where the a
1
, . . . , a
n
, h are atoms. The conjunction of atoms a
1
. . . a
n
is called the body of the Horn clause and h is called the head of the clause. Horn clauses thus
are universal sentences, where the sub-formula within the scope of the universal quantiers is an
implication with a conjunction of atoms as antecedent and a single atom as the consequent of the
implication. This fragment will be discussed extensively in the remainder of this chapter, as it
provides a foundation for logic programmng.
The Horn clause fragment is a subset of the universal fragment of rst-order logic, i.e. formulas
without occurrences of existential quantiers. In fact, Horn clauses are a special kind of clauses
as discussed above. A clause is a disjunction of literals where all variables have been implicitly
universally quantied. It is easy to rewrite a Horn clause into such a form by rewriting the
implication. Any Horn clause (a
1
. . .a
n
) h can be rewritten as the clause a
1
. . .a
n
h.
We thus can apply the resolution inference rule to Horn clauses immediately, but because of their
more special form a more specic proof procedure can be developed.
2.3 Logic Programming
The restriction to the Horn clause fragment has given rise to a special programming paradigm
called logic programming. The ideal of this paradigm has been to write special, declarative pro-
grams that specify what is the case, but do not specify how to solve a problem. Computation
in the logic programming paradigm essentially is the process of deriving a proof using a special
version of the resolution inference rule, and consists in an attempt to build a proof for a query of
the form a
1
. . . a
n
where the a
i
are atoms.
17
The basic idea has been paraphrased by Kowalski
in the following equation: an Algorithm = Logic + Control. Here, logic provides the means to
write a program as declarative knowledge, and control refers to the inference process, which is
automatic.
We refer the reader to additional short notes on logic programming for more information.
2.3.1 Prolog
The logic programming paradigm has been turned into a practical programming language known
as Prolog. Prolog extends the pure logic programming paradigm with various features to make the
language easier to use in practice. For example, all Prolog implementations come with extensive
sets of built-in operators, for example for arithmetic operators, for handling lists, etc. Also, equal-
ity = in Prolog is treated dierently from equality = in rst-order logic, and has a more syntactic
avor as only terms that are uniable are consider equal in Prolog. There are other features such
as modules which are available in most Prolog implementations that provide additional features
that go beyond the pure logic programming paradigm. We refer the reader to [68] for a classic
introduction and to the SWI-Prolog manual for details about SWI Prolog (see the [69] reference
in the bibliography).
2.4 Exercises
2.4.1
17
This is often called a goal in logic programming, but since this notion has a completely dierent meaning in
the context of rational agents (see chapter 1 we avoid the use of this terminology here.
2.4. EXERCISES 35
1. Explain why a rst-order language is:
(a) Declarative,
(b) Compositional,
(c) Expressive,
(d) Context-independent,
(e) Unambiguous.
2. The inference requirement states that a knowledge representation technology should
be able to answer as many queries as possible. What would be the most useful answer
that a technology can provide for a query of the form x? Explain your answer.
2.4.2
Show that a sentence is either true in a model or not true, i.e. false in a model. This shows
that the truth of a sentence does not depend on a valuation of variables.
2.4.3
Show that two formulas and

are (logically) equivalent if all models of are models of

, and vice versa. That is, show that and

are logically equivalent i for all models

M : M [= i M [=

.
2.4.4
1. Show that T [= if T is inconsistent.
2. Explain why it is undesirable that an agents beliefs are inconsistent.
2.4.5
Prove that xy : p(x, y) and yx : p(x, y) are not equivalent. That is, provide a coun-
terexample for xy : p(x, y) yx : p(x, y).
2.4.6
Provide counterexamples for the following formulas:
1. xy : r(x, y) yx : r(x, y)
2. x(p(x) r(x)) (x : p(x) x : r(x))
3. (x : p(x) x : r(x)) x : (p(x) r(x))
2.4.7
Prove that T = xyz((r(x, y) r(y, z)) r(x, z)), xy : r(x, y), xr(x, x) only has
innite models. That is, show that there are no models M = D, I with D a nite set such
that M [= T.
2.4.8 (Substitutions)
Prove that, for any model M = D, I, valuation V , and term t that is free for , the
following holds (use induction on the structure of ):
M, V [= [t/x] i M, V [V (t)/x] [=
2.4.9
Dene the quantier !x which means that there exists exactly one object that satises a
formula. That is, !x means that there is exactly one object that satises .
2.4.10 (Substitutions)
36 CHAPTER 2. AUTOMATED REASONING AND KNOWLEDGE REPRESENTATION
Show that () yields the same formula as (), assuming that all variables bound by
quantiers in do not occur in nor . This shows that we may drop parentheses and can
simply write . (Hint: use induction on the structure of formulas.)
2.4.11 (Prolog)
Consider the following program.
p :- not(q).
q :- not(p).
(a) Is this program well-dened? Does it have a meaning? Use T
P
to motivate your answer.
(b) What result is produced when you load this program into Prolog and enter the query
q.? Explain the output that you obtain.
(c) Do you think these results are intuitive? Do they correspond with the interpretation of
not as negation-as-failure? Motivate your answer.
Chapter 3
Mental States
A rational agent maintains a mental state to represent the current state of its environment and
the state it wants the environment to be in. The representation of the current state determines
the informational state of the agent, and consists of the knowledge and beliefs of an agent.
1
The
representation of the desired state determines the motivational state of the agent, and consists of
the goals of an agent.
2
A mental state thus is made up of the knowledge, beliefs and goals of an
agent. The mental attitudes discussed in this chapter are rst-order attitudes, and do not allow
for e.g. second-order beliefs about beliefs or goals. Agents equipped with such mental states are
rst-order intentional systems (cf. Chapter 1).
3.1 Representing Knowledge, Beliefs and Goals
One of the rst steps in developing and writing a Goal agent is to design and write the knowledge,
beliefs and goals that an agent needs to meet its design objectives. Of course, the process of doing
so need not be nished in one go but may need several iterations during the design of an agent. It
is however important to get the representation of the agents knowledge, beliefs and goals right as
the actions chosen by the agent will depend on its knowledge, beliefs and goals. More specically,
the action specications and action rules discussed in Chapters 4 and 5 also depend on it. To this
end, we need a knowledge representation language that we can use to describe the content of the
various mental attitudes of the agent. Although Goal is not married to any particular knowledge
representation language, here Prolog will be used to present an example Goal agent.
3.1.1 Example Domain
As a running example in this chapter, we will use one of the most famous domains in Articial
Intelligence known as the Blocks World [72, 67, 62]. In its most simple (and most common) form,
in the Blocks World an agent can move and stack cube-shaped blocks on a table by controlling a
robot gripper. One important fact is that the robot gripper is limited to holding one block at a
time and cannot hold a stack of blocks. For now, we will focus on the conguration of blocks on
the table; we will provide the details related to the gripper later in Chapter 4. A block can be
directly on top of at most one other block. That is, a block is part of a stack and either located
on top of a single other block, or it is sitting directly on top of the table. These are some of the
basic laws of the Blocks World. See Figure 3.1 for an example Blocks World conguration. This
gure graphically depicts both the initial state or conguration of blocks as well as the goal state.
It is up to the agent to realize the goal state by moving blocks in the initial state and its successor
states. We add one assumption about the table in the Blocks World: we assume that the table is
1
Knowing and believing are also called informational attitudes of an agent. Other informational attitudes are,
for example, expecting and assuming.
2
Wanting is a motivational attitude. Other motivational attitudes are, for example, intending and hoping.
37
38 CHAPTER 3. MENTAL STATES
Figure 3.1: Example Blocks World problem taken from [67].
large enough to be able to place all blocks directly on the table. This is another basic law of
our version of the Blocks World.
3
An agent that has the task to achieve a goal state in the Blocks World needs to be able to
represent the conguration of blocks. It needs to be able to represent such congurations for two
reasons: to keep track of the current state of the Blocks World and to describe the goal state
that it wants to reach. As we will be using a rst-order language, we need to introduce specic
predicates to be able to fully specify a conguration of blocks. Typically, it is a good idea to
introduce predicates that correspond with the most basic concepts that apply in a domain. More
complicated concepts then may be dened in terms of the more basic concepts. We will use this
strategy here as well.
4
One of the most basic concepts in the Blocks World is that a block is on top of another block
or is on the table. To represent this concept, we introduce a binary predicate:
on(X, Y)
The predicate on(X, Y) means that block X is (directly) on top of Y. For example, on(a,b)
is used to represent the fact that block a is on block b and on(b,table) is used to represent that
block b is on the table. This is our informal denition of the predicate on(X, Y). To understand
what is implied by this denition, a few comments on some aspects of this denition are in order.
First, only blocks can be on top of something else in the Blocks World. Second, X must be directly
on top of Y meaning that there can be no other block in between block X and Y. Third, Y may refer
either to a block or to the table. And, fourth, there can be at most one block on top of another
block. Note that it is up to the agent designer to stick to these rules and to use the predicate on
to express exactly this and nothing else.
There is one additional thing to note about the examples we have used. When we say that
on(b,table) means that block b is on the table we have implicitly assumed that all blocks have
unique names that we can use to refer to each block. This assumption is very useful since by
introducing such names we then can refer to each block and are able to distinguish one block from
another (as every block is assumed to have another name). It thus greatly simplies our task as
3
This assumption is dropped in so-called slotted Blocks World domains where there are only a nite number of
slots to place blocks.
4
It can be shown that the basic concept above is sucient in a precise sense to completely describe arbitrary,
possibly innite congurations of the Blocks World; that is not to say that everything there is to say about a Blocks
World conguration can be expressed using only the above predicate [18]. Here we follow tradition and introduce
the predicates on and clear to represent Blocks World congurations.
3.1. REPRESENTING KNOWLEDGE, BELIEFS AND GOALS 39
designer to design an agent controller for the Blocks World. In addition we will assume we have
names for all blocks in the Blocks World; and, as we have already been using it, we use the label
table to refer to the table in the Blocks World. This in eect is a domain closure assumption
for the Blocks World. In order to make explicit which blocks are present in the Blocks World we
introduce the unary predicate block. To represent an instance of the Blocks World domain with
exactly 7 blocks, as in Figure 3.1, we then can use:
block(a). block(b). block(c). block(d). block(e). block(f). block(g).
Of course, we need to implicitly assume here that there are no other blocks. We cannot
explicitly state this using Prolog (we would need a quantier to do so) but this assumption is built
into Prologs semantics (by means of the Closed World assumption, see also the box discussing this
assumption below). As a side eect, note that the block predicate also allows us to distinguish
blocks from the table.
Using the on predicate makes it possible to represent the state a Blocks World is in. For
example, the conguration of blocks in the initial state in Figure 3.1 can be represented by:
on(a,b). on(b,c). on(c,table). on(d,e). on(e,table). on(f,g). on(g,table).
Blocks World Problem
Using the on predicate we can actually dene the notion of a state in the Blocks World.
A state is a conguration of blocks and may be dened as a set of facts of the form
on(X,Y) that is consistent with the basic laws of the Blocks World (i.e. at most one
block is directly on top of another, etc.). Assuming that the set B of blocks is given, we
can dierentiate incomplete or partial states from completely specied states. A state
that contains a fact on(X,Y) for each block X B in the set B is called complete,
otherwise it is a partial state.
As both the initial state and the goal state are congurations of blocks, it is now also
possible to formally dene what a Blocks World problem is. A Blocks World problem
simply is a pair B
initial
, G where B
initial
is the initial state and G denotes the goal
state. The labels B
initial
and G have been intentionally used here to indicate that the
set of facts that represent the initial state correspond with the initial beliefs and the set
of facts that represent the goal state correspond with the goal of an agent that has the
task to solve the Blocks World problem.
The third predicate that we introduce is the unary predicate:
clear(X)
clear(X) means that X is clear. That is, if X is a block clear(X) means there is no other
block on top of it. Obviously, given a complete state, the information that a block is clear is
implicitly present and can be derived. Just by looking at Figure 3.1 it is clear that blocks a, d,
and f are clear in the initial state. The predicate is introduced mainly to facilitate reasoning
about the Blocks World. In order to deal with the limitations of the gripper it is important to be
able to conclude that a block is clear. It is possible to dene the clear concept in terms of the on
predicate by the following clause:
clear(X) :- block(X), not( on(_, X) ).
40 CHAPTER 3. MENTAL STATES
Floundering
It is important to take the oundering problem of Prolog systems into account when
dening the procedure clear(X). Floundering would cause problems if we would have
dened the clear predicate by
clear(X) :- not( on(Y, X) ), block(X).
Although this denition would still work ne when X is instantiated, it would give the
wrong answer when X would not be instantiated. That is, the query clear(a) in the
initial state of Figure 3.1 yields true, but the query clear(X) would yield false and
return no answers! An easy rule of thumb to avoid problems with oundering is to make
sure that each variable in the body of a rule rst appears in a positive literal. We have
achieved this by introducing the positive literal block(X) rst which binds X before
the variable is used within the second, negative literal not(on( , X)). Moreover, in
our denition we have used a dont care variable instead of the variable Y above.
The clear predicate is introduced in part because an agent needs to be able to conclude that
a block X can be placed on top of another block Y or on the table. This can only be done if there
is no other block on top of block Y, i.e. block Y is clear, or there is room on the table to put the
block on. In both cases we would like to say that the block or the table is clear to indicate that
a block can be moved onto either one. The informal meaning of clear(X) therefore is made
slightly more precise and clear(X) is interpreted as that there is a clear space on X to hold a
block [62]. In other words, the table is also said to be clear as we have assumed that the table
always has room to place a block. The denition of clear(X) above, however, does not cover
this case (verify yourself that clear(table) does not follow; also check that even when the
block(X) literal in the body of the clause dening clear(X) is removed it still does not follow
that clear(table)). We therefore need to add the following fact about the table:
clear(table)
This ends our design of a language to represent the Blocks World. That is not to say that
there are no logical extensions we can introduce that may be useful to represent and reason about
the Blocks World. In fact, below we will introduce a denition of the concept of a tower. And
there are still other useful concepts that may be introduced (see the Exercise Section where the
binary predicate above is dened).
3.1.2 Mental State
We are now ready to dene the mental state of our agent for controlling the robot gripper in
the Blocks World. A mental state of a Goal agent consists of three components: knowledge,
beliefs and goals. As discussed, knowledge and beliefs represent the current state of the agents
environment and goals represent the desired state. We will rst discuss the knowledge and beliefs
of our Blocks World agent and thereafter discuss the goal state of the agent.
The information that an agent has about its environment consists of the knowledge and of
the beliefs the agent has. The main dierence between knowledge and beliefs in Goal is that
knowledge is static and cannot change at runtime and belief is dynamic and may change at
runtime. An immediate consequence of this dierence is that the knowledge base that contains an
agents knowledge cannot be used to keep track of the current state of the environment. Because
the state of the environment will change instead this state needs to be represented by means of
the agents beliefs.
As we will explain in more detail in Chapter 4, only facts such as on(a,b) can be modied at
runtime and rules such as clear(X) :- block(X), not( on( , X) ) cannot be modied.
As a rule of thumb, therefore, it is a good idea to put rules and denitions into the knowledge base.
Such rules typically consist of domain knowledge that represents the basic laws or the logic
3.1. REPRESENTING KNOWLEDGE, BELIEFS AND GOALS 41
of the domain. The knowledge base may also contain facts that do not change. An example of a
fact in the Blocks World that might be added to the knowledge base because it is always true is
clear(table).
knowledge{
block(a). block(b). block(c). block(d). block(e). block(f). block(g).
clear(table).
clear(X) :- block(X), not(on(_, X)).
}
The knowledge keyword is used to indicate that what follows is the knowledge of the agent.
This part of the agent program is also called the knowledge section and is used to create the
knowledge base of the agent. Apart from the clear(table) fact the knowledge section also
consists of facts of the form block(X) to represent which blocks are present in the Blocks World.
All blocks present in Figure 3.1 are enumerated in this section. By putting these facts in the
knowledge section the assumption is made implicitly that no blocks will be introduced later on
nor will any of these blocks be removed from the environment (why?). The knowledge section also
includes the domain knowledge about when a block is clear. The rule clear(X) :- block(X),
not( on( , X) ) represents this domain knowledge.
One thing to note is that the block facts are represented as separate facts that are separated
using the period symbol as is usual in Prolog. The code listed above in the knowledge section
actually represents a Prolog program. In fact, the content of a knowledge section must be a
Prolog program and respect the usual syntax of Prolog. It is also possible to use most of the
built-in operators of the Prolog system that is used (in our case, SWI Prolog [69]). For a list of
all built-in operators that can be used, consult the Appendix A.
Closed World Assumption
It is important to realize that the rule clear(X) :- block(X), not(on( , X))
can only be used to correctly infer that a block is clear if the state represented by the
agents beliefs is complete. The point is that the negation not is the negation by failure of
Prolog. This means that block(X), not(on( , X)) succeeds for every block block
about which there is no information whether on( , block) holds. In the absence of
any information that on( , block) it follows that clear(block) since in that case
no proof can be constructed for on( , block) and negation as failure applies.
Another way to make the same point is to observe that Prolog supports the Closed World
Assumption. Informally, making the Closed World Assumption means that anything not
known to be true is assumed to be false. In our example, this means that if there is no
information that there is a block on top of another, it is assumed that there is no such
block. This assumption, of course, is only valid if all information about blocks that are
on top of other blocks is available and represented in the belief base of the agent. In
other words, the state represented in the belief base of the agent needs to be complete.
A nal remark concerns how an agent can maintain a complete state representation in
its belief base. An agent can only keep track of the complete state of the environment if
that state is fully observable for the agent.
The lesson to be learned here is that domain knowledge needs to be carefully designed
and basic assumptions regarding the domain may imply changes to the way domain
knowledge is to be represented. In our example, if an agent cannot keep track of the
complete state of the Blocks World, then the rule for clear(X) needs to be modied.
Facts that may change, however, must be put in the belief base of the agent. The initial state
of Figure 3.1 thus may be represented in the beliefs section of a Goal agent.
beliefs{
on(a,b). on(b,c). on(c,table). on(d,e). on(e,table). on(f,g). on(g,table).
}
42 CHAPTER 3. MENTAL STATES
The beliefs keyword is used to indicate that what follows are the initial beliefs of the agent.
This part of the agent program is also called the beliefs section. The facts that are included
in this section are used to initialize the belief base of the Goal agent. These facts may change
because, for example, the agent performs actions. A similar remark as for the knowledge section
applies to the beliefs section: the code within this section must be a Prolog program.
Perception
Since facts about the current state of the environment typically are collected through
the sensors available to the agent, the beliefs section of a Goal agent program often
is empty. The reason is simply that usually the initial state is unknown and the initial
beliefs need to be obtained by perceiving the initial state of the environment.
The beliefs section above consists of facts only. This is not required, however, and a beliefs
section may also include rules. The denition of clear(X) in the knowledge section might have
also been moved to the beliefs section. In fact, since rules cannot be modied anyway, just from
an informational perspective nothing would change. Below we will clarify, however, that when
goals are taken into account as well the choice to put the denition of clear(X) in the beliefs
section does change things. To repeat, as a rule of thumb, it is a good idea to include rules in the
knowledge base and not in the belief base; the main reason for making exceptions to this rule will
be discussed below.
The discussion about the Closed World Assumption and the denition of the clear(X) pred-
icate should make clear that the knowledge base in isolation is not sucient to make correct
inferences about the Blocks World. Only by combining the knowledge with the beliefs the agent
will be able to do so. This is exactly what happens in Goal. That is, a Goal agent derives conclu-
sions from the combination of its knowledge and beliefs. This combination allows an agent to infer
facts about the current state that it believes it is in by using the rules present in the knowledge
section. For example, from the knowledge present in the knowledge section above in combination
with the beliefs in the beliefs section the agent may derive that clear(a) holds. It is able to
infer that block a is clear by means of the rule clear(X) :- block(X), not(on( , X))
and the absence of any information in the belief base that there is a block on top of a.
Prolog Denitions
It is not possible to dene one and the same predicate in both the knowledge as well
as in the beliefs section of an agent program. That is, one and the same predicate can
not occur in the head of a Prolog rule that appears in the knowledge section as well
as in the head of a Prolog rule that appears in the beliefs section. Even if this were
possible it is not considered good practice to dene a Prolog predicate at two dierent
places. It is best practice to keep clauses that dene a predicate (called a procedure in
Prolog) close together.
We now turn to the representation of goals. For our example domain, illustrated in Figure 3.1,
it is rather straightforward to write down a clause that represents the goal state. We thus get:
goals{
on(a,e), on(b,table), on(c,table), on(d,c), on(e,b), on(f,d), on(g,table).
}
Note that in a Goal agent program the goals keyword is used to indicate that what follows
is wanted by the agent. The goal(s) present in this section of a Goal agent program dene the
initial goal base of the agent. A goal base thus consists of all goals that the agent initially wants
to achieve.
5
Intuitively, what is wanted should not be the case yet. The main reason is that a
5
Note that if the goal base is implemented as a Prolog database, the storage of negative literals is not supported
and goals to achieve states where a condition does not hold cannot be explicitly specied.
3.1. REPRESENTING KNOWLEDGE, BELIEFS AND GOALS 43
rational agent should not spent its resources on trying to realize something that is already the
case. It is easy to verify that the clause above represents the goal state depicted in Figure 3.1 and
is dierent from the initial state.
Types of Goals
Goals that are not currently the case but need to be realized at some moment in the
future are also called achievement goals. In order to realize such goals, an agent needs
to perform actions to change the current state of its environment to ensure the desired
state. A goal of realizing a particular conguration of blocks dierent from the current
conguration is a typical example of an achievement goal. Achievement goals are just
one type of goal among a number of dierent types of goals. At the opposite of the goal
spectrum are so-called maintenance goals. In order to realize a maintenance goal, an
agent needs to perform actions, or, possibly, refrain from performing actions, to maintain
a specic condition in its environment to ensure that this condition does not change.
A typical example in the literature is a robot that needs to maintain a minimum level
of battery power (which may require the robot to return to a charging station). In
between are goals that require an agent to maintain a particular condition until some
other condition is achieved. An agent, for example, may want to keep unstacking blocks
until a particular block needed to achieve a goal conguration is clear (and can be moved
to its goal position).
The careful reader will have noted one important dierence between the representation of the
goal state in the goals section above and the representation of the initial state in the beliefs
section. The dierence is that the goal state of Figure 3.1 is represented as a single conjunction in
the goals section. That is, the atoms describing the goal state are separated by means of a comma
,. The reason is that each of the facts present in the goals section need to be achieved simulta-
neously. If these facts would have been included as clauses separated by the period-symbol this
would have indicated that the agent has multiple, independent goals. The following specication
of the goals of an agent thus is not the same as the specication of the goal state above:
goals{
on(a,e). on(b,table). on(c,table). on(d,c). on(e,b). on(f,d). on(g,table).
}
The main dierence concerns the number of goals. The conjunctive goal counts as a single goal,
whereas the 7 atoms separated by the period symbol count as 7 distinct, independent goals. To
have two separate goals on(a,b) and on(b,c) instead of a single conjunctive goal on(a,b),
on(b,c) is quite dierent. Whereas having two separate goals does not pose any restrictions
on the order of achieving them, combining these same goals into a single conjunctive goal does
require an agent to achieve both (sub)goals simultaneously. This also restricts the actions the
agent can perform to achieve the goal. In the rst case with two separate goals, the agent may,
for example, put a on top of b, remove a again from b, and put b on top of c. Obviously, that
would not achieve a state where a is on top of b which is on top of c at the same time.
6
It thus
is important to keep in mind that, from a logical point of view, the period-symbol separator in
the beliefs (and knowledge section) means the same as the conjunction operator represented
by the comma-symbol, but that the meaning of these separators is dierent in the goals section.
In the goals section the conjunction operator is used to indicate that facts are part of a single
goal whereas the period-symbol separator is used to represent that an agent has several dierent
goals that need not be achieved simultaneously. As separate goals may be achieved at dierent
6
These observations are related to the famous Sussman anomaly. Early planners were not able to solve simple
Blocks World problems because they constructed plans for subgoals (parts of the larger goal) that could not be
combined into a plan to achieve the main goal. The Sussman anomaly provides an example of a Blocks World
problem that such planners could not solve, see e.g. [27].
44 CHAPTER 3. MENTAL STATES
times it is also allowed that single goals when they are taken together are inconsistent, where this
is not allowed in the beliefs section of an agent. For example, an agent might have the two goals
on(a,b) and on(b,a). Obviously these cannot be achieved simultaneously, but they can be
achieved one after the other.
Goals Must Be Ground
The goals in a goals section must be ground, i.e. they should not contain any free
variables. The main issue is that it is not clear what the meaning of a goal with a free
variable is. For example, what would the goal on(X,table) mean? In Prolog, the
reading would depend on whether on(X,table) is a clause (or rule with empty body)
or a query. In the former case, a goal on(X,table) would be implicitly universally
quantied and the meaning would be that everything should be on the table (but how
does an agent compute everything?). Taking on(X,table) to be a query would yield
an existential reading and would mean that the goal would be to have something on the
table. Both readings give rise to problems, however, since we want to be able to store
on(X,table) in a database supported by the underlying knowledge representation
language and we want to be able to use on(X,table) as a query to verify whether it is
believed by the agent (to check whether the goal has been achieved). Using Prolog this
gives rise to both readings. That is, the storage in a database assumes implicit universal
quantication and the use as query assumes existential quantication. We can not have
it both ways and therefore using Prolog it is not possible to oer support for goals with
free variables.
The content of a goals section thus does not need to be a Prolog program because the comma
separator , may be used to construct conjunctive goals. The conjuncts in a goal may be atoms
such as above. They may also be rules, however. We could, for example, have written the following
program code:
goals{
on(a,e), on(b,table), on(c,table), on(d,c), on(e,b), on(f,d), on(g,table),
(clear(X) :- not(on(_, X))).
}
The rst thing to note here is that additional brackets are needed to be able to parse the rule
for clear(X) correctly. The second thing is that the rule has been added as a conjunct to the
larger conjunctive goal to ensure is will be associated with these other subgoals. Intuitively, it is
clear that it should be possible to infer that clear(a), clear(f), and clear(g) are derived
goals, and that is also in fact the case in Goal. At the same time, however, it is not so clear
why the rule for clear(X) should be included in the goals section as part of the larger goal of
the agent. First of all, the denition of clear seems to be conceptual knowledge and it would be
more adequate as well as natural to have to specify this type of knowledge only once. That is,
since the rule for clear is already present in the knowledge base, why should it be repeated in the
goal base? Second, also from a designers perspective such duplication of code seems undesirable.
Duplication of code increases the risk of introducing bugs (by e.g. changing code at one place but
forgetting to change it also at another place).
This motivates the practice in Goal to support reasoning with goals in combination with
(background) knowledge. If a rule, in the example above the rule for clear is already present
in the knowledge base, the rule does not also need to be included in the goal base. Queries with
respect to a goal in the goals section in Goal are always performed in combination with the
available knowledge. This means that e.g. given the goal state of Figure 3.1 represented as above
it is possible to infer clear(a) from that goal using the rule for clear in the knowledge
section.
Another illustration of the usefulness of combining conceptual, background knowledge with
goals to infer derived goals can be provided by the tower concept in the Blocks World. It turns
out that this concept is particularly useful for dening when a block is in position or misplaced. In
3.1. REPRESENTING KNOWLEDGE, BELIEFS AND GOALS 45
order to provide such a denition, however, we need to be able to derive that an agent has the goal
of realizing a particular tower. It is clear that this cannot be derived from the information present
in the goals section above. We rst need to dene and introduce the conceptual knowledge related
to the notion of a tower. The following code provides a denition of the tower predicate:
tower([X]) :- on(X, table).
tower([X,Y|T]) :- on(X, Y), tower([Y| T]).
The rules that dene the tower predicate specify when a list of blocks [X|T] is a tower. The
rst rule tower([X]) :- on(X,table) requires that the basis of a tower is grounded on the
table. The second rule recursively denes that whenever [Y|T] is a tower, extending this tower
with a block X on top of Y also yields a tower; that is, [X,Y|T] is a tower. Observe that the
denition does not require that block X is clear. As a result, a stack of blocks that is part of a larger
tower also is considered to be a tower. For example, it is possible to derive that tower([b,c])
using the facts representing the initial state depicted in Figure 3.1.
Following the rule of thumb introduced earlier, the rules for tower should be included in the
knowledge section. The benet of doing this is that it makes it possible to also use the tower
concept to derive goals about towers. For example, it is possible to infer from the representation
of the goal state of Figure 3.1 that the agent wants tower([e,b]). The agent can infer this
(sub)goal by means of the rules that dene the tower predicate in the knowledge base and the
(sub)goals on(b,table) and on(e,b) in the goal base.
Summarizing, and putting everything together, we obtain the part of the agent program that
species the initial mental state of the agent, see Table 3.2.
knowledge{
block(a). block(b). block(c). block(d). block(e). block(f). block(g).
clear(table).
clear(X) :- block(X), not(on(_,X)).
tower([X]) :- on(X,table).
tower([X,Y|T]) :- on(X,Y), tower([Y|T]).
}
beliefs{
on(a,b). on(b,c). on(c,table). on(d,e). on(e,table). on(f,g). on(g,table).
}
goals{
on(a,e), on(b,table), on(c,table), on(d,c), on(e,b), on(f,d), on(g,table).
}
Figure 3.2: Mental State of a Blocks World Agent That Represents Figure 3.1
46 CHAPTER 3. MENTAL STATES
Where to Put Rules?
The rule of thumb introduced is to put rules in the knowledge section. This facilitates
reasoning with background or domain knowledge in combination with both the agents
beliefs as well as its goals. Sometimes it may be undesirable, however, to combine
background knowledge with goals as it may be possible to infer goals that should not
be inferred. To give an example, although it may be perfectly reasonable to require
that the block at the top of a goal tower is clear, it is just as reasonable to not require
this. However, by inserting the rule for clear(X) in the knowledge base, the agent will
always infer that it is desired that the top of a goal tower is clear. The dierence, of
course, is that the agent would sometimes have to remove a block to achieve this goal
whereas in the absence of such goals no such action would be needed. For example, when
tower([a,b,c]) is believed to be true and the agent wants to realize tower([b,c]),
the agent would need to move a to the table in order to make sure that b is clear. If
that is not intended, it may be better to put the rule for clear in the beliefs section
instead of the knowledge section as in that case no clear goals will be inferred (only
knowledge is combined with goals).
The choice to move the rule for clear to the beliefs section prevents the inference
that clear(b) is a goal in the example where the agent wants tower([b,c]). As
the careful reader will have noted, however, this solution does not resolve the problem
completely since the cause of the problem in fact stems from the Closed World As-
sumption. Although we cannot derive clear(b) anymore by moving the rule, we can
still derive not(on(a,b)). Even stronger, we can also derive not(on( ,b)) which
expresses that there should not be any block on top of b.
3.2 Inspecting an Agents Mental State
Agents that derive their choice of action from their beliefs and goals need the ability to inspect
their mental state. In Goal, mental state conditions provide the means to do so. These conditions
are used in action rules to determine which actions the agent will consider performing (see Chapter
5).
3.2.1 Mental Atoms
A mental state condition consists of mental atoms. A mental atom either is a condition of the
belief base or on the goal base of an agent. Conditions on the belief base are of the form bel()
and conditions on the goal base are of the form goal() where is a query of the knowledge
representation language that is used (e.g. a Prolog query).
Informally, bel() means that the the agent believes that . In Goal, that is the case
when follows from the agents knowledge and beliefs. In other words, bel() holds whenever
can be derived from the content of the agents belief base in combination with the content of
the knowledge base. Continuing the example of Figure 3.2, in the initial state it follows that
bel(clear(a)). In this state, the agent thus believes that block a is clear.
Informally, goal() means that the agent has a goal that . In Goal, that is the case when
follows from one of the agents goals and its knowledge. That is, goal() holds whenever
can be derived from a single goal in the goal base of the agent in combination with the content of
the knowledge base.
7
In the example of Figure 3.2 it follows that goal(tower([e,b])). This
follows from the denition of the tower predicate in the knowledge section and the (sub)goals
on(b,table) and on(e,b) that are part of the single goal present in the goal base in Figure
3.2.
7
This reading diers from that provided in [9] where the goal operator is used to denote achievement goals. The
dierence is that a goal is an achievement goal only if the agent does not believe that . The goal operator goal
introduced here is a more basic operator. It can be used in combination with the belief operator bel to dene
achievement goals.
3.2. INSPECTING AN AGENTS MENTAL STATE 47
3.2.2 Mental State Conditions
Mental state conditions are constructed using mental atoms. Mental atoms bel() and goal()
are mental state conditions. And so are the negations not(bel()) and not(goal()) of these
mental atoms. Plain mental atoms and their negations are also called mental literals. A mental
state condition then can be dened as a conjunction of mental literals, where single mental literal
are also included. For example,
goal(on(b,table)), not(bel(on(b,table))
is a mental state condition. It expresses that the agent has a goal that block b is on the table but
does not believe that this is the case (yet). It is not allowed to use disjunction in a mental state
condition.
Although disjunction cannot be used to combine mental state conditions, intuitively a
disjunctive mental state condition of the form
1

2
would provide two dierent reasons
for selecting an action: either if
1
is the case, possibly select the action, or else possibly
select the action if
2
is the case. In such cases, multiple action rules can be used to
select an action in either of these cases. Also note that negation can be distributed over
conjunction and disjunction, and we have that (
1

2
) is equivalent to
1

2
. By
using this transformations, and the fact that instead of disjunction equivalently multiple
rules may be introduced, negation in combination with conjunction is sucient.
Goals as in the example that need to be achieved because they are not yet the case are also
called achievement goals. Achievement goals are important reasons for choosing to perform an
action. For this reason they are frequently used in Goal programs and it is useful to introduce
an additional operator a-goal() that is an abbreviation of mental state conditions of the form
goal(), not(bel()).
8
a-goal()
df
= goal(), not(bel())
Interestingly, this operator provides what is needed to express that a block is misplaced as a
block is misplaced whenever the agent believes that the blocks current position is dierent from
the position the agent wants it to be in.
9
As the position of the tower which a block is part of is ir-
relevant, the fact that a block X is not in position can be represented by a-goal(tower([X[T]))
where T is a tower. a-goal(tower([X[T])) expresses that in the goal state block X is on top of
the tower T but the agent does not believe that this is already so in the current state. The concept
of a misplaced block is important for dening a strategy to resolve a Blocks World problem, since -
assuming goal states are complete - only misplaced blocks have to be moved, and can be expressed
easily and elegantly in Goal using mental state conditions.
10
Another useful mental state condition is goal(), bel() which expresses that a (sub)goal
has been achieved. Instantiating the template with tower([X[T]), this condition expresses
that the current position of a block X corresponds with the position it has in the goal state.
11
8
See [33] for a discussion of this denition.
9
Actually, here the dierence between knowledge and belief is important as we normally would say something
is misplaced only if we know that the block is in a dierent position. That is, an agents beliefs about the blocks
position must also correspond with the actual position of the block. If, in fact, the block is in the desired position,
in ordinary language, we would say that the block is believed to be misplaced but that in fact it is not.
10
Another important concept, that of a block that is in a self-deadlock is also easily expressed by means
of the mental state condition a-goal(tower([X|T])), goal-a(above(X,Y)). The operator goal-a is de-
ned below. The rst conjunct a-goal(tower([X|T])) expresses that X is misplaced and the second conjunct
goal-a(above(X,Y)) expresses that X is above some block Y in both the current state as well as in the goal state.
This concept is just as important for solving Blocks World problems since any self-deadlocked block needs to be
moved at least twice to reach the goal state. Moving such a block to the table thus will be a necessary move in
every plan.
11
Note that it would not be possible to express this using an achievement goal operator. The goal-a operator
may be used to dene the concept of a deadlock [67]; see also the previous footnote.
48 CHAPTER 3. MENTAL STATES
In this case is a (sub)goal that is achieved and we call such a (sub)goal a goal achieved. The
operator goal-a() is introduced as an abbreviation to denote such goals.
goal-a()
df
= goal(), bel()
The condition a-goal(tower([X,Y[T])), bel(tower([Y[T]) provides another useful
example of a mental state condition. It expresses that the achievement goal to construct a tower
tower([X,Y[T])) has been realized except for the fact that block X is not yet on top of tower
[Y[T]. It is clear that whenever it is possible to move block X on top of block Y the agent would
get closer to achieving (one of) its goals. Such a move, moreover, would be a constructive move
which means that the block would never have to be moved again. As the possibility to make a
move may be veried by checking whether the precondition of the move action holds (see chapter
4), in combination with the mental state condition, we are able to verify whether a constructive
move can be made. This condition therefore is very useful to dene a strategy for solving Blocks
World problems, and will be used in the chapter 5 to dene a rule for selecting actions.
Finally, the expression not(goal(true)) may be used to verify that an agent has no goals.
This can be explained as follows: if true does not follow from any of the goals of the agent, this
means the agent cannot have any goals, since true would follow from any goal. In other words,
not(goal(true)) means that the goal base of the agent is empty.
3.3 Notes
Mental states discussed in this chapter consist of the knowledge, beliefs and goals of an agent
about its environment. An agent with such a mental state is a rst-order intentional system (cf.
Chapter 1). Such agents maintain representations of their environment but not about their own
or other agents beliefs. Of course, when other agents are part of an agents environment, the
presence of these other agents and what they do may also be represented in the mental state of
the agent. In various situations it may be useful, however, to be able to represent other agents
beliefs and goals. This would require the ability to represent other agents beliefs and goals, and
agents that are second- or higher-order intentional systems. Agents would also require some kind
of Theory of Mind, to be able to reason with their beliefs about other agents. In Chapter 7 we
will introduce the tools to represent other agents mental states.
3.4 Exercises
knowledge{
block(a). block(b). block(c). block(d). block(e).
clear(X) :- block(X), not(on(Y,X)).
clear(table).
tower([X]) :- on(X,table).
tower([X,Y|T]) :- on(X,Y), tower([Y|T]).
above(X,Y) :- on(X,Y).
above(X,Y) :- on(X,Z), above(Z,Y).
}
beliefs{
on(a,d). on(b,table). on(c,table). on(d,b). on(e,a).
}
goals{
on(a,b), on(b,c), on(c,d), on(d,table).
}
Figure 3.3: Mental State
3.4.1
3.4. EXERCISES 49
Consider the mental state in Figure 3.3. Will the following mental state conditions succeed?
Provide all possible instantiations of variables, or otherwise a conjunct that fails.
1. goal(above(X,d), tower([d,X|T]))
2. bel(above(a,X)), goal(above(a,X))
3. bel(clear(X), on(X,Y), not(Y=table)), goal(above(Z,X))
4. bel(above(X,Y), a-goal(tower([X,Y|T]))
3.4.2
As explained,
a-goal(tower([X|T))
may be used to express that block X is misplaced. A block, however, is only misplaced if it
is part of the goal state. This is not the case for block e in Figure 3.3. Block e is, however,
in the way. This means that the block prevents moving another block that is misplaced,
and therefore needs to be moved itself (in the example in Figure 3.3, we have that on(e,a)
where a is misplaced but cannot be moved without rst moving e).
Provide a mental state condition that expresses that a block X is in the way in the sense
explained, and explain why it expresses that block X is in the way. Keep in mind that the
block below X may also not be part of the goal state! Only use predicates available in Figure
3.3.
50 CHAPTER 3. MENTAL STATES
Chapter 4
Actions and Change
An underlying premise in much work addressing the design of intelligent agents or
programs is that such agents should (either implicitly or explicitly) hold beliefs about
the true state of the world. Typically, these beliefs are incomplete, for there is much an
agent will not know about its environment. In realistic settings one must also expect
an agents beliefs to be incorrect from time to time. If an agent is in a position to make
observations and detect such errors, a mechanism is required whereby the agent can
change its beliefs to incorporate new information. Finally, an agent that nds itself in a
dynamic, evolving environment (including evolution brought about by its own actions)
will be required to change its beliefs about the environment as the environment evolves.
Quote from: [12]
An agent performs actions to eect changes in its environment in order to achieve its goals.
Actions to change the environment typically can be performed only in specic circumstances and
have specic eects. The conditions which need to be true to successfully execute an action and the
way the state of the environment changes are captured by an action specication. A programmer
writing a Goal agent program needs to provide action specications for all actions that are part
of the agents action repertoire to aect the agents environment.
4.1 Action Specications
Unlike other programming languages, but similar to planners, actions that may be performed by
a Goal agent need to be specied by the programmer of that agent. Goal does provide some
special built-in actions but typically most actions that an agent may perform are made available
by the environment that the agent acts in. Actions are specied in the actionspec section of a
Goal agent. These actions are called user-dened actions. Actions are specied by specifying
the conditions when an action can be performed and the eects of performing the action. The
former are also called preconditions and the latter are also called postconditions. The actionspec
section in a Goal agent program consists of a set of STRIPS-style specications [44] of the form:
actionname{
pre{precondition}
post{postcondition}
}
The action species the name of the action and its arguments or parameters and is of the
form name[args], where name denotes the name of the action and the [args] part denotes an
optional list of parameters of the form (t
1
, ..., t
n
), where the t
i
are terms. The parameters
51
52 CHAPTER 4. ACTIONS AND CHANGE
of an action may contain free variables which are instantiated at runtime. Actions without any
parameters consist of a name only without brackets. One of the most simple action specications
is the following:
skip{
{ true }
{ true }
}
This action specication species the action skip without parameters that can always be per-
formed and has no eect. The true precondition indicates that skip can always be performed,
whereas the true postcondition indicates that the action has no eect. It would also have been
possible to simply write an empty pre- and postconditions ; in other words, there is no need to
write true explicitly.
If an agent is connected to an environment, user-dened actions will be sent to the environment
for execution. In that case it is important that the name of an action corresponds with the name
the environment expects to receive when it is requested to perform the action.
Continuing the Blocks World example introduced in Chapter 3, we will now describe the robot
gripper that enables the agent that controls this gripper to pick up and move blocks. The robot
gripper can pick up at most one block at a time. It thus is not able to pick up one (let alone more)
stack of blocks. As is common in the simplied version of the Blocks World, we abstract from all
physical aspects of robot grippers. In its most abstract form, the gripper in the Blocks World is
modeled as a robot arm that can perform the single action of picking up and moving one block to
a new destination in one go. That is, the picking up and moving are taken as a single action that
can be performed instantaneously. This action can be specied in Goal as follows:
actionspec{
move(X,Y) {
pre{ clear(X), clear(Y), on(X,Z), not(X=Y) }
post{ not(on(X,Z)), on(X,Y) }
}
}
The actionspec keyword indicates the beginning of the action specication section in a
Goalagent. In the code fragment above the single action move(X,Y) has been specied.
Multiple Action Specications for One and the Same Action
Goal allows multiple action specications for the same action. Providing multiple
action specications for one and the same action may be useful to distinguish cases.
For example, in the wumpus environment [62], the agent may turn either left or right.
The turn action does not have any preconditions and is always enabled. Of course, the
eects of turning left or right are dierent. An easy way to dierentiate these cases is
to provide two action specications for the turn action as follows:
actionspec{
turn(X) {
pre{ X=left, ori(Ori), leftOri(OriNew) }
post{ not(ori(Ori)), ori(OriNew) }
}
turn(X) {
pre{ X=right, ori(Ori), rightOri(OriNew) }
post{ not(ori(Ori)), ori(OriNew) }
}
}
Note that even though the turn action can always be performed the preconditions in
the action specications are not empty. To be able to specify the eects of the action, the
new orientation is computed by means of the leftOri and the rightOri predicates.
It also is possible to instantiate the variable parameter of the turn action. In other
words, writing turn(left) instead of turn(X) would have been ok, which would also
allow for removing the conditions X=left and X=right from the preconditions.
4.1. ACTION SPECIFICATIONS 53
4.1.1 Preconditions
The keyword pre indicates that what follows is a precondition of the action. Preconditions are
queries of the knowledge representation language that is used (e.g. a Prolog query). Preconditions
are used to verify whether it is possible to perform an action. A precondition is evaluated by
verifying whether can be derived from the belief base (as always, in combination with knowledge
in the knowledge base). Free variables in a precondition may be instantiated during this process
just like executing a Prolog program returns instantiations of variables. An action is said to be
enabled whenever its precondition is believed to be the case by the agent.
1
The precondition for the move action species that in order to be able to perform action
move(X,Y) of moving X on top of Y both X and Y have to be clear. The condition not(X=Y)
expresses that it is not possible to move a block or the table on top of itself.
The condition on(X,Z) in the precondition does not specify a condition that needs to be
true in order to be able to perform the move action in the environment. The condition checks
on top of what Z block X currently is located. It retrieves in variable Z the thing, i.e. block or
table, that block X is currently on. The reason for including this condition in the precondition is
that it is needed to be able to specify the eects of the move action. After moving block X the
block obviously no longer is where it was before. This fact about X thus must be removed after
performing the action, which only is possible if the current fact is retrieved from the agents belief
base rst.
It is best practice to include in the precondition of an action specication only those conditions
that are required for the successful execution of an action. These conditions include conditions
that are needed to specify the eects of an action as the on(X,Z) atom in the specication of the
move action. In other words, a precondition should only include conditions that need to hold in
order to be able to successfully perform the action. Conditions such as, for example, conditions
that specify when it is a good idea to choose to perform the action should be specied in the
program section of the agent. These are strategic considerations and not strictly required for
the successful execution of action. Including such conditions would prevent an action from being
selected even when the action could be successfully executed in the environment.
2
Preconditions do not always need to include all conditions that are required for the successful
execution of an action. Although it is good practice to provide complete action specications,
sometimes there are pragmatic reasons for not providing all required preconditions. For example,
the precondition for the move action does not require that X is a block. Strictly speaking, the
precondition including the condition block(X) would result in a better match with constraints in
the Blocks World because only blocks can be moved in this environment. Adding the block(X)
condition would have resulted in a more complete action specication. However, when eciency
is considered as well, it makes sense to provide a precondition that checks as few conditions as
possible. It may also be that a precondition is better readable when not all details are included.
We thus may trade o completeness of an action specication for eciency and readability. A
programmer should always verify, however, that by not including some of the actual preconditions
of an action the program still operates as expected. As we will see in Chapter 5, the mental
state conditions of an action rule that provide the reason for selecting a move action prevent
variable X from ever being instantiated with table. Dropping the condition block(X) from the
precondition therefore does not do any harm.
Another illustration of a condition that is not included in the precondition of the move action
is related to specic moves that are redundant. The precondition of the move action does not
require that Y, the place to move X onto, is dierent from Z, the thing X stands on top of (retrieved
by the on(X,Z) atom). In this case, there is nothing really lacking in the precondition, but the
1
Note that because an agent may have false beliefs the action may not actually be enabled in the environment.
An agent does not have direct access to environments. Instead it needs to rely on its beliefs about the environment
to select actions. From the perspective of an agent an action thus is enabled if it believes it is.
2
Because a precondition is checked against the beliefs of an agent it may not actually be the case that an action
can be performed successfully. Still a precondition should specify those conditions that would guarantee successfull
execution. In that case, since an agent does not have direct access to the environment, for all the agent knows, the
action can be performed successfully if it believes the precondition to be true.
54 CHAPTER 4. ACTIONS AND CHANGE
condition may be added to prevent particular redundant moves. As the precondition does require
that Y is clear, whenever we have that both on(X,Z) and Y=Z it must be the case that Y is equal
to the table. We thus would have that a move of X onto the table is performed whereas block
X already is on the table. Clearly, performing such a move is redundant. For this reason, although
not strictly required, we might decide to add the condition not(Y=Z).
Actions are enabled when their preconditions hold. But there is one additional general condi-
tion that must be fullled before an action is enabled: All variables that occur in the parameters
of the action and in the postcondition must be instantiated to ensure the action and its eects are
well-specied. That is, all free variables in parameters of an action as well as in the postcondition
of the action must have been instantiated with ground terms. This is also the case for built-in
actions. For the move action specied above, this implies that all the variables X, Y, and Z need
to be instantiated with ground terms that refer either to a block or to the table.
Completely Instantiated Actions
The reason that the variables that occur in an actions parameters or in its postcon-
dition must be instantiated with ground terms is that otherwise it is not clear what it
means to execute the action. What, for example, does it mean to perform the action
move(X,table) with X a variable? One option would be to select a random item and
try to move that. Another would be to try and move all items. But shouldnt we exclude
tables? We know intuitively that the move action moves blocks only. But how would
the agent program know this?
[62] requires that all variables in the precondition also appear in the parameters of the
action. This requires that instead of the move(Block,To) action specied above an
action moveFromTo(Block,From,To) must be specied as the From variable needs
to included in the actions parameters. This restriction is lifted in Goal and no such
constraints apply. As mentioned, in order to ensure an actions postcondition is closed,
all variables that occur in the postcondition must also occur in either the precondition
or the actions parameters. Note that any variables in action parameters that do not
occur in the precondition must be instantiated by other means before the action can
be performed; in a Goal agent program this can be done by means of mental state
conditions.
4.1.2 Postconditions
The keyword post indicates that what follows is a postcondition of the action. Postconditions
are conjunctions of literals (Prolog literals when Prolog is used as the knowledge representation
language). A postcondition species the eect of an action. In Goal, eects of an action are
changes to the mental state of an agent. The eect of an action is used to update the beliefs
of the agent to ensure the agent believes after performing the action. In line with STRIPS
terminology, a postcondition is also called an add/delete list (see also [27, 44]). Positive literals
in a postcondition are said to be part of the add list whereas negative literals not() are said
to be part of the delete list. The eect of performing an action is that it updates the belief base
by rst removing all facts present in the delete list and thereafter adding all facts present in the
add list. Finally, as an action can only be performed when all free variables in the postcondition
have been instantiated, each variable present in a postcondition must also be present in the action
parameters or precondition of the action.
4.1. ACTION SPECIFICATIONS 55
Closed World Assumption (Continued)
The STRIPS approach to updating the state of an agent after performing an action
makes the Closed World Assumption. It assumes that the database of beliefs of the
agent consists of positive facts only. Negative information is inferred by means of the
Closed World Assumption (or, more precisely, negation as failure in the case we use Pro-
log). Negative literals in the postcondition are taken as instructions to remove positive
information that is present in the belief base. The action language ADL does not make
the Closed World Assumption and allows to add negative literals to an agents belief
base [62].
The postcondition not(on(X,Z)), on(X,Y) in the action specication for move(X,Y)
consists of one negative and one positive literal. The add list in this case thus consists of a single
atom on(X,Y) and the delete list consists of the atom on(X,Z). It is important to remember
that all variables must have been instantiated when performing an action and that both on(X,Y)
and on(X,Z) are only templates. Upon performing the action, the immediate eect of executing
the action is to update the agents mental state by rst removing all atoms on the delete list and
thereafter adding all atoms on the add list. For the move action this means that the current
position on(X,Z) of block X is removed from the belief base and thereafter the new position
on(X,Y) is added to it.
Inconsistent Postconditions
A remark is in order here because, as discussed above, it may be the case that Z is equal
to Y. In that case the postcondition would be of the form not(on(X,Y)), on(X,Y)
where Y is substituted for Z. This postcondition is a contradiction and, from a logical
point of view, can never be established. However, though logically invalid, nothing would
go wrong when a move action where Y and Z are equal (Y = Z = table) would be
executed. The reason is that the STRIPS semantics for updating the beliefs of an agent
given the postcondition is a procedural semantics. The procedure for updating proceeds
in steps, which, in this case, would rst delete on(X,Y) from the belief base if present,
and thereafter would add on(X,Y) (again, if initally present already, and nothing would
have changed). Although this procedural semantics prevents acute problems that might
arise because of contradictory postconditions, it is most of the time considered best
practice to prevent such situations from arising in the rst place. This therefore provides
another reason for adding not(Y=Z) to the precondition.
4.1.3 Updating an Agents Goals
Performing an action may also aect the goal base of an agent. As a rational agent should not
invest resources such as energy or time into achieving a goal that has been realized, such goals
are removed from the goal base. That is, goals in the goal base that have been achieved as a
result of performing an action are removed. Goals are removed from the goal base, however, only
if they have been completely achieved. The idea here is that a goal in the goal base is achieved
only when all of its subgoals are achieved. An agent should not drop any of these subgoals before
achieving the overall goal as this would make it impossible for the agent to ensure the overall goal
is achieved at a single moment in time. The fact that a goal is only removed when it has been
achieved implements a so-called blind commitment strategy [60]. Agents should be committed to
achieving their goals and should not drop goals without reason. The default strategy for dropping
a goal in Goal is rather strict: only do this when the goal has been completely achieved. This
default strategy can be adapted by the programmer for particular goals by using the built-in drop
action.
For example, a state with belief base and goal base with the following content is rational:
beliefs{
on(b,c). on(c, table).
}
56 CHAPTER 4. ACTIONS AND CHANGE
goals{
on(a,b), on(b,c), on(c, table).
}
but after successfully performing the action move(a,b) in this state, the following state would
result if we would not remove goals automatically:
beliefs{
on(a,b). on(b,c). on(c, table).
}
goals{
on(a,b), on(b,c), on(c, table).
}
This belief state in combination with the goal state is not rational. The point is that the goal
has been achieved and, for this reason, should be removed as a rational agent would not invest any
resources in it. Goal implements this rationality constraint and automatically removes achieved
goals, resulting in our example case in a state with an empty goal base:
beliefs{
on(a,b). on(b,c). on(c, table).
}
goals{
}
4.2 Built-in Actions
In addition to the possibility of specifying user-dened actions, Goal provides several built-in
actions for changing the beliefs and goals of an agent, and for communicating with other agents.
Here we discuss the built-in actions for modifying an agents mental state. The send action for
communicating a message to another agent is discussed in Chapter 7. There are four built-in
actions to modify an agents mental state.
We rst discuss the actions for changing the agents goal base. The action:
adopt()
is the built-in adopt action for adopting a new goal. The precondition of this action is that
the agent does not believe that is the case, i.e. in order to execute adopt() we must have
not(bel()). The idea is that it would not be rational to adopt a goal that has already been
achieved. The eect of the action is the addition of as a single, new goal to the goal base. We
remark here that the goal base consists of conjunctions of positive literals only. As a consequence,
the action adopt(not(posliteral)) does not insert a goal not(posliteral) in the goal
base. Note that this action also does not remove posliteral from the goal base; for removing
a goal the drop(posliteral) action should be used.
The action:
drop()
is the built-in drop action for dropping current goals of an agent. The precondition of this action
is always true and the action can always be performed. The eect of the action is that any goal in
the goal base from which can be derived is removed from the goal base. For example, the action
drop(on(a,e)) would remove all goals in the goal base that entail on(a,e); in the example
agent of Figure 3.2 the only goal present in the goal base would be removed by this action.
We now turn to actions to change the belief base of an agent. The action:
4.2. BUILT-IN ACTIONS 57
insert()
is the built-in insert action for inserting into the agents beliefs. In the case that Prolog is
used as a knowledge representation language, must be a conjunction of literals. The semantics
of insert in this case is similar to the update associated with the postcondition of an action.
The insert action adds all positive literals that are part of to the belief base of the agent
and removes all negative literals from the belief base. For example, insert(not(on(a,b)),
on(a,table)) removes the literal on(a,b) from the belief base and adds the positive literal
on(a,table). The insert() action modies the belief base such that follows from the belief
base, whenever it is possible to modify the belief base in such a way.
Note that the goal base may be modied as well if due to such changes the agent would come
to believe that one of its goals has been completely achieved; in that case, the goal is removed
from the goal base, as discussed above.
Finally, the action:
delete()
is the built-in delete action for removing from the agents beliefs. The delete action is kind
of the inverse of the insert action. Instead of adding literals that occur positively in it removes
such literals, and, instead of removing negative literals it adds such literals.
The delete action does not add expressivity, but it does enhance readability of a program. We
consider it best practice to only use insert to add positive literals and only use delete to remove
positive literals. Instead of writing insert(not(on(a,b)), on(a,table)) it is better to
use the two actions insert(on(a,table)) and delete(on(a,b)). Multiple actions can be
combined into a single, complex action by the + operator. Using this operator we can write:
insert(on(a,table)) + delete(on(a,b))
which would have exactly the same eect as the single action insert(not(on(a,b)), on(a,table)).
The + operator can be used to combine as many actions as needed into a single, complex action,
as long as it respects the requirement that at most one user-dened action is included in the list
of actions combined by +. The actions combined by + are executed in order of appearance (see
also Section 5.5).
Inserting Versus Deleting
If Prolog is used as the knowledge representation, the eects of the insert action are in
fact the same as the update associated with the postcondition according to the STRIPS
semantics. And, because a Closed World Assumption is made, in eect, inserting
negative information is the same as deleting positive information. It thus would be
possible to program all intended changes to the belief base by means of the insert
action only.
One thing to note about the delete() action is that it removes all positive literals
that occur in . The delete action does not support minimal change in the sense that
as little information is removed to ensure that is not believed anymore. For example,
delete(p, q) removes both p and q instead of only removing either p or q which
would be sucient to remove the belief that p and q both are true.
Finally, like all other actions, built-in actions must be closed when executed. That is, all
variables must have been instantiated. This is also true for actions combined by the + operator.
58 CHAPTER 4. ACTIONS AND CHANGE
4.3 Notes
The strategy for updating an agents goals in Goal is a blind commitment strategy. Using this
strategy, an agent only drops a goal when it believes the goal has been achieved. In [60] and [17]
various other strategies are introduced. One issue with an agent that uses a blind commitment
strategy is that such an agent rather fanatically commits to a goal. It would be more rational if
an agent would also drop a goal if it would come to believe the goal is no longer achievable. For
example, an agent may drop a goal to get to a meeting before 3PM if it misses the train. However,
providing automatic support for removing such goals when certain facts like missing a train are
believed by the agent is far from trivial. Goal provides the drop action which can be used to
remove goals by writing action rules with such actions as conclusions.
4.4. EXERCISES 59
4.4 Exercises
main: towerBuilder{
knowledge{
block(a). block(b). block(c). block(d). block(e). block(f).
clear(table).
clear(X) :- block(X), not(on(Y,X)), not(holding(X)).
above(X,Y) :- on(X,Y).
above(X,Y) :- on(X,Z), above(Z,Y).
tower([X]) :- on(X,table).
tower([X,Y|T]) :- on(X,Y), tower([Y|T]).
}
beliefs{
on(a,table). on(b,c). on(c,table). on(d,e). on(e,f). on(f,table).
}
goals{
on(a,table), on(b,a), on(c,b), on(e,table), on(f,e).
}
program{
% pick up a block that needs moving
if a-goal(tower([X|T])), bel((above(Z,X);Z=X)) then pickup(Z).
% constructive move
if a-goal(tower([X,Y|T])), bel(tower([Y|T])) then putdown(X,Y).
% put block on table
if bel(holding(X)) then putdown(X,table).
}
actionspec{
pickup(X){
pre{ }
post{ }
}
putdown(X,Y){
pre{ }
post{ }
}
}
}
Figure 4.1: Incomplete Blocks World Agent Program
4.4.1
Consider the incomplete agent program for a Blocks World agent in Figure 4.1. Suppose
that the agents gripper can hold one block at a time, only clear blocks can be picked up,
and blocks can only be put down on an empty spot. Taking these constraints into account,
provide a full action specication for:
1. pickup(X).
2. putdown(X,Y).
60 CHAPTER 4. ACTIONS AND CHANGE
Chapter 5
GOAL Agent Programs
This chapter provides an introduction to writing a Goal agent. The Goal language is introduced
by means of an example that illustrates what a Goal agent program looks like. The example of
the Blocks World introduced in Chapter 3 will be used again for this purpose. We like to think of
the Blocks World as the hello world example of agent programming (see also [67]). It is both
simple and rich enough to demonstrate various of the available programming constructs in Goal.
5.1 The Structure of an Agent Program
A Goal agent decides which action to perform next based on its beliefs and goals. As discussed
in Chapter 3, the knowledge, beliefs and goals of an agent make up its mental state. A Goal
agent inspects and modies this state at runtime similar to a Java method which operates on the
state of an object. Agent programming in Goal therefore can also be viewed as programming
with mental states.
In a Blocks World the decision amounts to where to move a block, in a robotics domain
it might be where to move to or whether to pick up something with a gripper or not. Such
a decision typically depends on the current state of the agents environment as well as general
knowledge about this environment. In the Blocks World an agent needs to know what the current
conguration of blocks is and needs to have basic knowledge about such congurations, such as
what a tower of blocks is, to make a good decision. The former type of knowledge is typically
dynamic and changes over time, whereas the latter typically is static and does not change over
time. In line with this distinction, in Goal two types of knowledge of an agent are distinguished:
conceptual or domain knowledge stored in a knowledge base and beliefs about the current state of
the environment stored in a belief base.
A decision to act will usually also depend on the goals of the agent. In the Blocks World, a
decision to move a block on top of an existing tower of blocks would be made, for example, if it
is a goal of the agent to have the block on top of that tower. In a robotics domain it might be
that the robot has a goal to bring a package somewhere and therefore picks it up. Goals of an
agent are stored in a goal base. The goals of an agent may change over time, for example, when
the agent adopts a new goal or drops one of its goals.
As a rational agent should not pursue goals that it already believes to be achieved, such goals
need to be removed. Goal provides a built-in mechanism for doing so based on a so-called blind
commitment strategy.
To select an action, a Goal agent needs to be able to inspect its knowledge, beliefs and goals.
An action may or may not be selected if certain things follow from an agents mental state. For
example, if a block is misplaced, that is, the current position of the block does not correspond
with the agents goals, the agent may decide to move it to the table. A Goal programmer needs
to write special conditions called mental state conditions that were introduced in Chapter 3 in
order to verify whether the appropriate conditions for selecting an action are met. In essence,
61
62 CHAPTER 5. GOAL AGENT PROGRAMS
writing such conditions means specifying a strategy for action selection that will be used by the
Goal agent. Such a strategy is coded in Goal by means of action rules which dene when an
action may or may not be selected.
After selecting an action, an agent needs to perform the action. Performing an action in
Goal means changing the agents mental state. An action to move a block, for example, will
change the agents beliefs about the current position of the block. The eects of an action on
the mental state of an agent need to be specied explicitly in a Goal agent program by the
programmer except for a few built-in actions. As discussed in Chapter 4, the conditions when
an action can be performed, i.e. its preconditions, and the eects of performing the action, i.e.
its postcondition), need to be specied. Whether or not a real (or simulated) block will also be
moved in an (simulated) environment depends on whether the Goal agent has been adequately
connected to such an environment. Percepts received from an environment can be used to verify
this. Goal provides so-called percept rules to process received percepts and update an agents
mental state.
Goal Agent Program
A basic Goal agent program consists of six sections:
knowledge base: a set of concept denitions or domain rules, which is optional and
represents the conceptual or domain knowledge the agent has about its environ-
ment, collectively called the knowledge base,
belief base: a set of beliefs, representing the current state of aairs, collectively called
the belief base,
goal base: a set of goals, representing in what state the agent wants to be called the
goal base,
program section: a set of action rules, that dene a strategy or policy for action
selection,
action specication: a specication of the conditions for each action available to the
agent of when an action can be performed (its precondition) and the eects of
performing an action (its postcondition), and
percept rules: a set of percept rules, which specify how percepts received from the
environment modify the agents mental state.
To avoid confusion of the program section with the agent program itself, from now on, the
agent program will simply be called agent. The term agent thus will be used both to refer to the
program text itself as well as to the execution of such a program, i.e. the running process. This
allows us to say that an agent consists of various program sections (rst sense) as well as that an
agent performs actions (second sense). It should be clear from the context which of the two senses
is intended.
An Extended Backus-Naur Form syntax denition (cf. [64]) of a Goal agent program is
provided in Table 5.1.
Remarks on Prolog Syntax
Do not use nested negations, i.e. not(not(...)) in a program, this is bad practice and
will produce an error when present in a postcondition of an action. Also do not include
negations of Prolog predened symbols such as not(member(...)) in a postcondition
of an action as this will modify the meaning of the symbol.
One additional remark needs to be made concerning the specication of the syntax of
conjunctions (poslitconj and litconj ) in an agent program: Certain operators require
additional brackets when used in a conjunction. More specically, the operators ,, ;,
->, :-, ?-, and --> can only be used with additional brackets.
5.1. THE STRUCTURE OF AN AGENT PROGRAM 63
program ::= main: id {
[knowledge { kr-module }]
beliefs { kr-module}
goals { poslitconj

}
program[options] {
macro
+
actionrule
+
}
action-spec {actionspec
+
}
[perceptrules {perceptrule
+
}]
}
kr-module ::= a legal kr module (e.g. a Prolog program)
poslitconj ::= atom , atom

.
litconj ::= literal , literal

.
literal ::= atom [ not(atom)
atom ::= predicate[parameters]
parameters ::= (term ,term

)
term ::= a legal term in the kr language
options ::= [ option ]
option ::= linear=order [ linear=random
macro ::= #dene id[parameters] mentalstatecond .
actionrule ::= if mentalstatecond then actioncombo .
mentalstatecond ::= mentalliteral , mentalliteral

mentalliteral ::= true [ mentalatom [ not( mentalatom )

mentalatom ::= bel ( litconj ) [ goal ( litconj )
actionspec ::= action { pre{litconj } post{litconj } }
perceptrule ::= if mentalstatecond then actioncombo .
actioncombo ::= action + action

action ::= user-def action [ built-in action [ communication

user-def action ::= id[parameters]
built-in action ::= insert( litconj ) [ delete( litconj ) [
adopt( poslitconj ) [ drop( litconj )
communication ::= send( id , poslitconj )
id ::= (a..z [ A..Z [ [ $) (a..z [ A..Z [ [ 0..9 [ $)

Boldface is used to indicate terminal symbols, i.e. symbols that are part of an actual program.
Italic is used to indicate nonterminal symbols. [...] is used to indicate that ... is optional, | is
used to indicate a choice, and

and
+
denote zero or more repetitions or one or more repeti-
tions of a symbol, respectively. The nonterminal kr-module refers to a module in a knowledge
representation language (e.g. a Prolog program, where details depend on the specic Prolog
system used; the current implementation of Goal uses SWI-Prolog [69]. See Appendix A for
additional comments on SWI Prolog operators available in Goal).
Table 5.1: Extended Backus Naur Syntax Denition
64 CHAPTER 5. GOAL AGENT PROGRAMS
5.2 A Hello World Example: The Blocks World
In order to explain how a Goal agent works, we will design an agent that is able to eectively
solve Blocks World problems. To this end, we now somewhat more precisely summarize the Blocks
World domain (see also Chapter 3). The Blocks World is a simple environment that consists of
a nite number of blocks that are stacked into towers on a table of unlimited size. It is assumed
that each block has a unique label or name a, b, c, .... Labelling blocks is useful because it allows
us to identify a block uniquely by its name. This is much simpler than having to identify a block
by means of its position with respect to other blocks, for example. Typically, labels of blocks are
used to specify the current as well as goal congurations of blocks, a convention that we will also
use here. Observe that in that case labels dene a unique feature of each block and they cannot be
used interchangeably as would have been the case if only the color of a block would be a relevant
feature in any (goal) conguration. In addition, blocks need to obey the following laws of the
Blocks World: (i) a block is either on top of another block or it is located somewhere on the table;
(ii) a block can be directly on top of at most one other block; and, (iii) there is at most one block
directly on top of any other block (cf. [18]).
1
Although the Blocks World domain denes a rather
simple environment it is suciently rich to illustrate various features of Goal and to demonstrate
that Goal allows to program simple and elegant agent programs to solve such problems.
To solve a Blocks World problem involves deciding which actions to perform to transform an
initial state or conguration of towers into a goal conguration, where the exact positioning of
towers on the table is irrelevant. A Blocks World problem thus denes an action selection problem
which is useful to illustrate the action selection mechanism of Goal. See Figure 3.1 for an example
problem. Here we assume that the only action available to the agent is the action of moving one
block that is on top of a tower onto the top of another tower or to the table (see also Chapter 4).
A block on top of a tower, that is, a block without any block on top of it, is said to be clear. As
there is always room to move a block onto the table, the table is also said to be clear.
The performance of a Blocks World agent can be measured by means of the number of moves it
needs to transform an initial state or conguration into a goal state. An agent performs optimally
if it is not possible to improve on the number of moves it uses to reach a goal state.
2
Some basic
insights that help solving a Blocks World problem and that are used below in the design of an
agent that can solve such problems are briey introduced next. A block is said to be in position
if the block in the current state is on top of a block or on the table and this corresponds with the
goal state, and all blocks (if any) below it are also in position. A block that is not in position is
said to be misplaced. In Figure 3.1 all blocks except block c and g are misplaced. Observe that
only misplaced blocks have to be moved in order to solve a Blocks World problem. The action of
moving a block is called constructive if in the resulting state that block is in position. It should be
noted that in a Blocks World where the table has unlimited size in order to reach the goal state it
is only useful to move a block onto another block if the move is constructive, that is, if the move
puts the block in position. Also observe that a constructive move always decreases the number of
misplaced blocks.
3
A block is said to be a self-deadlock if it is misplaced and above another block
which it is also above in the goal state; for example, block a is a self-deadlock in Figure 3.1. The
concept of self-deadlocks, also called singleton deadlocks, is important because on average nearly
40% of the blocks are self-deadlocks [67].
1
For other, somewhat more realistic presentations of this domain that consider e.g., limited table size, and
varying sizes of blocks, see e.g. [31]. Note that we also abstract from the fact that a block is hold by the gripper
when it is being moved; i.e., the move action is modeled as an instantaneous move.
2
The problem of nding a minimal number of moves to a goal state is also called the optimal Blocks World
problem. This problem is NP-hard [31]. It is not within the scope of this chapter to discuss either the complexity
or heuristics proposed to obtain near-optimal behavior in the Blocks World; see [34] for an approach to dene such
heuristics in Goal.
3
It is not always possible to make a constructive move, which explains why it is sometimes hard to solve a
Blocks World problem optimally. In that case the state of the Blocks World is said to be in a deadlock, see [67] for
a detailed explanation.
5.3. SELECTING ACTIONS: ACTION RULES 65
Code listing
1 main: BlocksWorldAgent
2 { % This agent solves the Blocks World problem of Figure 1.
3 knowledge{
4 block(a). block(b). block(c). block(d). block(e). block(f). block(g).
5 clear(table).
6 clear(X) :- block(X), not(on(_,X)).
7 tower([X]) :- on(X,table).
8 tower([X,Y|T]) :- on(X,Y), tower([Y|T]).
9 }
10 beliefs{
11 on(a,b). on(b,c). on(c,table). on(d,e). on(e,table). on(f,g). on(g,table).
12 }
13 goals{
14 on(a,e), on(b,table), on(c,table), on(d,c), on(e,b), on(f,d), on(g,table).
15 }
16 program{
17 if a-goal(tower([X,Y|T])), bel(tower([Y|T])) then move(X,Y).
18 if a-goal(tower([X|T])) then move(X,table).
19 }
20 actionspec{
21 move(X,Y) {
22 pre{ clear(X), clear(Y), on(X,Z), not(X=Y) }
23 post{ not(on(X,Z)), on(X,Y) }
24 }
25 }
26 }
Table 5.2: Goal Agent Program for solving the Blocks World Problem of Figure 3.1.
5.3 Selecting Actions: Action Rules
The program section species the strategy used by the agent to select an action to perform by
means of action rules. Action rules provide a Goal agent with the know-how that informs it
when it is opportune to perform an action. In line with the fact that Goal agents derive their
choice of action from their beliefs and goals, action rules consist of a mental state condition msc
and an action action and are of the form if msc then action. The mental state condition in an
action rule determines whether the corresponding action may be considered for execution or not.
If (an instantiation of) a mental state condition is true, the corresponding action is said to be
applicable. Of course, the action may only be executed if it is also enabled. If an action is both
applicable and enabled we say that it is an option. We also say that action rules generate options.
The program section of Table 5.2 consists of two action rules. These rules specify a simple
strategy for solving a Blocks World problem. The rule
if a-goal(tower([X,Y[T])), bel(tower([Y[T])) then move(X,Y)
species that move(X,Y) may be considered for execution whenever move(X,Y) is a construc-
tive move (cf. the discussion about the mental state condition of this rule in Chapter 3). The rule
if a-goal(tower([X[T])) then move(X,table) species that the action move(X,table)
of moving block X to the table may be considered for execution if the block is misplaced. As
these are all the rules, the agent will only generate options that are constructive moves or move
misplaced blocks to the table, and the reader is invited to verify that the agent will never consider
moving a block that is in position. Furthermore, observe that the mental state condition of the
second rule is weaker than the rst. In common expert systems terminology, the rst rule subsumes
the second as it is more specic.
4
This implies that whenever a constructive move move(X,Y)
is an option the action move(X,table) is also an option. The set of options generated by the
action rules thus may consist of more than one action. In that case, Goal arbitrarily selects one
action out of the set of all options. As a result, a Goal agent is nondeterministic and may execute
dierently each time it is run.
4
Thanks to Jorg M uller for pointing this out.
66 CHAPTER 5. GOAL AGENT PROGRAMS
A set of action rules is similar to a policy. There are two dierences with standard denitions
of a policy in the planning literature, however [27]. First, action rules do not need to generate
options for each possible state. Second, action rules may generate multiple options in a particular
state and do not necessarily dene a function from the (mental) state of an agent to an action. In
other words, a strategy of a Goal agent dened by its action rules does not need to be universal
and may underspecify the choice of action of an agent.
5
5
Universal in the sense of [63], where a universal plan (or policy) species the appropriate action for every
possible state.
5.3. SELECTING ACTIONS: ACTION RULES 67
Execution Traces of The Blocks World Agent
We will trace one particular execution of the Blocks World agent of Table 5.2 in more detail
here. As a Goal agent selects an arbitrary action when there are more options available, there
are multiple traces that may be generated by the agent, three of which are listed below.
In the initial state, depicted also in Figure 3.1, the agent can move each of the clear blocks a,
d, and f to the table. Although the the applicability of mental state conditions in a rule is
evaluated rst, we begin by inspecting the precondition of the move action to check whether
the action is enabled. It is easy to verify the precondition of the move action in each of
these cases by instantiating the action specication of the move action and inspecting the
knowledge and belief bases. For example, instantiating move(X,Y) with block a for variable X
and table for variable Y gives the corresponding precondition clear(a), clear(table),
on(a,Z), not(a=table). By inspection of the knowledge and belief bases, it immediately
follows that clear(table), and we nd that by instantiating variable Z with b it follows that
on(a,Z). Using the rule for clear it also follows that clear(a) and we conclude that action
move(a,table) is enabled. Similar reasoning shows that the actions move(d,table),
move(f,table), move(a,d), move(a,f), move(d,a), move(d,f), move(f,d),
move(f,a) are enabled as well. The reader is invited to check that no other actions are enabled.
A Goal agent selects an action using its action rules. In order to verify whether moving
the blocks a, d, and f to the table are options we need to verify applicability of actions
by checking the mental state conditions of action rules that may generate these actions.
We will do so for block a here but the other cases are similar. Both rules in the program
section of Table 5.2 can be instantiated such that the action of the rule matches with
move(a,table). As we know that block a cannot be moved constructively, however, and the
mental state condition of the rst rule only allows the selection of such constructive moves,
this rule is not applicable. The mental state condition of the second rule expresses that a
block X is misplaced. As block a clearly is misplaced, this rule is applicable. The reader is
invited to verify this by checking that a-goal([a,e,b]) holds in the initial state of the agent.
Assuming that move(a,table) is selected from the set of options, the action is exe-
cuted by updating the belief base with the instantiated postcondition not(on(a,b)),
on(a,table). This means that the fact on(a,b) is removed from the belief base and
on(a,table) is added. The goal base may need to be updated also when one of the goals has
been completely achieved, which is not the case here. As in our example, we have abstracted
from perceptions, there is no need to process any and we can repeat the action selection process
again to select the next action.
As all blocks except for blocks c and g are misplaced, similar reasoning would result in a pos-
sible trace where consecutively move(b,table), move(d,table), move(f,table) are
executed. At that point in time, all blocks are on the table, and the rst rule of the program
can be applied to build the goal conguration, e.g. by executing move(e,b), move(a,e),
move(d,c), move(f,d). In this particular trace the goal state would be reached after per-
forming 8 actions.
Additionally, we list the 3 shortest traces - each including 6 actions - that can be generated by
the Blocks World agent to reach the goal state:
Trace1 : move(a, table), move(b, table), move(d, c), move(f, d), move(e, b), move(a, e).
Trace2 : move(a, table), move(b, table), move(d, c), move(e, b), move(f, d), move(a, e).
Trace3 : move(a, table), move(b, table), move(d, c), move(e, b), move(a, e), move(f, d).
There are many more possible traces, e.g. by starting with moving block f to the table, all of
which consist of more than 6 actions.
To conclude the discussion of the example Blocks World agent, in Figure 5.1 the RSG line
shows the average performance of the Goal agent in number of moves relative to the number
of blocks present in a Blocks World problem. This performance is somewhat better than the
68 CHAPTER 5. GOAL AGENT PROGRAMS
US
RSG
20 40 60 80 100 120
1.00
1.05
1.10
1.15
1.20
number of blocks
1.25
1.30
1.35
1.40
p
e
r
f
o
r
m
a
n
c
e
Figure 5.1: Average Performance of a Blocks World Goal Agent
performance of the simple strategy of rst moving all blocks to the table and then restacking
the blocks to realize the goal state indicated by the US line
6
as the Goal agent may perform
constructive moves whenever this is possible and not only after moving all blocks to the table
rst.
5.4 Rule Order
The default selection of action options chooses randomly out of the available options. That is, if
more than one rule is applicable and the associated actions are enabled, then randomly one of these
actions is selected. Also, if one rule generates multiple action options, one of those is randomly
selected. For example, the Blocks World agent of Table 5.2 may perform either move(a,table),
move(d,table) or move(f,table) and by default one of these is randomly chosen.
As noted above, whenever a constructive move can be made in the Blocks World, it is always
a good idea to prefer such moves over others. There is a simple mechanism that can be used to
make sure that such moves are chosen whenever there is one available. Goal provides an option
associated with the program section to evaluate rules in (linear) order. Setting this option can
be done simply by adding [order=linear] after the program section keyword. (There is also
the option to set [order=random] but there is no need to add this as this is default behavior.)
The agent in Table 5.3 is a slightly modied agent compared to that of Table 5.2. Apart
from the fact that this agent handles only three blocks, it also has the option [order=linear].
The behavior of this agent will be to always perform an action that is generated by the rst rule
if possible. As the action move(b,c) and action move(b,table) both are enabled but only
the rst is a constructive move and therefore an option by the rst rule, the constructive action
move(b,c) will be selected for execution. Without the [order=linear] option either one of
these actions might have been selected with equal probability.
5.5 Rules with Composed Actions
It is useful to allow more than one action in the action part of a rule. Goal supports rules with
multiple actions, both in the program section as well as in the perceptrules section.
The action part of a rule in the program section may consist of any number of built-in actions
combined by means of the + operator with at most one user-dened action. Such a combination
of multiple built-in actions and possibly one user-dened action is called a composed action.
6
Observe that this simple strategy never requires more than 2N moves if N is the number of blocks. The label
US stands for Unstack Strategy and the label RSG stands for Random Select Goal, which refers to the
default action selection mechanism used by Goal.
5.6. ENVIRONMENTS AND SENSING 69
Code listing
1 main: BlocksWorldAgent
2 {
3 knowledge{
4 block(a). block(b). block(c).
5 clear(table).
6 clear(X) :- block(X), not(on(_,X)).
7 tower([X]) :- on(X,table).
8 tower([X,Y|T]) :- on(X,Y), tower([Y|T]).
9 }
10 beliefs{
11 on(a,table). on(b,a). on(c,table).
12 }
13 goals{
14 on(a,b), on(b,c), on(c,table).
15 }
16 program[order=linear]{
17 if a-goal(tower([X,Y|T])), bel(tower([Y|T])) then move(X,Y).
18 if a-goal(tower([X|T])) then move(X,table).
19 }
20 actionspec{
21 move(X,Y) {
22 pre{ clear(X), clear(Y), on(X,Z), not(X=Y) }
23 post{ not(on(X,Z)), on(X,Y) }
24 }
25 }
26 }
Table 5.3: Blocks World Agent with Rule Order.
insert(on(a,b)) + delete(on(a,c))
goto(5, up) + send(elevator1, dir(up))
Both examples combine two actions. The rst example combines the two built-in actions
insert and delete. The rst action is used to insert a new fact about the position of block a and
the second action is used to remove the fact on(a,c) from the belief base. The second composed
action consists of the environment action goto of the elevator environment and the built-in send
action. The goto action makes the elevator move to a particular oor and the send action is
used to communicate the choosen direction to agent elevator1.
A composed action is viewed as a single action. The actions that are part of a composed action
may be put in any order in the action part of a rule. However, the order the actions are put in
is taken into account when executing the composed action: The actions are executed in the order
they appear.
A rule in the perceptrules section is similar to a rule in the program section but diers in
one respect: User-dened actions are not allowed in such rules. That is, action parts of percept
rules may consist of any number of built-in actions combined by means of the + operator only.
5.6 Environments and Sensing
Agents are connected to some environment in which they act. There are many interesting things
to say about this connection. Here we discuss in particular the need to be able to sense state
changes by agents in all but a few environments.
7
The only environments in which an agent does
not need a sensing capability is an environment in which the agent has full control and actions
do not fail. The Blocks World environment, discussed above, in which no other agents operate
is an example of such an environment. In this environment a single agent is able to maintain an
accurate representation of its environment by means of a correct specication of the eects of the
actions it can perform.
7
We do not discuss the perception of actions.
70 CHAPTER 5. GOAL AGENT PROGRAMS
Perception is useful when an agent has incomplete knowledge about its environment and needs
to explore it to obtain sucient information to complete a task. For example, a robot may
need to locate an item in a partially observable environment such a robot may not even know
how its environment is geographically structured and by exploring it would be able to map the
environment. Perception is also useful when an agent acts in an environment in which
(i) actions may fail,
(ii) eects of actions are uncertain, or
(iii) other agents also perform actions.
In such environments the agent is not able to maintain an accurate representation of its envi-
ronment without perceiving what has changed. For example, if stacking a block on top of another
block may fail, there is no other way to notice this than by receiving some signal from the envi-
ronment that indicates such failure. Throwing a dice is an example of an action with uncertain
outcomes where perception is necessary to know what outcome resulted. When other agents also
perform actions in an environment a sensing capability is also required to be able to keep track
of what may have changed.
8
Environments may also change because of natural events and may
in this sense be viewed as active rather than passive. Again sensing is required to be able to
observe state changes due to such events. This case, however, can be regarded as a special case of
(iii) other agents acting by viewing the environment as a special kind of agent. The main purpose
of sensing thus is to maintain an accurate representation of the environment. Fully achieving this
goal, however, typically is not possible as environments may be only partially observable.
Sensing in Environments with Multiple Agents
Agents that act in an environment where other agents inhabit that same environment need to
have sensors to provide these agents with the ability to acquire information about changes in its
environment that are not caused by the agent itself and thus to keep track of the current state of its
environment. Suppose, for example, that the stackBuilder agent of Table 5.2 is joined by another
agent called tableAgent. The Goal code for tableAgent is listed in Table 5.4.This agent is almost
a copy of the program code for agent stackBuilder. The dierence between the agents is that
tableAgent has dierent action rules in its program section, an additional action specication
for the action skip, and has an additional perceptrules section. Both agents are able to move
blocks, but dierently from stackBuilder agent tableAgent only moves blocks to the table. Agent
tableAgent does not always move a block but may also sometimes perform the skip action, the
action that is always enabled and changes nothing. Clearly, if both agents change the conguration
of blocks in the Blocks World they each need perceptual capabilities to monitor what has changed
by actions performed by the other agent.
In Goal, sensing is not represented as an explicit act of the agent but a perceptual interface is
dened between the agent and the environment that species which percepts an agent will receive
from the environment. The percept interface is part of the environment interface to connect
Goal agents to an environment (see for more information about building such an interface the
Goal IDE Manual [37]). A Goal agent does not actively perform sense actions, except when
the environment makes actions to observe the environment explicitly available to an agent. Each
time just before a Goal agent will select an action to perform, the agent processes percepts it
receives through its perceptual interface.
9
The steps performed are (i) to clear the percept base
8
Agents may also communicate to other agents the actions they have performed (where we dierentiate com-
munication from perception). This would potentially also allow all agents to maintain an accurate representation
of the environment. In order to do so, however, all agents would have to coordinate their actions as well as the
required communication about these actions. A scheme that could work is to agree that all agents take turns and
one by one perform an action; only after the performance of an action has been broadcasted to all other agents
the next agent would then be allowed to perform an action. Although a scheme like this could work it has obvious
limitations.
9
Goal agents thus perform a simple sense-plan-act cycle.
5.6. ENVIRONMENTS AND SENSING 71
Code listing
1 main: tableAgent
2 { % This agent moves blocks to the table while the goal configuration is not achieved.
3 knowledge{
4 block(a). block(b). block(c). block(d). block(e). block(f). block(g).
5 clear(table).
6 clear(X) :- block(X), not(on(_,X)).
7 tower([X]) :- on(X,table).
8 tower([X,Y|T]) :- on(X,Y), tower([Y|T]).
9 }
10 beliefs{
11 on(a,b). on(b,c). on(c,table). on(d,e). on(e,table). on(f,g). on(g,table).
12 }
13 goals{
14 on(a,e), on(b,table), on(c,table), on(d,c), on(e,b), on(f,d), on(g,table).
15 }
16 program{
17 if bel(on(X,Y), not(Y=table)), goal(on(X,Z)) then move(X,table).
18 if goal(on(X,Y)) then skip.
19 }
20 actionspec{
21 move(X,Y) {
22 pre{ clear(X), clear(Y), on(X,Z), not(X=Y) }
23 post{ not(on(X,Z)), on(X,Y) }
24 }
25 skip {
26 pre{ true }
27 post{ true }
28 }
29 }
30 perceptrules{
31 if bel( percept(on(X,Y)), on(X,Z), not(Y=Z) ) then insert(on(X,Y)) + delete(on(X,Z))).
32 }
33 }
Table 5.4: tableAgent: Goal Agent That Moves Blocks to the Table
and remove previously received percepts, (ii) check whether any new percepts have been received
from the environment, (iii) insert these into the percept base, and (iv) process received percepts
and update the mental state of the agent. Step (iv) is performed by applying so-called percept
rules, which are discussed below. Thereafter the agent continues to decide which action to perform
next, where the information in the percept base may be used to inuence this decision.
The Blocks World environment, for example, that comes with the distribution of the Goal IDE
provides a percept interface that returns percepts for the position of each block. These percepts
received from the Blocks World environment are stored in the percept base of the agent. It is
assumed that percepts are represented in the knowledge representation language used by the Goal
agent. A special reserved predicate percept/1 is used to dierentiate what we will call perceptual
facts from other facts in the knowledge or belief base. Information received from the environment
that block a is on block b is inserted into the percept base as the fact percept(on(a,b)).
Percepts representraw data received from the environment that the agent is operating in. For
several reasons an agent cannot always simply add the new information to its belief base.
10
One
reason is that the received information is inconsistent with that currently stored in the belief base
of the agent. For example, receiving information that block a is on the table (on(a,table)) may
conict with the fact stored in the belief base that a is on block b. In order to correctly update
the belief base, the fact on(a,b) needs to be removed and the fact on(a,table) needs to be
added to the belief base. A pragmatic reason is that the perceptual facts received may represent
signals which need interpretation and it is more useful to insert this interpretation into the belief
base than the fact itself. For example, a percept indicating that the agent bumped against a wall
may be interpreted as a failure to move forward and it is more useful to insert the fact that the
agent is still located at its last known position into the belief base (see the Wumpus environment
10
Recall that the knowledge base is static and cannot be modied. As the belief base is used to represent the
current state of an environment, percepts might modify the belief base of the agent.
72 CHAPTER 5. GOAL AGENT PROGRAMS
provided in the distribution of Goal).
Goal provides percept rules to process received percepts and update the agents mental state
using this information. A percept rule species how to modify the mental state of the agent when
certain percepts are received from the environment. Percept rules are included in a perceptrules
section in a Goal agent program. The agent program listed in Table 5.4 contains a perceptrules
section with one percept rule. A percept rule has the same form as an action rule, except that
only built-in actions (possibly as part of a composed action) may be used:
if mentalstatecondition then built-in action
In a percept rule, in the mental state condition special literals of the form percept() may be
used to inspect the percept base; that is, such literals may be used within a bel operator as in
Table 5.4.
The (properly instantiated) action of a percept rule is performed if the condition of the rule
holds; in that case we say that the percept rule is applicable. Whether a percept rule is ap-
plicable is veried by inspecting the knowledge, belief and percept base. If the percept rules
condition can be derived from the combination of these three databases, the rule is applicable.
For every instantiation of variables for which the rule is applicable the correspondingly instan-
tiated action is performed. For example, when a percept on(a,table) is received the percept
rule of agent tableAgent (given the belief base) in 5.4 is applicable. In this case, the instanti-
ated condition percept(on(a,table)), on(a,b), not(table=b) holds. As a result, ac-
tion insert(on(a,table)) + delete(on(a,b)) would be performed and on(a,table)
would be inserted into the belief base and on(a,b) would be removed.
5.7 Action versus Percept Rules
Typically, when you write action rules, try to avoid writing action rules that only modify the
mental state of an agent (i.e. perform a insert, delete, adopt, drop action). Instead, write a
percept rule for this whenever possible.
5.8 Notes
The Goal programming language was rst introduced in [36]. Previous work on the programming
language 3APL [35] had made clear that the concept of a declarative goal, typically associated
with rational agents, was still missing. Declarative goals at the time were the missing link
needed to bridge the gap between agent programming languages and agent logics [17, 60, 41].
The programming language Goal was intended to bridge this gap. The design of Goal has
been inuenced by the abstract language Unity [15]. It was shown how to provide a temporal
verication framework for the language as well, as a rst step towards bridging the gap. In [33] it
has been shown that Goal agents instantiate Intention Logic [17], relating Goal agents to logical
agents specied in this logic.
The execution mode of Goal where action options are randomly chosen when multiple options
are available may remind the reader of the random simulation mode of Promela [7].
An agents mental state consists of its knowledge, its beliefs and its goals as explained in
Section 5.2. In the current implementation of Goal these are represented in Prolog [68, 69].
Goal does not commit to any particular knowledge representation technology, however. Instead
of Prolog an agent might use variants of logic programming such as Answer Set Programming
(ASP; [3]), a database language such as Datalog [14], the Planning Domain Denition Language
(PDDL; [27]), or other, similar such languages, or possibly even Bayesian Networks [56]. The only
assumption that we will make throughout is that an agent uses a single knowledge representation
technology to represent its knowledge, beliefs and goals. For some preliminary work on lifting this
assumption, we refer the reader to [21].
5.9. EXERCISES 73
Goal does not support explicit constructs to enable the mobility of agents. The main concern
in the design of the language is to provide appropriate constructs for programming rational agents
whereas issues such as mobility are delegated to the middleware infrastructure layer on top of
which Goal agents are run.
The book Multi-Agent Programming [11] provides references to other agent programming lan-
guages such as 3APL, Jason, and Jadex, for example.
5.9 Exercises
5.9.1
Consider again the program of Figure 4.1. According to the third program rule, an agent
can put a block that he is holding down on the table. This can happen even if the block
could also be put in its goal position, which would be more ecient. Change the rule to
ensure that a block is only put down on the table if it cannot be put in its goal position
directly. (Alternatively, the order of rule evaluation can be set to linear; this exercise
shows that in principle we can do without this option but in practice using this option is
easier and helps avoiding bugs that may be introduced by adding conditions).
5.9.2
The Blocks World agent program of Figure 5.2 does not specify a policy. That is, the action
rules do not generate an option for every possible state the agent can be in. Here we do not
mean the conguration of blocks but the mental state of the agent. Modify the agent such
that it can handle all belief and goal bases. You may assume that the knowledge base is
xed and correctly species the blocks present in the agents environment.
74 CHAPTER 5. GOAL AGENT PROGRAMS
Chapter 6
Modules and Focus of Attention
Rational agents are assumed to create partial plans for execution and to not overcommit to a
particular way of achieving a goal. One important reason for not computing a complete plan is
that in a dynamic, uncertain environment an agent typically does not have sucient knowledge to
ll in the details of a plan that is guaranteed to succeed. It therefore is better practice to decide
on the action to perform next when the required information is available. As the action selection
mechanism in Goal ensures that agents select an action to perform by inspection of their current
mental state overcommitment is avoided. The Blocks World agent, for example, provides a robust
solution for solving Blocks World problems because it is exible in its choice of action. It would
still perform well even if other agents would interfere, assuming that it is able to perceive what
happens in the Blocks World (see also the tableAgent example of Chapter 5).
Even though action rules provide for a exible choice of action, it is useful to add additional
structure to a Goal agent. As is the case in almost any programming language, it is useful to
be able to structure parts of a program in a single unit. In Goal it is useful to combine related
conceptual and domain knowledge, goals, actions and action rules that are relevant for handling
particular situations in a single structure. Modules provide such a structure in Goal. Modules
provide for reusability and the encapsulation of related knowledge, goals, actions and action rules.
They also provide a programmer with a tool to focus on the particular knowledge and skills that
an agent needs to handle a situation.
6.1 Module
A module is very similar to a Goal agent itself. The main dierence with a Goal agent such
as the Blocks World agent discussed in the previous section is that a module has an additional
context section, which species an activation condition. A distinguishing feature of modules in
Goal is that the context of a module is specied declaratively. A modules context species not
only when to activate the module but also for what purpose a module is activated. It thus provides
a declarative specication of the intended use of a module. Such specications are useful for a
programmer as a programmer does not have to inspect the implementation details inside a module
but can read o the intended use from the context.
Another dierence with a Goal agent is that a module does not have a beliefs section and
that all sections other than the program section are optional. The reason that a module does not
have a beliefs section is that a module species knowledge and skills that are independent of the
current state. A module species the generic knowledge and know-how to deal with a particular
situation but not the specics of a particular state. The belief base of an agent is used to keep
track of the state of the environment and is a global component of the agent. This means that the
beliefs of an agent are accessible by and may be modied by any module. The knowledge and
actionspec section are optional because the knowledge in the knowledge section and all actions
specied in the actionspec section of the Goal agent that contains the module are inherited
75
76 CHAPTER 6. MODULES AND FOCUS OF ATTENTION
Code listing
1 main: stackBuilder {
2 knowledge{
3 % only blocks can be on top of another object.
4 block(X) :- on(X,Y).
5 % a block is clear if nothing is on top of it.
6 clear(X) :- block(X), not(on(Y,X)).
7 % the table is always clear.
8 clear(table).
9 % the tower predicate holds for any stack of blocks on the table.
10 tower([X]) :- on(X,table).
11 tower([X,Y|T]) :- on(X,Y), tower([Y|T]).
12 % a block X is above another object Y if it is directly on top of it
13 % or if X is on top of another block that is above Y.
14 above(X,Y) :- on(X,Y).
15 above(X,Y) :- on(X,Z), above(Z,Y).
16 }
17 beliefs{
18 }
19 goals{
20 on(a,e), on(e,c), on(c,table).
21 on(d,e), on(e,f), on(f,table).
22 }
23 program{
24 #define misplaced(X) a-goal(tower([Y|T])), bel(above(X,Y) ; X=Y).
25 #define constructiveMove(X,Y) a-goal(tower([X,Y|T])), bel(tower([Y|T])).
26
27 module buildTower {
28 context{
29 a-goal(tower([X|T]), clear(X))
30 }
31 program[order=linear]{
32 if constructiveMove(X,Y) then move(X,Y).
33 if misplaced(X) then move(X,table).
34 }
35 }
36 }
37 actionspec{
38 % not(on(X,Y)) in precondition to prevent moving a block on the table to another place on the table.
39 move(X,Y) {
40 pre{ clear(X), clear(Y), on(X,Z), not(on(X,Y)) }
41 post{ not(on(X,Z)), on(X,Y) }
42 }
43 }
44 perceptrules{
45 % the Blocks World is fully observable.
46 if bel(percept(on(X,Y)), not(on(X,Y))) then insert(on(X,Y)).
47 if bel(on(X,Y), not(percept(on(X,Y)))) then delete(on(X,Y)).
48 }
49 }
Table 6.1: Blocks World agent with module for building towers.
by the module and are accessible to modules. The same does not hold for the goals of an agent,
however. The context of a module may be used as a lter on the set of goals that the agent
currently pursues which allows an agent to focus its attention on a subset of these goals.
Table 6.1 presents an example of a Blocks World agent that uses a module for building towers.
This agent is able to handle multiple, conicting goals in the Blocks World that our earlier Blocks
World agent is not able to deal with. Observe that the agent in Table 6.1 has two goals which
are conicting since the rst goal requires on(e,c) and the second goal requires on(e,f). The
point is that in order to handle such conicting goals the agent needs to choose which goal to
achieve rst and only thereafter try to achieve the second goal. The agent does needs to focus its
attention rst on one of the goals. Modules support focusing on a particular goal, which we will
illustrate by explaining how the module modies the behavior of the original Blocks World agent.
6.2. CONTEXT 77
6.2 Context
The context of a module is a mental state condition just like the conditions of action rules. A
context condition serves two functions: it species a condition for activation and enables focusing
on a specic goal.
6.2.1 Module Activation
The rst function of a context is that it species when a module may be activated and entered.
Like mental state conditions in action rules it is a condition that species when a module can be
executed. For example, the context of the module in Table 6.1 species that the module may be
activated whenever the agent has an achievement goal to build a tower with block X as the top of
that tower. That is, block X should be clear.
By inspecting the knowledge and initial goal base of the agent, it can be veried that the
context condition of the module can be satised by either of the two goals. Whether or not the
module is actually entered depends on the order used in the action selection mechanism (either
random or linear, see also Chapter 5). In case the order of evaluation in the program section is
linear, the place of the module within that section determines whether the module is activated or
not; otherwise entering the module, if the context condition holds, is a random choice out of all
other options that are available.
At most one module is active at any time. The attention set, introduced below, associated with
that module determines the current focus of the agent. A module provides a context which restricts
the choice of action. When a module is activated the action rules present in the module are the
only rules available to generate action options. A module may also introduce action specications
that are only available while the module is executed and specic for handling situations the module
has been designed for. Actions specied in the main Goal agent, but not those specied in other
modules, are also accessible from within a module.
The example module replaces the action rules in the program section of the Blocks World
agent of Table 5.2. The rst action rule of that agent which generates constructive moves is
included in the program section of the module. The second action rule of this agent which
generates moves of misplaced blocks to the table, however, has been replaced by another rule.
The reason is that the original rule assumed that each block is part of the goal conguration and,
as a consequence, any block is either in position or misplaced. As the attention set of an agent
upon activation of a module is restricted we can no longer make this assumption. Instead of being
part of a goal condition a block may now be in the way of achieving a goal of the agent, i.e. it may
obstruct making moves with a block that is part of such a goal because it is above such a block.
Therefore, the second action rule if bel(tower([X[T]), not(goal(tower([X[T])) then
move(X,table) in Table 6.1 still moves blocks to the table but under a dierent condition. The
mental state condition of this rule expresses that block X is possibly in the way to get to a block
needed to achieve a goal of the agent. Here, possibly in the way means that the agent does not
intend the block to be in the position it believes it to be in.
1
Observe that blocks that are misplaced
also satisfy this mental state condition but that blocks that are possibly in the way do not always
satisfy the mental statement condition goal(tower([X[T])), not(bel(tower([X[T]))).
The latter condition expresses that block X is misplaced and therefore must be part of the agents
goals whereas a block that is possibly in the way does not need to be part of one of the goals of
1
We use does not intend here instead of the seemingly more natural does not want as the agent is supposed
to not have a goal here. The natural language expression does not want is more commonly used to express that
one wants to be in a state where is not the case (the eect of which can be strengthed by putting more stress on
not in the phrase). In other words, this expression is commonly used to express that one has a goal to achieve
that is not the case. In contrast, the expression does not intend is more commonly used to express the lack of
an intention or goal. From a more technical point of view, as the knowledge representation used is Prolog, there is
no dierence between writing not(goal()) or goal(not()) since in Prolog the Closed World Assumption is
supported (a similar point can be made for the bel operator). The negation in Prolog is negation as failure and
cannot be used to express explicit negation which would be needed to make the distinction.
78 CHAPTER 6. MODULES AND FOCUS OF ATTENTION
the agent.
2
The second action rule may generate options that are not needed to realize the achievement
goal of the agent as there may be stacks of blocks which do not contain a block needed to build
the desired tower and these blocks therefore are not in the way to achieve this goal. The reader
is invited to provide a mental state condition that more accurately captures the notion of a block
being in the way. (Hint: it is useful to introduce a Prolog denition of the concept above.) The
strategy of building towers in the goal state one by one implemented using the module construct,
however, never requires more than 2N steps where N is the number of blocks.
6.2.2 Focus of Attention
The second function of a context is that it is used as a lter on the goals that the agent pursues
which selects a subset of these goals. In many situations it is natural to focus attention on achieving
particular goals and disregard other goals for the moment. Such focus allows for a more dedicated
use of resources and the need for creating plans for a subset of ones goals only. It also allows for
sequencing potentially conicting goals. As an example, consider a truck delivery domain where
a truck is supposed to deliver multiple packages to dierent locations. Given that the load of
packages that the truck may carry is limited, it is useful to focus on the delivery of packages to a
particular subset of locations and only load packages that need to be delivered to those locations.
Modules provide for a mechanism that enables agents to focus attention in this way.
Similarly, the Blocks World agent of Table 6.1 uses the context condition of the module to
select one of its current goals. The default mode for selecting a goal is to compute which goals
satisfy the context condition and randomly select one of those to focus attention on. As both goals
in the agent satisfy the context condition either one of them may be selected.
The goals currently pursued by an agent are said to be in the agents attention set. After
activating a module the attention set of an agent is restricted to those goals in that set that are
obtained by using the context of a module as a selector. The goal that is selected by the lter
mechanism is put into this attention set. In the example, one possible result of activating the
module and creating the associated attention set is:
main:
on(a,e) , on(e,c) , on(c,table)
on(d,e) , on(e,f) , on(f,table)
buildTower:
on(a,e) , on(e,c) , on(c,table)
There are two methods for focusing attention on goals. The options can be indicated by adding
a focusmethod option to the context condition as follows:
context[focusmethod=filter]{
a-goal(tower([X|T]), clear(X))
}
The default focus method option is select which results in the attention set above. By using
the option filter instead an instantiation of the goal conditions that occur positively in the
context are put into the attention set. In the example tower([X|T]), clear(X) is a goal
condition that occurs positively (since a-goal determines that the condition is a goal condition
and no negation occurs in front of the a-goal operator). The instantiation that is obtained can
be inspected in the goal base again and could be:
2
Suppose that block X is misplaced and the agent believes that X is part of a tower [X|T]. In that case, the
agent has a goal that the block is part of another tower. That is, we have not(goal([X|T])). Vice versa, it is not
possible to derive from the fact that a block is possibly in the way that the block is part of one of the goals of the
agent and we cannot conclude the block is misplaced.
6.3. NOTES 79
main:
on(a,e) , on(e,c) , on(c,table)
on(d,e) , on(e,f) , on(f,table)
buildTower:
tower([d,e,f]) , clear(d)
Goals introduced by the modules goals section, if any, are added to the attention set as well.
Activating a module is making a commitment to achieve the goals in the attention set that
is initialized upon activation. A module is terminated only when the attention set, i.e. the set
of goals currently pursued by the agent, is empty. The knowledge and skills incorporated in a
module need to be sucient in order to realize the goals in the agents attention set. In addition,
another module may be activated from a module whenever the context of that module is true.
6.2.3 Reactive and Goal-Based Modules
A module that has a context condition that selects or lters current goals of an agent is called a
goal-based module. Any context condition that has positive occurrences of goal conditions acts as
a focus method and selects a goal to focus on.
Context conditions do not need to have positive occurrences of goal conditions, however. They
may also consist of pure belief conditions. For example, bel(on( ,X), not(X=table) is a
belief condition that checks whether there are blocks that are not directly on the table. Such a
condition may also be used as activation condition of a module. In that case, no goal is put into
the attention set and the module is activated with an empty attention set. A module with such a
context condition is called a reactive module.
The termination behavior of reactive and goal-based modules diers. Goal-based modules are
terminated (automatically) whenever the attention set is empty and all goals have been achieved.
Reactive modules are terminated (automatically) only when there are no enabled actions anymore,
i.e. the module does not generate any action options.
Finally, Goal provides a programmer with the option to determine when a module should be
terminated by means of the built-in action exit-module. Whenever this action is performed
inside a module, the module is terminated no matter whether there are still other action options
or the attention set is nonempty.
6.3 Notes
The original proposal to introduce modules into Goal can be found in [32].
80 CHAPTER 6. MODULES AND FOCUS OF ATTENTION
Chapter 7
Communicating Rational Agents
7.1 Introduction
In a multi-agent system, it is useful for agents to communicate about their beliefs and goals. Agents
may have only a partial view on the environment, and by communicating, agents may inform each
other about parts they but other agents cannot perceive. Agents may also use communication to
share goals and coordinate the achievement of these goals.
This chapter will explain how communication works in the Goal platform, and how to pro-
gram communicating Goal agents. First, the organisation of a multi-agent system by means of
a .mas le is explained. Next, the communication primitive and the handling of messages is
discussed. Sections 7.5 and 7.6 go into more detail on dierent types of messages and how to
address other agents. Finally, an example multi-agent system is presented to demonstrate usage
of communication to have agents coordinate their actions.
7.2 Multi-Agent Systems
Goal facilitates the development and execution of multiple Goal agents. These agents may or
may not be associated with entities from the environment. Agents can be launched when the
multi-agent system is launched, or when an entity in the environment is born.
Agents in a multi-agent system (MAS) can communicate with each other. Communication is
essential in situations where agents have dierent roles and need to delegate actions to appropriate
agents, or when agents with conicting goals operate in the same environment space and need to
coordinate their actions to prevent deadlocks and ineciencies.
This section explains how to dene a MAS, and how to use communication in agent programs.
7.2.1 Example MAS
Throughout this chapter we will be exploring the concepts of multi-agent systems and communi-
cation guided by an example MAS. This example MAS is described below.
Coee domain
The Coee domain is a multi-agent system in which a coee maker and a coee grinder work
together to brew a fresh cup of coee. Optionally, a milk cow can provide milk for making a latte.
To make coee the coee maker needs water and coee grounds. It has water, and coee beans,
but not ground coee. Grinding the beans is the task of the coee grinder. The coee grinder
needs beans, and produces grounds. The programs of the coee maker and the coee grinder are
listed in Figures 7.7 and 7.8, respectively. Figure 7.1 lists a shorter version of the agent program
for the coee maker that does not include comments.
81
82 CHAPTER 7. COMMUNICATING RATIONAL AGENTS
The agents are designed in such a way that they know which ingredients are required for which
products. They know what they can make themselves, but they do not initially know what the
other agents can make. This is where communication comes in.
GOAL
1 main: coffeeMaker {
2 knowledge{
3 requiredFor(coffee, water).
4 requiredFor(coffee, grounds).
5 requiredFor(espresso, coffee).
6 requiredFor(grounds, beans).
7
8 canMakeIt(M, P) :- canMake(M, Prods), member(P, Prods).
9 }
10 beliefs {
11 have(water). have(beans).
12 canMake(maker, [coffee, espresso]).
13 }
14 goals {
15 have(coffee).
16 }
17 program {
18 if goal(have(P)) then make(P).
19 }
20 actionspec {
21 make(Prod) {
22 pre { forall(requiredFor(Prod, Req), have(Req)) }
23 post { have(Prod) }
24 }
25 }
26 perceptrules {
27 if bel(agent(A), not(me(A)), not(canMake(A, _))) then sendonce(A, ?canMake(A, _)).
28 if bel(me(Me), received(A, int(canMake(Me, _))), canMake(Me, Prod))
29 then sendonce(A, :canMake(Me, Prod)).
30 if bel(received(Sender, canMake(Sender, Products))) then insert(canMake(Sender, Products))
31 + delete(received(Sender, canMake(Sender, Products))).
32
33 if bel(agent(A), received(A, have(X))), not(bel(have(X))) then insert(have(X)).
34 if goal(have(P)), bel(requiredFor(P, R), not(have(R))),
35 bel(canMakeIt(Me, R), me(Me)) then adopt(have(R)).
36 if goal(have(P)), bel(requiredFor(P, R), not(have(R))),
37 bel(canMakeIt(Maker, R), not(me(Maker))) then sendonce(Maker, !have(R)).
38 if goal(have(P)), bel(requiredFor(P, R), not(have(R)), me(Me), not(canMakeIt(Me, P)))
39 then sendonce(allother, !have(R)).
40 if bel(agent(Machine), received(Machine, imp(have(X))), have(X))
41 then sendonce(Machine, :have(X)).
42 }
43 }
Figure 7.1: The Coee Maker
The knowledge section reects the agents knowledge of which ingredients are necessary for
which products. The beliefs section holds the agents beliefs in what it can make. In this case,
the maker can make coffee and espresso. The goals section states this agents mission:
having coffee. Note that this describes a goal state (coffee being available), not an action
(like making coffee). Also note that the perceptrules section contains all communication
related action rules, meaning that every round all instances of these action rules are executed.
This is discussed in Section 7.7.
The coee domain assumes the following, for simplicitys sake:
1. Resources (like water, beans, grounds and coffee) cannot be depleted.
2. The agents share the resources in the sense that if one agent has a resource, all agents
do. But there is no environment, so agents cannot perceive changes in available resources;
they have to communicate this. For example, if the coee grinder makes grounds, it will
thereafter believe have(grounds), but the coee maker will not have this belief until it
gets informed about it.
7.2. MULTI-AGENT SYSTEMS 83
7.2.2 MAS Files
A multi-agent Goal system needs to be specied by means of a mas le. A mas le in Goal
is a recipe for running a multi-agent system. It species which agents should be launched when
the multi-agent system is launched and which Goal source les should be used to initialize those
agents. Goal allows for the possibility that multiple agents instantiate a single Goal agent le.
Various features are available to facilitate this. In a mas le one can associate multiple agent
names with a single Goal le. Each agent name additionally can be supplied with a list of
optional arguments. These options include the number of instances of an agent, indicated by #nr,
that should be launched. This option is available to facilitate the launching of large numbers of
agents without also having to specify large numbers of dierent agent names.
A mas le is a recipe for executing a multi-agent system. The Goal interpreter uses these
les to launch a multi-agent system and an environment. A mas le should provide the informa-
tion to locate the relevant les that are needed to run a multi-agent system and the associated
environment. A mas le has the following format:
masprogram ::= [envdesc] agentles launchpolicy
envdesc ::= environment{ path. options. }
path ::= any valid path to a le in quotation-marks
options ::= list of options valid with respect to the selected environment
agentles ::= agentles{ agentle. , agentle.

}
agentle ::= path [agentparams] .
agentparams ::= [ nameparam ] [ [ langparam ] [
[ nameparam , langparam ] [
[ langparam , nameparam ]
nameparam ::= name = id
langparam ::= language = id
launchpolicy ::= launchpolicy{ launch [ launchrule
+
}
launch ::= launch agentbasename [agentnumber] : agentref .
agentbasename ::= [ id
agentnumber ::= [number]
agentref ::= plain agent le name without extension, or reference name
launchrule ::= when entitydesc do launch
entitydesc ::= [ nameparam ] [ [ typeparam ] [ [ maxparam ] [
[ nameparam , typeparam ] [ [ typeparam , nameparam ] [
[ maxparam , typeparam ] [ [ typeparam , maxparam ]
typeparam ::= type = id
maxparam ::= max = number
id ::= an identier starting with a lower-case letter
num ::= a natural number
A MAS-program consists of three sections:
1. an environment-description-section that denes the connection to one environment-interface,
2. a section of agent-les that denes a list of Goal-les, and
3. a launch-policy-section that denes a policy how and when to instantiate agents from the
Goal-les.
An environment-description denes a connection to one environment-interface. That environment-
interface is supposed to be a jar-le that conforms with EIS.
1
Example:
1
EIS is short for Environment Interface Standard, a standard developed for agent platforms to connect to
environments. See [5] for more information about this standard.
84 CHAPTER 7. COMMUNICATING RATIONAL AGENTS
environment "elevatorenv.jar" .
The agent-les dene the set of Goal-les that are to be used. Those Goal-les are then
referenced by the agents. You can simply dene a Goal-le like this:
agentfiles: {
"elevatoragent.goal" .
}
The reference-label for the agents would then be elevatoragent, which is the le-name
without its le-extension. However you can dene the reference-label yourself by using agent-
parameters. You can also dene the knowledge-representation language this way. Here is an
example:
agentfiles: {
"elevatoragent1.goal" [language=swiprolog,name=file1] .
"elevatoragent2.goal" [language=pddl,name=file2] .
}
This denes two agent les. The rst is referenced by the label file1 and uses SWI Prolog
as KR-language. The second is referenced by file1 and uses PDDL.
2
The nal section contains the launch-policy. The launch-policy consists of a list of launches
and launch-rules. A launch is applied before running the MAS and instantiates agents that do
not have a connection to the environment. An example:
launchpolicy {
launch elevator:file1 .
}
This launches a single agent and uses the agent-le that is labeled by file1. It also uses the
identier elevator as the base-name for the generation of unique agent names. You can also
instantiate several agents with one launch:
launchpolicy {
launch elevator[3]:file1 .
}
This launch would instantiate three agents. The agent-names would be elevator, elevator1,
and elevator2.
A launch-rule on the other hand is applied to instantiate an agent or agents when the environ-
ment contains an entity that is not associated with an agent, called a free entity. This happens
when the environment initializes a new elevator carriage, for example. A launch-rule is triggered
by the creation of an entity in the environment. Special conditions can be added on the type of
event or trigger. This is a very simple launch-rule:
launchpolicy {
when entity@env do launch elevator:file1 .
}
Its interpretation is: when there is a free entity create an agent with the base-name elevator
from file1 and associate it with the entity.
You can also do something nice with the base-name:
2
PDDL support is under development and is not yet available.
7.2. MULTI-AGENT SYSTEMS 85
launchpolicy {
when entity@env do launch
*
:file1 .
}
The asterisk means that the name of the entity as provided by the environment is used as the
base-name for the agent.
Of course you can also instantiate several agents:
launchpolicy {
when entity@env do launch elevator[3]:file1 .
}
This would instantiate three agents and associate them with one and the same entity. So if
the entity would perceive something, all three agents would receive that percept. If any of those
agents performs an environment action, it will be performed by that entity.
Launch-rules can be conditional on the type, amount and name of the entity/entities:
launchpolicy {
when [type=type1]@env do launch elevator:file1 .
}
This would only launch an agent if the type of the new entity is type1.
You can also restrict the amount of instantiated agents:
launchpolicy {
when [type=type1,max=20]@env do launch elevator:file1 .
}
This launch-rule would only be applied at most 20 times.
There is also a name-parameter:
launchpolicy {
when [name=car0]@env do launch elevator:file1 .
}
This would only be applied if the new entity has the name car0.
7.2.3 Automatic agent and me fact generation
In many practical multi-agent situations, the agents that are to be launched in the MAS and their
names are not known during programming, but are determined in the MAS le, as described in
Section 7.2.2. Also, in some MASs, agents may come and go dynamically during the lifetime of a
MAS. It is therefore not always possible or practical to hard-code the known agents in the belief
base.
Instead, Goal automatically inserts these agent facts in the belief base whenever a new agent
enters the MAS, and upon launch of an agent, it populates the belief base with an agent fact for
each existing agent (including itself). An agent program(mer) can thus assume that, at any time,
bel(agent(X)) will result in a substitution for X of each existing agent.
To give an agent knowledge of its own name and thus the ability to distinguish itself from the
other agents amongst the agent facts, a special me fact is inserted into its beliefbase. It has the
form me(<agentname>) where <agentname> is the name of the agent, as determined by the
launch-policy.
It is therefore not necessary to specify or maintain a list of existing agents, or to hard-code the
agents name in the program.
Unless an agent wants to actively ignore some agent, it is unwise to delete agent facts from
the belief base.
86 CHAPTER 7. COMMUNICATING RATIONAL AGENTS
7.2.4 Example MAS
A minimal mas le without environment would look like Figure 7.2. This would start a MAS
GOAL MAS file
1 agentfiles {
2 "agent.goal".
3 }
4
5 launchpolicy {
6 launch agent1:agent.
7 }
Figure 7.2: A minimal MAS le
without an environment, with one agent named agent1 whose agent program is loaded from le
agent.goal. This agents beliefbase will contain the following facts:
beliefs {
... % other facts
agent(agent1).
me(agent1).
}
A mas le for the coee domain would be as shown in Figure 7.3.
GOAL mas file
1 agentfiles {
2 "coffeemaker.goal".
3 "coffeegrinder.goal".
4 }
5
6 launchpolicy {
7 launch maker:coffeemaker.
8 launch grinder:coffeegrinder.
9 }
Figure 7.3: A mas le for the coee domain MAS
After launch of the agents, the coee makers beliefbase would look like this:
beliefs {
have(water). have(beans).
canMake(maker, [coffee, espresso]).
agent(maker).
agent(grinder).
me(maker).
}
An example of a more complex mas le is provided in Figure 7.4.
This example uses relative paths to the les and labels to reference those les. One elevator
agent will be launched and associated with each entity in the environment of type car (at most
three times).
After all three elevator agents have been lauched, the belief base of elevator2 will look like
beliefs {
... % other facts
agent(manager).
agent(elevator1).
agent(elevator2).
agent(elevator3).
me(elevator2).
}
7.3. COMMUNICATION 87
GOAL MAS file
1 environment{
2 "elevatorenv.jar".
3 }
4
5 agentfiles {
6 "elevatoragent.goal" [name=elevatorfile] .
7 "managingagent.goal" [name=managerfile] .
8 }
9
10 launchpolicy {
11 launch manager:managerfile .
12 when [type=car,max=1]@env do launch elevator1:elevatorfile .
13 when [type=car,max=1]@env do launch elevator2:elevatorfile .
14 when [type=car,max=1]@env do launch elevator3:elevatorfile .
15 }
Figure 7.4: A more complex MAS le
7.3 Communication
The basic means for communication are supported in Goal by means of a so-called mailbox se-
mantics. Messages received are stored in an agents mailbox and may be inspected by the agent by
means of queries on special, reserved predicates sent(agent,msg) and received(agent,msg)
where agent denotes the agent the message has been sent to or received from, respectively, and
msg denotes the content of the message expressed in a knowledge representation language.
7.4 Send Action and Mailbox
The action send(AgentName, Poslitconj) is a built-in action to send Poslitconj to the
agent with given AgentName. Poslitconj is a conjunction of positive literals. AgentName is
an atom with the name of the agent as specied in the mas le. Messages that have been sent
are placed in the mailbox of the sending agent, as a predicate of the form sent(AgentName,
Poslitconj) (note the t at the end of sent). The message is sent over the selected middleware
to the target agent, and after arrival the message is placed there in the formreceived(SenderAgentName,
Poslitconj) where SenderAgentName is the name of the agent that sent the message. De-
pending on the middleware and distance between the agents, there may be delays in the arrival of
the message. In the current implementation of Goal, messages are supposed to always arrive.
7.4.1 The send action
To illustrate the working of the send action, lets consider a simple example multi-agent system
consisting of two agents, fridge and groceryplanner. Agent fridge is aware of its contents and will
notify the groceryplanner whenever some product is about to run out. The groceryplanner will
periodically compile a shopping list. At some point, the fridge may have run out of milk, and
takes appropriate action:
program {
...
if bel(amountLeft(milk, 0)) then send(groceryplanner, amountLeft(milk, 0)).
...
}
At the beginning of its action cycle, the groceryplanner agent gets the following fact inserted in
its message base.
received(fridge, amountLeft(milk, 0)).
88 CHAPTER 7. COMMUNICATING RATIONAL AGENTS
The received messages can be inspected by means of the bel operator. In other words, if an
agent has received a message M from sender S, then bel(received(S, M)) will be true; the
agent believes it has received the message. This also holds for bel(sent(R, M)), where R is
the recipient of the message. This way, the groceryplanner can act on the received message:
program {
...
if bel(received(fridge, amountLeft(milk, 0))) then adopt(buy(milk)).
}
7.4.2 Mailbox management
In contrast with the percept base, mailboxes are not emptied automatically. This means that
once a message is sent or received, that fact will remain in the message base, even after execution
of the above program rule. The consequence of this is that the next action cycle, the fridge may
again select the shown program rule, sending the same message again, over and over. Also, the
groceryplanner will keep selecting this program rule.
We have to take action to prevent this. There may be some special cases in which it is preferred
to leave the message in the mailbox, for example if the message contains some message counter, so
you can review the whole message history. Otherwise it is possible that a new message containing
the same content sent to the same recipient will not be seen as a new message. So, we need to
remove the received when we process them. For this an internal action is added to the action
rule.
if bel(received(fridge, amountLeft(milk, 0)))
then adopt(buy(milk)) + delete(received(fridge, amountLeft(milk, 0))).
If the fridge sends this message only once, this program rule will be selected only once.
The coee maker agent from Section 7.2 also provides an example of a similar rule:
% process information from other agents on what they can make
if bel(received(Sender, canMake(Sender, Products)))
then insert(canMake(Sender, Products)) + delete(received(Sender, canMake(Sender, Products)))
The logic is slightly dierent for the sender, because if it would remove the sent fact it would
lose the belief that it has already notied the groceryplanner, and send the message again. Instead
it can use this information to prevent repeatedly sending the same message:
if bel(amountLeft(milk, 0), not(sent(groceryplanner, amountLeft(milk, 0))))
then send(groceryplanner, amountLeft(milk, 0)).
The sendonce action
Because the above leads to verbose programming, Goal oers a variant of the send action; the
sendonce action. The syntax is the same as that of send, but the semantics are such that the
message is sent only if there is no sent fact for that message (and receiver(s)) in the mailbox.
Writing
if bel(agent(A), fact(P)) then sendonce(A, fact(P)).
% if some machine seems to need a product, tell it we have it
if bel(agent(Machine), received(Machine, imp(have(P))), have(P))
then sendonce(Machine, have(P)).
is short for
7.5. MOODS 89
if bel(agent(A), fact(P), not(sent(A, fact(P)))) then send(A, fact(P)).
% if some machine seems to need a product, tell it we have it
if bel(agent(Machine), received(Machine, imp(have(P))),
have(P), not(sent(Machine, have(P)))) then send(Machine, have(P)).
This means that if the sent fact is deleted from the mailbox, the message may henceforth be sent
again by the sendonce action.
7.4.3 Variables
In Goal programs, the use of variables is essential to writing eective agents. Variables can be
used in messages as expected. For example, a more generic version of the fridges program rule
would be
if bel(amountLeft(P, N), N < 2, not(sent(groceryplanner, amountLeft(P, N))))
then send(groceryplanner, amountLeft(P, N)).
Note that this will eventually send one message for every value of N where N < 2.
Recipients and senders can also be variables in the mental state condition. Example:
% This isnt an argument; its just contradiction!
% - No it isnt.
if bel(received(X, fact)) then send(X, not(fact)).
% http://en.wikipedia.org/wiki/Marco_Polo_(game)
if bel(received(X, marco)) then send(X, polo).
This is especially useful in situations where you dont know who will send the agent messages, as
with the coee domain example:
% answer any question about what this agent can make
if bel(me(Me), received(A, int(canMake(Me, _))), canMake(Me, Prods))
then sendonce(A, canMake(Me, Prods)).
For any agent A it has received a question from, it will answer its question.
Closed actions
In order for any action in Goal to be selected for execution, that action must be closed, meaning
that all variables in the action must be bound after evaluation of the mental state condition. As
a consequence, messages must be closed as well, in order to make the action executable.
7.5 Moods
Goal agents are goal-oriented agents who have their goals specied declaratively. Up until now all
examples have shown communication of an agents beliefs. Every message was a statement about
the senders beliefs regarding the content. Given Goals goal-orientedness, it would be useful to
be able to not only communicate in terms of beliefs but also in terms of goals. This way Goal
agents can tell other agents that they have a certain goal.
In natural language communication, such a speech act is often performed by uttering a sentence
in a certain mood. This mood can be indicative (The time is 2 oclock), expressive (Hurray!!),
declarative (I hereby declare the meeting adjourned).
In Goal, the execution of the send action is the uttering, the message content is the sentence.
The mood is indicated by prexing the message content with a mood operator. Goal distinguishes
three moods listed in Figure 7.5.
90 CHAPTER 7. COMMUNICATING RATIONAL AGENTS
Mood operator example NL meaning
INDICATIVE : :amountLeft(milk, 0) Ive run out of milk.
DECLARATIVE ! !status(door, closed) I want the door to be closed!
INTERROGATIVE ? ?amountLeft(milk, ) How much milk is left?
Figure 7.5: Goal message moods
In the case of the indicative mood the mood operator is optional. In other words, in absence
of a mood operator, the indicative mood is assumed. That means that all examples in Section 7.4
were implicitly in the indicative mood.
Using these mood operators, Goal agents can be more Goalish in their communication. For
example, if the coee maker or coee grinder needs a resource to make something but does not
have it, it can inform an agent that it believes does have it that it needs it:
% if we need a product but dont have it, notify an agent that does have it that we need it.
if goal(have(P)), bel(requiredFor(P, R), not(have(R)), canMakeIt(Maker, R))
then send(Maker, !have(P)).
Now for the receiving side of the communication. Moods of messages in the mailbox are
represented as predicates, allowing for logic programming. An imperative is represented by the
imp predicate, an interrogative mood by the int predicate. There is no predicate for the indicative
mood in the mailbox. Using these mood predicates, we can inspect the mailbox for messages of
a specic type. For example, to handle a message like the one above from the coee maker, the
coee grinder can use this action rule:
% if some agent needs something we can make, adopt the goal to make it
if bel(received(_, imp(have(P))), me(Me), canMakeIt(Me, P)) then adopt(have(P)).
The coee grinder will grind beans for whichever agent needs them, so here a dont care is used
in place of the sender parameter. Another rule will make sure that the correct agent is notied of
the availability of the resulting grounds.
The previous section mentioned that messages must be closed. There is one exception, which
concerns interrogative type messages. These messages are like open questions, like, for example,
What time is it? or What is Bens age?. These cannot be represented by a closed sentence.
Instead, a dont care can be used to indicate the unknown component. For example:
if not(bel(timeNow(_))) then send(clock, ?timeNow(_)).
if not(bel(age(ben, _))) then send(ben, ?age(ben, _)).
% ask each agent what they can make
if bel(agent(A), not(me(A)), not(canMake(A, _))) then sendonce(A, ?canMake(A, _)).
7.6 Agent Selectors
In many MASs agents may nd themselves communicating with agents whose name they do not
know beforehand. For example, the MAS might have launched 100 agents, who communicate
with each other, using the agent[100]:file1 syntax. Or if a message needs to be multicast
or broadcast to multiple receivers. For these cases a more exible way of addressing messages is
needed.
7.6.1 send action syntax
The send action allows more dynamic addressing schemes than just the agent name, by means of
an agent selector. The syntax of the send action and this agent selector is shown in Figure 7.6.
7.6. AGENT SELECTORS 91
The rst parameter to the send action (agent name in the previous sections) is called an agent
selector. An agent selector species which agents are selected for sending a message to. It consists
of one or more agent expressions, surrounded by square brackets. The square brackets can be
omitted if there is only one agent expression.
Some examples of agent selectors:
% agent name
send(agent2, theFact).
% variable (Prolog)
send(Agt, theFact).
% message to the agent itself
send(self, theFact).
% multiple recipients
send([agent1, agent2, self, Agt], theFact).
% using quantor
% if we dont know anyone who can make our required resource, broadcast our need
if goal(have(P)), bel(requiredFor(P, R), not(have(R)), not(canMakeIt(_, R)))
then send(allother, !have(P)).
sendaction ::= send ( agentselector , [moodoperator] Poslitconj ) [
sendonce ( agentselector , [moodoperator] Poslitconj )
moodoperator ::= : [ ! [ ?
agentselector ::= agentexpression [
quantor [ [ quantor ] [
[ agentexpression [ , agentexpression ]* ]
agentexpression ::= agentname [ variable [ self
quantor ::= all [ allother
agentname ::= any valid agent name
Figure 7.6: Syntax of the send and sendonce action
Agent Name
The agent name is the simplest type of agent expression, which we have already seen in Sections 7.4
and 7.5. It consists of the name of the receiving agent. If the KR language of the agent is Prolog,
the agent name must start with a lowercase letter.
Example:
send(alice, :hello).
% using the square brackets to address multiple agents for one message
send([alice, bob, charlie], :hello).
If the agent name refers to an agent that does not exist in the MAS, or has died, or is other-
wise unadressable, the message will silently be sent anyway. There is no feedback conrming or
disconrming that an agent has received the message. Only a reply, the perception of expected
behaviour of the receiving agent, or the absence of an expected reply can conrm or disconrm
the reception of the message.
Variables
A variable type agent expression allows a dynamic way of specifying the message recipient. Some-
times the recipient depends on the agents beliefs or goals or on previous conversations. The
92 CHAPTER 7. COMMUNICATING RATIONAL AGENTS
variable agent expression consists of a variable in the agents KR language. If the KR language is
Prolog, this means it must start with an uppercase letter. This variable will be resolved when the
program rules mental state condition is evaluated. This means that the mental state condition
must bind all variables that are used in the agent selector. If an agent selector contains unbound
variables at the time of action selection, the action will not be considered for execution.
Example:
GOAL
1 beliefs {
2 agent(john).
3 agent(mary).
4 }
5 goals {
6 informed(john, fact(f)).
7 }
8 program {
9 if bel(agent(X)), goal(hold(gold)), not(bel(sent(_, !hold(_)))) then send(X, !hold(gold)).
10
11 goal(informed(Agent, fact(F))) then send(Agent, :fact(F)).
12
13 % This will never be selected:
14 if bel(something) then send(Agent, :something).
15 }
In this example, the program rule on line 9 contains the variable X, which has two possible
substitutions: [X/john] and [X/mary]. This results in there being two options for the action:
send(john, !hold(gold)) and send(mary, !hold(gold)). The agents action selection
engine will select only one option for execution. This means that variables resolve to one agent
name, and are therefore not suited for multicasting messages.
Quantors
Quantors are a special type of agent expression. They consist of a reserved keyword. There are
three possible quantors that can be used in combination with the communicative actions send
and sendonce: all, allother and self. When the send action is performed, the quantor is
expanded to a set of agent names, in the following way:
all will expand to all names of agents currently present in the belief base of the agent
(including the name of the sending agent itself).
allother will expand to all names of agents currently present in the MAS, with the ex-
ception of the sending agents name.
self will resolve to the sending agents name. So using self, an agent can send a message
to itself.
Sending a message addressed using a quantor will not result in the quantor being put literally
in the mailbox. Rather, the actual agent names that the quantor resolves to are subsituted, and
a sent(..) fact is inserted for every agent addressed by the quantor. This has consequences
for querying the mailbox using quantors. It is possible to test if a message has been sent to all
agents, for example, by doing
if bel(not(sent(all, fact))) then send(all, fact).
This will execute if the message has not been sent to all agents the sending agent believes to
exist, so all substitutions of X in bel(agent(X)). This means that after sending of the original
message, if new agents would join the MAS, this substitution would change (i.e. agent(X) facts
would be added). Thus the above mental state condition would again be satised, because the
message had not been sent to all agents. The semantics of the all and allother quantors in
belief queries reect the situation at the time of querying.
This is illustrated in the following code fragment, in which the mailbox... section reects
the mailbox contents at this time.
7.6. AGENT SELECTORS 93
Code listing
1 beliefs {
2 agent(maker).
3 agent(grinder).
4 agent(auxilliarygrinder).
5 me(maker).
6
7 % the new agent that just joined the MAS
8 agent(newagent).
9 }
10 mailbox {
11 sent(grinder, imp(have(grounds))).
12 sent(auxilliarygrinder, imp(have(grounds))).
13 }
14 program {
15 % will execute again:
16 if bel(not(sent(allother, imp(have(grounds))))) then send(allother, !have(grounds)).
17 }
7.6.2 The agent and me facts
In Section 7.6.1 we have seen the use of variables in agent selectors, and how such a variable must
be bound in the agent selector. In the example in that section the beliefbase was populated with
2 agent(..) facts, holding the names of the agents that agent believes to exist. Using this
list of agents, program rules can be constructed that send a message to agents that satisfy some
criterium. For example, a way to send a request only to agents that are not busy could be:
if bel(agent(X), not(busy(X))) then send(X, !sweep(floor)).
Note that the agent(X) is crucial here, to get a substitution set for X, because not(busy(X))
would not yield a substitution for variable X.
The agents and me
So the agent facts allows us to select a subset of all existing agents dynamically. An advantage
of this is that it makes it possible to write dynamic agent programs, meaning we can write one
Goal program for a MAS with multiple identical agents.
Lets reiterate the last example snippet:
if bel(agent(X), not(busy(X))) then send(X, !sweep(floor)).
This will select one agent that is not busy, and send !sweep(floor) to it. Recall that
an agent fact is inserted for every existing agent, including the agent itself. Consequently, the
agent whose program rule is given here, may send !sweep(floor) to itself, as it is one of the
agent(X)s. This may not be the intended behaviour. Suppose the behaviour should be that it
only sends this imperative to other agents. We cannot use allother as agent selector, because,
while it excludes the agent itself from the recipient list, it indiscriminately sends the message to
all other agents, ignoring the selection we made in the mental state condition.
We need another way to distinguish between other agents and this agent. For this purpose,
a special me(..) fact is inserted in an agents belief base upon launch. It species the name of
the agent. So, taking the example MAS from Figure 7.4, after launch of elevator2, its belief
base consist of the following facts:
agent(manager).
agent(elevator1).
agent(elevator2).
agent(elevator3).
me(elevator2).
94 CHAPTER 7. COMMUNICATING RATIONAL AGENTS
Now the elevator program can include a rule that sends a message to any other elevator agent
excluding itself as follows:
if bel(agent(Agt), me(Me), not(Agt=Me), not(Agt=manager)) then send(Agt, !service(somefloor)).
The whole point of this is that this program rule works for every elevator agent and so it is
not necessary to make a Goal program le for each agent in which the agents would be named
explicitly.
3
. Also, if the naming scheme or the number of the elevator agents were to be changed,
the agent program would not have to be modied; only the MAS le would need to be changed.
In the case of the coee domain agents, it means that the coee maker and the coee grinder,
which are both machines that can make something out of something, can have very similar pro-
grams, sharing action rules for production and capability exploration.
7.7 send action processing
Action rules containing a send(once) action can be placed in the program section, which we
have done so far, but they may also be placed in the perceptrules section. The way send
actions are selected and executed diers among these sections. These dierences and criteria are
discussed below.
In the program section One strategy is to place the action rule in the program rules section,
as we have done so far. Lets take a look at an example:
if goal(have(X)), bel(agent(A)) then sendonce(A, !have(X)).
Suppose there are three agents, and the agent has one goal have(milk). The action selection
mechanism will pool three options of this action to choose from for execution for this round, one
send action for each agent. Only one will be selected and executed. Next round, only two options
are pooled, etc.
It will take at least three rounds to notify all agents of the goal. To send this message to all
agents at once we can use the all or allother agent selectors. But when we want to lter the
agents to which the message will be sent we can not do this.
In the perceptrules section Rules in the perceptrules section are similar to rules placed in
the program section but there are two important dierences:
1. they can not contain environment actions, and
2. all options associated with each rule in the perceptrules section are executed.
The second item is consequential for message sending. If the example action rule from the
above paragraph would have been placed in the perceptrules section, all three options would be
executed in one round, so all three agents would be notied at the same time.
In many cases, it makes more sense to handle communication in a way that all possible messages
are sent at once instead of one per round. Often, the communication is a task that needs to be
done, but should not interfere with the selection of an environment action. Examples of such
communication tasks are answering incoming interrogatives, notifying agents of our goals and
beliefs proactively, relaying messages, but also tasks that do not involve sending like handling
incoming indicatives (inserting the content in the belief base).
3
In this example the exception is the manager, as here we assume this to be a special agent that always has
this name. If there were more managers, the belief clause would contain bel(manager(Mgr), not(Agt=Mgr))
7.8. EXAMPLES 95
7.8 Examples
7.8.1 Coee domain
In Section 7.2 the coee domain was introduced. In this section the workings of the coee maker
and coee grinder are analyzed in more detail.
As mentioned before, the agents coordinate their actions by communicating in several ways
which are discussed below.
Capability exploration
The agents know what they can make themselves. This is represented as beliefs in the agent
program. For the coee maker, this look like:
beliefs {
...
canMake(maker, [coffee, espresso]).
}
To nd out what the other agents can make, the following action rules are used in the program:
% ask each agent what they can make
if bel(agent(A), not(me(A)), not(canMake(A, _)), not(sent(A, int(canMake(A, _)))))
then send(A, ?canMake(A, _)).
% answer any question about what this agent can make
if bel(me(Me), received(A, int(canMake(Me, _)), canMake(Me, Prods))
then send(A, :canMake(Me, Prods)) + delete(received(A, int(canMake(Me, _)))).
% process answers from other agents
if bel(received(Sender, canMake(Sender, Products)))
then insert(canMake(Sender, Products)) + delete(received(Sender, canMake(Sender, Products))).
The rst rule checks if there is an agent A, other than this agent, for whom this agent does not
have any belief of what it can make, and to whom this agent has not already sent an interrogative
to query it. If this is the case, send an interrogative message to ask which products that agent A
can make. Note that not(me(A)) prevents A being bound to this agent, which would otherwise
result in this agent asking itself what it can make. In this situation that would not happen, because
not(canMake(A, )) has the same eect, since this agent has a belief of what it can make (e.g.
bel(me(Me), canMake(Me, )) is true). Also recall that after execution of a send action, a
sent fact is inserted in the mailbox.
The second rule handles such incoming interrogatives. It looks in the mailbox for received
interrogative messages asking what this agent can make. It replies to the sender with an indicative
message, indicating what it can make. Also, it removes the received message from the mailbox.
This prevents this rule from being triggered repeatedly.
Finally these indicatives are handled in the third rule. The mailbox is queried for received
indicative messages, containing the information about who makes what. If such a message exists,
insert the information as a fact in the belief base. Also, the received message is removed from the
mailbox to prevent repeated execution of this program rule for this message.
Production delegation
The coee maker needs ground beans (grounds) to make coee, but it cannot grind beans. But
once it has found out that the coee grinder can grind beans into coee grounds, using the above
program rules, it can request the grinder to make grounds by sending it an imperative message.
This is represented more generically in the following action rule:
% When we cannot make some product, try to find a maker for it
if goal(have(P)), bel(requiredFor(P, R), not(have(R))), bel(canMakeIt(Maker, R), not(me(Maker)))
then send(Maker, !have(R)).
96 CHAPTER 7. COMMUNICATING RATIONAL AGENTS
When this agent has a goal to make some product P for which it needs a requirement R which
it doesnt have, and it knows of a maker of R, it sends an imperative message to that maker. The
message content is !have(R) (the R will be bound to some product at this point), indicating that
this agent has a goal to have R.
When such an imperative message is received by an agent and it can make the requested
product, it can adopt a goal to make it so:
if bel(received(A, imp(have(A, P))), me(Me), canMakeIt(Me, P))
then adopt(have(A, P)).
Note that we did not remove the message from the mailbox. This is because this agent needs a
record of who requested what. If we would remove the message, the information that an agent
requested a product would have to be persisted by some other means.
Status updates
Once a product has been made for some other agent that requires it, that agent should be informed
that the required product is ready. Agents in the Coee Domain do not give each other products
or perceive that products are available, so they rely on communication to inform each other about
that.
if bel(received(A, imp(have(P))), have(P))
then send(A, :have(P)) + delete(received(A, imp(have(P)))).
Now we do remove the received message, because we have completely handled the case.
On the receiving side of this message, reception of such an indicative message :have(P) does
not automatically result in the belief by this agent that have(P) is true. This insertion of the
belief must be done explicitly
4
.
% update beliefs with those of others (believe what they believe)
if bel(received(A, have(P)))
then insert(have(P)) + delete(received(A, have(P))).
Pro-active inform
At any time, it may be the case that an agent sees an opportunity to inform an other agent about
some fact if it thinks this agent would want to know that, without being asked. This may happen
if it believes the other agent has some goal but it believes that this goal has already been achieved.
It can then help the other agent by sending an indicative message that the goal state is achieved.
In the coee domain example, if one machine believes that another machine needs some prod-
uct, and it has that product available, then it will inform that agent of that fact:
% if some machine seems to need a product, tell it we have it
if bel(received(Machine, imp(have(X))), bel(have(X), not(sent(Machine, have(X))))
then send(Machine, :have(X)).
7.9 Notes
As noted in Chapter 1, additional concepts may be introduced to structure and design multi-
agent systems. The idea is that by imposing organizational structure on a multi-agent system
specic coordination mechanisms can be specied. Imposing an organizational structure onto a
multi-agent system is viewed by some as potentially reducing the autonomy of agents based on
4
This is where we make a leap of faith. The other agent indicated its belief in have(P). The only reason we
copy this belief is because we trust that other agent.
7.10. EXERCISES 97
a perceived tension between individual autonomy and compliance with constraints imposed by
organizations. That is, in the view of [13], an organization may restrict the actions permitted,
which would have an immediate impact on the autonomy of agents.
The mailbox semantics of Goal is very similar to the communication semantics of 2APL
[20]. The semantics of communication in many agent programming languages is of a practical
nature and less founded compared to more theoretical frameworks such as FIPA. Some APLs do
use the semantics of FIPA through middlewares such as JADE [6], which aims to comply with the
FIPA standards. FIPA introduces many primitive notions of agent communication called speech
acts. The broad range of speech act types identied, however, may complicate writing agent
programs more than that it facilitates that task and it makes sense in practice to restrict the
set of communication primitives provided by an agent programming language. In this respect we
favor the approach taken by Jason which limits the set of communication primitives to a core set.
In contrast with Jason, a set of primitives that allows communication of declarative content only
has been preferred, in line with our aim to provide an agent programming language that facilitates
declarative programming.
7.10 Exercises
7.10.1 Milk cow
The coee domain example from Section 7.8.1 has a coee maker and a coee grinder. Suppose
we now also want to make lattes. A latte is coee with milk. To provide the milk, a cow joins the
scene. The cow is empathic enough that it makes milk whenever it believes that someone needs
it.
1. Expand the list of products the coee maker can make with latte.
2. Add the knowledge that latte requires coffee and milk to that of the coee maker.
3. Write a new agent called milkcow.goal which has the following properties:
(a) It has no knowledge, beliefs or goals.
5
(b) It does not do capability exploration, but it does answer other agents questions about
what it canMake.
(c) When it notices that another agent needs milk, it will make the milk resulting in the
cows belief that have(milk).
(d) When it notices that another agent needs milk and the cow has milk, it will notify that
agent of that fact.
5
as far as humans can tell.
98 CHAPTER 7. COMMUNICATING RATIONAL AGENTS
7.11 Appendix
7.11. APPENDIX 99
GOAL
1 % This agent represents the coffee machine. Its function is to supply a user
2 % with nice steaming fresh cups of coffee. It knows how to make coffee and
3 % espresso. It will communicate to find out who can make what. Notice that the
4 % program and perceptrules sections contain no literals.
5
6 % In fact, the program,perceptrules and actionspec implement a machine capable
7 % of making certain products, if it has all required ingredients, and finding
8 % producers of ingredients it cannot make itself.
9
10 main: coffeeMaker {
11 knowledge {
12 requiredFor(coffee, water).
13 requiredFor(coffee, grounds).
14 requiredFor(espresso, coffee).
15 requiredFor(grounds, beans).
16 canMakeIt(M, P) :- canMake(M, Prods), member(P, Prods).
17 }
18 beliefs {
19 have(water). have(beans).
20 canMake(maker, [coffee, espresso]).
21 }
22 goals {
23 have(latte).
24 }
25 program {
26 % if we need to make something, then make it (the actions precondition
27 % checks if we have what it takes, literally)
28 if goal(have(P)) then make(P).
29 }
30 actionspec {
31 make(Prod) {
32 pre { forall(requiredFor(Prod, Req), have(Req)) }
33 post { have(Prod) }
34 }
35 }
36 perceptrules {
37 % capability exploration:
38 % ask each agent what they can make
39 if bel(agent(A), not(me(A)), not(canMake(A, _))) then sendonce(A, ?canMake(A, _)).
40 % answer any question about what this agent can make
41 if bel(me(Me), received(A, int(canMake(Me, _))), canMake(Me, Prod))
42 then sendonce(A, :canMake(Me, Prod)).
43 % process answers from other agents
44 if bel(received(Sender, canMake(Sender, Products))) then insert(canMake(Sender, Products))
45 + delete(received(Sender, canMake(Sender, Products))).
46
47 % update beliefs with those of others (believe what they believe)
48 if bel(agent(A), received(A, have(X))), not(bel(have(X))) then insert(have(X)).
49
50 % If we need some ingredient, see if we can make it ourselves
51 if goal(have(P)), bel(requiredFor(P, R), not(have(R))),
52 bel(canMakeIt(Me, R), me(Me)) then adopt(have(R)).
53 % else try to find a maker for it
54 if goal(have(P)), bel(requiredFor(P, R), not(have(R))),
55 bel(canMakeIt(Maker, R), not(me(Maker))) then sendonce(Maker, !have(R)).
56 % else just broadcast our need
57 if goal(have(P)), bel(requiredFor(P, R), not(have(R)), me(Me), not(canMakeIt(Me, P)))
58 then sendonce(allother, !have(R)).
59
60 % if some machine seems to need a product, tell it we have it
61 if bel(agent(Machine), received(Machine, imp(have(X))), have(X))
62 then sendonce(Machine, :have(X)).
63 }
64 }
Figure 7.7: Coee maker agent
100 CHAPTER 7. COMMUNICATING RATIONAL AGENTS
GOAL
1 % The Coffee Grinder is an agent capable of grinding coffee beans into grounds.
2 % For making grounds it needs coffee beans. Whenever it needs beans it will
3 % announce as much by sending an imperative "!have(beans)" to allother agents.
4
5 main: coffeegrinder {
6
7 knowledge {
8 requiredFor(grounds, beans).
9 canMakeIt(M, P) :- canMake(M, Prods), member(P, Prods).
10 }
11 beliefs {
12 canMake(grinder, [grounds]).
13 }
14 goals {}
15 program {
16 % if we need to make something, then make it (the actions precondition
17 % checks if we have what it takes, literally)
18 if goal(have(P)) then make(P).
19 }
20 actionspec {
21 make(Prod) {
22 pre { forall(requiredFor(Prod, Req), have(Req)) }
23 post { have(Prod) }
24 }
25 }
26 perceptrules {
27 % capability exploration:
28
29 % ask each agent what they can make
30 if bel(agent(A), not(me(A)), not(canMake(A, _)))
31 then sendonce(A, ?canMake(A, _)).
32 % answer any question about what this agent can make
33 if bel(me(Me), received(A, int(canMake(Me, _))), canMake(Me, Prod))
34 then sendonce(A, :canMake(Me, Prod)).
35 % process answers from other agents
36 if bel(received(Sender, canMake(Sender, Products)))
37 then insert(canMake(Sender, Products))
38 + delete(received(Sender, canMake(Sender, Products))).
39
40 % update beliefs with those of others (believe what they believe)
41 if bel(agent(A), received(A, have(X))), not(bel(have(X))) then insert(have(X)).
42
43 % if we want to make grounds, but have no beans, announce that we need beans
44 if goal(have(P)), bel(requiredFor(P, R), not(have(R)), me(Me), not(canMakeIt(Me, P)))
45 then sendonce(allother, !have(R)).
46
47 % if some agent needs grounds, then adopt the goal to make it
48 if bel(received(_, imp(have(grounds)))) then adopt(have(grounds))
49 + delete(received(_, imp(have(grounds)))).
50
51 % if some machine seems to need a product, tell it we have it
52 bel(agent(Machine), received(Machine, imp(have(X))),
53 have(X)) then sendonce(Machine, :have(X)).
54 }
55 }
Figure 7.8: Coee grinder agent
Chapter 8
Reasoning About Agents
In this chapter we introduce the formal semantics of Goal and discuss the verication framework
for the language. The semantics of Goal consists of several more or less independent parts. The
rst part denes the semantics of the agents mental state and the mental state conditions that can
be used to inspect such states. The second part denes the semantics of actions and the agents
action rules used for choosing an action to perform. The various parts combined together dene
the operational semantics of Goal.
8.1 Semantics of Mental States
Goal is a general-purpose agent programming language. The basic design of the language assumes
that beliefs and goals of an agent are specied in a declarative way. Beliefs of a Goal agent thus
do not encode procedural knowledge but represent what is the case and goals of a Goal agent do
not specify which actions an agent wants to perform but represent what state an agent wants to
achieve. The main benet of using declarative specications to represent an agents beliefs and
goals is that it allows an agent to reason with its beliefs and goals. Goal thus aims to facilitate
the design of agent programs at the knowledge level [53].
An agents mental state consists of its knowledge, its beliefs and its goals as explained in
Section 5.2. In the current implementation of Goal these are represented in Prolog [68, 69].
The knowledge and beliefs of an agent in this implementation are stored in two dierent Prolog
databases; the storage of goals in this implementation is slightly more complicated because of
the dierence in semantics of goals and beliefs. The details are not important here, however,
since the main point we want to make is that Goal does not commit to any particular knowledge
representation technology. Instead of Prolog an agent might use variants of logic programming such
as Answer Set Programming (ASP; [3]), a database language such as Datalog [14], the Planning
Domain Denition Language (PDDL; [27]), or other, similar such languages, or possibly even
Bayesian Networks [56]. The only assumption that we will make throughout is that an agent uses
a single knowledge representation technology to represent its knowledge, beliefs and goals. For
some preliminary work on lifting this assumption, we refer the reader to [21].
In order to abstract from the details of any specic knowledge representation technology in the
presentation of the semantics of Goal, we rst dene abstractly what we mean by a knowledge
representation technology. The basic capabilities that we need such a technology to provide are
the capability to represent states of aairs (which is fundamental), the capability to store these
representations in a storage facility, the capability to reason with them and the capability to
change the representations present in a storage. These capabilities are similar to some of the
functions associated with a knowledge technology as discussed in [22].
The rst capability to represent states of aairs is realized by means of a language. The only
assumptions we make about this language is that it denes what a formula is and that it contains
a special formula . In other words, we assume that a language denes the grammar or syntax of
101
102 CHAPTER 8. REASONING ABOUT AGENTS
well-formed formulae. We write / to denote that is a formula of language /; in particular,
we have /. Intuitively, we think of a formula as a sentence that expresses that a state of
aairs is the case (or not) similar to declarative sentences in natural language. Although the
meaning of formulae of a language is not formally dened, informally, we think of a formula as
having a truth value and of a formula being true or false (but other possible truth values such
as undened are also allowed). The special formula is assumed to always have the truth value
false and is introduced to be able to dene when a set of formulae is inconsistent.
The second capability to store representations is formalised here by means of the notion of a
set. We thus abstract from most implementation details typically associated with this capability.
A knowledge, belief and goal base each are represented in the semantics as a set of formulae, or,
equivalently, as a subset of a language /. Below we use K / to denote a knowledge base, /
to denote a belief base, and / to denote a goal base.
The third capability is realized by means of a consequence relation (also called entailment). A
consequence relation denes when a formula follows from (is a consequence of) a set of formulae.
We use [= to denote consequence relations and write T [= for follows from a set of formulae T.
For example, a formula follows from an agents belief base whenever we have [= . When
the special formula follows from a set T we say that T is inconsistent; the intuition here is that
in that case T is contradictory, something we typically want to avoid. For example, we would
like an agents knowledge and belief base to be consistent. A consequence relation is the formal
counterpart of the reasoning capability of an agent in the semantics since it allows an agent to
derive and reason with its knowledge, beliefs, and goals.
The fourth and nal capability we need is the capability to update an agents beliefs.
1
Recall
that an agents knowledge base is assumed to be static and does not change since it is assumed
to represent conceptual and domain knowledge that does not change (see also section 5.1). In
particular we will need to be able to dene how an agents beliefs change when it performs an
action. In order to do so an update operator denoted by is assumed that updates a set of
formulae T with a formula . That is, T denotes the new set of formulae obtained after
updating T with . This will enable us in the next section to say that the resulting belief base of
updating a belief base with the eect of an action is . See section 5.2 for a concrete,
informally dened STRIPS-style operator.
Summarizing, a knowledge representation technology is dened here as a triple /, [=, with
/ a language to represent states of aairs, [= a consequence relation that denes when a formula
follows from a set of formulae, and denes how a set of formulae is updated with a given formula.
2
Using our denition of a knowledge representation technology, it is now easy to formally dene
what a mental state of an agent is and to formally dene the semantics of mental state conditions.
We rst dene a mental state, since it is needed to dene the semantics of mental state conditions
as well, and then proceeed to discuss mental state conditions.
A mental state consists of an agents knowledge, its beliefs, and its goals. Each of these are
represented using a particular knowledge representation language /. The knowledge, beliefs and
goals of a rational agent should satisfy some additional constraints that we will call rationality
constraints. First, we assume that an agents knowledge as well as its beliefs are consistent. This
is a reasonable assumption, which may be debated by philosophers, logicians and psychologists,
but makes sense in the context of an agent programming language. We also assume that individual
goals in the goal base of an agent are consistent. It is irrational for an agent to pursue
inconsisent goals, which by denition it cannot achieve. The reason that we require single goals in
a goal base to be consistent but not conjunctions of multiple goals is that we allow an agent to have
conicting goals in its goal base. For example, an agent may want to achieve a state where the
light is on but thereafter may want to achieve a state where the light is o again. Here we assume
that the language used to express goals is not capable of expressing such temporal dimensions of
1
In the setup we use here, we do not need a special capability to update the goal base when an agent comes to
believe it has achieved a goal; in that case we simply remove the goal from the goal base, which is a set-theoretic
operation; see the next section.
2
Technically, we would also need to clarify the notion of a term which may be used to instantiate a variable in
order to specify the use of variables in a Goal agent, but we abstract from such details here.
8.1. SEMANTICS OF MENTAL STATES 103
goals and therefore allow an agent to have multiple goals that when viewed as a single goal would
be inconsistent. The main reason for allowing contradictory goals thus is not because we believe
that the goals of an agent may be inconsistent but because of the (assumed) lack of expressivity of
the knowledge representation language used to represent goals here.
3
Finally, an agent is assumed
to only have goals which it does not believe to already have been achieved completely. Any rational
agent should avoid investing resources into achieving something that is already the case. For that
reason it should not have any goals that have already been achieved. Note that an agent is allowed
but not required to believe that the opposite of what it wants is the case; for example, it may
believe the light is on when it wants to have the light o but does not need to believe so to have
the goal.
Denition 8.1.1 (Mental State)
A mental state is a triple K, , where K / is called a knowledge base, / is a belief base,
and / is a goal base that satisfy the following rationality constraints:
An agents knowledge combined with its beliefs is consistent:
K ,[=
Individual goals are consistent with an agents knowledge:
: K ,[=
An agent does not have goals it believes to be completely achieved:
4
: K ,[=
The next step in dening the semantics of Goal is to dene the semantics of mental state
conditions. An agent needs to be able to inspect its mental state, and mental state conditions
allow an agent to do so. Mental state conditions are conditions on the mental state of an agent,
expressing that an agent believes something is the case, has a particular goal, or a combination
of the two (see also section 5.1). Special operators to inspect the belief base of an agent, we use
bel() here, and to inspect the goal base of an agent, we use goal() here, are introduced to do so.
We allow boolean combinations of these basic conditions but do not allow the nesting of operators.
Basic conditions may be combined into a conjunction by means of and negated by means of .
For example, goal() bel() with / is a mental state condition, but bel(goal()) which
has nested operators is not. Note that we do not assume the operators and to be present in
the /, and if so, a negation operator might still have a dierent meaning in /.
Denition 8.1.2 (Syntax of Mental State Conditions)
A mental state condition is dened by the following rules:
::= any element from /
::= bel() [ goal() [ [
The meaning of a mental state condition is dened by means of the mental state of an agent.
A belief condition bel() is true whenever follows from the belief base combined with the
knowledge stored in the agents knowledge base (in order to dene this the consequence relation
3
See for work on extending Goal with temporal logic as a knowledge representation language [33, 38].
4
The precise formulation of the rationality constraints relating the contents of the goal base to that of the
knowledge and/or belief base of an agent may depend on the knowledge representation language. In particular,
when the knowledge representation language allows for expressing temporal conditions, e.g. allows for expressing
that a state of aairs holds at some time in the future, then these constraints and the semantics of the goal operator
below would be in need of reformulation (see [40]). In that case, the third rationality constraint also could be rened
and in addition we could require that an agent should not have any goals it believes are impossible to achieve (a
condition which can only be properly expressed using temporal operators).
104 CHAPTER 8. REASONING ABOUT AGENTS
P1 if is an instantiation of a classical tautology, then [=
c
.
P2 if [= , then [=
c
bel.
P3 [=
c
bel(

) (bel bel

).
P4 [=
c
bel.
P5 [=
c
goal.
P6 if [=

, then [=
c
goal goal

.
Table 8.1: Properties of Beliefs and Goals
of the knowledge representation technology is used). The meaning of a goal condition goal() is
dierent from that of a belief condition. Instead of simply dening goal() to be true whenever
follows from all of the agents goals (combined with the knowledge in the knowledge base), we
will dene goal() to be true whenever follows from one of the agents goals (and the agents
knowledge). This is in line with the remarks above that a goal base may be inconsistent, i.e. may
contain multiple goals that taken together are inconsistent. We do not want an agent to conclude
it has the absurd goal (i.e. to achieve the impossible). Since individual goals are assumed to be
consistent, we can use these individual goals to infer the goals of an agent.
Denition 8.1.3 (Semantics of Mental State Conditions)
Let m = K, , be a mental state. The semantics of mental state conditions is dened by
the following semantic clauses:
m [=
c
bel() i K [= ,
m [=
c
goal() i : K [= ,
m [=
c

1

2
i m [=
c

1
and m [=
c

2
,
m [=
c
i m ,[=
c
.
Note that in the denition of the semantics of mental state conditions we have been careful to
distinguish between the consequence relation that is dened, denoted by [=
c
, and the consequence
relation [= assumed to be given by the knowledge representation technology and used to dene
[=
c
. The denition thus shows how the meaning of a mental state condition can be derived from
the semantics of more basic notions dened in an arbitrary knowledge representation technology.
5
In the remainder of this section, it is useful to assume that the knowledge representation
language at least provides the propositional operators for conjunction and negation. Here we will
simply use the same notation and also used for mental state conditions to refer to these
operators in the knowledge representation language / as well. Given this assumption, note that
because of the fact that a goal base may contain multiple goals that are inconsistent when taken
together, it follows that we may have that goal() as well as goal(). It should be clear from
our previous discussion however that it does not follow from this that goal() also holds. To
repeat, intuitively, goal() should be interpreted as expressing that the agent wants to achieve
some time in the future. Given this reading of goal() it is perfectly consistent for an agent to
also have a goal , i.e. goal().
Some other properties of the belief and goal modalities and the relation between these operators
are listed in Table 8.1. Here, we use to denote implication, which can be dened in the usual way
by means of the conjunction and negation . The rst property (P1) below states that mental
state conditions that instantiate classical tautologies, e.g. bel bel and goal (bel

goal), are valid with respect to [=
c
. Property (P2) corresponds with the usual necessitation rule
of modal logic and states that an agent believes all validities of the base logic. (P3) expresses
that the belief modality distributes over implication. This implies that the beliefs of an agent are
closed under logical consequence. Finally, (P4) states that the beliefs of an agent are consistent.
5
This semantics was rst introduced in [36]. For a discussion of alternative semantics for goals, see also [61].
8.2. SEMANTICS OF ACTIONS AND ACTION SELECTION 105
In essence, the belief operator thus satises the properties of the system KD (see e.g. [51]).
Although in its current presentation, it is not allowed to nest belief or goal operators in mental
state conditions in Goal, from [51], section 1.7, we conclude that we may assume as if our agent
has positive (bel belbel) and negative (bel belbel) introspective properties:
every formula in the system KD45 (which is KD together with the two mentioned properties) is
equivalent to a formula without nestings of operators. Property (P5) states that an agent also
does not have inconsistent goals, that is, we have [=
c
goal. Property (P6) states that the goal
operator is closed under implication in the base language. That is, whenever

is valid in
the base language then we also have that goal implies goal

. This is a dierence with the

presentation in [9] which is due to the more basic goal modality we have introduced here. For the
same reason we also have that bel goal is not inconsistent.
We may now put our denitions to work and provide some examples of what we can do. First,
as discussed in section 5.1, we can introduce some useful abbrevations. In particular, we can
dene the notions of an achievement goal a-goal() and the notion of a goal achieved goal-a()
as follows:
a-goal()
df
= goal() bel(),
goal-a()
df
= goal() bel().
For some properties of the a-goal operator we refer the reader to [9], Lemma 2.4. Both of these
dened operators are useful when writing agent programs. The rst is useful to derive whether a
part of a goal has not yet been (believed to be) achieved whereas the second is useful to derive
whether a part of a goal has already been (believed to be) achieved. For some concrete examples,
please refer back to section 5.1. It should be noted that an agent is allowed to believe part of one
of its goals has been achieved but cannot believe that one of its goals has been completely achieved
as such goals are removed automatically from the goal base. That is, whenever we have
we must have both a-goal() as well as goal() since it is not allowed by the third rationality
constraint in Denition 8.1.1 that an agent believes in that case.
Note that in this section we have only used the rst two components of a knowledge repre-
sentation technology, the language / and consequence relation [=, so far. We will use the third
component, the update operator , in the next section to formally dene the eects of performing
an action.
8.2 Semantics of Actions and Action Selection
Goal has a formal, operational semantics dened by means of Plotkin-style transition semantics
[57]. The details of the semantics of modules and communication are not discussed here.
6
In order to dene the semantics of actions, we need to model both when an action can be per-
formed as well as what the eects of performing an action are. As actions, except for the built-in
actions, are user-dened, we introduce some assumptions about what information is available to
dene the semantics. First, we assume that it is known which actions the agent can perform,
i.e. those actions specied by the programmer in the agent program, and that these actions are
given by a set /. Second, we assume that two mappings pre and post which map actions a
from this set of actions / and mental states m to a formula in the knowledge representation
language / are given. The mappings pre and post are assumed to provide the preconditions re-
spectively postconditions associated with an action in a given state. For example, we would have
pre(move(a,table), m)=clear(a), clear(table), on(a,b) in the initial state mental
mof the Goal agent listed in Table 5.2 and post(move(a,b), m)=not(on(a,b)),on(a,table).
Finally, we also assume that the postconditions specied by post for each action are consistent
with the domain knowledge of the agent. As the domain knowledge of an agent is assumed to be
6
The reader is referred to [32] for a detailed semantics of modules. Communication in the current implementation
of Goal implements a simple mailbox semantics as in 2APL [20]. In Goal, messages are stored in an agents
mailbox and may be inspected by querying special, reserved predicates sent and received. See for a discussion
also section ??.
106 CHAPTER 8. REASONING ABOUT AGENTS
static, it would not be possible to perform an action with a postcondition that conicts with the
agents domain knowledge without violating the rationality constraints introduced earlier.
The precondition of an action is used to represent when an action can be performed, whereas
the postcondition is used to represent the eects of an action. An action may aect both the
beliefs and goals of an agent. The postcondition expresses how the beliefs of an agents mental
state should be updated. This is where the update operator of the knowledge representation
technology is useful. The new belief base that results from performing an action a / can be
obtained by applying this operator. In addition, the goals that have been completely achieved need
to be removed from the goal base. This transformation of the mental state is formally dened by
means of a mental state transformer function /, which also provides the semantics of the built-in
actions adopt and drop below.
Denition 8.2.1 (Mental State Transformer /)
Let pre and post be mappings from / to /. Then the mental state transformer function / is
dened as a mapping from user-dened and built-in actions /adopt(), drop() [ / and
mental states m = K, , to mental states as follows:
/(a, m) =

K,

, Th(K

) if K [= pre(a, m)
undened otherwise
/(adopt(), m) =

K, , if ,[= and ,[=

undened otherwise
/(drop(), m) = , [ [=
where

= post(a, m) and Th(T) = / [ T [= .

As discussed above, an action rule r is of the form if then a. An action rule species that
action a may be performed if the mental state condition and the precondition of a hold. In that
case, we say that action a is an option. At runtime, a Goal agent non-deterministically selects an
action from the set of options. This is expressed in the following transition rule, describing how
an agent gets from one mental state to another.
Denition 8.2.2 (Action Semantics)
Let m be a mental state, and r =if then a be an action rule. The transition relation
a
is
the smallest relation induced by the following transition rule.
m [=
c
/(a, m) is dened
m
a
/(a, m)
The execution of a Goal agent results in a computation. We dene a computation as a
sequence of mental states and actions, such that each mental state can be obtained from the
previous by applying the transition rule of Denition 8.2.2. As Goal agents are non-deterministic,
the semantics of a Goal agent is dened as the set of possible computations of the Goal agent,
where all computations start in the initial mental state of the agent.
Denition 8.2.3 (Computation)
A computation, typically denoted by t, is an innite sequence of mental states m
0
, a
0
, m
1
, a
1
, m
2
, a
2
, . . .
such that for each i we have that m
i
ai
m
i+1
can be derived using the transition rule of Denition
8.2.2, or for all j > i, m
j
= m
i
and m
i
,
a
m

for any a and m

. The meaning S of a Goal agent

with initial mental state m
0
is the set of all computations starting in that state. We also write t
m
i
to denote the ith mental state and t
a
i
to denote the ith action.
Observe that a computation is innite by denition, even if the agent is not able to perform any
action anymore from some point in time on. Also note that the concept of an agent computation is
a general notion in program semantics that is not particular to Goal. The notion of a computation
can be dened for any agent programming language that is provided with a well-dened operational
semantics.
8.3. VERIFICATION FRAMEWORK 107
8.3 Verication Framework
A formal verication framework exists to verify properties of Goal agents [9]. This verication
framework allows for compositional verication of Goal agents and has been related to Intention
Logic [33]. The language Goal thus is rmly rooted in agent theory.
The verication logic for GOAL is based on Linear Temporal Logic extended with modal
operators for beliefs and goals. In addition the logic includes a set of Hoare rules to reason about
actions [9]. The setup of the verication framework has some similarities with that for Unity [15].
To obtain a verication logic for Goal agents temporal operators are added on top of mental
state conditions to be able to express temporal properties over traces. Additionally an operator
start is introduced to be able to pinpoint the start of a trace.
7
Denition 8.3.1 (Temporal Language: Syntax)
The temporal language /
G
, with typical elements ,

, is dened by:
/
G
::= start [ /

[ [ [ until
The semantics of /
G
is dened relative to a trace t and time point i.
Denition 8.3.2 (Temporal Language: Semantics)
The truth conditions of sentences from /
G
given a trace t and time point i are inductively dened
by:
t, i [= start i i = 0,
t, i [= bel i t
m
i
[=
c
bel,
t, i [= goal i t
m
i
[=
c
goal,
t, i [= i t, i ,[= ,
t, i [= i t, i [= and t, i [= ,
t, i [= _ i t, i + 1 [= ,
t, i [= until i j i : t, j [= and i k < j : t, k [=
Using the until operator, other temporal operators such as the sometime in the future
operator and the always in the future operator can be dened by ::= true until
and ::= .
The temporal logic introduced above has provided a basis for a Maude [16] implementation for
the Goal language which facilitates model checking of Goal agents.
8.4 Notes
See [42] for more on model checking Goal agent programs.
8.5 Exercises
8.5.1
Prove that the execution of an action by an agent will never lead to a mental state that
violates the rationality constraint : ,[= . (Hint: Prove by case distinction that
each of the built-in actions nor any possible user-specied action can lead to a violation.)
7
Here, only the temporal semantics is presented. The compositional verication of an agent program also requires
reasoning about actions. [9] introduces so-called Hoare rules to do so. In [33] an operator [a] for reasoning about
actions is introduced as this makes it easier to relate the verication logic for Goal to Intention Logic [17].
108 CHAPTER 8. REASONING ABOUT AGENTS
Bibliography
[1] Baader, F., Calvanese, D., McGuinness, D., Nardi, D., Patel-Schneider, P. (eds.): The De-
scription Logic Handbook. Cambridge University Press (2003)
[2] Bachmair, L., Ganzinger, H.: Handbook of Automated Reasoning, chap. Resolution Theorem
Proving, pp. 1999. Elsevier and MIT Press (2001)
[3] Baral, C.: Knowledge Representation, Reasoning and Declarative Problem Solving. Cam-
bridge University Pres (2003)
[4] Barandiaran, X., Paolo, E.D., Rohde, M.: Dening agency: individuality, normativity, asym-
metry and spatio-temporality in action. Adaptive Behavior 17(5), 367386 (2009)
[5] Behrens, T.M., Dix, J., Hindriks, K.V.: Towards an environment interface standard for agent-
oriented programming. Tech. Rep. IfI-09-09, Clausthal University (2009)
[6] Bellifemine, F., Caire, G., Greenwood, D. (eds.): Developing Multi-Agent Systems with
JADE. No. 15 in Agent Technology. John Wiley & Sons, Ltd. (2007)
[7] Ben-Ari, M.: Principles of the Spin Model Checker. Springer (2007)
[8] Besnard, P.: An Introduction to Default Logic. Springer-Verlag (1989)
[9] de Boer, F., Hindriks, K., van der Hoek, W., Meyer, J.J.: A Verication Framework for Agent
Programming with Declarative Goals. Journal of Applied Logic 5(2), 277302 (2007)
[10] Boolos, G.S., Burgess, J.P., Jerey, R.C.: Computability and Logic, fourth edn. Cambridge
University Press (2002)
[11] Bordini, R.H., Hbner, J.F., Wooldridge, M.: Programming Multi-Agent Systems in AgentS-
peak using Jason. John Wiley & Sons (2007)
[12] Boutilier, C.: A unied model of qualitative belief change: A dynamical systems perspective.
Articial Intelligence 1-2, 281316 (1998)
[13] Bradshaw, J., Feltovich, P., Jung, H., Kulkarni, S., Taysom, W., Uszok, A.: Dimensions of
adjustable autonomy and mixed-initiative interaction. In: Autonomy 2003, LNAI, vol. 2969,
pp. 1739 (2004)
[14] Ceri, S., Gottlob, G., Tanca, L.: What you always wanted to know about datalog (and never
dared to ask). IEEE Trans. of KDE 1(1) (1989)
[15] Chandy, K.M., Misra, J.: Parallel Program Design. Addison-Wesley (1988)
[16] Clavel, M., Duran, F., Eker, S., Lincoln, P., Mart-Oliet, N., Meseguer, J., Quesada, J.F.:
Maude: Specication and programming in rewriting logic. Theoretical Computer Science
285(2), 187243 (2002)
[17] Cohen, P.R., Levesque, H.J.: Intention Is Choice with Commitment. Articial Intelligence
42, 213261 (1990)
109
110 BIBLIOGRAPHY
[18] Cook, S., Liu, Y.: A Complete Axiomatization for Blocks World. Journal of Logic and
Computation 13(4), 581594 (2003)
[19] van Dalen, D.: Logic and Structure, 3rd edn. Springer-Verlag, Berlin (1997)
[20] Dastani, M.: 2apl: a practical agent programming language. Journal Autonomous Agents
and Multi-Agent Systems 16(3), 214248 (2008)
[21] Dastani, M., Hindriks, K.V., Novak, P., Tinnemeier, N.A.: Combining multiple knowledge
representation technologies into agent programming languages. In: Proceedings of the In-
ternational Workshop on Declarative Agent Languages and Theories (DALT08) (2008). To
appear
[22] Davis, R., Shrobe, H.E., Szolovits, P.: What is a knowledge representation? AI 14(1), 1733
(1993)
[23] Dennett, D.C.: The Intentional Stance, 8 edn. The MIT Press (2002)
[24] Doyle, J.: Philosophy and AI: Essays at the Interface, chap. The Foundations of Psychology:
A Logico-Computational Inquiry into the Concept of Mind, pp. 3978. The MIT Press (1991)
[25] Fagin, R., Halpern, J.Y., Moses, Y., Vardi, M.Y.: Reasoning About Knowledge. MIT Press
(1995)
[26] Forguson, L.: Common Sense. Routledge (1989)
[27] Ghallab, M., Nau, D., Traverso, P.: Automated Planning: Theory and Practice. Morgan
Kaufmann (2004)
[28] Goertzel, B., Pascal, H., Hutter, M. (eds.): Proceedings of the Second Conference on Articial
General Intelligence (2009)
[29] Grice, H.: Meaning. Philosophical Review 66, 37788 (1957)
[30] Grice, H.: Utterers meaning and intentions. Philosophical Review 78, 14777 (1969)
[31] Gupta, N., Nau, D.S.: On the Complexity of Blocks-World Planning. Articial Intelligence
56(2-3), 223254 (1992)
[32] Hindriks, K.: Modules as policy-based intentions: Modular agent programming in goal.
In: Proceedings of the International Workshop on Programming Multi-Agent Systems (Pro-
MAS07), vol. 4908 (2008)
[33] Hindriks, K., van der Hoek, W.: Goal agents instantiate intention logic. In: Proceedings of
the 11th European Conference on Logics in Articial Intelligence (JELIA08), pp. 232244
(2008)
[34] Hindriks, K., Jonker, C., Pasman, W.: Exploring heuristic action selection in agent program-
ming. In: Proceedings of the International Workshop on Programming Multi-Agent Systems
(ProMAS08) (2008)
[35] Hindriks, K.V., de Boer, F.S., van der Hoek, W., Meyer, J.J.C.: Agent Programming in
3APL. Autonomous Agents and Multi-Agent Systems 2(4), 357401 (1999)
[36] Hindriks, K.V., de Boer, F.S., van der Hoek, W., Meyer, J.J.C.: Agent Programming with
Declarative Goals. In: Proceedings of the 7th International Workshop on Agent Theories
Architectures and Languages, LNCS, vol. 1986, pp. 228243 (2000)
[37] Hindriks, K.V., Pasman, W.: The GOAL IDE Manual.
http://mmi.tudelft.nl/koen/goal.html (2009)
BIBLIOGRAPHY 111
[38] Hindriks, K.V., van Riemsdijk, M.B.: Using temporal logic to integrate goals and qualitative
preferences into agent programming. In: Proceedings of the International Workshop on
Declarative Agent Languages and Theories, vol. 5397, pp. 215232 (2008)
[39] Hindriks, K.V., van Riemsdijk, M.B.: A computational semantics for communicating rational
agents based on mental models. In: Proceedings of the 6th International Conference on
Programming Agents and Multi-Agent Systems (2009)
[40] Hindriks, K.V., van Riemsdijk, M.B., van der Hoek, W.: Agent programming with temporally
extended goals. In: Proceedings of the 8th International Conference on Autonomous Agents
and Multi-Agent Systems (2009)
[41] van der Hoek, W., van Linder, B., Meyer, J.J.: An Integrated Modal Approach to Rational
Agents. In: M. Wooldridge (ed.) Foundations of Rational Agency, Applied Logic Series 14,
pp. 133168. Kluwer, Dordrecht (1999)
[42] Jongmans, S.S.T.Q., Hindriks, K.V., van Riemsdijk, M.B.: Model checking agent programs
by using the program interpreter. In: Computational Logic in Multi-Agent Systems, pp.
219237 (2010)
[43] Kumar, V.: Algorithms for constraint satisfaction problems. AI Magazine 13(1), 3244 (1992)
[44] Lifschitz, V.: On the semantics of strips. In: M. George, A. Lansky (eds.) Reasoning about
Actions and Plans, pp. 19. Morgan Kaufman (1986)
[45] Lifschitz, V., Morgenstern, L., Plaisted, D.: Knowledge Representation and Classical Logic.
In: F. van Harmelen, V. Lifschitz, B. Porter (eds.) Handbook of Knowledge Representation,
pp. 388. Elsevier (2008)
[46] Luck, M., dInverno, M.: Motivated behaviour for goal adoption. In: Multi-Agent Systems:
Theories, Languages and Applications - 4th Australian Workshop on Distributed Articial
Intelligence, pp. 5873 (1998)
[47] McCarthy, J.: Programs with common sense. In: Proceedings of the Teddington Conference
on the Mechanization of Thought Processes, pp. 7591. Her Majestys Stationary Oce,
London (1959)
[48] McCarthy, J.: Ascribing mental qualities to machines. Tech. rep., Stanford AI Lab, Stanford,
CA (1979)
[49] McCune, W.: Mace4 reference manual and guide. Tech. Rep. ANL/MCS-TM-264, Mathe-
matics and Computer Science Division, Argonne National Laboratory, Argonne, IL (2003)
[50] Mendelson, E.: Introduction to Mathematical Logic. D. Van Nostrand Company (1979)
[51] Meyer, J.J.C., van der Hoek, W.: Epistemic Logic for AI and Computer Science. Cambridge:
Cambridge University Press (1995)
[52] Minsky, M.: A framework for representing knowledge. In: J. Haughland (ed.) Mind Design,
pp. 95128. MIT Press (1981)
[53] Newell, A.: The Knowledge Level. Articial Intelligence 18(1), 87127 (1982)
[54] Newell, A., Simon, H.A.: GPS, a program that simulates human thought. In: E. Feigenbaum,
J. Feldman (eds.) Computers and Thought. New York: McGraw-Hill (1963)
[55] Padgham, L., Lambrix, P.: Agent capabilities: Extending bdi theory. In: Proc. of the 7th
National Conference on Arti cial Intelligence - AAAI2000, pp. 6873 (2000)
112 BIBLIOGRAPHY
[56] Pearl, J.: Probabilistic Reasoning in Intelligent Systems - Networks of Plausible Inference.
Morgan Kaufmann (1988)
[57] Plotkin, G.: A Structural Approach to Operational Semantics. Tech. Rep. DAIMI FN-19,
University of Aarhus (1981)
[58] Pollock, J.L.: Philosophy and AI: Essays at the Interface, chap. OSCAR: A General Theory
of Rationality, pp. 189214. The MIT Press (1991)
[59] Quine, W.V.: Methods of Logic. London (1952)
[60] Rao, A.S., George, M.P.: Intentions and Rational Commitment. Tech. Rep. 8, Australian
Articial Intelligence Institute (1993)
[61] van Riemsdijk, M.B., Dastani, M., Meyer, J.J.C.: Goals in conict: semantic foundations of
goals in agent programming. Autonomous Agents and Multi-Agent Systems (2008). Online
[62] Russell, S., Norvig, P.: Articial Intelligence: A Modern Approach, 2nd edn. Prentice Hall
(2003)
[63] Schoppers, M.: Universal plans for reactive robots in unpredictable environments. In: Pro-
ceedings of the Tenth International Joint Conference on Articial Intelligence (IJCAI87)
(1987)
[64] Scowen, R.S.: Extended BNF - A generic base standard.
http://www.cl.cam.ac.uk/mgk25/iso-14977-paper.pdf (1996)
[65] Shoham, Y.: Implementing the Intentional Stance. In: R. Cummins, J. Pollock (eds.) Phi-
losophy and AI: Essays at the Interface, chap. 11, pp. 261277. MIT Press (1991)
[66] Shoham, Y.: Agent-oriented programming. Articial Intelligence 60, 5192 (1993)
[67] Slaney, J., Thiebaux, S.: Blocks World revisited. Articial Intelligence 125, 119153 (2001)
[68] Sterling, L., Shapiro, E.: The Art of Prolog, 2nd edn. MIT Press (1994)
[69] http://www.swi-prolog.org/ (2008)
[70] Wang, P., Goertzel, B., Franklin, S. (eds.): Articial General Intelligence 2008: Proceedings
of the First AGI Conference (2008)
[71] Watt, S.: The naive psychology manifesto. ?? (1995)
[72] Winograd, T.: Understanding Natural Language. Academic Press, New York (1972)
[73] Wooldridge, M., Jennings, N.R.: Intelligent agents: Theory and practice. Knowledge Engi-
neering Review 10, 115152 (1995)
Appendix A
SWI Prolog Operators in GOAL
Most built-in operators of SWI Prolog [69] can be used in Goal as well. Since SWI Prolog provides
hundreds of operators, instead of listing the operators that are also supported by Goal we list
only those operators available in SWI Prolog that can not be used in Goal. For an overview
of operators provided by SWI Prolog please consult the SWI Prolog reference manual [69]. An
overview of all operators supported by Goal is provided with the distribution of Goal itself.
Please consult the Goal User Manual [37].
The operators that can not be used are the following: assert, asserta, assertz, retract,
abolish, : (the operator used for modules), dynamic, multifile, discontiguous, op,
char conversion, initialization, ensure loaded, catch, and throw.
113
Index
action, 7, 15, 16, 1922, 2528, 30
applicable, 28
built-in, 1921, 26, 41
enabled, 28
option, 28
policy, 29
postcondition, 1921, 26
precondition, 1921, 26
selection mechanism, 28, 31
specication, 13, 26, 30
user-dened, 19, 20
action rule, 13, 16, 26, 2830
adopt, 22
agent, 25,
textbf26
program, 7, 25, 26, 26, 33
belief base, 15, 16, 20, 21, 25, 26, 30
blind commitment, 21, 25
Blocks World, 25
common sense, 7
declarative, 51
drop, 22
environment, 31
event
natural, 31
fact
perceptual, 33
goal
achievement, 16, 17
goal base, 15, 16, 21, 22, 25, 26
knowledge base, 15, 16, 20, 25, 26
knowledge representation, 13, 34
language, 41
literal
negative, 26
positive, 26
mental state, 16, 21, 25, 34
mental state condition, 16, 17, 25, 28, 30
percept base, 33
percept rule, 26
program section, 26, 30
programming
agent-oriented, 7
programming with mental states, 25
rational agent, 21, 25, 34
rule
percept, 33,
textbf33
sense, 31
STRIPS, 19, 21
underspecication, 29
114