1 / 57

Agents Transacting in Open Environments

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

jessie
Download Presentation

Agents Transacting in Open Environments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agents Transacting in Open Environments Two phases: • Locating appropriate agents • through different kinds of middle agents • Performing the transaction • with or without middle agents

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

  3. Matching Engine for Service Providers & Requesters sorted list of agent contact info unsorted list of agent contact info decision algorithm matching capabilities with requests (LARKS) matching capabilities with requests (LARKS) service request + parameters service request capability parameters capability parameters

  4. Broadcaster Request for service Requester Broadcaster Broadcast service request Offer of service Delegation of service Results of service request Provider 1 Provider n

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

  6. FacilitatorCombines Agent Location and Transaction Phases Request for service+pref. Requester Facilitator Results of service Advertisement of capabilities + para. Service result Delegation of service Provider 1 Provider n

  7. Contract Net Request for service + preferences Requester Manager Results of service Delegation of service Broadcast service request + pref Broadcast Results of Service Offer of service Broadcast Offer of service Provider 1 Provider 2 Provider n

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

  9. 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)

  10. Passive, Active, Peer

  11. 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)

  12. 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..”)

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

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

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

  16. Communication Actions

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

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

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

  20. 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 )

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

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

  23. 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)

  24. 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)

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

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

  27. 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)

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

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

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

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

  32. 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> …)

  33. KQML • Example: (tell :sender Agent1 :receiver Agent2 :language KIF :ontology Stocks :content (AND (ibm) (intl)) …)

  34. 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, …)

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

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

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

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

  39. Interoperation among different MAS --Mas can differ in: • ACL • MAS architecture • capability advertisements • default agent query preferences

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

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

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

  43. Matchmaking Using LARKS Matchmaker Agent x AdvertisementDB OntologyDB AuxiliaryDB Matching Result-of-Matching Capability Descriptions in LARKS Requester Agent Provider Agent 1 Service Request in LARKS LARKS Protocol for providing the service Provider Agent n Local Ontology 1 ? IS IS Process Request on Local IS IS Local Ontology n

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

  45. Examples for Specification in LARKS Agent Advertisement: “I can provide information about air combat missions in general.” AirCombatMissions Context Attack, Air, Combat, Mission*AirMission Types Date = (mm: Int, dd: Int, yy: Int); Input Output missionTypes: SetOf(String); missionAirplanes: SetOf(String); missions: ListOf(mType: String, mID:String|Int, mStart: Date, mEnd: Date); InConstraints OutConstraints ConcDescriptions [AirMission]

  46. Agent Advertisement: “I can provide information about deployed and launched AWAC air combat missions. ” AWAC-CombatMissions Context Combat, Mission*AWAC-AirMission Types 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]

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

  48. Request: “Find an agent who can provide information on deployedair combat missionslaunchedin a giventime interval.” Req-AirCombatMissions Context Attack, Mission*AirMission Types Date = (mm: Int, dd: Int, yy: Int); Mission = ListOf(mType: String, mID:String|Int, mStart: Date, mEnd: Date); Input sd: Date, ed: Date; Output missions: Mission; InConstraints sd <= ed. OutConstraints deployed(mID), launched_after(mID,sd), launched_before(mID,ed), (mType = AWAC; mType = CAP; mType = BARCAP; mType = DCA; mType = HVAA). ConcDescriptions [AirMission]

  49. Request: “Find an agent who can provide information on deployedand launched air combat missions that contain F-14 airplanes.” Req-DeployedF14CombatMissions Context Combat, Mission*F14-Mission Types 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))

More Related