1 / 30

The Semantics of MALLET--An Agent Teamwork Encoding Language

This paper discusses the semantics and implementation of MALLET, a language for encoding agent teamwork knowledge. It explores the syntax, semantics, and objectives of MALLET and compares it to existing approaches in encoding teamwork knowledge. The paper also covers the types of information needs in agent teamwork and the syntax for control messages, goals, and intentions in MALLET. Additionally, it explains the semantics of beliefs, goals, and intentions in MALLET and discusses the termination of plans.

smonson
Télécharger la présentation

The Semantics of MALLET--An Agent Teamwork Encoding Language

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. The Semantics of MALLET--An Agent Teamwork Encoding Language • Xiaocong FanSchool of Information Sciences and Technology The Pennsylvania State University • July 19, 2004

  2. Outline • Background on TOP • Objectives of MALLET • Syntax • Semantics • An implemented interpreter • What’s the distinguishing features?

  3. Team-Oriented Programming • Language level • Tidhar: Constructs for describing team behaviors based on mutual beliefs, joint plans and social structures • Methodology level • Pynadath, et al: Mechanism (reusable team wrapper) for supporting rapid development of agent teams

  4. The state of art: Encoding teamwork knowledge • Atomic team operators • Tidhar’s TOP supports atomic team operators • Joint team activities: long-term process involving multiple agents • The notion of team operator in STEAM • Shared team plans: common recipes that govern the collaboration behaviors • GRATE* has a higher-level language support • RETSINA uses the concept of shared plans, but no encoding language • JACK Teams uses Java

  5. The state of art: Dynamic task assignment • Role-capability matching • STEAM, JACK Teams • Constraints reasoning • RETSINA NO language-level support for specifying task-allocations within team plans

  6. The state of art: Complex teamwork process • GRATE*, JACK Teams, and TOP provided control constructs for coding complex team behaviors • Par, while, if, etc. • However, none of the existing approaches support the coding of decision points in a team plan

  7. Types of information needs • Action-performing information-need • Decision-making information-need • Goal-protection information-need • Goal-escape information-need

  8. Objectives of MALLET • A language suitable for encoding agent teamwork knowledge, especially for composing complex teamwork behaviors • Expressivity: three-level support, choice points • Understandability: high-level • Reusability: representation be independent of the context in which the knowledge is used • Encourage inferred team intelligence • support the specification of collaboration constraints, such as action preconditions and plan termination conditions • Allow the specification of adaptive team structure and team process

  9. Syntax

  10. Syntax

  11. Preparations—Control messages • A control message is a tuple < type, aid, gid, pid,olist >, • type {sync, ctell, cask, unachievable}, • aid is the sending agent, • gid is a well-formed first-order formula, denoting a goal. • pid is a plan id, • olist is a list of extra parameters varying from message type to message type. • A message of type sync is used to synchronize with a recipient with respect to the committed goal gid and current activity pid; • A message of type ctell is used to tell a recipient about the status of pid; • A message of type cask is used to request a recipient to perform pid; • A message of type unachievable is used to inform a recipient of the unachievability of pid. MALLET has a built-in domain-independent operator send (receivers, msg) • Assume pre(send)=true, and the execution of send always succeeds. • If <typ,a, …> is a control message, the effect of send (b,<typ,a,…>) will assert (typ\ a …>) as a fact into agent a's belief base. • The recipient of a control message will also assert an appropriate fact into its belief base. • For instance, when agent b receives message <sync, a, g, p>, predicate (sync a g p) will be asserted into b's belief base.

  12. Preparations—Goals and Intentions • A goal g is a pair <,A>. • An intention slice is of form (,A) s. • An intention is : [0\...\ k], where i (0 i  k) is of form (i,Ai) si. • The empty intention is denoted by T. • If h =[0\...\ k], [h\ '] = [0\...\ k\'].

  13. Preparations—Configuration • Def. 1 (MALLET configuration): A MALLET configuration of an agent is a tuple < B, G, H, >, where (1) B is consistent, (2) for any goal gG, g is not derivable from B and g is consistent by itself. • Def. 2 (achievement goal): Function agls is defined recursively as: • agls(T) = {}, • for any intention h=[0\...\ k-1\ (k, Ak) sk], agls(h) = {k}  agls([0\...\ k-1]).

  14. Preparations—Assumptions • A belief update function BU(B,p), which revises the belief base B with a new fact p. • Two domain-independent operators working on B: • unsync(,), and • untell(,s). • Their effects are to remove all the predicates that can be unified with • sync(?a, ,) and • ctell(?a, ,s,?id), respectively, from B. • B allows explicit negation. For any b(t), its explicit negation is denoted by • The execution of atomic operators always succeeds

  15. Semantics—beliefs, goals, intentions • Def. 3 : Given a Mallet configuration M= <B, G, H,  >, for any wff , any belief or goal formula ,’, any agent a,

  16. Semantics—termination of plans • The execution of a plan invocation  is terminated (i.e., isTermed() is derivable from the current configuration), iff: • On plan entering, the plan precondition does not hold, • In plan execution, the termination conditions become true, • On plan completion, the expected postcondition is not true. • Note: When isTermed ) is evaluated as true, a predicate of form (termed t) will be asserted into B, so that in later transitions the termination can be propagated upwards to a higher plan level.

  17. Semantics—termination of plans

  18. Semantics—goal selection

  19. Semantics—end of intention

  20. Semantics—Agent selection

  21. Semantics—Sequential execution

  22. Semantics—individual operator

  23. Semantics—team operator

  24. Semantics—joint-do

  25. Semantics—plan

  26. Semantics—choice

  27. Semantics—parallel

  28. Semantics—composite plans

  29. An implemented interpreter: CAST

  30. What’s the distinguishing features? • MALLET vs. OWL-S • MALLET is designed for encoding team intelligence that requires collaboration • MALLET vs. planning language (e.g., PDDL) • Guiding collaboration vs. guiding planning • MALLET vs. JACK Teams • High-level vs. lower-level

More Related