=Paper=
{{Paper
|id=Vol-494/paper-10
|storemode=property
|title=Normative Programming for Organisation Management Infrastructures
|pdfUrl=https://ceur-ws.org/Vol-494/coinpaper1.pdf
|volume=Vol-494
|dblpUrl=https://dblp.org/rec/conf/mallow/HubnerBB09
}}
==Normative Programming for Organisation Management Infrastructures==
https://ceur-ws.org/Vol-494/coinpaper1.pdf
Normative Programming for Organisation
Management Infrastructures
Jomi F. Hübner†∗ Olivier Boissier† Rafael H. Bordini‡
∗ Dept Automation and Systems Eng. † Ecole Nationale Supérieure des Mines ‡ Intitute of Informatics
Federal University of Santa Catarina Saint Etienne, France Federal University of Rio Grande do Sul
Florianópolis, Brazil Email: {hubner, boissier}@emse.fr Porto Alegre, Brazil
Email: jomi@das.ufsc.br Email: R.Bordini@inf.ufrgs.br
Abstract—Recent work shows a tendency to use programming coded using an object-oriented programming language (e.g.
languages specific to the social aspects of multi-agent systems, Java). However, the exploratory stage of current OMI lan-
for example in programming norms that agents ought to follow. guages often requires changes in the implementation so that
In this paper, we introduce a simple and elegant normative
programming language called NPL and show its operational one can experiment with new features. The refactoring of the
semantics. We then define a particular class of NPL programs OMI for such experiments is usually an expensive task that
that are suitable for programming Organisation Management we would like to simplify. Our work therefore addresses one
Infrastructures (OMI) for MOISE, defining a Normative Organ- of the main missing ingredients for the practical development
isation Programming Language (NOPL). We show how MOISE’s of sophisticated multi-agent systems where the macro-level
Organisation Modelling Language can be translated into NOPL,
and briefly describe how this all has been implemented on top requires complex organisational and normative structures in
of an artifact-based OMI for MOISE. the context of so many different views and approaches still
being actively researched by the MAS research community.
I. I NTRODUCTION This problem is particularly complex for organisation mod-
The use of organisational and normative concepts is widely els that consider elements with different natures like groups,
accepted as a suitable approach for the design and implemen- roles, common goals, and norms. These elements have their
tation of Multi-Agent Systems (MAS) [1]–[4]. Although these own life cycle, are bound together, and are constrained by a
concepts are useful for MAS methodologies and therefore set of properties (e.g. role compatibility and cardinality). Our
used at design time, in this paper we focus on their use at proposal is thus an uniformed approach where all kinds of
run-time. We conceive of a multi-agent system as a set of constraints are expressed by norms. These norms then can be
agents participating to an organisation by playing roles in it. explicitly and flexibly enforced by different mechanisms. The
An important component of MAS is thus the Organisation OMI is then mainly concerned with providing such mechanism
Management Infrastructure (OMI), which exists in a system instead of considering all kinds of constraints. However, we
to help and supervise agents in the achievement of the purpose do not want to force the MAS designer to program the organ-
of the organisation. isation using only norms. The designer should program their
A recent trend in the development of OMIs is to provide organisation using more suitable constructors. For example,
languages that the MAS designer (human or artificial in using a role cardinality constructor to state “a classroom has
the case of self-organisation) uses to write a program that one professor” instead of a norm like “it is prohibited that two
will define the organisational functioning of the system, agents play the role professor in the same classroom”).
complementing agent programming languages that defines The solution presented in this paper is to translate a more
the individual functioning of the system. The former type abstract language into another simpler language. The problem
of languages can focus on different aspects of the overall of implementing the OMI is thus reduced to a translation
system, for example: structural aspects (roles and groups) [5], problem, which is usually much simpler and less error prone.
dialogical aspects [2], coordination aspects [6], and normative We start from an organisational modelling language which is
aspects [7], [8]. The OMI is then responsible for interpreting then automatically translated into a normative programming
such a language and providing corresponding services to the language. The language available to the MAS designer has
agents. For instance, in the case of MOISE+ [4], the designer thus more abstract concepts (such as groups, roles, and global
can program a norm such as “an agent playing the role ‘seller’ plans) than normative languages. More precisely, our starting
is obliged to deliver some goods after being payed by the agent language is the MOISE Organisation Modelling Language
playing role ‘buyer”’. The OMI is responsible for identifying (OML — see Sec. III) and our target language is the Normative
the activation of that obligation and to enforce the compliance Organisation Programming Language (NOPL — Sec. IV).
to that norm by the agents playing the corresponding roles. NOPL is a particular class of programs of a normative pro-
We are particularly interested in a flexible and adaptable gramming language presented and formalised in this paper
implementation of OMIs. Such implementation is normally (Sec. II). All of this has been implemented on top of our
previous work on OMI where an artifact-based approach, np ::= “np” atom “{” ( rule | norm )* “}”
called ORA4MAS, is used (Sec. V). rule ::= atom [ “:-” formula ] “.”
The main contributions of this work are: (i) a normative norm ::= “norm” id “:” formula “->” ( fail | obl ) “.”
programming language and its formalisation using operational fail ::= “fail(” atom “)”
semantics; (ii) the translation from an organisational language obl ::= “obligation(”
into the normative language; and (iii) an implemented artifact- (var | id) “,” atom “,” formula “,” time “)”
based OMI that interprets the target normative language. These
contributions are better discussed and placed in the context of formula ::= atom | “not” formula |
the relevant literature in Sec. VI. atom ( “&” | “|”) formula
time ::= “‘” ( “now” |
II. N ORMATIVE P ROGRAMMING L ANGUAGE number ( “second” | “minute” | ...))
Although several languages for norms are available, (e.g. “‘” [ ( “+” | “-” ) time ]
[7]–[9]), for this project we need a language that handles
obligations and regimentation. While agents can violate obli- Fig. 1. EBNF of the NPL
gations (and sanctions might take place later), regimentation is
a preventive strategy of enforcement: agents are not capable to
violate a regimented norm [10]. Regimentation is important for the activation of the norm. Two types of norm consequences
an OMI to allow situations where the designer wants to define ψ are considered:
norms that must be followed because its violation represent a • fail – fail(r): represents the case where the norm is
serious risk for the organisation.1 The current languages either regimented. Argument r represents the reason for the
consider obligation or regimentation as enforcement strategies, failure;
and do not allow the designers (nor the agents) to dynamically • obl – obligation(a, r, g, d): represents the case where a
choose the best strategy for their application. new obligation has to be created for some agent a as the
Our language can be relatively simple because we do not consequence of the norm activation. Argument r is the
need prohibitions nor permission as primitives. By default, reason for the obligation (which has to include the norm’s
everything is permitted and thus the designer does not need id); g is the formula that represents the obligation (a state
to code permissions. Prohibitions can be represented either by of the world that the agent must try to bring about, i.e. a
regimentation or as an obligation for someone else to decide goal it has to achieve); and d is the deadline to fulfil the
how to handle the situation (this approach is inspired by the obligation.
approach by Grossi et al. [10]). For example, consider the A simple example to illustrate the language is given below;
norm “it is prohibited to submit a paper with more than 6 we used source code comments to explain the program.
pages”. In case of regimentation of this norm, tentatives to np example {
a(1). a(2). // facts
submit a paper with more than 6 pages will fail. In case this ok(X) :- a(A) & b(B) & A>B & X = A*B. // rule
norm is not regimented, the designer has to define a norm // note that b/1 is not defined in the program;
// it is a dynamic fact provided at run-time
such as “when a paper with more than 6 pages is submitted,
the chair has to decide wether to accept the submission or // alice has 4 hours to achieve a value of X < 5
norm n1: ok(X) & X > 5
not”. Another assumption that allowed us to devise a simple -> obligation(alice,n1,ok(X) & X<5,‘now‘+‘4 hours‘).
language is that we do not consider inconsistent norms. Either
// bob is obliged to sanction alice in case X > 10
the programmer or the program generator are supposed to norm n2: ok(X) & X > 10
handle this issue. -> obligation(bob,n2,sanction(alice),‘now‘+‘1 day‘).
// example of regimented norm; X cannot be > 15
A. Syntax norm n3: ok(X) & X > 15 -> fail(n3(X)).
}
Given the above requirements and simplifications, we intro-
duce below a new Normative Programming Language (NPL) As in other approaches (e.g. [11], [12]), we have a
(Fig. 1 contains the definition of its syntax).2 A normative static/declarative aspect of the norm (where norms are ex-
program np is composed of: (i) a set of facts and inference pressed in NPL resulting in a normative program) and a
rules (as in Prolog); and (ii) a set of norms. A NPL norm has dynamic/operational aspect (where obligations are created for
the general form norm id : ϕ -> ψ, where id is a unique existing agents). We call the first aspect simply norm and the
identifier of the norm; ϕ is a formula that determines the second obligation. An obligation has thus a run-time life-cycle.
activation condition for the norm; and ψ is the consequence of It is created when the activation condition ϕ of some norm n
holds. The activation condition formula is used to instantiate
1 The importance of regimentation is corroborated by relevant implementa- the values of variables a,r,g, and d of the obligation to be
tions of OMI, such as AGR, S-MOISE+ , and ISLANDER, which consider created. Once created, the initial state of an obligation is active
regimentation as an important enforcement mechanism. (Fig. 2). The state changes to fulfilled when agent a fulfils the
2 The non-terminals not included in the specification, atom, id, var, and
number, correspond, respectively, to predicates, identifiers, variables, and norm’s obligation g before the deadline d. The obligation state
numbers as used in Prolog. changes to unfulfilled when agent a does not fulfil the norm’s
• N is a set of norms, where each norm n ∈ N is a norm
fulfilled
g in the syntax defined for norm in the grammar in Fig. 1.
• The state of the normative system is either a sound state
ø d > now denoted by > or a failure state denoted by ⊥; the latter
active unfulfilled
is caused by regimentation through the fail( ) language
construct within norms. This is accessible to the agent
¬ø execution system which prevents the execution of the
inactive
action which would lead to the facts causing the failure
state, and rolls back the facts about the state of the
execution system.
Fig. 2. State Transitions for Obligations • OS is a set of obligations, each accompanied by its
current state; each element os ∈ sosts is of the form
ho, osti where o is an obligation, again according to
obligation g before the deadline d. As soon as the activation the syntax for obligations given in Fig. 1, and ost ∈
condition of the norm that creates the the obligation (ϕ) ceases {active, fulfilled, unfulfilled, inactive} (the possi-
to hold, the state changes to inactive. Note that a reference to ble states of each individual obligation). This is also of
the norm that led to the creation of the obligation is kept as interest to the agent execution system and thus accessible
part of the obligation itself (the r argument), and the activation to it.
condition of this norm must remain true for the obligation • t is the current time which is automatically changed
to stay active; only an active obligation will become either by the underlying execution system, using, of course, a
fulfilled or unfulfilled, eventually. Fig. 2 shows the obligation discrete, linear notion of time. For the purpose of the
life-cycle. operational semantics, it is assumed that all rules that
apply at a given time are actually applied before the
B. Semantics system changes the state to the next time.
We now give semantics to NPL using the well known Given a normative program P — which is, remember, a
structural operational semantics approach [13]. set of facts and rules (PF ) and a set of norms (PN ) written
in NPL — the initial configuration of the normative system
A program in NPL is essentially a set of norms where each
(before the system execution starts) is hPF , PN , >, ∅, 0i.
norm is given according to the grammar in Fig. 1; it can also
In the semantic rules, we use the notation Tc to denote the
contain a set of initial facts and inference rules specific to the
component c of tuple T . The semantic rules are as follows.
program’s domain (all according to the grammar of the NPL
1) Norms: The rule below formalises regimentation: when
language). The normative system operates in conjunction with
any norm n becomes active — i.e. its condition component
an agent execution system; the former is constantly fed by the
holds in the current state — and its consequence is fail( ),
latter with “facts” which, possibly together with the domain
we move to a configuration where the normative state is no
rules, express the current state of the execution system. Any
longer sound but a failure state (⊥). Note that we use nϕ to
change in such facts leads to a potential change in the state of
refer to the condition part of norm n (the formula between “:”
the normative system, and the execution system checks that the
and “->” in NPL’s syntax) and nψ to refer to the consequence
normative system is still in a sound state before committing
part of n (the formula after “->”).
towards particular execution steps; similarly, it can have access
to current obligations generated by the normative system. The n∈N F |= nϕ nψ = fail( )
overall system’s clock also causes potential changes in the (Regim)
state of the transition system, by changing the time component hF, N, >, OS, ti −→ hF, N, ⊥, OS, ti
of its configuration.
The underlying execution system, after realising a failure
As we use operational semantics to give semantics to the state caused by Rule Regim above, needs to ensure the facts
normative programming language (i.e. the language used to are rolled back to the previously consistent state, which will
program the normative system specifically), we first need make the following rule apply.
to define a configuration of the transition system that will
be defined through the semantic rules presented later. A ∀n ∈ N.(F |= nϕ ⇒ nψ 6= fail( ))
configuration of our normative system, giving semantics to (Consist)
hF, N, ⊥, OS, ti −→ hF, N, >, OS, ti
NPL, is a tuple hF, N, >, OS, ti where:
• F is a set of facts received from the execution system The next rule is similar to Rule Regim but instead of
and possibly rules expressing domain knowledge. The failure, the consequence is the creation of an obligation. In
former works as a form of input from the agent execution the rule, ‘m.g.u.’ means “most general unifier” as in Prolog-
system to the normative system. Each formula f ∈ F is, like unification; the notation tθ means the application of the
as explained earlier, an atomic first order formula or a variable substitution function θ to formula t. Note that we
Horn clause. required that the deadlines of newly created obligations are not
obl
yet past. The notation = is used for equality of obligations, os ∈ OS os = ho, activei F 6|= or
(Inactive)
which ignores the deadline in the comparison. That is, we hF, N, >, OS, ti −→
define that an obligation obligation(a, r, g, d) is equals to hF, N, >, (OS \ {os}) ∪ {ho, inactivei}, ti
an obligation obligation(a0 , r0 , g 0 , d0 ) if and only if a = a0 ,
r = r0 , and g = g 0 . Because of this, Rule Oblig does not III. MOISE O RGANISATIONAL M ODELLING L ANGUAGE
allow the creation of the same obligation with two different MOISE proposes an organisational modelling language
deadlines. Note also that if there already exists an equal (OML) that explicitly decomposes the specification of or-
obligation but it has become inactive, this does not prevent ganisation into structural, functional, and normative dimen-
the creation of the obligation. sions [4]. The structural dimension specifies the roles, groups,
and links of the organisation. The definition of roles states
n∈N F |= nϕ nψ = o oθd > t that when an agent chooses to play some role in a group, it
0 0 obl
¬∃ho , osti ∈ OS . (o = oθ ∧ ost 6= inactive) is accepting some behavioural constraints and rights related to
(Oblig) this role. The functional dimension specifies how the global
hF, N, >, OS, ti −→ collective goals should be achieved, i.e. how these goals are
hF, N, >, OS ∪ hoθ, activei, ti decomposed (within global plans), grouped in coherent sets
where θ is the m.g.u. such that F |= oθ (through missions) to be distributed among the agents. The
decomposition of global goals results in a goal-tree, called
2) Obligations: Recall that a NPL obligation has the scheme, where the leaf-goals can be achieved individually by
general form obligation(a, r, g, d). With a slight abuse of the agents. The normative dimension is added in order to bind
notation, we shall use oa to refer to the agent that has the the structural dimension with the functional one by means
obligation o; or to refer to the reason for obligation o; og of the specification of the roles’ permissions and obligations
to refer to the state of the world that agent oa is obliged to within missions.
achieve (the goal the agent should adopt); and od to refer to As an illustrative and simple example of an organisation
the deadline for the agent to do so. An important aspect of specified using MOISE+ , we consider agents that aim at writ-
obligation syntax is that the NPL parser always ensures that ing a paper and therefore have an organisational specification
the programmer used the norm’s id as predicate symbol in to help them collaborate. Due to lack of space, we will focus
or and so in the semantics, when we say or , we are actually on the functional and normative dimensions in the remainder
referring to the activation condition nϕ of the norm used to of this paper. For the structure of the organisation, it is enough
create the obligation. to know that there is only one group (wpgroup) where two
Rule Fulfil says that the state of an active obligation o roles (editor and writer) can be played.
should be changed to fulfilled if the state of the world og To coordinate the achievement of the goal of writing a
that the agent agent was obliged to achieve has already been paper, a scheme is defined in the functional specification of
achieved (i.e. the domain rules and facts from the underlying the organisation (Fig. 3(a)). In this scheme, a draft version of
system imply g). Note however that such state must have been the paper has to be written first (identified by the goal fdv
achieved within the deadline. in Fig. 3(a)). This goal is decomposed into three sub-goals:
write a title, an abstract, and the section titles; the sub-goals
os ∈ OS os = ho, activei have to be achieved in this very sequence. Other goals, such
F |= og od ≥ t as finish, have sub-goals that can be achieved in parallel. The
(Fulfil) specification also includes a “time-to-fulfil” (TTF) attribute for
hF, N, >, OS, ti −→
goals indicating how much time an agent has to achieve the
hF, N, >, (OS \ {os}) ∪ {ho, fulfilledi}, ti
goal. The goals of this scheme are distributed in three missions
which have specific cardinalities (see Fig. 3(c)): the mission
Rule Unfulfil says that the state of an active obligation o mM an is for the general management of the process (one and
should be changed to unfulfilled if the deadline is already only one agent must commit to it), mission mCol is for the
past; note that the rule above would have changed the status collaboration in writing the paper’s content (from one to five
to fulfilled so the obligation would no longer be active if it agents can commit to it), and mission mBib is for gathering
had been achieved in time. the references for the paper (one and only one agent must
commit to it). A mission defines all goals an agent commits to
os ∈ OS os = ho, activei od < t when participating in the execution of a scheme; for example,
(Unfulfil)
hF, N, >, OS, ti −→ a commitment to mission mM an is effectively a commitment
hF, N, >, (OS \ {os}) ∪ {ho, unfulfilledi}, ti to achieve four goals of the scheme. Goals without an assigned
mission are satisfied by the achievement of their sub-goals.
Rule Inactive says that the state of an active obligation o The normative specification relates roles to missions (Ta-
should be changed to inactive if the reason (i.e. motivation) ble I). For example, norm n2 states that any agent playing the
for the obligation no longer holds in the current system state role writer has one day to commit to mission mCol. Designers
reflected in F . can also define their own application-dependent conditions (as
in Sec. V. The main idea is that an OS is translated to
different programs in NOPL, such programs define then the
management of norms for groups and schemes. In this section
we consider only the programs for schemes.
A. Facts
For scheme programs, the following facts, defined in the
OS, are considered:
• scheme_mission(m,min,max): is a fact
that defines the cardinality of a mission (e.g.
scheme_mission(mCol,1,5)).
(a) Paper Writing Scheme
• goal(m,g,pre-cond,‘ttf ‘): is a fact that defines the
arguments for a goal g: its mission, pre-conditions, and
mission cardinality TTF (e.g. goal(mMan,wsec,[wcon],‘2 days‘)).
mM an 1..1 The NOPL also defines some dynamic facts that represent
mCol 1..5 the current state of the organisation and will be provided by
mBib 1..1 the artifact that manage the scheme instance:
(b) Monitoring Scheme
mr 1..1 • plays(a,ρ,gr): agent a plays the role ρ in the group
ms 1..1 instance identified by gr.
(c) Mission Cardinalities
• responsible(gr,s): the group instance gr is responsi-
ble for the missions of scheme instance s.
• committed(a,m,s): agent a is committed to mission
m in scheme s.
• achieved(s,g,a): goal g in scheme s has been
Fig. 3. Functional Specification for the Paper Writing Example achieved by agent a.
B. Rules
id condition role type mission TTF
Besides facts, we define some rules that will be useful for
n1 editor per mM an –
n2 writer obl mCol 1 day
the norms. The rules are used to infer the state of the scheme
n3 writer obl mBib 1 day (e.g. whether it is well-formed) and goals (e.g. whether it is
n4 unfulfilled(n2) editor obl ms 3 hours ready to be achieved or not). Note that the semantics of well-
n5 fulfilled(n3) editor obl mr 3 hours
n6 #mc editor obl ms 1 hour
formed and ready goal are formally given by these rules. As
an example, some of such rules for the paper writing scheme
#mc stands for the condition “more agents committed to a mission than are listed below.
permitted by the mission cardinality” // number of players of a mission M in scheme S
TABLE I mplayers(M,S,V) :- .count(committed(_,M,S),V).
N ORMATIVE S PECIFICATION FOR THE PAPER W RITING E XAMPLE // status of a scheme S
well_formed(S) :-
mplayers(mBib,S,V1) & V1 >= 1 & V1 <= 1 &
mplayers(mCol,S,V2) & V2 >= 1 & V2 <= 5 &
mplayers(mMan,S,V3) & V3 >= 1 & V3 <= 1.
in norms n4–n6). Norms n4 and n5 define sanction and reward
// ready goals: all pre-conditions have been achieved
strategies for fulfilment and unfulfilment of norms n2 and n3 ready(S,G) :-
respectively. Norm n5 can be read as “the agent playing role goal(_, G, PCG, _) & all_achieved(S,PCG).
all_achieved(_,[]).
‘editor’ has 3 hours to commit to mission mr when norm n3 all_achieved(S,[G|T]) :-
is fulfilled”. Once committed to mission mr, the editor has achieved(S,G,_) & all_achieved(S,T).
to achieve the goal reward. Note that a norm in MOISE is
C. Norms
always an obligation or permission to commit to a mission.
Goals are therefore indirectly linked to roles since a mission We have three classes of norms in NOPL: norms for goals,
is a set of goals. norms for properties, and domain norms (which are explicitly
stated in the normative specification). For the former class, we
IV. N ORMATIVE O RGANISATION have the following norm:
// agents are obliged to fulfil their ready goals
P ROGRAMMING L ANGUAGE norm ngoa:
committed(A,M,S) & goal(M,G,_,D) &
The NOPL is a particular class of NPL programs applied to well_formed(S) & ready(S,G)
MOISE. The syntax and semantics are the same as presented -> obligation(A,ngoa,achieved(S,G,A),‘now‘ + D).
in Sec. II, but the set of facts, rules, and norms are specific This norm can be read as “when an agent A: (1) is committed
for MOISE model and the organisational artifacts presented to a mission M that (2) includes a goal G, and (3) the mission’s
scheme is well-formed, and (4) the goal is ready, then agent scheme instance is managed by an artifact. We can effortlessly
A is obliged to achieve the goal G before the deadline for the distribute the OMI by deploying as many artifacts as necessary
goal”. This norm thus gives a precise semantics for commit- for the application.
ment. It also illustrates the advantage of using a translation to Each organisational artifact has an NPL interpreter loaded
implement the OMI instead of an object oriented programming with (i) the NOPL program automatically generated from
language. For example, if some application or experiment the OS for the type of the artifact and (ii) dynamic facts
requires a semantics of commitment where the agent is obliged representing the current state of (part of) the organisation. The
to achieve the goal even if the scheme is not well-formed, interpreter is then used to compute: (i) whether some operation
it is simply a matter of changing the translation to a norm will bring the organisation into a inconsistent state (where
that does not include the well_formed(S) predicate in the inconsistency is defined by the designer by means of regi-
activation condition of the norm. One could even conceive an mentations), and (ii) the current state of the obligations. The
application using schemes being managed by different NOPL following algorithm, implemented on top of CArtAgO [16],
programs (i.e. schemes translated differently). shows the general pattern we used to implement every op-
For the second class of norms, only the mission cardinality eration (e.g. role adoption, commitment to mission) in the
property is considered in this paper since other properties are organisational artifacts. In this new approach, the artifacts
handled in a similar way. In the case of mission cardinality, the still provide an interface for the agents, and are now mostly
norm has to define the consequences of a circumstance where programmed in NOPL instead of Java.
there are more agents committed to a mission than permitted
in the scheme specification. As presented in Sec. II, two kinds // let oe be the current state of the organisation managed by the
of consequences are possible, obligation and regimentation, artifact
and the designer chooses one or the other when writing // let p be the current NOPL program
the OS. Regimentation is the default consequence and it // let npi be the NPL interpreter
is used when there is no norm with condition #mc in the when an operation o is triggered by agent a do
normative specification. Otherwise, as in norm n6 of Table I, oe0 ← oe // creates a “backup” of current oe
the consequence will be an obligation. The norm for mission executes operation o to change oe
cardinality regimentation is: f ← a list of predicates representing oe
// norm for the cardinality regimentation
norm mission_cardinality: r ← npi(p, f ) // runs the interpreter for the new state
scheme_mission(M,_,MMax) & if r = fail then
mplayers(M,S,MP) & MP > MMax
-> fail(mission_cardinality). oe ← oe0 // restore the state backup
and the norm without regimentation is: fail operation o
// norm for the cardinality regimentation
else
norm mission_cardinality: update obligations in the observable properties
scheme_mission(M,_,MMax) & succeed operation o
mplayers(M,S,MP) & MP > MMax
responsible(Gr,S) & plays(A,editor,Gr)
-> obligation(A,mission_cardinality,
committed(A,ms,_), ‘now‘+‘1 hour‘).
where the agent playing editor is obliged to commit to the We also developed a program that automatically generate
mission ms in one hour. the NOPL given an OS, however, due the lack of space, it is
For the third class of norms, each norm in the normative not presented here. The reader will find more details about this
specification of the OML has a corresponding norm in NOPL. architecture, the translation, and a complete implementation of
Whereas OML obligations refer to roles and missions, NPL this OMI at https://sourceforge.net/scm/?type=svn&group id=
requires that obligations are for agents and towards a goal. 163721.
The NOPL norm thus identifies the agents playing the role VI. R ELATED W ORKS
in groups responsible for the scheme and, if the number of
This work is based on several approaches to organisation,
players still does not reach the maximum, the agent is obliged
institutions, and norms (cited throughout the paper). In this
to achieve a state where it is committed to the mission. For
section, we briefly relate and compare our main contributions
example, the NOPL norm for norm n2 of Table I is:
norm n2: to such work.
plays(A,writer,Gr) & responsible(Gr,S) & The first contribution of the paper, the NPL, should be
mplayers(mCol,S,V) & V < 5
-> obligation(A,n2,committed(A,mCol,S),‘now‘+‘1 day‘). considered specially for two properties of the language: its
simplicity and its formalisation (that led to an available
V. A RTIFACT-BASED A RCHITECTURE implementation). Similar work has been done by Tinnemeier
The proposals of this paper have been implemented on et al. [7], where the operational semantics for a normative
an OMI that follows the Agent & Artifact [14], [15]. In language was also proposed. They assume the availability of
this approach, a set of organisational artifacts is available a snapshot of the global state of the organisation to evaluate
in the MAS environment providing operations for the agents activation of norms, which may hinder the implementation in
so that they can interact with the OMI. For example, each a distributed scenario. Our NPL also requires a snapshot of
the organisational artifact state to evaluate norms, however [5] J. Ferber and O. Gutknecht, “A meta-model for the analysis and design of
the distribution problem is solved by generating different organizations in multi-agents systems,” in Proc. of the 3rd International
Conference on Multi-Agent Systems (ICMAS’98), Y. Demazeau, Ed.
normative programs for several distributed artifacts where only IEEE Press, 1998, pp. 128–135.
the local state of the organisation is required. Another impor- [6] D. V. Pynadath and M. Tambe, “An automated teamwork infrastructure
tant difference is that in our approach the designer specifies for heterogeneous software agents and humans,” Autonomous Agents
and Multi-Agent Systems, vol. 7, no. 1-2, pp. 71–100, 2003.
the organisation in a higher-level language (OML) that is [7] N. Tinnemeier, M. Dastani, and J.-J. Meyer, “Roles and norms for
translated into a normative programmin language (NOPL). programming agent organizations,” in Proc. of AAMAS 09, J. Sichman,
Regarding the second contribution, namely the automatic K. Decker, C. Sierra, and C. Castelfranchi, Eds., 2009.
[8] A. Garcı́a-Camino, J. A. Rodrı́guez-Aguilar, C. Sierra, and W. Vas-
translation, we were inspired by work on ISLANDER [8], [17]. concelos, “Constraining rule-based programming norms for electronic
The main difference here is the initial and target languages. institutions,” Journal of Autonomous Agents and Multi-Agent Systems,
While they translate a normative specification into a rule-based vol. 18, no. 1, pp. 186–217, Feb 2009.
[9] F. L. y López, M. Luck, and M. d’Inverno, “Constraining autonomy
language, we start from an organisational language and target through norms,” in Proc. of first ICMAS. ACM, 2002, pp. 674 – 681.
at a normative language. It is simpler to translate organisational [10] D. Grossi, H. Aldewered, and F. Dignum, “Ubi Lex, Ibi Poena: Design-
norms into NPL norms, since we have norms in both sides ing norm enforcement in e-institutions,” in Coordination, Organizations,
Institutions, and Norms in Agent Systems II, ser. LNAI, P. Noriega,
of the translation it is a 1-to-1 translation, than translate J. Vázquez-Salceda, G. Boella, O. Boissier, V. Dignum, N. Fornara,
organisational norms into rules. and E. Matson, Eds., vol. 4386. Springer, 2007, pp. 101–114, revised
Selected Papers.
Regarding the third contribution, the OMI, we started from [11] N. Fornara and M. Colombetti, “Specifying and enforcing norms in
ORA4MAS [15]. The advantages of the approach presented artificial institutions,” in Proc. of the 4th European Workshop on
here are twofold: (i) it is easier to change the translation Multi-Agent Systems (EUMAS 06), A. Omicini, B. Dunin-Keplicz, and
J. Padget, Eds., 2006.
than the Java implementation of the OMI; and (ii) from the [12] J. Vázquez-Salceda, H. Aldewereld, and F. Dignum, “Norms in multia-
operational semantics of NPL and the formal translation we gent systems: some implementation guidelines,” in Proc. of the Second
are taking significant steps towards a formal semantics for European Workshop on Multi-Agent Systems (EUMAS 2004), 2004,
[13] G. D. Plotkin, “A structural approach to operational semantics,” Com-
MOISE. puter Science Department, Aarhus University, Aarhus, Denmark, Tech.
Rep., 1981.
VII. C ONCLUSION [14] A. Omicini, A. Ricci, and M. Viroli, “Artifacts in the A&A meta-model
for multi-agent systems,” Autonomous Agents and Multi-Agent Systems,
In this paper we showed an approach for translating an vol. 17 (3), pp. 432–456, Dec. 2008.
[15] J. F. Hübner, O. Boissier, R. Kitio, and A. Ricci, “Instrumenting multi-
organisation specification written in MOISE OML into a agent organisations with organisational artifacts and agents: “giving
normative program that can be interpreted by an artifact based the organisational power back to the agents”,” Journal of Autonomous
OMI. Focusing on the translation instead of Java coding, Agents and Multi-Agent Systems, 2009.
[16] A. Ricci, M. Piunti, M. Viroli, and A. Omicini, “Environment program-
we have brought flexibility to the development of the OMI. ming in CArtAgO,” in Multi-Agent Programming: Languages, Tools
We also stressed the point that such a normative language and Applications, R. H. Bordini, M. Dastani, J. Dix, and A. El Fal-
can be based on only two basic concepts: regimentation and lah Seghrouchni, Eds. Springer, 2009, ch. 8, pp. 259–288.
[17] V. T. da Silva, “From the specification to the implementation of norms:
obligation. Prohibitions are considered either as regimentation an automatic approach to generate rules from norm to govern the
or as an obligation for someone else. The resulting NPL is thus behaviour of agents,” Journal of Autonomous Agents and Multi-Agent
simpler to formalise (only 6 rules in operational semantics) Systems, vol. 17, no. 1, pp. 113–155, Aug 2008.
and implement. Future work will explore NPL translations for
other organisational and institutional languages. We also plan
to prove correctness of the translation from OML into NOPL
in future work.
R EFERENCES
[1] O. Boissier, J. F. Hübner, and J. S. Sichman, “Organization oriented pro-
gramming from closed to open organizations,” in Engineering Societies
in the Agents World VII (ESAW 06), ser. LNCS, G. O’Hare, M. O’Grady,
O. Dikenelli, and A. Ricci, Eds., vol. 4457. Springer, 2007, pp. 86–105.
[2] M. Esteva, D. de la Cruz, and C. Sierra, “ISLANDER: an electronic
institutions editor,” in Proc. of the First International Joint Conference
on Autonomous Agents and MultiAgent Systems (AAMAS 2002), ser.
LNAI 1191, C. Castelfranchi and W. L. Johnson, Eds. Springer, 2002,
pp. 1045–1052.
[3] V. Dignum, J. Vazquez-Salceda, and F. Dignum, “OMNI: Introducing
social structure, norms and ontologies into agent organizations,” in Proc.
of the Programming Multi-Agent Systems (ProMAS 2004), ser. LNAI
3346, R. H. Bordini, M. Dastani, J. Dix, and A. El Fallah-Seghrouchni,
Eds. Berlin: Springer, 2004.
[4] J. F. Hübner, J. S. Sichman, and O. Boissier, “Developing organised
multi-agent systems using the MOISE+ model: Programming issues at
the system and agent levels,” International Journal of Agent-Oriented
Software Engineering, vol. 1, no. 3/4, pp. 370–395, 2007.