FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS

 

 

FIPA ACL Message Structure Specification

 

 

 

 

 

 

 

 

 

 

 

© 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 17countries worldwide. Further information about FIPA as an organization, membership information, FIPA specifications and upcoming meetings may be found at http://www.fipa.org/.

Contents

1     Scope. 3

2     FIPA ACL Message Structure. 3

2.1      Type of Communicative Act3

2.1.1      Performative. 3

2.2      Participants in Communication. 3

2.2.1      Sender3

2.2.2      Receiver3

2.2.3      Reply To. 3

2.3      Content of Message. 3

2.3.1      Content3

2.4      Description of Content3

2.4.1      Language. 3

2.4.2      Encoding. 3

2.4.3      Ontology. 3

2.5      Control of Conversation. 3

2.5.1      Protocol3

2.5.2      Conversation Identifier3

2.5.3      Reply With. 3

2.5.4      In Reply To. 3

2.5.5      Reply By. 3

3     Maintenance of the FIPA ACL Message Elements List3

3.1.1      Inclusion Criteria. 3

3.1.2      Comments and Questions. 3

4     References. 3

1         Scope

This document contains specifications for the FIPA ACL message elements including: the list of current FIPA ACL message elements, procedures for maintenance of this list, and criteria for adopting new elements in the list.

 

The objectives of standardizing the form of a FIPA compliant ACL message are:

 

·         To help ensure interoperability by providing a standard set of ACL message structure, and,

 

·         To provide a well-defined process for maintaining this set.

2         FIPA ACL Message Structure

A FIPA ACL message contains a set of one or more message elements. Precisely which elements are needed for effective agent communication will vary according to the situation; the only element that is mandatory in all ACL messages is the performative, although it is expected that most ACL messages will also contain sender, receiver and content elements.

 

If an agent does not recognize or is unable to process one or more of the elements or element values, it can reply with the appropriate not-understood message.

 

Specific implementations are free to include user-defined message elements other than the FIPA ACL message elements specified in Table 1. The semantics of these user-defined elements is not defined by FIPA, and FIPA compliance does not require any particular interpretation of these elements.

 

Some elements of the message might be omitted when their value can be deduced by the context of the conversation. However, FIPA does not specify any mechanism to handle such conditions, therefore those implementations that omit some message elements are not guaranteed to interoperate with each other.

 

The full set of FIPA ACL message elements is shown in Table 1 without regard to their specific encodings in an implementation. FIPA-approved encodings and element orderings for ACL messages are given in other specifications. Each ACL message representation specification contains precise syntax descriptions for ACL message encodings based on XML, text strings and several other schemes.

 

A FIPA ACL message corresponds to the abstract element message payload identified in the [FIPA00001].

 

 

Table 1: FIPA ACL Message Elements

 

The following terms are used to define the ontology and the abstract syntax of the FIPA ACL message structure:

 

·         Frame.  This is the mandatory name of this entity, that must be used to represent each instance of this class.

 

·         Ontology. This is the name of the ontology, whose domain of discourse includes their elements described in the table.

 

·         Element. This identifies each component within the frame.  The type of the element is defined relative to a particular encoding. Encoding specifications for ACL messages are given in their respective specifications.

 

·         Description. This is a natural language description of the semantics of each element.  Notes are included to clarify typical usage.

 

·         Reserved Values. This is a list of FIPA-defined constants associated with each element.  This list is typically defined in the specification referenced.

 

All of the FIPA message elements share the frame and ontology shown in Table 2.

 

 

Table 2: FIPA ACL Message Frame and Ontology

 

2.1        Type of Communicative Act

2.1.1          Performative

Element	Description	Reserved Values
performative	Denotes the type of the communicative act of the ACL message	See [FIPA00037]

 

Notes: The performatives is a required element of all ACL messages. Developers are encouraged to use the FIPA standard performatives (see [FIPA00037]) whenever possible.

 

2.2        Participants in Communication

2.2.1          Sender

Element	Description	Reserved Values
sender	Denotes the identity of the sender of the message, i.e. the name of the agent of the communicative act.

 

Notes: The sender element will be an element of most ACL messages.  It is possible to omit the sender if, for example, the agent sending the ACL message wishes to remain anonymous. The sender refers to the agent which performs the communicative act giving rise to this ACL message.

 

2.2.2          Receiver

Element	Description	Reserved Values
receiver	Denotes the identity of the intended recipients of the message.

 

Notes: Ordinarily, the receiver will be a part of every ACL message.  It is only permissible to omit the receiver if the message recipient can be reliably inferred from context, or in special cases such as the embedded ACL message in proxy and propagate.

 

The receiver may be a single agent name, or a non-empty set of agent names. The latter corresponds to the situation where the message is multicast.  Pragmatically, the semantics of this multicast is that the sender intends the message for each recipient of the CA encoded in the message. For example, if an agent performs an inform act with a set of three agents as receiver, it denotes that the sender intends each of these agents to come to believe the content of the message.

 

2.2.3          Reply To

Element	Description	Reserved Values
reply-to	This element indicates that subsequent messages in this conversation thread are to be directed to the agent named in the reply-to element, instead of to the agent named in the sender element.

 

2.3        Content of Message

2.3.1          Content

Element	Description	Reserved Values
content	Denotes the content of the message; equivalently denotes the object of the action.

 

Notes: Most ACL messages require a content expression. Certain ACL message types, such as cancel, have an implicit content, especially in cases of using conversation-id or in-reply-to.

 

2.4        Description of Content

2.4.1          Language

Element	Description	Reserved Values
language	Denotes the language in which the content element is expressed.	See [FIPA00007]

 

Notes: The ACL content element is expressed in a formal language. This field may be omitted if the agents receiving the message can be assumed to know the language of the content expression. 

 

2.4.2          Encoding

Element	Description	Reserved Values
encoding	Denotes the specific encoding of the content language expression.	See [FIPA00007]

 

Notes: The content expression might be encoded in several ways. The encoding element is optionally used to specify this encoding to the recipient agent. If the encoding element is not present, the encoding will be specified in the message envelope that encloses the ACL message.

 

2.4.3          Ontology

Element	Description	Reserved Values
ontology	Denotes the ontology(s) used to give a meaning to the symbols in the content expression.

 

Notes: The ontology(s) is/are used in conjunction with the language element to support the interpretation of the content expression by the receiving agent.  In many situations, the ontology(s) will be commonly understood by the agent community, and so this message element may be omitted.

 

2.5        Control of Conversation

2.5.1          Protocol

Element	Description	Reserved Values
protocol	Denotes the interaction protocol that the sending agent is employing with this ACL message.	See [FIPA00025]

 

Notes: The protocol message element defines the interaction protocol in which the ACL message is generated. This element is optional; however, developers are advised that employing ACL without the framework of an interaction protocol (and thus directly using the ACL semantics to control the agent’s generation and interpretation of ACL messages) is an extremely ambitious undertaking.

 

2.5.2          Conversation Identifier

Element	Description	Reserved Values
conversation-id	Introduces an expression (a conversation identifier) which is used to identify the ongoing sequence of communicative acts that together form a conversation.

           

Notes: An agent may optionally tag ACL messages with a conversation identifier to manage its communication strategies and activities. Typically this will allow an agent to identify individual conversations with multiple agents. It will also allow agents to reason across historical records of conversations.

 

2.5.3          Reply With

Element	Description	Reserved Values
reply-with	Introduces an expression that will be used by the responding agent to identify this message.

 

Notes: This message element is designed to be used to follow a conversation thread in a situation where multiple dialogues occur simultaneously.  For example, if agent i sends to agent j a message which contains:

 

reply-with <expr>

 

Agent j will respond with a message containing:

 

in-reply-to <expr>

 

2.5.4          In Reply To

Element	Description	Reserved Values
in-reply-to	Denotes an expression that references an earlier action to which this message is a reply.

 

Notes: See notes for Section 2.5.3, Reply With.

 

2.5.5          Reply By

Element	Description	Reserved Values
reply-by	Denotes a time and/or date expression which indicates the latest time by which the sending agent would like to have received a reply.

 

Notes: The time will be expressed according to the sender’s view of the time on the sender’s platform. The reply message can be identified in several ways: as the next sequential message in an interaction protocol, through the use of reply-with, through the use of a conversation-id and so forth. The way that the reply message is identified is determined by the agent implementer.

 

3         Maintenance of the FIPA ACL Message Elements List

The most effective way of maintaining the FIPA ACL message element list is through the use of the elements 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 FIPA ACL message elements in this document and to promote further research, FIPA encourages coordination among designers, agent developers, and FIPA members. FIPA will make an annual report on the use of the ACL element in this document.

 

FIPA will designate a Technical Committee (TC) to maintain the FIPA ACL message elements. This TC will manage the FIPA ACL message elements and will be responsible for the following items:

 

·         Collecting feedback and the comments about the FIPA ACL elements. Depending on interest, the TC may organize more specific Working Groups. These groups would be responsible for maintaining public lists referring projects and people that are currently using ACL elements of interest.

 

·         Inviting contributions in various forms: e-mail comments, written reports, papers, technical documents, and so forth. The current email address of the TC is: comm@fipa.org

 

·         All TC members will be notified about contributions, comments or proposed changes and should be able to access them.

 

·         The proposed updates to the FIPA ACL elements 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 FIPA ACL elements in this document library.

 

3.1.1          Inclusion Criteria

To populate the FIPA ACL element list, it is necessary to set some basic guidelines for the selection of specific FIPA ACL elements. The minimal criteria that must be satisfied for a FIPA ACL element to be FIPA compliant are:

 

·         Substantial and clear documentation must be provided,

 

·         The message element must not duplicate an existing element, and,

 

·         The usefulness of a new ACL element should be made clear.

 

3.1.2          Comments and Questions

The latest version of this document may be found on the FIPA web site (http://www.fipa.org). Comments and questions regarding this document and the specification therein should be addressed to agent_comm@fipa.org.

4         References

[FIPA00001]      FIPA Abstract Architecture Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00001/

[FIPA00007]      FIPA Content Languages Library Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00007/

[FIPA00025]      FIPA Interaction Protocol Library Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00025/

[FIPA00037]      FIPA Communicative Act Library Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00037/