Norm-Oriented Programming Language for Electronic
Institutions
Andre´s Garcı´a-Camino1, J. A. Rodrı´guez-Aguilar1,
Carles Sierra1, and Wamberto Vasconcelos2
1 IIIA-CSIC, Campus UAB 08193 Bellaterra Spain
{andres,jar,sierra}@iiia.csic.es
2 Dept. of Computing Science, Univ. of Aberdeen, AB24 3UE, UK,
wvasconcelos@acm.org
Abstract. Norms constitute a powerful coordination mechanism among hetero-
geneous agents [27, 4]. This work proposes a means to specify and control the
normative dynamics of societies of software agents. For this we introduce a lan-
guage with which one can explicitly manage the normative positions of agents
[21] and distinct deontic notions and their relationships can be captured. This
language is conceived as a machine language to facilitate norm-oriented pro-
gramming and to found higher-level normative languages. We provide a model-
theoretic semantics to our formalism, as well as an operational semantics. Fur-
thermore, we show that our rule-based language captures the expressiveness of a
wide range of normative models and systems in the literature.
1 Introduction
At the beginning of the multi-agent system (MAS) paradigm, the behaviour of agents
was regulated assuming that the system is closed, imposing a certain architecture and
specification language in the design of agents which can be easily verified not to violate
any specification requirement.
One of the major challenges in MAS research is the design and implementation of
open multi-agent systems where agents can be specified with different architectures and
different specification languages by several, maybe distrusted, designers [12]. Norms
can be used for this purpose as a mean to regulate the observable behaviour of agents
as they interact in pursuit of their goals [7, 17]. There is a wealth of socio-philosophical
and logic-theoretical investigation on the subject of norms (e.g., [5, 21–23]). But re-
cently more attention has being paid to more pragmatic and implementational aspects
of norms, that is, how norms can be given a computational interpretation and how norms
can be factored in the design and execution of MASs (e.g. [10]).
And yet, we believe that there is a need for norm-oriented programming languages
that support the implementation of normative systems. We try to make headway along
this direction by introducing a language to specify agents’ normative positions and man-
age their changes as agents interact. A normative position [21] is the “social burden”
associated with individual agents, that is, their obligations, permissions and prohibi-
tions. Depending on what agents do, their normative positions may change – for in-
stance, permissions/prohibitions can be revoked or obligations, once fulfilled, may be

2 A. Garcı´a-Camino et al.
removed. We present a language that acts as a “machine language” for norms on top of
which higher-level languages may eventually be accommodated. This language can rep-
resent distinct flavours of deontic notions and relationships. Although our language is
rule-based, we achieve greater flexibility, expressiveness and precision than production
systems by allowing constraints to be part of our rules. We provide a model-theoretic se-
mantics to our language, as well as an operational semantics setting the foundations for
the language implementation. Although in this paper we restrict to a particular type of
MAS, namely Electronic Institutions [8], we believe that we managed to set the founda-
tions for specify and implement normative systems in general using only our language.
This would allow us to implement different models of institutions like [8][21][26].
In section 2 we present the desired properties of an operationalisable normative lan-
guage. In section 3 we propose the simplest normative language that covers all these
requirements. Section 4 summarises the notion of Electronic Institution and details how
to capture normative positions of its participating agents. A case study is detailed in
section 5. In section 6 we show how to employ our language to capture the expressive-
ness of other contemporary approaches. Finally, we draw some conclusions and outline
future work in section 7.
2 Desiderata for Norm-Oriented MASs
Our main goal is to produce a language that supports the specification of coordination
mechanisms in multi-agent systems by means of norms. For this purpose, we identify
below the desirable features we expect from our language.
We take the stance that we cannot refer to agents’ mentalistic notions, but only
to their observable actions. As a result of agents’ social interactions, their normative
positions [21] – permissions, prohibitions and obligations – change. Hence, the first
requirement of our language is to support the explicit management of agents’ normative
positions.
Turning our attention to theoretical models of norms, we notice that there is a
plethora of deontic logics with different axioms to establish relationships among deon-
tic notions. Thus, we require that our language captures different deontic notions along
with their relationships. In other words, the language must be of general purpose so
that it helps MAS designers to encode any axiomatisation, and thus specify the widest
range of normative systems as possible.
In a sense, we pursue a “machine language” for norms on top of which higher-level
languages may eventually be accomodated. Along this direction, and from a language
designer’s point of view, it is fundamental to identify the norm patterns (e.g. conditional
obligation, time-based permissions and prohibitions, continuous obligation, and so on)
in the literature to ensure that our language supports their encoding (as demonstrated
in section 6). In this way, not only shall we be guaranteeing the expressiveness of our
language, but also addressing pragmatic concerns by providing design patterns to guide
and ease MAS design.
In order to ease MAS programming, we shall also require our language to be declar-
ative, with an implicit execution mechanism to reduce the number of issues designers

Norm-Oriented Programming Language for Electronic Institutions 3
ought to concentrate on. As an additional benefit, we expect its declarative nature to
facilitate verification of properties of the specifications.
3 A Language for Managing Norms
The building blocks of our language are first-order terms (denoted as T) and atomic
formulae (denoted as A). We shall make use of numbers and arithmetic functions to
build terms; arithmetic functions may appear infix, following their usual conventions.
We adopt Prolog’s convention [2] using strings starting with a capital letter to represent
variables and strings starting with a small letter to represent constants. We also employ
arithmetic relations (e.g., =, 6=, and so on) as predicate symbols, and these will appear
in their usual infix notation. Atomic formulae with arithmetic relations represent con-
straints on their variables and have a special status, as we explain below. We give a
definition of our constraints, a specific subset of our atomic formulae:
Def. 1. A constraint C is any construct of the form T  T,  ∈ {=, 6=, >,≥, <,≤}
We need to differentiate ordinary atomic formula from constraints. We shall use A′ to
denote atomic formulae that are not constraints.
We now introduce our rules. These are constructs of the form LHS RHS,
where LHS contains a representation of parts of the current state of affairs which, if
they hold, will cause the rule to be triggered. RHS depicts the updates to the current
state of affairs, yielding the next state of affairs:
Def. 2. A rule, denoted as R, is defined as:
R ::= LHS RHS
LHS ::= As ∧ LHS | ¬As ∧ LHS | As | ¬As
RHS ::= U ∧RHS | U
As ::= As ∧ As | A
U ::= ⊕A′ | A′ | ⊕C
Some examples of our rules are shown in section 5. The Us (updates) add and remove
A′s but constraints C can only be added – our rules work by refining a state of affairs,
always adding constraints. Finally, we make use of a special kind of term, called a set
constructor, represented {A′ | LHS}. It is useful when we need to refer to all A’s in
the state of affairs for which LHS holds. For instance,
{utt(auction,W , I) | I = p(Ag1, buyer,Ag2,R,M ,T ) ∧ T > 20}
stands for the set of utterances in scene auction by buyer agent Ag1 after time-stamp
20.
The semantics of our rules are defined in terms of state of affairs: rules map an
existing state of affairs to a new state of affairs. Intuitively, a state of affairs stores the
current state of the environment as a set of atomic formulae:
Def. 3. A state of affairs ∆ = {A0, . . . ,An} is a a finite and possibly empty set of
atomic formulae Ai , 0 ≤ i ≤ n .

4 A. Garcı´a-Camino et al.
We now define the semantics of our rules as relationships between states of affairs. We
adopt the usual semantics of production rules [14, 20], that is, we exhaustively apply
each rule by matching its LHS against the current state of affairs and use the values of
variables obtained in this match to instantiate the RHS.
Def. 4. s∗(∆,LHS RHS,∆′) holds iff s∗l (∆,LHS, {σ1, . . . , σn}) and sr (∆,
RHS · σi ,∆′), 1 ≤ i ≤ n , hold.
That is, two states of affairs ∆ and ∆′ are related by a rule LHS RHS if, and only
if, we obtain all different substitutions {σ1, . . . , σn} that make the left-hand side match
∆ and apply these substitutions to RHS in order to build∆′.
We now state when the left-hand side of a rule matches a state of affairs. We employ
relationship sl(∆,LHS, σ) defined below.
Def. 5. sl(∆,LHS, σ) holds between state of affairs ∆, the left-hand side of a rule
LHS and a substitution σ depending on the format of LHS:
1. sl(∆,Atfs
′ ∧ Constrs, σ) holds iff sl(∆,Atfs
′, σ) and sl(∆,Constrs, σ) hold.
2. sl(∆,Atf
′ ∧ Atfs′, σ) holds iff sl(∆,Atf
′, σ′) and sl(∆,Atfs
′, σ′′) hold and
σ = σ′ ∪ σ′′.
3. sl(∆,¬ Atf
′, σ) holds iff sl(∆,Atf
′, σ) does not hold.
4. sl(∆,Atf
′, σ) holds iff Atf ′ · σ ∈ ∆.
5. sl(∆, (Constr1 ∧ · · · ∧ Constrn), σ) holds iff constrs(∆,C ) and {Constr1 ·
σ, . . . , Constrn · σ} v C .
Case 1 breaks the left-hand side of a rule into its atomic formulae and constraints and
defines how their semantics are combined via σ. Cases 2-4 depict the semantics of
atomic formulae and how their individual substitutions are combined to provide the se-
mantics for a conjunction. Case 5 formalises the semantics of our constraints when they
appear on the left-hand side of a rule: we apply the substitution σ to them (thus reflect-
ing any values of variables given by the matchings of atomic formula), then compare
constraints using v.
We want our rules to be exhaustively applied on the state of affairs. We thus need
relationship s∗l (∆,LHS,Σ) which uses sl above to obtain in Σ = {σ0, . . . , σn} all
possible matches of the left-hand side of a rule:
Def. 6. s∗l (∆,LHS,Σ) holds, iff Σ = {σ1, . . . , σn} is the largest non-empty set such
that sl(∆,LHS, σi), 1 ≤ i ≤ n , holds.
We can define the application of a set of a substitutions Σ = {σ1, . . . , σn} to a term
Term: this results in a set of substituted terms, Term · {σ1, . . . , σn} = {Term ·
σ1, . . . , T erm · σn}. We now define the semantics of the RHS of a rule:
Def. 7. Relation sr (∆,RHS,∆′) mapping a state of affairs ∆, the right-hand side of
a rule RHS and another state of affairs∆′ is defined as:
1. sr (∆, (Update ∧ RHS),∆′) holds iff both sr (∆,Update,∆1) and sr (∆,RHS,
∆2) hold and∆′ = ∆1 ∪∆2.
2. sr (∆,⊕Atf
′,∆′) holds iff∆′ = ∆ ∪ {Atf ′}.
3. sr (∆, Atf
′,∆′) holds iff∆′ = ∆ \ {Atf ′}.
4. sr (∆,⊕Constr,∆′) = true iff constrs(∆,C ) and satisfy(C ∪{Constr},C ′)
hold and∆′ = ∆ ∪ Constr.

Norm-Oriented Programming Language for Electronic Institutions 5
Case 1 decomposes a conjunction and builds the new state by merging the partial states
of each update. Cases 2 and 3 cater for the insertion and removal of atomic formulae
Atf ′ which do not conform to the syntax of constraints. Case 4 defines how a constraint
is added to a state of affairs ∆: the new constraint is checked for its satisfaction with
constraints C ⊆ ∆ and then added to∆′. We assume the new constraint is merged into
∆: if there is another constraint that subsumes it, then the new constraint is discarded.
For instance, if X > 20 belongs to ∆, then attempting to add X > 15 will yield the
same∆.
In the usual semantics of rules of production systems, the values assigned to those
variables in the left-hand side must be passed on to the right-hand side. We capture
this by associating the right-hand side with a substitution σ obtained when matching
the left-hand side against ∆ via relation sl . In the definition 7 above, we have actually
sr (∆,RHS · σ,∆′) – that is, we have a version of the right-hand side with ground
variables whose values originate from the matching of the left-hand side to∆.
The semantics above define an infinite sequence of states 〈∆0,∆1, . . .〉 if s∗(∆i ,
{R1, . . . ,Rn},∆i+1), that is,∆i+1 (obtained by applying the rules to∆i ) is used to ob-
tain∆i+2 and so on. Figure 1 illustrates how this sequence can accommodate the inter-
Fig. 1. Semantics as a Sequence of ∆’s
vention of agents, that is, their messages. The diagram shows an initial state∆0 (possi-
bly empty) that is offered (represented by “”) to a set of agents {ag1, . . . , agn}. These
agents add their utterances {A01, . . . ,A
0
n} to ∆0. After the agents add their utterances,
then the rules are exhaustively applied (represented by “
∗
”) to ∆0 ∪ {A01, . . . ,A
0
n}.
The resulting state ∆1 is, on its turn, offered to agents, and so on. A meta-interpreter
[11] operationalises the semantics above.
4 Electronic Institutions
Our work fits within the context of electronic institutions (EIs) [8], providing them
with an explicit normative layer. There are two major features in EIs – the states and
illocutions (i.e., messages) uttered (i.e., sent) by those agents taking part in the EI. The
states are connected via edges labelled with the illocutions that ought to be sent at that
particular point in the EI. Another important feature in EIs are the agents’ roles: these
are labels that allow agents with the same role to be treated collectively thus helping

6 A. Garcı´a-Camino et al.
engineers abstract away from individuals. We define below the class of illocutions we
aim at – these are a special kind of term:
Def. 8. Illocutions ı¯ are terms p(ag, r, ag′, r′,T, t) where p is an illocutionary particle
(e.g., inform,ask); ag, ag′ are agent identifiers; r , r ′ are role labels; T is a term with
the actual content of the message; t ∈ IN is a time stamp.
We shall refer to illocutions that may have uninstantiated (free) variables within them-
selves as illocution schemes and will be denoted by I.
Another important concept in EIs we employ here is that of a scene. Scenes offer
means to break down larger protocols into smaller ones with specific purposes. We can
uniquely refer to the point of the protocol where an illocution ı¯ was uttered by the pair
(s,w) where s is a scene name and w is the state from which an edge labelled with I
leads to another state.
An institutional state is a state of affairs that stores all utterances during the execu-
tion of a MAS, also keeping a record of all obligations, permissions and prohibitions
associated with the agents. We differentiate five kinds of atomic formulae in our insti-
tutional states∆, with the following intuitive meanings:
1. ground formulae oav(o, a, v) – object o has an attribute called a with value v .
2. ground formulae att(s,w , ı¯) – an agent attempted to utter ı¯ at state w of scene s .
3. ground formulae utt(s,w , ı¯) – ı¯ was uttered at w of s .
4. obl(s,w , i) – i is obliged to be uttered at w of s .
5. per(s,w , i) – i is permitted to be uttered at w of s .
6. prh(s,w , i) – i is prohibited at w of s .
7. ctr(s,w , st , ts) – s entered to w at state st and time ts
We shall use formulae 4–6 above to represent normative aspects of agent societies. We
only allow fully ground illocutions and attributes (cases 1–3 above) to be uttered1; how-
ever, in formulae 4-6 s andw may be variables and i may contain variables. We shall use
formulae 7 to represent the state change and time passing. We do not “hardwire”deontic
notions in our semantics: the predicates above represent deontic operators but not their
relationships. These are captured with rules (also called in this context institutional
rules), conferring generality on our approach as different deontic relationships can be
forged, as we show below.
5 Example: The Dutch Auction Protocol
In this section, we try to illustrate the pragmatics of our norm-oriented language by
specifying the auction protocol employed in the fish market described in [19]. Following
1 We differentiate between attempts to utter (att) and actual utterances (utt). Since we aim at
heterogeneous agents whose behaviour we cannot guarantee, we create a “sandbox” where
agents can utter whatever they want and we represent these utterances via att formulae. How-
ever, not everything agents say may be in accordance with the protocol specification – the ut-
terances that are not part of the protocol may be discarded or may cause sanctions, depending
on the deontic notions we want or need to implement. The utt formulae are thus confirmations
of the att formulae.

Norm-Oriented Programming Language for Electronic Institutions 7
[19], the fish market can be described as a place where several scenes [8] take place
simultaneously, at different locations, but with some causal continuity. The principal
scene is the auction itself, in which buyers bid for boxes of fish that are presented by
an auctioneer who calls prices in descending order, the so-called downward bidding
protocol, a variation of the traditional Dutch auction protocol that proceeds as follows:
[Step 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.
[Step 2 ] With a chosen good g , the auctioneer opens a bidding round by quoting offers
downward from the good’s starting price, (pα) previously fixed by a sellers’ admit-
ter, as long as these price quotations are above a reserve price (prsv ) previously
defined by the seller.
[Step 3 ] For each price the auctioneer calls, several situations might arise during the
open round described below.
[Step 4 ] The first three steps repeat until there are no more goods left.
The situations arising in step 3 are:
Multiple bids – Several buyers submit their bids at the current price. In this case, a
collision comes about, the good is not sold to any buyer, and the auctioneer restarts
the round at a higher price;
One bid – Only one buyer submits a bid at the current price. The good is sold to this
buyer whenever his credit can support his bid. Otherwise, the round is restarted by
the auctioneer at a higher price, the unsuccessful bidder is fined;
No bids – No buyer submits a bid at the current price. If the reserve price has not been
reached yet, the auctioneer quotes a new price obtained by decreasing the current
price according to the price step. Otherwise, the auctioneer declares the good as
withdrawn and closes the round.
Proposed Solution: These features are captured in figure 2 ( for formatting reasons,
we will use Ai and Asi to denote, respectively, an atomic formula and a conjunction of
them):
Multiple bids – Expression 1 shows a rule that obliges the auctioneer to inform the
buyers, whenever a collision comes about, about the collision and to restart the
bidding round at a higher price (in this case, 120% the collision price). Notice that
X will hold all the utterances at scene DutchA and state w4 issued by buyer agents
that bid for an item IT at price P at time T0 after the last offer. We obtain the last
offers by checking that there are not further offers whose time-stamp are greater
than the time-stamp of the first one. If the number of illocutions in X is greater
than one, the rule fires the obligation above;
Timeout – Each bidding round has a associated bidding time that can be regarded as
a timeout. Expression 2 shows a rule that checks whether the bidding time has
expired since scene DutchA reached state w4. Intuitively it means that if we are
at state w4, the amount of time before the timeout is stored by an oav and it is
To , the last time the scene entered at state w3 was T and the first time the scene
entered at state w4 after T was T3 (and time-stamp Timestamp3), D is the current

8 A. Garcı´a-Camino et al.

X =

A0 A1 ∧ ¬ (A2 ∧ T2 > T1) ∧ T0 > T1

∧ | X |> 1




⊕A3 ∧ ⊕A4 ∧ ⊕(P2 > P ∗ 1.2)


where
A0 = utt(DutchA,w4, inform(A1, buyer ,Au, auctioneer , bid(IT ,P),T0))
A1 = utt(DutchA,w3, offer(Au, auctioneer ,All, buyer , offer(IT ,P),T1)),
A2 = utt(DutchA,w3, offer(Au, auctioneer ,All, buyer , offer(IT ,P),T2))
A3 = obl(DutchA,w5, inform(Au, auctioneer ,All, buyer , collision(IT ,P),T2))
A4 = obl(DutchA,w3, inform(Au, auctioneer ,All, buyer , offer(IT ,P2),T3))
(1)

ctr(DutchA,w4,T0,Ts0) ∧ now(T0) ∧ oav(DutchA w4, timeout,Tout )∧
As0 ∧ As1 ∧ T3 > T ∧ As2 ∧ current date(D) ∧D − Timestamp3 > Tout



⊕ctr(DutchA,w5,T6,D) ∧ now(T0) ∧ ⊕now(T6)∧
⊕(T6 = T0 + 1) ∧ ⊕timeout(DutchA,w4,w5,T6)

where
As0 = ctr(DutchA,w3,T ,Timestamp) ∧ ¬ (ctr(DutchA,w3,T2,Timestamp2) ∧ T2 > T)
As1 = ctr(DutchA,w4,T3,Timestamp3) ∧ ¬ (ctr(DutchA,w4,T4,Timestamp4) ∧ T4 < T3)
As2 = ¬ (utt(DutchA,w4, inform(A1, buyer ,Au, auctioneer , bid(IT ,P),T5)) ∧ T5 > T)
(2)

X =

A0 A1 ∧ ¬ (A2 ∧ T2 > T1) ∧ T0 > T1

∧ | X |= 1 ∧ oav(A1, credit,C ) ∧ C ≥ P




⊕A3


where
A0 = utt(DutchA,w4, inform(A1, buyer ,Au, auctioneer , bid(IT ,P),T0))
A1 = utt(DutchA,w3, offer(Au, auctioneer ,All, buyer , offer(IT ,P),T1)),
A2 = utt(DutchA,w3, offer(Au, auctioneer ,All, buyer , offer(IT ,P),T2))
A3 = obl(DutchA,w5, inform(Au, auctioneer ,All, buyer , sold(IT ,P,A1),T4))
(3)

A0 ∧ ¬ (A1 ∧ T2 > T) ∧ oav(Ag, credit,C ) ∧ C < P




⊕A2


where
A0 = utt(DutchA,w3, inform(Au, auctioneer ,A, buyer , offer(IT ,P),T))
A1 = utt(DutchA,w3, inform(Au, auctioneer ,A, buyer , offer(IT ,P),T2))
A2 = prh(DutchA,w4, inform(A, buyer ,Au, auctioneer , bid(IT ,P2),T3))
(4)

X =

A0 A1 ∧ ¬ (A2 ∧ T2 > T1) ∧ T0 > T1

∧
| X |= 1 ∧ oav(A1, credit,C ) ∧ C < P



oav(A1, credit,C ) ∧ ⊕oav(A1, credit,C2) ∧ ⊕A3
⊕(C2 = C − P ∗ 0.1) ∧ ⊕(P2 = P ∗ 1.2)

where
A0 = utt(DutchA,w4, inform(A1, buyer ,Au, auctioneer , bid(IT ,P),T0))
A1 = utt(DutchA,w3, offer(Au, auctioneer ,All, buyer , offer(IT ,P),T1)),
A2 = utt(DutchA,w3, offer(Au, auctioneer ,All, buyer , offer(IT ,P),T2))
A3 = obl(DutchA,w5, offer(Au, auctioneer ,All, buyer , offer(IT ,P2),T3))
(5)
0
@
ctr(DutchA,w5,Tn ,Ts) ∧ now(Tn) ∧ A0 ∧ ¬ (A1 ∧ T2 > T)∧
timeout(DutchA,w4,w5,T3) ∧ T3 > T ∧ oav(IT , reservation price,RP)∧
oav(IT , decrement rate,DR) ∧ RP < P −DR
1
A


⊕A2 ∧ ⊕(P2 = P −DR)


where
A0 = utt(DutchA,w3, offer(Au, auctioneer ,All, buyer , offer(IT ,P),T))
A1 = utt(DutchA,w3, offer(Au, auctioneer ,All, buyer , offer(IT ,P),T2))
A2 = obl(DutchA,w5, offer(Au, auctioneer ,All, buyer , offer(IT ,P2),T4))
(6)
0
@
ctr(DutchA,w5,Tn ,Ts) ∧ now(Tn) ∧ A0 ∧ ¬ (A1 ∧ T2 > T)∧
timeout(DutchA,w4,w5,T3) ∧ T3 > T ∧ oav(IT , reservation price,RP)∧
oav(IT , decrement rate,DR) ∧ RP ≥ P −DR
1
A

⊕A2


where
A0 = utt(DutchA,w3, offer(Au, auctioneer ,All, buyer , offer(IT ,P),T))
A1 = utt(DutchA,w3, offer(Au, auctioneer ,All, buyer , offer(IT ,P),T2))
A2 = obl(DutchA,w5, inform(Au, auctioneer ,All, buyer ,withdrawn(IT),T3))
(7)
Fig. 2. Institutional rules for the Dutch auction protocol

Norm-Oriented Programming Language for Electronic Institutions 9
date and the time that have passed from Timestamp3 until now is greater than the
timeout To then we update the current state from w4 to w5, change the current
time (now(T6)) and register the timeout in the model. We use the predicate ctr to
store the history of states ordered by a natural T0 and time-stamped Ts0
One bid - Winner determination – Expression 3 states that if only one bid has oc-
curred during the current bidding round and the credit of the bidding agent is greater
or equal than the price of the good in auction, the rule adds the obligation for the
auctioneer to inform all the buyers about the sale;
One bid - Unsupported bid – In the current formalization of electronic institutions
[8], illegal illocutions are prevented by rejecting them. Therefore, agents can not
be punished when acting illegaly.
a) Prevention – Expression 4 shows a rule that prevents agents to issue bids whose
credit can notpay for. It states that if P is the last offer called by an auctioneer for
item IT , at scene DutchA and state w3, and agent Ag’s credit is less than P , then
agent Ag is prohibited to bid;
b) Punishment – In case we do not want to reject illegal actions, we must provide
methods for discouraging agents to violate norms. For instance, by applying pun-
ishments when norms are violated. Expression 5 shows a rule that punishes an agent
when issuing a winning bid he can not pay for. More precisely, the rule punishes an
agent (A1) by decreasing his credit 10% the value of the good at auction. The oav
predicate on the LHS of the rule is used for gathering the value of the current credit
of the offender agent. The rule also add an obligation for the auctioneer to restart
the bidding round and the constraint that the new offer should be greater than 120%
the old price;
No bids - New Price – Expression 6 shows a rule that checks if there were no bids and
the next price is greater than the reservation price. If so, it adds the obligation for the
auctioneer to start a new bidding round. Rule 6 checks that the current scene state is
w5, whether a timeout has expired after the last offer and whether the new price is
greater than reservation price. If so, the rule adds the obligation for the auctioneer
to offer the item at a lower price. By retrieving the last offer we gather the last offer
price. By checking the oav predicates we gather the values of the reservation price
and the decrement rate for item IT . 5)
No bids - Withdrawal – Expression 7 shows a rule that checks if there were no bids
and the next price is less than the reservation price, then adds the obligation for the
auctioneer to withdraw the item. Rule 7 checks that the current institutional state is
w5, whether a timeout has occurred after the last offer and whether the new offer
price is greater than reservation price. If the LHS holds, the rule fires to add the
obligation for the auctioneer to withdraw the item. By checking the last offer we
gather the last offer price. By checking the oav predicates we gather the values of
the reservation price and the decrement rate for item IT .
6 Expressiveness Analysis
In this section we analyse the expressiveness of our language by comparing it with other
recent approaches.

10 A. Garcı´a-Camino et al.
6.1 Conditional Deontic Logic with Deadlines
As shows the BNF definition of figure 3 [24, 25], a norm description is composed by
several fields.
The norm condition is the declarative norms, as obtained from, for instance, the
legal domain. The other fields in the norm description are; 1) the violation condition
which is a formula defining when the norm is violated, 2) the detection mechanism
which describes the mechanisms included in the agent platform that can be used for
detecting violations, 3) the sanctions which defines the actions that are used to punish
the agent(s) violation of the norm, and 4) the repairs which is a set of actions that are
used for recovering the system after the occurrence of a violation.
NORM ::= NORM CONDITION
VIOLATION CONDITION
DETECTION MECHANISM
SANCTIONS
REPAIRS
VIOLATION CONDITION ::= formula
DETECTION MECHANISM ::= {action expressions}
SANCTIONS ::= PLAN
REPAIRS ::= PLAN
PLAN ::= action expression | action expression ; PLAN
Fig. 3. BNF of Utrecht’s norms
As the definition of figure 4 shows, norms can be deontic notions as either permis-
sions, obligations or prohibitions. Furthermore, norms can be related to actions or to
predicates (states). The former restrict or allow the actions that a set of agents can per-
form, the latter constrain the results of the actions that a set of agents can perform. This
results are predicates that can be done true or false. It is forbidden that tom performs
the action of smoke (FORBIDDEN (tomDOsmoke)) 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.
NORM CONDITION ::= N(S 〈IF C〉) | OBLIGED(a ENFORCE(N(a, S〈IF C〉)))
N ::= OBLIGED | PERMITTED | FORBIDDEN
J ::= (a,P) | (aDOA)
S ::= J | J TIME | J ACTION
C ::= formula
P ::= predicate
A ::= action expression
TIME ::= BEFORED |AFTERD
ACTION ::= BEFOREJ |AFTERJ
Fig. 4. BNF of the norm condition

Norm-Oriented Programming Language for Electronic Institutions 11
Through the condition (C) and temporal operators (BEFORE and AFTER), norms
can be made only applicable to certain situations. Conditions and temporal operators
are considered optional. Temporal operators can be applied to a deadline (D) or to an
action or predicate (J).
Now we are going to expose the translation of the norms presented above into our
rule language. Since we consider illocutions as the only actions that can be performed
in a electronic institution, actions need to be translated into illocutions uttering that the
action has been done.
Utrecht norms Institutional rules
PERMITTED((ADOutter(S ,W , I ))) scene(S ,W ) ∧ att(S ,W , I )
⇒ att(S ,W , I ) ∧ ⊕utt(S ,W , I )
FORBIDDEN((ADOutter(S ,W , I ))) scene(S ,W ) ∧ att(S ,W , I )
⇒ att(S ,W , I ) ⊕ vio
OBLIGED((ADOutter(S ,W , I ))) a) scene(S ,W ) ∧ ¬ utt(S ,W , I ) ⇒ ⊕vio
b) scene(S ,W ) ∧ obl(S ,W , I )∧
utt(S ,W , I ) ⇒ obl(S ,W , I )
Table 1. Translation of general norms into rules
Table 1 shows the translation of general norms into our rules. The permission of
an action can be translated into a rule the converts the attempt to utter the I illocution
at state W of scene S (att(S ,W , I )) into the result of the illocution being uttered
(utt(S ,W , I )). The prohibition of an action can be translated into a rule that ignores
the attempt to utter the illocution, and optionally can sanction the violation (vio(id)).
For space reasons, we use the predicate vio to represent that the proper sanctions and
repairs are executed. We assume that there exists another rule with the vio predicate on
the LHS and sanctions and repairs on the RHS. The obligation of an action needs to
be translated into two rules. The former rule sanctions the obliged agents if they do not
utter the expected illocution in the scene and state in which they are obliged to do it.
The latter rule removes the obligation once the obliged action has been done.
Utrecht norms Institutional rules
PERMITTED((ADOutter(S ,W , I ))if C ) scene(S ,W ) ∧ C ∧ att(S ,W , I )
⇒ att(S ,W , I ) ∧ ⊕utt(S ,W , I )
FORBIDDEN((ADOutter(S ,W , I ))if C ) scene(S ,W ) ∧ C ∧ att(S ,W , I )
⇒ att(S ,W , I ) ∧ ⊕vio(1)
OBLIGED((ADOutter(S ,W , I ))if C ) a) scene(S ,W ) ∧ C ∧ ¬ utt(S ,W , I ) ⇒ ⊕vio(2)
b) scene(S ,W ) ∧ C ∧ obl(S ,W , I )∧
utt(S ,W , I ) ⇒ obl(S ,W , I )
Table 2. Translation of conditional norms into rules
Table 2 shows the translation of conditional norms into our rules. This translation
can be done in a similar way to the translation done in the previous table but adding a
condition (C ) on the LHS of the rule.

12 A. Garcı´a-Camino et al.
Utrecht norms Institutional rules
PERMITTED((ADOutter(S ,W , I ))BEFORED) scene(S ,W ) ∧ att(S ,W , I ) ∧ T < D
⇒ att(S ,W , I ) ∧ ⊕utt(S ,W , I )
FORBIDDEN((ADOutter(S ,W , I ))BEFORED) scene(S ,W ) ∧ att(S ,W , I ) ∧ T < D
⇒ att(S ,W , I ) ⊕ vio(3)
OBLIGED((ADOutter(S ,W , I ))BEFORED) a) scene(S ,W ) ∧ ¬ utt(S ,W , I )∧
current time(T1) ∧ T1 > D ⇒ ⊕vio(4)
b) scene(S ,W ) ∧ utt(S ,W , I ) ∧ T > D ⇒ ⊕vio(5)
c) scene(S ,W ) ∧ obl(S ,W , I )∧
utt(S ,W , I ) ∧ T < D ⇒ obl(S ,W , I )
Table 3. Translation of “BEFORE time” norms into rules
Table 3 shows the translation of norms with the BEFORE time construct into our
rules. This translation can be done likewise the translation done in the table 1 but adding
in the LHS of the rule the condition that the time in which the attempt is done (T ) has to
be less that the deadline (D). Now in the translation of obligations we need three rules:
one to sanction the agents that do not utter the expected illocution before the deadline,
other to sanction the agents that utter the expected illocution late and another rule to
remove the obligation if the illocution is uttered before the deadline.
Utrecht norms Institutional rules
PERMITTED((ADOutter(S ,W , I ))AFTERD) scene(S ,W ) ∧ att(S ,W , I ) ∧ T > D
⇒ att(S ,W , I ) ∧ ⊕utt(S ,W , I )
FORBIDDEN((ADOutter(S ,W , I ))AFTERD) scene(S ,W ) ∧ att(S ,W , I ) ∧ T > D
⇒ att(S ,W , I ) ⊕ vio(6)
OBLIGED((ADOutter(S ,W , I ))AFTERD) scene(S ,W ) ∧ obl(S ,W , I ) ∧ utt(S ,W , I )∧
T > D ⇒ obl(S ,W , I )
Table 4. Translation of “AFTER time” norms into rules
Table 4 shows the translation of norms with the construct AFTER time into our
rules. This translation can be done in a similar way to the translation done in the table
1 but adding to the LHS of the rule the condition that the time in which the attempt is
done (T ) has to be greater that the deadline (D). Now in the translation of obligations
we only need one rule to remove the obligation if the illocution is uttered after the
specified time. In the current implementation of electronic institutions obligations must
be satisfied the first time the agents are in the expected scene and state. However, as we
do not assume that, this norm can not be sanctioned.
Table 5 shows the translation of norms with the construct BEFORE action into
our rules. The translation of a permission before another utterance is done by adding
two rules that transform an attempt to utter into the illocution being uttered, first if the
second action has not been performed yet or if the second illocution has been uttered
but after the permitted illocution. The translation of a prohibition before another utter-
ance is also done by adding two rules similar to the rules for the permitted before case
but changing the RHS to sanction the violation. The translation of an obligation be-
fore another utterance is done by means of four rules; a) sanctions when the permitted
illocution has not been uttered and the deadline illocution has been uttered; b) sanc-

Norm-Oriented Programming Language for Electronic Institutions 13
Utrecht norms Institutional rules
PERMITTED((ADOutter(S ,W , I )) a) scene(S ,W ) ∧ att(S ,W , I ) ∧ ¬ utt(S2,W2, I2)
BEFORE(BDOutter(S2,W2, I2))) ⇒ att(S ,W , I ) ∧ ⊕utt(S ,W , I )
b) scene(S ,W ) ∧ att(S ,W , I ) ∧ utt(S2,W2, I2) ∧ T < T2
⇒ att(S ,W , I ) ∧ ⊕utt(S ,W , I )
FORBIDDEN((ADOutter(S ,W , I )) a) scene(S ,W ) ∧ att(S ,W , I ) ∧ ¬ utt(S2,W2, I2)
BEFORE(BDOutter(S2,W2, I2))) ⇒ att(S ,W , I ) ⊕ vio(7)
b) scene(S ,W ) ∧ att(S ,W , I ) ∧ utt(S2,W2, I2) ∧ T < T2
⇒ att(S ,W , I ) ⊕ vio(8)
OBLIGED((ADOutter(S ,W , I )) a) scene(S ,W ) ∧ ¬ utt(S ,W , I ) ∧ utt(S2,W2, I2)
BEFORE(BDOutter(S2,W2, I2))) ⇒ ⊕vio(9)
b) scene(S ,W ) ∧ utt(S ,W , I ) ∧ utt(S2,W2, I2)∧
T > T2 ⇒ ⊕vio(10)
c) scene(S ,W ) ∧ obl(S ,W , I ) ∧ utt(S ,W , I )∧
¬ utt(S2,W2, I2) ⇒ obl(S ,W , I )
d) scene(S ,W ) ∧ obl(S ,W , I ) ∧ utt(S ,W , I )∧
utt(S2,W2, I2) ∧ T < T2 ⇒ obl(S ,W , I )
Table 5. Translation of “BEFORE action” norms into rules
tions when the deadline illocution has been uttered before the permitted illocution; c)
removes the obligation if it is fulfilled and the deadline illocution has not been uttered;
and d) removes the obligation if it is fulfilled before the deadline illocution has been
uttered.
Utrecht norms Institutional rules
PERMITTED((ADOutter(S ,W , I )) scene(S ,W ) ∧ att(S ,W , I ) ∧ utt(S2,W2, I2)∧
AFTER(BDOutter(S2,W2, I2))) T > T2 ⇒ att(S ,W , I ) ∧ ⊕utt(S ,W , I )
FORBIDDEN((ADOutter(S ,W , I )) scene(S ,W ) ∧ att(S ,W , I ) ∧ utt(S2,W2, I2)∧
AFTER(BDOutter(S2,W2, I2))) T > T2 ⇒ att(S ,W , I ) ⊕ vio(11)
OBLIGED((ADOutter(S ,W , I )) scene(S ,W ) ∧ obl(S ,W , I ) ∧ utt(S ,W , I ) ∧ utt(S2,W2, I2)∧
AFTER(BDOutter(S2,W2, I2))) T > T2 ⇒ obl(S ,W , I )
Table 6. Translation of “AFTER action” norms into rules
Table 6 shows the translation of norms with the AFTER action construct into our
rules. The translation of these type of norms is simply done by checking if the time when
the attempt to utter an illocution is greater than the time of the deadline illocution.
We will not deeply cope with the bringing about of predicates. But they can be trans-
lated into rules in a similar way as stated above. For that purpose, we use a new predicate
to represent an attempt to bring about something: att(A,R,P ,T ). That means that an
agentAwho enacts roleR attempts to bring aboutP at timeT . We use brg(A,R,P ,T )
to represent that an agentAwho enacts roleR brought aboutP at timeT . Table 7 shows
the translation of norms with predicates into rules.
Hence, the norms defined by Dignum et al. can be translated into normative rules
by adding the violation condition into the LHS of the rule and sanctions and repairs into
the RHS as the following rule scheme shows:
VC ⇒ S ∧ R

14 A. Garcı´a-Camino et al.
Utrecht norms Institutional rules
PERMITTED((A,P)) now(T) ∧ att(A,R,P,T) ⇒ att(A,R,P,T) ∧ ⊕brg(A,R,P,T) ∧ ⊕P
FORBIDDEN((A,P)) now(T) ∧ att(A,R,P,T) ⇒ att(A,R,P,T) ⊕ vio(1)
OBLIGED((A,P)) now(T) ∧ obl(A,R,P,T1) ∧ brg(A,R,P,T) ⇒ obl(A,R,P,T1)
PERMITTED((A,P)if C ) now(T) ∧ C ∧ att(A,R,P,T) ⇒ att(A,R,P,T) ∧ ⊕brg(A,R,P,T) ∧ ⊕P
FORBIDDEN((A,P)if C ) now(T) ∧ C ∧ att(A,R,P,T) ⇒ att(A,R,P,T) ⊕ vio(2)
OBLIGED((A,P)if C ) now(T) ∧ C ∧ ¬ brg(A,R,P,T) ⇒ ⊕vio(3)
now(T) ∧ C ∧ obl(A,R,P,T1) ∧ brg(A,R,P,T) ⇒ obl(A,R,P,T1)
Table 7. Translation of some “Bring about” norms into rules
where VC is the violation condition, S and R stands respectively for sanctions and
repairs, all of them extracted from the norm.
6.2 Z Specification of Norms
Although Luck et al. proposed a framework that covers several topics of a normative
multi-agent system, we shall focus on their definition of norm [18]. As figure 5 shows
a norm is composed of several fields: addressees stands for the set of agents that have
to comply with the norm; beneficiaries stands for the set of agents that profit from
the compliance of the norm; normativegoals stands for the set of goals that ought
to be achieved by addressee agents; rewards are received by addressee agents if they
satisfy the normative goals; punishments are imposed to addressee agent when they do
not satisfy the normative goals; context specifies the preconditions to apply the norm
and exceptions when it is not applicable. As we see in their definition, a norm always
must have addressees, normative goals and context. We can also see that rewards and
punishments are disjoint sets, as well as context and exceptions also are.
Norm
addresses, beneficiaries : PAgent
normativegoals, rewards, punishments : PGoal
context , exceptions : PEnvState
normativegoals 6= ∅; addresses 6= ∅; context 6= ∅
context ∩ exceptions = ∅; rewards ∩ punishments = ∅
Fig. 5. Z definition of a Luck’s norm
The contextualisation of the norms includes linking the addressee, beneficiaries and
normative goal to the correct corresponding utterance, as well as defining the predicates
used in the eInstitution to express the context and exceptions.
Using the language introduced in section 3 we can again show that norms specified
in this norm frame can be operationalised. After contextualisation the norms can be

Norm-Oriented Programming Language for Electronic Institutions 15
easily translated into the following normative rule to detect violations of the norm:
(context ∧ ∼ exception ∧ ¬ goal ′) ⇒ punishments
where context and exception are predicates obtained through the contextualisation for
specifying the context and exceptions mentioned in the norm, goal ′ is the contextu-
alised normative goal (thus including the addressee and possible beneficiaries), and
the ∼ operator for expressing negation-as-failure (since no exceptions might be given).
punishments are contextualised actions obtained from the norm. This rule means that
in a particular context that it is not an exception of the norm and the goal has not been
fulfilled the actions defined by punishments should be executed. If rewards are speci-
fied, the following normative rule can be also obtained:
(context ∧ ∼ exception ∧ goal ′) ⇒ rewards
where rewards are also contextualised actions obtained from the norm. This rule speci-
fies that a reward should be given when addressee agents comply with the norm, which
is when the norm is applicable and the contextualised normative goal (goal ′) has been
achieved.
6.3 Event Calculus
In [3], Artikis et al. propose the use of event calculus for the specification of protocols.
The event calculus is a formalism to represent reasoning about actions or events and
their effects in a logic programming framework. It is based on a many-sorted first-order
predicate calculus. Figure 6 shows the main predicates of the event calculus.
Predicate Meaning
happens(Act ,T ) Action Act occurs at time T
initially(F = V ) The value of fluent F is V at time 0
holdsAt(F = V ,T ) The value of fluent F is V at time T
initiates(Act ,F = V ,T ) The occurrence of action Act at time T
initiates a period of time for which
the value of fluent F is V
terminates(Act ,F = V ,T ) The occurrence of action Act at time T
terminates a period of time for which
the value of fluent F is V
Fig. 6. Main Predicates of the Event Calculus
Predicates that change with time are called fluents. As figure 7 shows, obligations,
permissions, empowerments, capabilities and sanctions are formalized by means of
the following fluents : obl(Ag ,Act), per(Ag ,Act), pow(Ag ,Act), can(Ag ,Act) and
sanction(Ag). Prohibitions are not formalized in the example of [3] as a fluent since
they assume that every not permitted action is forbidden by default.

16 A. Garcı´a-Camino et al.
Fluent Domain Meaning
requested(S ,T ) boolean subject S requested the floor at time T
status {free, granted(S ,T )} the status of the floor: status = free
denotes that the floor is free whereas
status = granted(S ,T ) denotes that the
floor is granted to subject S until time T
best candidate agent identifiers the best candidate for the floor
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
Fig. 7. Main Fluents of the Artikis’ example
Figure 8 shows an example of obligation specified in Event Calculus extracted from
[3]. The obligation that C revokes the floor holds at time T if C enacts the role of chair
and the floor is granted to someone else different from the best candidate.
holdsAt(obl(C , revoke floor(C )) = true,T )←
role of (C , chair), holdsAt(status = granted(S ,T ′),T ), (T ≥ T ′),
holdsAt(best candidate = S ′,T ), (S 6= S ′)
Fig. 8. Example of Obligation in Event Calculus
If we translate all the holdsAt predicates into uttered predicates, we can translate
the obligations and permissions of the example by including the rest of conditions in
the LHS of the normative rules. However, since there is no concrete definition of norm,
we can not state that Artikis’ approach is fully translatable into normative rules.
Although event calculus models time, the deontic fluents specified in the example of
[3] 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 fluent and the part of the theory that models the violation of the
deadline.
6.4 Hybrid Metric Interval Temporal Logic
Cranefield proposes in [6] the use of rules written in a modal logic with temporal opera-
tors called hyMITL±. It combines CTL± with Metric Interval Temporal Logic (MITL)
as well as features of hybrid logics. He use the technique of formula progression from
the planning system TLPlan to monitor social expectations until they are fulfilled or
violated.
Expression 10 shows an example of rule in hyMITL. This rule states that if the
current state is one in which c has just made payment for the service, and the current

Norm-Oriented Programming Language for Electronic Institutions 17
state is within the one week period from the time this offer is made (time t) then weekly
reports will be sent during the next 52 weeks until p optionally cancels the order.
AG+(Done(c,make payment(c, p, amount , prod num)) ∧ [t , t + 1week)→
↓week w .((¬ F−[−0,w ]Done(p, send report(c, prod num,w))→
F+[+0,w+1week]Done(p, send report(c, prod num,w)))
W+[+0,w+52weeks]
Done(c, cancel order(c, p, prod num)))
(10)
Rule 11 shows the translation of the previous hyMITL± rule into our rule language.
We calculate the number of weeks since the last utterance of payment and the time in
which this week ends. If the number of weeks is less than 52 and the report for that
week has not been done then the payed agent is obliged to send the report before the
end of the week.
0
B
B
B
@
A0 ∧ ¬ (A1 ∧ T1 > T0)∧
current date(Tn)∧
W = trunc((Tn − T0)/A)∧
W < 52 ∧ ¬ A2∧
Tend w = T0 + (W + 1) ∗ A
1
C
C
C
A


⊕A3∧
⊕(Ti < Tend w )

where (11)
A = (6048 ∗ 105)
A0 = utt(payment,W0, inform(C , customer ,P, payee,
pay(Amount,Prod num),T0))
A1 = utt(report,W1, inform(C , customer ,P, payee,
cancel(Prod num),T1))
A2 = utt(report,W2, inform(P, payee,C , customer ,
send report(R,W ),T2))
A3 = obl(report,W2, inform(P, payee,C , customer ,
send report(R,W ),T3))
Our rules are equivalent toAG+(LHS → X+RHS )where LHS and RHS are atomic
formulae without any temporal operator. As we build the next state of affairs by apply-
ing the operations in the RHS of the fired rules, we can not use any other temporal
operator in the RHS of our rules. Furthermore, since our state of affairs is non mono-
tonic we can not reason over the past of any formulae. We can only do it in predicates
with time-stamps, like the utt predicate, that are not removed from the state of affairs.
We can capture the meaning of the X− operator when it is used in the LHS of the
hyMITL rule:
X−φ ' ctr(S ,W ,T ,Ts) ∧ φ(T0) ∧ T0 = T − 1
We can also translate the U+ operator when it is used in the RHS of the hyMITL rule:
φ U+ψ ' ψ φ
Although we can not use all the temporal operators in the RHS of our rules, we can
get equivalent results by imposing certain restrictions in the set of rules. F+φ can be
achieved if ⊕φ appears in the RHS of a rule and it is possible that the rule fires. G+φ
can be achieved after φ is added and no rule that could fire removes it. Time intervals
can be translated into comparisons of time-points as shown in the previous example.

18 A. Garcı´a-Camino et al.
6.5 Social Integrity Constraints
A language called Social Integrity Constraints (SIC) is proposed in [1] and checks
whether some events have occurred and some conditions hold and adds new expec-
tations, optionally with constraints.
H(request(B,A,P,D,Tr )) ∧ H(accept(B,A,P,D,Ta)) ∧ Tr < Ta
→ E(do(A,B,P,D,Td )) : Td < Ta + τ
The expression above shows an example of SIC that intuitively means: if agent B
sent a request P to agent A at time Tr , in the context of dialogue D , and A sent an
accept to B ’s request at a later time Ta , then A is expected to do P before a deadline
Ta + τ .
The translation of their SICs is very straightforward, because events (H) can be
translated into our att predicates. Since we also allow predicates to be restricted by
constraints, expectations can be translated directly into obligations.
Although syntactically their language is very similar to ours, they are semantically
different. Contrarily to them, that use abduction and CHR to execute their rules, we use
a forward chaining approach.
Despite the fact that expectations they use are quite similar to obligations, their
approach also lack of the rest of deontic notions we manage (permissions and prohibi-
tions). Furthermore, although they mention how expectations are treated, that is, what
happens when a expectation is fulfilled or when it is not, and state the possibility of
SICs being violated, they do not offer mechanisms to regulate agent’s behaviour like
the punishment of offender agents or repairing actions that the system can do.
6.6 Object Constraint Language
In [9], it is proposed the use of Object Constraint Language (OCL) for the specification
of artificial institutions.
The expression below shows an example of norm written in OCL. This norm com-
mits the auctioneer not to declare a price lower than the agreed reservation price.
As we saw in section 5 we can express with a easier syntax (rule 7) the case that
auctioneer is obliged to withdraw the good when the Dutch auction arrives to a price
lower than the reservation price. As for [9], we can not perform an exhaustive analysis
of the language because they do not offer nor the syntax specification nor the semantics
specification.
within h : AuctionHouse
on e : InstitutionalRelationChange(h.dutchAuction,
auctioneer , created)
if true then
foreach agent inh.employee →
select(em | e.involved → contains(em))
do makePendingComm(agent,
DutchInstAgent(notSetCurPrice(
h.dutchAuction.id,
?p[?p < h.agreement.reservationPrice]),
< now ,now + time of (e1 : InstStateChange(
h.dutchAuction,OpenDA,ClosedDA)) >, ∀))

Norm-Oriented Programming Language for Electronic Institutions 19
As far as we know, they found their theory on the notion of commitment which is
quite similar to obligations. In this sense, they do not have the notions of permissions
and prohibitions as we do.
6.7 Standard Production Systems
Garcı´a-Camino [10] proposes the translation of the normative language presented in
[24] into Jess rules [13] to monitor and enforce norms. This language captures the de-
ontic notions of permission, prohibition and obligation in several cases: absolute norms,
conditional norms, norms with deadline and norms in temporal relation with another
event. Absolute norms are directly translated into JESS facts; conditional norms are di-
rectly translated into rules that add the deontic facts when the condition holds; norms
with deadline are translated into rules that add conditional norms after the deadline has
passed. Finally, norms in temporal relation with other events are translated into rules
that check if those events have occurred.
Our proposal also bears strong similarities with the work of Lopes Cardoso and
Oliveira [16, 15] where norms are also represented as rules of a production system.
We notice that our institutional rules can express their notions of contracts and their
monitoring (i.e., fulfillment and violation of obligations). However, in [16] constraints
can only be used to depict the right-hand side of a rule, that is, the situation(s) when a
rule is applicable – constraints are not manipulated the way we do. Furthermore, in that
work there is no indication as to how individual agents will know about their normative
situation; a diagram introduces the architecture, but it is not clear who/what will apply
the rules to update the normative aspects of the system nor how agents synchronise their
activities. It is not clear how their approach can be used to engineer open, heterogeneous
MASs.
The advantages of using our language, instead of production systems, to specify
and monitor the normative position of the agents conforming a MAS are that we can
use constraint solving techniques to handle with predicates restricted with constraints
and that we borrow unification from Prolog that permits higher level pattern matching.
The latter advantage is very useful when specifying complex data structures as, i.e., il-
locutions. As they can have atomic formulae as the content of the message, they become
a second order formula and you need to make programming tricks to express them as
a production system fact. In this sense, the programming of higher order formulae as
facts gets inviable.
7 Discussion, Conclusions and Future Work
In the beginning of this article we proposed some features that a normative language
should embody. In section 3 we proposed a language to model theory change, which
we used in sections 4 and 5 to express the normative positions of a set of agents. The
case study of section 5 set out the pragmatics of the language and how it incorporates
the features detailed in section 2.
In section 6 we compared our language with other contemporary approaches and
we found that a wide range of constructs and notions in those languages can be trans-
lated into our rule language by using predicates and constraints. After analysing those

20 A. Garcı´a-Camino et al.
languages, we found many features in common. Some are used to capture the deon-
tic notions of permission, prohibition and obligation in predicates or norm constructs.
In some cases these deontic notions can be conditional or can be related in time with
other events (deadlines or actions). At least, two of the languages capture the notion
of sanction as well as the specification of the actions to perform when a violation of a
norm occurs. Similarly, rewards specify the actions to perform when a norm has been
fulfilled.
Our future work includes the generalisation of the language to cope with actions.
We also need to explore the possibility of storing all the past events to reason over the
past and the possibility of adding time operators to reduce the amount of code in the
LHS of a rule.
References
1. Marco Alberti, Marco Gavanelli, Evelina Lamma, Paola Mello, and Paolo Torroni. Speci-
fication and Verification of Agent Interactions using Integrity Social Constraints. Technical
Report DEIS-LIA-006-03, Universita` degli Studi di Bologna, October 2003.
2. K. R. Apt. From Logic Programming to Prolog. Prentice-Hall, U.K., 1997.
3. A. Artikis, L. Kamara, J. Pitt, and M. Sergot. A Protocol for Resource Sharing in Norm-
Governed Ad Hoc Networks. volume 3476 of LNCS. Springer-Verlag.
4. Robert Axelrod. The complexity of cooperation: agent-based models of competition and
collaboration. Princeton studies in complexity. Princeton University, New Jersey, 1997.
5. G. Boella and L. van der Torre. Permission and Obligations in Hierarchical Normative Sys-
tems. In Procs. 8th Int’l Conf. in AI & Law (ICAIL’03), Edinburgh, 2003. ACM.
6. S. Cranefield. A Rule Language for Modelling and Monitoring Social Expectations in Multi-
Agent Systems. Technical Report 2005/01, University of Otago, February 2005.
7. Frank Dignum. Autonomous Agents with Norms. Artificial Intelligence and Law, 7(1):69–
79, 1999.
8. M. Esteva. Electronic Institutions: from Specification to Development. PhD thesis, Univer-
sitat Polite`cnica de Catalunya (UPC), 2003. IIIA monography Vol. 19.
9. Nicoletta Fornara, Francesco Vigano`, and Marco Colombetti. An Event Driven Approach to
Norms in Artificial Institutions. In AAMAS05 Workshop: Agents, Norms and Institutions for
Regulated Multiagent Systems (ANI@REM), Utrecht, 2005.
10. A. Garcı´a-Camino, P. Noriega, and J. A. Rodrı´guez-Aguilar. Implementing Norms in Elec-
tronic Institutions. In 4th Int’l Joint Conf on Autonomous Agents and Multiagent Systems
(AAMAS), 2005. Forthcoming.
11. A. Garcı´a-Camino, J. A. Rodrı´guez-Aguilar, C. Sierra, and W. Vasconcelos. A Distributed
Architecture for Norm-Aware Agent Societies. AUCS/TR0503, Dept of Computing Sc.,
Univ. of Aberdeen, Aberdeen, UK, 2005.
12. N.R. Jennings, K. Sycara, and M. Wooldridge. A roadmap of agent research and develop-
ment. Journal of Agents and Multi-Agents Systems, 1:7–38, 1998.
13. Jess. The Rule Engine for Java. Sandia Nat’l Labs.
http://herzberg.ca.sandia.gov/jess, October 2005.
14. Bryan Kramer and John Mylopoulos. Knowledge Representation. In S. C. Shapiro, editor,
Encyclopedia of Artificial Intelligence, volume 1. John Wiley & Sons, 1992.
15. Henrique Lopes Cardoso and Euge´nio Oliveira. Towards an Institutional Environment using
Norms for Contract Performance. volume In press of LNAI. Springer-Verlag, 2005.
16. Henrique Lopes Cardoso and Euge´nio Oliveira. Virtual Enterprise Normative Framework
within Electronic Institutions. volume In press of LNAI. Springer-Verlag, 2005.

Norm-Oriented Programming Language for Electronic Institutions 21
17. F. Lo´pez y Lo´pez. Social Power and Norms: Impact on agent behaviour. PhD thesis, Uni-
versity of Southampton, June 2003.
18. F. Lo´pez y Lo´pez and Michael Luck. A Model of Normative Multi-Agent Systems and
Dynamic Relationships. volume 2934 of LNAI. Springer-Verlag, 2004.
19. P. Noriega. Agent-Mediated Auctions: The Fishmarket Metaphor. PhD thesis, Universitat
Auto`noma de Barcelona (UAB), 1997. IIIA monography Vol. 8.
20. S. J. Russell and P. Norvig. Artificial Intelligence: A Modern Approach. Prentice Hall, Inc.,
U.S.A., 2 edition, 2003.
21. M. Sergot. A Computational Theory of Normative Positions. ACM Trans. Comput. Logic,
2(4):581–622, 2001.
22. Y. Shoham and M. Tennenholtz. On Social Laws for Artificial Agent Societies: Off-line
Design. Artificial Intelligence, 73(1-2):231–252, 1995.
23. R. Tuomela and M. Bonnevier-Tuomela. Norms and Agreement. European Journal of Law,
Philosophy and Computer Science, 5:41–46, 1995.
24. Javier Va´zquez-Salceda, Huib Aldewereld, and Frank Dignum. Implementing Norms in
Multiagent Systems. volume 3187 of LNAI. Springer-Verlag.
25. Javier Va´zquez-Salceda, Huib Aldewereld, and Frank Dignum. Norms in Multiagent Sys-
tems: Some Implementation Guidelines. In 2nd EuropeanWorkshop onMulti-Agent Systems,
Barcelona, 2004.
26. M. Verdicchio and M. Colombetti. A logical model of social commitment for agent commu-
nication. In Procs. AAMAS 2003. ACM Press, 2003.
27. MichaelWooldridge. An Introduction to Multiagent Systems. JohnWiley & Sons, Chichester,
UK, February 2002.