Ignoring, Forcing and Expecting Concurrent Events in Electronic Institutions
Available from www.garcia-camino.es
Page 1
Ignoring, Forcing and Expecting Concurrent Events in Electronic Institutions
Ignoring, Forcing and Expecting Concurrent
Events in Electronic Institutions
Andres Garca-Camino
IIIA, Arti cial Intelligence Research Institute
CSIC, Spanish National Research Council
Campus UAB, 08193 Bellaterra, Spain
andres@iiia.csic.es
Abstract. Norms constitute a powerful coordination mechanism among
heterogeneous agents. We propose means to specify open environments
regulated using the notions of ignoring, forcing, expecting and sanction-
ing events and prevention of unwanted states. These notions make ex-
plicit and clear the stance of institutions about forbidden and obligatory
behaviour. Our rule-based language calculates the e ects of concurrent
events generated by agents given a set of norms based on the deontic no-
tions previously mentioned. Our formalism has been conceived as basis
for an implementation of Electronic Institutions.
1 Introduction
Ideally, open multi-agent systems (MAS) involve heterogeneous and autonomous
agents whose concurrent interactions ought to conform to some shared conven-
tions. The challenge is how to express and enforce such conditions so that truly
autonomous agents can adscribe to them. One way of addressing this issue is to
look at MAS as environments regulated by some sort of normative framework.
There are many examples of languages for regulating agent behaviour (for
example, [1{5]). However, very few of them regulate concurrent events taking
into account the rest of events that occur at an instant of time. The few that
exist (e.g. [3]) are not conceived to deal with open MAS.
Furthermore, in the literature we nd that almost all these languages are
based on deontic logic [6] that establishes which actions are permitted, forbidden
or obligatory. However, it does not establish which is the semantics of these
modalities with respect to a computational system. For instance, when an action
is claimed to be forbidden, does it means that it is prevented to happen, or that
the agents that bring it about must be sanctioned or that the e ects of that
action are just ignored?
Instead, we propose a language, called I, and one implementation of it that
uses the notions of ignoring, forcing, and expecting events along with the no-
tion of preventing a state, in the computation of the e ects of concurrent agent
behaviour in a regulated open MAS. The main contributions of I is the man-
agement of sets of events that occur simultaneously and the distinction between
Events in Electronic Institutions
Andres Garca-Camino
IIIA, Arti cial Intelligence Research Institute
CSIC, Spanish National Research Council
Campus UAB, 08193 Bellaterra, Spain
andres@iiia.csic.es
Abstract. Norms constitute a powerful coordination mechanism among
heterogeneous agents. We propose means to specify open environments
regulated using the notions of ignoring, forcing, expecting and sanction-
ing events and prevention of unwanted states. These notions make ex-
plicit and clear the stance of institutions about forbidden and obligatory
behaviour. Our rule-based language calculates the e ects of concurrent
events generated by agents given a set of norms based on the deontic no-
tions previously mentioned. Our formalism has been conceived as basis
for an implementation of Electronic Institutions.
1 Introduction
Ideally, open multi-agent systems (MAS) involve heterogeneous and autonomous
agents whose concurrent interactions ought to conform to some shared conven-
tions. The challenge is how to express and enforce such conditions so that truly
autonomous agents can adscribe to them. One way of addressing this issue is to
look at MAS as environments regulated by some sort of normative framework.
There are many examples of languages for regulating agent behaviour (for
example, [1{5]). However, very few of them regulate concurrent events taking
into account the rest of events that occur at an instant of time. The few that
exist (e.g. [3]) are not conceived to deal with open MAS.
Furthermore, in the literature we nd that almost all these languages are
based on deontic logic [6] that establishes which actions are permitted, forbidden
or obligatory. However, it does not establish which is the semantics of these
modalities with respect to a computational system. For instance, when an action
is claimed to be forbidden, does it means that it is prevented to happen, or that
the agents that bring it about must be sanctioned or that the e ects of that
action are just ignored?
Instead, we propose a language, called I, and one implementation of it that
uses the notions of ignoring, forcing, and expecting events along with the no-
tion of preventing a state, in the computation of the e ects of concurrent agent
behaviour in a regulated open MAS. The main contributions of I is the man-
agement of sets of events that occur simultaneously and the distinction between
Page 2
norms that can be violated or not. For instance, an obligation that may be vio-
lated to perform a set of simultaneous events is represented as the expectation of
the attempts to perform them. However, the enforcement of an obligation that
may not be violated to perform a set of events is carried out by the system by
taking these events as performed even they are not. We denote such enforcement
as forcing events.
The paper is structured as follows. Section 2 introduces I, a rule language
for electronic institutions. A basic example illustrating the expressiveness of I is
shown in section 3. In section 4, we introduce the formulae that we use for mod-
elling electronic institutions. An example of a bank institution is presented in
section 5. In section 6 we contrast our approach with a sample of other contem-
porary work. Finally, we draw conclusions and outline future work in section 7.
2 I: A Rule Language for Electronic Institutions
In this section we introduce a rule language for the regulation and management of
concurrent events generated by a population of agents. Our rule-based language
allows us to represent norms and changes in an elegant way.
The building blocks of our language are rst-order terms and implicitly, uni-
versally quanti ed atomic formulae without free variables. We shall make use
of numbers and arithmetic functions to build terms; arithmetic functions may
appear in x, following their usual conventions1. We also employ arithmetic re-
lations (e.g., =, 6=, and so on) as predicate symbols, and these will appear in
their usual in x notation with their usual meaning.
ECA-Rule ::= on events if conditions do actions
if -Rule ::= if conditions do actions
ignore-Rule ::= ignore events if conditions
prevent-Rule ::= prevent conditions if conditions
force-Rule ::= force events on events if conditions do actions
events ::= list of events j ;
list of events ::= atomic formula; list of events j atomic formula
conditions ::= conditions ^ conditions j :(conditions) j atomic formula
actions ::= action actions j action
action ::= atomic formula j atomic formula
Fig. 1. Grammar for I
One goal of the I language is to specify which are the e ects of concurrent
events and this is achieved with Event-Condition-Action (ECA) rules. Intuitively,
an ECA-rule means that whenever the events occur and the conditions hold then
the actions are applied. These actions consist in the addition and removal of
atomic formulae from the state of a airs. ECA-rules are checked in parallel and
they are executed only once without chaining.
1 We adopt Prolog's convention using strings starting with a capital letter to represent variables
and strings starting with a small letter to represent constants.
lated to perform a set of simultaneous events is represented as the expectation of
the attempts to perform them. However, the enforcement of an obligation that
may not be violated to perform a set of events is carried out by the system by
taking these events as performed even they are not. We denote such enforcement
as forcing events.
The paper is structured as follows. Section 2 introduces I, a rule language
for electronic institutions. A basic example illustrating the expressiveness of I is
shown in section 3. In section 4, we introduce the formulae that we use for mod-
elling electronic institutions. An example of a bank institution is presented in
section 5. In section 6 we contrast our approach with a sample of other contem-
porary work. Finally, we draw conclusions and outline future work in section 7.
2 I: A Rule Language for Electronic Institutions
In this section we introduce a rule language for the regulation and management of
concurrent events generated by a population of agents. Our rule-based language
allows us to represent norms and changes in an elegant way.
The building blocks of our language are rst-order terms and implicitly, uni-
versally quanti ed atomic formulae without free variables. We shall make use
of numbers and arithmetic functions to build terms; arithmetic functions may
appear in x, following their usual conventions1. We also employ arithmetic re-
lations (e.g., =, 6=, and so on) as predicate symbols, and these will appear in
their usual in x notation with their usual meaning.
ECA-Rule ::= on events if conditions do actions
if -Rule ::= if conditions do actions
ignore-Rule ::= ignore events if conditions
prevent-Rule ::= prevent conditions if conditions
force-Rule ::= force events on events if conditions do actions
events ::= list of events j ;
list of events ::= atomic formula; list of events j atomic formula
conditions ::= conditions ^ conditions j :(conditions) j atomic formula
actions ::= action actions j action
action ::= atomic formula j atomic formula
Fig. 1. Grammar for I
One goal of the I language is to specify which are the e ects of concurrent
events and this is achieved with Event-Condition-Action (ECA) rules. Intuitively,
an ECA-rule means that whenever the events occur and the conditions hold then
the actions are applied. These actions consist in the addition and removal of
atomic formulae from the state of a airs. ECA-rules are checked in parallel and
they are executed only once without chaining.
1 We adopt Prolog's convention using strings starting with a capital letter to represent variables
and strings starting with a small letter to represent constants.
Page 3
If-rules are similar to rules in standard production systems, if the conditions
hold then the actions are applied. They are implemented with a forward chaining
mechanism: they are executed sequentially until no new formula is added or
removed.
Ignore-rules are used for ignoring events when the conditions hold in order to
avoid unwanted behaviour. Similarly, prevent-rules are used for preventing some
conditions to hold in the situations given. In order to prevent unwanted states,
events causing such unwanted states are ignored. Force-rules generate events and
execute actions as consequence of other events and conditions.
Sanctions over unwanted events can be carried out with ECA-rules. For in-
stance, we can decrease the credit of one agent by 10 if she generates certain
event.
We add an additional kind of rules, 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 events if conditions
ful lled-if conditions 0 violated-if conditions 00
sanction-do actions
Each expectation rule can be translated into three ECA-rules:
on events if conditions do exp(event) (1)
if exp(event) ^ conditions 0 do exp(event) (2)
if exp(event) ^ conditions 00 do exp(event) actions (3)
Rules 1 and 2 respectively adds and removes an expectation whenever the
events have occurred and the conditions hold. Rule 3 cancels the unful lled
expectation and sanctions an agent for the unful lled expectation by executing
the given actions whenever some conditions hold.
2.1 Semantics
Instead of basing the I language in 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 e ects (includ-
ing sanctions) in the institution after performing certain (possibly concurrent)
events. ECA-rules might 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 state
has to be prevented or not. By default, states are not prevented. Obligations
are di erentiated 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 really performed by the agents.
hold then the actions are applied. They are implemented with a forward chaining
mechanism: they are executed sequentially until no new formula is added or
removed.
Ignore-rules are used for ignoring events when the conditions hold in order to
avoid unwanted behaviour. Similarly, prevent-rules are used for preventing some
conditions to hold in the situations given. In order to prevent unwanted states,
events causing such unwanted states are ignored. Force-rules generate events and
execute actions as consequence of other events and conditions.
Sanctions over unwanted events can be carried out with ECA-rules. For in-
stance, we can decrease the credit of one agent by 10 if she generates certain
event.
We add an additional kind of rules, 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 events if conditions
ful lled-if conditions 0 violated-if conditions 00
sanction-do actions
Each expectation rule can be translated into three ECA-rules:
on events if conditions do exp(event) (1)
if exp(event) ^ conditions 0 do exp(event) (2)
if exp(event) ^ conditions 00 do exp(event) actions (3)
Rules 1 and 2 respectively adds and removes an expectation whenever the
events have occurred and the conditions hold. Rule 3 cancels the unful lled
expectation and sanctions an agent for the unful lled expectation by executing
the given actions whenever some conditions hold.
2.1 Semantics
Instead of basing the I language in 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 e ects (includ-
ing sanctions) in the institution after performing certain (possibly concurrent)
events. ECA-rules might 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 state
has to be prevented or not. By default, states are not prevented. Obligations
are di erentiated 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 really performed by the agents.
Page 4
Each set of ECA-rules generates a labelled transition system hS ;E ;Ri where
each state S is a set of atomic formulae, E is a set of events, and R is a S2ES
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 to execute any transition that contains in its labelling all
the events that appear in each ignore-rule. For instance, having a rule ignore 1
if true would avoid to execute the transitions labelled as f 1g, f 1; 2g and
f 1; 2; 3g. However, having a rule ignore 1; 2 if true would avoid to exe-
cute f 1; 2g and f 1; 2; 3g but not f 1g.
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 4, 5 and 6. After the occurrence of events 1 and 2 and
since q1 is an e ect of event 2, all the actions in ECA-rule 5 would be ignored
obtaining a new state where p and r hold but neither q1 nor q2.
on 1 if true do p (4)
on 2 if true do q1 q2 (5)
on 1; 2 if true do r (6)
Force-rules generate events during the execution of the transition system.
However, the e ects of such events are still speci ed by ECA-rules and subject
to prevent and ignore-rules.
2.2 Operational Semantics
In the de nitions below we rely on the concept of substitution, that is, the set of
values for variables in a computation [7, 8]:
We now de ne the semantics of the conditions, that is, when a condition
holds:
De nition 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(;: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(; true; ) always holds.
5. sl(; ; ) holds i 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 the negation by failure. Case 3 compares if two lists have the same el-
ements possibly in di erent order. Case 4 gives semantics to the keyword \true".
Case 5 holds when an atomic formulae is part of the state of a airs.
We now de ne the semantics of the actions of a rules:
each state S is a set of atomic formulae, E is a set of events, and R is a S2ES
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 to execute any transition that contains in its labelling all
the events that appear in each ignore-rule. For instance, having a rule ignore 1
if true would avoid to execute the transitions labelled as f 1g, f 1; 2g and
f 1; 2; 3g. However, having a rule ignore 1; 2 if true would avoid to exe-
cute f 1; 2g and f 1; 2; 3g but not f 1g.
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 4, 5 and 6. After the occurrence of events 1 and 2 and
since q1 is an e ect of event 2, all the actions in ECA-rule 5 would be ignored
obtaining a new state where p and r hold but neither q1 nor q2.
on 1 if true do p (4)
on 2 if true do q1 q2 (5)
on 1; 2 if true do r (6)
Force-rules generate events during the execution of the transition system.
However, the e ects of such events are still speci ed by ECA-rules and subject
to prevent and ignore-rules.
2.2 Operational Semantics
In the de nitions below we rely on the concept of substitution, that is, the set of
values for variables in a computation [7, 8]:
We now de ne the semantics of the conditions, that is, when a condition
holds:
De nition 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(;: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(; true; ) always holds.
5. sl(; ; ) holds i 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 the negation by failure. Case 3 compares if two lists have the same el-
ements possibly in di erent order. Case 4 gives semantics to the keyword \true".
Case 5 holds when an atomic formulae is part of the state of a airs.
We now de ne the semantics of the actions of a rules:
Page 5
De nition 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 (; ;0) holds i
(a) 62 and 0 = [ f g or;
(b) 0 = .
3. sr (; ;0) holds i
(a) 2 and 0 = n f g 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., not all the conditions hold in the state of a airs . It
checks whether contain all the conditions of each prevent-rule or not.
De nition 3. Relation checkprv (;PrvRules) mapping a state and a se-
quence PrvRules of prevent-rules holds i an empty set is the largest set of con-
ditions C such that prevent-rule p = prevent C if C 0, p 2 PrvRules, sl(;C )
and sl(;C 0) hold.
De nition 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
assert( red(C )), 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.
De nition 5. Relation can re(; if C do A; ) mapping a state an if-rule
and a substitution holds i sl(;C ; ) holds and red(C ) does not hold.
Relation resolve determines the rule that will be red by selecting the rst
rule in the list.
De nition 6. Relation resolve(RuleList ;SelectedRule) mapping a list of if-rules
and a selected if-rule holds i
1. RuleList = ; and SelectedRule = ;; or
2. RuleList = hr1; ; rni and SelectedRule = r1.
Relation select rule determines the rule that will be red by selecting all the
rules that can re and resolving the con
ict with relation resolve.
De nition 7. Relation select rule(; IfRulesList ;SelectedRule) mapping a state
of a airs a list of if-rules and a selected if-rule holds i Rs is the largest set
of rules R 2 IfRulesList such that can re(;R; ); resolve(Rs;SR) hold and
SelectedRule = SR .
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 (; ;0) holds i
(a) 62 and 0 = [ f g or;
(b) 0 = .
3. sr (; ;0) holds i
(a) 2 and 0 = n f g 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., not all the conditions hold in the state of a airs . It
checks whether contain all the conditions of each prevent-rule or not.
De nition 3. Relation checkprv (;PrvRules) mapping a state and a se-
quence PrvRules of prevent-rules holds i an empty set is the largest set of con-
ditions C such that prevent-rule p = prevent C if C 0, p 2 PrvRules, sl(;C )
and sl(;C 0) hold.
De nition 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
assert( red(C )), 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.
De nition 5. Relation can re(; if C do A; ) mapping a state an if-rule
and a substitution holds i sl(;C ; ) holds and red(C ) does not hold.
Relation resolve determines the rule that will be red by selecting the rst
rule in the list.
De nition 6. Relation resolve(RuleList ;SelectedRule) mapping a list of if-rules
and a selected if-rule holds i
1. RuleList = ; and SelectedRule = ;; or
2. RuleList = hr1; ; rni and SelectedRule = r1.
Relation select rule determines the rule that will be red by selecting all the
rules that can re and resolving the con
ict with relation resolve.
De nition 7. Relation select rule(; IfRulesList ;SelectedRule) mapping a state
of a airs a list of if-rules and a selected if-rule holds i Rs is the largest set
of rules R 2 IfRulesList such that can re(;R; ); resolve(Rs;SR) hold and
SelectedRule = SR .
Page 6
Relation sif determines the new state of a airs after applying a set of if-rules
to a initial state of a airs taking into account a set of prevent-rules.
De nition 8. Relation sif (; IfRules;PrvRules; 0) mapping a state of a airs
, a list of if-rules, a list of prevent-rules and a new state of a airs holds i
1. select rule(; IfRules;R) hold, R 6= ;, re(;PrvRules;R; 00) and sif (00;
IfRules;PrvRules; 0) hold; or
2. select rule(; IfRules;R) hold, R = ;; or
3. sif (; IfRules;PrvRules; 0) hold.
Relation ignored determines a set of events that occurred have to be ignored
taking into account a list of ignore-rules.
De nition 9. Relation ignored(;;E ; IgnRules) mapping a state of a airs
, a list of events that occurred, a list of events in a ECA-rule and a list of
ignore-rules holds i i = ignore E 0 if C , i 2 IgnRules, E 0 , E intersects
with E 0 and sl(;C ) holds.
Relation s0r applies sr rst and then sif in order to activate the forward
chaining.
De nition 10. Relation s0r (; IfRules;PrvRules;ActionList ;
0) mapping a state
of a airs , a list of if-rules, a list of prevent-rules, a list of actions and a new
state of a airs holds i
1. ActionList = ; and 0 = ; or
2. ActionList = ha1; ; ani, sr (; a1; 00), checkprv (00;PrvRules), sif (00;
IfRules;PrvRules; 000) and s0r (
000; IfRules;PrvRules; ha2; ; ani; 0) hold;
or
3. s0r (; IfRules;PrvRules; ha2; ; ani;
0).
Relation son calculates the new state of a airs 0 from an initial state and
a set of events that occurred applying a list of ECA-rules, if-rules, ignore-rules
and prevent-rules.
De nition 11. Relation son(;;ECARules; IfRules; IgnRules;PrvRules; 0)
mapping a state of a airs , 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, and a
new state of a airs holds i As is the largest set of actions A0 = A in
a ECA-rule r = on E if C do A such that R 2 ECARules, E 0 ,
sl(;C ; 00) hold, ignored(;;E ; IgnRules) does not hold and = 0 [ 00;
and s0r (; IfRules;PrvRules;As;
0) hold.
Relation sf calculates the new state of a airs 0 and the new set 0 of
occurred events from an initial state and a set of events that occurred
applying a list of if-rules, ignore-rules, prevent-rules and force-rules.
to a initial state of a airs taking into account a set of prevent-rules.
De nition 8. Relation sif (; IfRules;PrvRules; 0) mapping a state of a airs
, a list of if-rules, a list of prevent-rules and a new state of a airs holds i
1. select rule(; IfRules;R) hold, R 6= ;, re(;PrvRules;R; 00) and sif (00;
IfRules;PrvRules; 0) hold; or
2. select rule(; IfRules;R) hold, R = ;; or
3. sif (; IfRules;PrvRules; 0) hold.
Relation ignored determines a set of events that occurred have to be ignored
taking into account a list of ignore-rules.
De nition 9. Relation ignored(;;E ; IgnRules) mapping a state of a airs
, a list of events that occurred, a list of events in a ECA-rule and a list of
ignore-rules holds i i = ignore E 0 if C , i 2 IgnRules, E 0 , E intersects
with E 0 and sl(;C ) holds.
Relation s0r applies sr rst and then sif in order to activate the forward
chaining.
De nition 10. Relation s0r (; IfRules;PrvRules;ActionList ;
0) mapping a state
of a airs , a list of if-rules, a list of prevent-rules, a list of actions and a new
state of a airs holds i
1. ActionList = ; and 0 = ; or
2. ActionList = ha1; ; ani, sr (; a1; 00), checkprv (00;PrvRules), sif (00;
IfRules;PrvRules; 000) and s0r (
000; IfRules;PrvRules; ha2; ; ani; 0) hold;
or
3. s0r (; IfRules;PrvRules; ha2; ; ani;
0).
Relation son calculates the new state of a airs 0 from an initial state and
a set of events that occurred applying a list of ECA-rules, if-rules, ignore-rules
and prevent-rules.
De nition 11. Relation son(;;ECARules; IfRules; IgnRules;PrvRules; 0)
mapping a state of a airs , 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, and a
new state of a airs holds i As is the largest set of actions A0 = A in
a ECA-rule r = on E if C do A such that R 2 ECARules, E 0 ,
sl(;C ; 00) hold, ignored(;;E ; IgnRules) does not hold and = 0 [ 00;
and s0r (; IfRules;PrvRules;As;
0) hold.
Relation sf calculates the new state of a airs 0 and the new set 0 of
occurred events from an initial state and a set of events that occurred
applying a list of if-rules, ignore-rules, prevent-rules and force-rules.
Page 7
De nition 12. Relation sf (;; IfRules; IgnRules;PrvRules;FrcRules; 0; 0)
mapping a state of a airs , a list of events that occurred, a list of if-rules,
a list of ignore-rules, a list of prevent-rules, a list of force-rules, a new list
of events that occured and a new state of a airs holds i EAs is the largest
set of tuples hFE ;A i of forced events and actions in a force rule fr =
force FE on E if C do A such that fr 2 FrcRules, E 0 , sl(;C ; 00)
holds,ignored(;;E ; IgnRules) does not hold and = 0[00; Es is the largest
set of forced events Ev such that hEv ;Ai 2 EAs; 0 = [Es; As is the largest
set of actions A such that hEv ;Ai 2 EAs; and s0r (; IfRules;PrvRules;As;
0)
holds.
Relation s calculates the new state of a airs 0 from an initial state and a
set of events that occurred applying a list of ECA-rules, if-rules, ignore-rules,
prevent-rules and force-rules.
De nition 13. Relation s(;;ECARules; IfRules; IgnRules;PrvRules;FrcRules;
0) mapping a state of a airs , 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 a airs holds i Cs is the largest set of conditions C such
that retract( red(C )) holds; assert( red(false)), sif (; IfRules;PrvRules; 00),
sf (00; ; IfRules; IgnRules;PrvRules;FrcRules; 0; 000) and son(000; 0;ECARules;
IfRules; IgnRules;PrvRules; 0) hold.
3 Example of Concurrency: Soup Bowl Lifting
In this section we present an example on how to use the I language in order
to specify a variation of a problem about concurrent action: the Soup Bowl
Lifting problem [9]. Picture a situation where a soup bowl has to be lifted by
two (physical) agents; one lifting from the right-hand side and the other one
from the left-hand side. If both sides are not lifted simultaneously then the soup
spills.
The order in which the rules are declared is important since they are executed
in the order they are declared. We do not obtain the same e ect with rules 7, 8
and 9 ( nally spilled does not hold after lifted from both sides simultaneously)
than with rules 9, 7 and 8 ( nally spilled holds even after lifted from both sides
simultaneously).
on pushLeft if true do spilled (7)
on pushRight if true do spilled (8)
on pushLeft ; pushRight if true do spilled onTable (9)
Rules 7 and 8 specify that the soup is spilled whenever the bowl is lifted
either from the right-hand side or the left-hand side. However, rule 9 removes
the spill e ect whenever both events are done simultaneously. However, with
rules 9, 7 and 8, we do not obtain the desired result since the spilled formula
may be added after executing the rule that removes spilled formula.
mapping a state of a airs , a list of events that occurred, a list of if-rules,
a list of ignore-rules, a list of prevent-rules, a list of force-rules, a new list
of events that occured and a new state of a airs holds i EAs is the largest
set of tuples hFE ;A i of forced events and actions in a force rule fr =
force FE on E if C do A such that fr 2 FrcRules, E 0 , sl(;C ; 00)
holds,ignored(;;E ; IgnRules) does not hold and = 0[00; Es is the largest
set of forced events Ev such that hEv ;Ai 2 EAs; 0 = [Es; As is the largest
set of actions A such that hEv ;Ai 2 EAs; and s0r (; IfRules;PrvRules;As;
0)
holds.
Relation s calculates the new state of a airs 0 from an initial state and a
set of events that occurred applying a list of ECA-rules, if-rules, ignore-rules,
prevent-rules and force-rules.
De nition 13. Relation s(;;ECARules; IfRules; IgnRules;PrvRules;FrcRules;
0) mapping a state of a airs , 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 a airs holds i Cs is the largest set of conditions C such
that retract( red(C )) holds; assert( red(false)), sif (; IfRules;PrvRules; 00),
sf (00; ; IfRules; IgnRules;PrvRules;FrcRules; 0; 000) and son(000; 0;ECARules;
IfRules; IgnRules;PrvRules; 0) hold.
3 Example of Concurrency: Soup Bowl Lifting
In this section we present an example on how to use the I language in order
to specify a variation of a problem about concurrent action: the Soup Bowl
Lifting problem [9]. Picture a situation where a soup bowl has to be lifted by
two (physical) agents; one lifting from the right-hand side and the other one
from the left-hand side. If both sides are not lifted simultaneously then the soup
spills.
The order in which the rules are declared is important since they are executed
in the order they are declared. We do not obtain the same e ect with rules 7, 8
and 9 ( nally spilled does not hold after lifted from both sides simultaneously)
than with rules 9, 7 and 8 ( nally spilled holds even after lifted from both sides
simultaneously).
on pushLeft if true do spilled (7)
on pushRight if true do spilled (8)
on pushLeft ; pushRight if true do spilled onTable (9)
Rules 7 and 8 specify that the soup is spilled whenever the bowl is lifted
either from the right-hand side or the left-hand side. However, rule 9 removes
the spill e ect whenever both events are done simultaneously. However, with
rules 9, 7 and 8, we do not obtain the desired result since the spilled formula
may be added after executing the rule that removes spilled formula.
Page 8
To prevent the bowl from spilling, we may add the next rule to rules 7-9:
prevent spilled if true (10)
However, adding the following rules instead would also prevent the bowl to
be lifted since ignoring one event will prevent all the combined events to be
considered.
ignore pushLeft if true (11)
ignore pushRight if true (12)
Contrarily, if we add rule 13 to rules 7-9, we prevent the bowl to be lifted
from both sides simultaneously but not to be only lifted from one side since we
are only ignoring the events if they occur together.
ignore pushLeft ; pushRight if true (13)
This basic example give us a sample of the expressiveness of I. In the next
section, we introduce electronic institutions and the meaning of the formulae
needed for representing them in I.
4 Electronic Institutions
Our work extends electronic institutions (EIs) [10]2, providing them with a nor-
mative layer speci ed in terms of ignore, prevent and force rules. 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 engineers
abstract away from individuals. We de ne below the class of illocutions we aim
at { these are a special kind of term:
De nition 14. Illocutions I are terms ill(p; ag; r; ag0; r0; ) where p is a perfor-
mative ( e.g. inform or request); ag; ag0 are agent identi ers; r ; r 0 are role labels;
and is a term with the actual content of the message.
We shall refer to illocutions that may have uninstantiated (free) variables as
illocution schemes, denoted by I.
An institutional state is a state of a airs that stores all utterances during
the execution of a MAS, also keeping a record of the state of the environment,
all observable attributes of agents and all the expectations associated with the
agents.
We di erentiate two kinds of events, with the following intuitive meanings:
1. I { an agent uttered illocution I.
2. newtick(t) { a new tick of the clock occurred at time t .
2 EI scenes are basically covered with ECA rules
prevent spilled if true (10)
However, adding the following rules instead would also prevent the bowl to
be lifted since ignoring one event will prevent all the combined events to be
considered.
ignore pushLeft if true (11)
ignore pushRight if true (12)
Contrarily, if we add rule 13 to rules 7-9, we prevent the bowl to be lifted
from both sides simultaneously but not to be only lifted from one side since we
are only ignoring the events if they occur together.
ignore pushLeft ; pushRight if true (13)
This basic example give us a sample of the expressiveness of I. In the next
section, we introduce electronic institutions and the meaning of the formulae
needed for representing them in I.
4 Electronic Institutions
Our work extends electronic institutions (EIs) [10]2, providing them with a nor-
mative layer speci ed in terms of ignore, prevent and force rules. 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 engineers
abstract away from individuals. We de ne below the class of illocutions we aim
at { these are a special kind of term:
De nition 14. Illocutions I are terms ill(p; ag; r; ag0; r0; ) where p is a perfor-
mative ( e.g. inform or request); ag; ag0 are agent identi ers; r ; r 0 are role labels;
and is a term with the actual content of the message.
We shall refer to illocutions that may have uninstantiated (free) variables as
illocution schemes, denoted by I.
An institutional state is a state of a airs that stores all utterances during
the execution of a MAS, also keeping a record of the state of the environment,
all observable attributes of agents and all the expectations associated with the
agents.
We di erentiate two kinds of events, with the following intuitive meanings:
1. I { an agent uttered illocution I.
2. newtick(t) { a new tick of the clock occurred at time t .
2 EI scenes are basically covered with ECA rules
Page 9
We shall use event 2 above to obtain the time with which illocutions and
expectations are time-stamped.
We di erentiate two kinds of atomic formulae in our institutional states ,
with the following intuitive meanings:
1. inst(I; t) { I was accepted as an institutional utterance at time t .
2. exp(I; t) { I is expected to be uttered since time t .
We allow agents to utter whatever they want (via I events). However, the
unwanted utterances may be discarded and/or may cause sanctions, depending
on the deontic notions we want or need to implement via our rules. The inst
formulae are thus con rmations of the I events. We shall use formula 2 above to
represent expectations of agents within EIs.
5 Applied Example: Bank
In this section we introduce an example of banking institution where agents are
allowed to do certain operations with money. The operations in our bank are
depositing, withdrawing and transferring. In our example we have two types of
accounts called a and b owned by two di erent agents. In order to perform an
operation in one of these accounts both agents have to simultaneously make the
proper request.
Type a accounts have the limitation that no withdrawing, transferring from
and debiting is allowed having a negative credit. If it is the case and there is
enough money in a type b account of the same agent then necessary credit is
automatically transferred to the account with negative credit and a fee is debited.
Type b accounts have the following limitations:
1. They cannot be in red. All the transactions that would nish in negative
credit are rejected.
2. Withdrawing from or depositing to these accounts is not allowed.
Rule 14 specify the e ects of opening an account of type T to agents A1 and
A2 with an amount M of credit if another account of the same type with the
same owners is not already opened.
on newtick(Time); open account(Id ;A1;A2;T ;M )
if :account(Id ;A1;A2;T ; ) ^ :account(Id ;A2;A1;T ; )
do account(Id ;A1;A2;T ;M )
inst(open account(Id ;A1;A2;T ;M );Time)
(14)
Rule 15 specify the e ect of withdrawing a given quantity Mq of money from
a given account due to the simultaneous request of both owners of the account.
The rules in the action section calculate the new credit for the account and
modi es its value by removing the old credit and adding the new one. Likewise,
a rule for the e ects of depositing may also be speci ed.
on newtick(Time);withdraw(A1; Id ;Mq);withdraw(A2; Id ;Mq)
if account(Id ;A1;A2;T ;M )
do M 2 = M Mq account(Id ;A1;A2;T ;M )
account(Id ;A1;A2;T ;M 2) inst(withdraw(A1;A2; Id ;Mq);Time)
(15)
expectations are time-stamped.
We di erentiate two kinds of atomic formulae in our institutional states ,
with the following intuitive meanings:
1. inst(I; t) { I was accepted as an institutional utterance at time t .
2. exp(I; t) { I is expected to be uttered since time t .
We allow agents to utter whatever they want (via I events). However, the
unwanted utterances may be discarded and/or may cause sanctions, depending
on the deontic notions we want or need to implement via our rules. The inst
formulae are thus con rmations of the I events. We shall use formula 2 above to
represent expectations of agents within EIs.
5 Applied Example: Bank
In this section we introduce an example of banking institution where agents are
allowed to do certain operations with money. The operations in our bank are
depositing, withdrawing and transferring. In our example we have two types of
accounts called a and b owned by two di erent agents. In order to perform an
operation in one of these accounts both agents have to simultaneously make the
proper request.
Type a accounts have the limitation that no withdrawing, transferring from
and debiting is allowed having a negative credit. If it is the case and there is
enough money in a type b account of the same agent then necessary credit is
automatically transferred to the account with negative credit and a fee is debited.
Type b accounts have the following limitations:
1. They cannot be in red. All the transactions that would nish in negative
credit are rejected.
2. Withdrawing from or depositing to these accounts is not allowed.
Rule 14 specify the e ects of opening an account of type T to agents A1 and
A2 with an amount M of credit if another account of the same type with the
same owners is not already opened.
on newtick(Time); open account(Id ;A1;A2;T ;M )
if :account(Id ;A1;A2;T ; ) ^ :account(Id ;A2;A1;T ; )
do account(Id ;A1;A2;T ;M )
inst(open account(Id ;A1;A2;T ;M );Time)
(14)
Rule 15 specify the e ect of withdrawing a given quantity Mq of money from
a given account due to the simultaneous request of both owners of the account.
The rules in the action section calculate the new credit for the account and
modi es its value by removing the old credit and adding the new one. Likewise,
a rule for the e ects of depositing may also be speci ed.
on newtick(Time);withdraw(A1; Id ;Mq);withdraw(A2; Id ;Mq)
if account(Id ;A1;A2;T ;M )
do M 2 = M Mq account(Id ;A1;A2;T ;M )
account(Id ;A1;A2;T ;M 2) inst(withdraw(A1;A2; Id ;Mq);Time)
(15)
Page 10
Rule 16 speci es the e ect of transferring from one account (of an agent and
of a certain type) to another account possibly as payment of a certain concept
C : the source account is reduced and the destination account is increased by the
stated amount.
on newtick(Time); transfer(A1; Ids ; Idd ;C ;M ); transfer(A2; Ids ; Idd ;C ;M )
if account(Ids ;A1;A2;Ts ;Ms) ^ account(Idd ;A3;Td ;Md)
do M 2s = Ms M account(Ids ;A1;A2;Ts ;Ms)
account(Ids ;A1;A2;Ts ;M 2s) M 2d = Md + M
account(Idd ;A3;Td ;Md) account(Idd ;A3;Td ;M 2d)
inst(transfer(A1;A2; Ids ; Idd ;C ;M );Time)
(16)
To avoid concurrent actions a ecting the same account, we use rule 17. In
this case, only the rst action is taken into account and the rest of concurrent
actions are ignored.
prevent account(I ;A1;A2;T ;M ) ^ account(I ;A1;A2;T ;M2) if M 6= M2 (17)
In our example, accounts of type a have the restriction that agents are not
allowed to withdraw or transfer from a accounts with negative credit. This is
achieved with rules like:
ignore withdraw(A; Id ; ) if account(Id ;A; ; a;M ) ^M < 0 (18)
ignore transfer(A; Ids ; ; ; ) if account(Ids ;A; ; a;M ) ^M < 0 (19)
Accounts of type b also have some restrictions. First, they cannot go into
negative numbers. This is achieved with the following rule:
prevent account(Id ;A1;A2; b;M ) if M < 0
Second, agents are not allowed to withdraw from accounts of type b. This is
achieved by rule 20.
ignore withdraw( ; Id ; ) if account(Id ; ; ; b; ) (20)
Furthermore, if an account of type a goes into the negatives then the nec-
essary amount to avoid this situation is transferred from an account of type b.
Rule 21 forces this type of events. Notice that a similar rule but with the order
of the owners of the accounts reversed is also necessary since the owners may
not appear in the same order.
force transfer(A; Idb ; Ida ; a negative;C ); transfer(A2; Idb ; Ida ; a negative;C )
if account(Ida ;A;A2; a;C 2) ^ C 2 < 0 ^ C = C 2 ^
account(Idb ;A;A2; b;C 3) ^ C 3 C
(21)
6 Related Work
In the model of Electronic Institutions of [10], agent interaction is brought about
by uttering illocutions and it is decomposed in a set of scenes where only one
illocution is accepted as legal simultaneously. As for norms, agents may be ex-
pected to utter certain illocutions under given conditions. However, there is no
of a certain type) to another account possibly as payment of a certain concept
C : the source account is reduced and the destination account is increased by the
stated amount.
on newtick(Time); transfer(A1; Ids ; Idd ;C ;M ); transfer(A2; Ids ; Idd ;C ;M )
if account(Ids ;A1;A2;Ts ;Ms) ^ account(Idd ;A3;Td ;Md)
do M 2s = Ms M account(Ids ;A1;A2;Ts ;Ms)
account(Ids ;A1;A2;Ts ;M 2s) M 2d = Md + M
account(Idd ;A3;Td ;Md) account(Idd ;A3;Td ;M 2d)
inst(transfer(A1;A2; Ids ; Idd ;C ;M );Time)
(16)
To avoid concurrent actions a ecting the same account, we use rule 17. In
this case, only the rst action is taken into account and the rest of concurrent
actions are ignored.
prevent account(I ;A1;A2;T ;M ) ^ account(I ;A1;A2;T ;M2) if M 6= M2 (17)
In our example, accounts of type a have the restriction that agents are not
allowed to withdraw or transfer from a accounts with negative credit. This is
achieved with rules like:
ignore withdraw(A; Id ; ) if account(Id ;A; ; a;M ) ^M < 0 (18)
ignore transfer(A; Ids ; ; ; ) if account(Ids ;A; ; a;M ) ^M < 0 (19)
Accounts of type b also have some restrictions. First, they cannot go into
negative numbers. This is achieved with the following rule:
prevent account(Id ;A1;A2; b;M ) if M < 0
Second, agents are not allowed to withdraw from accounts of type b. This is
achieved by rule 20.
ignore withdraw( ; Id ; ) if account(Id ; ; ; b; ) (20)
Furthermore, if an account of type a goes into the negatives then the nec-
essary amount to avoid this situation is transferred from an account of type b.
Rule 21 forces this type of events. Notice that a similar rule but with the order
of the owners of the accounts reversed is also necessary since the owners may
not appear in the same order.
force transfer(A; Idb ; Ida ; a negative;C ); transfer(A2; Idb ; Ida ; a negative;C )
if account(Ida ;A;A2; a;C 2) ^ C 2 < 0 ^ C = C 2 ^
account(Idb ;A;A2; b;C 3) ^ C 3 C
(21)
6 Related Work
In the model of Electronic Institutions of [10], agent interaction is brought about
by uttering illocutions and it is decomposed in a set of scenes where only one
illocution is accepted as legal simultaneously. As for norms, agents may be ex-
pected to utter certain illocutions under given conditions. However, there is no
Page 11
notion of prevention of a state or force of events. Furthermore, only events that
are not part of the protocol are ignored, not allowing to write further conditions
in which an illocution is ignored.
The work presented in this paper is the result of the evolution of our pre-
vious work on norm languages for electronic institutions [1]. In that work, we
presented a rule language that does not use forward chaining to calculate the
e ects of events and to explicitly manage normative positions (i.e. permissions,
prohibitions and obligations). For the present work, we use those rules in the
form of event-condition-action rules. Then, we added standard condition-action
rules that use forward chaining. Furthermore, we changed our standard deontic
notions that only regulated one illocution into more institutional-centred notions
as ignoring, forcing or expecting concurrent events or preventing an institutional
state.
nC+ is a language for representing and reasoning about action domains that
include some normative notions [3]. Its semantics is based on labelled transi-
tion systems. The language allows to make queries about the transition system
generated from an action description allowing to pre-dict, post-dict, or plan.
In the normative aspect, nC+ only labels states and actions as green or red
without including our notion of prevention that ignores actions that lead to
an unwanted state. We can obtain this labeling by adding green to the ini-
tial state and rules of the form \on events if conditions do green red" or
\if condition do green red". Instead of using ignore-rules, nC+ may label
events as non-executable obtaining no solution when this kind of events occur.
Since we want to maintain the state of the multi-agent system, we would need
to ignore all the actions that occurred in that moment even the ones that does
not lead to an unwanted state.
The implementation of nC+ loads the full transition system in order to resolve
the queries. When dealing with
uents with large numeric values, the implemen-
tation su ers from a state explosion increasing the load and resolution time. As
mentioned above, we are aiming at monitoring and maintaining the state of the
enactment of open regulated multi-agent systems. To use the implementation of
nC+ in this setting, we would have to add the new agents to the action descrip-
tion le and reload it again. However, the long time that elapses to complete
this operation makes unviable the use of the implementation for our purposes
and motivated this work.
7 Conclusions and Future Work
In this paper we have introduced a formalism for the management and regu-
lation of concurrent events generated by agents in open MAS. Ours is a rule
language in which concurrent events may have a combined e ect and may be
ignored, forced, expected or sanctioned. The semantics of our formalism relies
on transition systems conferring it a well-studied semantics.
We have explored our proposal in this paper by specifying an example of
concurrency: soup bowl lifting problem and an example of bank as Electronic
Institution.
are not part of the protocol are ignored, not allowing to write further conditions
in which an illocution is ignored.
The work presented in this paper is the result of the evolution of our pre-
vious work on norm languages for electronic institutions [1]. In that work, we
presented a rule language that does not use forward chaining to calculate the
e ects of events and to explicitly manage normative positions (i.e. permissions,
prohibitions and obligations). For the present work, we use those rules in the
form of event-condition-action rules. Then, we added standard condition-action
rules that use forward chaining. Furthermore, we changed our standard deontic
notions that only regulated one illocution into more institutional-centred notions
as ignoring, forcing or expecting concurrent events or preventing an institutional
state.
nC+ is a language for representing and reasoning about action domains that
include some normative notions [3]. Its semantics is based on labelled transi-
tion systems. The language allows to make queries about the transition system
generated from an action description allowing to pre-dict, post-dict, or plan.
In the normative aspect, nC+ only labels states and actions as green or red
without including our notion of prevention that ignores actions that lead to
an unwanted state. We can obtain this labeling by adding green to the ini-
tial state and rules of the form \on events if conditions do green red" or
\if condition do green red". Instead of using ignore-rules, nC+ may label
events as non-executable obtaining no solution when this kind of events occur.
Since we want to maintain the state of the multi-agent system, we would need
to ignore all the actions that occurred in that moment even the ones that does
not lead to an unwanted state.
The implementation of nC+ loads the full transition system in order to resolve
the queries. When dealing with
uents with large numeric values, the implemen-
tation su ers from a state explosion increasing the load and resolution time. As
mentioned above, we are aiming at monitoring and maintaining the state of the
enactment of open regulated multi-agent systems. To use the implementation of
nC+ in this setting, we would have to add the new agents to the action descrip-
tion le and reload it again. However, the long time that elapses to complete
this operation makes unviable the use of the implementation for our purposes
and motivated this work.
7 Conclusions and Future Work
In this paper we have introduced a formalism for the management and regu-
lation of concurrent events generated by agents in open MAS. Ours is a rule
language in which concurrent events may have a combined e ect and may be
ignored, forced, expected or sanctioned. The semantics of our formalism relies
on transition systems conferring it a well-studied semantics.
We have explored our proposal in this paper by specifying an example of
concurrency: soup bowl lifting problem and an example of bank as Electronic
Institution.
Page 12
Although our language is not as expressive as the language of [3] since we
cannot post-dict or plan about an action description, our language is not a
language for checking properties of a transition system but for specifying its
behaviour.
As a proof of concept, an interpreter of I were implemented in Prolog. As
future work, we would like to embed this interpreter in a real MAS and include
the distributed management of normative positions introduced in [11].
Acknowledgements { This work was partially funded by the Spanish Edu-
cation and Science Ministry as part of the projects TIN2006-15662-C02-01 and
2006-5-0I-099 and it was partially done during a stay of the author in Imperial
College London. The author wants to thank Marek Sergot for his advise and
hospitality. He also thanks Juan-Antonio Rodrguez-Aguilar and Pablo Noriega
for their comments and reviews. Garca-Camino enjoys an I3P grant from the
Spanish National Research Council (CSIC).
References
1. Garca-Camino, A., Rodrguez-Aguilar, J.A., Sierra, C., Vasconcelos, W.: Norm
Oriented Programming of Electronic Institutions. In: Fifth International Joint
Conference on Autonomous Agents and Multiagent Systems. (AAMAS'06). (2006)
2. Artikis, A., Kamara, L., Pitt, J., Sergot, M.: A Protocol for Resource Sharing in
Norm-Governed Ad Hoc Networks. In: Declarative Agent Languages and Tech-
nologies II. Volume 3476 of LNCS. Springer-Verlag (2005)
3. Sergot, M., Craven, R.: The deontic component of nC+. In: Eighth International
Workshop on Deontic Logic in Computer Science (DEON'06). (2006)
4. Alberti, M., Gavanelli, M., Lamma, E., Mello, P., Sartor, G., Torroni, P.: Mapping
deontic operators to abductive expectations. In: Proceedings of 1st International
Symposium on Normative Multiagent Systems (NorMAS 2005), AISB 2005, Hert-
fordshire, Hat eld, UK (2005)
5. Minsky, N.: Law Governed Interaction (LGI): A Distributed Coordination and
Control Mechanism (An Introduction, and a Reference Manual). Technical report,
Rutgers University (2005)
6. von Wright, G.H.: Norm and Action: A Logical Inquiry. Routledge and Kegan
Paul, London (1963)
7. Apt, K.R.: From Logic Programming to Prolog. Prentice-Hall, U.K. (1997)
8. Fitting, M.: First-Order Logic and Automated Theorem Proving. Springer-Verlag,
New York, U.S.A. (1990)
9. Gelfond, M., Lifschitz, V., Rabinov, A.: What are the limitations of the Situation
Calculus? Essays in Honor of Woody Bledsoe (1991) 167{179
10. Esteva, M.: Electronic Institutions: from speci cation to development. PhD thesis,
Universitat Politecnica de Catalunya (2003) Number 19 in IIIA Monograph Series.
11. Gaertner, D., Garca-Camino, A., Noriega, P., Rodrguez-Aguilar, J.A., Vasconce-
los, W.: Distributed Norm Management in Regulated Multi-agent Systems. In:
Sixth International Joint Conference on Autonomous Agents and Multiagent Sys-
tems. (AAMAS'07). (2007)
cannot post-dict or plan about an action description, our language is not a
language for checking properties of a transition system but for specifying its
behaviour.
As a proof of concept, an interpreter of I were implemented in Prolog. As
future work, we would like to embed this interpreter in a real MAS and include
the distributed management of normative positions introduced in [11].
Acknowledgements { This work was partially funded by the Spanish Edu-
cation and Science Ministry as part of the projects TIN2006-15662-C02-01 and
2006-5-0I-099 and it was partially done during a stay of the author in Imperial
College London. The author wants to thank Marek Sergot for his advise and
hospitality. He also thanks Juan-Antonio Rodrguez-Aguilar and Pablo Noriega
for their comments and reviews. Garca-Camino enjoys an I3P grant from the
Spanish National Research Council (CSIC).
References
1. Garca-Camino, A., Rodrguez-Aguilar, J.A., Sierra, C., Vasconcelos, W.: Norm
Oriented Programming of Electronic Institutions. In: Fifth International Joint
Conference on Autonomous Agents and Multiagent Systems. (AAMAS'06). (2006)
2. Artikis, A., Kamara, L., Pitt, J., Sergot, M.: A Protocol for Resource Sharing in
Norm-Governed Ad Hoc Networks. In: Declarative Agent Languages and Tech-
nologies II. Volume 3476 of LNCS. Springer-Verlag (2005)
3. Sergot, M., Craven, R.: The deontic component of nC+. In: Eighth International
Workshop on Deontic Logic in Computer Science (DEON'06). (2006)
4. Alberti, M., Gavanelli, M., Lamma, E., Mello, P., Sartor, G., Torroni, P.: Mapping
deontic operators to abductive expectations. In: Proceedings of 1st International
Symposium on Normative Multiagent Systems (NorMAS 2005), AISB 2005, Hert-
fordshire, Hat eld, UK (2005)
5. Minsky, N.: Law Governed Interaction (LGI): A Distributed Coordination and
Control Mechanism (An Introduction, and a Reference Manual). Technical report,
Rutgers University (2005)
6. von Wright, G.H.: Norm and Action: A Logical Inquiry. Routledge and Kegan
Paul, London (1963)
7. Apt, K.R.: From Logic Programming to Prolog. Prentice-Hall, U.K. (1997)
8. Fitting, M.: First-Order Logic and Automated Theorem Proving. Springer-Verlag,
New York, U.S.A. (1990)
9. Gelfond, M., Lifschitz, V., Rabinov, A.: What are the limitations of the Situation
Calculus? Essays in Honor of Woody Bledsoe (1991) 167{179
10. Esteva, M.: Electronic Institutions: from speci cation to development. PhD thesis,
Universitat Politecnica de Catalunya (2003) Number 19 in IIIA Monograph Series.
11. Gaertner, D., Garca-Camino, A., Noriega, P., Rodrguez-Aguilar, J.A., Vasconce-
los, W.: Distributed Norm Management in Regulated Multi-agent Systems. In:
Sixth International Joint Conference on Autonomous Agents and Multiagent Sys-
tems. (AAMAS'07). (2007)
Sign up today - FREE
Mendeley saves you time finding and organizing research. Learn more
- All your research in one place
- Add and import papers easily
- Access it anywhere, anytime
Start using Mendeley in seconds!
Readership Statistics
3 Readers on Mendeley
by Discipline
by Academic Status
67% Ph.D. Student
33% Post Doc
by Country
100% Spain