Specifying Laws in Open Multi-Agent Systems

Specifying Laws in Open Multi-Agent Systems

Rodrigo Paes1, Gustavo Carvalho1, Carlos Lucena1, Paulo Alencar2,Hyggo Almeida3, and Viviane Silva1

1 Puc-Rio,Rio de Janeiro, Brazil

rbp, guga, lucena, [email protected] University of Waterloo,

Waterloo, [email protected]

3 UFCG,Campina Grande, [email protected]

Abstract. Laws have been used to deal with theoretical and practicalissues regarding notions of openness and unpredictably of open multi-agent systems. In order to achieve a higher degree of predictability andconfidence, practical applications of distributed agents need to describethe interaction structure of the system, and this interaction structuremust be regulated. Governing agent interactions can lead to higher de-gree of system trust. This paper uses the notion of interaction laws asabstraction to regulate agents’ interaction. In this paper, we introduce aconceptual model for developing laws in open multi-agent systems. Thismodel is composed of static, dynamic and formal definitions. We alsodepict a declarative language used for supporting the conceptual model.Moreover, we show a software implementation that allows the enforce-ment of laws through the interception of agents’ interaction. Finally, theconceptual model is applied in a case study in the domain of flight tickettrading.

1 Introduction

Laws are rules governing the behavior of a system [1]. Such kind of approachhas gained increasing importance in the field of distributed systems [2, 3]. Thesesystems are frequently composed of components that can enter and leave fromthe system at any time; and they can have been developed using different lan-guages and architectures. In this sense, those systems have much of the featuresattributed to open multi-agent systems (open MAS) [4, 5], and we use the agentabstraction to refer to this sort of distributed system. The global behavior ofopen MAS emerges from the interaction of the agents, and therefore, it is nottotally predictable. Although this kind of emergent behavior is acceptable oreven desirable, in some applications unexpected behavior may lead to systemfaults [6]. It is particularly true in domains such as electronic commerce, supplychain and health care.

2 Rodrigo Paes et al.

To deal with this scenario, distributed software systems are viewed as a set ofcommunicating agents whose interaction is based on precise specifications namedlaws. The conventional approach to implement laws is to hard-code them into allmembers of a multi-agent system. Separating the law from the agents facilitatesthe dynamical change of the distributed system’s behavior, and enables reuse ofexperts’ knowledge.

In this paper, we propose a conceptual model used to specify laws in openmulti-agent systems, where laws [7] are used as abstraction to specify policiesthat regulate the agents’ interactions. This model includes many useful elementsfor regulating the interaction among agents and it also considers time aspectsto specify laws. Moreover, it is introduced to support our approach a softwaremiddleware for governing laws. Such middleware is able to mediate agent’s in-teraction and verify if the interactions are fulfilling the laws. The specificationof laws is performed using a declarative language.

The remainder of this paper is organized as follows. Section 2 describes thelaw governed approach. In Section 3, we present the conceptual model includingits static, dynamic and formal definitions. In Section 3.4, we present a declarativelanguage used for representing the concepts introduced in Section 3. We alsoexplain the software developed to support our approach in Section 4. Section 5illustrates the applicability of this proposal in a case study. Some related worksare discussed in Section 6. Finally, discussions are presented in Section 7.

2 The Law Governed Approach

The law governed approach is used to build open multi-agent systems where acertain degree of control over agents’ behavior is desirable. Although no agree-ment exists on the exact definition of agent, there is a consensus about theimportance of at least two characteristics: agents are autonomous[4] and havesocial ability[5].

Autonomy is the agent’s ability to (i) act without external intervention, (ii)say yes or no in response to another agent request, and (iii) initiate an action self-motivated [8]. Social ability is the ability to interact with other agents throughsome communication language [9]. Governing interactions affects the agent’sautonomy, because it regulates agent’s actions by laws. So, laws can be seen asa boundary that establishes limits for agent’s autonomy.

Laws act as a regulatory system controlling the behavior of agents. In an openMAS, the internal aspects of agents are inaccessible. The only accessible infor-mation about agents is their observable behavior from the exchange of agents’messages.

We argue that a law governed mechanism should intercept those messages,and then, enforce the desired system behavior. This mechanism acts as a medi-ator among agents. This mediator is not necessarily neither one unique entityor centralized. If the mediator is centralized, some degree of scalability can beachieved using a pool of mediators. However, in this case, we still having a uniquepoint of failure. Another solution is to think of mediator as many decentralized

Governing Open Multi-Agent Systems 3

entities that monitor the system execution. In this sense, depending on how me-diators are implemented (centralized or decentralized), higher or lower level ofscalability can be achieved. The mediator idea was already reported, with minorvariations, in a number of publications such as controllers [10], governors [11],and inter agents [12]. The mechanism is responsible for providing the basic com-munication components and the interoperability concerns. It could be necessaryto extend this basic infrastructure to attend system requirements.

Our law governed mechanism life cycle consists of three high-level activities(Figure 1): (i) interception; (ii) enforcement; and (iii) redirection. In the firststage, the mechanism intercepts the messages exchanged between agents. Then,the mechanism interprets the law specifications and check if the message complieswith the laws. If so, the mechanism redirects the message to the real addressee.In this sense, all the observable behavior of agents can be controlled and thelaws can be enforced.

Law EnforcementMechanism

Agent A Agent B

1

2

3

Communication

Interception

Enforcement

Redirection

Fig. 1. Law Governed Interaction Model

3 Conceptual Model

To further discuss the law governed approach, it is necessary to introduce theelements that compose our approach. In this sense, this section aims to providethe conceptual base describing a Structural Model, Dynamic Model, the for-malization of relationships among elements, and an example of a specificationlanguage based on these concepts.

3.1 Structural Model

We propose a conceptual model for laws (Figure 2) and represent it by using theUML notation. This diagram shows the laws elements and their relationships.

The starting point of this model is the LawOrganization element. The LawOr-ganization element is not the multi-agent organization itself; indeed, it representsthe laws of a multi-agent organization. This element contains Scenes, Norms andClocks.

Scenes specify agents and agent roles that may interact while the scene isrunning. By agent, we mean any autonomous, interactive entity that commu-nicates through message exchanges. These agents usually play roles, which is


entrance/creation

TransitionProtocol

Scene Agent Message

-template: String

Clock

-type: String

-tick-period: long

Norm

-owner: Agent or Role

State-type: String

-label: String

Role

LawOrganization

entrance/creation

plays1..*

sends

fromto

message-ref

activeNorms

requiredNorms

0..*

0..*

0..*

0..*

0..*

0..*

1

0..*0..*

1

1 1

0..*

1..*

0..*

Fig. 2. Law Conceptual Model

an abstraction of recurrent agent behavior, linked to an interaction context ina scene. Moreover, scenes are composed of Protocols, Clocks, and Norms. Itmeans that these three elements share a common interaction context throughthe scenes. Every scene specifies one protocol. Because protocols define the in-teraction among the agents, different protocols should be specified in differentscenes.

Protocols represent the interaction patterns between the agents; they de-fine the valid interactions that agents can have. We represent protocols as non-deterministic automatons, where states represent snapshots of the protocol ex-ecution and transitions are the link between the states. Finite automatons havea set of symbols that they are able to process. In the context of protocol spec-ification, those symbols are messages exchanged between the agents, and thesemessages might fire transitions.

Each transition has an attribute called messagePattern. It means that thetransition only fires if the received message matches the specified pattern in theattribute messagePattern.

Norms prescribe how the agents are allowed or must behave and what theirrights are. In other words, they prescribe the permissions, obligations and pro-hibitions of agents. As a consequence of the relationship between norms andtransitions, it is possible to specify which norms must be active for firing a tran-sition. For instance, a transition should only fire if the sender agent has a specificpermission.

Many scenes might compose a law, and each scene defines a specific executioncontext. That context defines scopes where norms, clocks and protocols are valid.It means that active norms are only visible in the context where they werecreated. There are two levels of contexts: organization and scene context. Normsspecified inside the organization context (LawOrganization element) are visibleto all scenes, and norms specified inside a scene are only visible to that scene.

Time Aspect in Laws Time aspects of a system are relevant issues in thecontext of many classes of important systems, such as real-time, simulators,


electronic commerce, and interactive systems. To the best of our knowledge,other law governed approaches [13–15] have not addressed time aspects in lawspecification. We argue that laws must be time sensitive. In other words, althoughan agent may be able to perform an action a1 at time t1, it might not be ableto perform the same action at time t2 (t1 < t2).

Our conceptual model provides the Clock element acting as a timing aspect.The clock element is able to generate events at specific time intervals. For ex-ample, a clock allows the activation of norms after a certain amount of time haselapsed. A transition firing or a norm activation might also activate clocks.

A new clock instance is created each time a clock is activated. It means thatthe clock will start counting the time from that beginning and independentlyof other active clocks. Once activated, a clock can generate clock-tick events ordeactivate itself. Besides, it is allowed to have many simultaneous clocks.

3.2 Dynamic Model

In this section, we describe the behavior of the elements that compose a lawspecification. Events are the basis of the communication among law elements,that is, law elements dynamically relate with other elements through event no-tifications. Basically, we can understand the dynamic of the elements as a chainof causes and consequences, where an event can activate a law element; this lawelement could generate other events and so on. For example, the arrival of amessage activates a transition, which activates a clock, which generates a clocktick, and the clock tick activates a norm. Figure 3 shows all the elements whichare able to generate and sense events.

LawElement

Clock Norm Protocol SceneTransition Message

Eventgenerates/senses

Fig. 3. Event Generators

There is a close relationship between law elements and events. Events aregenerated during the life cycle of law elements.

Clocks generate a clock activation event when the clock starts working; clocktick events when the time specified in the clock specification is elapsed; anddeactivation events when the clock stops working.

Norms also generate activation and deactivation events; however, it is impor-tant to notice that their activation event are norm activation events.


Transitions generate only transition activation events. Transitions are part ofprotocols, and therefore, a transition for a message arrival will only be notifiedif the current protocol execution state reaches the transition. Furthermore, atransition activation event is fired only if two other conditions are satisfied:the message that originated the message arrival event must satisfy the messagepattern; and all the required norms must be enabled.

Scenes generate scene completion events when their protocol reaches a finalstate. If a final state is reached many times during a scene execution, many scenecompletion events are generated.

3.3 Formal Law Structure Definition

Our law governed conceptual framework is formally defined as below. This for-malization is mapped to the XMLaw language in the next section (Section 3.4).For example, the Org element is mapped to the XML tag < LawOrganization >,the Scni is mapped to the XML tag < Scene >, and so on.

– Org = 〈Scn, N〉, where Org stands for organization, Scn is a finite set ofscenes, N is a finite set of norms and C is a finite set of clocks;

– Scni = 〈R,P, C,N, κ, Ag〉, where: Scni ∈ Scn, i ∈ N; R stands for theoperator requires meaning a finite set of all the norms that should be activein order to the scene begin, P stands for protocol, C is a finite set of clocks,N is a finite set of norms, κ is a finite set of roles that interact in this scene,and Ag is a finite set of agents that interact in this scene;

– κi = 〈id〉, where where κi ∈ κ, i ∈ N, and id is a identifier for the role;– Agi = 〈id〉, where Agi ∈ Ag, i ∈ N, and id is a identifier for the agent;– P = 〈S, T 〉, where S is a set of states and T is a set of transitions;– Si, where Si ∈ S, and i ∈ N;– Ti = 〈F, D, τ, A〉, where Ti ∈ T , i ∈ N, F stands for source state, D stands

for destination state, F ∈ S, D ∈ S, τ is a message template, and A is a setof norms that must be active;

– Ci = 〈δ, π, α, θ〉, where Ci ∈ C, i ∈ N, δ stands for clock type, π stands forclock period, α represents the events that activate the clock, and θ are theevents that deactivate the clock;

– Ai = 〈ρ〉, where Ai ∈ A, i ∈ N, and ρ stands for references to norms;– Ri = 〈ρ〉, where Ri ∈ R, i ∈ N, and ρ stands for references to norms;– Ni = 〈Θ, Γ,Ω〉, where Ni ∈ N , i ∈ N, Θ stands for a finite set of obligations,

Γ stands for a finite set of permissions, and Ω stands for a finite set ofprohibitions;

– Θi = 〈α, ξ〉, where Θi ∈ Θ, i ∈ N, α represents a finite set of elements thatactivate the obligation, and ξ is a finite set of events that deactivate theobligation;

– Γi = 〈α, ξ〉, where Γi ∈ Γ , i ∈ N, α represents a finite set of elements thatactivate the permission, and ξ is a finite set of events that deactivate thepermission;


– Ωi = 〈α, ξ〉, where Ωi ∈ Ω, i ∈ N, α represents a finite set of elements thatactivate the prohibition, and ξ is a finite set of events that deactivate theprohibition;

– E = 〈name〉, where E stands for event, and name is the name which identifiesthe event.

3.4 Textual Law Representation: XMLaw

Based on our conceptual model and on its formal definition, we developed adeclarative language for law specification. That language is based on XML. Inthis section, we explain the main elements of the language and provide someexplanations and comments on how to use them.

LawOrganization : the laws of an organization are specified inside the LawOr-ganization element. The id attribute is used to uniquely identify this element.The name attribute allows humans to identify the organization more easily be-cause it is a description. Furthermore, the organization has the Scenes elementthat represents all the possible scenes of an organization, as well as the set ofnorms.

1 <LawOrganization id=”anOrgId”2 name=”Organizat ion name”/>3 <Scenes> . . . </Scenes>4 <Norms> . . . </Norms>5 <Clocks> . . . </Clocks>6 </LawOrganization>

1 <Scene id=” nego t i a t i on ”>2 <Requires>3 <!− Al l the norms that must be a c t i v e in order4 to s t a r t the execut ion o f t h i s scene −−>5 </Requires>6 <Messages>7 < !−− Al l po s s i b l e messages pat terns −−>8 </Messages>9 <Protoco l>

10 <!−The i n t e r a c t i o n pro toco l f o r t h i s scene −−>11 </ Protoco l>12 <Clocks>13 <!−Al l the c l o ck s f o r t h i s scene −−>14 </Clocks>15 <Norms>16 < !−− Al l the norms for t h i s scene −−>17 </Norms>18 </Scene>


Requires : the Requires element contains a reference to some norms specifiedinside the Norms element in the organization. It does not make sense to use areference to some norm inside the scene itself because the Requires element is aprecondition to start the scene execution, but if the norm belongs to the Normselement inside the scene specification, the norm can be only activated during thescene execution. Therefore, the scene will never start.

1 <Requires>2 <Norm r e f=”aNormRef”/>3 </Requires>

Messages : the Messages element specifies all the templates of messages usedin the scene. This template comprises the fields performative; sender, whichspecifies both the agent that is sending the message and its respective role;receiver, which defines both the addressee agent and its role; and finally thecontent of the message being transmitted. The protocols use these templates tospecify transitions.

1 <Messages>2 <Message id=”aMessageId”3 template=”message ( per format ive , sender (Sname , S ro l e ) ,4 r e c e i v e r (RName, RRole ) , content ( Content ) ) . ”/>5 </Messages>

Protocol : the Protocol element is a type of non-deterministic automaton, andit is composed of only two attributes: a set of states and a set of transitions.

1 <Protoco l>2 <State s> . . . </ Sta te s>3 <Trans i t i on s> . . . </ Trans i t i on s>4 </ Protoco l>

State : the id attribute allows the law developer to make references to the state.In this way, transitions can connect one state to another. Moreover, a state hasa label and can be the initial or the final state of the protocol.

1 <State id=” anStateId ” i n i t i a l=” true ”2 f i n a l=” f a l s e ” l a b e l=”A s t a t e l a b e l ”/>


Transition : transitions connect two states. A transition is activated when theprotocol is at the state from and if a message that matches the pattern specifiedby aMessageId arrives. It is important to notice that the attributes from and toare references to states specified in the States element, and the message-ref isalso a reference to a message pattern specified in the Messages element.

Furthermore, transitions can also have the ActiveNorms element representingall the norms that must be active in order to the transition been activated.

1 <Trans i t i on id=”anId” from=”anStateId ”2 to=” anotherState Id ” message−r e f=”aMessageId”>3 <ActiveNorms>4 <Norm r e f=”aNormId”/>5 </ActiveNorms>6 </ Trans i t i on>

Clock : clocks can be of two types- regular or periodic. Regular means thatit will generate only one clock-tick after a tick-period of milliseconds have beenelapsed. Periodic clocks generate clock-ticks at the interval specified at the tick-period attribute. Clocks are activated and deactivated by law elements. TheActivation and Deactivation elements represent these activations and deactiva-tion conditions. They both have reference to other law elements, and they havetwo attributes: ref and event-type. The ref is a reference to an id attribute andthe event-type is the type of event generated by the referenced element. It isnecessary because some elements generate more than one type of event, then;with the event type attribute it is possible to specify exactly what event shouldstart the clock.

1 <Clock id=”aClockId ” type=” r egu l a r ” t i ck−per iod=”1000”>2 <Act iva t i ons>3 <Element r e f=”anId” event−type=”anEventType”/>4 </ Act iva t i ons>5 <Deact iva t i ons>6 <Element r e f=” other Id ” event−type=”anEventType”/>7 </ Deact iva t i ons>8 </Clock>

Norm : norms can contain three types of elements - Permission, Obligation andProhibition. In the presented language, the structure of these three elements isequal. Each type of norm contains activation and deactivation conditions. Theseconditions have the same semantic of the clock’s conditions.

1 <Norms>2 <Permiss ion id=” aPermiss ionId ”>3 <Act iva t i ons>4 <Element r e f=”anId” event−type=”anEventType”/>5 </ Act iva t i ons>6 <Deact iva t i ons>7 <Element r e f=” anotherId ” event−type=”anEventType”/>8 </ Deact iva t i ons>9 </Permiss ion>

10 <Obl igat ion id=” anObl igat ionId ”> . . . </ Obl igat ion>11 <Proh ib i t i on id=” aProh ib i t i on Id ”> . . . </ Proh ib i t i on>12 </Norms>


4 Software Support

Development of multi-agent systems requires appropriated techniques, modelsand tools [16]. Tools, in particular, play an important role in the developmentscenario helping to build multi-agent systems faster and less error prone. Recog-nizing the importance of these aspects, we developed an object-oriented frame-work and a monitoring tool supporting the law governed approach.

In the proposed framework, agent developers have access to the API (Ap-plication Program Interface) for Law Governed which provides a basic agentcommunication component and other facilities. They can use this API to createtheir agents and interact with the law governed mechanism. Law developers canextend our framework to adapt it to their needs.

Each message format must have a message pattern recognizer associated withit. Declaration of message patterns is necessary for protocol specification. Ourframework provides a prolog like message pattern. It means that agents caninteract with each other using prolog as the content language.

Another framework’s hotspot is the communication mechanism. Currently, itis offered a default implementation for the communication this hot-spot based onthe Jade platform [17]. In this way, the Jade platform is used just as a messagetransport layer among the agents. However, developers are also free to use anyother communication infrastructure, implementing the communication interfaceprovided by the framework.

A monitoring tool provides graphical support for monitoring of laws’ execu-tion. In this tool, it is possible to visualize all the scenes in execution, whichnorms and clocks are active, and also what is the current protocol execution’sstate.

5 Case Study

Nowadays large airports do more than just serving as a place for airplanes land-ing and taking off. Aiming to increase the customer satisfaction, the fictitiousairport of this case study provides an Internet based system where users canbuy flight tickets. This system is based on an auction mechanism, and the air-line companies placed in the airport dependencies integrate their own systemsto it. The airport system should provide a good level of trust in the sense thatthe costumers should be protected against malicious behavior of airline com-panies and airline companies should be also protected against malicious users.However, the airline companies’ systems are not available to the airport devel-opment team, and therefore, they cannot blindly trust in the airline companiessystems’ behavior.

In this example, the whole process consists of three stages: negotiation, pay-ment, and ticket emission. First, the customer exposes its flight preferences, suchas destination and cabin type, and waits for the airline company’s bids. Afterthat, the costumer chooses one of the bids. The second stage starts when thenegotiation stage ends. The costumer should follow the required procedures and


carry the payment out. In the last stage, the airline company emits an electronicflight ticket to the costumer.

5.1 Applying the Conceptual Model

According to the scenario description, we can identify two participant roles: cus-tomer and airline company. During the negotiation, customers may get irritatedif the airline companies take too long for providing their bids. In that way, wepropose that 10 seconds is the maximum time for airline companies proposingtheir bids.

Furthermore, if an airline company is negotiating a flight ticket with a cus-tomer, then it cannot sell the same ticket for another costumer. On the otherhand, the airline companies can also have financial losses in cases where the usertakes too long to choose among the bids, so, the user should also have a time-outto decide, for instance, 5 minutes.

In this case study, we have a negotiation phase, a payment phase and weconclude the process with a ticket emission phase. Each phase corresponds to ascene.

Each scene is analyzed and designed. We have made two simplifications on theproblem. First, it is described only part of the negotiation scene, and second, it isconsidered the negotiation process between one agent and one airline company.

The scene begins when a costumer sends a request of flight ticket proposalto the airline company through a request message. In this point, the airlinecompany has to answer within 10 seconds; otherwise, the costumer can senda cancel message and leaves the scene. Once the airline company accepted therequest on time, the customer has 5 minutes to decide about, and to send anaccept-proposal or a reject-proposal message. After that, the airline companyinforms if the sale was well succeed or if some problem happened. That sequenceof interaction is the basis of the protocol element.

We specify this protocol using declarative law language (Listing 1.1). In theline 1, we specify the organization element. The line 2 delimits the beginning ofthe negotiation scene specification. This scene contains a protocol specification(lines 07 to 21). This protocol contains three states (lines 08 to 12) and twotransitions (lines 13 to 20). The transition t1 links the states s0 and s1 and it isactivated by the request message, specified in the line 4.

When this transition is activated, the clock specified in the line 23 is alsoactivated. This occurs because the activation attribute in the line 25 has a ref-erence to the transition t1. This clock addresses the non-functional requirementresponse-time-1. It counts 10 seconds and fires a clock-tick event. The permis-sion cancel-request (line 30) has specified in its activation condition (line 32)that clock-ticks events originated by the clock The response-time-1 activate thistransition. The transition t2 (line 15) links the state s1 to the state s3, andit is activated by the cancel message - m2 (line 5). However, the norm cancel-request must be active for enabling this transition (line 17). Although we do notspecify the whole scene, the remaining specification is similar to the providedspecification.


The execution of the laws is monitored and this monitoring helps to achievea better understanding of the system. For instance, in this case study, the moni-toring can identify that many customers take more than the specified 5 minutesto decide about the bid. This might indicate that the initial time is not sufficientor that the customers are having difficulties to use the system.

1 <LawOrganization id=”Org−t i c k e t−s a l e s ” name=”Ticket s a l e s ”>2 <Scene id=” nego t i a t i on ”>3 <Messages>4 <Message id=”m1” template=”message ( request , sender (SName , SRole ) ,

r e c e i v e r (RName, RRole ) , content ( Content ) ) . ”/>5 <Message id=”m2” template=”message ( cance l , sender (SName , SRole ) ,

r e c e i v e r (RName, RRole ) , content ( Content ) ) . ”/>6 </Messages>7 <Protoco l>8 <State s>9 <State id=” s0 ” i n i t i a l=” true ” f i n a l=” f a l s e ” l a b e l=” I n i t i a l S t a t e ”

/>10 <State id=” s1 ” i n i t i a l=” f a l s e ” f i n a l=” f a l s e ” l a b e l=”MessageSent”

/>11 <State id=” s3 ” i n i t i a l=” f a l s e ” f i n a l=” true ” l a b e l=”

SceneCance l led ”/>12 </ Sta te s>13 <Trans i t i on s>14 <Trans i t i on id=” t1 ” from=” s0 ” to=” s1 ” message−r e f=”m1”/>15 <Trans i t i on id=” t2 ” from=” s1 ” to=” s3 ” message−r e f=”m2”>16 <ActiveNorms>17 <Norm r e f=” cance l−r eques t ”/>18 </ActiveNorms>19 </ Trans i t i on>20 </ Trans i t i on s>21 </ Protoco l>22 <Clocks>23 <Clock id=” response−time−1” type=” r egu l a r ” t i ck−per iod=”5000”>24 <Act iva t i ons>25 <Element r e f=” t1 ” event−type=” t r a n s i t i o n a c t i v a t i o n ”/>26 </ Act iva t i ons>27 </Clock>28 </Clocks>29 <Norms>30 <Permiss ion id=” cance l−r eques t ”>31 <Act iva t i ons>32 <Element r e f=” response−time−1” event−type=” c l o c k t i c k ”/>33 </ Act iva t i ons>34 </Permiss ion>35 </Norms>36 </Scene>37 </LawOrganization>

Listing 1.1. Law Description

6 Related Work

In Esteva [11] approach, scenes are similar to the protocol elements proposedin this paper. Both Esteva scenes and protocol elements specify the interactionprotocol using a global view of the interaction. It means that all the interactionamong the agents is specified in only one protocol in opposite to individual agentviews, where many partial views of the protocol (one of each agent) are specified.The time aspect is represented in Esteva approach as timeouts. Timeouts allow


activating transitions after a given number of time units passed since a state wasreached. On the other hand, due to our event model, the clock element proposedin this paper can both activate and deactivate not only transitions, but alsoother clocks and norms. Connecting clocks to norms allows a more expressivenormative behavior; norms become time sensitive elements.

OMNI [18] is a framework for modeling agent organizations. This frame-work is composed of three dimensions: normative, organizational and ontolog-ical. These dimensions aim to cover from analysis to implementation of agentorganizations. In the normative dimension, developers specify the mechanismsof social order, in terms of common norms and rules, which members are ex-pected to adhere to. The organizational dimension describes the structure ofan organization. The ontological dimension defines environment and contextualrelations and communication aspects in organizations. In addition, each one ofthese dimensions can be viewed in three abstraction levels: abstract, concreteand implementation. In the abstract level, the general organization goals are de-fined in a high level of abstraction. It also contains the definition of the ontologyof the model itself. Based on the abstract level, norms, rules, roles, interactionprotocols and concrete ontological concepts are defined. The implementationlevel assumes a given multi-agent architecture as basis for the implementationof the organizational model, and also mechanisms for role enactment and normenforcement.

Minsky [19, 20] proposes a coordination and control mechanism called lawgoverned interaction (LGI). This mechanism is based in two basic principles:the local nature of the LGI laws and a decentralization of law enforcement.The local nature of LGI laws means that a law can regulate explicitly onlylocal events at individual home agents, where home agent is the agent beingregulated by the laws; the ruling for an event e can depend only on e itself,and on the local home agent’s context; and the ruling for an event can mandateonly local operations to be carried out at the home agent. On the other hand,the decentralization of law enforcement is an architectural decision argued asnecessary for achieving scalability. Furthermore, it provides a language to specifylaws and it is concerned with architectural decisions to achieve a high degree ofrobustness. In contrast, our approach provides a explicit conceptual model andfocuses on different concepts such as Scenes, Norms and Clocks.

7 Conclusion

In this paper, we presented a conceptual model for specifying laws in open MAS.This model includes static, dynamic and formal definitions and integrates con-cepts of norms, interaction protocols, and time, using a flexible event baseddynamical model. We also presented a declarative language, XMLaw, used forsupporting the conceptual model. XMLaw is based on XML and was designedto be simple and even expressive. We briefly described a software implementa-tion that allows the use of laws through the interception of agents’ interaction.Finally, the approach was exemplified through a case study.


The identification of a group of static definitions permits the discussion ofconcepts regarding their structural semantics and their relationships. The iden-tification of events as dynamic elements has facilitated the integration of staticconcepts, because events reify the relationships described in the structural defin-itions. However, we know that this conceptual model is still under construction.We aim to improve this version by implementing more experiments and by re-flecting elements gathered from other related work.

Despite the contributions of this work, there are many further research topicssuch as role assignment [21], and the integration of deliberative normative agentarchitectures [22] with our approach. The former is concerned with which agentis able to play certain organizational roles, and when they can play the role. Inthis paper, it is assumed that roles were already assigned and the informationrelated to the agent role contained in the messages is trustful.

A future work is the development of tools that help the specification andvalidation of laws in a graphical way. Furthermore, a proposal to improve thisapproach by dealing with laws in different abstraction levels is under develop-ment. Besides, we are researching how to represent this conceptual model usingan approach based on ontology to easier the interpretation of laws by softwareagents. Another important issue that we are researching is the relation betweenlaws and contracts.

We claim that the proposed approach is suitable to deal with the unpre-dictability of open systems by taming agents’ autonomy through the enforcementof interaction laws.

References

1. Sloman, M.: Policy driven management for distributed systems. J. Networks Syst.Manage. 2 (1994)

2. Ao, X., Minsky, N., Nguyen, T.D.: Hierarchical policy specification language, andenforcement mechanism, for governing digital enterprises. In: 3rd InternationalWorkshop on Policies for Distributed Systems and Networks (POLICY’02). (2002)

3. Feeney, K.C., Lewis, D., Wade, V.P.: Policy based management for internet com-munities. In: POLICY ’04: Proceedings of the 5th International Workshop onPolicies for Distributed Systems and Networks (POLICY’04), IEEE Computer So-ciety (2004)

4. Jennings, N.R.: Agent-Oriented Software Engineering. In: Proceedings of the 9thEuropean Workshop on Modelling Autonomous Agents in a Multi-Agent World.Volume 1647., Springer-Verlag (1999) 1–7

5. Woolridge, M.: Introduction to Multiagent Systems. John Wiley & Sons, Inc.(2001)

6. Sommerville, I.: Software Engineering. 7 edn. Addison-Wesley (2004)7. Jones, A.J., Sergot, M.: On the characterisation of law and computer systems:

The normative systems perspective. In Meyer, J.J., Wieringa, R., eds.: DeonticLogic in Computer Science: Normative System Specification. John Wiley andSons, Chicester (1993) 275–307

8. Huhns, M.N., Singh, M.P.: Agents and multiagent systems: Themes, approaches,and challenges. In Huhns, M.N., Singh, M.P., eds.: Readings in Agents. MorganKaufmann (1997) 1–23


9. Wooldridge, M.J., Jennings, N.R.: Intelligent agents: Theory and practice. TheKnowledge Engineering Review 10 (1995) 115–152

10. Murata, T., Minsky, N.H.: On monitoring and steering in large-scale multi-agentsystems. In: Selmas’03 2nd International Workshop on Software Engineering forLarge-Scale Multi-Agent Systems, Portland, Oregon (2003)

11. Esteva, M.: Electronic Institutions: from specification to development. PhD thesis,Institut d’Investigaci en Intel.ligncia Artificial, Catalonia - Spain (2003)

12. Martn, F.J., Plaza, E., Rodriguez-Aguilar, J.A.: An infrastructure for agent-basedsystems: an interagent approach. International Journal of Intelligent Systems (IJIS)(1999) 217–240

13. Castelfranchi, C., Dignum, F., Jonker, C.M., Treur, J.: Deliberative normativeagents: Principles and architecture. In: Agent Theories, Architectures, and Lan-guages. (1999) 364–378

14. Dignum, F.: Abstract norms and electronic institutions. In: Proceedings of In-ternational Workshop on Regulated Agent-Based Social Systems: Theories andApplications (RASTA’02), at AAMAS, Bologna, Italy (2002)

15. Vazquez-Salceda, J., Dignum, F.: Modelling electronic organizations. In: Multi-Agent Systems and Applications III. Springer Verlag, Berlim (2003)

16. Choren, R., Garcia, A., Lucena, C., Griss, M., Kung, D., Minsky, N., Romanovsky,A., Castro, J., de Lemos, R., Weyns, D.: Software engineering for large-scale multi-agent systems - selmas 2004: workshop report. SIGSOFT Softw. Eng. Notes 29(2004) 1–10

17. Bellifemine, F., Poggi, A., Rimassa, G.: Jade: a fipa2000 compliant agent de-velopment environment. In: Proceedings of the fifth international conference onAutonomous agents, ACM Press (2001) 216–217

18. Vzquez-Salceda, J., Dignum, V., Dignum, F.: Organizing multiagent systems. Tech-nical report, Institute of Information & Computing Sciences (2004)

19. Minsky, N.H., Murata, T.: On manageability and robustness of open multi-agentsystems. In Lucena, C., Garcia, A., Romanovsky, A., Castro, J., Alencar, P., eds.:Software Engineering for Multi-Agent Systems II: Research Issues and PracticalApplication. Volume 2940/2004. Springer-Verlag Heidelberg (2004) 189–206

20. Minsky, N.H., Ungureanu, V.: Law-governed interaction: a coordination and con-trol mechanism for heterogeneous distributed systems. ACM Trans. Softw. Eng.Methodol. 9 (2000) 273–305

21. Dastani, M., Dignum, V., Dignum, F.: Role-assignment in open agent societies.In: Proceedings of the second international joint conference on Autonomous agentsand multiagent systems, ACM Press (2003) 489–496

22. Kollingbaum, M.J., Norman, T.J.: Norm adoption in the noa agent architecture.In: Proceedings of the second international joint conference on Autonomous agentsand multiagent systems, ACM Press (2003) 1038–1039

Specifying Laws in Open Multi-Agent Systems

Documents

Transcript of Specifying Laws in Open Multi-Agent Systems