Normative Regulation of
Open Multi-agent Systems
Andres Garca-Camino
Directors:
Dr. Pablo Noriega Blanco-Vigil
Dr. Juan Antonio Rodrguez Aguilar
i Dr. Wamberto Weber Vasconcelos
Tutor: Dr. Josep Puyol Gruart
Departament de Ciencies de la Computacio i Intel
ligencia Articial
Escola Tecnica Superior d'Enginyeria
Universitat Autonoma de Barcelona
2008

A mis padres y a mi hermano.

Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Related Work 11
2.1 Logics of Norms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Normative Computational Languages . . . . . . . . . . . . . . . . 14
2.2.1 Conditional Deontic Logic with Deadlines . . . . . . . . . 14
2.2.2 Z Specication of Norms . . . . . . . . . . . . . . . . . . . 15
2.2.3 Event Calculus . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4 Rights and Obligations . . . . . . . . . . . . . . . . . . . . 17
2.2.5 NoA Agent Architecture . . . . . . . . . . . . . . . . . . . 18
2.2.6 Social Integrity Constraints . . . . . . . . . . . . . . . . . 18
2.2.7 Object Constraint Language . . . . . . . . . . . . . . . . 19
2.2.8 Hybrid Metric Interval Temporal Logic . . . . . . . . . . 20
2.3 Models for Regulated MAS . . . . . . . . . . . . . . . . . . . . . 21
2.3.1 Electronic Institutions . . . . . . . . . . . . . . . . . . . . 22
2.3.2 MOISE and MOISE
+
. . . . . . . . . . . . . . . . . . . . 24
2.3.3 Commitment-based Institutions . . . . . . . . . . . . . . . 25
2.3.4 OperA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.5 LGI Model . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.6 Electronic Institutions for Virtual Organisations . . . . . 28
2.3.7 Multi-agent Policy Architecture . . . . . . . . . . . . . . . 28
2.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Regulating Activities in Electronic Institutions 33
3.1 A Normative Language for Electronic Institutions . . . . . . . . . 34
3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Executable Norms . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 Jess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Norm implementation . . . . . . . . . . . . . . . . . . . . 38
3.3 Developing and Deploying Norms . . . . . . . . . . . . . . . . . . 41
v

3.3.1 Automatic Translation of Norms . . . . . . . . . . . . . . 41
3.3.2 Integration with Electronic Institutions . . . . . . . . . . 42
3.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Constraint-based Regulation 47
4.1 A Rule Language for Managing Normative Positions . . . . . . . 48
4.1.1 Preliminary Denitions . . . . . . . . . . . . . . . . . . . 50
4.1.2 A Language for Rules with Constraints . . . . . . . . . . 51
4.1.3 Semantics of Rules . . . . . . . . . . . . . . . . . . . . . . 52
4.1.4 An Interpreter for Rules with Constraints . . . . . . . . . 54
4.1.5 Pragmatics of Rules with Constraints . . . . . . . . . . . 55
4.2 Programming Institutional Rules . . . . . . . . . . . . . . . . . . 56
4.2.1 Institutional States . . . . . . . . . . . . . . . . . . . . . . 57
4.3 Providing Semantics to Deontic Notions . . . . . . . . . . . . . . 58
4.4 Normative Con
ict Resolution . . . . . . . . . . . . . . . . . . . 60
4.4.1 Representing and Enacting Protocols via Institutional Rules 61
4.4.2 Example: The Dutch Auction Protocol . . . . . . . . . . 62
4.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5 Regulating Concurrency 67
5.1 I: A Language for Institutions . . . . . . . . . . . . . . . . . . . 68
5.1.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.2 Operational Semantics . . . . . . . . . . . . . . . . . . . . 71
5.1.3 Interpreter . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2 Example of Concurrency: Soup Bowl Lifting . . . . . . . . . . . . 77
5.3 Applied Example: Bank . . . . . . . . . . . . . . . . . . . . . . . 78
5.4 Norm-Oriented Programming of Scenes . . . . . . . . . . . . . . 80
5.4.1 Providing Semantics to Normative Positions . . . . . . . . 80
5.4.2 Normative Con
ict Resolution . . . . . . . . . . . . . . . 81
5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6 A Normative Structure for Multiple Activities 85
6.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.2 Normative States, Transitions and Structures . . . . . . . . . . . 87
6.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.3 Formalising Con
ict-Freedom . . . . . . . . . . . . . . . . . . . . 92
6.3.1 Mapping Normative Structures to Coloured Petri Nets . . 93
6.3.2 Properties of Normative Structures . . . . . . . . . . . . . 94
6.4 Resolving Normative Con
icts in Run-time . . . . . . . . . . . . 96
6.4.1 Con
ict Detection . . . . . . . . . . . . . . . . . . . . . . 96
6.4.2 Con
ict Resolution . . . . . . . . . . . . . . . . . . . . . . 97
6.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
vi

7 Computational Model and Distributed Architecture 101
7.1 Proposed Distributed Architecture . . . . . . . . . . . . . . . . . 101
7.1.1 Social Layer Protocols . . . . . . . . . . . . . . . . . . . . 104
7.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8 Conclusions and Future Work 111
8.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.2.1 Improving Expressiveness . . . . . . . . . . . . . . . . . . 115
8.2.2 Electronic Institutions . . . . . . . . . . . . . . . . . . . . 117
8.2.3 New applications using norms . . . . . . . . . . . . . . . . 118
A UML Diagrams 119
B An Interpreter for I 121
Bibliography 125
vii

List of Figures
1.1 This thesis as intersection of research elds. . . . . . . . . . . . . 3
1.2 Comparison of the approaches proposed in each chapter . . . . . 5
2.1 BNF of Norms from [Vazquez-Salceda et al., 2004] . . . . . . . . 14
2.2 BNF of Norm Conditions . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Z Denition of a Norm from [Lopez y Lopez, 2003] . . . . . . . . 15
2.4 Main Predicates of Event Calculus . . . . . . . . . . . . . . . . . 16
2.5 Main Fluents from [Artikis et al., 2005] . . . . . . . . . . . . . . 17
2.6 EI architecture using AMELI. . . . . . . . . . . . . . . . . . . . . 23
3.1 Conditional obligation with a deadline . . . . . . . . . . . . . . . 35
3.2 Permission in an interval of time . . . . . . . . . . . . . . . . . . 36
3.3 Sanction related to a deadline violation . . . . . . . . . . . . . . 36
3.4 Example of a Jess unordered fact . . . . . . . . . . . . . . . . . . 37
3.5 Example of a Jess rule . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Example of a conditional obligation with a deadline . . . . . . . 39
3.7 Translating the condition . . . . . . . . . . . . . . . . . . . . . . 40
3.8 Translating the obligation . . . . . . . . . . . . . . . . . . . . . . 41
3.9 Translating the deadline . . . . . . . . . . . . . . . . . . . . . . . 42
3.10 Rule activation for norm OBLIGED( utter(s;w ; i) BETWEEN t1; t2 ) 42
3.11 Conditional obligation along a time interval . . . . . . . . . . . . 43
3.12 Implementation of a conditional obligation along a time interval . 43
3.13 Developing and deploying norms . . . . . . . . . . . . . . . . . . 44
3.14 AMELI and the JessNormEngine Service . . . . . . . . . . . . . 45
4.1 Semantics as a Sequence of
's . . . . . . . . . . . . . . . . . . . 50
4.2 Interpreter for Rules with Constraints . . . . . . . . . . . . . . . 54
4.3 Sample Institutional State . . . . . . . . . . . . . . . . . . . . . . 58
4.4 The Dutch Auction Protocol . . . . . . . . . . . . . . . . . . . . 63
5.1 Semantics as a Sequence of
's . . . . . . . . . . . . . . . . . . . 68
5.2 Grammar for I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3 The s star predicate . . . . . . . . . . . . . . . . . . . . . . . . 76
5.4 The s if predicate . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.5 The fire predicate . . . . . . . . . . . . . . . . . . . . . . . . . . 76
ix

List of Tables
1.1 Comparison of the dierent approaches of chapters 3, 4, and 5 . . 4
2.1 Comparison of norm languages . . . . . . . . . . . . . . . . . . . 29
2.2 Comparison of models of regulated MAS . . . . . . . . . . . . . . 30
8.1 Final comparison of the dierent norm languages . . . . . . . . . 112
8.2 Final comparison of the dierent models of regulated MAS . . . 115
xi

Acknowledgements
First of all, my deepest acknowledgements are for my advisors, Pablo Noriega,
Juan Antonio Rodrguez, and Wamberto Vasconcelos, I could not have com-
pleted this thesis without them.
A mis padres, por sacricarse tanto, por ayudarme en los momentos duros y
no tan duros de este camino.
A los de siempre (Vctor, Jose y Alberto), por estar siempre ah.
A Eva Bou, Andrea Giovannucci, Eloi Puertas, Raquel Ros y al resto de
doctorandos del IIIA, por compartir buenos momentos juntos a lo largo de este
camino.
Querra dar las gracias a todo el personal del IIIA, tanto cientco como
administrativo, por la inestimable ayuda que siempre me han ofrecido.
Thanks to Marek Sergot, Keith Clarke and Robert Craven who hosted me
during my short stage in Imperial College London. Their in
uence undoubtedly
is present in I, the language presented in chapter 5 of this thesis.
Thanks to Dorian Gaertner and Martin Kollingbaum to remind me that
research is a team work.
Thanks to Tim Norman and Wamberto Vasconcelos who hosted me during
my short stage in the University of Aberdeen.
Este trabajo ha sido parcialmente nanciado por una beca I3P del CSIC y
los proyectos de investigacion TIC-2003-08763-C02-00, TIN2006-15662-C02-01 y
2006-5-0I-099.
xiii

\Imagination is more important that knowledge.
For knowledge is limited, whereas imagination
embraces the entire world, stimulating progress,
giving birth to evolution."
(Albert Einstein, \What Life Means to Ein-
stein" in The Saturday Evening Post (26
October 1929))

1.1. Motivation 3
Q.3 How to specify norms that handle multiple concurrent activities?
In the literature it is admitted that norms may be contradictory [Sartor, 1992].
Let us consider that a norm may allow all suppliers in an auction to bid at a
given moment. However, another norm may state that ShinningCopper Co., a
specic supplier agent, is forbidden to bid because of previous unfullled dead-
lines on delivery. In [Kollingbaum, 2005], agents are provided with mechanisms
to resolve con
icts among norms. However, the norms have to be con
ict-free in
order to apply them. For instance, what should the MAS do? Should the MAS
allow the bid or should it punish the agent? Thus, in our opinion, the resolution
of con
icts among norms should be applied in the activity by the MAS.
Since our main goal is to regulate with norms MASs with multiple distributed
activities, the following questions also arise:
Q.4 How to make norms operational to regulate multiple concurrent and dis-
tributed activities?
Q.5 How to computationally enact distributed regulation?
Regulation of
interactions in
MAS
Multi-agent
Systems
Software
Engineering
Norms
Figure 1.1: This thesis as intersection of research elds.
The questions posed above are the main concerns of this thesis. Figure 1.1
shows where the problem addressed in this thesis are. The main concern is to
provide means to build a computational realisation of a class of MASs regulated
by norms. To accomplish this task we will benet from studies on norms like
deontic logics [von Wright, 1951] and from already built, regulated MAS such
as electronic institutions [Rodrguez-Aguilar, 2001].

8 Chapter 1. Introduction
ings of 4th International Joint Conference on Autonomous Agents and
Multi-agent Systems (AAMAS'05), pages 667{673, Utrecht, The Nether-
lands.
 [Garca-Camino et al., 2005b] Garca-Camino, A., Noriega, P., and Rodrguez-
Aguilar, J.-A. Implementing Norms in Electronic Institutions (Extended
Abstract). In 3rd European Workshop on Multi-agent Systems (EU-
MAS'05), Brussels, Belgium.
The work in Chapter 4 has been published in:
 [Garca-Camino et al., 2008] Garca-Camino, A., Rodrguez-Aguilar, J. A.,
Sierra, C., and Vasconcelos, W. (2008). Constraint rule-based program-
ming of norms for electronic institutions. Journal on Autonomous Agents
and Multi-Agent Systems. (In press).
 [Garca-Camino et al., 2006a] Garca-Camino, A., Rodrguez-Aguilar, J.-
A., Sierra, C., and Vasconcelos, W. A Distributed Architecture for Norm-
Aware Agent Societies. In Baldoni, M. et al., editors, Declarative Agent
Languages and Technologies III, volume 3904 of Lecture Notes in Articial
Intelligence (LNAI), pages 89{105. Springer, Berlin Heidelberg.
 [Garca-Camino et al., 2006b] Garca-Camino, A., Rodrguez-Aguilar, J.-
A., Sierra, C., and Vasconcelos, W. A Rule-based Approach to Norm-
Oriented Programming of Electronic Institutions. ACM SIGecom Ex-
changes, 5(5):33{40.
 [Garca-Camino et al., 2006c] Garca-Camino, A., Rodrguez-Aguilar, J.-
A., Sierra, C., and Vasconcelos, W. Norm Oriented Programming of Elec-
tronic Institutions. In Proceedings of 5th International Joint Conference
on Autonomous Agents and Multiagent Systems. (AAMAS'06).
 [Garca-Camino et al., 2007b] Garca-Camino, A., Rodrguez-Aguilar, J.-
A., Sierra, C., and Vasconcelos, W. Norm-Oriented Programming of Elec-
tronic Institutions: A Rule-based Approach. In Coordination, Organiza-
tion, Institutions and Norms in agent systems II, volume 4386 of Lecture
Notes in Computer Science, pages 177{193. Springer-Verlag.
 [Garca-Camino et al., 2006d] Garca-Camino, A., Rodrguez-Aguilar, J.-
A., Sierra, C., and Vasconcelos, W. Norm-Oriented Programming of Elec-
tronic Institutions (Extended Abstract). In Fourth European Workshop
on Multi-Agent Systems (EUMAS'06), Lisbon, Portugal.
The work in Chapter 5 has been published in:
 [Garca-Camino, 2007] Garca-Camino, A. Ignoring, Forcing and Expect-
ing Concurrent Events in Electronic Institutions. In COIN III: Coordi-
nation, Organization, Institutions and Norms in Agent Systems. Revised
Selected Papers from the 2007 Workshop Series, volume 4870 of Lecture
Notes in Computer Science, pages 15{26. Springer.

1.4. Publications 9
The work in Chapter 6 has been published in:
 [Garca-Camino et al., 2007a] Garca-Camino, A., Noriega, P., and Rodrguez-
Aguilar, J.-A. (2006) An Algorithm for Con
ict Resolution in Regulated
Compound Activities. In Engineering Societies in the Agents World VII,
volume 4457 of Lecture Notes in Computer Science, pages 193{208.
 [Gaertner et al., 2007] Gaertner, D., Garca-Camino, A., Noriega, P., Rodrguez-
Aguilar, J.-A., and Vasconcelos, W. Distributed Norm Management in
Regulated Multi-agent Systems. In Proceedings of 6th International Joint
Conference on Autonomous Agents and Multiagent Systems. (AAMAS'07).
 [Gaertner et al., 2008] Gaertner, D., Garca-Camino, A., Noriega, P., Rodrguez-
Aguilar, J. A., and Vasconcelos, W. (2008). Normative structures for reg-
ulating open multi-agent systems. Journal on Autonomous Agents and
Multi-Agent Systems. (submitted).
 [Kollingbaum et al., 2007a] Kollingbaum, M. J., Vasconcelos, W. W., Garca-
Camino, A., and Norman, T. J. Con
ict resolution in norm-regulated envi-
ronments via unication and constraints. In Declarative Agent Languages
and Technologies V, volume 4897 of Lecture Notes in Articial Intelligence,
pages 158{174. Springer.
 [Kollingbaum et al., 2007b] Kollingbaum, M. J., Vasconcelos, W. W., Garca-
Camino, A., and Norman, T. J. Managing con
ict resolution in norm-
regulated environments. In Engineering Societies in the Agents World
VIII, volume (In press) of Lecture Notes in Articial Intelligence. Springer.
The work in Chapter 7 has been published in:
 [Garca-Camino et al., 2007c] Garca-Camino, A., Rodrguez-Aguilar, J. A.,
and Vasconcelos, W. (2007). A Distributed Architecture for Norm Man-
agement in Multi-Agent Systems. In COIN III: Coordination, Organiza-
tion, Institutions and Norms in Agent Systems. Revised Selected Papers
from the 2007 Workshop Series, volume 4870 of Lecture Notes in Computer
Science, pages 275{286. Springer.

Chapter 2
Related Work
Apart from classical studies on law, research on norms and agents has been ad-
dressed by two dierent disciplines: sociology and philosophy. On the one hand,
socially-oriented contributions highlight the importance of norms in agent be-
haviour (e.g., [Conte and Castelfranchi, 1995b, Conte and Castelfranchi, 1993,
Tuomela and Bonnevier-Tuomela, 1995]) or analyse the emergence of norms in
multi-agent systems (for instance, [Walker and Wooldridge, 1995] or the work in
[Shoham and Tennenholtz, 1995]). On the other hand, logic-oriented contribu-
tions focus on the deontic logics required to model normative modalities along
with their paradoxes (e.g., [von Wright, 1963] [Alchourron and Bulygin, 1981]
[Lomuscio and Nute, 2004]). The last few years, however, have seen signicant
work on norms in multi-agent systems, and norm formalisation has emerged as
an important research topic in the literature (for example, [Fornara et al., 2004]
[Dignum, 1999] [Boella and van der Torre, 2003] [Vazquez-Salceda et al., 2004]).
In this chapter, we present relevant related work in the following topics:
logics of norms, normative computational languages and Regulated MASs.
2.1 Logics of Norms
Norms have been widely studied in several elds such as logics, sociology, psy-
chology, and law. In this section we focus on the logics that study norms, i.e.
deontic logics, since the languages on this thesis are inspired on them.
Although prior to Wright philosophers have remarked on the formal logical
relations of deontic concepts and compared deontic concepts with alethic ones1
[Huisjes, 1981, Knuuttila, 1981], Wright was the rst one to propose a plausible
deontic logic in [von Wright, 1951]. It was found later on that a deontic logic
could be given a Kripke semantics [Fllesdal and Hilpinen, 1981].
Further on, the work in [Meyer, 1987] reduces deontic logic to a variant of
dynamic logic [Harel, 1979] that represents the consequences of prohibited ac-
1Alethic concepts are those denoting modalities of truth, such as necessity, contingency, or
impossibility.
11

2.1. Logics of Norms 13
to perform an action. For instance, the fact that agent a is obliged to deliver
good g to agent b will be regarded as a normative position. We will see dierent
notations for this in chapters 3, 4, and 5.
The work in [Broersen et al., 2004] proposes a deontic logic to represent obli-
gations with deadlines based on CTL (Computational Tree Logic), a temporal
logic. They start by dening obligations with deadlines in terms of violations:
an obligation regarding formula  to hold with deadline  holds if and only if
a violation holds when  does not hold before the deadline . However, they
found a counter-intertuitive property and decided to redene obligations with
deadlines in terms of achievements: an obligation of formula  to hold with
deadline  holds if and only if there exists a time-point before the deadline 
where formula  holds. The property in question is if there is no possibility of
 not to hold before the deadline  then  is obligatory before . They argue
that is counter-intuitive because if  is unavoidable, then the obligation to meet
the deadline is void, since it concerns an achievement that is already met. They
avoid this property with their denition of obligation with deadline in terms of
achievement. This kind of obligations are partial, that is, some real applica-
tions cannot be implemented with them. For instance, if agents are obliged to
not smoke even they violate (or achieve) this obligation they should stiil being
obliged to not do it so. Furthermore, as they are not raising violations anymore,
obligations just disappear. We nd an interesting work of research to redene
obligations with deadline based both in achievement and violations and analyse
the properties of the newly created normative system.
In the literature, there are two views of obligations. On the one hand, an
obligation is resembled to the alethic notion of necessity, i.e. there is no pos-
sibility that the contrary happens. In [Sergot, 2001] this notion of necessity is
used in obligatory actions: \It is obligatory that a brings about F". For in-
stance, if I always cross the main door of the building towards the exterior, I am
outside the building. If it is obligatory that I cross the main door towards the
exterior, then it is obligatory for me to be outside the building. On the other
hand, an obligation is the expectation of someone regarding something to be in
a certain way or to something to happen, i.e. there are possibilities to not full
the expectations. When the expectations about actions are not fullled, they
are commonly called violations [Conte and Castelfranchi, 1995a]. For instance,
in case of re I am obliged to cross the main door of the building towards the
exterior. However, I am free to leave the building through a safer or closer exit
if it is appropriate.
Basically, the paradoxes of deontic logic appear since they include connec-
tives, such as the implication, inside the deontic operators. The emergence of
these paradoxes are the result of the interpretation of the same obligation op-
erator in both senses (necessity and expectation). Thus, there is a need to
dierentiate both operators properly.

14 Chapter 2. Related Work
2.2 Normative Computational Languages
In this section we compare a representative sample of norm languages for MAS.
2.2.1 Conditional Deontic Logic with Deadlines
Vazquez-Salceda et al. [Vazquez-Salceda et al., 2004] propose the use of a de-
ontic logic with deadline operators. These operators specify the time or the
event after (or before) which a norm is valid. This deontic logic includes obli-
gations, permissions and prohibitions, possibly conditional, over agents' actions
or predicates.
As shown in gure 2.1, a norm as dened in [Vazquez-Salceda et al., 2004] is
composed of several parts. The norm condition is the declaration of the context
NORM ::= NORM CONDITION
VIOLATION CONDITION
DETECTION MECHANISM
SANCTIONS
REPAIRS
VIOLATION CONDITION ::= formula
DETECTION MECHANISM ::= faction expressionsg
SANCTIONS ::= PLAN
REPAIRS ::= PLAN
PLAN ::= action expression j action expression ; PLAN
Figure 2.1: BNF of Norms from [Vazquez-Salceda et al., 2004]
in which the norm applies. The other elds in the norm description are: 1) the
violation condition, a formula dening when the norm is violated; 2) the detection
mechanism that describes the mechanisms included in the agent platform that
can be used for detecting violations; 3) the sanctions dening the actions that
are used to punish an agent's violation of the norm; and 4) the repairs, a set
of actions that are used for recovering the system after the occurrence of a
violation. As the denition in gure 2.2 shows, norms can be deontic notions
NORM CONDITION ::= N(S hIF Ci) j OBLIGED(a ENFORCE(N(a;ShIF Ci)))
N ::= OBLIGED j PERMITTED j FORBIDDEN
J ::= (a;P) j (a DO A)
S ::= J j J TIME j J ACTION
C ::= formula
P ::= predicate
A ::= action expression
TIME ::= BEFORE D j AFTER D
ACTION ::= BEFORE J j AFTER J
Figure 2.2: BNF of Norm Conditions
such as permissions, obligations or prohibitions. Furthermore, norms can be
related to actions or to predicates (states). The former restrict or allow the

2.2. Normative Computational Languages 15
actions that a set of agents can perform, the latter constrain the results of the
actions that a set of agents can perform. These results are predicates that can
hold or not. For instance, It is forbidden that tom performs the action of smoke
(FORBIDDEN (tom DO smoke)) and it is forbidden that tom brings about that
the air is polluted (FORBIDDEN (tom; polluted(air)))) are two examples of the
types of norm stated above.
Through the condition (C) and temporal operators (BEFORE and AFTER),
norms can be made applicable only to certain situations. Conditions and tem-
poral operators are considered optional. Temporal operators can be applied to
a deadline (D) or to an action or predicate (J).
Although this approach syntactically includes all the common deontic no-
tions (obligations, permissions, and prohibitions), it does not explicitly manage
normative positions. That is, it allows to specify the activation of a norm but
not its termination. For example, the authors do not specify if an obligation
should still be active or not after its deadline expires. Nevertheless, we took it
as basis for the language presented in chapter 3 in which its implementation by
the translation of norms into JESS rules is also provided.
Time management is captured by operators BEFORE and AFTER lending
more pragmatism to the language but it lacks complex temporal expressions like
'weekly', 'monthly' and so on.
The enforcement mechanisms proposed are limited to alarm and logging
mechanisms which, on their own, are not persuasive enough.
2.2.2 Z Specication of Norms
Lopez y Lopez et al. [Lopez y Lopez and Luck, 2004] [Lopez y Lopez, 2003]
present a model of normative multi-agent system specied in the Z language.
Although this work proposes a framework that covers several topics of norma-
tive multi-agent systems we shall focus on its denition of norm. Figure 2.3
shows a norm from [Lopez y Lopez, 2003] composed of several parts. In the
Norm
addresses; beneciaries : PAgent
normativegoals; rewards; punishments : PGoal
context ; exceptions : PEnvState
normativegoals 6= ;; addresses 6= ;; context 6= ;
context \ exceptions = ;; rewards \ punishments = ;
Figure 2.3: Z Denition of a Norm from [Lopez y Lopez, 2003]
schema, addressees stands for the set of agents that have to comply with the
norm; beneciaries stands for the set of agents that prot from the compliance
of the norm; normativegoals stands for the set of goals that ought to be achieved

2.2. Normative Computational Languages 17
Fluent Domain Meaning
requested(S ;T ) boolean subject S requested the
oor at time T
status ffree; the status of the
oor: status = free
granted(S ;T )g denotes that the
oor is free whereas
status = granted(S ;T ) denotes that the
oor is granted to subject S until time T
best candidate agents the best candidate for the
oor
can(Ag ;Act) boolean agent Ag is capable of performing Act
pow(Ag ;Act) boolean agent Ag is empowered to perform Act
per(Ag ;Act) boolean agent Ag is permitted to perform Act
obl(Ag ;Act) boolean agent Ag is obliged to perform Act
sanction(Ag) Z the sanctions of agent Ag
Figure 2.5: Main Fluents from [Artikis et al., 2005]
in logic programming.
Although event calculus models change with time, it lacks on explicit time
management functionalities as shown in [Artikis et al., 2005]. Deadlines thus
need to be modelled as new events.
Another desired feature is that agents can reason about norms without the
need of new complicated machinery. Their deontic
uents are not enough to
inform an agent about all types of duties. For instance, to inform an agent that
it is obliged to perform an action before a deadline, it is necessary to show the
agent the obligation
uent and the part of the theory that models the violation
of the deadline.
The enforcement mechanism provided simply amounts to a violation counter.
It does not distinguish between violations although some of them are more seri-
ous than others. Furthermore, the number of violations an agent has performed
is not very persuasive if any of their goals are not hindered, e.g. earn money.
In [Stratulat et al., 2001] (previous to [Artikis et al., 2005]), event calculus
is also used to model obligations, permissions, prohibitions and violations.
2.2.4 Rights and Obligations
Michael et al. [Michael et al., 2004] propose a formal scripting language to model
the essential semantics, namely, rights and obligations, of market mechanisms.
Whereas right(]action; ]condition) denotes the right to execute action ]action
whenever condition ]condition is true, obligation(]satisfy ; ]violate; ]punishment),
denotes the obligation to ensure that condition ]satisfy is satised no later than
condition ]violate under the penalty of executing action ]punishment . For in-
stance, the following obligation states that Bob must ensure that her bank bal-
ance goes above 1000 dollars at some time before the end of 2004, under the
penalty of 100 dollars being deducted from her account.
obligation(balance(bob) > 1000;Time > 12=31=2004; deduct account(bob; 100))

22 Chapter 2. Related Work
2.3.1 Electronic Institutions
We start by introducing the reader to one of the rst models for regulated MAS
not based in regimentation, i.e. Electronic Institutions (EIs). [Noriega, 1997]
sets the foundations of EIs by proposing dialogical institutions as a means to
regulate and implement agent-mediated auctions using a sh market metaphor.
These dialogical institutions, subsequently called EIs, were conceived as three
components: dialogical framework, performative structure and rules of behaviour.
The dialogical framework captured the notion of context by making explicit
the participants, their roles and their relevant social interrelationships as well as
the communication and the language used in it.
The performative structure is a set of interdependent located scenes. Each
scene is dened as a set of agents assumed to enact a role by interchanging
statements by illocution. These statements are therefore called illocutions. Fur-
thermore, this interchange of statements is subject to a protocol, dened by
means of a nite-state machine (FSM) where state transitions are labelled by
illocutions and the states have associated pending commitments.
Illocutions start with an illocutionary particle that declares the intention of
the message. For instance, a message informing about the selling of a given good
would use the illocutionary particle inform.
Finally, as protocols may not be sucient to make fully explicit how the
agent should behave, the rules of behaviour complete the specication of the be-
haviour of each agent. The notion of governor, agents in charge of ensuring that
institutional communication follows the aforementioned protocols by neglecting
forbidden illocutions, is also introduced in [Noriega, 1997].
[Rodrguez-Aguilar, 2001] continues this line of work by proposing a new for-
malisation of EI which includes a specication language and a computational
model. In that work a performative structure species the conditions and the
order in which agents may enter and leave scenes. Performative structures rep-
resent:
 causal dependencies (e.g. a good cannot be auctioned if it has not been
previously registered in the auction house);
 synchronisation while entering or leaving a scene;
 parallelism by executing several instances of a scene (e.g. concurrent auc-
tioning of several items);
 choice points that allow roles to select what scenes to enter and leave, and
 role
ow policy among scenes, i.e. what paths can be followed by roles
leaving a scene and what scenes they can reach.
Furthermore, this work introduces the need of normative rules in order to ac-
count the obligations of agents. However, only examples of normative rules are
given.

2.3. Models for Regulated MAS 23
[Esteva, 2003] further extends the work on EIs by improving the formalisa-
tion and developing general-purpose software tools to design and interpret in-
stitutional specications to be followed when executing a open set of dialogical
agents.
As a result of this thesis, the Electronic institution development environment
(EIDE) started to be developed. Initially, it only comprised of ISLANDER, an
editor and o-line verier of EI specications. and AMELI, an agent-based mid-
dleware to execute EIs [Esteva et al., 2004]. Currently it also provides aBuilder,
an editor that partially completes the development of agents by taking advan-
tage from recurrent particularities of a given specication, and SIMDEI, an
online verier and simulator of specications.
Figure 2.6: EI architecture using AMELI.
[Esteva, 2003] and [Esteva et al., 2004] propose the use of Jess engines to
implement norms in EIs. The former proposes one global rule engine per insti-
tution, the latter proposes one local rule engine per governor (one per agent).
However, none of the previous proposals are optimal since in the former one the
rule engine may become a bottleneck in a large MAS and the latter one fails
to process information out of the reach of each governor. For instance, when
two agents are forbidden to perform certain simultaneous actions, the governor
cannot access actions of other agents. In chapter 7 we propose a distributed
architecture with rule engines at several levels.
We now focus on the architecture for executing EIs that uses AMELI and is
depicted in gure 2.6. It is composed of three layers: 1) external agent layer:
external agents taking part in the institution; 2) social layer (AMELI): imple-
mentation of the control functionality of the institution infrastructure; and 3)
communication layer: in charge of providing a reliable and orderly transport
service.
The functionality of AMELI includes: 1) the mediation of speech acts uttered
by agents; 2) the provision of key information to successfully participate in the
institution; and 3) the institutional enforcement.

2.3. Models for Regulated MAS 25
plans (oriented graphs of actions and sub-goals) to follow (Pi), actions to exe-
cute (Ai) and resources to use (Ri). Thus, each element that does not belong
to any associated mission is not allowed.
They may equal these sets to ; (nothing is allowed) and Any (all is allowed).
The s parameter may be an obligation O (the agent playing the role has no
choice, it has to execute the mission) or a permission P (the agent playing the
role may decide to execute this mission or not). We notice that, contrary to
obligations in EIs that may not be fullled, this kind of obligation is imposed in
agent's code.
[Hubner et al., 2005] presents MOISE
+
, an extension of MOISE model allow-
ing agents to not comply with obligations, and S-MOISE, a middleware using
MOISE
+
to deploy organised MAS.
2.3.3 Commitment-based Institutions
[Colombetti et al., 2002] proposes a commitment-based semantics for agent com-
munication and sketches a model of institution. In their work, a conditional
commitment its characterised by the following components:
Debtor. The agent that has the commitment.
Creditor. The agent towards which the commitment is made.
Condition. A state of aairs that \activates" the commitment if it becomes
true within a given timeout.
Content. A state of aairs that the debtor is committed to the creditor. It
may have an associated deadline to become true.
State. A commitment can be in one of six possible states: unset, cancelled,
pending, active, fullled, and violated.
Thus, they represent a conditional commitment with state s, debtor x , cred-
itor y , condition , and content ' as the statement C (s; x ; y ; ; ').
They envisage an institution made up of four components: a set of regis-
tration rules, a set of interaction rules, a set of authorisations, and an internal
ontology. They propose registration and interaction rules to be implemented by a
collection of commitment-based protocols, and authorisations to be implemented
as a library of role-dependent actions that can be performed by the members of
the group.
In their \Core Institution", they provide three institutional rules that sets
the basis for authorisations:
Rule CI-1: any agent is authorised to create an unset commitment with arbi-
trary debtor, creditor, condition, and content.
Rule CI-2: the debtor of an unset commitment is authorised to set it to either
cancelled or pending.

2.3. Models for Regulated MAS 27
From [Dignum, 2003] we quote the following:
The organisational model (OM) species the organizational charac-
teristics of an agent society in terms of four structures: social, in-
teraction, normative and communicative. The social structure (SS)
species objectives of the society, its roles and what kind of model
governs coordination. The interaction structure (IS) describes inter-
action moments, as scene scripts, representing a society task that re-
quires the coordinated action of several roles, and gives partial order-
ing of scene scripts, which specify the intended interactions between
roles. Society norms and regulations are specied in the normative
structure (NS), expressed in terms of roles and interaction norms.
Finally, the communicative structure (CS), species the ontologies
for description of domain concepts and communication illocutions.
We notice the similarities of OperA with the EI model. The goal of an in-
teraction structure of OperA model is the same as the one of a performative
structure. The goals of communicative structure and social structure are cap-
tured with a dialogical framework. The normative structure of OperA model
is very similar to the notion of norms in EIs since it can be summarised as a
set of norms written in LCR. \LCR is an extension of CTL, which in turn is
an extension of classical propositional logic.". CTL is a temporal modal logic
whose model of time is a tree-like structure in which the future is not determined
[Emerson and Halpern, 1986].
2.3.5 LGI Model
[Minsky, 2005] proposes law-governed interaction (LGI), a decentralised coordi-
nation and control mechanism for distributed systems. This middleware allows
a possible large, heterogeneous and open set of actors to interact governed by a
given policy, called the interaction law. The interaction law may be written in
Java or Prolog.
In order to enforce the interaction law, a component called controller is
associated to each actor. The controller is entrusted to mediate the interaction
of its actor with others, it decides by interpreting the active law, how to react
to messages sent and received by its actor.
Although LGI does not proposes a social model, we notice the similarities
between EI governors and LGI controllers. Both realise a local regulation of
messages at agent level. However, some applications require regulations that
access the state of several agents. To implement this with controllers or governors
would require to duplicate in each controller (or governor) the state of all agents
possibly involved in a non-local regulation. However, in large systems this is not
a viable solution.

2.4. Conclusions 29
parties, their only common parent is the VO agent converting the latter in a
bottleneck in large e-commerce scenarios.
2.4 Conclusions
In this section we compare some features of normative languages and models for
regulated MAS.
In order to compare normative languages we use the following features:
Constraints { This feature depicts the degree of constraint management. We
distinguish no specication ({), specication only of time constraints (time),
specication of constraints (specication) and specication and modica-
tion (management).
Distribution { This feature re
ects the degree of distribution of norms. We
distinguish no distribution of norms (centralised), norms distributed in
each agent (agents), and norms distributed in each activity (activities).
Concurrent Behaviour { This feature shows the degree of concurrency on
actions. We distringuish no concurrency ({), concurrent actions in one
or no activity (actions), and concurrent actions in concurrent activities
(activities).
Concurrent Regulation { This feature depicts the degree of regulation on
concurrent actions. We distinguish:
 no regulation of actions ({),
 no regulation of actions but regulation of goals (goals),
 just monitoring and sanctioning of actions (monitoring),
 monitoring, sanctioning and prevention of one action at a time (one
action),
 monitoring, sanctioning and prevention of simultaneous actions (si-
multaneous actions).
Language Features
Constraints Distribution Conc. Behaviour Conc. Regulation
1. CDeonticL time centralised actions monitoring
2. Z { agents actions goals
3. EC time centralised actions one action
4. Rights specication centralised actions one action
5. NoA { agents actions goals
6. SIC specication centralised actions monitoring
7. OCL specication centralised activities one action
8. hyMTL time centralised actions monitoring
Table 2.1: Comparison of norm languages

2.4. Conclusions 31
interact. We prefer these interactions to be regulated only by norms since reg-
ulating by protocols and norms requires the MAS programmers to learn how
to specify protocols in addition to norms. Furthermore, role hierarchies pro-
vide more expressiveness when specifying activities and norms for roles since
the specication applies to a role and its subsumed ones. For instance, some
activities may be performed or some actions may be forbidden to be bring about
by a given set of roles just specifying the subsuming role. Although we plan
to include role hierarchies, we acknowledge that the proposal presented in this
thesis only deals with role labels. Finally, we envisage a MAS that structures
actions and norms in activities allowing a modular design and distribution of
the MAS according to the purpose of interactions.

34 Chapter 3. Regulating Activities in Electronic Institutions
proposes a theoretical deontic language, with norms that are kept active during
a time interval, and conditional norms over the state of the institution, e.g. the
observable attributes of agents. Moreover, our extension includes the possibility
to sanction or reward agents by modifying their external attributes.We also
provide operational semantics to the language by translating constructs written
in it into Jess rules [Sandia National Labs, 2006].
As for the norm service in AMELI, governors (cf. Section 2.3.1) provide us
with changes in the values of observable variables and use it to check if illocutions
are nally permitted. Likewise, this service also changes the values of variables
stored in governors.
3.1 A Normative Language for Electronic Insti-
tutions
As we mentioned in the beginning of the chapter, there is a need to redene
norms in electronic institutions to include time restrictions. Thus, we propose
the BNF description of our normative language as follows:
NORM := N ( utter(S ;W ; I ) hTIMEi hIF C i )
N := OBLIGED j PERMITTED j
FORBIDDEN
I := (A;R;A;R;M ;T)
TIME := BEFORE D j AFTER D j
BETWEEN (D;D) j
BEFORE uttered(S;W ; I) j
AFTER uttered(S;W ; I) j
BETWEEN ( uttered(S;W ; I);
uttered(S;W ; I) )
C := : (CONDS) j CONDS
CONDS := h: iCOND h;C i
COND := V OP V j uttered(S;W ; I) j
N ( utter(S;W ; I) ) j predicate
V := AT j F j value
AT := identier:attribute j variable
OP := > j < j  j  j =
SANCTION := SANCTION ( (COMMS) IF NP (NORM ) )
NP := VIOLATED j COMPLIED
COMMS := COMM h;COMMSi
COMM := AT = F j F
F := identier( < ARGS > )
ARGS := V <; V >
where S is a scene identier; W is a state identier;  is an illocutionary parti-
cle; A is an agent identier; R is a role identier; M is a content message in the
language LO from the dialogical framework; T is a time stamp; D is a deadline;
S, W , I , A, R, M , T  are expressions which may contain variables refer-
ring, respectively, to scenes, states, illocutions, agent identiers, role identiers,

3.1. A Normative Language for Electronic Institutions 35
messages and time stamp; and predicate is a rst-order formula whose variables
are universally quantied.
On the one hand, utter(s;w; i) is the predicate that represents the action
(not carried out yet) of submitting an illocution at the state w of scene s.
This predicate is the only one that can be restricted with deontic operators.
On the other hand, uttered(s;w; i) is used to denote that the submission
of an illocution has been carried out. The latter predicate can be used in the
conditional construct of a normative rule.
From the BNF notation it follows that a norm (NORM ) can be either an obli-
gation (OBLIGED), a permission (PERMITTED) or a prohibition (FORBIDDEN)
concerning the utterance of a given illocution utter(S ;W ; I ) if conditions are
satised (IF C ). The BEFORE construct is used to activate the norm before a
deadline or an action. The AFTER construct is used to activate the norm after
a given deadline or an action. The BETWEEN construct results from the com-
bination of the previous two and it is used to activate the norm once the time
specied by the rst argument is reached and de-activate it once the time spec-
ied by the second argument is reached. The IF construct is used to introduce
conditions over variables, agents' observable attributes or function results. The
AT denition denotes how attribute values can be accessed with the language,
identier :attribute denotes that the value of the attribute with name attribute
of the agent or object with name identier is retrieved.
Sanctions (and, analogously, rewards) can also be expressed by dening the
sequence of attribute updates or functions (COMMS ) to be executed if a norm
is violated (analogously, complied) that is, VIOLATED NORM or COMPLIED
NORM .
3.1.1 Examples
In this section we show how to use our normative language through several
examples. All these examples, along with the rest of examples in this chapter,
are based on an electronic auction institution. The institution has four scenes or
activities: Registration, where agents sign in along with the information about
the goods they want either buy or sell; Auction, where the actual bidding takes
place; Payment , where buyers pay for acquired items and sellers are paid; and
Delivery , where the sold goods are delivered to the acquiring buyers.
OBLIGED (utter(payment;W ;
inform(A; buyer ;B; payee; pay(IT ;P)))
BEFORE uttered(payment;w5;
inform(B; payee; all; buyer ;
close()))
IF uttered(auction;w2;
inform(A; auctioneer ; all; buyer ;
sold(IT ;P;C )));
A:credit > P
Figure 3.1: Conditional obligation with a deadline
After the registration of agents and goods, agents join the Auction scene to

3.2. Executable Norms 37
3.2 Executable Norms
Once the normative language has been dened, we need to handle the norma-
tive state of an institution. We chose a rule-based system to implement norms
because the normative language is of the form preconditions postconditions,
which is easily expressable with rules. In order to facilitate the integration with
AMELI we decided to implement this tool with Jess since both are written in
Java.
In this section we rst introduce the (norm) engine used for implementing
executable norms. The translation of norms expressed in the language presented
in section 3.1 into executable norms written in Jess is also detailed.
3.2.1 Jess
Jess is an expert system shell and scripting language from Sandia National Lab-
oratories [Sandia National Labs, 2006] written entirely in Java [Gossling, 1996].
Jess supports the development of rule-based systems that can be tightly coupled
to code written in Java. It can manipulate Java objects and can be extended
with new functions implemented in Java.
Facts
A rule-based system maintains a collection of knowledge portions called facts.
This collection is known as the knowledge base. In Jess, there are three kinds
of facts: ordered facts, unordered facts, and denstance facts. Ordered facts are
simply Lisp-style lists where the rst eld, the head of the list, acts as a category
for the fact. Unordered facts allow the programmer to structure the properties
of a fact in slots. Before the creation of unordered facts, the slots they have
must be dened using the deftemplate construct.
Figure 3.4 shows an example of an unordered fact template used to model the
predicate uttered . An uttered fact is composed of several slots: scene, state,
agent, receiver, performative and content. The scene and state where an
utterance takes place is specied by the scene and state slot; while the agent
and receiver slots dene the sender and receiver of the message (content).
The illocutionary particle of the illocution is stated by the performative slot.
(deftemplate uttered
(slot scene)
(slot state)
(slot agent)
(slot receiver)
(slot performative)
(multislot content))
Figure 3.4: Example of a Jess unordered fact

38 Chapter 3. Regulating Activities in Electronic Institutions
Rules
Rules have two parts separated by the connective \=>": a left-hand side (LHS)
and a right-hand side (RHS). The LHS is employed for matching fact patterns.
The RHS is a list of actions (postconditions) to perform if the patterns of the
LHS (preconditions) are satised. These actions are typically method calls. An
important feature of Jess is that the RHS can call native Jess methods, instance
methods of externally referenced Java objects and static class methods. This
feature adds enormous
exibility to the code.
(defrule cob-1-sanction
"Reduce agent's credit on violation"
(V (type negative) (constraints ?c) (agent ?a)
(scene deliver) (state w0) (receiver ?b)
(performative inform) (content deliver ?it))
(agent (id ?a) (attrs ?at ))
=>
(bind ?old (?at get "credit"))
(bind ?new (- ?old 100))
(?at put "credit" ?new))
Figure 3.5: Example of a Jess rule
Figure 3.5 shows an example of a rule. When a violation occurs, that is, when
there exists a fact V with the specied slots and the attributes of the violator
agent ?a can be retrieved in the variable ?at then store the value of the credit of
the agent in variable ?old, store in ?new the value of variable ?old decreased by
a hundred and change the credit of the violator agent ?a to the value of variable
?new.
3.2.2 Norm implementation
In addition to the normative language we need to keep the sequence of actions
done at run-time and to query what actions are permitted or forbidden and what
are the pending obligations. To introduce utterances, permissions, prohibitions
and obligations in the norm engine, a translation from our language to Jess rules
is needed. This translation can be carried out using the criteria established in
the following sections.
We dene four types of Jess unordered facts: O, P, F and V that stand,
respectively, for obligations, permissions, prohibitions and violations. Further-
more, we distinguish three types of norms: conditional, action-dependent and
time-dependent norms.
Conditional norms.
Conditional norms are those norms that include an IF section. The translation
of IF sections is directly realised by placing the conditions in the LHS of a Jess
rule.

3.3. Developing and Deploying Norms 41
Production rule
Obligation
Norm
Figure 3.8: Translating the obligation
3.3 Developing and Deploying Norms
Figure 3.13 shows the process of developing norms and preparing them for ex-
ecution. As any software process, after an initial analysis of the problem, we
obtain a set of requirements of the problem. For instance, we can conclude that
there is a certain seller that wants a given item to be auctioned. At design time,
we reformulate these requirements into permissions, prohibitions and obligations
over the agents. For instance, after we choose to implement the Dutch auction
protocol one of the new requirements could be \The storemanager is given 15
days to deliver the paid item". This can be reformulated as \The storemanager
is obliged to deliver item IT to agent A within 15 days if agent A has paid for
item IT" (Fig. 3.6). Then, at development time, we translate these norms into
production rules as we explained in section 3.2.2 (Cf. Figs. 3.7 - 3.9 for the
translation of the norm of the example). We start the run time step by provid-
ing the production rules obtained at the last step into the norm engine. Finally,
obligations, permissions, prohibitions, violations and illocutions are entered into
the production system as facts as the MAS evolves, running the production rules
and updating the facts, i.e. the normative state of the MAS.
3.3.1 Automatic Translation of Norms
To reduce the work in the life cycle mentioned above, we have developed a com-
piler that automatically translates norms written in the language presented in
this chapter into Jess rules. Figure A.2 shows a UML diagram of the automatic
translator. This compiler is composed of a parser-writer and a translator. The
parser-writer transforms the contents of a text le, if it follows the norm lan-

3.4. Conclusions 45
Autonomous
Agents
Layer
Communication Layer
. . . . . .
. . .. . .
Distributed,
Social
Layer
P
r
i
v
a
t
e
P
u
b
l
i
c
A 1 A i A n
G 1 G i G n
Service 1
JessNormEngine
Service n
...
...
Figure 3.14: AMELI and the JessNormEngine Service
it consumes each day and a maximum quantity of copper that it can store, then
we may also want to specify that copper sellers are prohibited to deliver less than
0.75 and more than 1.25 times the stipulated amount of copper for today. Thus,
in the following chapter we include constraint management in our proposal.

48 Chapter 4. Constraint-based Regulation
In this chapter we present IRL, the Institutional Rule Language. Constraints
are entities managed explicitly in conjunction with predicates { we accommo-
date, as we show, constraints in our semantics using standard constraint solving
techniques. Constraints allow for more sophisticated notions of norms and nor-
mative positions to be expressed. For instance, in a scenario in which a selling
agent is obliged to deliver a product satisfying some quality requirements before
a deadline, both the quality requirements and the delivery deadline can be re-
garded as constraints that must be considered as part of the agent's obligation.
Thus, when the agent delivers the good satisfying all the constraints, we should
regard the obligation as fullled. Notice too that since the deadline might even-
tually be changed, we also require the capability of modifying constraints at
run-time.
We also show how agent's behaviour are regulated by means of protocols and
norms that can be represented and be given a computational realisation. By
regulating interactions with rules, we provide a light-weight engine in order to
regulate open MAS.
This language has been conceived to represent distinct
avours of deontic
notions and relationships: we can dene dierent situations in which dierent
deontic notions hold, that is, we can dene the behaviour of the institution in
certain conditions. In our language, we can specify situations in which, for in-
stance, prohibitions cannot be violated and situations in which, e.g., prohibitions
of certain actions can be violated under penalties.
Our normative approach gives more
exibility to EIs [Esteva, 2003] in that
we can also capture deviant behaviour. Our work sets the foundations to specify
and implement light-weight institutions via rules.
The main contributions of this chapter are:
1. a means to specify what an agent can, may, may not and ought to utter
using normative positions and constraints;
2. an operational semantics to the above mentioned specication by means
of rules and constraint solving techniques;
3. a computational model that establishes how agents' speech acts are pro-
cessed; and
4. the application of this computational notion of norm to implement and
enrich a model of regulated MAS like Electronic Institutions and, as an
illustrative example, its application to regulate the Dutch Auction.
4.1 A Rule Language for Managing Normative
Positions
In this section we present the work introduced in [Garca-Camino et al., 2006a],
a rule-based language for the specication of the translation of agents' illocutions
into actions in the normative environment. We consider that agents can (directly

4.1. A Rule Language for Managing Normative Positions 55
4.1.5 Pragmatics of Rules with Constraints
In this section we illustrate the pragmatics of our rules with some examples:

do(A; pay(P ;B);T ) &
credit(B ;X ) & X2 = X + P


0
@
del(do(A; pay(P ;B);T )),
del(credit(B ;X )),
add(credit(B ;X2))
1
A (4.1)
0
B
B
@
do(A; ext(obl(X ;T2) : C ;D);T ) &
(T < D) & (T2 < D2) 2 C &
delete((T2 > D2);C ;C 0) &
append(C 0; (T2 > D);C 00)
1
C
C
A

del(do(A; ext(obl(X ;T2) : C ;D);T )),
del(obl(X ;T2) : C ),add(obl(X ;T2) : C 00)

(4.2)

do(C ; pay(P ;B);T ) & min(D) &
time(T ) & (P > D)



del(do(C ; pay(P ;B))),
add(done(C ; pay(P ;B);T ))

(4.3)
The rst example shows a rule depicting the circumstances under which it should
be applied: if agent A generates the event of paying price P to agent B and the
credit of the latter is X . It also shows on the RHS the updates to perform: we
ensure the event is \consumed" (thus not triggering o the rule indenitely) and
the credit of agent B is updated to X + P .
The second example illustrates the management of constraints: these can be
manipulated like ordinary elements of the state of aairs. In that example, we
show that events of type obl (i.e. an obligation) may have associated constraints.
Particularly, this rule states that if an event of extending (ext) the deadlines of
all the obligations to time D occurs before the deadline D and there exists a
constraint restricting the time of fulllment of the obligations to be less than a
deadline D2, then the event is consumed, the old obligation is removed and an
obligation with the new deadline is added.
The third example illustrates how constraints can additionally be checked
for their satisfaction: when an event of paying price P is performed by agent C
and there is a formula min(D) (storing a minimum price), we check that all the
constraints in the state of aairs, including the one establishing that the amount
paid is greater than the minimum (P > D), are satised. If this is so, then we
remove the event and add a record of this case to the state of aairs. Notice
that we make use of a built-in predicate time=1 to check the current time of the
system.
Our rules manage states of aairs, adding or removing formulae (expressed on
the RHS) when certain conditions (expressed on the LHS) hold. As illustrated
in gure 4.1, our approach accommodates the participation of agents: they add
atomic formulae onto the current state of aairs { these formulae represent agent-
related events, represented above as do(Ag ;Ev ;T ) that, together with further
elaboration on the circumstances, will trigger o rules to update the state of
aairs.
The language that we propose denes a rule-based system enhanced with
constraint satisfaction techniques in order to check how specied constraints
aect the facts they constrain. We have obtained a language to express, manage,
check fullment and/or sanction unfullled normative positions, i.e. obligations,

4.4. Normative Con
ict Resolution 61
A third possibility is to raise an exception via a term which can then be dealt
with at the institutional level. The following rule could be used for this purpose:
att(E ) & time(T ) & obl(E ;T ;T0) & prh(E ;T ;T1) add(exc(E )) (4.11)
These examples illustrate how we explicitly manage normative positions of agents
in our language.
When adding constraints to predicates, some problems may rise:
1. constraints in a predicate may be erroneously specied as not satisable.
For instance, a rule might try to add an obligation to an agent to pay more
than 50e and less than 20e.
2. constraints in related normative positions may be erroneously specied as
not satisable. For instance, an agent may be obliged to pay more than
50e but also forbidden to pay more than 20e.
A solution for the rst problem is already included in the semantics of IRL,
as we check in the RHS of the rules the satisability of constraints before adding
a predicate. The second problem may be avoided by verication techniques at
design time. However, these methods do not have good performance when the are
too many constraints to check. In chapter 6, we will propose an algorithm to be
applied at run-time to x the problem of normative positions with unsatisable
constraints.
4.4.1 Representing and Enacting Protocols via Institutional
Rules
The purpose of this section is to represent and build a computational model of the
dynamics of an interaction enactment based on protocols, that is, its execution
with our rule-based language. Our model is based on scenes of EIs [Esteva, 2003]
(see section 2.3.1) but our approach addresses any protocol specied via non-
deterministic nite-state machines.
We shall represent protocols declaratively as logic programs, as described in
[Vasconcelos et al., 2004]. Each edge connecting two states of a protocol will be
denoted as the fact
edge(State; Event;NewState)
representing that if the control of the enactment of the protocol is in State and
Event is uttered, then the control should move to NewState. Edges are compact
descriptions of what can be performed, i.e., the meaningful actions, and how
the control of the enactment of the protocol (and by extension, of the MAS as
a whole) should change as events are generated. Notice that although an agent
may generate a meaningful event (att(Event) and edge(State;Event ;NewState))
in a given situation, it may also need to be permitted (per(E ;Tinst ;T0)) and not
prohibited (not prh(E ;Tinst ;T1)) to do it so. By \meaningful" we mean that
the event makes sense in the context of that protocol, that is, at a particular

62 Chapter 4. Constraint-based Regulation
point of the protocol, we specify via edges all possible events that agents may
generate at any point. Of these, some will be permitted, as explained below.
Protocols are descriptions of what events may be performed and when they
can be brought about in order to have a desired meaning. When permissions are
combined with attempted events (i.e, att(Event), as captured by formula 4.4
above) and approved utterances (i.e, inst(Event ;T )) are combined with up-
dates on the state of the enactment, then the protocol can be fully captured.
In order to represent the control of the protocol enactment we use the term
ctr(State; T imeStamp), stored in the institutional state, which informs that at
time TimeStamp the protocol enacted is at State.
The dynamics of the control of the enactment can be captured generically as
the following institutional rule:
0
B
B
@
state(Wi ;T ) & time(T2) &
att(E ) & edge(Wi ;E ;Wj ) &
per(E ;T2;T0) : C & sat(C ) &
not(prh(E ;T2;T1) : C 0 & sat(C 0))
1
C
C
A
0
B
B
@
del(state(Wi ;T )),
add(old state(Wi ;T )),
add(state(Wj ;T2)),
add(inst(E ;T2))
1
C
C
A (4.12)
That is, if the control of the enactment of the protocol is at state Wi and
event E has been performed, there is an edge connecting Wi with Wj labelled
with that event, and the event is permitted and not prohibitted, then the state
of the enactment at the next time will move to state(Wj ;T2). We keep track of
the time of previous states using the old state predicate.
We notice that institutional rules are expressive enough to represent norma-
tive aspects as well as protocols (i.e., interactions) and their enactment.
4.4.2 Example: The Dutch Auction Protocol
In this section, we illustrate the pragmatics of our norm-oriented language
by specifying the auction protocol employed in the sh market described in
[Noriega, 1997]. Following [Noriega, 1997], the sh market can be described as a
place where several scenes [Esteva, 2003] take place simultaneously, at dierent
locations, but with some causal connection. The principal scene is the auction
itself, in which buyers bid for boxes of sh that are presented by an auctioneer
who calls prices in descending order, following an open cry, sudden death, down-
ward bidding protocol, a variation of the traditional Dutch auction protocol that
proceeds as follows:
1. The auctioneer chooses a good out of a lot of goods that is sorted according
to the order in which sellers deliver their goods to the sellers' admitter.
2. With a chosen good, the auctioneer opens a bidding round by quoting
oers downward from the good's starting price, previously xed by a sell-
ers' admitter, as long as these price quotations are above a reserve price
previously dened by the seller.
3. For each price the auctioneer calls, several situations might arise during
the open round described below.

4.5. Conclusions 65
No bids/New Price { We must check if there were no bids and if the next
price is greater than the reserve price. If so, we must add an obligation
for the auctioneer to start a new bidding round. Rule 4.17 checks that the
current scene state is w5, the last oer occurred before w5 and whether the
new price is greater than reserve price. If so, the rule adds the obligation
for the auctioneer to oer the item at a lower price. By retrieving the
last oer we gather the last oer price. By checking the oav predicates we
gather the values of the reserve price and the decrement rate for item It .
0
B
B
B
@
ctr(dutch;w5;Tn) & 0 &
not(1 & (T2 > T)) & (Tn > T) &
oav(IT ; reservation price;RP) &
oav(IT ; decrement rate;DR) &
(RP < (P DR)) & (P2 = P DR) & time(T3)
1
C
C
C
A


add(2)


where
8
<
:
0 = instill(inform;Au; auct; all; buyer ; oer(IT ;P));T)
1 = inst(ill(inform;Au; auct; all; buyer ; oer(IT ;P));T2)
2 = obl(ill(inform;Au; auct; all; buyer ; oer(IT ;P2));T4;T3)
(4.17)
No bids/withdrawal { We must check if there were no bids and the next price
is less than the reserve price; if so we add the obligation for the auctioneer
to withdraw the item. Rule 4.18 checks that the current institutional state
is w5, the last oer occurred before w5 and whether the new oer price
is greater than reserve price. If the LHS holds, the rule res to add the
obligation for the auctioneer to withdraw the item. By checking the last
oer we gather the last oer price. By checking the oav predicates we
gather the values of the reserve price and the decrement rate for the price
of item It :
0
B
B
B
@
ctr(dutch;w5;Tn) & 0 &
not(1 & (T2 > T)) & (Tn > T) &
oav(It; reservation price;RP) &
oav(It; decrement rate;DR) &
(RP  (P DR)) & time(T3)
1
C
C
C
A


add(2)


where
8
<
:
0 = inst(ill(inform;Au; auct; all; buyer ; oer(It;P));T)
1 = inst(ill(inform;Au; auct; all; buyer ; oer(It;P));T2)
2 = obl(ill(inform;Au; auct; all; buyer ;withdrawn(It));T4;T3)
(4.18)
4.5 Conclusions
In this chapter, to continue answering our rst two research questions, we
have introduced a language for the explicit management of normative positions
bounded by arithmetical constraints and specifying the behaviour of agents in
MASs. The classical model of EIs proposed in [Esteva, 2003] is strict in the sense
that only meaningful speech acts are accepted in the protocols without checking
if they are permitted or not. We propose a language to extend the notion of EI
by implementing its scenes and providing them with several
avours of deontic
notions.
The main advantage of using our language, instead of standard production
systems (such as Jess, used in Chapter 4), to specify and monitor the normative
position of the agents conforming a MAS is to be able to avoid forward-chaining

66 Chapter 4. Constraint-based Regulation
mechanisms to easily implement one-time actions and sanctions, and the in-
clusion of constraint solving techniques in the semantics to handle constrained
predicates, i.e. to manage constraints and to check how these constraints aect
the predicates they constrain. We have obtained a language to express, manage,
check fullment and/or sanction unfullled normative positions, i.e. obligations,
permissions and prohibitions, that are bounded with constraints.
Thus, the language presented in this chapter is useful to predict a future
state of aairs with an initial state and a sequence of sets of events that occur
by modifying the intermediate states of aairs until we reach the nal one. The
limitations of the language are determined by the rule engine. These limitations
include the inability to plan, i.e. determine the sequence of sets of events that
must occur in order to reach a given state of aairs from a given initial state,
or post-dicting, i.e. determine the previously unknown facts in a partial initial
state given a nal state and the sequence of sets of events that have occurred.
However, the goal of the language is to regulate a MAS and keep track of its
evolution by prediction. Post-diction and planning would be interesting for a
language that an agent could use for deciding which action to perform but this
is not the aim of this thesis.
We envisage two typical ways of using our language: i) directly, to supplement
a MAS with interaction protocols and norms or declaratively implement scenes
of EIs or ii) specifying norms with a language like the one presented in chapter
4 and then using a compiler to translate it into IRL to execute it.
Although the proposals of this chapter answers the rst two research ques-
tions posed in Chapter 1, we noticed that we can provide more expressiveness
to candidate languages by exploiting more the computational model presented
in this chapter for the specication of simultaneous speech acts that can be per-
mitted, prohibited and forbidden. Furthermore, we can improve the semantics
of our language by including some enforcement actions, that we call institutional
actions, such as ignoring, expecting or forcing certain simultaneous speech acts
or preventing a given state of aairs. Thus, we will include this in the proposal
of the next chapter.

70 Chapter 5. Regulating Concurrency
namely addition and removal of constrained formulae. A constrained formulae is
an atomic formula that may be followed by a set of arithmetical constraints using
the syntax presented in Def. 4.1.3. Furthermore, by conditions we mean one
or more possibly negated conditions. Then, a condition may be a constrained
formula, the sat predicate that checks that a set of constraints are satisable,
the seteq predicate that checks if two sets are equal, the timepredicate that
checks current time or the true constant that always hold.
If-rules specify the logical consequence if the conditions hold by means of a
sequence of actions. Ignore-rules specify the set of events that should be ignored
if the conditions hold. Similarly, prevent-rules specify the conditions that should
not hold if some conditions hold. Finally, force-rules specify a set of new events
that are generated on the occurrence of a set of events and the satisfaction of
a sequence of conditions. Furthermore, it also species a sequence of actions to
perform if the rule is triggered.
We add an extra kind of rules, called expectation-rules, that generate and
remove expectations of events. If the expectation fails to be fullled then some
sanctioning or corrective actions are performed.
expectation-Rule ::= expected event on set of events if conditions
fullled-if conditions 0 violated-if conditions 00
sanction-do actions
Each expectation rule can be translated into the following rules:
on set of events if conditions do add(exp(event)) (5.1)
if exp(event) ^ conditions 0 do del(exp(event)) (5.2)
if exp(event) ^ conditions 00 do del(exp(event)),actions (5.3)
Rule 5.1 and 5.2 respectively adds and removes an expectation whenever the
events have occurred and the conditions hold. Rule 5.3 cancels the unfullled
expectation and sanctions an agent for the unfullled expectation by executing
the given actions whenever some conditions hold.
5.1.1 Semantics
Instead of basing the I language on the standard deontic notions, two types
of prohibitions and two types of obligations are included. In our language,
ECA-rules determine what is possible to perform, i.e. they establish the eects
(including sanctions) in the institution after performing certain (possibly con-
current) events. ECA-rules can be seen as conditional count-as rules: the given
events count as the execution of the actions in the ECA-rule if the conditions
hold and the event is not explicitly prohibited. As for the notion of permission,
all the events are permitted if not explicitly prohibited. The notion of an event
being prohibited may be expressed depending on whether that event has to be
ignored or not. If not otherwise expressed, events are not ignored. Likewise, the
notion of a state being prohibited may be specied depending on whether that

5.1. I: A Language for Institutions 71
state has to be prevented or not. By default, states are not prevented. Obli-
gations are dierentiated in two types: expectations, which an agent may not
fulll, and forced (or obligatory) events, which the system takes as institutional
events even they are not actually performed by the agents.
Each set of ECA-rules generates a labelled transition system hS; E ;Ri where
S is a set of states, each state in S is a set of atomic formulae, E is a set of events,
and R is a S2
E
S relationship indicating that whenever a set of events occur
in the former state, then there is a transition to the subsequent state.
Ignore-rules avoid executing any transition that contains in its labelling the
events that appear in any ignore-rule. For instance, having a rule ignore 1
if true would avoid to execute the transitions labelled as f1g, f1; 2g and
f1; 2; 3g. However, having a rule ignore 1; 2 if true would avoid execut-
ing f1; 2g and f1; 2; 3g but not f1g.
Prevent-rules ignore all the actions in an ECA-rule if it brings the given
formulae about. For example, suppose that we have
prevent q1 if true
along with ECA-rules 5.4, 5.5 and 5.6 below. After the occurrence of events 1
and 2 and since q1 is an eect of event 2, all the actions in ECA-rule 5.5 would
be ignored obtaining a new state where p and r hold but neither q1 nor q2.
on 1 if true do add(p) (5.4)
on 2 if true do add(q1),add(q2) (5.5)
on 1; 2 if true do add(r) (5.6)
Force-rules generate events during the execution of the transition system.
However, the eects of such events are still specied by ECA-rules and subject
to prevent and ignore-rules.
5.1.2 Operational Semantics
We now dene the semantics of the conditions, that is, when a condition holds:
Denition 5.1.1. Relation sl(
;C ; ) holds between state
, a condition C
in an if clause and a substitution  depending on the format of the condition:
1. sl(
;C & C 0; ) holds i sl(
;C ; 0) and sl(
;C 0
0; 00) hold and  =
0 [ 00.
2. sl(
; not(C ); ) holds i sl(
;C ; ) does not hold.
3. sl(
; seteq(L;L2); ) holds i L  L2, L2  L and j L j=j L2 j.
4. sl(
; sat(constraints); ) holds i satisfiable(constraints
) hold.
5. sl(
;
2 ; ) holds i (

) 2 (
).
6. sl(
; time(T ); ) holds i current time is T .

72 Chapter 5. Regulating Concurrency
7. sl(
; true; ) always holds.
8. sl(
; constr formula; ) holds i constr formula
 2
.
Case 1 depicts the semantics of atomic formulae and how their individual
substitutions are combined to provide the semantics for a conjunction. Case
2 introduces negation by failure. Case 3 compares if two lists have the same
elements possibly in dierent order. Case 4 checks if a set of constraints is
satisable. Case 5 checks if a constraint belongs to a set of constraints. Case 6
checks if T is current time. Case 7 gives semantics to the keyword true. Case 8
holds when an possibly constrained, atomic formulae constr formula is part of
the state of aairs.
We now dene the semantics of the actions of a rule:
Denition 5.1.2. Relation sr (
;A;
0) mapping a state
, the action section
of a rule and a new state

0
is dened as:
1. sr (
; (A,As);
0) holds i both sr (
;A;
1) and sr (
1;As;
0) hold.
2. sr (
; add(constr formula);
0) holds i
(a) constr formula 62
and
0 =
[ fconstr formulag or;
(b)

0
=
.
3. sr (
; del(constr formula);
0) holds i
(a) constr formula 2
and
0 =
n fconstr formulag or;
(b)

0
=
.
Case 1 decomposes a conjunction and builds the new state by merging the
partial states of each update. Case 2 and 3 cater respectively for the insertion
and removal of atomic formulae .
We now dene relation checkprv that checks if there is no prevent-rule that
has been violated, i.e., it is not the case that all the conditions of any prevent-rule
hold in the state of aairs

0
. It checks whether

0
contain all the conditions
of each prevent-rule or not, if
also contain the given conditions.
Denition 5.1.3. Relation checkprv (
;
0;PrvRules) mapping
, the state be-
fore applying updates,

0
, the state after applying updates, and a sequence
PrvRules of prevent-rules, holds i an empty set is the largest set of conditions
C such that prevent-rule p = prevent C if C 0, p 2 PrvRules, sl(
;C 0) and
sl(
0;C ) hold.
Denition 5.1.4. Relation re(
;PrvRules; if C do A;
0) mapping a state

, a sequence PrvRules of prevent-rules, an if-rule and a new state
0 holds i
red(C ;A) starts to hold, sr (
;A;
0) and checkprv (
;
0;PrvRules) hold.
Relation can re checks whether the conditions of a given if-rule hold and
the rule after applying substitution  has not been already red.

5.1. I: A Language for Institutions 75
Denition 5.1.13. Relation s(
;;ECARules; IfRules; IgnRules;PrvRules;
FrcRules;
0) mapping a state of aairs
, a list  of events that occurred, a
list of ECA-rules, a list of if-rules, a list of ignore-rules, a list of prevent-rules, a
list of force-rules and a new state of aairs holds i:
 Cs is the largest set of conditions C such that red(C ;A) stop holding;
 red(false; false) starts to hold,
 sif (
; IfRules;PrvRules;
00),
 sforce(
00;; IfRules; IgnRules;PrvRules;FrcRules;0;
000) and
 seca(
000;0;ECARules; IfRules; IgnRules;PrvRules;
0) hold.
5.1.3 Interpreter
In this section we introduce the main predicates we use in the interpreter of
language I that we entirely present in Appendix B.
Figure 5.3 shows the top level predicate of our interpreter. Mirroring Def.
5.1.13, s star calculates a new state of aairs triggering rst if-rules to calculate
logical consequences in initial state Delta; then it applies force-rules to create
new forced events; and nally it executes ECA-rules to calculate the causal
consequence of the initial events plus the generated ones. To apply force-rules
and ECA rules, a checking of ignore-rules is performed, i.e. checking if any of
the triggering events is ignored. After each if-rule, force-rule and ECA rule it
checks if any prevent-rule is applicable to reject the triggering of the rule.
Recall from Defs. 5.1.7 and 5.1.6 that we chose if-rules to be triggered in
declaration order. Similarly, by using findall/3 Prolog predicate, we also as-
sume the rest of rules to be triggered in declaration order but no rule resolution
mechanism is provided in our prototype. We acknowledge that ordering of rules
may be a desirable feature in production systems so we envisage a more expres-
sive although more complex denitions of rule triggering including the feature
mentioned above.
In Defs. 5.1.10 and 5.1.2 we introduced how actions in rules change the
initial state by adding and removing possibly constrained atomic formulae. We
use forward chaining for if-rules to calculate logical consequence of facts, that is,
we execute rules until no new rule can be executed. In order to do not repeat
the execution of the same rule with the same parameters we record them during
one exhaustive application of rules.
Thus, starting from a inital state Delta, i.e. a list of atomic formulae, a list
of events Events, and a list of each type of rule, the predicate calculates a new
state NewDelta.
Then, predicate s star calculates a new state performing the following pro-
cedure: it resets the annotations on rules previously red, i.e. executed; it then
calculates a partial state Delta2 by applying if-rules; afterwards it modies the
list of events Events, and the partial state Delta2 with the application of force
rules obtaining a new list of events NewEvents and a new partial state Delta3;

76 Chapter 5. Regulating Concurrency
s_star(Delta,Events,ECARules,IfRules,IgnRules,PrvRules,FrcRules,
NewDelta):-
reset,
s_if(Delta,IfRules,PrvRules,Delta2),
s_force(Delta2,Events,IfRules,IgnRules,PrvRules,FrcRules,
NewEvents, Delta3),
s_eca(Delta3,NewEvents,ECARules,IfRules,IgnRules,PrvRules,
NewDelta).
Figure 5.3: The s star predicate
nally it applies ECA-rules on the partial state Delta3 using the new list of
events NewEvents and obtaining the nal state NewDelta.
As gures 5.4 and 5.5 show, the application of if-rules, mirroring Def. 5.1.8,
consist on the repetition of selecting the rst rule that can be red and apply it
until no new rule can be selected. To execute or re a rule consist on annotating
that the rule has been red with the given parameters, calculating the new state
after applying the actions of the rule and checking if no prevent-rule has to avoid
the result.
s_if(Delta,IfRules,PrvRules,NewDelta):-
select_rule(Delta,IfRules,R),R\=[],
fire(Delta,PrvRules,R,TmpDelta),
s_if(TmpDelta,IfRules,PrvRules,NewDelta).
s_if(Delta,IfRules,_,Delta):-
select_rule(Delta,IfRules,[]).
s_if(Delta,IfRules,PrvRules,NewDelta):-
s_if(Delta,IfRules,PrvRules,NewDelta).
Figure 5.4: The s if predicate
fire(Delta,PrvRules,if C do A,NewDelta):-
assert(fired(if C do A)),
s_r(Delta,A,NewDelta),
check_prv(NewDelta,PrvRules).
Figure 5.5: The fire predicate
Figure 5.6 shows the application of force-rules mirroring Def. 5.1.12. It
consists executing all the rules that can be red, i.e. checking that the partially
grounded events in the rules can be unied with the events in the list Events,
checking with predicate s l that the condition C holds in state Delta and that
the events that re the rules are not ignored by any ignore-rule. Then, rule

5.4. Norm-Oriented Programming of Scenes 81
ignore I if time(T ) & not(per(I ;T ) : C & sat(C )) (5.23)
ignore I if time(T ) & prh(I ;T ) : C & sat(C ) (5.24)
As for obligations, rule 5.25 is an example of rule that removes an obligation
when it is fullled by an institutionalised event. Rule 5.26 shows an example
of rule capturing that if certain conditions hold then an obligation to utter an
(institutionalised) illocution before a given deadline D is generated.
if inst(I ;T ) & obl(I ;T ) : C & sat(C ) do del(obl(I ;T ) : C ) (5.25)
if conds do add(obl(ill(P ;A;R;A2;R2;M );T ) : [T < D ]) (5.26)
Rule 5.27, translated from rule 4.9, states that if an obligation with deadline
has not been fullled, i.e. there exists an obligation with a constraint associated
the time, the deadline has passed, i.e. the current time is greater than or equal
to the deadline, and we have not yet applied a sanction for that particular
obligation, then we apply a sanction.
if
0
B
B
@
obl(ill(inform;Ag1;R;Ag2;R0;Action);T ) : C &
(T < D) 2 C & time(T2) & (T2  D) &
not(sanction(obl(ill(inform;Ag1;R;Ag2;R0;Action);T ); (T < D)))
& credit(Ag1;C ) & credit(ei ;C 2) & C 3 = C 20 & C 4 = C 2 + 20
1
C
C
A
do
0
@
del(credit(Ag1;C )),add(credit(Ag1;C 3)),
del(credit(ei ;C 2)),add(credit(ei ;C 4)),
add(sanction(obl(ill(inform;Ag1;R;Ag2;R0;Action);T ); (T < D)))
1
A
(5.27)
These examples show how I can be also used in the specication and enact-
ment of protocols.
5.4.2 Normative Con
ict Resolution
As we mentioned above, I has a clear semantics: what is not ignored or prevented
is therefore executed. Therefore in the case an event is both expected and
ignored, it will not be executed. Furthermore, in the case of rules 5.23 and 5.24,
if con
icting permissions and prohibitions exist then the illocution is ignored.
However, the normative positions are not removed and may lead the agents to
confusion if they do not have clear that the EI will ignore events in case of
inconsistency.
Although I has a xed semantics, we can work around this by using the
following rules: Rule 5.28 makes prohibitions prevail over permissions and obli-
gations; Rule 5.29 makes prohibitions prevail over permissions but not over obli-
gations; and Rule 5.30 makes prohibitions yield for permissions and obligations.

5.5. Conclusions 83
may be obliged to pay the good in a bank or a special facility for that purpose
possibly using a pre-established protocol dierent from the auction protocol.
Thus, in the next chapter, we generalise the notion of propagation of obligations
to normative positions allowing actions of agents to generate normative posi-
tions in other activities and involving other agents. We specify this causal
ow
by means of a semi-graphical representation, the normative structure which con-
forms a normative layer on top of activities driven by normative positions, e.g.
using languages presented in chapters 4 and 5. Furthermore, proposes a con
ict
resolution algorithm to be applied whenever a normative position is added to a
protocol.