Intelligent A gents
K atia S ycara
k atia@ cs.cm u.ed u
T h e R o b o tics In stitu te
Jo sep h G iam p ap a
g aro f@ cs.cm u .ed u
w w w .cs.cm u .ed u /~ so ftag en ts
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
sorted list of agent contact info
unsorted list of agent contact info
decision algorithm
matching capabilities with requests
service request
(LARKS)
capability parameters
matching capabilities with requests
service request
+ parameters
(LARKS)
capability parameters
Broadcaster
Request for service
Requester
Broadcaster
Broadcast
service request
Offer of service
Delegation of service
Results of
service request
Provider 1
Provider n
Matchmaking
Request for service
Requester
Matchmaker
Unsorted full description
of (P1,P2, …, Pk)
Advertisement
of capabilities
+para.
Delegation of service
Results of
service request
Provider 1
Provider n
Facilitator
Combines Agent Location and Transaction Phases
Request for service+pref.
Requester
Facilitator
Results of service
Delegation
of service
Advertisement
of capabilities
Service
+ para.
result
Provider 1
Provider n
Contract Net
Request for service
+ preferences
Requester
Results of service
Manager
Delegation
of service
Results of
Service
Broadcast
Broadcast
Offer
of service
Provider 1
Offer
of service
Provider 2
Broadcast service
request + pref
Provider n
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
P assiv e
ag en t
R eceiv e
assertio n s
R eceiv e
q u eries
S en d
assertio n s
S en d
q u eries

A ctiv e
ag en t



P eer ag en t






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 Actions
A ction
Illocutionary force
E xpected resu lt
A ssertion
Inform
A cceptance
Q uery
Q uestion
R eply
R eply
Inform
A cceptance
R equest
R equest
E xplanation
Inform
C o m m and
R equest
P erm ission
Inform
A cceptance
R efusal
O ffer/bid
A cceptance
Inform
Inform
A cceptance
A cceptance
A greem ent
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 nondeterministic 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 exchange
FIPA 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 protocol
FIPA-query Protocol
FIPA-request-when Protocol
FIPA-contract-net Protocol
FIPA-Iterated-Contract-Net Protocol
FIPA-Auction-English Protocol
FIPA-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 communication
Require 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
What is LARKS about?
 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
 to ‘match’ requests with relevant provider agents
in heterogeneous and dynamic agent societies.
Enables automated interoperability among heterogeneous agents
in the Internet/WWW
http://www.cs.cmu.edu/~softagents/interop/matchmaking.html
______________________
Sycara, Lu, Klusch, “Interoperability Among Heterogeneous Software Agents on the Internet”,
CMU-RI-TR-98-22
Matchmaking Using LARKS
Matchmaker Agent x
AdvertisementDB
OntologyDB
AuxiliaryDB
Matching
Result-of-Matching
Requester Agent
Service Request
in LARKS
Capability Descriptions
in LARKS
Provider Agent 1
LARKS Protocol
? for providing the Provider Agent n
service
Process Request
on Local IS
IS
ISIS
Local Ontology n
Local
Ontology 1
Specification in LARKS
Context
 Context of Specification
Type
 Data Types Used in Variable Declarations
Input
 Input/Output Variable Declarations
Output
InConstraints
OutConstraints
 Logical Constraints on Variables
(Pre-/Post-Conditions)
ConcDescriptions
 Ontological Description of Used Words
Service Matching Parameters: Time, Cost, Quality, etc.
 Constraints: set of definite program clauses/goals (Horn clauses)
 Concepts: ontological description of words in concept language ITL
Examples for Specification in LARKS
Agent Advertisement:
“I can provide information about air combat missions in general.”
AirCombatMissions
Context
Types
Input
Attack, Air, Combat, Mission*AirMission
Output
missionTypes: SetOf(String);
missionAirplanes: SetOf(String);
missions: ListOf(mType: String, mID:String|Int,
mStart: Date, mEnd: Date);
Date = (mm: Int, dd: Int, yy: Int);
InConstraints
OutConstraints
ConcDescriptions
[AirMission]
Agent Advertisement:
“I can provide information about deployed and launched AWAC air combat missions. ”
AWAC-CombatMissions
Context
Types
Combat, Mission*AWAC-AirMission
Date = (mm: Int, dd: Int, yy: Int);
DeployedMission =
ListOf(mType: String, mID:String|Int,
mStart: Date, mEnd: Date);
Input
Output
missions: DeployedMission;
InConstraints
OutConstraints
deployed(mID), mType = AWAC,
launched_after(mID,mStart), launched_before(mID,mEnd).
ConcDescriptions
[AWAC-AirMission]
Example for Ontology
(1) An Ontology written in the Concept Language ITL (Terminology):
AirMission  (and Mission (atleast 1 had-airplane) (all has-airplane Airplane)
(all has-MissionType aset(AWAC,BARCAP,CAP,DCA,HVAA))… )
AWAC-AirMission  (and AirMission (atleast 1 has-airplane) (atmost 1 has-airplane)
(all has-airplane aset(E-2)) …)
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) …)
...
(2) Concept Subsumption Hierarchy:
AirMission
AWAC-AirMission
DCA-AirMission
...
HVAA-AirMission
Request:
“Find an agent who can provide information on
deployed air combat missions launched in a given time interval.”
Req-AirCombatMissions
Context
Types
Attack, Mission*AirMission
Input
sd: Date, ed: Date;
Output
missions: Mission;
InConstraints
sd <= ed.
Date = (mm: Int, dd: Int, yy: Int);
Mission = ListOf(mType: String, mID:String|Int,
mStart: Date, mEnd: Date);
OutConstraints
deployed(mID), launched_after(mID,sd),
launched_before(mID,ed), (mType = AWAC;
mType = CAP; mType = BARCAP; mType = DCA;
mType = HVAA).
ConcDescriptions
[AirMission]
Request:
“Find an agent who can provide information on
deployed and launched air combat missions that contain F-14 airplanes.”
Req-DeployedF14CombatMissions
Context
Types
Combat, Mission*F14-Mission
Date = (mm: Int, dd: Int, yy: Int);
Mission = ListOf(mType: String, mID:String|Int,
mStart: Date, mEnd: Date);
Input
Output
missions: Mission;
InConstraints
OutConstraints
deployed(mID), launched_after(mID,mStart),
launched_before(mID,mEnd).
ConcDescriptions
F14-Mission  (and AirMission (atleast 1 has-F14))
Matchmaking Process
Main Steps:
(pairwise matching of specifications in LARKS)
 Context Matching
 Word Distances
 Subsumption or Equality of attached Concepts
 Syntactical Matching
 Comparison of Profiles (TF-IDF)
 Similarity Matching of Declarations and Constraints
 Word Distances
 Distances in the Ontology (Weighted Associative Network)
 Full Signature Matching of Declarations
 Subsumption of Data Types
 Semantical Matching
 Logical Implication of Constraints
Different Matching Modes
 “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.
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.)
 Full Signature Matching of Declarations 
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);
 Apply Type Inference Rules for Computing Type Subsumption.
Result:
Output declarations :signature(D12) = signature(D22)
Input declarations: none in the advertisement.
Thus, proceed with
Matchmaking Process: Simple Example (cont’d)
 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 computations
among all pairs of declarations and constraints.
Similarity value for AWAC-AirCombatMissions and Req-AirCombatMissions
exceeds given threshold.
Thus, proceed with
Matchmaking Process: Simple Example (cont’d)
 Semantical Matching of Constraints 
InConstraints in
Req-AirCombatMissions
InConstraints in
 AWAC-AirCombatMissions:
sd <= ed;
OutConstraints in
AWAC-AirCombatMissions 
deployed(mID),
mType = AWAC,
launched_after(mID,mStart),
launched_before(mID,mEnd).
OutConstraints in
Req-AirCombatMissions:
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)
Descargar

Document