FOUNDATION FOR INTELLIGENT
PHYSICAL AGENTS
FIPA Communicative Act Library Specification
|
Document title |
FIPA Communicative Act Library Specification |
||
|
Document number |
PC00037E |
Document source |
FIPA TC C |
|
Document status |
Preliminary |
Date of this status |
2000/10/20 |
|
Supersedes |
OC00003, DC00038, DC00039, DC00040, DC00041, DC00042, DC00043, DC00044, DC00045, DC00046, DC00047, DC00048, DC00049, DC00050, DC00051, DC00052, DC00053, DC00054, DC00055, DC00056, DC00057, DC00058, DC00059, DC00060 |
||
|
Contact |
fab@fipa.org |
||
|
Change history |
|||
|
2000/01/18 |
Initial draft |
||
|
2000/07/14 |
Append ACL semantics as Annex A from OC00003 |
||
|
2000/07/28 |
Incorporating the changes from Baltimore meeting. Each CA specs are combined as one document. |
||
|
2000/08/10 |
Example messages are modified compatible with new ACL string representation and SL specs. |
||
|
2000/10/19 |
Edited examples to conform add new footnotes and clarify cfp, propose and not-understood. |
||
|
2000/10/20 |
Editorial changes; Submission to the FAB |
||
© 2000 Foundation for Intelligent Physical Agents - http://www.fipa.org/
Geneva, Switzerland
|
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. |
Foreword
The Foundation for Intelligent Physical Agents
(FIPA) is an international organization that is dedicated to promoting the
industry of intelligent agents by openly developing specifications supporting
interoperability among agents and agent-based applications. This occurs through
open collaboration among its member organizations, which are companies and
universities that are active in the field of agents. FIPA makes the results of
its activities available to all interested parties and intends to contribute
its results to the appropriate formal standards bodies.
The members of FIPA are individually and
collectively committed to open competition in the development of agent-based
applications, services and equipment. Membership in FIPA is open to any
corporation and individual firm, partnership, governmental body or
international organization without restriction. In particular, members are not
bound to implement or use specific agent-based standards, recommendations and
FIPA specifications by virtue of their participation in FIPA.
The FIPA specifications are developed through
direct involvement of the FIPA membership. The status of a specification can be
either Preliminary, Experimental, Standard, Deprecated or Obsolete. More detail about the process of
specification may be found in the FIPA Procedures for Technical Work. A
complete overview of the FIPA specifications and their current status may be
found in the FIPA List of Specifications. A list of terms and abbreviations
used in the FIPA specifications may be found in the FIPA Glossary.
FIPA is a non-profit association registered in
Geneva, Switzerland. As of January 2000, the 56 members of FIPA represented 17 countries worldwide. Further
information about FIPA as an organization, membership information, FIPA
specifications and upcoming meetings may be found at http://www.fipa.org/.
Contents
2.1 Status of a
FIPA-Compliant Communicative Act
2.2 FIPA Communicative
Act Library Maintenance
5 Informative Annex A – Formal Basis of ACL Semantics
5.1 Introduction to
the Formal Model
5.2.1 Basis of the
Semantic Language Formalism
5.3.7 Note on the Use of
Symbols in Formulae
5.4 Primitive
Communicative Acts
5.4.3 Confirming an
Uncertain Proposition: Confirm
5.4.4 Contradicting
Knowledge: Disconfirm
5.5 Composite
Communicative Acts
5.5.1 The Closed Question
Case
5.5.3 The
Confirm/Disconfirm Question Act
5.6 Inter-Agent
Communication Plans
This document contains specifications for structuring the FIPA Communicative Act Library (FIPA CAL) including: status of a FIPA-compliant communicative act, maintenance of the library and inclusion criteria.
This document is primarily concerned with defining the structure of the FIPA CAL and the requirements for a proposed communicative act to be included in the library. The elements of the library are listed in this document.
This document also contains the formal basis of FIPA ACL semantics in the annex for the semantic characterization of each FIPA communicative act.
This document focuses on the organization, structure and status of the FIPA Communicative Act Library, FIPA CAL and discusses the main requirements that a communicative act must satisfy in order to be FIPA-compliant.
The objectives of standardizing and defining a library of FIPA compliant communicative acts are:
· To help ensure interoperability by providing a standard set of composite and macro communicative acts, derived from the FIPA primitive communicative acts,
· To facilitate the reuse of composite and macro communicative acts, and,
· To provide a well-defined process for maintaining a set of communicative acts and act labels for use in the FIPA ACL.
In the following, we present the basic principles of the FIPA CAL. These principles help to guarantee that the CAL is stable, that there are public rules for the inclusion and maintenance of the CAL and that developers seeking communicative acts for their applications can use the CAL.
The definition of a communicative act belonging to the FIPA CAL is normative. That is, if a given agent implements one of the acts in the FIPA CAL, then it must implement that act in accordance with the semantic definition in the FIPA CAL. However, FIPA-compliant agents are not required to implement any of the FIPA CAL languages, except the not-understood composite act.
By collecting communicative act definitions in a single, publicly accessible registry, the FIPA CAL facilitates the use of standardized Communicative Acts by agents developed in different contexts. It also provides a greater incentive to developers to make any privately developed communicative acts generally available.
The name assigned to a proposed communicative act must uniquely identify which communicative act is used within a FIPA ACL message. It must not conflict with any names currently in the library, and must be an English word or abbreviation that is suggestive of the semantics. The FIPA Agent Communication Technical Committee is the initial judge of the suitability of a name.
FIPA is responsible for maintaining a consistent list of approved and proposed communicative act names and for making this list publicly available to FIPA members and non-members. This list is derived from the FIPA Communicative Act Library.
In addition to the semantic characterization and descriptive information that is required, each Communicative Act in the FIPA CAL may specify additional information, such as stability information, versioning, contact information, different support levels, etc.
The most effective way of maintaining the FIPA Communicative Act Library is through the use of the communicative acts themselves by different agent developers. This is the most direct way of discovering possible bugs, errors, inconsistencies, weaknesses, possible improvements, as well as capabilities, strengths, efficiency etc. In order to collect feedback on the communicative acts in the library and to promote further research, FIPA encourages coordination between agent language designers, agent developers, and FIPA members.
FIPA will designate a Technical Committee to maintain the FIPA CAL. The FIPA CAL will be managed by this technical committee, which will be responsible for the following items:
· Collecting feedback and the comments about communicative acts in the FIPA CAL. Depending on interest, the technical committee may organize more specific Working Groups. These groups would be responsible for maintaining public lists referring to projects and people who are currently working on different communicative acts.
· Inviting contributions in various forms: e-mail comments, written reports, papers, technical documents, and so forth. The current email address of the technical committee is specified on the first page of this document.
· All technical committee members will be notified about contributions, comments or proposed changes and should be able to access them.
· The proposed updates to the FIPA CAL must be discussed and approved during an official FIPA meeting, in order that the FIPA community may be involved with and informed of all of the FIPA approved communicative acts in the library
· In the future, FIPA intends to supply templates (publicly accessible from the FIPA web site) in order to facilitate submission of candidate communicative acts to the FIPA CAL, and to ensure that agent language developers understand and can easily satisfy the requirements for the submission of a new communicative act to the FIPA CAL.
In order to populate the FIPA CAL, it is necessary to set some fundamental guidelines for the selection of specific communicative acts.
The minimal criteria that must be satisfied for a communicative act to be included in the FIPA CAL are:
· A summary of the candidate act's semantic force and content type are required.
· A detailed natural language description of the act and its consequences are required.
· A formal model, written in SL, of the act's semantics, its formal preconditions, and its rational effects is required.
· Examples of the usage of the new communicative act are required.
· Substantial and clear documentation must be provided. This means that the proposal must be already well structured. FIPA members are in no way responsible for translating submitted communicative acts into an acceptable form. See the form of the acts in the library for a sample.
· The utility of such a new communicative act should be made clear. In particular, it should be clear that the need it solves is reasonably general, and that this need would be cumbersome to meet by combining existing communicative acts.
FIPA does not enforce the use of any particular communicative act, except for the case of not-understood, and those acts which are required to meet the agent management needs of the agent.
|
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 propose act). 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, Ii Done (<j, act>,
f))> FP: Bi a Ù ØBi
(Bifj a Ú Uifj a) RE: Bj a 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 Ú Uifj a) RE: Bj a 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 cancelling some previously requested action which has temporal extent, that is, it is not instantaneous. |
|
Message
Content |
An action expression denoting the action to be cancelled. |
|
Description |
Cancel allows an agent to stop another agent from continuing to perform (or expecting to perform) an action which was previously requested. 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. In most interaction protocols, attempting to cancel an action that has already been performed should result in a refuse message being sent back to the originator of the request. |
|
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 is the action of cancelling any form of requested action. In other
words, an agent i has requested an
agent j to perform some action,
possibly if some condition holds. This has the effect of i informing j that i has an intention. When i comes to drop its intention, it has
to inform j that it no longer has
this intention, that is, 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 x a(x))
Ù ØUrefi(Ref x a(x))
Ù ØBi Ij
Done (<j, inform-ref (i, Ref
x a(x))>) RE: Done (<j, inform (i, Ref x a(x)
= r1)> | … | <j,
inform (i, Ref x a(x)
= rk)>) Where: a(x) = Ii Done (<j,
act>, f(x)) Þ Ij 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 x d(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 an inform-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) =
r1)> |
... | (<i, inform (j, Ref x d(x) =
rk)> 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 x d(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-ref used 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-understood message 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 |