Rheinisch-Westfälische Technische Hochschule AachenLehrstuhl für Informatik IVProf. Dr. rer. nat. Otto Spaniol

Betreuung: Karl-Heinz KrempelsLehrstuhl für Informatik IV, RWTH Aachen

Datenkommunikation und Verteilte-Systeme

Communication in FIPA-conform Agent SystemsSemester 4

Yu LiMatrikelnummer: 236810

1

INDEX

1 Introduction 2

2 What is FIPA 2

2.1 What is Agent 2

2.2 FIPA 3

2.3 The FIPA Application 3

3 FIPA Communicative Act Library 5

3.1 Overview 5

3.2 Principles of FIPA-Compliant Communicative Act 5

3.3 Maintenance of FIPA-CAL 6

3.4 Guidelines for Candidate Communicative Act 6

4 FIPA Agent Communication 7

4.1 A Figure Example 7

4.2 The Communication Steps in the Example 8

5 The FIPA Communication Level from Bottom to Top 14

5.1 Overview 14

5.2 Transport Level 14

5.3 FIPA ACL Level 15

5.4 Interaction Protocol Level 16

5.5 Content Language Level 17

5.6 Ontology Level 19

2

1. Introduction

Agent technology is a new branch in the computer science. Nowadays agent technology hasbeen applied in many fields, such as medicine, astrology, geology, meteorology, etc. It seemsthat the agent technology is becoming more and more important actors in more and morescience and techniques fields.

Agent technology itself is still in developing process. An agent is a piece of softwarecapable of acting intelligently to help a user or users to accomplish a task. Because manytimes a task can be completed not by only single agent, but by several agent. The problem,how agents communicate, comes out, since the agents need cooperate like human beings now.Different agents maybe use different programming language. For example, one agent usesC++; another agent uses Java. When they are required to cooperate to finish a task, how willthey understand each other in communication? The way is standardisation. When themessages are standardised. The receiver agent will surely understand the messages fromsender agent. “The Foundation for Intelligent Physical Agents (FIPA) is an internationalorganization that is dedicated to promoting the industry of intelligent agents by openlydeveloping specifications supporting interoperability among agents and agent-basedapplications.” FIPA defined the FIPA Communicative Act Library (FIPA CAL) whichincludes all possible messages sent between agents. Agent can use these standard message tocommunication. The massages are transferred in the architecture of the FIPA Communication.The architecture include five levels: Transport Level, FIPA-ACL [9] Level, InteractionProtocol [8] Level, Content Language Level and Ontology [6] Level.

2. What is FIPA

2.1 What is Agent

An agent is a piece of software to help users intelligently to accomplish a task. Agents, likehumans, cooperate so that a society of agents can combine their abilities to resolve problems.Agent technology is currently being applied to a number of application areas such as networkmanagement, information filtering, business process management, etc. Due to thecollaborative nature of agent systems, an agent standard represents a key requirement for thecommercialisation of agent technology.

Why is an agent standard so important? It can be showed by a simple restaurant-bookingexample. A customer requests his personal agent to find a particular type of restaurant, withina specific price range, with a choice of locations, for a particular set of dates. The personalagent searches for all available agents offering booking services, asks them to offer theinformation on service that agree with its criteria, ranks the suitable services based on itsknowledge of the user’s preferences, and finally reports back to its user. The user selectshis/her preferred service and authorises the agent to agree a contract and pay the requireddeposit.

The scenario contains two types of agent — customer agents, which solely represent theinterests of a customer, and restaurant agents offering booking services and representing theinterests of guests. Each agent would be owned by and represent a different party. Similarly,each agent could have been developed by different companies, at different times and usingdifferent underlying agent technologies.

3

For such a scenario to work there needs to be a minimum set of agent standards whichprovide:

• A commonly agreed means by which agents can communicate with each other so thatthey can exchange information, negotiate for services, or delegate tasks,

• Facilities whereby agents can locate each other (i.e. directory facilities),

• A secure and reliable environment where agents can operate and exchange confidentialmessages,

• A unique way of agent identification (i.e. globally unique names),

• A means of accessing back-end or legacy systems,

• A means of interacting with users,

• If necessary, a means of migrating from one platform to another.

An agent standard will also provide confidence for the development of an agent-componentmarket. Early adopters of new technologies tend to be wary where there is no consensusacross appropriate industries on a new technology. An agent standard will provide addedconfidence to potential adopters of this technology. The standardisation process also shifts thedebate from longer-term research issues to the practicalities of realising commercial agentsystems. Organisations, such as the Foundation for Intelligent Physical Agents (FIPA), allowfocused collaboration in addressing the key challenges facing commercial agent developers asthey bring this technology to market.

2.2 FIPA

FIPA is a non-profit, open organisation established in December 1995 for producingspecifications for open agent interfaces. Its primary purpose was to create consensus amongdifferent organisations involved in agent technology, and so initiate the agent standardisationprocess. Currently it has over 44 international member organisations including Siemens,Alcatel, HP, BT, NTT, WEBM, France Telecom, Hitachi, and Toshiba. FIPA operatesthrough a consensual process where commercial, rather than academic, interests have beenwell represented.

FIPA is a representative body for commercial agent interests, as well as the appropriatebody for agreeing common agent specifications. FIPA is defining consortia standards1 as ameans of promoting emerging agent applications, services and products. Already there areindications that agent component products are emerging based on the initial FIPAspecifications.

2.3 The FIPA specifications

The FIPA specifications represent the first step towards an agent standard. They attempt toprescribe neither the internal architecture of agents nor how they should be implemented, butthey do specify the interfaces necessary to support interoperability between agent systems.FIPA97 (issued in October 1997) is the first output from FIPA covering part of the

4

requirements for an agent standard. FIPA98 is currently being produced for release in October1998 which covers additional areas. Four areas of standardisation have been identified byFIPA .

Fig.1 Key agent interface

Agent communication (interface a in Fig 1): This facilitates communication betweenagents, and could support agent interactions such as negotiation, co-operation and informationexchange. An agent communication language (ACL), FIPA ACL, has been specified by FIPAto support this interface.

Agent management: This includes interfaces to the facilities necessary to support thelocation and creation of agents, the communication between agents as well as facilities forsecurity and mobility. FIPA97 part 1 specifies facilities for agent management, although themobility and security issues will not be covered until FIPA98.

Agent/software integration (interface b): This interface supports interaction between anagent and other non-agent software. This could include backend or legacy systems, orhardware drivers (e.g. in robotics).

Human/agent interaction (interface c): This covers how agents can interact with the humanusers and/or other agents manipulating user-related information such as user models. Thisinterface is being specified as part of FIPA’s 1998 work-plan and so there will be nospecification issued until FIPA98 is issued.

The FIPA97 specification contains three normative specifications (parts 1—3), and fourinformative specifications (parts 4—7) (see Table 1). Conformant agent systems must follow

user

User interface

c

a

bApplication software

agent

agent

Agent platform

5

parts 1—3. The informative parts provided guidance during the development of the normativespecifications and are intended to support developers when interpreting the normativespecifications. These are based on application scenarios as a means of illustrating theapplication of agents and the use of the FIPA specification.

FIPA 97 specification Normative InformationPart1 Agent management Part 4 Personal Travel assistancePart 2 Agent communication Part 5 Personal assistant

Pert 6 Audio/visual entertainmentPart 3 Agent software integrationPart 7 Network Management

Table 1 Structure of the FIPA 97 specification

3. FIPA Communicative Act Library

3.1 Overview

The aims of standardising and defining a library of FIPA compliant communicative actsare:• To ensure interoperability by providing a standard set of communicative acts, derived

from the FIPA primitive communicative acts,

• To facilitate the reuse of communicative acts, and,

• To provide a well-defined process for maintaining a set of communicative acts and actlabels in the FIPA ACL.

3.2 Principles of FIPA-Compliant Communicative Act

The definition of a communicative act in the FIPA CAL is normative. That is, if a givenagent uses one of the acts in the FIPA CAL, then it must use that act in accordance with thesemantic definition in the FIPA CAL. However, FIPA does not require its compliant agentsto implement any of the FIPA CAL languages, except the not-understood composite act. By collecting communicative act definitions in a single, publicly accessible registry, theFIPA CAL make agents developed in different situation able to use the standardisedCommunicative Acts. It also encourages developers to make their privately developedcommunicative acts available to public.

The name of any proposed communicative act must be unique and identify onecommunicative act in FIPA ACL. So it should not conflict with any other names in thelibrary. It must be an English word or abbreviation, which can suggest the semantics. The

6

FIPA Agent Communication Technical Committee is the first judge to decide whether a nameis suitable. FIPA maintains a consistent list of all the approved and proposed communicative act namesand makes this list publicly available to FIPA users. This list is derived from the FIPACommunicative Act Library. Each Communicative Act in the FIPA CAL describes its semantic characterisation andother descriptive information that is required. They may also specify additional information,such as stability information, versioning, contact information, different support levels, etc. 3.3 Maintenance of FIPA Communicative Act Library

The most effective and direct way of maintaining the FIPA Communicative Act Library isdifferent agent developers use the communicative acts in CAL. When CAL is used, itspossible bugs, errors, inconsistencies and weaknesses will appear, and its possibleimprovements will be found, as well as capabilities, strengths, efficiency etc. In order tocollect feedback on the communicative acts in CAL so that improvement can be made on thelibrary and further research can be promoted, FIPA encourages agent language designers,agent developers, and FIPA members to co-ordinate. FIPA will set a Technical Committee to maintain and to manage the FIPA CAL. Thetechnical committee is responsible for collecting feedback and the comments aboutcommunicative acts in the FIPA CAL from CAL’s users. Depending on interest, the technicalcommittee may be divided into several specific Working Groups. These groups would beresponsible for maintaining public lists referring to projects and people who are currentlyworking on different communicative acts. The committee invites contributions in variousforms: e-mail comments, written reports, papers, technical documents, and so on. Alltechnical committee members will be notified about contributions, comments or proposedchanges and should be able to access them.

The proposed improvement to the FIPA CAL must be discussed and approved during anofficial FIPA meeting, so that the FIPA community may be involved with and informed of allof the FIPA communicative acts in the library. In the future, FIPA will supply templates,which are publicly accessible from the FIPA Web site, for submission of candidatecommunicative acts to the FIPA CAL and for assurance that agent language developers canunderstand and easily satisfy the requirements of the submission of a new communicative actto the FIPA CAL. 3.4 Guidelines for Candidate Communicative Act

FIPA sets some fundamental guidelines for the selection of specific communicative acts. Acandidate communicative act to be included in the FIPA CAL must have: • A summary of the act's semantic force and content type. • A detailed description of the act and its consequences in natural language. • A formal model, written in SL, of the act's semantics, its formal preconditions, and its

rational effects.

7

• Examples of the usage of the communicative act. • Substantial and clear documentation. This means that the proposal must be already well

structured. FIPA members are in no way responsible for translating submittedcommunicative acts into an acceptable form. See the form of the acts in the library for asample.

• Clear utility of such a new communicative act. In particular, it should be clear that the

need it solves is reasonably general, and that this need would be cumbersome to meet bycombining existing communicative acts.

FIPA does not enforce the use of any particular communicative act, except for the case ofnot-understood, and those acts which are required to meet the agent management needs of theagent.

4. FIPA Agent Communication

4.1 An Figure Example

FIPA-ContractNet-Protocol< Buyer, Seller cfp-seller : cfp, refuse : refuse, not-understood, propose, reject-proposal, accept-proposal, cancel, inform, failure>

8

Fig. 2 a FIPA agent communication example

4.2 The Communication Steps in the Example

4.2.1 Responding to a cfp should answer with a proposition giving the value of the parameterin the original precondition expression (see the statement of cfp's rational effect). Forexample, the cfp the buyer firstly sends Call for Proposal (cfp) to the seller.cfp is the action of calling for proposals to perform a given action. Its massage content is atuple containing an action expression denoting the action to be done, and a referentialexpression defining a single-parameter proposition which gives the preconditions on theaction.

cfp is a general-purpose action to initiate a negotiation process by making a call forproposals to perform the given action. The actual protocol under which the negotiation

9

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 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 befor 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 someaction. Also note that this formalization of cfp is restricted to the common case of proposalscharacterized by a single parameter (x) in the proposal expression. Other scenarios mightinvolve multiple proposal parameters, demand curves, free-form responses, and so forth.

Agent buyer asks seller to submit its proposal to sell 50 boxes of apples. (cfp :sender (agent-identifier :name buyer) :receiver (set (agent-identifier :name seller)) :content ((action (agent-identifier :name seller) (sell apple 50)) (any ?x (and (= (price apple) ?x) (< ?x 10)))) :ontology fruit-market)

4.2.2 For the seller there may be different answers to the cfp.

a. One case is he refuses the cfp, then the negotiation ends.

Refuse is the action of refusing to perform a given action, and explaining the reason for therefusal. Its message content is a tuple, consisting of an action expression and a propositiongiving the reason for the refusal.

The refuse act is an abbreviation for denying (strictly speaking, disconfirming) that an actis 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 theaction to be carried out, both implicit and explicit. For example, the agent may not knowsomething it is being asked for, or another agent requested an action for which it hasinsufficient 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), The causal reason for the refusal is represented by the a proposition which is the secondelement of the message content tuple, which may be the constant true. There is no guaranteethat the reason is represented in a way that the receiving agent will understand. However, aco-operative agent will attempt to explain the refusal constructively.

The different cases of refuse form the refuse-1, refuse-2,…

In fig. 2, assume seller refuses to offer buyer 50boxes of apples. since there are insufficientfunds in i's account,

10

(refuse :sender (agent-identifier :name seller) :receiver (set (agent-identifier :name buyer)) :content ((action (agent-identifier :name buyer) (offer-apples LHR MUC 27-sept-97)) (insufficient-funds ac12345)) :language FIPA-SL)

b. Another case is the seller does not understand the cfp (not-understood). In this case, thenegotiation ends too.

not-understood means the sender of the act (for example, seller) informs the receiver (forexample, buyer) that it perceived that buyer performed some action, but that seller did notunderstand what buyer just did. A particular common case is that seller tells buyer that sellerdid not understand the message that buyer has just sent to seller.

The message content of not-understood is a tuple consisting of an action or event, forexample, a communicative act, and an explanatory reason.

The sender received a communicative act that it did not understand. There may be severalreasons 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 strictlyfollowing 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 alsobe 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 reasonfor the failure to understand. There is no guarantee that the reason is represented in a way thatthe receiving agent will understand. However, a co-operative agent will attempt to explain themisunderstanding constructively.

Note: It is not possible to fully capture the intended semantics of an action not beingunderstood by another agent. The characterization below captures that an event happened andthat the recipient of the not-understood message was the agent of that event. The reason must be a well-formed formula of the content language of the sender agent. Ifthe sender uses the bare textual message, that is, 'String' in the syntax definition, as the reason,it must be a propositional assertive statement and at least the sender can understand thatmessage and calculate its truth value, that is, decide its assertion is true or false. So, forexample, in the SL language, to use textual message for the convenience of humans, it mustbe encapsulated as the constant argument of a predicate defined in the ontology that thesender uses, for example:(error "message")In our case, suppose seller did not understand a cfp message because it did not recognize theontology. (not-understood :sender (agent-identifier :name seller) :receiver (set (agent-identifier :name buyer))

11

:content ((action (agent-identifier :name buyer) (cfp :sender (agent-identifier :name buyer) :receiver (set (agent-identifier :name seller)) :content ((action (agent-identifier :name seller) (sell apple 50)) (any ?x (and (= (price apple) ?x) (< ?x 10)))) :ontology fruit-market)

) (unknown (ontology " fruit-market "))) :language FIPA-SL)

c. Maybe the seller will give a proposal. propose is the action of submitting a proposal toperform a certain action, given certain preconditions. Its message content is a tuple containingan action description, representing the action that the sender is proposing to perform, and aproposition representing the preconditions on the performance of the action.

propose is a general-purpose action to make a proposal or respond to an existing proposalduring a negotiation process by proposing to perform a given action subject to certainconditions being true. The actual protocol under which the negotiation process is beingconducted is known either by prior agreement, or is explicitly stated in the protocol parameterof the message. The proposer (the sender of the propose) informs the receiver that the proposer will adoptthe intention to perform the action once the given precondition is met, and the receivernotifies 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 anauctioning or negotiation protocol. For example, Agent seller proposes to buyer to sell 50 boxes of apples for €5. Thisexample continues the example of cfp. (propose :sender (agent-identifier :name seller) :receiver (set (agent-identifier :name buyer)) :content ((action seller (sell apple 50)) (= (any ?x (and (= (price apple) ?x) (< ?x 10))) 5) :ontology fruit-market :in-reply-to cfp :language FIPA-SL)

4.2.3 when buyer receives the proposal, he will

a. reject it

Reject Proposal is an action of rejecting a proposal to perform some action during anegotiation. Its message content is a tuple consisting of an action description and a

12

proposition which formed the original proposal being rejected, and a further propositionwhich denotes the reason for the rejection.

Reject-proposal is a general-purpose rejection to a previously submitted proposal. Theagent sending the rejection informs the receiver that it has no intention that the recipientperforms the given action under the given preconditions.

The additional proposition represents a reason that the proposal was rejected. Since it is ingeneral hard to relate cause to effect, the formal model below only notes that the senderbelieved the reason proposition true at the time of the rejection. Syntactically the reasonshould be treated as a causal explanation for the rejection, even though this is not establishedby the formal semantics.

For example, buyer informs seller that it rejects an offer from seller: (reject-proposal :sender (agent-identifier :name buyer) :receiver (set (agent-identifier :name seller)) :content ((action (agent-identifier :name seller) (sell apple 50)) (cost 200) (price-too-high 50)) :in-reply-to propose)

orb. accept it

Accept proposal is an action of accepting a previously submitted proposal to perform anaction. Its message content is a tuple consisting of an action expression denoting the action tobe done, and a proposition giving the conditions of the agreement.

Accept-proposal is a general-purpose acceptance of a proposal that was previouslysubmitted (typically through a propose act). The agent sending the acceptance informs thereceiver that it intends that at some point in the future the receiving agent will perform theaction, once the given precondition is, or becomes, true. The proposition given as part of the acceptance indicates the preconditions that the agent isattaching to the acceptance. A typical use of this is to finalize the details of a deal in someprotocol. For example, a previous offer to "hold a meeting anytime on Monday" might beaccepted with an additional condition that the time of the meeting is 15.00. Note for future extension: an agent may intend that an action become done withoutnecessarily 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 aprice p as a precondition, but be prepared to accept price p'.

For example buyer informs seller that it accepts an offer from seller. buyer will informseller of this fact when appropriate. (accept-proposal

13

:sender (agent-identifier :name buyer) :receiver (set (agent-identifier :name seller)) :in-reply-to propose :content ((action (agent-identifier :name seller) (apple 50)) (B (agent-identifier :name seller) (ready customer78))) :language FIPA-SL)

4.2.4 After receiving the accept-proposal from buyer, seller will take an action like inform orfailure

a. inform means the sender informs the receiver that a given proposition is true. Its messagecontent is a proposition.

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 theproposition.

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 theact. If an agent knows already that some state of the world holds (that the receiver knowsproposition 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 asstrong as it perhaps appears. The sender is not required to establish whether the receiverknows p. It is only the case that, in the case that the sender already happens to know about thestate of the receiver's beliefs, it should not adopt an intention to tell the receiver something italready 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 ofthe receiver's trust in the sincerity and reliability of the sender.

In our case, Agent seller may inform agent buyer that it is true that apples are ready. (inform :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :language FIPA-SL :content "goods (apple, ready)" )

14

b. failure means The action of telling another agent that an action was attempted but theattempt failed. Its message content is a tuple, consisting of an action expression and aproposition giving the reason for the failure.The failure act is an abbreviation for informing that an act was considered feasible by thesender, 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 feasible, 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 secondelement of the message content tuple. It may be the constant true. Often it is the case thatthere is little either agent can do to further the attempt to perform the action.For example, Agent seller informs buyer that it has failed to send apples. (failure :sender (agent-identifier :name seller) :receiver (set (agent-identifier :name buyer)) :content ((action (agent-identifier :name seller) (send apple)) (error-message "No enough apple”)) :language FIPA-SL)

5. The Levels from Bottom to Top

5.1 Overview

FIPA agent communication can be divided into 5 levels: At the Bottom is the TransportLevel; Then is the FIPA-ACL Level, Interaction Protocol Level, and Content LanguageLevel; at the top is Ontology Level.

5. Ontology Level4. Content Language Level3. Interaction Protocol Level2. FIPA ACL Level1. Transport Level

Table 2. FIPA agent communication levels

5.2 Transport Level

Each agent has an agent-name. This agent-name is unique and unchangeable. Each agenthas one or more transport-descriptions, which are used by other agents to send a transport-message.

Each transport-description correlates to a particular form of message transport, such asHTTP, IIOP. A transport-message is a message expressed in a format (or encoding) that isappropriate to the transport being used. A set of transport-descriptions can be held in alocator.

15

HTTP (hypertext transfer protocol) is a kind of protocol at the application layer of internet.HTTP is implemented in two programs: a client program and a server program. The twoprograms are at different end system, talking each other and exchanging HTTP messages.

HTTP define how clients request Web sites to servers and how servers send the Web sitesto clients. In our everyday lives, when one wants to enter a Web site, he/she should first enterthe name of the Web site, for example, www.rwth-aachen.de, into the Web browser. Thebrowser sends the HTTP request messages to the server. The server receives the message andreply with the HTTP response messages, which contain the contents on the Web site.

IIOP (Internet Inter-ORB Protocol) is a protocol that makes distributed programs writtenin different programming languages able to communicate over the Internet. IIOP is a criticalpart of a strategic industry standard, the Common Object Request Broker Architecture(CORBA). Using CORBA's IIOP and related protocols, a company can write programs thatwill be able to communicate with their own or other company's existing or future programswherever they are located and without having to understand anything about the program otherthan its service and a name. CORBA and IIOP are competing with a similar strategy fromMicrosoft called the Distributed Component Object Model (DCOM).

CORBA and IIOP assume the client/server model of computing in which a client programalways makes requests and a server program waits to receive requests from clients. Whenwriting a program, you use an interface called the General Inter-ORB Protocol (GIOP). TheGIOP is implemented in specialised mappings for one or more network transport layers.Undoubtedly, the most important specialised mapping of GIOP is IIOP, which passes requestsor receives replies through the Internet's transport.

For a client to make a request of a program somewhere in a network, it must have anaddress for the program. This address is known as the Interoperable Object Reference (IOR).Using IIOP, part of the address is based on the server's port number and IP address. In theclient's computer, a table can be created to map IORs to proxy names that are easier to use.The GIOP lets the program make a connection with an IOR and then send requests to it (andlets servers send replies). A Common Data Representation (CDR) provides a way to encodeand decode data so that it can be exchanged in a standard way.

. There are still other possible transport services, such as Wireless Access Protocol,Microsoft Named Pipes, etc.

Generally, the inter-agent communications and user-agent communications are in the suchway. A user or an agent sends the request message, which is a message in FIPA-ACL, throughinternet to another agent. After receiving the message, the latter will reply with a message.

5.3 FIPA-ACL Level

As I have mentioned, The messages exchanged on the Transport Level are communicativeacts defined in FIPA-ACL. Every communicative act may be described by several attributes,most important in them are:

1)sender: who send the message. The sender parameter will be a parameter of most ACLmessages. It is possible to omit the sender parameter if, for example, the agent sending theACL message wishes to remain anonymous. The sender parameter refers to the agent whichperforms the communicative act giving rise to this ACL message.

16

2)receiver: who receive the message. Ordinarily, the receiver parameter will be a part ofevery ACL message. It is only permissible to omit the receiver parameter if the messagerecipient can be reliably inferred from context, or in special cases such as the embedded ACLmessage in proxy and propagate. The receiver parameter may be a single agent name or anon-empty set of agent names. The latter corresponds to the situation where the message ismulticast. Pragmatically, the semantics of this multicast is that the sender intends the messagefor each recipient of the CA encoded in the message. For example, if an agent performs aninform act with a set of three agents as receiver, it denotes that the sender intends each ofthese agents to come to believe the content of the message.

3)content: denotes the content of the message; equivalently denotes the object of theaction. The meaning of the content of any ACL message is intended to be interpreted by thereceiver of the message. This is particularly relevant for instance when referring to referentialexpressions, whose interpretation might be different for the sender and the receiver.

4)language: which language is used to describe the content. For example, FIPA-SL, FIPA-RDF, etc. The ACL content parameter is expressed in a formal language. This field may beomitted if the agent receiving the message can be assumed to know the language of thecontent expression.

5)ontology: the nouns used to give a meaning to the symbols in the content expression.The ontology parameter is used in conjunction with the language parameter to support theinterpretation of the content expression by the receiving agent. In many situations, theontology parameter will be commonly understood by the agent community and so thismessage parameter may be omitted.

In fig. 2 of agent communication, there are eight kinds of communication acts: cfp(call forproposal), refuse, not-understood, propose, reject-proposal, accept-proposal, inform, failure.All of them are Ill defined in FIPA-ACL. Propose has all of the five attributes.(propose :sender (agent-identifier :name seller) :receiver (set (agent-identifier :name buyer)) :content ((action seller (sell apple 50)) (= (any ?x (and (= (price apple) ?x) (< ?x 10))) 5) :ontology fruit-market :in-reply-to proposal :language FIPA-SL)Here the sender is seller. The receiver is buyer. The content is written in FIPA-SL, whichmeans seller proposes to sell 50 boxes of apples for 5 Dollars. The noun that cannotunderstood by agents, that is ontology, is fruit-market.

5.4 Interaction Protocol Level

The FIPA Agent Communication Language (ACL) is based on speech act theory [7]:messages are actions, or communicative acts, as they are intended to perform some action byvirtue of being sent.

The specification consists of a set of message types and the description of their pragmatics,

17

that is the effects on the mental attitudes of the sender and receiver agents.

In the Theory of Speech Acts, utterances are classified, according to the purpose of speech,into the following five classes of speech act:• Assertives represent facts of the world of utterance or common experiences, e.g. reports

or statements.• Directives represent the speaker’s attempt to get the hearer to perform the action I

indicated in the propositional content, e.g. requests.• Commissives represent the speaker’s intention to perform the action indicated in the

propositional content, e.g. promises.• Expressives say something about the speaker’s feelings or psychological attitudes

regarding the state of affairs represented by the propositional content, e.g. apologies.• Declaratives change the world through the utterance of the speech act. The speaker brings

about the state of affairs represented by the propositional content solely by uttering thespeech act, e.g. sentencing a prisoner or performing a marriage.

During inter-agent or user-agent communication, the sender will give some information,which is hold in content, to the receiver, and receiver perhaps will do something afterreceiving the information. In fig. 2,

refuse is both declarative and assertive. It has two meanings: first, sender will not replythe cfp(call for proposal), so it is declarative. Second, send tells the reason why he refuse thecfp. The reason is representing the fact that the funds are insufficient, so it is assertive.

cfp and propose are directives. cfp means sender hope to get receiver to propose. proposemeans sender want to get receiver to accept the proposal.

inform and failure are assertives. Inform means the sender represents the receiver the factthat the given proposition is true. failure means the sender represents the receiver some errors.

not-understood is expressives. It expresses the sender’s feeling, The sender is at a loss.

reject-proposal and accept-proposal are declaratives. They declare that the sender willreject or accept the proposal. Either of them changes the situation.

5.5 Content Language Level

The definition of a content language belonging to the FIPA Content Language Library(CLL) [1] is normative. That is, if a given agent advertises that it accepts one of the languagesin the FIPA CLL, then it must implement a parser or interpreter for the language as it isdefined in the FIPA CLL. However, FIPA-compliant agents are not required to implementany of the FIPA CLL languages, except those required for agent management.

By collecting content language definitions in a single, publicly accessible registry, theFIPA CCL facilitates the use of standardized content languages by agents developed indifferent contexts. It also provides a greater incentive to developers to make their contentlanguages generally applicable.

In general, a content language must be able to express propositions (statements expressingthat some sentence in a language is true or false), objects (constructs that represent anidentifiable entity in the domain of discourse) and actions, which try to express an activity

18

that can be carried out by an object. No other properties are required, though any givencontent language may be much more expressive than this. Minimal criteria for a CL to beFIPA compliant are:

• A good level of syntactical development is required• A clear and intuitive (although not necessarily formal) semantics• Examples of the usage of such a language are recommended• Substantial and clear documentation must be provided.• The utility of such a new language should be made clear.

Today there are several languages in CLL, including FIPA-SL [2], FIPA-RDF [5], FIPA-CCL[3] and FIPA-KIF [4].

Semantic Language (SL) is a general-purpose representation formalism that may besuitable for use in a number of different agent domains. SL is the formal language used todefine the semantics of the FIPA ACL, so it is used in most of the FIPA agent communicationmessages. In SL, logical propositions are expressed in logic of mental attitudes and actions,and formalized in a first order modal language with identity.

Resource Description Framework (RDF) is based on an entity-relationship model. TheRDF Data Model is described by means of resources, properties and their values. A specificresource together with one or more named properties plus the values of these properties is anRDF description. In addition to the RDF Data Model, the RDF Schemas specificationprovides a typing system for the resources and properties used in the RDF data. It definesconcepts such as classes, subclasses, properties or sub-properties. It also allows expressingconstraints. Both the RDF Data Model and RDF Schema propose XML as serializationsyntax. RDF is a "foundation for processing meta-data in the way that it providesinteroperability between applications that exchange machine-understandable information."This suggests that RDF could be most useful to facilitate knowledge sharing and exchangebetween agents.

Constraint Choice Language (CCL) is primarily intended to enable agentcommunication for applications that involve exchanges about multiple interrelated choices.FIPA CCL is based on the representation of choice problems as Constraint SatisfactionProblems (CSPs) and supports problem representation, information gathering, informationfusion and access to problem solution techniques.

A finite binary discrete CSP is defined by a finite set of variables, a finite domain ofpossible discrete values for each variable, and a finite set of constraints between any pairs ofvariables. A solution to the CSP is defined as an assignment of values to variables such thateach variable is assigned a value, and none of the constraints are violated. Having definedCSPs, a choice problem can be defined as a CSP in such a way that variables are choices to bemade, domains are the available options for each variable, and constraints are relationshipsbetween choices which express valid or invalid combinations.

The CSP model which underlies FIPA CCL has three restrictions imposed which have beenmade to make the model minimal and more suitable for a communication language: • Binary Constraints. All constraints expressed must have an arity of no more than 2. • Discrete Variable Domains. CSPs with only discrete sets of values in each variable

domain are by far the best understood in the literature. • Intensional Relations.There are also several implicit constraints which arise out of the fact that that CSPsrepresented in FIPA CCL must be contained in a single message: The number of variables

19

must be finite, and, the number of constraints must be finite since they must be encapsulatedin a single message.

Knowledge Interchange Format (KIF) is a language for use in the interchange ofknowledge among disparate computer systems created by different programmers, at differenttimes, in different languages, especially among FIPA agents. KIF has declarative semantics. Itis possible to understand the meaning of expressions in the language without appeal to aninterpreter for manipulating those expressions. KIF is logically comprehensive. At its mostgeneral, it provides for the expression of arbitrary logical sentences. KIF provides for therepresentation of knowledge about knowledge. This allows the user to make knowledgerepresentation decisions explicit and permits the user to introduce new knowledgerepresentation constructs without changing the language. KIF is also designed to maximizethe implementability and readability.

In example of the fig.2, all the message contents are written in FIPA-SL.

5.6 Ontology Level

FIPA agent communication is based on the assumption that two agents, who wish tocommunicate, share common ontology for the domain of discourse. The ontology definesspeech acts and protocols. This ensures that the agents ascribe the same meaning to thesymbols used in the message. For a given domain, either ontology that is explicit, publiclyrepresented and stored somewhere, or ontology that is implicitly encoded with the actualsoftware implementation of the agents themselves, is possible. The latter means ontology willnot formally published to an ontology service.

Ontology based communication

Agent Agent

Fig. 3 ontology based communication model

This FIPA specification deals with technologies enabling agents to manage explicit,publicly represented ontology. An ontology service for a community of agents is specified forthis purpose. It is required that the service be provided by a dedicated agent, called anOntology Agent (OA), which provides some or all of the following services: • discovery of public ontology in order to access it, • maintain a set of public ontology, • translate expressions in different ontology or different content languages, • respond to query for relationships between terms or between ontology, and, • facilitate the identification of shared ontology for communication between two agents.

ontology

Ontology queryOntology queryquery

ACL Communication is

20

The application of this specification does not prevent the existence of agents that, for agiven domain, use ontology implicitly encoded with the implementation of the agentsthemselves. In these cases full agent communication and understanding can still be obtained,however the services provided by the OA cannot apply to implicit encoded ontology. It is notmandated that every AP must include an Ontology Agent. However, in order to promoteinteroperability, if one OA exists, then it must comply with these specifications. And, if theservices here described are required by a specific agent platform implementation, then theymust be implemented in compliance with this specification.

In the Example of fig. 2, both cfp and propose have the same ontology fruit-market. Thismeans the agents, which send the messages, do not understand the noun fruit-market, andhave to refer to the ontology.

SUMMARY Different agents need standardized messages to communication, when they cooperate toaccomplish some tasks. FIPA has defined such messages in FIPA-ACL. Each message showsa specific act of agent, which can be understood by both the sender agent and the receiveragent. During communication agents send such messages to each other. The messages aretransferred on some application layer of network, such as HTTP, IIOP. FIPA-ACL is based onspeech act theory, which is about the interaction protocol. In the message, agent can get theinformation such as sender, receiver, content, etc. The message content can be written invarious languages defined in FIPA-CLL including SL, RDF, CCL and KIF. Both agents incommunication share common ontology, which defines speech acts and protocols.

21

REFERENCE

[1] FIPA Content Language Library Specification. Foundation for Intelligent PhysicalAgents, 2000.

[2] FIPA SL Content Language Specification. Foundation for Intelligent Physical Agents,2001.

[3] FIPA CCL Content Language Specification. Foundation for Intelligent Physical Agents,2001.

[4] FIPA KIF Content Language Specification. Foundation for Intelligent Physical Agents,2003.

[5] FIPA RDF Content Language Specification. Foundation for Intelligent Physical Agents,2000.

[6] FIPA Ontology Service Specification. Foundation for Intelligent Physical Agents, 2000.[7] JR Searle. Speech Acts: An Essay in the Philosophy of Language. Cambridge University

Press, Cambridge. 1969.[8] FIPA Interaction Protocol Specification. Foundation for Intelligent Physical Agents,

2001.[9] FIPA ACL Message Structure Specification. Foundation for Intelligent Physical Agents,

2000.[10] S willmott, J Dale, P Charlton.. Agent Communication Semantics for Open

Environments. 2002