<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Agents Interoperability via Conformance Modulo Mapping</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>(T C =y)</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>s T A:</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Davide Ancona, Angelo Ferrando, and Viviana Mascardi DIBRIS, University of Genova</institution>
          ,
          <country country="IT">Italy</country>
        </aff>
      </contrib-group>
      <fpage>109</fpage>
      <lpage>115</lpage>
      <abstract>
        <p>-We present an algorithm for establishing a flexible conformance relation between two local agent interaction protocols (LAIPs) based on mappings involving agents and where S =m)sg R represents the interaction consisting of sender messages, respectively. Conformance is in fact computed “modulo S sending msg to receiver R, landed stands for “did the mapping”: two LAIPs and 0 may involve different agents and plane land?”, docked stands for “did the ship dock?”, and cuosnefodrifmfearnenttprsoyvnitdaexdftohratmaesgsiavgenesm,bauptfrmoamy esntitliltibese afpopuenadritnog bine so on. The : symbol represents the prefix operator between an to corresponding entities in 0 is applied. LAIPs are modelled interaction and a protocol, and represents the empty protocol. as trace expressions whose high expressive power allows for the The _ symbol models exclusive choice between protocols, design of protocols that could not be specified using finite state meaning that the travel agency can make only one request automata or equivalent formalisms. This expressive power makes at a time among the allowed ones, and represents protocol twhiethprthobislepmroobflesmtatbinygoivfer-acponpfroorxmimsattoing0 turnadceeceidxapbreles.siWones ctohpaet concatenation, meaning - in this example - that after receiving may lead to infinite computations, obtaining a sound but not one request, the chatbot will react by selecting and sending one complete implementation of the proposed conformance check. answer among the three allowed ones. Finally, means that Index Terms-Agent Interaction Protocols, Conformance, the protocol definition is recursive: after having received and Mappings, Trace Expressions answered one question, T ravelChat is ready to start again. I. INTRODUCTION Another company AI4M oving develops chatbots that interact with citizens to provide useful information for planning a safe journey within the city boundaries. A typical conversation between the citizen C and the chatbot M ovingChat starts with C asking if some ship docked (because the city traffic is highly impacted by cars and trunks disembarking), or if a train or bus just reached or will reach the main city station (because C might consider to take that bus or train, instead of the car); the chatbot answers either “yes”, “in one hour”, “in two hours”, or “not in the next three hours”, and moves to the state where it can receive new questions. The global agent interaction protocol 0 governing mas0 which involves C and M C (for M ovingChat) is</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>_ T C not yet T A:
=)
_ T C c=a)nc T A: )
We open the paper by means of an example. The example
allows us to explain the research question we address and
to introduce the trace expressions formalism for representing
agent interaction protocols in a gentle way, before their formal
presentation in the body of the paper.</p>
      <p>The example scenario is the following: the company
AI4T our develops chatbots interacting with human beings
in their daily working activities. AI4T our business is in the
touristic sector and chatbots support touristic operators.</p>
      <p>A typical conversation between a touristic agency
T ourAgency and the chatbot T ravelChat starts with the
request of whether a plane landed1, or a cruise ship docked,
or a train/bus reached the main city station; the chatbot,
by accessing some database or web service in the backend,
answers either “yes”, “not yet”, or “canc” (for canceled), and
then becomes available to answer new questions.</p>
      <p>The global agent interaction protocol (GAIP) which
norms the simple multiagent system mas involving T A (for
T ourAgency) and T C (for T ravelChat) might look like
_ C train =in)station M C:
C bus i=n)station M C: )
(M C =y)es C: _ M C =)</p>
      <p>in 1 h C: _
_</p>
      <p>M C not in 3 h C: )
=)
0 = (C d=oc)ked M C:</p>
      <p>in 2 h C:
M C =)
= (T A la=n)ded T C:
T A train=a)rrived T C:
_ T A d=oc)ked T C:</p>
      <p>_
_ T A bus =a)rrived T C: )
1For sake of clarity, we disregard the facts that a flight is characterized by
a code which should be supplied as a parameter to the query, and that when
the chatbot answers and becomes ready to manage a new query, it might be
able to interact with a travel agency different from T ourAgency. The trace
expressions formalism supports parameters both at the data level (to model
messages which only differ for the flight code) and at the agent level (to
model multiple concurrent conversations among different agents), but taking
parameters into account would make the presentation more complex and we
opted for keeping it as simple as possible.
0
_</p>
      <p>When the AI4T our company acquires AI4M oving, it
decides to keep providing the services previously offered
by AI4M oving, but re-implementing them with its own
technologies, in the most efficient and less error-prone way.</p>
      <p>W.r.t. to the re-implementation of M ovingChat, given
that AI4T our already developed the T ravelChat chatbot
which clearly shares some similarities with M ovingChat,
the AI4T our software engineers start wondering whether
T ravelChat can be adapted and reused to play the role of
M ovingChat. They address the question: “can T ravelChat
safely substitute M ovingChat provided that suitable
mappings between messages and between agents in mas and mas0
respectively are applied?”</p>
      <p>The intuition behind the “mappings” the AI4T our software
engineers are looking for should be clear. We formally define
them as a map MM : M1 ! M2 from the messages that
appear in an interaction protocol ag1 to those that appear in
a0 g2, and a map MA : A1 ! A2 from the agents that appear
in ag1 to those that appear in a0 g2, respectively. To answer
their “substitutability” question, the engineers must:
(1) Move from the global description of how T A and T C
interact, to T C’s local agent interaction protocol T C
(LAIP):</p>
      <p>T C = (la(nd=edT A :
train arrived
(=</p>
      <p>T A :
_
_
bus arrived
(=
d(ock=edT A :</p>
      <p>T A : )
_
(=y)es T A :
In T C we omit to write T C as sender or receiver, as this
information is implicit. Also, if there were messages in
that involved T ravelChat neither as the sender not as
the receiver, they would not appear in T C .
(2) Move from the global description 0 of how citizens and
M C interact, to M C’s LAIP, M0C :</p>
      <p>M0C = (d(ock=edC :
_</p>
      <p>train (in=stationC :
bus i(n=stationC : )
in 2 h
=) C :
_
(=y)es C :
not in 3 h
=)</p>
      <p>_
C : )
in 1 h
=) C :</p>
      <p>M0C
_
_
(3) Check whether T C is conformant to M0C ; this is
achieved by looking for mappings MA among agents
and mappings MM among messages involved in T C
and M0C , such that T ravelChat can play the role of
M ovingChat in mas0, still ensuring that the GAIP 0 is
respected.
(4) Select one couple of mappings among those computed in
step (3), hMM, MAi, based on their
semantics/pragmatics.
(5) Implement a means to allow T ravelChat and the citizens
to interact, by forcing T ravelChat to apply the selected
mappings when interacting with them.</p>
      <p>Agent T ourAgency in mas must be necessarily mapped
to C in mas0. From a semantic and pragmatic point of view,
the most reasonable message mapping is the one that maps
docked 2 mas into docked 2 mas0 (we abuse notation, and
we write msg 2 mas to mean that msg is one of the messages
exchanged by agents belonging to mas); train arrived into
train in station; bus arrived into bus in station; yes 2
mas into yes 2 mas0; not yet into in 2 h; and canc into
not 3 h. The landed message is mapped into no message:
when “pretending to be M ovingChat”, T ravelChat will
never receive a message whose meaning is close to landed,
as 0 does not support it. On the other hand, T ravelChat is
not able to discriminate between trains and buses arriving in
one or two hours. The mapping of not yet into in 2 h is a
cautious choice and the citizen will never receive the message
in 1 h, even if it would be supported by 0.</p>
      <p>From a purely syntactic point of view, and considering
protocol specifications only – hence, disregarding the actual
services and actions that are triggered by reception of
messages –, many other mappings would respect the protocol
conformance, including the one that maps canc into yes 2 mas0
and yes 2 mas into not 3 h.</p>
      <p>
        The research question that we address in this paper is the
one in step (3) above. We point out that such research question
cannot be answered by using ontology matching algorithms
[
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. Ontology matching techniques could indeed be exploited
in step (4) of the process, as we discuss in the Conclusions, but
not in step (3): an ontology represents static knowledge, not
dynamic behaviour. An agent interaction protocol represents
dynamic behaviour, not static knowledge. Checking whether a
protocol is conformant to another must necessarily take such
dynamics into account, which is not required in an ontology
matching process and which raises many subtle issues. For
example, when moving from to 0 to substitute ag0, ag must
be capable to react at least to all the “passive events” (for
example, receiving a message) that ag0 can address, and to
perform at most all the “active events” (for example, sending
a message) that ag0 can perform, at any stage of the protocol.
This requirement cannot be satisfied by an ontology matching
approach, where it does not even make sense, whereas it is
well known in the protocol conformance literature. Depending
on the expressiveness of the language used to specify GAIPs,
verifying that ag can actually substitute ag0 in a safe way
may be more or less complex, or even impossible to perform
in an exact way. As an example, recursive protocol definitions
are usually disregarded in the literature as they are extremely
complex to manage. The formalism we use for modeling
GAIPs and LAIPs supports recursion, and this is enough to
make existing conformance checking algorithms not powerful
enough for our needs.
      </p>
      <p>
        Our contribution is an algorithm for addressing step (3)
above when GAIPs are specified as trace expressions [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ],
[
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ], [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ], [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. To demonstrate the feasibility of our
approach, we present an example implemented in JADE [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ].
      </p>
    </sec>
    <sec id="sec-2">
      <title>II. RELATED WORK</title>
      <p>
        The works closer to our proposal come from Baldoni and
Baroglio who, together with their colleagues, introduced the
notion of syntactic conformance in the context of interaction
protocols for MAS and Service Oriented Computing (SOC)
scenarios, starting from 2004. Conformance is based on the
notion of interoperability among the entities’ policies (e.g. a
BPEL process [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], similar to some extent to our LAIPs) with
respect to interaction protocols (e.g. a WS-CDL choreography
[
        <xref ref-type="bibr" rid="ref12">12</xref>
        ], similar to our GAIPs), through the use of finite state
automata. While in [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ], [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ], [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] protocols were limited to
involve two entities only, [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ] presents an extension supporting
multiple parties. A further extension is presented in [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ] where
decision points are explicitly represented.
      </p>
      <p>Besides the fact that we address the conformance between
LAIPs, there are other differences between those works and
ours: first, they assume that entities/messages involved in the
policy and in the protocol respectively, are exactly the same
in order for the conformance check to have some chance
to succeed: no notion of mapping is foreseen; second, the
expressive power of trace expressions is higher than the
expressive power of WS-CDL/BPEL. The presence of expansive
subtraces, introduced later on, makes trace expressions able
to recognize context-free and non context-free languages, and
raises technical problems that do not show up when less
expressive formalisms are used.</p>
      <p>
        Among the works by Baldoni and Baroglio’s team, however,
the most inspiring for our research is [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ], recently improved
and extended in [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ]. That work presents an agent typing
system, where types are defined as commitments [
        <xref ref-type="bibr" rid="ref20">20</xref>
        ]. The
typing includes a notion of compatibility, based on subtyping,
which allows for the safe substitution of agents to roles along
an interaction that is ruled by a commitment-based protocol.
The proposal is implemented in the 2COMM framework [
        <xref ref-type="bibr" rid="ref21">21</xref>
        ]
which is based on the Agent &amp; Artifact meta-model [
        <xref ref-type="bibr" rid="ref22">22</xref>
        ],
and exploits JADE and CArtAgO [
        <xref ref-type="bibr" rid="ref23">23</xref>
        ]. Considering the LAIP
associated with an agent as its “communicative type” is an
almost natural idea in our approach also. The LAIP makes the
communicative interface of an agent explicit and can be used
both to type check an agent w.r.t. the possibility of entering
a MAS normed by some GAIP, and to define a subtyping
relation which we name “is conformant to” relation. The main
difference between our approach and the one discussed in [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ]
lies in the adopted formalism and the generality: commitments
without mappings there, trace expressions with mappings here.
      </p>
      <p>
        Many other works besides those mentioned above aim at
defining and testing conformance in the SOC community,
including [
        <xref ref-type="bibr" rid="ref24">24</xref>
        ], [
        <xref ref-type="bibr" rid="ref25">25</xref>
        ], [
        <xref ref-type="bibr" rid="ref26">26</xref>
        ], [
        <xref ref-type="bibr" rid="ref27">27</xref>
        ]. None of them uses formalisms
which are as powerful as context-free grammars, or more, and
none integrates the notion of agents and messages mappings.
Also, some of them are limited to two-party protocols.
      </p>
      <p>
        When moving to the MAS realm, we can devise the
same differences between our approach and the others as
those identified for SOC approaches: lower expressive power
of the adopted formalisms and less generality, due to the
absence of mappings in the conformance definition. Among
the most notable contributions to protocol conformance, we
may mention [
        <xref ref-type="bibr" rid="ref28">28</xref>
        ] where Endriss et al. identify three levels
of conformance, weak, exhaustive, and robust, and explore
how a specific class of logic-based agents can exploit an AIP
formalism based on simple if-then rules to check conformance
a priori or enforce it at runtime. In a similar way, Alberti
et al. exploit the SCIFF abductive proof-procedure [
        <xref ref-type="bibr" rid="ref29">29</xref>
        ] for
both a priori and runtime verification of compliance of agent
interactions [
        <xref ref-type="bibr" rid="ref30">30</xref>
        ]. In [
        <xref ref-type="bibr" rid="ref31">31</xref>
        ], Chopra and Singh formalize the
notions of conformance, coverage and interoperability. In [
        <xref ref-type="bibr" rid="ref32">32</xref>
        ]
a formal interoperability test for agents is presented. That work
considers the presence of two agents only, but in an open
scenario where agents can behave differently from the protocol
specification. Finally, in [
        <xref ref-type="bibr" rid="ref33">33</xref>
        ], Giordano and Martelli address
the problem of conformance between an agent and a protocol
through an automata-based technique, when the specification
of the protocol is given in a temporal action logic.
      </p>
    </sec>
    <sec id="sec-3">
      <title>III. BACKGROUND AND BASIC DEFINITIONS</title>
      <p>a) Trace expressions: Trace expressions are based on
events and event types and can be combined with various
operators. For sake of presentation, in this paper we do not
distinguish between events and event types, and we trace the
last ones back to the notion of interactions.</p>
      <p>An interaction is represented by S =m)sg R where S is the
sender, msg is the message, and R is the receiver. We define
M SG as the function which, given an interaction, returns its
message: M SG(S =m)sg R) = msg.</p>
      <p>A trace expression represents a set of possibly infinite
interaction traces and is defined on top of the following
operators:
– (empty trace), denoting the singleton set f g containing
the empty interaction trace ,
– int : (prefix), denoting the set of all traces whose first
interaction is int and the remainder is a trace of ,
– 1 2 (concatenation), denoting the set of all traces obtained
by concatenating the traces of 1 with those of 2,
– 1^ 2 (intersection), denoting the intersection of the traces
of 1 and 2,
– 1_ 2 (union), denoting the union of the traces of 1 and
2,
– 1j 2 (shuffle), denoting the set obtained by shuffling the
traces in 1 with the traces in 2.</p>
      <p>To support recursion without introducing an explicit
construct, trace expressions are regular terms and can be
represented by a finite set of syntactic equations.</p>
      <p>
        As an example, T = int :T is equivalent to the infinite but
regular term int :int :int :int : : : :. The only trace represented by
T is int !: trace expressions are interpreted in a coinductive
way to represent infinite traces of interactions [
        <xref ref-type="bibr" rid="ref34">34</xref>
        ].
      </p>
      <p>The semantics of trace expressions is specified by a
transition relation T I T , where T and I denote the set
of trace expressions and of interactions, respectively. Notation
1 in!t 2 means ( 1; int ; 2) 2 ; the transition 1 in!t 2
expresses the property that the system can safely move from
the state specified by 1 into the state specified by 2 when
interaction int takes place. Trace expressions model GAIPs.</p>
      <p>b) Expansive trace expressions: The expressive power of
trace expressions is due to the presence of expansive terms.</p>
      <p>Def. 3.1: A trace expression is expansive iff = 1 2
and 1 is a cyclic term containing ; or = 1j 2 and either
1 or 2 is a cyclic term containing ; or = 1^ 2 and either
1 or 2 is a cyclic term containing ; or it contains a subtrace
that is expansive.</p>
      <p>Expansive subtraces allow the trace expression formalism
to recognize more than context-free languages. Given a trace
expression , exp( ) is true if is expansive.</p>
      <p>c) Trace expression over-approximation: Given a trace
expression , e is an over-approximation of iff is not
expansive and e = ; or is expansive and e is a trace
expression equivalent to a regular expression representing a
superset of the traces recognized by .</p>
      <p>
        Since e is equivalent to a regular expression, it is not
expansive. Given an expansive trace expression , there may be
many e that over-approximate it. The algorithm that computes
one of these non-expansive over-approximations is discussed
in [
        <xref ref-type="bibr" rid="ref35">35</xref>
        ].
      </p>
      <p>
        d) Projection: Let A be a set of agents. Projection [
        <xref ref-type="bibr" rid="ref36">36</xref>
        ] is
a function : T P(A) ! T . Given a trace expression and
a set of agents ags A as input, returns a trace expression
ags which contains only interactions involving agents in ags:
interactions that do not involve agents in ags are removed
from ags. Since in this paper we are interested in projecting
onto a single agent at a time, we will write ag instead of
fagg to denote the projection of onto agent ag.
      </p>
      <p>When projected onto S, interaction S =m)sg R is represented
by =m)sgR (“sending interaction”); when projected onto R, it
is represented by (ms=gS (“receiving interaction”). In projected
interactions, we omit to write the agent onto which the
projection is performed. We extend the M SG function
introduced for interactions, to sending and receiving interactions:
M SG(=m)sgR) = M SG((ms=gR) = msg. Projected trace
expressions model LAIPs.</p>
      <p>e) GAIPs, agents, interactions, and messages: Let mas
be a multiagent system governed by some GAIP modeled
by trace expression . We define GAIP (mas) as . Let
be a trace expression involving all and only agents A and
interactions I. We define AG( ) as A, IN T ( ) as I, and
M SG( ) as fmsg j int 2 IN T ( ) and msg = M SG(int)g.</p>
      <p>The definitions of AG, IN T and M SG hold for both trace
expressions and projected trace expressions.</p>
    </sec>
    <sec id="sec-4">
      <title>IV. LAIP CONFORMANCE MODULO MAPPING We first give a simpler, but stronger, definition of compliance which does not allow renaming of messages and agents.</title>
      <p>Def. 4.1: Given two LAIPs ag1 and a0 g2, we say that ag1
is conformant to a0 g2, written ag1 a0 g2, iff the following
conditions are coinductively verified:
=m)sg ag
! a00g1, then 9 a00g02 s.t.
8msg ; ag if 9 a00g1 s.t. ag1</p>
      <p>msg
a0 g2 =)!ag a00g02^ a00g1 a00g02;
8msg ; ag if 9 a00g02 s.t. a0 g2</p>
      <p>msg
ag1 (=!ag a00g1^ a00g1
(ms=g ag
!</p>
      <p>a00g02, then 9 a00g1 s.t.
a00g02;
=m)sg ag</p>
      <p>!
f a00g02 j 9msg ; ag: a0 g2 a00g02g =6 ; implies f a00g1 j
msg
9msg ; ag: ag1 =)!ag a00g1g =6 ;.</p>
      <p>In the following formalization we assume that ag1 is
an agent in mas, and ag2 an agent in mas0, and define
= GAIP (mas), 0 = GAIP (mas0), ag1 = ( ; ag1),
a0 g2 = ( 0; ag2) , A1 = AG( ag1), A2 = AG( a0 g2),
M1 = M SG( ag1), M2 = M SG( a0 g2).</p>
      <p>As introduced in Section I, we consider a map MM :
M1 ! M2 from the messages that appear in ag1 to those
that appear in a0 g2, and a map MA : A1 ! A2 from the
agents that appear in ag1 to those that appear in a0 g2.</p>
      <p>A more general conformance relation modulo mappings
can be defined in terms of the basic conformance relation of
Definition 4.1.</p>
      <p>Def. 4.2: Given two LAIPs ag1 and a0 g2, and two
mappings MM and MA on messages and agents, respectively, we
say that ag1 is conformant to a0 g2 modulo MM and MA,
written ag1 hMM;MAi a0 g2, iff hMM; MAi( ag1) a0 g2.
obtWaiinthed hMfroMm; MaAgib(yagr1e)plawceingdeanloltethetheintterraaccetioenxspr=ems)ssgioang
and (ms=g ag with MM=()msg)MA(ag) and MM((=msg)MA(ag),
respectively.</p>
      <p>Intuitively, the relation ag1 hMM;MAi a0 g2 ensures that
ag1 can safely substitute ag2 in mas0, provided that mappings
MM and MA are applied to messages and agents in ag1,
respectively.</p>
      <p>An algorithm for conformance. Given the definitions 4.1
and 4.2, a first question that may arise is whether there
exists an algorithm for deciding if the compliance relation
holds for a pair of trace expressions, and, in case of the
more general notion of conformance modulo mappings, if
such mappings can be computed. Unfortunately, the problem
is undecidable even for the simpler conformance relation of
Definition 4.1; this can be derived by the fact that a
contextfree grammar can be encoded into a trace expression, and
that the problem of inclusion between context-free languages
(which is known to be undecidable) can be reduced to the
conformance problem between two trace expressions. Despite
this negative result, it is still interesting to investigate the
existence of algorithms which are sound (even though not
complete) w.r.t. the definition of conformance between trace
expressions.</p>
      <p>We define the merging of two maps in the following way:
let MM : M1 ! M2 and M M0 : M10 ! M20 be two maps
among messages:
if 9msg2M1\M10 :MM(msg) 6= M M0(msg)
then merge(MM; M M0) = ;
else merge(MM; M M0) = M M00 : M1[M10 ! M2[M20
such that M 00 = MM [ M 0 .</p>
      <p>M M</p>
      <p>In other words, merging two maps consists in computing
the union of the elements in the maps, unless there is some
conflict, namely, some element is mapped to two different
elements in the two maps. In this case, the maps cannot
be merged (the merged map is empty). For instance, if
MM = fmsg1 7! msg2; msg3 7! msg4g and M M0 =
fmsg3 7! msg4; msg5 7! msg6g, the merged map is
M M00 = fmsg1 7! msg2; msg3 7! msg4; msg5 7! msg6g.
If MM = fmsg1 7! msg2g and M M0 = fmsg1 7! msg3g,
their merged map is empty.</p>
      <p>The same definition can be adopted for merging maps of
agents.</p>
      <p>Given two maps MM and MA, a sending interaction =m)sgR
can substitute a sending interaction m=)sg0R0 in the context of
MM and MA iff merge(fmsg 7! msg0g; MM) 6= ; and
merge(fR 7! R0g; MA) 6= ;. The definition for a receiving
interaction (ms=gS substituting a receiving interaction m(s=g0S0 is
similar.</p>
      <p>The computation of ag1 hMM;MAi a0 g2 is carried out by
the “isConformant” algorithm. The algorithm starts from two
initial agent and message maps, and incrementally adds to
them those mappings which are necessary to ensure agents
interoperability. Consequently, it is possible to obtain partial
maps where some messages and agents have not been mapped
to anything at the end of the computation. Partial maps must
be completed (namely, they must become total maps and be
defined on all the elements in their domain), in order to
be used in practice. Completion can be achieved by adding
dummy elements in the range, and associate the elements in
the domain that had no corresponding element in the range,
with such dummy elements. The completion step is necessary
to ensure that, when actually used to substitute ag1 2 mas
to ag2 2 mas0, the maps returned by the algorithm can be
applied to all the agents and messages appearing in ag1. The
isConformant algorithm operates by cases, and the following
implication holds:</p>
      <p>ag1 hcMM;cMAi a0 g2 (=
hMM; MAi = isConformant( ag1, a0 g2, ;, fag1 7! ag2g)
and hMM; MAi 6= h;; ;i and complete(MM) = cMM and
complete(MA) = cMA, where complete is the map
completion step sketched above.</p>
      <p>Conformance can be lifted to global protocols:
0 () 8agi2mas:9agj02mas0 : agi
hMM;MAi 0 () 8agi2mas:9agj02mas0 : agi hMM;MAi a0 gj0
Conjecture: Soundness. The conformance algorithm is sound
w.r.t. Definition 4.2.</p>
      <p>Claim: No Completeness. The algorithmic implementation of
the conformance test is not complete.</p>
      <p>For space constraints, the pseudo-code of isConformant
along with the sketch of the claim proof is available
at https://www.disi.unige.it/person/MascardiV/Download/
supplementalConformanceModuloMapping.pdf.</p>
    </sec>
    <sec id="sec-5">
      <title>V. EXAMPLES AND IMPLEMENTATION</title>
      <p>Given two MASs mas and mas0 ruled by = GAIP (mas)
and 0 = GAIP (mas0) respectively, the steps for using an
agent involved in mas inside mas0 are the following: (i)
identify the agent ag1 2 mas to be used in mas0; (ii) generate
the set of agents and maps that ensure ag1 conformance
f(ag2; hMM; MAi)jag2 2 mas0; ag1 hMM;MAi a0 g2g; (iii)
select one couple of agents and maps (ag2; hMM; MAi)
from the set, based on domain-dependent criteria that might
involve message similarity, similar behaviours of the mapped
agents, and so on; (iv) generate an interface i for ag1 driven
by (ag2; hMM; MAi); (v) substitute ag2 in mas0 with the
“interfaced version” of ag1: the agents in the MAS obtained
via this substitution still respect 0, because of step (ii).</p>
      <p>The notion of interface introduced in step (iv) is related to
the actual use of the maps generated during the conformance
check and it is meant as a logical component offering a
“bridging service”, that can be implemented in many different
ways. Hence, the interface i generated in step (iv) realizes the
map-driven translations needed by agents in mas and mas0
to interoperate. Each time ag1 2 mas performs the action
of sending a message msg1 to an agent ag1r 2 mas, the
interface i “intercepts” (from a logical point of view) msg1,
translates it into MM(msg1) = msg2, and forwards msg2
to MA(ag1r) 2 mas0. In the same way, each time an agent
ag2s 2 mas0 sends a message msg3 to ag2 2 mas0, the
interface intercepts msg3, looks for a message msg4 that ag1 can
receive in the current protocol state s.t. MM(msg4) = msg3,
translates msg3 into msg4, and forwards it to ag1.</p>
      <p>As an example, let us consider a GAIP representing the
protocol where an agent Buyer (Buy) asks to an agent Seller
(Sel) for a resource and if the resource is available, the Seller
can give it in exchange of money, otherwise the Seller informs
the Buyer of the unavailability.</p>
      <p>= (Buy =re)s? Sel):
(Sel =r)es Buy:Buy m=o)ney Sel: _Sel =n)o Buy: )
Let us consider another similar GAIP 0 defining a
bookshop protocol where an agent Client (Cl) asks for a book
to an agent BookShop, and again if the book is available the
BookShop (Shop) agent sells it for a given amount of euros,
otherwise a no avbl message is returned.</p>
      <p>0 = (Cl b=oo)k? Shop):
((Shop =bo)ok Cl:Cl e=u)ros Shop: )_(Shop no=)avbl Cl: 0))
We want to check if is conformant to 0, 0. From the
definition of conformance between global protocols, for each
agent ag 2 we must find at least one agent ag0 2 0
s.t. ag hMM;MAi a0 g0 . First of all, we generate the local
perspectives LAIPs of and 0 through projection.</p>
      <p>Buy = (=re)s?Sel):(( (re=sSel : m=o)neySel : )_(=)Sel : Buy))</p>
      <p>no
money no
Sel = ((res=?Buy):((=r)es Buy : (= Buy : )_((=Buy : Sel))
C0l = (b=oo)k?Shop):(((=Shop : e=u)rosShop : )_(no(a=vblShop : C0l))</p>
      <p>book</p>
      <p>S0hop = (b(oo=k?Cl):((=bo)okCl : e(ur=osCl : )_(no=)avblCl : S0hop))
Then we apply the rules deriving from Definition 4.2,
obtaining that (Figure 1c) Buy hMM;MAi C0l with MM = fres? 7!
book?; res 7! book; money 7! euros; no 7! no avblg
and MA = fBuy 7! Cl; Sel 7! Shopg and (Figure 1d)
Sel hMM;MAi S0hop with the same maps. From this, we
derive that hMM;MAi 0.</p>
      <p>In this example we had no prior knowledge on possibly
correct mappings. In many real scenarios, however, some of the
correct mappings among messages and agents, respectively,
are known in advance. The values ;, fag1 7! ag2g used to
initialize the maps in the definition of ag1 hcMM;cMAi a0 g2
iff hMM; MAi = isConformant( ag1, a0 g2, ;, fag1 7! ag2g)
correspond to the worst case where the developer has no
knowledge at all about the possible correct mappings, and
wants to generate all of them for further inspection. If the
developer knows that the initial associations modelled by
(a) (b) To demonstrate how to exploit the maps generated by the
conformance testing to substitute JADE (http://jade.tilab.com)
money euros agents with other JADE agents, we adopted an automatic
Buyer rreess? Seller Client book? BookShop
lsoowurecdae)cco1onsdtseissttstreaipnn,sltachtorieonenfosratmepppasrn:ocaechc.hTechkeinmget(hcoodrroelsopgoyndwinegfotlobook steps (i),(ii) and (iii) presented at the very beginning of this
no</p>
      <p>no avbl Section): The algorithm presented in Section IV is fully
im(c) plemented in SWI-Prolog (http://www.swi-prolog.org). Prolog</p>
      <p>has been chosen thanks to its built-in support to cyclic terms,
euros coinduction, and for the possibility to use backtracking for
money generating all the existing maps. The implementation of the
Buyer res? i book? BookShop algorithm is &lt; 400 LOC.</p>
      <p>res book b) 2nd step, substitution (corresponding to step (iv)):
no Let us suppose that ag1 2 mas can substitute ag2 2 mas0
no avbl with maps MA and MM. For demonstrating how substitution
(d) can be put into practice we have opted for a basic approach
euros money uwsheetrheewmeoadpifipleyd tshoeurmceapcsodtoe tmheapso(augrc1e) cinosdteeaodf oafgt1h,easnodurwcee
book? res? code of ag2 in mas0: we operate on the Java file containing
Client book i res Seller the JADE class implementing ag1 and we substitute all the
no avbl no owcicthurMrenMce(smosfgai)g.i Twhitihs MsubAs(taitguit)ioanndsteapll oisccaulsrore nimcepsleomfemnstegdi
Fig. 1: (a) and (b) MASs presented in the example; (c) Buyer sub- in SWI-Prolog (&lt; 30 LOC).
sbCtoilotiuektne;stm; SConelileelyenrt7!t7!harcokuBg;hnoootkh7!Sehionnpotegr,afavcMbelMgi); d(rd=i)veSneflrbleeysr?MsuA7!bstit=ubtoeosfkBB?uo;yroeeksrSho77!!p recomc)pil3erdmsatepp(,age1xe)cauntidonw(ecoerxreecsuptoendminags0towsitthepm(va)p)(:agW1e)
with an interface driven by the same maps. instead of ag2. Despite being simple and applicable only
when the source code is available, this approach demonstrates
how we can actually use the maps generated during the
conformance check, and has been adopted for all the examples
shown in this paper.</p>
      <p>MM0 and MA0 must hold, he/she can run isConformant( ag1,
a0 g2, MM0 , MA0 ), forcing the algorithm to extend such initial
knowledge with new associations or to answer that, with these
maps, the protocols are not conformant. This would be the
case for example in Software Product Line applications and
in evolving IoT scenarios where the developer knows which
components in the previous product version/system should be
replaced by which in the new one, and wants to check if it is
possible, respecting the existing communication protocols.</p>
      <p>Although introducing the notion of interface for showing
how we can use the mappings generated during the
conformance check (step (5) presented in Section I deals with
exploiting mappings in practice) makes the presentation almost
simple and intuitive, the actual implementation of such an
interface requires to take care of many aspects dependent
on the adopted MAS framework. Step (5) is in fact heavily
application-dependent and can be faced in different ways,
depending on the applications constraints: it would be possible
for example to insert a “translator agent” into mas0, that
intercepts and manages all interactions involving ag; or to
create a wrapper for agent ag that allows it to automatically
translate incoming and outgoing messages according to MM;
or even to automatically modify ag’s source code, if available,
to hard-wire the MM mapping at source code level. Whatever
the approach is, all the agents in mas0 should be aware that ag0
has been substituted by ag, in order to handle communication
properly.</p>
    </sec>
    <sec id="sec-6">
      <title>VI. CONCLUSIONS AND FUTURE WORK</title>
      <p>In this paper we have presented a conformance modulo
mapping algorithm suitable for checking conformance
between local protocols specified as (projected) trace
expressions, together with its implementation and usage example.
The paper presents a general solution to the problem with
as few constraints as possible, to make it reusable in as
many situations as possible, but the actual scenarios where
we believe that our approach can be more profitably exploited
involve conformance between different versions of the same
LAIP or LAIPs which are known to be similar, like the
ones presented in Sections I and V. As another example,
a self-driving car may interact with other cars, lights, etc.,
according to the current road norms (LAIP 1). Norms change
and the new LAIP to which the car must conform, becomes
2. Which transformations (mappings) should we implement
over 1 to ensure it is syntactically conformant to 2? The
developer in charge of migrating 1 to 2 can use our algorithm
for having guarantees on the syntactic compliance, although
he/she cannot have guarantees that semantics is preserved: a
human is required to finally select and validate the produced
mappings. We think that semantic compliance will never be
fully automatized, and for this reason we expect that our
algorithm should be used in scenarios where LAIPs should
not be re-aligned frequently.</p>
      <p>W.r.t. the five steps introduced in Section I, we exploited
achieved results for steps (1-2), we devoted the entire paper
to step (3), and we demonstrated how to tackle step (5). More
sophisticated approaches could be followed for step (5), each
with pros and cons. Experimenting some of them, such as
introducing a mediator agent between mas and mas0 acting
as the i interface and generating wrappers for the agents that
must substitute other agents, will be explored in the future.</p>
      <p>
        Step (4) is an open problem which falls outside the scope
of our investigation: in this paper we do not face the issue of
“semantic/pragmatic conformance”, but only that of “syntactic
conformance”. In case some constraints on interactions are
know, for example commitments that must be fulfilled and
that can drive the choice of the most suitable mapping, we
might exploit them. Otherwise, by interpreting messages as
words or sentences in some natural language, we might take
advantage of semantic techniques similar to those used for
matching ontological concepts [
        <xref ref-type="bibr" rid="ref37">37</xref>
        ]. Ontology matching could
hence be exploited in the global process we have presented,
in step (4). We remark that if we knew in advance which
are the semantically correct message and agents mappings,
we could feed our algorithm with them and use it as a “plain
conformance checker” like those mentioned above, rather than
a “conformant mappings builder”. Even if we knew all the
correct mappings in advance, however, we could not run any
of the existing conformance checking algorithms on trace
expressions, because of their higher expressiveness.
      </p>
      <p>Finally, an extremely challenging issue would be to identify
mappings where one message used in one MAS corresponds to
a sequence of messages used in another MAS, and to consider
message inputs and outputs as well. This issue will drive our
future directions of investigation.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <surname>Euzenat</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shvaiko</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          : Ontology matching. Springer (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <surname>Ancona</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Drossopoulou</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mascardi</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Automatic generation of self-monitoring MASs from multiparty global session types in Jason</article-title>
          .
          <source>In: DALT</source>
          . Volume
          <volume>7784</volume>
          of LNCS., Springer (
          <year>2012</year>
          )
          <fpage>76</fpage>
          -
          <lpage>95</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <surname>Ancona</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Barbieri</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mascardi</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Constrained global types for dynamic checking of protocol conformance in multi-agent systems</article-title>
          . In: SAC,
          <string-name>
            <surname>ACM</surname>
          </string-name>
          (
          <year>2013</year>
          )
          <fpage>1377</fpage>
          -
          <lpage>1379</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <surname>Briola</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mascardi</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ancona</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>Distributed runtime verification of JADE multiagent systems</article-title>
          .
          <source>In: IDC. Volume 570 of Studies in Computational Intelligence</source>
          ., Springer (
          <year>2014</year>
          )
          <fpage>81</fpage>
          -
          <lpage>91</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <surname>Ancona</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Briola</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ferrando</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mascardi</surname>
          </string-name>
          , V.:
          <article-title>Global protocols as first class entities for self-adaptive agents</article-title>
          .
          <source>In: AAMAS</source>
          ,
          <string-name>
            <surname>ACM</surname>
          </string-name>
          (
          <year>2015</year>
          )
          <fpage>1019</fpage>
          -
          <lpage>1029</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <surname>Ancona</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bono</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bravetti</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Campos</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Castagna</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          , Denie´lou,
          <string-name>
            <given-names>P.</given-names>
            ,
            <surname>Gay</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.J.</given-names>
            ,
            <surname>Gesbert</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.</given-names>
            ,
            <surname>Giachino</surname>
          </string-name>
          ,
          <string-name>
            <given-names>E.</given-names>
            ,
            <surname>Hu</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            ,
            <surname>Johnsen</surname>
          </string-name>
          ,
          <string-name>
            <surname>E.B.</surname>
          </string-name>
          , et al.,
          <string-name>
            <surname>F.M.:</surname>
          </string-name>
          <article-title>Behavioral types in programming languages</article-title>
          .
          <source>Foundations and Trends in Programming Languages</source>
          <volume>3</volume>
          (
          <issue>2</issue>
          -3) (
          <year>2016</year>
          )
          <fpage>95</fpage>
          -
          <lpage>230</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <surname>Ancona</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ferrando</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mascardi</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Comparing trace expressions and linear temporal logic for runtime verification</article-title>
          .
          <source>In: Theory and Practice of Formal Methods. Volume 9660 of LNCS</source>
          . (
          <year>2016</year>
          )
          <fpage>47</fpage>
          -
          <lpage>64</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <surname>Ancona</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ferrando</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mascardi</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Parametric runtime verification of multiagent systems</article-title>
          . In: AAMAS,
          <string-name>
            <surname>ACM</surname>
          </string-name>
          (
          <year>2017</year>
          )
          <fpage>1457</fpage>
          -
          <lpage>1459</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <surname>Ancona</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ferrando</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Franceschini</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mascardi</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Parametric trace expressions for runtime verification of Java-like programs</article-title>
          . In: FTfJP@ECOOP,
          <string-name>
            <surname>ACM</surname>
          </string-name>
          (
          <year>2017</year>
          )
          <volume>10</volume>
          :
          <fpage>1</fpage>
          -
          <lpage>10</lpage>
          :
          <fpage>6</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <surname>Bellifemine</surname>
            ,
            <given-names>F.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Caire</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Greenwood</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>Developing Multi-Agent Systems with JADE</article-title>
          . Wiley (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <surname>The OASIS Web Services Business Process Execution Language (WSBPEL) Technical</surname>
            <given-names>Committee</given-names>
          </string-name>
          :
          <article-title>Web services business process execution language version 2.0</article-title>
          . (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <surname>Kavantzas</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Burdett</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ritzinger</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fletcher</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lafon</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Barreto</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <string-name>
            <surname>Web Services Choreography Description Language</surname>
          </string-name>
          v.
          <volume>1</volume>
          .0. (
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <surname>Baldoni</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baroglio</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Martelli</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Patti</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schifanella</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Verifying the conformance of web services to global interaction protocols: A first step</article-title>
          .
          <source>In: EPEW/WS-FM. Volume 3670 of LNCS</source>
          . (
          <year>2005</year>
          )
          <fpage>257</fpage>
          -
          <lpage>271</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <surname>Baldoni</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baroglio</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Martelli</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Patti</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schifanella</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Verifying protocol conformance for logic-based communicating agents</article-title>
          .
          <source>In: CLIMA. Volume 3487 of LNCS</source>
          . (
          <year>2004</year>
          )
          <fpage>196</fpage>
          -
          <lpage>212</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <surname>Baldoni</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baroglio</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Martelli</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Patti</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Verification of protocol conformance and agent interoperability</article-title>
          .
          <source>In: CLIMA. Volume 3900 of LNCS</source>
          . (
          <year>2005</year>
          )
          <fpage>265</fpage>
          -
          <lpage>283</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [16]
          <string-name>
            <surname>Baldoni</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baroglio</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Martelli</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Patti</surname>
          </string-name>
          , V.:
          <article-title>A priori conformance verification for guaranteeing interoperability in open environments</article-title>
          .
          <source>In: ICSOC. Volume 4294 of LNCS</source>
          . (
          <year>2006</year>
          )
          <fpage>339</fpage>
          -
          <lpage>351</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [17]
          <string-name>
            <surname>Baldoni</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baroglio</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chopra</surname>
            ,
            <given-names>A.K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Desai</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Patti</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Singh</surname>
            ,
            <given-names>M.P.</given-names>
          </string-name>
          : Choice, interoperability, and
          <article-title>conformance in interaction protocols and service choreographies</article-title>
          .
          <source>In: AAMAS (2)</source>
          , IFAAMAS (
          <year>2009</year>
          )
          <fpage>843</fpage>
          -
          <lpage>850</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [18]
          <string-name>
            <surname>Baldoni</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baroglio</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Capuzzimati</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          :
          <article-title>Typing multi-agent systems via commitments</article-title>
          .
          <source>In: EMAS@AAMAS. Volume 8758 of LNCS</source>
          . (
          <year>2014</year>
          )
          <fpage>388</fpage>
          -
          <lpage>405</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          [19]
          <string-name>
            <surname>Baldoni</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baroglio</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Capuzzimati</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Micalizio</surname>
          </string-name>
          , R.:
          <article-title>Type checking for protocol role enactments via commitments</article-title>
          .
          <source>Autonomous Agents and Multi-Agent Systems 32(3)</source>
          (
          <year>2018</year>
          )
          <fpage>349</fpage>
          -
          <lpage>386</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          [20]
          <string-name>
            <surname>Yolum</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Singh</surname>
            ,
            <given-names>M.P.</given-names>
          </string-name>
          :
          <article-title>Commitment machines</article-title>
          .
          <source>In: ATAL. Volume 2333 of LNCS</source>
          . (
          <year>2001</year>
          )
          <fpage>235</fpage>
          -
          <lpage>247</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          [21]
          <string-name>
            <surname>Baldoni</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baroglio</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Capuzzimati</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          :
          <article-title>2COMM: A commitmentbased MAS architecture</article-title>
          .
          <source>In: EMAS@AAMAS. Volume 8245 of LNCS</source>
          . (
          <year>2013</year>
          )
          <fpage>38</fpage>
          -
          <lpage>57</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          [22]
          <string-name>
            <surname>Omicini</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ricci</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Viroli</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>Artifacts in the A&amp;A meta-model for multi-agent systems</article-title>
          .
          <source>Autonomous Agents and Multi-Agent Systems 17(3)</source>
          (
          <year>2008</year>
          )
          <fpage>432</fpage>
          -
          <lpage>456</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          [23]
          <string-name>
            <surname>Ricci</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Piunti</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Viroli</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Environment programming in multiagent systems: an artifact-based perspective</article-title>
          .
          <source>Autonomous Agents and Multi-Agent Systems 23(2)</source>
          (
          <year>2011</year>
          )
          <fpage>158</fpage>
          -
          <lpage>192</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          [24]
          <string-name>
            <surname>Bordeaux</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          , Salau¨n, G.,
          <string-name>
            <surname>Berardi</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mecella</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>When are two web services compatible? In: TES</article-title>
          . Volume
          <volume>3324</volume>
          of LNCS. (
          <year>2004</year>
          )
          <fpage>15</fpage>
          -
          <lpage>28</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          [25]
          <string-name>
            <surname>Busi</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gorrieri</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Guidi</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lucchi</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zavattaro</surname>
          </string-name>
          , G.:
          <article-title>Choreography and orchestration: A synergic approach for system design</article-title>
          .
          <source>In: ICSOC. Volume 3826 of LNCS</source>
          . (
          <year>2005</year>
          )
          <fpage>228</fpage>
          -
          <lpage>240</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          [26]
          <string-name>
            <surname>Bravetti</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zavattaro</surname>
          </string-name>
          , G.:
          <article-title>Contract based multi-party service composition</article-title>
          .
          <source>In: FSEN. Volume 4767 of LNCS</source>
          . (
          <year>2007</year>
          )
          <fpage>207</fpage>
          -
          <lpage>222</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          [27]
          <string-name>
            <surname>Bravetti</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zavattaro</surname>
          </string-name>
          , G.:
          <article-title>A theory for strong service compliance</article-title>
          .
          <source>In: COORDINATION. Volume 4467 of LNCS</source>
          . (
          <year>2007</year>
          )
          <fpage>96</fpage>
          -
          <lpage>112</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          [28]
          <string-name>
            <surname>Endriss</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Maudet</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sadri</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Toni</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          :
          <article-title>Protocol conformance for logic-based agents</article-title>
          . In: IJCAI, Morgan Kaufmann (
          <year>2003</year>
          )
          <fpage>679</fpage>
          -
          <lpage>684</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          [29]
          <string-name>
            <surname>Alberti</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gavanelli</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lamma</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mello</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Torroni</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>The Sciff abductive proof-procedure</article-title>
          .
          <source>In: AI*IA. Volume 3673 of LNCS</source>
          . (
          <year>2005</year>
          )
          <fpage>135</fpage>
          -
          <lpage>147</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          [30]
          <string-name>
            <surname>Alberti</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gavanelli</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lamma</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chesani</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mello</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Torroni</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Compliance verification of agent interaction: a logic-based software tool</article-title>
          .
          <source>Applied Artificial Intelligence</source>
          <volume>20</volume>
          (
          <issue>2-4</issue>
          ) (
          <year>2006</year>
          )
          <fpage>133</fpage>
          -
          <lpage>157</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref31">
        <mixed-citation>
          [31]
          <string-name>
            <surname>Chopra</surname>
            ,
            <given-names>A.K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Singh</surname>
            ,
            <given-names>M.P.</given-names>
          </string-name>
          :
          <article-title>Producing compliant interactions: Conformance, coverage, and interoperability</article-title>
          .
          <source>In: DALT. Volume 4327 of LNCS</source>
          . (
          <year>2006</year>
          )
          <fpage>1</fpage>
          -
          <lpage>15</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref32">
        <mixed-citation>
          [32]
          <string-name>
            <surname>Chopra</surname>
            ,
            <given-names>A.K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Singh</surname>
            ,
            <given-names>M.P.:</given-names>
          </string-name>
          <article-title>Interoperation in protocol enactment</article-title>
          .
          <source>In: DALT. Volume 4897 of LNCS</source>
          . (
          <year>2007</year>
          )
          <fpage>36</fpage>
          -
          <lpage>49</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref33">
        <mixed-citation>
          [33]
          <string-name>
            <surname>Giordano</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Martelli</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Verifying agent conformance with protocols specified in a temporal action logic</article-title>
          .
          <source>In: AI*IA. Volume 4733 of LNCS</source>
          . (
          <year>2007</year>
          )
          <fpage>145</fpage>
          -
          <lpage>156</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref34">
        <mixed-citation>
          [34]
          <string-name>
            <surname>Ancona</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dovier</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>A theoretical perspective of coinductive logic programming</article-title>
          .
          <source>Fundam. Inform</source>
          .
          <volume>140</volume>
          (
          <issue>3-4</issue>
          ) (
          <year>2015</year>
          )
          <fpage>221</fpage>
          -
          <lpage>246</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref35">
        <mixed-citation>
          [35]
          <string-name>
            <surname>Ferrando</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>The early bird catches the worm: first verify</article-title>
          , then monitor! Presented at Vortex'
          <volume>16</volume>
          (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref36">
        <mixed-citation>
          [36]
          <string-name>
            <surname>Ancona</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Briola</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>El Fallah Seghrouchni</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mascardi</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Taillibert</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Efficient verification of MASs with projections</article-title>
          .
          <source>In: EMAS@AAMAS. Volume 8758 of LNCS</source>
          . (
          <year>2014</year>
          )
          <fpage>246</fpage>
          -
          <lpage>270</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref37">
        <mixed-citation>
          [37]
          <string-name>
            <surname>Mascardi</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Locoro</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rosso</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Automatic ontology matching via upper ontologies: A systematic evaluation</article-title>
          .
          <source>IEEE Trans. Knowl. Data Eng</source>
          .
          <volume>22</volume>
          (
          <issue>5</issue>
          ) (
          <year>2010</year>
          )
          <fpage>609</fpage>
          -
          <lpage>623</lpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>