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 is true.

The informal implication is that f is the reason that the action failed, though this causality is not expressed formally in the semantic model.

Example

Agent j informs i that it has failed to open a file.

(failure

  :sender (agent-identifier :name j)

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

  :content

    ((action (agent-identifier :name j)

      (open "foo.txt"))

     (error-message "No such file: foo.txt"))

  :language FIPA-SL)

Summary

The sender informs the receiver that a given proposition is true.

Message Content

A proposition.

Description

The sending agent:

·       holds that some proposition is true,

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

·       does not already believe that the receiver has any knowledge of the truth of the proposition.

The first two properties defined above are straightforward: the sending agent is sincere, and has (somehow) generated the intention that the receiver should know the proposition (perhaps it has been asked). The last property is concerned with the semantic soundness of the act. If an agent knows already that some state of the world holds (that the receiver knows proposition p), it cannot rationally adopt an intention to bring about that state of the world (i.e. that the receiver comes to know p as a result of the inform act). Note that the property is not as strong as it perhaps appears. The sender is not required to establish whether the receiver knows p. It is only the case that, in the case that the sender already happens to know about the state of the receiver's beliefs, it should not adopt an intention to tell the receiver something it already knows.

From the receiver's viewpoint, receiving an inform 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, adopt belief in the proposition will be a function of the receiver's trust in the sincerity and reliability of the sender.

Formal Model

<i, inform (j, f )>

  FP: BifÙØ Bi(BifjfÚ Uifjf)

  RE: Bjf

Examples

Agent i informs agent j that (it is true that) it is raining today.

(inform

  :sender (agent-identifier :name i)

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

  :content

    "weather (today, raining)"

  :language Prolog)

Summary

A macro action for the agent of the action to inform the recipient whether or not a proposition is true.

Message Content

A proposition.

Description

The inform-if macro act is an abbreviation for informing whether or not a given proposition is believed. The agent which enacts an inform-if macro-act will actually perform a standard inform act. The content of the inform act will depend on the informing agent's beliefs. To inform-if on some closed proposition f:

·       if the agent believes the proposition, it will inform the other agent that f, and,

·       if it believes the negation of the proposition, it informs that f is false, that is, Øf.

Under other circumstances, it may not be possible for the agent to perform this plan. For example, if it has no knowledge of f, or will not permit the other party to know (that it believes) f, it will send a refuse message.

Formal Model

<i, inform-if (j, f)> º

  <i, inform (j, f)>|<i, inform (j, Øf)>

    FP: Bifi fÙØBi (Bifj fÚ Uifj f)

    RE: Bifj f

Inform-if represents two possible courses of action: i informs j that f, or i informs j that not f.

Examples

Agent i requests j to inform it whether Lannion is in Normandy.

(request

  :sender (agent-identifier :name i)

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

  :content

    ((action (agent-identifier :name j)

      (inform-if

        :sender (agent-identifier :name j)

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

        :content

          "in( lannion, normandy)"

        :language Prolog)))

  :language FIPA-SL)

Agent j replies that it is not:

(inform

  :sender (agent-identifier :name j)

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

  :content

    "\+ in (lannion, normandy)"

  :language Prolog)

Summary

A macro action for sender to inform the receiver the object which corresponds to a descriptor, for example, a name.

Message Content

An object description (a referential expression).

Description

The inform-ref macro action allows the sender to inform the receiver some object that the sender believes corresponds to a descriptor, such as a name or other identifying description.

inform-ref is a macro action, since it corresponds to a (possibly infinite) disjunction of inform acts, each of which informs the receiver that "the object corresponding to name is x" for some given x. For example, an agent can plan aninform-ref of the current time to agent j, and then perform the act "inform j that the time is 10.45".

The agent performing the act should believe that the object or set of objects corresponding to the reference expression is the one supplied, and should not believe that the receiver of the act already knows which object or set of objects corresponds to the reference expression.  The agent may elect to send a refuse message if it is unable to establish the preconditions of the act.

Formal Model

<i, inform-ref (j, Ref x d(x))> º

  <i, inform (j, Ref x d(x) = r₁)> | ... |

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

    FP: Brefi Ref x d(x) ÙØBi(Brefj Ref x d(x) Ú Urefj Ref x d(x))

    RE: Brefj Ref x d(x)

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

Inform-ref represents an unbounded, possibly infinite set of possible courses of action, in which i informs j of the referent of x.

Example

Agent i requests j to tell it the current Prime Minister of the United Kingdom:

(request

  :sender (agent-identifier :name i)

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

  :content

    ((action (agent-identifier :name j)

      (inform-ref

        :sender (agent-identifier :name j)

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

        :content

          "((iota ?x (UKPrimeMinister ?x)))"

        :ontology world-politics

        :language FIPA-SL)))

  :reply-with query0

  :language FIPA-SL)

Agent j replies:

(inform

  :sender (agent-identifier :name j)

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

  :content

    ((= (iota ?x (UKPrimeMinister ?x)) "Tony Blair"))

  :ontology world-politics

  :in-reply-to query0)

Note that a standard abbreviation for the request of inform-refused in this example is the act query-ref.

Summary

The sender of the act (for example, i) informs the receiver (for example, j) that it perceived that j performed some action, but that i did not understand what j just did. A particular common case is that i tells j that i did not understand the message that j has just sent to i.

Message Content

A tuple consisting of an action or event, for example, a communicative act, and an explanatory reason.

Description

The sender received a communicative act that it did not understand. There may be several reasons for this: the agent may not have been designed to process a certain act or class of acts, or it may have been expecting a different message. For example, it may have been strictly following a pre-defined protocol, in which the possible message sequences are predetermined. The not-understoodmessage indicates to that the sender of the original, that is, misunderstood, action that nothing has been done as a result of the message. This act may also be used in the general case for i to inform j that it has not understood j's action.

The second element of the message content tuple is a proposition representing the reason for the failure to understand. There is no guarantee that the reason is represented in a way that the receiving agent will understand. However, a co-operative agent will attempt to explain the misunderstanding constructively.

Note: It is not possible to fully capture the intended semantics of an action not being understood by another agent. The characterization below captures that an event happened and that the recipient of the not-understood message was the agent of that event.

f must be a well formed formula of the content language of the sender agent.  If the sender uses the bare textual message, that is, 'String' in the syntax definition, as the reason f, it must be a propositional assertive statement and (at least) the sender can understand that (natural language) message and calculate its truth value, that is, decide its assertion is true or false. So, for example, in the SL language, to use textual message for the convenience of humans, it must be encapsulated as the constant argument of a predicate defined in the ontology that the sender uses, for example:

(error "message")

Formal Model

<i, not-understood(j, a, f)> º

  <i, inform( j,  a) >

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

    RE: Bj a

Where:

a = fÙ ($x) Bi ((ie Done (e) Ù Agent (e, j) Ù B_j(Done (e) Ù

        Agent (e, j) Ù (a = e))) = x)

Examples

Agent i did not understand a query-if message because it did not recognize the ontology.

(not-understood

  :sender (agent-identifier :name i)

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

  :content

    ((action (agent-identifier :name j)

       (query-if

         :sender (agent-identifier :name j)

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

         :content

           "<fipa-ccl content expression>"

         :ontology www

         :language FIPA-CCL))

     (unknown (ontology "www")))

  :language FIPA-SL)

Summary

The sender intends that the receiver treat the embedded message as sent directly to the receiver, and wants the receiver to identify the agents denoted by the given descriptor and send the received propagate message to them.

Message Content

A tuple of a descriptor, that is, a referential expression, denoting an agent or agents to be forwarded the propagate message, an embedded ACL communicative act, that is, an ACL  message, performed by the sender to the receiver of the propagate message and a constraint condition for propagation, for example, timeout.

Description

This is a compound action of the following two actions. First, the sending agent requests the recipient to treat the embedded message in the received propagate message as if it is directly sent from the sender, that is, as if the sender performed the embedded communicative act directly to the receiver. Second, the sender wants the receiver to identify agents denoted by the given descriptor and to send a modified version of the received propagate message to them, as described below.

On forwarding, the :receiver parameter of the forwarded propagate message is set to the denoted agent(s) and the :sender parameter is set to the receiver of the received propagate message. The sender and receiver of the embedded communicative act of the forwarded propagate message is also set to the same agent as the forwarded propagate message's sender and receiver, respectively.

This communicative act is designed for delivering messages through federated agents by creating a chain (or tree) of propagate messages. An example of this is instantaneous brokerage requests using a proxy message, or persistent requests by a request-when/request-whenevermessage embedding a proxy message.

Formal Model

<i, propagate (j, Ref x d(x), <i, cact>, f)> º

  <i, cact(j)>;

  <i, inform (j, Ii(($y) (Bj(Ref x d(x) = y) Ù

       Done (<j, propagate (y, Ref x d(x), <j, cact>, f)>, B_jf))))>

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

    RE: Done (cact) Ù Bj a

Where :

a= Ii(($y) (Bj(Ref x d(x) = y) Ù

   Done (<j, propagate (y, Ref x d(x), <j, cact>, f)>, B_j f)))

Agent i performs the embedded communicative act to j: <i, cact(j)> and i wants j to send the propagate message to the denoted agent(s) by Ref x d(x).

Note that <i,cact> in the propagate message is the  ACL communicative act without the :receiver parameter.

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

Example

Agent i requests agent j and its federating other brokerage agents to do brokering video-on-demand server agent to get "SF" programs.

(propagate

  :sender (agent-identifier :name i)

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

  :content

    ((any ?x (registered

      (agent-description

        :name ?x

        :services (set

          (service-description

            :name agent-brokerage))))

      (action (agent-identifier :name i)

     (proxy

       :sender (agent-identifier :name i)

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

       :content

         "((all ?y (registered

           (agent-description

             :name ?y

             :services (set

               (service-description

                 :name video-on-demand)))))

           (action (agent-identifier :name j)

          (request

            :sender (agent-identifier :name j)

            :content

              \"((action ?z[4]

                (send-program (category "SF"))))\"

            :ontology vod-server-ontology

            :protocol fipa-reqest …))

          true)"

       :ontology brokerage-agent-ontology

       :conversation-id vod-brokering-2

       :protocol fipa-brokering …))

     (< (hop-count) 5))

  :ontology brokerage-agent-ontology

  …)

Summary

The action of submitting a proposal to perform a certain action, given certain preconditions.

Message Content

A tuple containing an action description, representing the action that the sender is proposing to perform, and a proposition representing the preconditions on the performance of the action.

Description

Propose is a general-purpose action to make a proposal or respond to an existing proposal during a negotiation process by proposing to perform a given action subject to certain conditions being true. The actual protocol under which the negotiation process is being conducted is known either by prior agreement, or is explicitly stated in the :protocol parameter of the message.

The proposer (the sender of the propose) informs the receiver that the proposer will adopt the intention to perform the action once the given precondition is met, and the receiver notifies the proposer of the receiver's intention that the proposer performs the action.

A typical use of the condition attached to the proposal is to specify the price of a bid in an auctioning or negotiation protocol.

Formal Model

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

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

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

    RE: Bj a

Where:

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

Agent i informs j that, once j informs i that j has adopted the intention for i to perform action act, and the preconditions for i performing act have been established, i will adopt the intention to perform act.

Example

Agent j proposes to i to sell 50 boxes of plums for $5. This example continues the example of cfp.

(propose

  :sender (agent-identifier :name j)

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

  :content

    ((action j (sell plum 50))

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

  :ontology fruit-market

  :in-reply-to proposal2

  :language FIPA-SL)

Summary

The sender wants the receiver to select target agents denoted by a given description and to send an embedded message to them.

Message Content

A tuple of a descriptor, that is, a referential expression, that denotes the target agents, an ACL communicative act, that is, an ACL message, to be performed to the agents, and a constraint condition for performing the embedded communicative act, for example, the maximum number of agents to be forwarded, etc.

Description

The sending agent informs the recipient that the sender wants the receiver to identify agents that satisfy the given descriptor, and to perform the embedded communicative act to them, that is, the receiver sends the embedded message to them.

On performing the embedded communicative act, the :receiver parameter is set to the denoted agent and the :sender is set to the receiver of the proxy message. If the embedded communicative act contains a :reply-to parameter (for example, in the recruiting case where the :protocol parameter is set to fipa-recruiting), it should be preserved in the performed message.

In the case of a brokering request (that is, the :protocol parameter is set to fipa-brokering), the brokerage agent (the receiver of the proxy message) must record some parameters, for example, :conversation-id, :reply-with, :sender, etc.) of the received proxy message to forward back the reply message(s) from the target agents to the corresponding requester agent (the sender of the proxy message).

Formal Model

<i, proxy (j, Ref x d(x), <j, cact>, f)> º

  <i, inform (j, Ii(($y)(Bj (Ref x d(x) = y) Ù

              Done (<j, cact(y)>, Bjf))))>

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

    RE: Bj a

Where:

a= Ii(($y) (Bj (Ref x d(x) = y) Ù Done (<j, cact(y)>, Bj f)))

Agent i wants j to perform the embedded communicative act  to the denoted agent(s) (y) by Ref x d(x).

Note that <j,cact>in the proxy messageis the ACL communicative act without the :receiver parameter. Its receiver is denoted by the given Ref xd(x) by the agent j.

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

Two types of proxy can be distinguished.  We will call the type of proxy defined above strong, because it is a feasibility precondition of j's communicative act to y that j satisfies the feasibility preconditions of the proxied communicative act.  So, if i proxies an inform of the proposition y to y via j, j must believe y before it sends the proxied inform message to y.

In addition, we could define weak-proxy, where we do not suppose that j is required to believe y. In this case, j cannot directly inform y of y, because j does not satisfy the feasibility preconditions of inform. In this case, j can only inform y that the original sender i has the intention that the inform of y should happen. More generally, weak-proxy can be expressed as an instance of proxy where the action <j,cact(y)> is replaced by <j, inform(y, I_i Done (<i, cact(y)>))>.

Example

Agent i requests agent j to do recruiting and request a video-on-demand server to send "SF" programs.

(proxy

  :sender (agent-identifier :name i)

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

  :content

    ((all ?x (registered(agent-description

      :name ?x

      :services (set

        (service-description

          :name video-on-demand)))))

     (action (agent-identifier :name j)

       (request

         :sender (agent-identifier :name j)

         :content

           "((action  ?y[5]

             (send-program (category "SF"))))"

         :ontology vod-server-ontology

         :language FIPA-SL

         :protocol fipa-request

         :reply-to (set (agent-identifier :name i))

         :conversation-id request-vod-1)

      true)

  :language FIPA-SL

  :ontology brokerage-agent

  :protocol fipa-recruiting

  :conversation-id vod-brokering-1 …)

Summary

The action of asking another agent whether or not a given proposition is true.

Message Content

A proposition.

Description

Query-ifis the act of asking another agent whether (it believes that) a given proposition is true. The sending agent is requesting the receiver to inform it of the truth of the proposition.

The agent performing the query-if act:

·         has no knowledge of the truth value of the proposition, and,

·         believes that the other agent can inform the querying agent if it knows the truth of the proposition.

Formal Model

<i, query-if (j, f)> º

  <i, request (j, <j, inform-if (i, f)>)>

    FP: ØBififÙØUififÙØBi Ij Done(<j, inform-if (i, f)>)

    RE: Done (<j, inform(i, f)>|<j, inform (i, Øf)>)

Example

Agent i asks agent j if j is registered with domain server d1:

(query-if
    :sender (agent-identifier :name i)
    :receiver (set (agent-identitfier :name j))
    :content
       ((registered (server d1) (agent j)))
    :reply-with r09
    …)

Agent j replies that it is not:

(inform
    :sender (agent-identifier :name j)
    :receiver (set (agent-identifier :name i))
    :content ((not (registered (server d1) (agent j))))
    :in-reply-to r09)

Summary

The action of asking another agent for the object referred to by an referential expression.

Message Content

A descriptor (a referential expression).

Description

Query-ref is the act of asking another agent to inform the requester of the object identified by a descriptor. The sending agent is requesting the receiver to perform an inform act, containing the object that corresponds to the descriptor.

The agent performing the query-ref act:

·         does not know which object or set of objects corresponds to the descriptor, and,

·         believes that the other agent can inform the querying agent the object or set of objects that correspond to the descriptor.

Formal Model

<i, query-ref (j, Ref x d(x))> º

  <i, request (j, <j, inform-ref (i, Ref x d(x))>)>

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

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

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

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

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

Example

Agent i asks agent j for its available services.

(query-ref

  :sender (agent-identinfier :name i)

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

  :content

     ((all ?x (available-service j ?x)))

  …)

Agent j replies that it can reserve trains, planes and automobiles.

(inform

  :sender (agent-identifier :name j)

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

  :content

    ((= (all ?x (available-service j ?x))

      (set (reserve-ticket train)

           (reserve-ticket plane)

           (reserve automobile))))

  …)

Summary

The action of refusing to perform a given action, and explaining the reason for the refusal.

Message Content

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

Description

The refuse act is an abbreviation for denying (strictly speaking, disconfirming) that an act is possible for the agent to perform, and stating the reason why that is so.

The refuse act is performed when the agent cannot meet all of the preconditions for the action to be carried out, both implicit and explicit. For example, the agent may not know something it is being asked for, or another agent requested an action for which it has insufficient privilege.

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

·         the action has not been done,

·         the action is not feasible (from the point of view of the sender of the refusal), and,

·         the (causal) reason for the refusal is represented by the a proposition which is the second element of the message content tuple, (which may be the constant true). There is no guarantee that the reason is represented in a way that the receiving agent will understand. However, a cooperative agent will attempt to explain the refusal constructively. See the description at not-understood.

Formal Model

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

  <i, disconfirm (j, Feasible(<i, act>))>;

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

    FP: Bi ØFeasible (<i, act>) Ù Bi (Bj Feasible (<i, act>) Ú

        Uj Feasible (<i, act>)) Ù Bi aÙØBi (Bifj aÚ Uifj a)

    RE: Bj ØFeasible (<i, act>) Ù Bj a

Where:

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

Agent i informs j that action act is not feasible, and further that, because of proposition f, act has not been done and i has no intention to do act.

Example

Agent j refuses to i reserve a ticket for i, since there are insufficient funds in i's account.

(refuse

  :sender (agent-identifier :name j)

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

  :content

    ((action (agent-identifier :name j)

      (reserve-ticket LHR MUC 27-sept-97))

      (insufficient-funds ac12345))

  :language FIPA-SL)

Summary

The action of rejecting a proposal to perform some action during a negotiation.

Message Content

A tuple consisting of an action description and a proposition which formed the original proposal being rejected, and a further proposition which denotes the reason for the rejection.

Description

Reject-proposalis a general-purpose rejection to a previously submitted proposal. The agent sending the rejection informs the receiver that it has no intention that the recipient performs the given action under the given preconditions.

The additional proposition represents a reason that the proposal was rejected. Since it is in general hard to relate cause to effect, the formal model below only notes that the reason proposition was believed true by the sender at the time of the rejection. Syntactically the reason should be treated as a causal explanation for the rejection, even though this is not established by the formal semantics.

Formal Model

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

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

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

RE : Bj a

Where:

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

Agent i informs j that, because of proposition y, i does not have the intention for j to perform action act with precondition f.

Example

Agent i informs j that it rejects an offer from j to sell.

(reject-proposal

  :sender (agent-identifier :name i)

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

  :content

    ((action (agent-identifier :name j)

     (sell plum 50))

    (cost 200)

    (price-too-high 50))

  :in-reply-to proposal13)

Summary

The sender requests the receiver to perform some action.

One important class of uses of the request act is to request the receiver to perform another communicative act.

Message Content

An action expression.

Description

The sender is requesting the receiver to perform some action. The content of the message is a description of the action to be performed, in some language the receiver understands. The action can be any action the receiver is capable of performing: pick up a box, book a plane flight, change a password, etc.

An important use of the request act is to build composite conversations between agents, where the actions that are the object of the request act are themselves communicative acts such as inform.

Formal Model

<i, request (j, a )>

  FP: FP (a) [i\j] Ù Bi Agent (j, a) ÙØBi Ij Done (a)

  RE: Done (a)

FP(a) [i\j]denotes the part of the FPs of a which are mental attitudes of i.

Examples

Agent i requests j to open a file.

(request

  :sender (agent-identifier :name i)

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

  :content

    "open \"db.txt\" for input"

  :language vb)

Summary

The sender wants the receiver to perform some action when some given proposition becomes true.

Message Content

A tuple of an action description and a proposition.

Description

Request-whenallows an agent to inform another agent that a certain action should be performed as soon as a given precondition, expressed as a proposition, becomes true.

The agent receiving a request-whenshould either refuse to take on the commitment, or should arrange to ensure that the action will be performed when the condition becomes true. This commitment will persist until such time as it is discharged by the condition becoming true, the requesting agent cancels the request-when, or the agent decides that it can no longer honour the commitment, in which case it should send a refuse message to the originator.

No specific commitment is implied by the specification as to how frequently the proposition is re-evaluated, nor what the lag will be between the proposition becoming true and the action being enacted. Agents that require such specific commitments should negotiate their own agreements prior to submitting therequest-when act.

Formal Model

<i, request-when (j, <j, act>, f)> º

  <i, inform (j, ($e') Done (e') Ù Unique (e') Ù

              Ii Done (<j, act>, ($e) Enables (e, Bj f) Ù

              Has-never-held-since (e', Bj f)))>

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

    RE: Bj a

Where:

a = ($e') Done (e') (Unique (e') Ù

              Ii Done (<j, act>, ($e) Enables (e, Bj f) Ù

              Has-never-held-since (e', Bj f))

Agent i informs j that i intends for j to perform some act when j comes to believe f.

Examples

Agent i tells agent j to notify it as soon as an alarm occurs.

(request-when

  :sender (agent-identifier :name i)

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

  :content

    ((action (agent-identifier :name j)

      (inform

        :sender (agent-identifier :name j)

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

        :content

          "((alarm \"something alarming!\"))"))

    (Done( alarm )))

  …)

Summary

The sender wants the receiver to perform some action as soon as some proposition becomes true and thereafter each time the proposition becomes true again.

Message Content

A tuple of an action description and a proposition.

Description

Request-wheneverallows an agent to inform another agent that a certain action should be performed as soon as a given precondition, expressed as a proposition, becomes true, and that, furthermore, if the proposition should subsequently become false, the action will be repeated as soon as it once more becomes true.

Request-wheneverrepresents a persistent commitment to re-evaluate the given proposition and take action when its value changes. The originating agent may subsequently remove this commitment by performing the cancel action.

No specific commitment is implied by the specification as to how frequently the proposition is re-evaluated, nor what the lag will be between the proposition becoming true and the action being enacted. Agents who require such specific commitments should negotiate their own agreements prior to submitting the request-whenact.

Formal Model

<i, request-whenever (j, <j, act>, f)> º

  <i, inform (j, Ii Done (<j, act>, ($e) Enables (e, Bj f)))>

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

    RE: Bj a

Where:

a = Ii Done (<j, act>, ($e) Enables (e, Bj f))

Agent i informs j that i intends that j will perform some act whenever some event causes j to believe f.

Examples

Agent i tells agent j to notify it whenever the price of widgets rises from less than 50 to more than 50.

(request-whenever

  :sender (agent-identifier :name i)

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

  :content

    ((action (agent-identifier :name j)

      (inform-ref

        :sender (agent-identifier :name j)

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

        :content

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

     (> (price widget) 50))

  …)

Summary

The act of requesting a persistent intention to notify the sender of the value of a reference, and to notify again whenever the object identified by the reference changes.

Message Content

A descriptor (a referential expression).

Description

The subscribe act is a persistent version of query-ref, such that the agent receiving the subscribe will inform the sender of the value of the reference, and will continue to send further informs if the object denoted by the description changes.

A subscription set up by a subscribe act is terminated by a cancel act.

Formal Model

<i, subscribe (j, Ref x d(x))> º

  <i, request-whenever (j, <j, inform-ref (i, Ref x d(x))>,

                       ($y) Bj ((Ref x d(x) = y))>

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

    RE: Bj a

Where:

a= Ii Done (<j, inform-ref (i, Ref x d(x))>,

           ($e) Enables (e, ($y) Bj ((Ref x d(x) = y)))

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

Examples

Agent i wishes to be updated on the exchange rate of Francs to Dollars, and makes a subscription agreement with j (an exchange rate server).

(subscribe

  :sender (agent-identifier :name i)

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

  :content

    ((iota ?x (= ?x (xch-rate FFR USD)))))

Symbol

Usage

a

Used to denote an action. Example:  a = <i, inform (j, p)>

act

Used to denote an action type. Example:  act = inform (j, p)

Thus, if a = <i, inform (j, p)> and act = inform (j, p) then a = <i, act>.

cact

Used to denace only an ACL communicative act type.

f

Used to denote any closed proposition (without any restriction).

p

Used to denote a given proposition. Thus 'f' is a formula schema, that is, a variable that denotes a formula, and 'p' is a formula (not a variable).