<!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>Constraints among Commitments: Regulative Specification of Interaction Protocols</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Matteo Baldoni</string-name>
          <email>baldoni@di.unito.it</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Cristina Baroglio</string-name>
          <email>baroglio@di.unito.it</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Elisa Marengo</string-name>
          <email>emarengo@di.unito.it</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Dipartimento di Informatica - Universita` degli Studi di Torino c.</institution>
          <addr-line>so Svizzera 185, I-10149 Torino</addr-line>
          ,
          <country country="IT">Italy</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Interaction protocols play a fundamental role in multi-agent systems. In this work, after analysing the trends that are emerging not only from research on multi-agent interaction protocols but also from neighbouring fields, like research on workflows and business processes, we propose a novel definition of commitment-based interaction protocols, that is characterized by the decoupling of the constitutive and the regulative specifications and that explicitly foresees a representation of the latter based on constraints among commitments. A clear distinction between the two representations has many advantages, that are explained in the paper, mainly residing in a greater openness of multi-agent systems, and an easier re-use of protocols and of action definitions. A language, named 2CL, for writing regulative specifications is also given.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        The term “interaction protocol” refers to a pattern of behavior that allows a set of agents
to become a multi-agent system (MAS), by engaging expected cooperations.
Particularly relevant are commitment protocols by Singh [
        <xref ref-type="bibr" rid="ref29">29, 36, 35</xref>
        ]. Commitments are literals
that can hold in the social state of the system, representing the fact that a debtor commits
to a creditor to bring about some condition. All agents using a commitment protocol
share the semantics of a set of actions which affect the social state. The greatest
advantages of commitment protocols, w.r.t. other approaches to interaction, are that they
do not over-constrain the agents’ behavior by imposing an ordering on the execution
of the shared actions, and that by giving a shared meaning to the social actions, they
allow working on actual knowledge rather than on beliefs about each others’ mental
state. Nonetheless, commitment protocols do not yet suit well those situations where
the evolution of the social state is constrained by laws, preferences or habits, because
they do not allow the specification of legal patterns of execution, although this kind of
constraints makes sense in many practical situations, as noticed also in [
        <xref ref-type="bibr" rid="ref31">31</xref>
        ].
      </p>
      <p>
        In this work, we face this issue by taking on Chopra and Singh’s [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] distinction
between the constitutive and regulative specifications of interaction, deriving from the
seminal work of Searle [
        <xref ref-type="bibr" rid="ref27">27</xref>
        ]. Roughly speaking, constitutive rules give the semantics
of actions. Regulative rules rule the flow of execution, by capturing some important
characteristics of how things should be carried on in specific contexts of interaction [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ].
An actual separation of the constitutive from the regulative specification would bring
many advantages in the construction of MAS, mostly as direct effects of the obtained
modularity: easier re-use of actions in different contexts, easier customization on the
protocol, easier composition of protocols. For instance, commitment protocols are sets
of shared actions. When some behavioral patterns are desired, some authors, e.g. [34],
force specific orderings by introducing additional preconditions/effects to actions: these
actions cannot be used out of the context they were thought for. If, instead, an explicit
regulative specification were given, actions should not be over-specified, in the spirit of
the commitment approach to protocol definition. Actions would be simpler and easier
to understand because the constitutive part would correspond to the definition of the
action per se and not of the action in a context of reference.
      </p>
      <p>
        As a consequence, MAS would gain greater openness, interoperability, and
modularity of design. Interoperability would be better supported because it would be possible
to verify it w.r.t. specific aspects (e.g. at the level of actions [
        <xref ref-type="bibr" rid="ref11 ref12 ref9">11, 9, 12</xref>
        ] or at the level of
regulation rules [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]). Protocols would be more open in the sense that their modularity
would allow designers to easily adapt them to different contexts. Agents could more
easily enter a system due to the increased probability of re-using their actions. Agents
could also check individually (against the protocol specification) if they have actions
that, when executed maybe according to some pattern, match with the constitutive rules
independently from the context given by the regulative specification.
      </p>
      <p>
        In the light of the distinction between constitutive and regulative rules, this work
analyzes alternative commitment protocol models (namely [
        <xref ref-type="bibr" rid="ref11 ref18 ref19 ref21 ref22 ref26 ref3 ref30">11, 22, 18, 19, 35, 34, 26, 21,
3, 30</xref>
        ], Section 2), showing that, despite the fact that it is possible to recognize various
attempts to capture both specifications, these proposals still miss the degree of
modularity postulated in [
        <xref ref-type="bibr" rid="ref27 ref7">27, 7</xref>
        ] and described above. We show that none allows the specification
of both parts (1) in a decoupled way, (2) by means of first-class languages, (3) which
allow flexible representations – either one of the two specifications is disregarded or it
is too strict or the two representations are to some extent mixed. Section 3, then,
proposes a model for commitment interaction protocols that separates the constitutive and
the regulative parts and supplies first-class languages for representing both in a
flexible way. In particular, for the constitutive specification we adopt [
        <xref ref-type="bibr" rid="ref11 ref9">11, 9</xref>
        ], while for the
regulative specification we propose the use of constraints among commitments as well
as a language, 2CL, that allows the specification of different kinds of such constraints.
The language inherits from [
        <xref ref-type="bibr" rid="ref21 ref26">26, 21</xref>
        ] but it is very different from it in its basic principles.
In fact, it builds on commitments and not on events (actions). Section 4 shows how it
is easy to tailor an interaction protocol, expressed in 2CL, to different contexts of use,
by modifying the regulative specifications only. For the sake of simplicity we chose the
well-known Contract Net Protocol (CNP) [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ]. In the Conclusions we finish the
comparison with the models in Section 2 showing that our proposal includes the others as a
special case or overcomes their limits.
2
      </p>
    </sec>
    <sec id="sec-2">
      <title>Actions and Protocols: Constitutive and Regulative</title>
    </sec>
    <sec id="sec-3">
      <title>Specifications</title>
      <p>
        Let us consider commitment-based protocols. Commitments are directed from a debtor
to a creditor. The notation C(x, y, r, p) denotes that agent x commits to an agent y to
bring about condition p when the condition r holds. All commitments are conditional.
An unconditional commitment is merely a special case where r equals true.
Whenever this is the case, we use the short notation C(x, y, p). Agents share a social state
that contains commitments and other literals that are relevant to their interaction. Every
agent can affect the social state by executing actions, whose definition is given in terms
of modifications to the social state (e.g. adding a new commitment, releasing another
agent from some commitment, satisfying a commitment, etc. see [35]). Commitment
protocols are interaction patterns given in terms of commitments. Usually a
commitment protocol is made of a set of actions (messages), whose semantics is known to –
and agreed upon by – all of the participants [
        <xref ref-type="bibr" rid="ref9">35, 36, 9</xref>
        ].
      </p>
      <p>
        There are many definitions for actions in the literature. In UML and in the
literature about workflows, actions are atomic executions. They are considered to take zero
time, and cannot be interrupted, while activities represent more complex behaviors, that
may run for a long time, and may be interrupted by events. Most of works on agents
adopt, instead, a precondition-effect view of actions, independently from the time they
take to complete or from possible interruptions. Preconditions can be of two kinds:
preconditions to the action execution, and preconditions to some effect. The former are
literals that must hold in the social state to make the action executable, the latter are
additional conditions that, when holding, allow the production of the specific effect that
they control. For instance, in order to pay by credit card it is necessary to own a credit
card (precondition to the action). If a credit card owner uses it for paying, the
payment will be done only if the card is valid (conditional effect). For example, in [
        <xref ref-type="bibr" rid="ref11 ref9">11, 9</xref>
        ]
actions have no preconditions of any kind, in [
        <xref ref-type="bibr" rid="ref10 ref20">10, 20</xref>
        ] actions have both preconditions
to the executability and conditional effects, while [34] uses only preconditions to the
execution of actions. Given these basic notions, let us, now, focus on regulative rules
and overview the most relevant works in the context of commitment-based interaction
protocols, in order to compare and discuss the proposed models, which are graphically
summarized in Fig. 1 and Fig. 2.
      </p>
      <p>
        Chopra and Singh. ([
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], Fig. 1(a)) Chopra and Singh introduce the distinction
between constitutive and regulative specifications in the definition of commitment
protocols. Each agent is publicly described by the effects of the messages it can send,
which make the constitutive specification of the agent. Such specifications allow agents
to agree on the meaning of their communications. Instead, the regulative specification
rules the data flow among messages. For instance, the constitutive specification of the
action buy could be the commitment to pay the merchant, while the regulative
specification may require that goods are sent only after the payment has been done. In that
work (personal communication) and in [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] the regulative specification is based on the
actions themselves; in particular, the flow is controlled by the preconditions to the
(non)executability of the actions. So, in order to impose that sending goods should follow
payment, the action send-goods should have as a precondition a literal that is made true
as an effect of the action pay. This solution (which is adopted also in works like [
        <xref ref-type="bibr" rid="ref19 ref9">19, 35,
36, 9, 34</xref>
        ]) is characterized by a strong localization of the regulative specification. Both
the constitutive and the regulative specifications are indistinguishable (being both based
on actions, see Fig. 1(a)). The problem is that by doing so the definition of an action
becomes dependent on the protocol where it is used. This limits the openness of the
system and in particular complicates the re-use of software (the agents’ actions). Actions,
in fact, are defined not only for what concerns their effects (constitutive specification)
but also taking into account their context of use. When changing context (protocol), the
regulative specification inside the actions is to be updated or new, specific actions are to
be defined. Analogously, when adding a new action, it is necessary to enrich it with the
correct regulative specification. In our view, a greater decoupling between the actions
and the regulative specification would have the advantage of facilitating the re-use of
actions because it would allow the avoidance of the over-specification that is necessary
to impose an ordering among actions.
      </p>
      <p>
        Preferences and dependencies. ([
        <xref ref-type="bibr" rid="ref22">22</xref>
        ], Fig. 1(b) and [
        <xref ref-type="bibr" rid="ref30">30</xref>
        ], Fig. 1(c), respectively) Mallya
and Singh [
        <xref ref-type="bibr" rid="ref22">22</xref>
        ] propose to order the possible executions according to a set of preferences
that take into account the policies of the various parties. No execution is strictly
forbidden but a preference criterion is specified. Differently than above, here the constitutive
specification is given in terms of commitments but the preference rules are given in
terms of actions. Preferences do not precisely correspond to regulatives rules because
they specify selection policies rather than constraining the execution flow.
Nevertheless, giving them in terms of actions makes the specification less flexible and less easily
adaptable or open. The same limits, Fig. 1(c), can be ascribed to the work to which [
        <xref ref-type="bibr" rid="ref22">22</xref>
        ]
is inspired, i.e. [
        <xref ref-type="bibr" rid="ref30">30</xref>
        ], although in this work it is possible to recognize the introduction of
a regulative specification, based on the before relation applied to events.
ConDec. ([
        <xref ref-type="bibr" rid="ref21 ref25 ref26 ref8">26, 25, 8, 21</xref>
        ], Fig. 2(a)) Pesic and van der Aalst propose an approach that is
radically opposite to the one by Chopra and Singh [
        <xref ref-type="bibr" rid="ref26">26</xref>
        ]. In this approach, which totally
lacks of a constitutive component (and does not build on commitments nor is set in
the agents framework), the declarative language ConDec is proposed for representing
business processes which, though not exactly interaction protocols, specify the expected
behavior of a set of interacting parties by constraining the execution of their tasks. The
regulative rules are a first-class element of the protocol which are given by means of an
ad hoc declarative language. They are not local to single actions as in Fig. 1(a), rather
they are constraints that rule the flow of activity execution (activity in UML sense).
In [
        <xref ref-type="bibr" rid="ref21 ref25 ref8">25, 8, 21</xref>
        ], the authors use this approach to specify interaction protocols and service
choreographies. To this aim, they integrate ConDec with SCIFF thus giving a semantics
to actions that is based on expectations.
      </p>
      <p>
        Still, however, in these proposals there is a too tight connection between the
regulative rules and actions because such rules define temporal constraints over actions
(events), see Fig. 2(a). This, in our opinion, clashes with the openness of MAS. Let us
explain our view with an example. Let us suppose that payment should occur before
sending the goods, and that the protocol foresees the actions pay-by-credit-card and
send-goods. Then, it will specify that pay-by-credit-card must occur before send-goods.
Now, if a client arrives which can pay cash, it will not be in condition to take part to the
interaction unless the regulative specification is changed by adding a rule that says that
paying cash should occur before sending the goods. This should be done even though
the action has the same semantics of pay-by-credit-card in terms of commitments. The
need of modifying the regulative specification (even in the case when actions have the
same semantics!), gives an undesired rigidity to the protocol. Problems arise also in
the case an agent can execute a sequence of actions which altogether implement one of
those foreseen by the protocol. The problem is that the regulative specification is given
in terms of actions, so, when changing the actions names we need to change
regulative specifications as well. It is also easy to make mistakes by forgetting to update the
regulative part when a new action is changed or when its semantics is changed.
Fornara and Colombetti. ([
        <xref ref-type="bibr" rid="ref15 ref17 ref18">15, 18, 17</xref>
        ], Fig. 2(b)) Fornara and Colombetti define a
commitment-based semantics for the speech acts of agent communication languages,
like FIPA, and then use interaction diagrams to define agent interaction protocols. In
this proposal, the social actions are represented by the speech acts and the constitutive
specification is given in terms of commitments. The choice of relying on interaction
diagrams is, however, very strong because it forces the ordering of action executions,
loosing, in our opinion the flexibility aimed at by the adoption of commitments.
Summary. The distinction between a regulative and a constitutive specification is surely
interesting but the current proposals show some limits in the realization of this model,
each with its pros and cons. Fornara and Colombetti’s proposal is too rigid: the use
of interaction diagrams conflicts with the desirable flexibility of commitments. In this
respect, ConDec’s use of constraints is better: the declarative approach that is proposed
is aligned with the declarative nature of commitments. The problem is that constraints
are defined in terms of performing actions rather than of bringing about conditions.
Also Chopra and Singh propose an implementation where the regulative specification
is given on top of actions: again, while commitments are given on conditions and not on
the actions that should bring them about, constraints are posed on the action execution,
with the result that modularity is not obtained. The same holds for [
        <xref ref-type="bibr" rid="ref19">34, 19, 35, 36</xref>
        ].
      </p>
      <p>
        Our proposal aims at overcoming the listed limits. As in [
        <xref ref-type="bibr" rid="ref18 ref22">22, 18</xref>
        ] we propose the
use of commitments to give constitutive specifications. As in [
        <xref ref-type="bibr" rid="ref25 ref26">26, 25</xref>
        ] we propose the
use of a declarative language, 2CL, for capturing constraints that rule the execution
flow. The difference is that in our proposal such constraints relate commitments and
not actions (see Fig. 3). The consequent greater modularity brings along the mentioned
advantages: an easier re-use of actions in different contexts, an easier re-use of
protocols with different actors, greater openness, better support to interoperability checks,
simpler customization of protocols. The next section illustrates our proposal for the
representation of regulative specifications.
3
      </p>
    </sec>
    <sec id="sec-4">
      <title>Commitment Protocols: A Decoupled Approach</title>
      <p>In this work, we propose an approach to the definition of commitment-based interaction
protocols which includes a constitutive specification, that defines the meaning of actions
for all the agents in the system, and a regulative specification, which constrains the
possible evolutions of the social state. Both are defined based on commitments.
Definition 1 (Interaction protocol). An interaction protocol P is a tuple hRo, F, A, Ci,
where Ro is a set of roles, identifying the interacting parties, F is a set of literals
(including commitments) that can occur in the social state, A is a set of actions, and C is
a set of constraints.</p>
      <p>
        The set of social actions A, defined on F and on Ro, forms the constitutive specification
of the protocol, while the set of constraints C, defined on F and on Ro too, forms
the regulative specification of the protocol. The constitutive specification of an action,
similarly to [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], defines its meaning in terms of how it affects the social state by adding
or removing literals or by performing operations on the commitments (the usual create,
release, delete, etc., see [
        <xref ref-type="bibr" rid="ref28">28, 36</xref>
        ]). The constitutive specification follows the grammar:
      </p>
      <sec id="sec-4-1">
        <title>A → (Action means Operation)+</title>
        <p>Action → protocolAction([paramList])
Operation → Op(commitment) | f act | Operation ∧ Operation</p>
        <p>Op → CREATE | DELETE | RELEASE | DELEGATE | ASSIGN
where protocolAction is the name of an interactive action of the protocol; paramList
denotes the possible parameter list of the action; Op is one of the operations on
commitments; commitment is a commitment of form C(x, y, r, p), as specified in Section 2
(see also [9, page 49]), where x and y are roles in Ro and r and p are formulas in
disjunctive normal form of propositional literals in F ; and fact is a positive or negative
proposition that does not concern commitments and which contributes to the social state
(they are the conditions that are brought about – when necessary they are enriched by
two parameters: the actor and the recipient). For instance, the action cfp of the contract
net protocol (which is used as an example below) is given in this way: cf p(i, p) means
CREATE(C(i, p, assigned task(i, p))), i.e. its effect is to add to the social state the
commitment C(i, p, assigned task(i, p)) by which the initiator (role i) commits to a
participant (role p) to assign a task of interest. Not necessarily the task will be assigned
to the p at issue; if many participants propose to solve a task, the choice depends on the
criteria implemented by the specific initiator, which are not modeled by the protocol.</p>
        <p>In order to represent the regulative specification, we propose a constraint-based
representation following the grammar:</p>
      </sec>
      <sec id="sec-4-2">
        <title>C → (Disj op Disj)+</title>
        <p>Disj → Conj ∨ Disj | Conj</p>
        <p>Conj → literal ∧ Conj | literal
C, see Def. 1, is a set of constraints of the form A op B, where A and B are formulas
of literals in disjunctive normal form and op is one of the operators in Table 1; literal
can be either a commitment or a positive or negative proposition (where negation means
that a certain literal does not hold in the social state). Such constraints rule the evolution
of the social state by imposing specific patterns on how states can progress. For instance,
C(i, p, assigned task(i, p)) −.• (ref used task(p, i) ∨ C(p, i, solved task(p, i)))
expresses the fact that a participant cannot refuse a task nor it is allowed to commit to solve
it before the initiator has taken a commitment, stating its intention to assign the task to
that participant. Notice that the constraint does not specify which actions should bring
these conditions about, in fact, constraints do not rule the occurrence of events. The
declarative nature of the specification adds flexibility w.r.t. an algorithmic specification,
in fact, while the latter specifies all the allowed evolutions, declarative constraints allow
any evolution that respects the relations involving the specified literals.</p>
        <p>
          We named the language for representing the regulative specification 2CL (the
acronym stands for “Constraints among Commitments Language”) . The names of the
operators and the graphical format, used in Section 4, are inspired by ConDec [
          <xref ref-type="bibr" rid="ref26">26</xref>
          ]. We
remark again that the main difference is that constraints are defined over commitments
and facts, while in ConDec they are defined on actions. This distinction motivates the
differences both on the names of the operators (e.g. before instead of precedence) and
on the LTL translation of them. For allowing the application of reasoning techniques
(e.g. to check if an interaction is respecting the protocol, to build sequences of actions
that respect the protocol, or to verify properties of the system) it is necessary to give
the operators a semantics that can be reasoned about. To this aim, we use linear
temporal logic (LTL, [
          <xref ref-type="bibr" rid="ref13">13</xref>
          ]), which includes temporal operators like next-time (°), eventually
(3), always (2), weak until (U). Let us describe the various operators. For simplicity
the description are given on single literals rather than formulas.
        </p>
        <p>Correlation: this operator captures the fact that in an execution where a occurs, also b
occurs but there is no temporal relation between the two. Its negation means that if
a occurs in some execution, b must not occur.</p>
        <p>Co-existence: the mutual correlation between a and b. Its negation captures the mutual
exclusion of a and b. Notice that in LTL the semantics of negated co-existence is
equivalent to the semantics of negated correlation.</p>
        <p>Response: this is a temporal relation, stating that if a occurs b must hold at least once
afterwards (or in the same state). It does not matter if b already held before a. The
negation states that if a holds, b cannot hold in the same state or after.</p>
        <p>Before: this is a temporal relation, stating that b cannot hold until a becomes true.</p>
        <p>Afterwards, it is not necessary that b becomes true. The negation of a −.• b is
equivalent to b −.• a.</p>
        <p>Cause: this operator states that if a occurs, after b must occur at least once and b cannot
occur before a. The negation states that if a occurs, b cannot follow it and if b
occurs, a is not allowed to occur before.</p>
        <p>Premise: is a stronger temporal relation concerning subsequent states, stating that a
must hold in all the states immediately preceding one state in which b holds. The
negation states that a must never hold in a state that immediately precedes one
where b holds.</p>
        <p>Notice that the negated operators semantics (column 5) not always corresponds to the
negation of the semantics of the corresponding positive operator (column 3). This is
due to the intention of capturing the intuitive meaning of negations. We show this need
by means of a couple of examples. For what concerns correlation, the negation of the
formula in column 3, which is 3a ∧ ¬3b, is too strong because it says that a must hold
sooner or later while b cannot hold. What we mean by negated coexistence, instead, is
that if a becomes true then b must not occur in the execution. For completeness, the
semantics of negated correlation is not equivalent to the semantics of a •− ¬b.</p>
        <p>For what concerns premise, by negating the semantics in column 3 we obtain 3(°b∧
¬a) which says that b occurs in some state and a does not occur in the previous state.
Instead, the intended meaning is that a does not have to hold in the states that precede
those in which b holds (but b does not necessarily have to hold). Analogous
considerations can be drawn for the other operators. The choice of sticking to the intuitive
semantics of the operators is done to give the user only seven basic operators. Had
we defined the negated operators semantics by negating the semantics of the positive
operators, we would have defined fourteen different operators.
3.1</p>
        <sec id="sec-4-2-1">
          <title>Constraints, conditional commitments and normative aspects</title>
          <p>Is there any relationship between conditional commitments and constraints among
commitments? Indeed, the two have different natures. A conditional commitment C(x, y, r,
p) does not capture a temporal relation: in fact, p can occur before r becomes true or
even before the commitment is ever taken. When the conditional commitment holds, r
immediately triggers C(x, y, p) because this behavior is intrinsic to the commitment’s
life cycle (see also [34], where the complete transition diagram is reported). The
expressions that we represent in 2CL, instead, define properties of the interaction, that are
to be checked against the evolution of the social state.</p>
          <p>
            For what concerns the violation of commitments and of constraints, according to
Singh [
            <xref ref-type="bibr" rid="ref28">28</xref>
            ], commitments have a normative nature. Agents can freely decide if and when
committing to do something but when they do, they are obliged to fulfill their
commitments. Consider the conditional commitment: C(p, i, assigned task(i, p), solved
task(p,i) XOR f ailed(p, i)). Here the participant p commits to either do some work or
declare a failure, if the initiator i assign it a task (assigned task(i, p)). The problem
is that, since the participant is free to decide whether or not taking the commitment,
the initiator has no guarantee that its decision to assign a task will be followed by
an answer by the participant because there is no guarantee that the commitment will
ever be taken. If, instead, we use one of our constraints, e.g. assigned task(i, p) •−.•
solved task(p, i) XOR f ailed(p, i), imposing that after the decision of i to assign a
task (assigned task(i, p)), the participant p must either solve it or declare a failure
(solved task(p, i) XOR f ailed(p, i)), the initiator has some guarantees about the
behavior of the participant. The initiator knows this before starting the interaction, because
the protocol is public, and can use this information to decide whether to use the
protocol. Guarantees, however, are given only if constraints have a normative nature: the
violation of a constraint, as well as the violation of a commitment, pushes the agent
out of the protocol. In case of constraints, being out of the protocol does not imply that
the interaction will be unsuccessful but only that the participants lose the guarantee that
all the parties involved will achieve an effective result. By sticking to the constraints,
the agents waive part of their autonomy but they do this autonomously, because they
consider it advantageous w.r.t. interacting without rules.
4
          </p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Tailoring Protocols to different needs</title>
      <p>
        In this section, we show the use of the proposed model by, first, representing the
wellknown Contract Net Protocol (CNP for short) [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ] and, then, by showing how easy it
is to produce variants by playing with its regulative specification, separately from the
constitutive specification of its actions. Briefly, CNP includes two roles, the initiator (i
in the following) and a participant (p). The initiator calls for proposals. The participant
may send a proposal or refuse to do it. When a proposal is received, the initiator may
either reject or accept it. Notice that, for the sake of simplicity, we do not model the
exchange of information concerning the proposal itself but only the interaction concerning
the task assignment and solution. We report the CNP as represented according to our
proposal, by giving its constitutive specification followed by its regulative specification.
Constitutive specification of CNP. The actions of CNP, as expressed according to the
grammar in Section 3, are:
(a) cf p(i, p) means CREATE(C(i, p, assigned task(i, p)))
(b) propose(p, i) means CREATE(C(p, i, solved task(p, i)))
(c) ref use(p, i) means ref used task(p, i) ∧ RELEASE(C(i, p, assigned task(i, p)))
(d) accept(i, p) means assigned task(i, p)
(e) reject(i, p) means rejected proposal(i, p) ∧ DELETE(C(i, p, assigned task(i,
p))) ∧ RELEASE(C(p, i, solved task(p, i)))
(f) inf orm done(p, i) means solved task(p, i)
(g) f ailure(p, i) means f ailed(p, i) ∧ DELETE(C(p, i, solved task(p, i)))
Since such definitions are quite straightforward, we get into the details of just a couple
of them. The effect of action cfp is to create the commitment C(i, p, assigned task(i,
p)). Intuitively, this commitment states the resolution of the initiator to assign a task to
a participant because it needs someone to solve it. This does not mean that, at the end,
the task will be assigned to that participant. Indeed, during the execution the participant
may refuse to solve the task or the initiator may reject its proposal because, for example,
it is not convenient. The action ref use(p, i) (the participant refuses to solve a task),
instead, has, as effect, the action RELEASE(C(i, p, assigned task(i, p))), by which
the participant releases the initiator from the commitment of assigning a task to it, and
the fact ref used task(p, i), whose meaning is clear.
      </p>
      <p>Regulative specification of CNP. The regulative rules of CNP, as expressed according
to the grammar in Section 3, are:
c1: C(i, p, assigned task(i, p)) •−.• C(p, i, solved task(p, i)) XOR ref used task(p, i)
c2: C(p, i, solved task(p, i)) •−.• rejected proposal(i, p) XOR assigned task(i, p)
c3: assigned task(i, p) •−.• solved task(p, i) XOR f ailed(p, i)
initiator declares its intention to assign a task (node n1, C(i, p, assigned task(i, p))).
If this happens, afterwards the participant takes its decision and alternatively refuses or
states its intention to solve the task. This is represented by the fact that the node n1 is
connected to the nodes n2 (C(p, i, solved task(p, i))), and n3 (ref used task(p, i)):
n2 and n3 are alternative evolutions of the social state after n1. The connector n4
denotes the exclusive or of the two. It is a graphical simplification of the and-or formula
implementing the “exclusive or”. The arrow used (of kind a •−.• b) represents the fact
that when the initiator must assign a task, the participant necessarily has to either refuse
the task or take the commitment to solve it. It is not obliged to do it as the next step
of its execution but sooner or later it must take one of the two ways. The specification
foresees that the participant cannot take the initiative of proposing to solve a task (or of
refusing to do something) if the initiator has not declared that there is a task to solve.
This is the intuitive meaning of the circles at the two sides of the arrow c1.</p>
      <p>Notice that we have not mentioned which actions should be executed to change
the social state. Actually, we do not care. Any action, whose effect is compatible with
the schema of evolution of the social state reported above is feasible. In the same way
it is not necessary, in commitment protocols, to say which action to take to satisfy
a commitment. Moreover, the transition from one state to one of its next (w.r.t. the
description given by regulative specification) states may require the application of many
actions (not necessarily one). The regulative specification does not give any procedure
for achieving the social state change, that it captures. In fact, constraints on the evolution
of the social state are independent from the actions that are used by the agents. Both,
however, are specified on top of the literals in the social state.</p>
      <p>If the interaction continues because the participant has proposed to solve the task,
the initiator must either reject the proposal or accept it and assign the task to the
participant, which, in this case, will try to solve the task and give back to the initiator an
answer (the solution or the information that it has failed). The arrows in the graph
between nodes n2 and the alternative between n5 and n6, on a side, and between n6 and
the alternative between n8 and n9 are again of the kind •−.• (causality operator).
Let us show the versatility of the proposed representation by showing how a designer
can easily modify the specification of CNP, given above, so as to build new protocols
which adapt to different conditions. All the variations are produced by working
exclusively on the regulative specification without modifying the actions. Of course, it is
possible to do the opposite or to modify both parts if needed.</p>
      <p>Lazy and zealous participant. (Fig. 5(a), Fig. 5(b)) The first two simple variants are
obtained by changing a single arrow with another operator from Table 1. With reference
to Fig. 5(a), if we use a before relation (−.•), the participant would not be obliged to
answer (it is allowed to have a lazy behavior). In constraints the whole variant is:
c1: C(i, p, assigned task(i, p)) −.• C(p, i, solved task(p, i)) XOR ref used task(p, i)
c2: C(p, i, solved task(p, i)) •−.• rejected proposal(i, p) XOR assigned task(i, p)
c3: assigned task(i, p) •−.• solved task(p, i) XOR f ailed(p, i)
Instead, Fig. 5(b), if a response (•−. ) is used, the participant can also take the initiative
to solve a task even though the initiator has not made any request (zealous participant):
c1: C(i, p, assigned task(i, p)) •−. C(p, i, solved task(p, i)) XOR ref used task(p, i)
c2: C(p, i, solved task(p, i)) •−.• rejected proposal(i, p) XOR assigned task(i, p)
c3: assigned task(i, p) •−.• solved task(p, i) XOR f ailed(p, i)
These two variants correspond to protocols that differ from CNP but that can easily be
obtained by working at the level of constraints among commitments.</p>
      <p>CNP with Anticipated Failure (Fig. 5(c)) The next context that we consider is a call
for bids, where an initiator publishes an open call, e.g. in an official gazette, that does
not require the subscribers to the gazette to answer. Fig. 5(c) shows the new protocol:
the fact that the participant is not obliged to send a bid is captured by the constraint
c1, which is a before (−.•) instead of being a cause (•−.•, in Fig. 4). We have further
modified the CNP by changing the constraint c3 in Fig. 4, in order to capture the fact
that a participant can notify a failure in the task solution also in the case in which the
task has not been assigned to it yet but, for some reason, it has found out that it has
become impossible for it to proceed with the solution, in case the task is assigned to it.
Instead, it is not allowed to communicate the solution until the task is assigned to it. The
new protocol can be obtained by modifying the regulative specification as in Fig. 5(c).
In rules:
c1: C(i, p, assigned task(i, p)) −.• C(p, i, solved task(p, i)) XOR ref used task(p, i)
c2: C(p, i, solved task(p, i)) •−.• rejected proposal(i, p) XOR assigned task(i, p)
c3: assigned task(i, p) •−. solved task(p, i) XOR f ailed(p, i)
c4: assigned task(i, p) −.• solved task(p, i)
The changes concern the constraints after node n6. In the new version, instead of
having simply a cause constraint, we have a response (•−. ). Response is a softer
constraint because it does not forbid to the alternatives specified by n10 to hold before
assigned task(i, p). For this reason, in order to enforce that the solution is
communicated only after the assignment, another constraint is to be added (c4). In this way,
failure can be notified at any moment.</p>
      <p>(a)
(b)
(c)
(d)
Fig. 5. (a) Lazy Participant; (b) Zealous Participant; (c) CNP with Anticipated Failure; (d) Soft
CNP.</p>
      <p>Soft CNP. (Fig. 5(d)) The last example is a very soft interaction protocol that,
differently than the previous ones, expresses just a few regulative constraints, leaving a much
greater freedom of behavior to the initiator and to the participant.
c1: C(p, i, solved task(p, i)) −.• assigned task(i, p)
c2: ref used task(p, i) •−6• C(p, i, solved task(p, i))
c3: rejected proposal(i, p) •−6• assigned task(i, p)
This example also shows the use of negative constraints. The only constraint that is
imposed on the evolution of the social state is that a task cannot be assigned to a
participant who has not yet committed to solve it. Moreover, there are two negative constraints
(of kind •−6•) stating that proposal assignment and rejection are mutually exclusive (c3),
and that the refusal of a task is mutually exclusive to the commitment to solve it (c2).
So, for instance, a participant can express its intention to solve a task for which no call
has been made, and it is also possible for it to give a solution before any assignment of
the task has been made to it. On the other hand, the initiator can ignore the participant
even though it has committed to solve the task by avoiding to answer to it. It can call
for proposals even if it already has a commitment by the participant, and it can reject a
participant even though it has not made any proposal. It is not even necessary that the
initiator commits to assign the task.</p>
    </sec>
    <sec id="sec-6">
      <title>Conclusion and future work</title>
      <p>
        Constitutive and regulative specifications have been recognized as fundamental
components of the interaction based on communication starting from Searle [
        <xref ref-type="bibr" rid="ref27 ref7">27, 7</xref>
        ], and
including various authors in the Multi-Agent community, e.g. [
        <xref ref-type="bibr" rid="ref11 ref6 ref9">11, 9, 6</xref>
        ]. In this paper
we have presented a model of commitment-based interaction protocols that includes an
explicit representation of both constitutive and regulative specifications. From a
graphical point of view, the language 2CL is inspired to [
        <xref ref-type="bibr" rid="ref26 ref4">26, 4</xref>
        ]. The semantics of the operators
is based on linear temporal logic due to the fact that this logic is well-known and simple
and opens the way to possible integrations with model checkers like SPIN or NuSMV.
We mean, however, to study both alternatives to LTL (such as CTL*) and alternatives
to model checking techniques (such as SAT solvers and ASP).
      </p>
      <p>
        The proposal includes as special cases some of the representation models discussed
in Section 2. Specifically, we can model the proposal by Chopra and Singh [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] as well
as the models adopted in [
        <xref ref-type="bibr" rid="ref19">19, 36, 34</xref>
        ] which follow the same principles, by introducing
for each action a literal that is univocally associated to it, as an effect of the action, and,
then, to define constraints (typically of kind premise, .. −) among these literals. The use
of constraints of kind premise also allows the designer to specify strict sequences of
action executions, as in [
        <xref ref-type="bibr" rid="ref15 ref16 ref18">16, 18, 15</xref>
        ]. Last but not the least, the proposal overcomes the
limits of [
        <xref ref-type="bibr" rid="ref21 ref25 ref26 ref30 ref8">26, 30, 25, 8, 21</xref>
        ] because the regulative specification rules the evolution of the
social state and not the execution of actions/events. However, if the designer wishes to
constrain the execution of specific actions, he/she can do it, as explained.
      </p>
      <p>
        An approach similar to commitment-based protocols is the one introduced in [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ],
where expectation-based protocols are presented. Expectations concern events expected
to happen (or not to happen) and can be associated to time points. Protocols are specified
by constraining the times at which events occur. As for the previous works, the limit of
this approach is that it works directly on events (i.e. actions); by constraining actions the
approach lacks the openness discussed in the Introduction and in the discussion about
ConDec in Section 2. On the other hand, our proposal does not handle time explicitly
so we cannot yet represent and handle timeouts and also compensation mechanisms.
The aim of this paper is, indeed, to present the idea of an explicit, declarative, and
decoupled representation of both the constitutive and the regulative specifications. We
mean to tackle also issues concerning time, deadlines, faults and compensation, like in
[
        <xref ref-type="bibr" rid="ref32">32</xref>
        ] (where commitments are implemented by means of expectations), in future work.
      </p>
      <p>
        The adaptation of commitment-based protocols to different contexts of use has been
tackled in [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]. The authors show how declarative approaches suit well this aim. Our
proposal is set along this line. In fact, not only the constitutive rules are given in a
declarative way but also the regulative specification is made of declarative constraints
and it is possible to contextualize it by adding or removing constraints. The advantage
w.r.t. [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] is the modularity of the two specifications discussed along the paper.
      </p>
      <p>
        The work in [
        <xref ref-type="bibr" rid="ref24">24</xref>
        ] contains a comparison of various approaches to interaction
protocols, including but not limited to commitment-based protocols. Specifically, also
normative systems, algebraic-operational approaches (like RASA [
        <xref ref-type="bibr" rid="ref23">23</xref>
        ]), and Petri nets are
considered. The comparison is done along many directions. The authors confirm our
opinion that declarative approaches (like commitment-based ones) are very flexible.
However, they claim that they are less readable (and sometimes more verbose) than
algorithmic approaches. To support this consideration they cite some of the major
existing tools for the designer (like AgentUML), which are algorithmic. For verbosity,
they cite the CNP representation in [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] which consists of seventeen rules. We underline
that our regulative representation of CNP consists instead of three rules only. The
constitutive specification is made of seven rules (because there are seven actions). For what
concerns commitment protocols, the difficulty in reading declarative specifications is,
in our opinion, due to the lack of separation between the constitutive and the regulative
specifications that many approaches show. Moreover, as [
        <xref ref-type="bibr" rid="ref33">33</xref>
        ] notices, there is a lack
of graphical intuitive representations oriented to designers. We have tried to overcome
these problems by decoupling the regulative and the constitutive specifications and by
giving a graphical representation. This representation has the advantage of giving the
perception of a flow in the execution, remaining however at a what rather than at a
how level (no-flow in-flow). This representation also supports the compositionality of
the protocols. In fact, to put it simply, in order to produce a new protocol starting from
existing ones, it is sufficient to draw together the sets of constraints of interest and
produce a bigger graph without any effort. Protocols can, then, be designed bottom-up.
This aspects will further be studied as future work.
      </p>
      <sec id="sec-6-1">
        <title>Acknowledgements</title>
        <p>The authors would like to thank the reviewers twice for the helpful comments. This
research has partially been funded by “Regione Piemonte” through the project ICT4LAW.
34. M. Winikoff, W. Liu, and J. Harland. Enhancing commitment machines. In Proc. of DALT,
volume 3476 of LNCS, pages 198–220, 2004.
35. P. Yolum and M. P. Singh. Commitment machines. In Proc. of ATAL, volume 2333 of LNCS,
pages 235–247. Springer, 2001.
36. P. Yolum and M. P. Singh. Designing and executing protocols using the event calculus. In
Agents, pages 27–28, 2001.</p>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <source>Proc. of the 2nd Multi-Agent Logics, Languages, and Organisations Federated Workshops</source>
          , volume
          <volume>494</volume>
          <source>of CEUR Workshop Proceedings. CEUR-WS.org</source>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <given-names>Declarative</given-names>
            <surname>Agent</surname>
          </string-name>
          Languages and
          <string-name>
            <surname>Technologies</surname>
            <given-names>VII</given-names>
          </string-name>
          ,
          <source>7th Int. Workshop, DALT</source>
          <year>2009</year>
          , volume
          <volume>5948</volume>
          of Lecture Notes in Computer Science. Springer,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <given-names>M.</given-names>
            <surname>Alberti</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Daolio</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Torroni</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Gavanelli</surname>
          </string-name>
          , E. Lamma, and
          <string-name>
            <given-names>P.</given-names>
            <surname>Mello</surname>
          </string-name>
          .
          <article-title>Specification and verification of agent interaction protocols in a logic-based system</article-title>
          .
          <source>In Proc. of the SAC</source>
          <year>2004</year>
          , pages
          <fpage>72</fpage>
          -
          <lpage>78</lpage>
          . ACM,
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <given-names>M.</given-names>
            <surname>Baldoni</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Baroglio</surname>
          </string-name>
          , I. Brunkhorst,
          <string-name>
            <given-names>N.</given-names>
            <surname>Henze</surname>
          </string-name>
          , E. Marengo, and
          <string-name>
            <given-names>V.</given-names>
            <surname>Patti</surname>
          </string-name>
          .
          <article-title>Constraint Modeling for Curriculum Planning and Validation</article-title>
          .
          <source>Int. J. of Interactive Learning Environments</source>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <given-names>M.</given-names>
            <surname>Baldoni</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Baroglio</surname>
          </string-name>
          , and
          <string-name>
            <given-names>E.</given-names>
            <surname>Marengo</surname>
          </string-name>
          .
          <article-title>Commitment-based Protocols with Behavioral Rules and Correctness Properties of MAS</article-title>
          .
          <source>In Proc. of International Workshop on Declarative Agent Languages and Technologies</source>
          ,
          <string-name>
            <surname>DALT</surname>
          </string-name>
          <year>2010</year>
          , Toronto, Canada, May
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <given-names>G.</given-names>
            <surname>Boella</surname>
          </string-name>
          and
          <string-name>
            <surname>L. W. N. van der Torre. Regulative</surname>
          </string-name>
          <article-title>and constitutive norms in normative multiagent systems</article-title>
          .
          <source>In Proc. of KR</source>
          , pages
          <fpage>255</fpage>
          -
          <lpage>266</lpage>
          . AAAI Press,
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <given-names>C.</given-names>
            <surname>Cherry</surname>
          </string-name>
          .
          <article-title>Regulative rules and constitutive rules</article-title>
          .
          <source>The Philosophical Quarterly</source>
          ,
          <volume>23</volume>
          (
          <issue>93</issue>
          ):
          <fpage>301</fpage>
          -
          <lpage>315</lpage>
          ,
          <year>1973</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <given-names>F.</given-names>
            <surname>Chesani</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Mello</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Montali</surname>
          </string-name>
          , and
          <string-name>
            <given-names>P.</given-names>
            <surname>Torroni. Verifying</surname>
          </string-name>
          a
          <article-title>-priori the composition of declarative specified services</article-title>
          .
          <source>In MALLOW [1].</source>
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <given-names>A.K.</given-names>
            <surname>Chopra</surname>
          </string-name>
          . Commitment Alignment: Semantics, Patterns, and
          <article-title>Decision Procedures for Distributed Computing</article-title>
          .
          <source>PhD thesis</source>
          , North Carolina State University, Raleigh,
          <string-name>
            <surname>NC</surname>
          </string-name>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>A.K. Chopra</surname>
            and
            <given-names>M. P.</given-names>
          </string-name>
          <string-name>
            <surname>Singh</surname>
          </string-name>
          .
          <article-title>Contextualizing commitment protocol</article-title>
          .
          <source>In Proc. of AAMAS'06</source>
          , pages
          <fpage>1345</fpage>
          -
          <lpage>1352</lpage>
          . ACM,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>A.K. Chopra</surname>
            and
            <given-names>M. P.</given-names>
          </string-name>
          <string-name>
            <surname>Singh</surname>
          </string-name>
          .
          <article-title>Constitutive interoperability</article-title>
          .
          <source>In Proc. of AAMAS'08</source>
          , pages
          <fpage>797</fpage>
          -
          <lpage>804</lpage>
          ,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>A.K. Chopra</surname>
            and
            <given-names>M. P.</given-names>
          </string-name>
          <string-name>
            <surname>Singh</surname>
          </string-name>
          .
          <article-title>Multiagent commitment alignment</article-title>
          .
          <source>In Proc. of AAMAS'09</source>
          , pages
          <fpage>937</fpage>
          -
          <lpage>944</lpage>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <given-names>E. A.</given-names>
            <surname>Emerson</surname>
          </string-name>
          .
          <article-title>Temporal and Modal Logic</article-title>
          .
          <source>In Handbook of Theoretical Computer Science</source>
          , volume B, pages
          <fpage>997</fpage>
          -
          <lpage>1072</lpage>
          . Elsevier,
          <year>1990</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <article-title>Foundation for Intelligent Physical Agents</article-title>
          .
          <source>FIPA Contract Net Interaction Protocol Specification</source>
          ,
          <year>December 2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <given-names>N.</given-names>
            <surname>Fornara</surname>
          </string-name>
          .
          <article-title>Interaction and Communication among Autonomous Agents in Multiagent Systems</article-title>
          .
          <source>PhD thesis</source>
          , Universita` della Svizzera italiana,
          <source>Facolta` di Scienze della Comunicazione</source>
          ,
          <year>June 2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <given-names>N.</given-names>
            <surname>Fornara</surname>
          </string-name>
          and
          <string-name>
            <given-names>M.</given-names>
            <surname>Colombetti</surname>
          </string-name>
          .
          <article-title>Defining interaction protocols using a commitment-based agent communication language</article-title>
          .
          <source>In Proc. of AAMAS'03</source>
          , pages
          <fpage>520</fpage>
          -
          <lpage>527</lpage>
          ,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <given-names>N.</given-names>
            <surname>Fornara</surname>
          </string-name>
          and
          <string-name>
            <given-names>M.</given-names>
            <surname>Colombetti</surname>
          </string-name>
          .
          <article-title>Protocol Specification Using a Commitment Based ACL</article-title>
          .
          <source>In ACL</source>
          <year>2003</year>
          , volume
          <volume>2922</volume>
          <source>of LNCS</source>
          , pages
          <fpage>108</fpage>
          -
          <lpage>127</lpage>
          . Springer,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <given-names>N.</given-names>
            <surname>Fornara</surname>
          </string-name>
          and
          <string-name>
            <given-names>M.</given-names>
            <surname>Colombetti</surname>
          </string-name>
          . A
          <string-name>
            <surname>Commitment-Based Approach</surname>
          </string-name>
          To Agent Communication.
          <source>Applied Artificial Intelligence</source>
          ,
          <volume>18</volume>
          (
          <fpage>9</fpage>
          -10):
          <fpage>853</fpage>
          -
          <lpage>866</lpage>
          ,
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19. L.
          <string-name>
            <surname>Giordano</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          <string-name>
            <surname>Martelli</surname>
            , and
            <given-names>C.</given-names>
          </string-name>
          <string-name>
            <surname>Schwind</surname>
          </string-name>
          .
          <article-title>Specifying and verifying interaction protocols in a temporal action logic</article-title>
          .
          <source>J. Applied Logic</source>
          ,
          <volume>5</volume>
          (
          <issue>2</issue>
          ):
          <fpage>214</fpage>
          -
          <lpage>234</lpage>
          ,
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          20.
          <string-name>
            <given-names>O</given-names>
            <surname>¨ . Kafali</surname>
          </string-name>
          and
          <string-name>
            <given-names>P.</given-names>
            <surname>Yolum</surname>
          </string-name>
          .
          <article-title>Detecting exceptions in commitment protocols: Discovering hidden states</article-title>
          .
          <source>In MALLOW [1].</source>
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          21.
          <string-name>
            <surname>Montali</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Pesic</surname>
          </string-name>
          ,
          <string-name>
            <surname>W.M. P. van der Aalst</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          <string-name>
            <surname>Chesani</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          <string-name>
            <surname>Mello</surname>
            , and
            <given-names>S.</given-names>
          </string-name>
          <string-name>
            <surname>Storari</surname>
          </string-name>
          .
          <article-title>Declarative specification and verification of service choreographies</article-title>
          .
          <source>ACM Transactions on the Web</source>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          22.
          <string-name>
            <given-names>A. U.</given-names>
            <surname>Mallya</surname>
          </string-name>
          and
          <string-name>
            <given-names>M. P.</given-names>
            <surname>Singh</surname>
          </string-name>
          .
          <article-title>Introducing preferences into commitment protocols</article-title>
          .
          <source>In AC</source>
          , volume
          <volume>3859</volume>
          <source>of LNCS</source>
          , pages
          <fpage>136</fpage>
          -
          <lpage>149</lpage>
          . Springer,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          23.
          <string-name>
            <given-names>T.</given-names>
            <surname>Miller</surname>
          </string-name>
          and
          <string-name>
            <given-names>P.</given-names>
            <surname>McBurney</surname>
          </string-name>
          .
          <article-title>Annotation and matching of first-class agent interaction protocols</article-title>
          .
          <source>In Proc. of the 7th AAMAS</source>
          , pages
          <fpage>805</fpage>
          -
          <lpage>812</lpage>
          ,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          24.
          <string-name>
            <given-names>T.</given-names>
            <surname>Miller</surname>
          </string-name>
          and
          <string-name>
            <given-names>J.</given-names>
            <surname>McGinnis</surname>
          </string-name>
          .
          <article-title>Amongst first-class protocols</article-title>
          .
          <source>In Proc. of Eng. Societies in the Agents World VIII, volume 4995 of LNCS</source>
          , pages
          <fpage>208</fpage>
          -
          <lpage>223</lpage>
          . Springer,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          25.
          <string-name>
            <given-names>M.</given-names>
            <surname>Montali</surname>
          </string-name>
          .
          <article-title>Specification and Verification of Declarative Open Interaction Models - A Logicbased framework</article-title>
          .
          <source>PhD thesis</source>
          , University of Bologna,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          26.
          <string-name>
            <given-names>M.</given-names>
            <surname>Pesic</surname>
          </string-name>
          and
          <string-name>
            <given-names>W. M. P. van der</given-names>
            <surname>Aalst</surname>
          </string-name>
          .
          <article-title>A Declarative Approach for Flexible Business Processes Management</article-title>
          .
          <source>In Proc. of. Business Process Management Workshops</source>
          , volume
          <volume>4103</volume>
          <source>of LNCS</source>
          , pages
          <fpage>169</fpage>
          -
          <lpage>180</lpage>
          . Springer,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          27.
          <string-name>
            <given-names>J. Searle. Speech</given-names>
            <surname>Acts</surname>
          </string-name>
          . Cambridge University Press,
          <year>1969</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          28.
          <string-name>
            <given-names>M. P.</given-names>
            <surname>Singh</surname>
          </string-name>
          .
          <article-title>An ontology for commitments in multiagent systems</article-title>
          .
          <source>Artif. Intell. Law</source>
          ,
          <volume>7</volume>
          (
          <issue>1</issue>
          ):
          <fpage>97</fpage>
          -
          <lpage>113</lpage>
          ,
          <year>1999</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          29.
          <string-name>
            <given-names>M. P.</given-names>
            <surname>Singh</surname>
          </string-name>
          .
          <article-title>A social semantics for agent communication languages</article-title>
          . In F. Dignum and M. Greaves, editors,
          <source>Issues in Agent Communication</source>
          , volume
          <volume>1916</volume>
          <source>of LNCS</source>
          , pages
          <fpage>31</fpage>
          -
          <lpage>45</lpage>
          . Springer,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          30.
          <string-name>
            <given-names>M. P.</given-names>
            <surname>Singh</surname>
          </string-name>
          .
          <article-title>Distributed enactment of multiagent workflows: temporal logic for web service composition</article-title>
          .
          <source>In AAMAS</source>
          , pages
          <fpage>907</fpage>
          -
          <lpage>914</lpage>
          . ACM,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref31">
        <mixed-citation>
          31.
          <string-name>
            <given-names>M. P.</given-names>
            <surname>Singh</surname>
          </string-name>
          and
          <string-name>
            <given-names>A. K.</given-names>
            <surname>Chopra</surname>
          </string-name>
          .
          <article-title>Correctness properties for multiagent systems</article-title>
          .
          <source>In DALT [2]</source>
          , pages
          <fpage>192</fpage>
          -
          <lpage>207</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref32">
        <mixed-citation>
          32.
          <string-name>
            <given-names>P.</given-names>
            <surname>Torroni</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Chesani</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Mello</surname>
          </string-name>
          , and
          <string-name>
            <given-names>M.</given-names>
            <surname>Montali</surname>
          </string-name>
          .
          <article-title>Social commitments in time: Satisfied or compensated</article-title>
          .
          <source>In DALT [2]</source>
          , pages
          <fpage>228</fpage>
          -
          <lpage>243</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref33">
        <mixed-citation>
          33.
          <string-name>
            <surname>W. M. P. van der Aalst</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          <string-name>
            <surname>Dumas</surname>
          </string-name>
          ,
          <string-name>
            <surname>A. H. M. ter Hofstede</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          <string-name>
            <surname>Russell</surname>
            ,
            <given-names>H. M. W.</given-names>
          </string-name>
          <string-name>
            <surname>Verbeek</surname>
            , and
            <given-names>P.</given-names>
          </string-name>
          <string-name>
            <surname>Wohed</surname>
          </string-name>
          . Life after BPEL?
          <source>In Proc. of WS-FM</source>
          , volume
          <volume>3670</volume>
          <source>of LNCS</source>
          , pp.
          <fpage>35</fpage>
          -
          <lpage>50</lpage>
          ,
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>