RPI.Social: Simple Enactment and Execution of First-Class Agent

Interaction Protocols

Atef Nouri and Wided Lejouad Chaari

Laboratoire COSMOS, ENSI, University of La Manouba, 2010 La Manouba, Tunisia

Keywords:

First-Class Agent Interaction Protocols, Multiagent Systems, Executable Interaction Protocols, Role Enact-

ment, Agent-Oriented Software Engineering.

Abstract:

In Multiagent systems, ﬁrst-class interaction protocols are those whose implementations are decoupled from

the agents. A previous work has introduced the RPI framework (Role Playing Interactions) and established the

contribution of RPI.Idiom which is a high-level language for the deﬁnition of such protocols. In this paper, we

present RPI.Social which is a social engine associated with the agent to help it use interaction protocols written

in RPI.Idiom. RPI.Social has two components: RPI.Social.IoP (for Initiate or Play) and RPI.Social.Exec. The

ﬁrst component deals with discovering and initiating interaction protocols for an agent which has a goal that

could only be pursued through interacting. The same component is also used by agents invited for interaction

to decide whether to participate or to decline the invitation. The second component serves as an interpreter of

interaction protocols with several mechanisms and rules to coordinate and share results amongst the interacting

agents. The main contribution of this paper is a solution for agents to automatically identify and execute ﬁrst-

class interaction protocols.

1 INTRODUCTION

Multiagent systems (MAS) have two deﬁning core

concepts: agents and interactions. Despite the equal

importance they both share in the deﬁnition of MAS,

the focus has always been put on agents. Indeed, re-

search on interactions has previously dealt with com-

munication languages, documentation (e.g. negoti-

ation protocols) (Miller and McBurney, 2007) and

the game theoretical aspect of interaction protocols

(Shoham and Leyton-Brown, 2008), etc. In contrast,

agents have been studied as single autonomous ob-

jects (mobility, BDI, etc.) and as interacting enti-

ties (institutions (Morales et al., 2017), organizations

(Jensen, 2015), roles, etc.). As a result, over the years,

agents have become more capable at performing in

their environments while interaction protocols grew

more diverse. Nevertheless, as part of the effort to

efﬁciently document interaction protocols, there have

been several works that have dealt with the abstrac-

tion of interactions. These efforts started with early

MAS methodologies and design formalisms, notably

AUML (Bauer et al., 2000). The aim of these works

was to decouple interactions and agents at design

time. Some works in the last decade took the decou-

pling to the implementation phase so that the inter-

action’s code is no longer intertwined with the inter-

acting agents’. Such interactions are interchangeably

called reiﬁed (Khalfaoui and Chaari, 2013) and ﬁrst-

class (Miller and McBurney, 2007).

As easy as specifying an interaction protocol

amongst abstract roles using some notation could be,

the actual interpretation of such speciﬁcation hides

some tedious tasks that have to be performed by the

interacting agents. In fact, in the case of second-class

interactions, agents know by design the course of ac-

tion that has to be taken and the execution is automat-

ically based on little to no deliberation on the actual

content of the interaction i.e. the agent trusts that its

programmer:

• has taken care of checking the preconditions and

the postconditions of the interaction; and

• made sure that the goal for which the interaction is

executed in the ﬁrst place would be possibly ful-

ﬁlled by the end of the exchange.

On the other hand, agents interacting using ﬁrst-class

interaction protocols need to have the capabilities to:

• match their goals for interacting with the end re-

sult of the interaction protocol;

• initiate an interaction protocol or take a role in

one;

Nouri, A. and Chaari, W.

RPI.Social: Simple Enactment and Execution of First-Class Agent Interaction Protocols.

DOI: 10.5220/0006599400910102

In Proceedings of the 10th International Conference on Agents and Artiﬁcial Intelligence (ICAART 2018) - Volume 1, pages 91-102

ISBN: 978-989-758-275-2

• enact roles in protocols;

• execute the operations assigned to their roles.

In order to provide the aforementioned capabili-

ties to agents, we propose RPI.Social, a social engine

associated with the agent to endow it with the abil-

ity to take roles in the execution of interaction proto-

cols. A previous work (Nouri et al., 2015) has intro-

duced RPI.Idiom which is a high-level language for

implementing ﬁrst-class interaction protocols within

a framework baptized Role Playing Interactions (or

RPI). Along with the descriptive language, RPI pro-

vides through RPI.Social mechanisms for the agents

to be able to reason on interaction protocols and exe-

cute them.

The purpose of this paper is to introduce

RPI.Social and give an overview on its inner work-

ings. The present paper does not attempt to demon-

strate the properties of RPI.Idiom interaction proto-

cols that are enumerated in Section 2.2 since the lan-

guage was fairly presented in (Nouri et al., 2015).

Likewise, RPI.Inference is not covered by this paper.

The rest of this paper is organized as follows.

Section 2 is a brief introduction of RPI framework.

RPI.Social.IoP, the unit used for enacting interactions

and roles is detailed in Section 3. RPI.Social.Exec is

presented in Section 4. Section 5 gives an overview

on RPI.Inference. Section 6 is an exposition of some

related works with comparisons that aim to position

RPI.Social in the literature and highlight its contribu-

tion. Section 7 is the conclusion.

2 RPI FRAMEWORK

This Section gives an overview of the features and

aims of the RPI framework and its components.

2.1 RPI Framework Overview

The Role Playing Interactions framework proposes an

approach to separate interaction protocols from the

agents. The goal of RPI is to provide a common envi-

ronment for implementing and executing interaction

protocols that have these properties:

• To be role-based i.e. to be deﬁned between a set of

abstracting roles instead of the actual interacting

agents.

• To be automatically enactable and executable i.e.

agents should be self-sufﬁcient in enacting roles

in the interaction protocol and in executing their

parts in it.

• To have a generic structure i.e. the unit of con-

struction of the interaction is a behaviour which

covers the actions of transmission and reception

of messages, as well as any action or service that

the underlying agent could perform or provide.

• To have a meaning and to be socially generic

i.e. each unit of construction has its own ex-

plicit meaning. The meanings attributed to the

construction units are independent from the social

prescriptions (e.g. commitments) which deﬁnes

the property of social genericity.

• To be modular in order to support the reuse and

the potential composition of protocols.

Similarly, an agent within the RPI environment has a

set of properties:

• Its implementation excludes interactions and ex-

plicit references to external implementations of

interaction protocols.

• It has a set of state variables and another one for

social behaviours that both are exposed to other

agents to the roles played in interactions.

• At a given moment during runtime, it may have a

goal which is expressed in the same language as

the constraints in RPI.Idiom (see 2.2). To fulﬁll

its goal, the agent either takes individual actions

or it starts interaction.

• It has a social engine that manages the whole pro-

cess of interacting with other agents. The social

engine which is speciﬁed by RPI is a deﬁning part

of an agent within the framework.

RPI is divided into several component sub-

systems that achieve a part of the functionalities pro-

vided by the framework (Fig. 1).

The central sub-system of the framework is

RPI.Idiom which is the language for deﬁning inter-

action protocols. Section 2.2 gives a quick overview

of the language and its main features.

RPI.Idiom interaction protocols are managed by

RPI.Library. This sub-system provides the developer

with a tool for managing the repository of protocols.

It also plays the role of interaction protocols broker to

the agents within the framework.

The RPI.Social sub-system is the social engine as-

sociated with an agent. This sub-system has two com-

ponent units:

• RPI.Social.IoP for initiating interactions and/or

playing roles in them; and

• RPI.Social.Exec for performing behaviours asso-

ciated with the agent’s role within an interaction

protocol.

The features of RPI.Social are detailed in Section

3 and 4.

ICAART 2018 - 10th International Conference on Agents and Artiﬁcial Intelligence

Figure 1: Interdependence within RPI.

RPI.Inference is the sub-system responsible for

providing the tools to RPI.Social to reason on inter-

action protocols to decide whether to pick the proto-

col to achieve a given goal, or if a behaviour is well-

executed during an interaction. An overview of the

tools RPI.Inference provides is given in Section 5.

2.2 RPI.Idiom Overview

RPI.Idiom is a high-level language for implementing

ﬁrst-class interaction protocols. Protocols speciﬁed

in RPI.Idiom verify the properties of the RPI frame-

work mentioned in the previous Section (2.1). An

RPI.Idiom interaction protocol has two parts:

• a data template in which the data and the roles

relevant to the interaction are declared; and

• a process template that deﬁnes the actual interac-

tion in terms of behaviours.

As Fig. 3 shows, the process template which is

the part that speciﬁes the interaction protocol is de-

ﬁned by a premises system and a move. The former

is basically a declaration of the predicates and the ax-

ioms using them that would be used in the latter. The

move is the actual process that speciﬁes how the in-

teraction would be executed. A move has two con-

straints: one to denote its precondition and the second

for its postcondition. These constraints are expressed

using the predicates declared in the premises system.

A constraint is a ground formula that could be atomic

(i.e. a literal) or composite (i.e. a conjunction or a

disjunction of ground formulas). The move could be

atomic or composite, where the latter is deﬁned as a

composition of moves.

There are four composition operators to combine

moves:

• and-seq(M): a sequence of sub-moves M;

• and-con(M): a set of concurrent sub-moves M;

• xor(M): a choice of exactly one sub-move from

M; and

• or(M): a subset of concurrent sub-moves from M,

or -alternatively- a subset choice.

The constraints of the combined moves are also

composed using the following rules:

• for xor and or operators, the constraints of the

move are the disjunction of the respective con-

straints of the underlying sub-moves;

• for and-con operator, the constraints of the com-

posite move are the conjunction of the respective

constraints of the underlying sub-moves; and

• for and-seq operator, the constraints of the com-

posite move are the conjunction of the respective

constraints of the sub-moves after eliminating the

inconsistent constraints, i.e. only the initial pre-

conditions and the ﬁnal postconditions are kept.

An atomic move, on the other hand, is deﬁned by

an instance of a behaviour belonging to a role, the

sets of inputs and outcomes, and the usual constraints

for the move. The precondition of the atomic move

acts as a ﬁlter on the inputs while its postcondition

speciﬁes the effect of performing the behaviour on the

outcomes.

RPI.Social: Simple Enactment and Execution of First-Class Agent Interaction Protocols

Figure 2: Structure of the data template in RPI.Idiom.

A role is deﬁned by a data set that tracks its state

during the interaction and a set of behaviours that the

role player should be able to perform. The declara-

tion of the set of roles that would be placeholders for

the interacting agents within an RPI.Idiom protocol

is done in the data template. As shown in Fig. 2,

this part of an RPI.Idiom interaction protocol speciﬁ-

cation also contains the declaration of two data sets.

The ﬁrst is the environment data set which contains

the bare necessary knowledge about the environment

for the interaction protocol while the second is the lo-

cal data set which contains temporary knowledge for

the span of the interaction. The elements of three data

sets (roles’ states, environment’s, local’s) are used as

inputs and outcomes for the behaviour instances that

represent the atomic moves in the protocol.

3 RPI.Social.IoP: ENACTMENT OF

INTERACTION PROTOCOLS

AND ROLES

In the previous Section, we gave a glimpse of

RPI.Idiom, the language to use for the speciﬁcation

of interaction protocols in RPI. RPI.Idiom is consid-

ered to be the static dimension of interactions in the

framework. The dynamic dimension is ensured by

both units of RPI.Social. This Section puts the focus

on RPI.Social.IoP (Initiate or Play) that is the ﬁrst of

these two units. RPI.Social.IoP is basically an interac-

tion that transcends RPI which purpose is to bootstrap

RPI interaction protocols.

RPI.Social.IoP has two complementary protocols:

an active one for initiating interactions and a passive

one for receiving and responding to invitations to play

roles in interactions. In each of the protocols, the so-

cial engine of the agent is in one of a given set of

states at all times. Transitions between states are de-

ﬁned by events such as receivinga notiﬁcation or data,

or reaching a milestone in the enactment of the inter-

action protocol. A transition usually triggers an al-

gorithm executed by the social engine of the agent to

advance the enactment of the interaction protocol.

The intuition behind RPI.Social.IoP is the need for

establishing an ad-hoc agent organization for the in-

teraction protocol since an RPI interaction requires

permanent agents for its span. This way, the mem-

bers of the organization should play the roles in the

interaction. This is similar to the TCP connection

establishment through the three-way handshake pro-

cess. Due to that similarity, we represent the state-

transition aspect of RPI.Social.IoP as a ﬁnite state ma-

chine (FSM). Fig. 4 depicts the state machine for an

initiator agent. Likewise, Fig. 5 is the state machine

for a non-initiator agent. A second aspect of the unit

is algorithmic and it deﬁnes the behaviour of the agent

in a given state (e.g. in the Idle state, the agent awaits

for a triggering event to happen as seen in the state

machines).

3.1 Social Engine States in

RPI.Social.IoP

The social engine of an agent could be in one of eight

states. One of those states is the initial state called In-

valid (denoted by the solid ﬁlled circle in Fig. 4 and

Fig. 5). It is a temporary state in which the agent

is being initialized and is consequently not ready for

interacting. As soon as the initialization is properly

done, the social engine of the agent transits automati-

cally and irreversibly from Invalid to Idle. The other

six states are Fetching, Waiting Response, Waiting Ap-

proval, Starting Interaction, Idle Interaction and Busy

Interaction.

In the Idle state the social engine is neither at-

tempting to enact a role nor executing an interaction

protocol. In the case when the agent comes across a

goal that could not be attained but through interact-

ing, the social engine turns to the Fetching state and

starts searching for an interaction protocol that helps

it fulﬁll that goal. If no sufﬁcient interaction protocol

is found, the social engine rolls back to the Idle state.

However, if a candidate interaction protocol is found,

ICAART 2018 - 10th International Conference on Agents and Artiﬁcial Intelligence

Figure 3: Structure of the process template in RPI.Idiom.

an invitation to play a role in that particular protocol is

sent to a set of agents that could be selected based on

one or more criteria like proximity, etc. The invitation

takes the form of a PROPOSE message embedding

the identiﬁer of the interaction protocol. The mes-

sage is broadcast to the chosen agents. Upon sending

the invitation, the social engine of the initiator agent

switches to the Waiting Response. In that state, the

social engine is passively waiting for potential candi-

dates to enact roles in the proposed interaction proto-

col. The candidatures are ranked by default from the

ﬁrst to be received which holds the highest priority, to

the last positive reply to the invitation which has the

least priority. If the initiator fails to establish an ad-

hoc agent organization for the interaction, it rejects all

the candidatures and reverts to the Fetching state.

From an invited agent’s perspective, its social en-

gine does not accept invitations unless it is in the Idle

state. If the social agent does not accept to play a role,

it sends a REJECT

PROPOSAL to the initiator. Oth-

erwise, it sends an ACCEPT

PROPOSAL message to

the initiator agent and embed its candidature in the

content of the message, then it switches to the Waiting

Approval state in which it awaits for two events: the

acceptation of the candidature coming from the ini-

tiator and the complete foundation of an ad-hoc agent

organization for the purpose of instantiating the in-

teraction protocol. In the case of a rejection from the

initiator due to failure to form the ad-hoc organization

or any other reason, the invited agent turns back to the

Idle state.

Figure 4: FSM for initiating interactions in RPI.

When all the role players are gathered together to

interact, the interaction starts and the social agent of

every agent taking part in it goes immediately to the

Starting Interaction state.

The work of RPI.Social.IoP ends when an agent

goes to either the Idle Interaction or the Busy Interac-

tion states. Both of the latter states and the transitions

related to them (transitions (7) to (12) shown in Fig.

4 and Fig. 5) are part of RPI.Social.Exec as explained

in Section 4.

RPI.Social: Simple Enactment and Execution of First-Class Agent Interaction Protocols

Figure 5: FSM for responding to invitations to interacting

in RPI.

The tables 1 and 2 complement respectively ﬁg-

ures 4 and 5 with the exhaustive state transitions in

the realm of RPI.Social.IoP as well as their triggering

events and the actions that are executed right before

the transition.

3.2 RPI.Social.IoP Mechanics

While being in a given state or in the process of tran-

siting from one state to another, the social engine

may execute algorithms that attempt to match data be-

tween the agent and the role, and to evaluate precon-

ditions and postconditions. These algorithms deﬁne

the inner workings of RPI.Social.IoP.

3.2.1 Initiation of an Interaction

As soon as the social engine enters the Fetching state,

it starts executing the algorithm for fetching proto-

cols. Before starting the algorithm, the social en-

gine queries the repository of interaction protocols

for an enumeration of all its available items and sets.

The search for an adequate protocol could be done

on multiple rounds until either an ad-hoc organization

is formed and the interaction is started, or the proto-

cols enumeration is entirely exhausted and no match

is found.

On each fetching round, the social engine picks

the ﬁrst protocol that satisﬁes a following set of the

agent’s requirements:

• The agent is able to play a role in the interaction.

• The agent is able to acquire and lock environment

resources needed for the interaction (i.e. environ-

ment data set as deﬁned in the RPI.Idiom speciﬁ-

cation of the protocol).

• The precondition of the interaction is contingent

(i.e. its truth value is true or unknown) for the

agent’s current state (i.e. the state of the role that

the agent relates to should allow it to be poten-

tially able to start the interaction).

• The postcondition of the interaction protocol

should potentially satisfy the agent’s goal (i.e. it

should not be in contradiction with the goal).

The social engine acquires the environment data

prescribed in the RPI.Idiom interaction protocol us-

ing the same method of matching for role data sets as

described later in the identiﬁcation to a role in an in-

teraction protocol process. Each of these resources

is locked to be exclusively used by the role players

during the interaction.

The whole purpose of initiating an interaction for

an agent is to achieve a goal which is unreachable oth-

erwise. For that reason, verifying the alignment of the

interaction protocol’s postcondition with the agent’s

goal is part of the selection of the protocol. The ﬁrst

part of the veriﬁcation is the uniﬁcation between the

expressions of both the goal and the postcondition.

The second and last part is to establish whether the

postcondition entails the goal. The entailment is veri-

ﬁed using RPI.Inference seen later in Section 5.

3.2.2 Responding to an Invitation to Interact

Upon the reception of a PROPOSE message to play

a role in an interaction while in the Idle state, a posi-

tive response to the invitation depends on two require-

ments on the invited agent’s side:

• Like the initiator, the agent should be able to play

a role in the interaction.

• The precondition of the interaction is contingent

for the agent’s current state in the same manner as

the initiator.

If the two requirements are met, the agent responds

with an ACCEPT

PROPOSAL message otherwise it

sends back a REJECT PROPOSAL.

3.2.3 Identiﬁcation to a Role in an Interaction

Protocol

In order to identify with a role in an interaction proto-

col, the agent runs the algorithm for picking a role to

play in the interaction protocol. Along with the inter-

action protocol as an input to the algorithm, there is

a ﬂag that indicates if the agent is the initiator of the

interaction. For each role deﬁned in the protocol, the

agent attempts to generate a proﬁle for that particular

role. If the proﬁle is generated, the agent uses it to

prepare a candidature object that will be sent to the

other potential role players.

ICAART 2018 - 10th International Conference on Agents and Artiﬁcial Intelligence

Table 1: State transitions for an initiator agent.

Transition Trigger Action

Invalid → Idle (0) The social engine is properly initialized None

Idle → Fetching

(1)

The agent decides that interacting is needed to

attain a goal

None

Fetching → Idle

(2)

No sufﬁcient interaction protocol is found None

Fetching → Wait-

ing Response (3)

The agent ﬁnds a candidate interaction protocol Send PROPOSE [broad-

cast/multicast] {interaction protocol

identiﬁer}

Waiting Response

→ Fetching (4)

Waiting for candidatures timeout is up Send CANCEL [broad-

cast/multicast]

Waiting Response

(5)

Receive ACCEPT PROPOSAL [candidate]

{candidature of the sender}

Send FAILURE [candidate] if the

candidature is unintelligible

Waiting Response

(5)

Receive REJECT PROPOSAL [invited agent] None

Waiting Response

(5)

Receive ACCEPT PROPOSAL [candidate]

{candidature of the sender} and all the roles

could be ﬁlled

Form an ad-hoc organization of role

players and send CONFIRM to ev-

eryone of them

Waiting Response

(5)

Receive FAILURE [role player] after the CON-

FIRM messages are sent to the role players

Re-send CONFIRM [role player]

{role players list}

Waiting Response

(5)

Receive INFORM [role player] {sender’s can-

didature}

Send INFORM [role player] {own

candidature}

Waiting Response

→ Starting Inter-

action (6)

Receive CONFIRM [role player] from every

role player

Go to RPI.Social.Exec

Waiting Response

→ Fetching (4)

Receive CANCEL [role player] Send CANCEL [broad-

cast/multicast]

Waiting Response

→ Fetching (4)

Receive ACCEPT PROPOSAL [candidate]

{candidature of the sender} and all the roles

could be ﬁlled but the agent organization could

not be formed

Send CANCEL to every role player

Waiting Response

→ Fetching (4)

An unrecoverable failure Send CANCEL [broad-

cast/multicast]

The generation of a role proﬁle is simply made

by matching the state data set of the role and its be-

haviours with the internal state and the capabilities of

the agent. The matching of data is done on both types

and labels. Matching labels could be either word by

word or semantic in accordance to an external con-

ﬁguration set by the designer of the multiagent appli-

cation. Similarly, the matching of the behaviours is

performed on the label of the behaviour as well as on

its input and output data.

3.2.4 Evaluation of the Precondition

At the fetching stage of initiating an interaction in

RPI, the precondition of the protocol is evaluated. Its

truth value could be true, false or unknown. At this

stage, the agent is interested in the possibility of run-

ning the interaction protocol; accordingly, it checks

the precondition for contingency i.e. the social engine

plugs in the precondition the values of the environ-

ment data set and the state data set items that belong

to the role the agent identiﬁes to, then checks if the

truth value of the expression is not false. Both true

and unknown truth values are acceptable to pick the

interaction protocol since the values attributed to the

state data sets of the other roles are unknown at the

time of the evaluation.

3.2.5 Establishing an Ad-Hoc Organization for

the Interaction

At some point of the interaction instantiation, the so-

cial engine of the initiator agent gathers a set of candi-

datures for every role deﬁned in the RPI.Idiom proto-

col. Only one candidature is picked for a given role to

be part of an ad-hoc organization. The algorithm that

RPI.Social: Simple Enactment and Execution of First-Class Agent Interaction Protocols

Table 2: State transitions for an invited agent.

Transition Trigger Action

Invalid → Idle (0) The social engine is properly initialized None

Idle → Waiting

Approval (2)

Receive PROPOSE [initiator] {interaction

protocol identiﬁer} and a role could be

played in the interaction

Send ACCEPT PROPOSAL [initiator]

{own candidature}

Waiting Approval

→ Idle (3)

Waiting for CONFIRM from the initiator

timeout is up

Send CANCEL [initiator]

Waiting Approval

(4)

Receive CONFIRM [initiator] {role players

list}

Send FAILURE [initiator] if the list is

unintelligible otherwise send INFORM

[role players] {own candidature} and

become a conﬁrmed role player

Waiting Approval

(4)

Receive INFORM [role player] {sender’s

candidature}

Send FAILURE [role player] if the can-

didature is unintelligible

Waiting Approval

(4)

Receive FAILURE [role player] Send INFORM [role player] {own can-

didature}

Waiting Approval

→ Starting Inter-

action (5)

Receive CONFIRM [initiator] role players

list and all the role players are known to the

agent

Go to RPI.Social.Exec

Waiting Approval

→ Idle (3)

Receive CONFIRM [initiator] role players

list and all the role players are known to the

agent but the interaction could not be started

Send CANCEL [initiator]

Waiting Approval

→ Starting Inter-

action (5)

Receive INFORM [role player] {sender’s

candidature}, the agent is a conﬁrmed role

player and all the other role players are

known to it

Go to RPI.Social.Exec

Waiting Approval

→ Idle (3)

Receive INFORM [role player] {sender’s

candidature}, the agent is a conﬁrmed role

player and all the other role players are

known to it but the interaction could not be

started

Send CANCEL [initiator]

Waiting Approval

→ Idle (3)

Receive CANCEL [initiator] None

Waiting Approval

→ Idle (3)

An unrecoverable failure Send CANCEL [initiator]

Idle → Idle (1) Receive PROPOSE [initiator] {interaction

protocol identiﬁer} and no role could be

played in the interaction

Send REJECT PROPOSAL [initiator]

achieves this attempts to ﬁnd the ﬁrst organization of

role players for which the precondition of interaction

protocol is true. In contrast to the ﬁrst evaluation of

the precondition performed by the initiator, this one

does not accept unknown as a valid truth value since

all the role players are present.

4 RPI.Social.Exec: EXECUTION

OF INTERACTION

PROTOCOLS

Once the interaction is launched, RPI.Social.Exec

comes into action. This framework sub-system is re-

sponsible of the execution of the move speciﬁed in the

process template of the interaction protocol. Depend-

ing on the type of the move, its execution is treated as

follows:

• If the move is atomic, the role to which it is asso-

ciated executes it and passes the results to the rest

of the role players.

ICAART 2018 - 10th International Conference on Agents and Artiﬁcial Intelligence

• If the move is a composition (and-con), its com-

ponent moves are executed recursively and con-

currently to the best of the agent’s ability.

• If the move is a composition (or), its selected

component moves (i.e. those which are possible)

are executed recursively and concurrently to the

best of the agent’s ability.

• If the move is a composition (xor), the unique se-

lected component move is executed recursively.

• If the move is a composition (and-seq), the com-

ponent moves are executed recursively one after

the other.

Upon the formation of the ad-hoc organization

for the interaction, the social engine of every role

player enters Starting Interaction transitional state. In

that state, the social engine pushes in the task queue

of its underlying agent a ProcessLauncherTask task

which navigates the interaction’s main process’s tree

to reach the ﬁrst atomic move. If the reached move

is deﬁned by one of the role player’s behaviour, the

latter pushes in its task queue an item to execute

the behaviour mapped to the move and immediately

switches to the Busy Interaction state (transition (7)

in Fig. 4 and Fig. 5), otherwise it switches to the

Idle Interaction state (transition (8) in Fig. 4 and Fig.

5). From that point on, the social engine alternates

between Busy Interaction and Idle Interaction states

which are essentially the RPI.Social.Exec states (tran-

sitions (9) to (12) in Fig. 4 and Fig. 5).

In the Busy Interaction state, when the agent runs

the move’s task, ﬁrst, it evaluates the precondition of

the move; then, it executes it; after that it evaluates

the postcondition to detect if the execution was suc-

cessful; and eventually, it pushes in its queue a task

performs two operations:

• It sends to the rest of the organization an IN-

FORM message that holds the state of the run (i.e.

if it was done and whether it was successful or

not) and the values of the output.

• It emulates the execution of the move on its own

internal representation of the interaction.

In the Idle Interaction state, the social engine

expects INFORM messages from busy role players.

When one of those message is received, if the move

is done, the execution is emulated by plugging in the

output values and the state of the run is marked too.

At the end of each of the RPI.Social.Exec states,

the social engine executes ProcessLauncherTask task

again unless the root process that deﬁnes the whole

interaction protocol is marked as done. Fig. 6 depicts

the routine of task processing by RPI.Social.Exec.

5 RPI.Inference OVERVIEW

In RPI, agent goals, interaction protocols constraints

and axioms are represented using predicates. Goals

and constraints are logic expressions that contain only

atomic formulas or their negations applied only to

constant symbols, i.e. ground expressions. An axiom

is a rule with a head and a potential body, similar to a

Horn clause (Van Emden and Kowalski, 1976). How-

ever, axioms in RPI differ from Horn clauses with

these properties:

• the head of the rule could be a negative, on the

contrary, the head of the rule form of a Horn

clause is always the positive unless it is a goal

clause; and

• unlike a Horn clause, an axiom in RPI may con-

tain more than one positive atomic formula.

Based on these two properties, in contrast to Horn

clauses, there is more than one way to express an ax-

iom as a rule. In fact, each of the literals in the axiom

could be placed as head to the rule.

5.1 Main Rule and Interpretations of an

Axiom

The main rule of an axiom is the one that explicitly

deﬁnes it in RPI.Idiom. An interpretation of an ax-

iom, on the other hand, is any rule derived from its

main one.

For example, if the main rule is:

p(X, Y) :- ¬r(Y), s(X, Y).

where p is the head of the rule; then, the interpreta-

tions will be the following:

r(X) :- ¬p(X, Y), s(X, Y).

¬s(X, Y) :- ¬r(Y), ¬p(X, Y).

In RPI, there are two distinct operations that are

performed on logic expressions:

• evaluation of ground expressions; and

• proving entailment relations among ground ex-

pressions.

The unit of RPI responsible for providing these two

operations is RPI.Inference.

In some cases, the information needed for the

evaluation of a precondition is incomplete. There are

two approaches to deal with this case: default to ei-

ther truth values false or unknown. In the former ap-

proach the world is assumed to be closed while in the

latter the world is assumed to be open. In a closed

world, e.g. in a Prolog program, anything that can’t

RPI.Social: Simple Enactment and Execution of First-Class Agent Interaction Protocols

Figure 6: Activity diagram for processing tasks in RPI.Social.Exec.

be inferred from the system is automatically false. By

contrast, in an open world, the system acknowledges

the lack of the necessary information to know the ve-

racity of a queried truth value and attributes to it the

unknown value. In order to operate in an open world,

RPI adopts Kleene’s logic (Kleene, 1938) which is a

ternary logic that recognizes a third truth value for the

indeterminate.

The evaluation of expressions is procedural like

a function call, i.e. the values of the arguments are

passed to the predicates and the whole expression is

evaluated for a truth value. If, for a given predicate,

any of the arguments is unknownat the moment of the

evaluation, that predicate’s truth value is unknown.

The system for proving entailment is built on top

of Prolog. The left side of the entailment is the

ﬁrst ground expression plus the set of axioms deﬁned

in the interaction protocol’s RPI.Idiom speciﬁcation,

while its right side is the second ground expression.

In RPI.Inference, we label the ﬁrst and second expres-

sions facts and crossfacts, respectively. The basic idea

is to generate a Prolog program with the axioms and

the facts. Then, the generated program is queried for

individual literals in the crossfacts. If a query does not

return true, a second one is launched with the nega-

tion of the same literal. If that second query does not

return true as well, the truth value of the literal will be

unknown, otherwise it will be false.

6 RELATED WORKS

The previous work (Nouri et al., 2015) argues that

the works on ﬁrst-class interaction protocols that

are close to RPI.Idiom are the ARIP model (Khal-

faoui and Chaari, 2013), the RASA language (Miller

and McBurney, 2007) and the commitment machines

(Yolum and Singh, 2002). We extend the comparison

between these approaches to implementing ﬁrst-class

agent protocols and RPI to cover RPI.Social as well.

ICAART 2018 - 10th International Conference on Agents and Artiﬁcial Intelligence

100

While RASA protocols are claimed to be exe-

cutable, there is no explicit mechanism that speciﬁes

how to achieve that, thus this approach is eliminated

from the comparison. ARIP model on the other hand

relies on a third party language for implementing

component interaction to specify actual agent proto-

col. While ARIP interaction protocols are executable

as component interactions, the model is limited to the

discovery and the instantiation of the protocols and

has not any form of control over the ﬂow of their ex-

ecution. This is equivalent to having only the same

functionalities provided by RPI.Social.IoP.

Considering the OWL-P ontology language (De-

sai et al., 2006) as a representative work for the

commitment machines, its interaction protocols are

compiled into Jess rules which then could be exe-

cuted on demand. The execution of the interaction

protocols in OWL-P seems to be comparable with

RPI.Social.Exec. However, the initiation of a proto-

col is slightly different from RPI.Social.IoP. In fact,

agents that wish to interact will have to pick their pro-

tocols from a repository with the possibility to com-

pose them if needed. Then, the agent enacts one of the

roles in interaction protocols and register itself as a

service provider for the interaction. An initiator agent

would seek a service provider and ask for the descrip-

tion of its role which is subsequently enacted for the

span of the interaction.

XRole (Cabri et al., 2002) is an XML notation for

roles in the BRAIN framework (Cabri et al., 2003).

The interaction protocols in BRAIN are supported by

XRole where each role has a set of actions that trig-

ger events and a set of events that it listens to. The

mediator, called the interaction infrastructure, is the

part of the environment that generates events from

the actions performed. RoleX (Cabri et al., 2004)

is the part of BRAIN that dynamically enacts roles

by agents. To this extent, RoleX covers a subset of

RPI.Social.IoP functionalities since agents in RPI as-

sume roles only for an imminent interaction. The me-

diator in BRAIN plays the role of an event bus that

dispatches events to roles listening to them. There-

fore, in BRAIN a third party entity coordinates be-

tween the interacting agents. The same functionality

is covered by RPI.Social.Exec on an agent level.

In (Dastani et al., 2005), the authors introduce

the concept of role enactment. The agent has four

operators for assuming the role, playing it and for

the opposite of these two operations, which makes

them respectively enact, activate, deact and deacti-

vate. While this proposition shares a common ground

with RPI.Social.IoP, it has a strong organizational

component that implies norms and restrictions on the

model for implementing ﬁrst-class interaction.

7 CONCLUSION

The RPI framework provides the tools necessary for

the multiagent system developer to design and imple-

ment ﬁrst-class interaction protocols that could be au-

tonomously instantiated by the agents in runtime. The

framework has a modular design in which loosely-

coupled responsibilities within its ecosystem are as-

signed to different sub-systems.

Our contribution in this paper, is the introduc-

tion of RPI.Social which is the sub-system of the

RPI framework that performs all the social behaviours

of the agent on its behalf. It consists of two

units. The ﬁrst, RPI.Social.IoP, takes care of initi-

ating interaction protocols and responding to invita-

tions to play roles in others. The second unit which

RPI.Social.Exec is responsible for the execution of

the interaction and the coordination between the role

players. The paper gives an overview on RPI.Idiom

and RPI.Inference on which RPI.Social depends.

The literature on the execution of ﬁrst-class agent

protocols is very rare due to the relative scarcity of

works on the implementation of reiﬁed protocols. Ac-

cordingly, assessing the relevance of the contribution

of RPI.Social was made in comparison to some of the

few works on the implementation of ﬁrst-class inter-

actions that explained their mechanisms for running

their interaction protocols.

RPI.Social has the limitation of not being fully

fault-tolerant. The bootstrap protocol deﬁned by

RPI.Social.IoP is made to be tolerant to the unavail-

ability of agents during the negotiations for establish-

ing an ad-hoc organization for the interaction. How-

ever, RPI.Social.Exec would not recover from events

such as the sudden absence of an interacting agent.

In our future works we intend to add the support

for fault tolerance to RPI.Social to overcome its limi-

tation. Besides, we will focus on detailing the contri-

bution of RPI.Inference and RPI.Library.

REFERENCES

Bauer, B., Muller, J. P., and Odell, J. (2000). An exten-

sion of UML by protocols for multi-agent interaction.

In Proceedings of the Fourth International Conference

on MultiAgent Systems, pages 207–214. IEEE.

Cabri, G., Ferrari, L., and Leonardi, L. (2004). The

RoleX environment for multi-agent cooperation. In

Cooperative Information Agents VIII, pages 257–270.

Springer.

Cabri, G., Leonardi, L., and Zambonelli, F. (2002). XRole:

XML roles for agent interaction. In Proceedings of

the 3rd International Symposium ”From Agent The-

ory to Agent Implementation”, at the 16th European

RPI.Social: Simple Enactment and Execution of First-Class Agent Interaction Protocols

101

Meeting on Cybernetics and Systems Research (EM-

CSR 2002), Wien.

Cabri, G., Leonardi, L., and Zambonelli, F. (2003). BRAIN:

a framework for ﬂexible role-based interactions in

multiagent systems. In On The Move to Meaningful

Internet Systems 2003: CoopIS, DOA, and ODBASE,

pages 145–161. Springer.

Dastani, M., van Riemsdijk, M. B., Hulstijn, J., Dignum,

F., and Meyer, J.-J. C. (2005). Enacting and Deact-

ing Roles in Agent Programming. In Proceedings of

the 5th International Conference on Agent-Oriented

Software Engineering, AOSE’04, pages 189–204.

Springer.

Desai, N., Mallya, A. U., Chopra, A. K., and Singh, M. P.

(2006). OWL-P: a methodology for business process

development. In Agent-Oriented Information Systems

III, pages 79–94. Springer.

Jensen, A. S. (2015). The AORTA Reasoning Framework-

Adding Organizational Reasoning to Agents. PhD the-

sis, Department of Applied Mathematics and Com-

puter Science, Algorithms and Logic, Department

of Applied Mathematics and Computer Science, De-

partment of Informatics and Mathematical Modeling,

Technical University of Denmark.

Khalfaoui, S. and Chaari, W. L. (2013). Automatic Reuse

of Interaction Protocols in MAS: ARIP Model. In

Advanced Methods and Technologies for Agent and

Multi-Agent Systems, Proceedings of the 7th KES

Conference on Agent and Multi-Agent Systems - Tech-

nologies and Applications (KES-AMSTA 2013), pages

315–324. IOS Press.

Kleene, S. C. (1938). On notation for ordinal numbers. The

Journal of Symbolic Logic, 3(04):150–155.

Miller, T. and McBurney, P. (2007). Using constraints and

process algebra for speciﬁcation of ﬁrst-class agent in-

teraction protocols. In Engineering Societies in the

Agents World VII, pages 245–264. Springer.

Morales, J., Wooldridge, M., Rodr´ıguez-Aguilar, J. A., and

L´opez-S´anchez, M. (2017). Evolutionary Synthesis

of Stable Normative Systems. In Proceedings of the

16th Conference on Autonomous Agents and MultiA-

gent Systems, AAMAS ’17, pages 1646–1648, Rich-

land, SC. International Foundation for Autonomous

Agents and Multiagent Systems.

Nouri, A., Chaari, W. L., and Ghedira, K. (2015).

RPI.Idiom: A high-level language for ﬁrst-class agent

interaction protocols. In Computer Systems and Appli-

cations (AICCSA), 2015 IEEE/ACS12th International

Conference of, pages 1–8. IEEE.

Shoham, Y. and Leyton-Brown, K. (2008). Multiagent

Systems: Algorithmic, Game-Theoretic, and Logical

Foundations. Cambridge University Press, New York,

NY, USA.

Van Emden, M. H. and Kowalski, R. A. (1976). The Seman-

tics of Predicate Logic As a Programming Language.

Journal of the ACM, 23(4):733–742.

Yolum, P. and Singh, M. P. (2002). Commitment machines.

In Intelligent Agents VIII, pages 235–247. Springer.

ICAART 2018 - 10th International Conference on Agents and Artiﬁcial Intelligence

102