Notice

Use of the technologies described in this specification may infringe patents, copyrights or other intellectual property rights of FIPA Members and non-members. Nothing in this specification should be construed as granting permission to use any of the technologies described. Anyone planning to make use of technology covered by the intellectual property rights of others should first obtain permission from the holder(s) of the rights. FIPA strongly encourages anyone implementing any part of this specification to determine first whether part(s) sought to be implemented are covered by the intellectual property of others, and, if so, to obtain appropriate licenses or other permission from the holder(s) of such intellectual property prior to implementation. This specification is subject to change without notice. Neither FIPA nor any of its Members accept any responsibility whatsoever for damages or liability, direct or consequential, which may result from the use of this specification.

Summary

The action of accepting a previously submitted proposal to perform an action.

Message Content

A tuple consisting of an action expression denoting the action to be done, and a proposition giving the conditions of the agreement.

Description

Accept-proposal is a general-purpose acceptance of a proposal that was previously submitted (typically through a proposeact). The agent sending the acceptance informs the receiver that it intends that (at some point in the future) the receiving agent will perform the action, once the given precondition is, or becomes, true.

The proposition given as part of the acceptance indicates the preconditions that the agent is attaching to the acceptance. A typical use of this is to finalize the details of a deal in some protocol. For example, a previous offer to "hold a meeting anytime on Tuesday" might be accepted with an additional condition that the time of the meeting is 11.00.

Note for future extension: an agent may intend that an action become done without necessarily intending the precondition. For example, during negotiation about a given task, the negotiating parties may not unequivocally intend their opening bids: agent a may bid a price p as a precondition, but be prepared to accept price p'.

Formal Model

<i, accept-proposal (j, <j, act>, f))> º

  <i, inform (j, I_i Done (<j, act>, f))>

    FP: B_iaÙØBi (BifjaÚ Uifja)

    RE: Bja

Where:

a = Ii Done (<j, act>, f)

Example

Agent i informs j that it accepts an offer from j to stream a given multimedia title to channel 19 when the customer is ready. Agent i will inform j of this fact when appropriate.

(accept-proposal

  :sender (agent-identifier :name i)

  :receiver (set (agent-identifier :name j))

  :in-reply-to bid089

  :content

    ((action (agent-identifier :name j)

      (stream-content movie1234 19))

     (B (agent-identifier :name j)

      (ready customer78)))

  :language FIPA-SL)

Summary

The action of agreeing to perform some action, possibly in the future.

Message Content

A tuple, consisting of an action expression denoting the action to be done, and a proposition giving the conditions of the agreement.

Description

Agree is a general-purpose agreement to a previously submitted request to perform some action. The agent sending the agreement informs the receiver that it does intend to perform the action, but not until the given precondition is true.

The proposition given as part of the agree act indicates the qualifiers, if any, that the agent is attaching to the agreement. This might be used, for example, to inform the receiver when the agent will execute the action which it is agreeing to perform.

Pragmatic note: The precondition on the action being agreed to can include the perlocutionary effect of some other CA, such as an inform act. When the recipient of the agreement (for example, a contract manager) wants the agreed action to be performed, it should then bring about the precondition by performing the necessary CA. This mechanism can be used to ensure that the contractor defers performing the action until the manager is ready for the action to be done.

Formal Model

<i, agree (j, <i, act>, f))> º

  <i, inform (j, Ii Done (<i, act>, f))>

    FP: Bi aÙØBi (Bifj aÚ Uifja)

    RE: Bja

Where:

a = Ii Done(<i, act>, f)

Note that the formal difference between the semantics of agree and the semantics of accept-proposal rests on which agent is performing the action.

Example

Agent i (a job-shop scheduler) requests j (a robot) to deliver a box to a certain location. J answers that it agrees to the request but it has low priority.

(request

  :sender (agent-identifier :name i)

  :receiver (set (agent-identifier :name j))

  :content

    ((action (agent-identifier :name j)

      (deliver box017 (loc 12 19))))

  :protocol fipa-request

  :language FIPA-SL

  :reply-with order567)

(agree

  :sender (agent-identifier :name j)

  :receiver (set (agent-identifier :name i))

  :content

    ((action (agent-identifier :name j)

      (deliver box017 (loc 12 19)))

     (priority order567 low))

  :in-reply-to order567

  :protocol fipa-request

  :language FIPA-SL)

Summary

The action of one agent informing another agent that the first agent no longer has the intention that the second agent perform some action.

Message Content

An action expression denoting the action that is no longer intended.

Description

Cancel allows an agent i to inform another agent j that i no longer intends that j perform a previously requested action.  This is not the same as i informing j that i intends that j not perform the action or stop performing an action.  Cancel is simply used to let an agent know that another agent no longer has a particular intention.  (In order for i to stop j from performing an action, i should request that j stop that action.  Of course, nothing in the ACL semantics guarantees that j will actually stop performing the action; j is free to ignore i’s request.) Finally, note that the action that is the object of the act of cancellation should be believed by the sender to be ongoing or to be planned but not yet executed.

Formal Model

<i, cancel (j, a)> º

  <i, disconfirm (j, Ii Done (a))>

    FP: ØIi Done (a) Ù Bi (Bj Ii Done (a) Ú Uj Ii Done (a))

    RE: Bj ØIi Done (a)

Cancel applies to any form of requested action. Suppose an agent i has requested an agent j to perform some action a, possibly if some condition holds. This request has the effect of i informing j that i has an intention that j perform the action a. When i comes to drop its intention, it can inform j that it no longer has this intention with a disconfirm.

Example

Agent j asks i to cancel a previous request-whenever by quoting the action.

(cancel

  :sender (agent-identifier :name j)

  :receiver (set (agent-identifier :name i))

  :content

    ((action (agent-identifier :name j)

      (request-whenever

        :sender (agent-identifier :name j)

        :receiver (set(agent-identifier :name i))

        :content[1]

          "((action (agent-identifier :name i)

            (inform-ref

              :sender (agent-identifier :name i)

              :receiver (set (agent-identifier :name j))

              :content[2]

                \"((iota ?x

                    (=(price widget) ?x))\")

                    (> (price widget) 50))"

                    …)))

  :langage FIPA-SL

  …)

Summary

The action of calling for proposals to perform a given action.

Message Content

A tuple containing an action expression denoting the action to be done, and a referential expression defining a single-parameter proposition which gives the preconditions on the action.

Description

CFP is a general-purpose action to initiate a negotiation process by making a call for proposals to perform the given action. The actual protocol under which the negotiation process is established is known either by prior agreement, or is explicitly stated in the :protocol parameter of the message.

In normal usage, the agent responding to a cfp should answer with a proposition giving the value of the parameter in the original precondition expression (see the statement of cfp's rational effect). For example, the cfp might seek proposals for a journey from Frankfurt to Munich, with a condition that the mode of travel is by train. A compatible proposal in reply would be for the 10.45 express train. An incompatible proposal would be to travel by airplane.

Note that cfp can also be used to simply check the availability of an agent to perform some action. Also note that this formalization of cfp is restricted to the common case of proposals characterized by a single parameter (x) in the proposal expression. Other scenarios might involve multiple proposal parameters, demand curves, free-form responses, and so forth. 

Formal Model

<i, cfp (j, <j, act>, Ref x f(x))> º

  <i, query-ref (j, Ref x (Ii Done (<j, act>, f(x)) Þ

                (Ij Done (<j, act>, f(x))))>

    FP: ØBrefi(Ref xa(x)) ÙØUrefi(Ref xa(x)) Ù

                ØBi Ij Done (<j, inform-ref (i, Ref xa(x))>)

    RE: Done (<j, inform (i, Ref xa(x) = r₁)> | … |

                <j, inform (i, Ref xa(x) = r_k)>)

Where:

a(x) = Ii Done (<j, act>, f(x)) Þ I_j Done (<j, act>, f(x))

Agent i asks agent j: "What is the 'x' such that you will perform action 'act' when 'f (x)' holds?"

Note:  Ref xd(x) is one of the referential expressions:  ix d(x), any x d(x) or all x d(x).

Note: The RE of this is not a proposal by the recipient. Rather, it is the value of the proposal parameter. See the example in the definition of the propose act.

Example

Agent j asks i to submit its proposal to sell 50 boxes of plums.

(cfp

  :sender (agent-identifier :name j)

  :receiver (set (agent-identifier :name i))

  :content

    ((action (agent-identifier :name i)

      (sell plum 50))

     (any ?x (and (= (price plum) ?x) (< ?x 10))))

  :ontology fruit-market)

Summary

The sender informs the receiver that a given proposition is true, where the receiver is known to be uncertain about the proposition.

Message Content

A proposition.

Description

The sending agent:

·       believes that some proposition is true,

·       intends that the receiving agent also comes to believe that the proposition is true, and,

·       believes that the receiver is uncertain of the truth of the proposition.

The first two properties defined above are straightforward: the sending agent is sincere[3], and has (somehow) generated the intention that the receiver should know the proposition (perhaps it has been asked). The last pre-condition determines when the agent should use confirm vs. inform vs. disconfirm: confirm is used precisely when the other agent is already known to be uncertain about the proposition (rather than uncertain about the negation of the proposition).

From the receiver's viewpoint, receiving a confirm message entitles it to believe that:

·       the sender believes the proposition that is the content of the message, and,

·       the sender wishes the receiver to believe that proposition also.

Whether or not the receiver does, indeed, change its mental attitude to one of belief in the proposition will be a function of the receiver's trust in the sincerity and reliability of the sender.

Formal Model

<i, confirm (j, f)>

  FP: BifÙ BiUjf

  RE: Bjf

Examples

Agent i confirms to agent j that it is, in fact, true that it is snowing today.

(confirm

  :sender (agent-identifier :name i)

  :receiver (set (agent-identifier :name j))

  :content

    "weather (today, snowing)"

  :language Prolog)

Summary

The sender informs the receiver that a given proposition is false, where the receiver is known to believe, or believe it likely that, the proposition is true.

Message Content

A proposition.

Description

The disconfirm act is used when the agent wishes to alter the known mental attitude of another agent.

The sending agent:

·       believes that some proposition is false,

·       intends that the receiving agent also comes to believe that the proposition is false, and,

·       believes that the receiver either believes the proposition, or is uncertain of the proposition.

The first two properties defined above are straightforward: the sending agent is sincere3, and has (somehow) generated the intention that the receiver should know the proposition (perhaps it has been asked). The last pre-condition determines when the agent should use confirm vs. inform vs. disconfirm: disconfirm is used precisely when the other agent is already known to believe the proposition or to be uncertain about it.

From the receiver's viewpoint, receiving a disconfirm message entitles it to believe that:

·       the sender believes that the proposition that is the content of the message is false, and,

·       the sender wishes the receiver to believe the negated proposition also.

Whether or not the receiver does, indeed, change its mental attitude to one of disbelief in the proposition will be a function of the receiver's trust in the sincerity and reliability of the sender.

Formal Model

<i, disconfirm (j, f)>

  FP: BiØfÙ Bi(UjfÚ Bjf)

  RE: BjØf

Example

Agent i, believing that agent j thinks that a shark is a mammal, attempts to change j's belief.

(disconfirm

  :sender (agent-identifier :name i)

  :receiver (set (agent-identifier :name j))

  :content

    ((mammal shark))

  :language FIPA-SL)

Summary

The action of telling another agent that an action was attempted but the attempt failed.

Message Content

A tuple, consisting of an action expression and a proposition giving the reason for the failure.

Description

The failure act is an abbreviation for informing that an act was considered feasible by the sender, but was not completed for some given reason.

The agent receiving a failure act is entitled to believe that:

·         the action has not been done, and,

·         the action is (or, at the time the agent attempted to perform the action, was) feasible

The (causal) reason for the failure is represented by the proposition, which is the second element of the message content tuple. It may be the constant true. Often it is the case that there is little either agent can do to further the attempt to perform the action.

Formal Model

<i, failure (j, a, f)> º

  <i, inform (j, ($e) Single (e) Ù Done (e, Feasible (a) Ù

             Ii Done (a)) ÙfÙØDone (a) ÙØIi Done (a))>

    FP: Bi aÙØBi (Bifj aÚ Uifj a)

    RE: Bj a

Where:

a = ($e) Single (e) Ù Done (e, Feasible (a) Ù Ii Done (a)) ÙfÙ

                     ØDone (a) ÙØIi Done (a)

Agent i informs agent j that, in the past, i had the intention to do action a and a was feasible. i performed the action of attempting to do a (that is, the action/event e is the attempt to do a), but now a has not been done and i no longer has the intention to do a, and f