agents transacting in open environments

Intelligent Agents Katia Sycara

[email protected] Robotics Institute

Joseph [email protected]

www.cs.cmu.edu/~softagents

Agents Transacting in Open Environments

Two phases:• Locating appropriate agents

– through different kinds of middle agents

• Performing the transaction– with or without middle agents

Transaction Phase

• Providers and requesters interact with each other directly– a negotiation phase to find out service parameters and preferences

(if not taken into account in the locating phase)– delegation of service

• Providers and requesters interact through middle agents– middle agent finds provider and delegates– hybrid protocols

• Reasons for interacting through middle agents– privacy issues (anonymization of requesters and providers)– trust issues (enforcement of honesty; not necessarily keep

anonymity of principals); e.g. NetBill

Matching Engine for Service Providers & Requesters

matching capabilities with requests

capability parametersservice request

(LARKS) matching capabilities with requests

capability parametersservice request+ parameters

(LARKS)

unsorted list of agent contact infodecision algorithm

sorted list of agent contact info

Broadcaster

BroadcasterRequester

Provider 1 Provider n

Request for service

Broadcast service request

Delegation of serviceResults of

service request

Offer of service

Matchmaking

MatchmakerRequester


Request for service

Unsorted full description of (P1,P2, …, Pk) Advertisement

of capabilities+para.Delegation of service

Results of service request

FacilitatorCombines Agent Location and Transaction Phases

FacilitatorRequester


Request for service+pref.

Advertisementof capabilities

+ para.

Results of service

Serviceresult

Delegationof service

Contract Net

ManagerRequester


Request for service+ preferences

Broadcast service request + pref

Delegationof service

Results of service

Offer of service

Provider 1

BroadcastBroadcast

Offer of service

Results ofService

Agent Communication• Aspects of communication:

– syntax: the structure of communicated symbols– semantics: what the symbols denote– pragmatics: the interpretation of the symbols

• Dimensions:– Personal vs. conventional meaning– subjective vs. objective meaning– semantics vs pragmatics– contextuality– agent and message identity

Message Types• Agent roles in a dialogue: active, passive, both• This allows it to be master, slave, peer,

respectively• Two basic message types: assertion and query• For example, an agent that takes the passive role

can:– accepts a query from external source (asserted)– sends a reply (makes an assertion)

Passive, Active, Peer

Passiveagent

Activeagent

Peer agent

Receiveassertions

Receivequeries

Sendassertions

Sendqueries

Communication levels• Lower level: specifies method of interconnection• Middle level: specifies format, syntax• Top level: specifies meaning, semantics

(substance and type)• Agent Communication specification includes:

– sender– receiver(s)– language – encoding and decoding functions– actions to be taken by the receiver(s)

Speech Act Theory• Theory of communication which is the basis for

the FIPA ACL• Speech act theory is derived from linguistic

analysis of human communication• Speaker not only makes statements but also

performs actions (e.g., “I hereby request…”)• Verbs that cannot be put in this form are not

speech acts (e.g. “I hereby solve this equation..”)

Speech Act Theory (cont)• Aspects of a speech act:

– Locution, the physical utterance by the speaker– Illocution, the intended meaning of the utterance by

the speaker– Perlocution, the action that results from the locution

• In communication among agents, we want to insure there is no doubt about the message type

• Speech act theory uses performative to identify the illocutionary force

• Helps define the type of message

Speech Act Theory (cont.d) In FIPA ACL:• Locution refers to formulation of an utterance• Illocution refers to a categorization of an

utterance from the speaker’s point of view (e.g. question, command)

• Perlocution refers to the other intended effects on the hearer, i.e., updating of the hearer’s mental attitudes.

Types of Communicative Acts • Assertives which inform: The door is shut• Directives which request: Shut the door – or query: Can pelicans fly?• Commissives which promise something: I will shut the door• Permissives which give permission for an act: You may shut the door• Prohibitives which ban some act: You may not shut the door• Declaratives which cause events in themselves: I name this door the

Golden Gate• Expressives which express emotions and evaluations: I wish this door

were the Golden Gate

Communication ActionsAction Illocutionary force Expected result

Assertion Inform AcceptanceQuery Question ReplyReply Inform AcceptanceRequest RequestExplanation Inform AgreementCommand RequestPermission Inform AcceptanceRefusal Inform AcceptanceOffer/bid Inform AcceptanceAcceptance

Assumptions of FIPA ACL

• The agents are communicating at a higher level of discourse, i.e. the contents of the communication are meaningful statements about the agent’s environment or knowledge.

• This assumption differentiates agent communication from other interaction mechanisms, such as method invocation in CORBA

• Abstract characterization of agent’s capabilities in terms of mental attitudes.*beliefs denote set of propositions (statements that can be true or false) which the agent currently accepts as true *Uncertainty, denotes sets of propositions an agent accepts as not

known as to be false or true*Intention, which denotes a choice or set of properties the agent

desires to be true and which are not currently believed to be true. An agent which adopts an intention will form a plan of action to bring about the state of the world indicated by his choice.

Set of requirements for FIPA ACL compliant agents

Requirement 1:

Agents should send “not understood” if they receive a message they do not understand; agents must also be able to handle properly a “not understood” message sent by another agent to them Requirement 2:

An ACL compliant agent may chose to implement any subset of the pre-defined message types and protocols.

Set of requirements for FIPA ACL compliant agents, cont.

Requirement 3:An ACL compliant agent, which uses the FIPA-defined communicative acts, must implement them correctly with respect to their definition Requirement 4:Agents may use communicative acts with other names, as long as they are responsible for ensuring the receiving agent will understand them; agents may not define new acts whose meaning is same as a pre-defined meaning. Requirement 5:An ACL compliant agent must be able to generate syntactically correct messages, and parse well formed messages it receives.

Overview ACL example (inform :sender agent1 :receiver hp1-auction-server :content (price (bid good02) 150) :in-reply-to round-4 :reply-with bid04 :protocol Auction :language sl :ontology hp1-auction)

Pre-defined Message Parameters :sender :receiver :content :reply-with :in-reply-to :envelope :language :ontology :reply-by :protocol :conversation-id

Requirement on Content Language A content language must be able to express propositions, objects/entities, and actions. No other properties are required.

•The FIPA specification does not mandate the use of any specific content language.

•The FIPA spec gives guidelines for simple syntax, e.g.—s-expressions are admissible as legal ACL messages

Primitive and Composite Communicative Acts (CA’s)

• Primitive CA’s are those whose actions are defined atomically

• Composite CA’s are composed by one of the following methods:

• making one CA the object of another (e.g.. “I request you to inform me whether it is raining”)

• using the compositional operator “;” to sequence actions (e.g. a ; b means action a followed by action b)

• using the compositional operator “!” to denote a non-deterministic choice of action (e.g. a ! b means a or b but not both)

Catalogue of Communicative Acts

Accept-proposal: accepting a previously submitted proposal to perform an action in the future, e.g. when a stated precondition becomes true (e.g. (accept-proposal :sender I :receiver j :in-reply-to bid089 :content ( (action j (stream-content moview1234 19)) (B j (ready customer78)) )“language sl)

Catalogue of Communicative Acts (cont.)

agree: agreeing to perform some action, possibly in the future cancel: cancelling a previously requested action which has temporal extent cfp: the action of calling for proposals to performa a given action confirm: sender informs the receiver that a given proposition is true, where the receiver is known to be uncertain about the proposition disconfirm: the sender informs the receiver that a give proposition is false, where the receiver is known to believe, or believe it likely that a proposition is true.

Catalogue of Communicative Acts (cont.)inform: the sender informs the receiver that a given proposition is true

*the sending agent(a) holds that some proposition is true(b) intends that the receiving agent also comes to believe that the proposition is true(c) does not already believe that the receiver has

any knowledge of the truth of the proposition *the receiving agent is entitled to believe

(a) the sender believes the proposition(b) the sender wishes the receiver to believe the proposition also

Catalogue of Communicative Acts (cont.)failure: the action of telling the receiver that an action was attempted but failed inform-if: a macro action for the agent of the action to inform the recipient of whether or not a proposition is true (e.g. Agent I requests j to inform it whether Katia is in Pittsburgh) inform-ref: a macro action for sender to inform the receiver the object which corresponds to a definite description (e.g. a name) not-understood: the sender k informs the receiver j that it perceived that j performed some actin but k does not understand what j did (a common case is when k tells j it does not understand the message that j sent to k)

Catalogue of Communicative Acts (cont.)propose: the action of submitting a proposal to perform a certain action given a certain precondition query-if: the action of asking another agent whether or not a given proposition is true query-ref: the action of asking an agent for the object referred to by an expression refuse: the action of refusing to perform an action and explaining the reason for the refusal reject-proposal: the action of rejecting to perform some action during a negotiation

Catalogue of Communicative Acts (cont.)request: the sender requests the receiver to perform some action request-when: sender wants the receiver to perform some action when some given precondition becomes true request-whenever: sender wants the receiver to perform some action as soon as some proposition becomes true and thereafter each time the proposition becomes true again. request-whomever: sender wants an action to be performed by some agent other than itself. The receiving agent should either perform the action or pass it to wsome other agent subscribe: the act of requesting a persistent intention to notify the sender of the value of a reference, and to notify again whenever the object identified by that reference changes

Interaction Protocols

Interaction protocols are standard patterns of message exchangeFIPA pre-specifies a (non-exhaustive) set of protocols to facilitate agent interaction. Requirement 8: An ACL compliant agent need not implement any of the standard protocols, nor is it restricted from using any other protocol names. However, if one of the standard names is used, the agent must behave consistently with the FIPA protocol specification.

FIPA-specified Protocols FIPA-request protocolFIPA-query ProtocolFIPA-request-when ProtocolFIPA-contract-net ProtocolFIPA-Iterated-Contract-Net ProtocolFIPA-Auction-English ProtocolFIPA-Auction-Dutch Protocol

Knowledge Query and Manipulation Language (KQML)

• Separation of protocol semantics from content semantics

• All of the information for understanding a message is included in the message

• A message structure (lisp like):

(KQML-performative:sender <word>:receiver <word>:language <word>:ontology <word>:content <expression>…)

KQML

• Example:(tell

:sender Agent1:receiver Agent2:language KIF:ontology Stocks:content (AND (ibm) (intl))

…)

Performative Categories

• Basic query performatives (ask-one, ask-all,...)• Multi-response query performatives (stream-in,..)• Response (reply, sorry,…)• Generic informational (tell, untell, achieve, …)• Generator (standby, ready, next, rest, …)• Capability definition (advertise, monitor, …)• Networking (register, broadcast, forward, …)

Summary of KQML and FIPA Semantic Assumptions

• KQML semantics presupposes a virtual

knowledge base for each agent.--Telling a fact corresponds to reporting on the knowledge base. Querying corresponds to the sending agent trying to extract a fact from the recipient’s knowledge base.

• KQML has only assertives and directives as primitives (performatives)

• KQML primitives cannot be composed.

Summary of KQML and FIPA Semantic Assumptions, cont.

• FIPA presupposes that an agent has beliefs, intentions and can represent uncertainty about facts.The performance conditions define when an agent can perform a specific communicationRequire the agents to reason about each other’s beliefs and intentions and behave cooperatively and sincerely.

• FIPA primitives are also only directives and assertives• FIPA primitives can be composed• FIPA also discusses interaction protocols

Critique of KQML and FIPA ACLs (Singh, Computer 1998)

• They both emphasize communication based on mental agency, which is antithetical to autonomy and heterogeneity of agents.

• KQML and FIPA emphasize the sender’s perspective, though both sender and receiver should be considered equal

Requirements for ACL that allows agent interoperation (Singh, Computer 1998)

• A useful ACL should be normative and have criteria for compliance• A useful ACL should consider the social context of the agents without imposition of

requirements for e.g. for the agents to be sincere.• Singh proposes, social semantics, I.e., communication should be based on agents’ social • context.

--agents belong to societies--agents play different roles within a society --roles entail social commitments to other roles within the society --an agent joins a society in one or more roles, thereby acquiring the role’s commitment--a role’s commitments are the restrictions of how an agent in that role must act and communicate --a protocol is defined as sets of commitments, rather than a finite state machine --designers can create specific protocols, hence societies, for different applications, e.g. e-commerce and publish the specifications of the societies and associated protocols.

Interoperation among different MAS

--Mas can differ in:• ACL• MAS architecture• capability advertisements• default agent query preferences

The RETSINA-OAA Interoperator (Giampapa et al Agents 2000)

• Goal: to allow any agent in RETSINA to access the services of any agent in OAA and vice versa

• Differences --RETSINA is a system with matchmaker organization --OAA uses a Facilitator --RETSINA agents speak KQML with a structured content language --OAA agents speak Prolog --These two languages have different syntactic and semantic

structure

RETSINA-OAA Interoperator Design Principles

• MAS interoperators should maintain distinct MAS boundaries

• MAS interoperators should be scalable • MAS interoperators should present increase in savings as new agents are added to

the interoperating MAs

• MAS interoperators should cross-register agent capabilities across MAS’s • MAS interoperational transparency: agents can dialogue across MAS’s without

being aware of the interoperator presence.

The LARKS Project Language for Advertisement and Requests for Knowledge Sharing

in heterogeneous and dynamic agent societies.

to ‘match’ requests with relevant provider agents

Enables automated interoperability among heterogeneous agents in the Internet/WWW

http://www.cs.cmu.edu/~softagents/interop/matchmaking.html

Frame-based specification of ads and requests of agent capabilities. Optional use of a domain ontology. Automated processing of LARKS specifications.

Matchmaking Services via Matchmaker Agents using LARKS

What is LARKS about?

______________________

Sycara, Lu, Klusch, “Interoperability Among Heterogeneous Software Agents on the Internet”, CMU-RI-TR-98-22

LARKS Protocol for providing the service

Matchmaking Using LARKS

Matchmaker Agent x

AdvertisementDBOntologyDBAuxiliaryDB

Requester AgentProvider Agent 1

Provider Agent n Local Ontology 1

Local Ontology n

Matching

Service Requestin LARKS

Result-of-Matching

Process Requeston Local IS IS

ISIS?

Capability Descriptions in LARKS

Context of Specification

Type

Input

Output

InConstraints

OutConstraints

Input/Output Variable Declarations

Logical Constraints on Variables(Pre-/Post-Conditions)

Context Data Types Used in Variable Declarations

Specification in LARKS

Service Matching Parameters: Time, Cost, Quality, etc.

ConcDescriptions Ontological Description of Used Words

Constraints: set of definite program clauses/goals (Horn clauses) Concepts: ontological description of words in concept language ITL

Context

InputOutput

OutConstraintsInConstraints

Attack, Air, Combat, Mission*AirMission

AirCombatMissions

missionTypes: SetOf(String);missionAirplanes: SetOf(String);missions: ListOf(mType: String, mID:String|Int, mStart: Date, mEnd: Date);

Examples for Specification in LARKS

ConcDescriptions [AirMission]

Types Date = (mm: Int, dd: Int, yy: Int);

Agent Advertisement: “I can provide information about air combat missions in general.”

Context

InputOutput

OutConstraints

InConstraints

Combat, Mission*AWAC-AirMission

AWAC-CombatMissions

missions: DeployedMission;

deployed(mID), mType = AWAC, launched_after(mID,mStart), launched_before(mID,mEnd).

ConcDescriptions [AWAC-AirMission]

Types Date = (mm: Int, dd: Int, yy: Int); DeployedMission = ListOf(mType: String, mID:String|Int, mStart: Date, mEnd: Date);

Agent Advertisement: “I can provide information about deployed and launched AWAC air combat missions. ”

AWAC-AirMission (and AirMission (atleast 1 has-airplane) (atmost 1 has-airplane) (all has-airplane aset(E-2)) …)

AirMission (and Mission (atleast 1 had-airplane) (all has-airplane Airplane) (all has-MissionType aset(AWAC,BARCAP,CAP,DCA,HVAA))… )

DCA-AirMission (and AirMission (all has-MissionType aset(DCA)) (all has-F14 plane-F14D) (all has-F18 plane-F18) (atleast 2 has-F14) (atmost 2 has-F14) (atleast 2 has-F18) (atmost 2 has-F18) (atleast 2 has-E2) (atmost 2 has-E2) …). . .

(1) An Ontology written in the Concept Language ITL (Terminology):

(2) Concept Subsumption Hierarchy:

AirMission

AWAC-AirMission DCA-AirMission . . .

Example for Ontology

HVAA-AirMission

Context

Input

Output

OutConstraintsInConstraints

Attack, Mission*AirMission

Req-AirCombatMissions

missions: Mission;

deployed(mID), launched_after(mID,sd), launched_before(mID,ed), (mType = AWAC;mType = CAP; mType = BARCAP; mType = DCA; mType = HVAA).

ConcDescriptions [AirMission]

Types Date = (mm: Int, dd: Int, yy: Int); Mission = ListOf(mType: String, mID:String|Int, mStart: Date, mEnd: Date);

Request: “Find an agent who can provide information on deployed air combat missions launched in a given time interval.”

sd: Date, ed: Date;

sd <= ed.

Context

InputOutput

OutConstraints

InConstraints

Combat, Mission*F14-Mission

Req-DeployedF14CombatMissions

missions: Mission;

deployed(mID), launched_after(mID,mStart),launched_before(mID,mEnd).

ConcDescriptions F14-Mission (and AirMission (atleast 1 has-F14))

Types Date = (mm: Int, dd: Int, yy: Int); Mission = ListOf(mType: String, mID:String|Int, mStart: Date, mEnd: Date);

Request: “Find an agent who can provide information on deployed and launched air combat missions that contain F-14 airplanes.”

Matchmaking Process

Syntactical Matching

Context Matching

Comparison of Profiles (TF-IDF)

Word Distances Distances in the Ontology (Weighted Associative Network)

Similarity Matching of Declarations and Constraints

Semantical Matching Logical Implication of Constraints

Main Steps:

Word Distances Subsumption or Equality of attached Concepts

(pairwise matching of specifications in LARKS)

Subsumption of Data Types Full Signature Matching of Declarations

“Complete Matching”:

All filters.

“Relaxed Matching”:

No signature matching.

“Profile Matching” :

Comparison of profiles (TF-IDF) only.

“Plug-In Matching”:

Signature and semantical matching only.

Different Matching Modes

Matchmaking Process: Simple Example

Request for Agent Capability in ‘Req-AirCombatMissions’ Advertisement of Agent Capability in ‘AWAC-AirCombatMissions’

Mode Plug-in Matching

Context Matching

Look-up/compute word distances for (Attack, Combat), (mission, Mission);All values exceed given threshold.Attached concepts are terminologically equal.

Syntactical Matching

Comparison of Profiles (TF-IDF) Profile similarity value of documents exceeds given threshold.Thus, proceed with

Matchmaking Process: Simple Example (cont’d)

Syntactical Matching (ff.)

Apply Type Inference Rules for Computing Type Subsumption.

Input declarations -D11 = sd: Date, ed: Date; Output declarations -D12 = missions: ListOf(mType: String, mID:String|Int, mStart: Date, mEnd: Date);D22 = missions: ListOf(mType: String, mID:String|Int, mStart: Date, mEnd: Date);

Result:Output declarations :signature(D12) = signature(D22)Input declarations: none in the advertisement.

Thus, proceed with

Full Signature Matching of Declarations

Similarity Matching

Compute word distances in declarations and constraints


Concepts attached to similar words: AirMission subsumes AWAC-AirMission.

Similarity value of two specifications:Average of sum of similarity computationsamong all pairs of declarations and constraints.

Similarity value for AWAC-AirCombatMissions and Req-AirCombatMissionsexceeds given threshold. Thus, proceed with

Semantical Matching of Constraints


OutConstraints in OutConstraints in AWAC-AirCombatMissions Req-AirCombatMissions:

InConstraints in InConstraints in Req-AirCombatMissions AWAC-AirCombatMissions:

sd <= ed;

deployed(mID),mType = AWAC, launched_after(mID,mStart), launched_before(mID,mEnd).

deployed(mID), launched_after(mID,sd), launched_before(mID,ed),(mType = AWAC; mType = CAP; mType = BARCAP; mType = DCA; mType = HVAA).

Current Implementations of LARKS Project

Web-based Interface for Specification of Requests in LARKS Matchmaker module Knowledge management module (Concept classifier, KB)

agents transacting in open environments

Documents