A Formal Architecture for the 3APL Agent Programming Language

A Formal Architecture for the 3APL Agent Programming Language Mark d’Inverno, Koen Hindriksy , and Michael Luckz  y Cavendish School of Computer Science, 115 New Cavendish Street, University of Westminster, London W1M 8JS, UK [email protected] Dept. of Computer Science, Universiteit Utrecht, P.O. Box 80.089; 3508 TB Utrecht, The Netherlands [email protected] z Department of Computer Science, University of Warwick, Coventry CV4 7AL, UK [email protected] Abstract. The notion of agents has provided a way of imbuing traditional computing systems with an extra degree of flexibility that allows them to be more resilient and robust in the face of more varied and unpredictable forms of interaction. One class of agents, typically called intelligent agents, represent their world symbolically according to their beliefs, have goals which need to be achieved, and adopt plans or intentions to achieve them. Now, one approach to building agents is to design a programming language whose semantics are based on some theory of rational or intentional agency and to program the desired behaviour of individual agents directly using mental attitudes. Such a technique is referred to as agent oriented programming. Arguably, the most innovative of these languages is 3APL (pronounced “triple-a-p-l”) which supports the construction of intelligent agents for the development of complex systems through a set of intuitive concepts like beliefs, goals and plans. In this paper, we provide a Z specification of the programming language 3APL which provides a basis for implementation and also adds to a growing library of agent techniques and features. 1 Introduction Recently, there has been an explosion of interest in agent-based systems and the related subfield of distributed artificial intelligence (DAI). The focus of much agent-based work is on building architectures for intelligent agents, providing information about essential data structures, relationships between these data structures, the processes or functions that operate on them and the operation or execution cycle of an agent. Deliberative Agent Systems symbolically model their environment and manipulate these symbols in order to act. In order to model rational or intentional agency, an abstraction level is chosen for the symbols such that they represent mental attitudes. Most agent systems include a deliberative architecture to support deliberative reasoning at the mental-attitude level. Mental attitudes used to describe and characterise the behaviour of agents include beliefs, goals, assumptions, desires, knowledge, plans, motivations and intentions, and are commonly grouped into three categories, informative, motivational and deliberative [9]. The first refers to that which a system considers to be true about the world and includes knowledge, beliefs and assumptions, the second to the ‘wants’ of a system including goals, desires and motivations, and the third concerns how an agent’s behaviour is directed and includes plans and intentions. The distinction between the second and third categories is subtle since it is possible that a system may desire a certain state without planning for it, or intending it to happen. There are several compelling reasons why agents defined using mental attitudes might be useful. First, if an agent can be described in terms of what it knows, what it wants and what it intends then, since it is modelled on familiar concepts, it becomes possible for users to understand and predict its behaviour. Second, understanding the relationship between these different attitudes and how they affect behaviour could provide the control mechanism for ‘intelligent action’ in general. Third, computational agents designed in this way may be able to interpret the behaviour of others independently of any implementation. Rather than defining an architecture, agent oriented programming is a paradigm for directly programming the behaviour of agents using computational languages whose semantics capture some theory of rational agency [14]. Typically agents have an initial set of beliefs, goals and plans and an interpreter that details how agents should achieve their goals given an environmental context. 1.1 The 3APL Programming Language One such agent programming language is 3APL which supports the design and construction of intelligent agents for the development of complex systems through a set of intuitive concepts like beliefs, goals and plans. In turn, these can be used to describe and understand the computational system in a natural way. Indeed, applications such as personal assistants [12] are naturally seen as agents that act on behalf of their users and in pursuit of user goals, using these concepts. 3APL supports this style of programming by means of an expressive set of primitives to program agents, which consist of sets of beliefs, goals and practical reasoning rules. Beliefs represent the issues the agent must deal with, while goals allow the agent both to focus on what it must achieve and to represent the way in which it can achieve it. In 3APL, goals are thus used to represent achievement goals and as plans. The practical reasoning rules provide the agent with planning capabilities to find an appropriate plan to achieve a goal, capabilities to create new goals to deal with a particular situation, and capabilities to use the rules to revise a plan. The architecture for 3APL [8] is based on the think-act cycle, which is divided into two parts. The first part corresponds to a phase of practical reasoning by using practical reasoning rules, and the second corresponds to an execution phase in which the agent performs some action. Originally, the operational semantics of 3APL was specified by means of Plotkinstyle transition semantics [7]. In this work, we provide a re-specification of 3APL in Z, which has a number of benefits. First, it helps to get closer to a good implementation of 3APL, because of the tools available for Z which support type-checking, animation, and so on. By specifying 3APL, we can provide a computational model that includes data structures, operation and architecture, thereby isolating the data-types for an efficient implementation of 3APL. Second, the process of re-specification provides a different perspective, highlighting different aspects of the language and architecture that are not manifested in a similar way in the transition style semantics. In carrying out this work, we aim to provide a clearer analysis and insight into agent languages and architectures, and add to a growing library (written in Z) of desirable and reusable agent features. The next section introduces the basic types used to build the 3APL model, comprising beliefs, actions, goals and practical reasoning rules. Then we define 3APL agents and finally we describe their operation. 2 3APL types Beliefs and goals are the basic types of expressions in 3APL from which rule expressions are derived. In this specification, beliefs are a subset of first order formulae (though in principle any knowledge representation language could be used), and this first order language is defined in the usual way. First order terms are defined by means of given sets of constants, first order variables, and function symbols. Since the programming language distinguishes between first order variables and variables that range over goals, we first define a partition of the set of variables, and use FOVar to denote the set of first order variables and Gvar to denote the set of goal variables. Const Var Fun Sym ℄ [ ; ; FOVar : P Var GVar : P Var FOVar \ GVar = ? FOVar [ GVar = Var The sets of all constants and function symbols are respectively denoted as [Const ℄ and [Fun Sym ℄. In terms of this specification, the contents of these sets are unimportant, and we use them directly without further elaboration. A first order term is either a constant, a first order variable, or a function symbol with a non-empty sequence of terms as a parameter. The auxiliary function fovars returns the set of all first order variables in a (first order) term. FOTerm ::= onst hhConst ii j var hhFOVar ii j fun tor hhFun Sym  seq1 FOTerm ii fovars : FOTerm ! (P FOVar ) 8 : Const ; v : FOVar ; f : Fun Sym ; ts : seq FOTerm  fovars ( onst ) = ? ^ fovars (var v ) = fv g ^ S fovars (fun tor (f ts )) = ft : FOTerm j t 2 (ran ts )  fovars t g ; 2.1 Beliefs Beliefs are defined by building types from the above primitives. The set of all predicate symbols is denoted by [PredSym ℄, and a belief atom is a predicate symbol with a (possibly empty) sequence of terms as its argument. Beliefs are then either an atom, the negation of an atom, the conjunction of two beliefs, or the implication of one belief by some other belief. PredSym ℄ [ Atom head : PredSym terms : seq FOTerm Belief pos hhAtom ii j not hhAtom ii j and hhBelief  Belief ii j imply hhBelief  Belief ii j false j true ::= The running example in this paper concerns a personal assistant for scheduling meetings and other activities, which acts on behalf of its user, monitors the need to schedule activities, and helps the user to find appropriate slots. The agent might also provide its user with information concerning the appropriate means of transportation to go to the location of a scheduled meeting. Part of the knowledge representation language of a personal assistant for scheduling (PAS) consists of predicates to represent, for example, the agenda of the user and the means of transportation to get from A to B. In particular, the predicate agenda represents the user’s agenda, with five arguments: agenda (A tivity Time Duration People Lo ; ; ; ; ) Each variable, respectively, represents the activity scheduled (such as meetings, lunch, etc), the date and time, the duration of the activity, the set of people involved, and the location. For example, the PAS may have the following belief concerning the user’s agenda, indicating that an hour meeting is scheduled for May 5th at 12:00 with John and Peter in Utrecht: pos agenda(meeting; may5th12 : 00; 60min; fjohn; peterg; utre ht) Other predicates include free (Time ; Length ), indicating that a free slot of length Length at time Time , and transport (Means ; FromLo ; ToLo ; Time ; DurTrans ), indicating that a possible means of moving from FromLo to ToLo at (date and) time Time is Means , and taking DurTrans time. Finally, lo ation (Lo ; Time ) keeps track of the location of the user at a particular time, which is assumed to be persistent. That is, without information to the contrary, the location of the user at a time T 0 after time T will be assumed to be the same as that at time T . 2.2 Actions In order to achieve goals or accomplish tasks, an agent must perform actions, represented by action symbols specified in the same way as atoms. A tionSym ℄ [ A tion name : A tionSym terms : seq FOTerm A basic action used by the PAS agent is the action ins agenda for inserting items in the belief base. The action has five associated arguments matching the arguments of the predicate agenda , and is used to insert a particular item in the agenda. Specifically, ins agenda (A tivity ; Time ; Length ; People ; Lo ) inserts the corresponding agenda predicate into the belief base of the PAS. For example, ins agenda(meeting; may5th12 : 00; 60min; [john; peter℄; utre ht) inserts an hour-long meeting scheduled for May 5th with John and Peter in Utrecht in the agenda of the agent. At this point, a number of auxiliary functions may also be defined to return the set of variables in an atom, a belief, or an action, and which are used in the specification of the operation of an agent. atomvars : Atom ! (P FOVar ) beliefvars : Belief ! (P FOVar ) a tionvars : A tion ! (P FOVar ) 8 : Const ; v : FOVar ; f : Fun Sym ; ts : seq FOTerm ; at : Atom ; b1 b2 : Belief ; a : A tion  fovars ( onst ) = ? ^ fovars (var v ) = fv g ^ S fovars (fun tor (Sf ts )) = ft : FOTerm j t 2 (ran ts )  fovars t g ^ atomvars at = ft : FOTerm j t 2 (ran at terms )  fovars t g ^ beliefvars (pos at ) = atomvars at ^ beliefvars (not at ) = atomvars at ^ beliefvars (and (Sb1 b2 )) = beliefvars b1 [ beliefvars b2 ^ a tionvars a = ft : FOTerm j t 2 (ran a terms )  fovars t g ; ; : ; : 2.3 Goals, Contexts and Front Contexts In 3APL, goals are used to represent both the goals and the plans to achieve these goals of the agent. Goals are program-like structures that are built from basic constructs, such as actions, and regular imperative programming constructs, such as sequential composition and nondeterministic choice. 3APL goals can be characterised as goalsto-do, which are mental attitudes corresponding to plans of action to achieve a state of affairs, or goals-to-be, which are mental attitude corresponding to the state of affairs desired by an agent. For example, an agent may have adopted the goal-to-do of learning to play the piano, and then performing at the ZB conference dinner. This might be done in pursuit of the agent’s goal-to-be of wanting to be a pop-star rather than an academic. Contexts Before formally describing goals, we introduce the notion of contexts, which are goals with an extra feature called ‘holes’ that act as placeholders within the structure of goals1 . Contexts are well-known structures in programming language semantics, closely related to the concept of goals, and are used to describe the operation and architecture of 3APL agents. Use of contexts in this way differs substantially from the transition style semantics presented in [7], which is inappropriate in this Z specification, since it would require a recursive relationship between schemas. While contexts, by contrast, allow us to give an elegant specification of the operation of a 3APL agent, we must stress that their role is in the presentation of an architecture for 3APL, rather than in the 3APL language itself. More precisely, a context is either a basic action, a query goal, an achieve goal, the sequential composition of two contexts, the nondeterministic choice of two contexts, a goal variable or “” which represents a place within a context that might contain another context. In the definition below, we use the set of goal variables, GVar , to allow a process called goal revision to take place as will be described later. Context ::= ba hhA tion ii j query hhBelief ii j a hieve hhAtom ii j seq omp hhContext  Context ii j hoi e hhContext  Context ii j goalvar hhGVar ii j  The , which denotes the placeholder or hole within a context, is distinct from a goal variable. Although both  and a goal variable are placeholders,  is a facility used for specifying 3APL, whereas goal variables are part of 3APL itself. Five examples of contexts are shown in Figure 1. Goals We can now define a goal as a context without any occurrences of . Only the third context in Figure 1 is a goal since it contains no squares. None of the other contexts are goals because they contain at least one occurrence of . The auxiliary function square ount counts the occurrences of  in a context. square ount : Context ! N 8 a : A tion ; b : Belief ; at : Atom ; 1 2 : Context ; gv : GVar  square ount (ba a ) = 0 ^ square ount (query b ) = 0 ^ square ount (a hieve at ) = 0 ^ square ount (seq omp ( 1 2 )) = square ount 1 + square ount 2 ^ square ount ( hoi e ( 1 2 )) = square ount 1 + square ount 2 ^ square ount (goalvar gv ) = 0 ^ square ount  = 1 ; ; ; Goal == fg : Context j square ount g = 0g Front Contexts An important type of context, known as a front context, is used to illustrate significant properties of 3APL. Front contexts are contexts with precisely one 1 Note that our use of the term context is distinct from the notion of a context in such systems as AgentSpeak(L) [13, 3], which is defined as the pre-condition of a plan. hoi e (seq omp (; ba ins agenda(meeting; Time; Dur; People; Lo omp (seq omp (query pos free(Time; Length); ); goalvar X) 3:goalvar X 4:seq omp (; ba ins(agenda(meeting; Time; Dur; People; Lo )) 5: hoi e (seq omp (; ba ins(agenda(meeting; Time; Dur; People; Lo query (pos free(Time; Length))) 1: 2:seq ))); ) )); Fig. 1. Examples of Contexts occurrence of  at the front of the context. Informally, an element at the front of a context means that an agent could choose to perform this element first, so that if a  at the front of a context was replaced by a goal, then that goal could be performed first, before the remainder of the overall goal. A front context is defined formally as either a single square, the sequential composition of a front context with a goal, or the choice (in either order) of a front context and a goal. In Figure 1, neither Context 1, 2, nor 3 are front contexts, but both 4 and 5 are. front ontext : P(Context ) 8 f f 1 : Context ; g : Goal  front ontext (f ) , f =_ (f = seq omp (f 1 g ) ^ front ontext f 1 ) _ (f = hoi e (f 1 g ) ^ front ontext f 1 ) _ (f = hoi e (g f 1 ) ^ front ontext f 1 ) ; ; ; ; The type FrontContext is the set of contexts satisfying front FrontContext == ff : Context j front ontext f ontext . g Clearly any front context has only one occurrence of a ‘hole’. 8f : FrontContext  square ount f =1 A goal may contain both goal variables as well as first order variables. We therefore define three functions that return the set of all variables, goal variables and first order variables, respectively, of a goal. A definition of optional and related elements can be found in [3]. goalvars : optional [Goal ℄ ! (P Var ) goalgvars : optional [Goal ℄ ! (P GVar ) goalfovars : optional [Goal ℄ ! (P FOVar ) 8 g : optional [Goal ℄; a : A tion ; b : Belief at : Atom ; g1 g2 : Goal ; gv : GVar  goalvars ? = ? ^ goalvars fba a g = a tionvars a ^ goalvars fquery b g = beliefvars b ^ goalvars fa hieve at g = atomvars at ^ goalvars fseq omp (g1 g2 )g = goalvars fg1 g [ goalvars fg2 g ^ goalvars f hoi e (g1 g2 )g = goalvars fg1 g [ goalvars fg2 g ^ goalvars fgoalvar gv g = fgv g ^ goalgvars g = (goalvars g ) \ GVar ^ goalfovars g = (goalvars g ) \ FOVar ; ; ; 2.4 Practical Reasoning Rules A 3APL agent uses practical reasoning rules not only to plan in the more conventional sense, but also to reflect on its goals. Whilst the use of rules for planning is a familiar concept from the literature, using rules for reflection on goals or plans is less well known. Reflection allows an agent to re-consider one of its plans in a situation in which the plan will fail with respect to the goal it is trying to achieve or has already failed, or where a more optimal strategy can be pursued. Practical reasoning rules are divided into four classes: reactive rules, which are used not only to respond to the current situation but also to create new goals; plan-rules, which are used to find plans for achievement goals; failure-rules, which are used to replan when plans fail; and optimisation-rules, which can replace less effective plans with more optimal plans. (This classification of rules was first proposed in [8].) We introduce a type to correspond to each of these categories. PRType ::= rea tive j failure j plan j optimisation A practical reasoning rule consists of an (optional) head, which is a goal, an (optional) body which is a goal, a guard which is a belief and a type to define its purpose. Informally, a practical reasoning rule with head g , body p and guard b , states that if the agent tries to achieve goal g and finds itself in a situation b , then it might consider replacing g by a plan p as a means to achieve it. If it is a plan-rule, the goal g is of the form a hieve s where s is a simple formula, and the rule states that to achieve goal g in situation b , consider plan p . If it is a failure-rule, then g may be any goal and the rule states that if g fails in situation b , consider dropping g and instead, adopting strategy p to deal with the failure. Finally, if it is an optimisation-rule, then g may be any goal and the rule states that if g is not so efficient in situation b , consider dropping g and instead, adopting strategy p . Formally, we define a practical reasoning rule in the schema below, in which the conditions specify that a reactive-rule has an empty head (and it can be applied whenever the guard is true) and that a plan-rule has an achieve goal as its head. head = fa hieve s hedule(A tivity; Time; DurationA t; People; Lo )g; guard = and (pos free(Time; DurationA t); pos lo ation(FromLo ; Time)); body = fseq omp (seq omp ( query (pos transport(Means; FromLo ; Lo ; Time; DurationTrans)); ba ins agenda(Means; Time DurationTrans; DurationTrans; agent; FromLo ba ins agenda(A tivity; Time; Duration; People; Lo )))g ))); head = fseq omp (goalvar X; ba ins(agenda(A t; Time; Dur; People; Lo )))g; guard = neg free(Time; Dur); body = fa hieve find alternative time(A t; Time; Dur; People; Lo ; AltTime)g Fig. 2. Two Practical Reasoning Rules PRrule head body : optional [Goal ℄ guard : Belief type : PRType head = ? , type = rea tive ^ thehead 2 (ran a hieve ) ^ body 6= ? , type = plan ; Whilst there is a correspondence between the syntax of a PRrule and its purpose for reactive and plan rules, there is none for optimisation and failure rules because it is not possible to syntactically distinguish plans that fail or plans that can be optimised. The first rule in Figure 2 inserts an activity in the agenda. It states that a plan to achieve the scheduling of an activity is to find a means of transportation to the specified location, then reserve the time needed for transport in the agenda, and finally insert the activity itself in the agenda. This plan should only be used if the slot at time Time of length DurationA t is still free in the agenda. The second conjunct in the guard of the rule is used to retrieve the location of the user at time Time. Note that FromLo does not occur in the head of the rule so that the binding for it must be retrieved from the agent’s beliefs. This illustrates the two uses of a guard as specifying the situation in which the rule might be considered by the agent and alternatively to retrieve some parameters from the agent’s beliefs. The second rule of Figure 2 is a revision rule that deals with failure. It states that if the agent has a sequential goal of doing anything (denoted by the goal variable X) followed by the goal of inserting an activity in the agenda of a user at a slot which is not free (specified by the guard), then the agent should consider revising that goal and replacing it with the goal of finding an alternative time for the activity. Note that the variables that occur in the head and guard of a rule, are called the global variables of the rule, and those that occur in the body but not in the head or guard of the rule, are called the local variables. This distinction is made to separate the local data-processing in the body from the global variables that may also be used in other parts of a (complex) goal. In the first rule of Figure 2, the variables Means and DurationTrans are local variables that can only be used in the body of the goal and cannot transfer information to other parts of a (more complex) goal. Global variables, however, can be used to ‘communicate with the rest of the goal’ by parameter passing. 3 3APL Agents 3.1 Agents and Mental State An agent can be characterised by specifying its beliefs, goals, practical reasoning rules and expertise. The main difference between these components of an agent are that the former two sets are dynamically updated while the latter two are fixed and do not change. We define an agent as an entity consisting of the static expertise and rulebase, i.e. a set of practical reasoning rules. Agent expertise P A tion rulebase P PRrule 8 a expertise  a tionvars a ? : : : = This differs slightly from earlier work, in that the expertise of an agent is explicitly included as part of an agent. The predicate part of the schema indicates that the agent is only capable of performing grounded actions, since it is not clear how to specify the semantics of actions that contain variables. The interpretation of the instantiation of free variables in an action as a sensing act which semantically could be specified as a function of the environment of the agent fall outside the scope of this paper. We only deal with the specification of the components of a single agent in this paper. The beliefs of an agent are recorded in its beliefbase and the goals of an agent in its goalbase. Together, these comprise the mental state of an agent. During the execution of an agent, its mental state is updated; the goals and beliefs of the agent are dynamic. AgentState Agent beliefbase P Belief goalbase P Goal : : Only the mental state of the agent may change during the operation of an agent, not the expertise or the rulebase. This is shown in the schema below by the convention, which indicates that some state variables change, and the convention, which states that the dashed variables are equal to their undashed counterparts (i.e. no state change). 
AgentState AgentState AgentState  Agent 0
3.2 Initial Agent State A 3APL agent specifies the expertise (repertoire of basic actions), and a set of practical reasoning rules, but does not specify the initial beliefbase or goalbase of the agent, however. The first step in the operation of an agent, therefore, is to initialise the mental state. In the schema below, b 0? and g 0? denote input variables. InitAgentState
AgentState b 0? : P Belief g 0? : P Goal beliefbase = b 0? goalbase = g 0? 0 0 The operation of an agent is parameterised by two semantic notions. First, the semantics of basic actions is defined by a global function, exe ute , which specifies that a basic action is an update operator on the beliefs of the agent. For example, the basic action ba ins(agenda(A t Time Dur People Lo )) of a scheduling agent updates the beliefs by inserting a new item in the agenda. Since exe ute is a global function, any two agents capable of performing an action are guaranteed to do the same thing when executing that action. This is particularly important to prevent confusion when specifying and programming agents. ; ; ; ; exe ute : A tion  P Belief !7 P Belief The second semantic notion needed to specify the semantics of agents is a logical consequence relation. The logical consequence relation determines which implications the agent is allowed to derive from its beliefs. Formally, the consequence relation is a relation between two sets of beliefs such that the first set of beliefs implies all the beliefs in the second set. The logical consequence relation is also global. This makes sure that all agents draw conclusions from their beliefs in the same way, which guarantees a “minimal amount of global consistency”. That is, one agent will not derive the negation of a belief b from the same set of beliefs from which another agent derives b . LogCon : P(P Belief  P Belief ) 4 3APL Agent Operation 4.1 Applying Practical Reasoning Rules Practical reasoning rules provide 3APL agents with reflective capabilities. The rules can be used to plan, revise, and create goals. The application of a rule is formally defined in this section. The application of a rule r to a goal g results in the replacement of a subgoal g 0 which matches with the head of rule r by the body of rule r in case the head of the rule is non-empty. If the body of the rule is empty, the subgoal is simply dropped. The application yields a substitution which is applied to the entire resulting goal. In head = fseq omp (goalvar X; ba ins agenda(A t; Time; Dur; People; Lo )))g; Rule: guard = negfree(Time; Dur); body = fa hievefind alternative time(A t; Time; Dur; People; Lo ; AltTime)g Bel: neg free(may5th10 : 00; 60min) seq omp (seq omp (ba ins(agenda(train; may5th9 : 30; 30min; [john℄; utre ht)); Goal: ba ins(agenda(meeting; may5th10 : 00; 60min; [john; peter℄; amsterdam))); a hieve (new s heduling task)) Fig. 3. Example Scenario for Practical Reasoning Rules # Substitution: Guard: New Plan (Goal): fX=ba ins(agenda(train; may5th9 : 30; 30min; [john℄; utre ht)); A t=meeting; Time=may5th10 : 00; Dur=60min; People=[john; peter℄; Lo =amsterdamg neg free(may5th10 : 00; 60min) seq omp ( a hieve find alternative time(meeting; may5th10 : 00; 60min; [john; peter℄; amsterdam; AltTime) ; a hieve (new s heduling task)) = Fig. 4. Results of Applying the Rule (and Substitution) case the head of a rule is empty only the guard of the rule needs to be derivable from the beliefs of the agent, and a new goal (the body of the rule) is added to the goalbase of the agent. Consider the example in Figure 3, with the practical reasoning rule of dealing with a failure of the scheduling of an activity, and a goal and belief as specified. Since the belief is an instance of the guard of the rule, and the goal can be unified with the head of the rule, the rule is applicable. Unifying the head of a rule with a (subgoal of a) goal of an agent amounts to finding a unifier (or substitution) which, when applied to the head of the rule and the goal makes them identical. In this example, unification yields a most general unifier, shown in Figure 4 which, when applied to the guard of the rule, gives the instantiated guard that is implied by the belief. Applying a rule to a subgoal means replacing that subgoal by the body of the rule, so that the new plan that replaces the original goal of the agent by applying the substitution, as also shown in the figure. The example illustrates that a subgoal at the front of a goal of the agent is replaced, rather than just any subgoal, and this is the case for all rule applications. Consequently, the front contexts introduced earlier are very useful in specifying rule application. Suppose that g 0 is a subgoal of some goal g that appears at the front of g , and 0 g matches with the head of a rule r . The task is to find a front context f such that if the subgoal g 0 is inserted for  (at the front of f ), the resulting goal is identical to g . Applying r then amounts to updating the f with the body of the rule. There is a crucial difference here between inserting and updating. Inserting a goal in a front context means substituting the goal for the  in the front context; while updating a front context with a goal means replacing  with that goal and also committing to the choices made (pursuing a subgoal in a choice goal means committing to the branch in which the subgoal appears in the choice goal). To formalise this, we define two functions, one to insert a goal into the square of a front context and one to update a front context with a goal. Insert : (Goal  FrontContext ) ! Goal 8 g g : Goal ; f : FrontContext  Insert (g ) = g ^ Insert (g seq omp (f g )) = seq omp (Insert (g f ) g ) ^ Insert (g hoi e (f g )) = hoi e (Insert (g f ) g ) ^ Insert (g hoi e (g f )) = hoi e (g Insert (g f )) ; 0 ; ; ; ; ; 0 ; 0 ; 0 ; 0 ; ; ; ; 0 0 ; Now, since a front context may be updated with the empty goal if a rule with empty body is applied or an execution step is performed (see below), the goal types of the function UpdateGoal are optional goals. Note that if the front context is a choice context, this commits to the branch where the  occurs. The latter branch is the one the agent has chosen to pursue. This is different from Insert , which left these branches intact. UpdateGoal : (optional [Goal ℄  FrontContext ) ! optional [Goal ℄ 8 g : optional [Goal ℄; f : FrontContext ; g : Goal  UpdateGoal (g ) = g ^ non empty UpdateGoal (g f ) ) (UpdateGoal (g seq omp (f g )) = fseq omp (the (UpdateGoal (g f )) g )g ^ UpdateGoal (g hoi e (f g )) = UpdateGoal (g f ) ^ UpdateGoal (g hoi e (g f )) = UpdateGoal (g f )) ^ empty UpdateGoal (g f ) ) (UpdateGoal (g seq omp (f g )) = fg g ^ UpdateGoal (g hoi e (f g )) = ? ^ UpdateGoal (g hoi e (g f )) = ?) 0 ; ; ; ; 0 ; ; ; 0 ; 0 ; 0 ; ; ; ; ; ; ; ; ; 0 0 0 0 ; Note that if the front context is of the form hoi e (; g ) for some goal g , and the empty goal is inserted for , Insert yields Insert ( hoi e (; g )) = fg g. This is a natural definition, but the empty goal could result with a different view on dropping a branch from a choice goal. A rule with empty body prevents an agent from attempting to execute a particular goal. If the dropped goal is a branch of a choice goal, Insert simply removes this branch. The definition of Insert above does not remove the alternative branch, however, so that the choice goal thus is still not completed. If there is a reason to remove the choice goal, then this reason should be stated in the guard of a rule which removes the choice goal completely. A rule is applicable if the head unifies with a (sub)goal of the agent and the guard of the rule follows from the agent’s beliefs. If the rule has no head, it is applicable simply if the guard follows from the beliefbase. For a treatment of substitutions, binding and unification please see Appendix A. appli able : P(PRrule  Goal  (P Belief )) 8 g : Goal ; r : PRrule ; bb : P Belief  non empty r :head ) (appli able (r ; g ; bb ) , (9 #; : Substitution ; subg : Goal ; f : FrontContext  Insert (subg ; f ) = g ^ mgu ((the r :head ); subg ) = # ^ (dom )  (beliefvars r :guard ) ^ LogCon (bb ; fASBelief (# z )r :guard g))) ^ empty r :head ) (appli able (r ; g ; bb ) , (9 # : Substitution j (dom #)  (beliefvars r :guard )  LogCon (bb ; fASBelief # r :guard g))) Using this definition, we can now specify the rule application. If the head of the rule is not empty, applying the rule amounts to replacing a subgoal by the body of the rule. Otherwise, we simply add the body of the rule to the goalbase of the agent. Care must be taken here to avoid interference of variables occurring in rules and those variables occurring in goals (cf. [7]. For this reason, all variables in the rule applied are renamed to variables not occurring in the target goal. A function RuleRename (r V ), which is not defined in this paper due to space constraints (but available on request from the authors), renames the variables in the rule r so that no variable from the set V of variables occurs in the renamed rule. ; RuleRename : (PRrule  (P Var )) ! PRrule ApplyRule
AgentState g ? : Goal ; r ? : PRrule ; rr : PRrule rr = RuleRename (r ?; goalvars fg ?g) r ?:type = 6 rea tive ) (9 f : FrontContext ; subg : Goal  Insert (subg ; f ) = g ? ^ (9 #; : Substitution j (dom )  (beliefvars rr :guard )  mgu (the rr :head ; subg ) = # ^ LogCon (beliefbase ; fASBelief (# z )rr :guard g) ^ beliefbase = beliefbase ^ goalbase = goalbase n fg ?g[ ASGoal (# z ) f(Insert (the (rr :body ); f ))g)) r ?:type = rea tive ) (9 : Substitution j (dom )  (beliefvars rr :guard )  LogCon (beliefbase ; fASBelief rr :guard g) ^ beliefbase = beliefbase ^ goalbase = goalbase [ ASGoal rr :body ) 0 0 0 0 4.2 Goal Execution The execution of a goal is specified through the computation steps an agent can perform on a goal. A computation step corresponds to a simple action of the agent, which is either a basic action or else a query on the beliefs of the agent. Recall that the semantics of basic actions is given by a global function exe ute and the semantics of beliefs is specified by the LogCon relation. The agent is only allowed to execute a basic action or query that occurs at the front of a goal, i.e. it is one of the first things the agent should consider doing. The notion of front context is useful to find an action or query which the agent might execute. If there is a front context f in which a basic action or query can be inserted for , and which results in a goal of the agent, the agent might consider executing that basic action or query. After executing the goal, the goal needs to be updated, and this updating is the same as updating the front context by removing . The execution of a basic action amounts to changing the beliefbase of the agent in accordance with the function exe ute . The condition (a beliefbase ) 2 (dom exe ute ) expresses that the basic action a is enabled, and thus can be executed. ; Exe uteBasi A tion
AgentState  Agent g ? : Goal (9 f : FrontContext ; a : A tion j a 2 expertise ^ Insert ((ba a ); f ) = g ? ^ (a ; beliefbase ) 2 (dom exe ute )  beliefbase = exe ute (a ; beliefbase ) ^ goalbase = (goalbase n fg ?g) [ UpdateGoal (fg; f )) 0 0 Queries are goals to check if some condition follows from the beliefbase of the agent. Any free variables in the condition of the query can be used to retrieve data from the beliefbase. The values retrieved are recorded in a substitution . A query can only be executed if it is a consequence of the beliefbase (otherwise, nothing happens). # Exe uteQueryGoal
AgentState  Agent g ? : Goal (9 f : FrontContext ; b : Belief  Insert (query b ; f ) = g ? ^ (9 # : Substitution  LogCon (beliefbase ; fASBelief # b g) ^ beliefbase = beliefbase ^ goalbase = (goalbase n fg ?g) [ (ASGoal # (UpdateGoal (fg; f 0 0 ))))) Executing a goal is then defined as the disjunction of these two functions. Exe uteGoal == Exe uteBasi A tion _ Exe uteQueryGoal 5 Conclusions In this paper we have described a specification of the agent-oriented programming language 3APL. The arguments for using Z in agent-based systems are well-rehearsed (eg.[5, 3]), and we will not re-state them here. In particular, however, Z enables a uniform presentation of both the 3APL programming language and its architecture in a clear and concise way. We are not familiar with any work that specifies both these aspects in this way, and believe that our work moves a step closer to a unified account of agent languages and architectures. The contribution of this work is threefold. First, we provide an operational specification of 3APL that can be used as the basis of a subsequent implementation, so that the transition from what might be called theory to practice is facilitated. At lower levels, this kind of transition is demonstrated, for example, through the provision of a simple agent simulation environment [11], and a sophisticated Jini-based development environment [1], both based on an extensive agent framework [10]. This work addresses the more detailed aspects involved in dealing with the transition of a fully designed system, rather than an outline structure. Second, we allow an easy and simple comparison of 3APL and its competitor systems that have been specified in a similar style such as AgentSpeak(L) [3] and dMARS [2], as illustrated in [6]. Third, we provide an accessible resource in the specification of techniques for the development of agent systems that might not otherwise be available in a form relevant both to agent architects and developers. This work can thus be viewed in a standalone fashion in contributing to the understanding of 3APL on the one hand, and in using it to provide a window on the larger area of generic agent architecture on the other. Acknowledgements. We would like to thank Jean-Jules Meyer for many constructive and helpful discussions during the preparation of this work, and the Universities of Westminster and Utrecht for hosting and supporting the authors during their collaboration. References 1. R. Ashri and M. Luck. Agent implementation through jini. In Proceedings of the Eleventh International Workshop on Database and Expert Systems Applications. IEEE Computer Society Press, to appear 2000. 2. M. d’Inverno, D. Kinny, M. Luck, and M. Wooldridge. A formal specification of dMARS. In Intelligent Agents IV: Proceedings of the Fourth International Workshop on Agent Theories, Architectures and Languages, Lecture Notes in Artificial Intelligence 1365, pages 155–176. Springer-Verlag, 1998. 3. M. d’Inverno and M. Luck. Engineering agentspeak(L): A formal computational model. Journal of Logic and Computation, 8(3):233–260, 1998. 4. M. R. Genesereth and N. Nilsson. Logical Foundations of Artificial Intelligence. Morgan Kaufman, 1987. 5. R. Goodwin. A formal specification of agent properties. Journal of Logic and Computation, 5(6):763–781, 1995. 6. K. Hindriks, M. d’Inverno, and M. Luck. Architecture for agent programming languages. In ECAI 2000: Proceedings of the Fourteenth European Conference on Artificial Intelligence, to appear 2000. 7. K. V. Hindriks, F. S. de Boer, W. van der Hoek, and J-J. Ch. Meyer. Formal Semantics for an Abstract Agent Programming Language. In Intelligent Agents IV: Proceedings of the Fourth International Workshop on Agent Theories, Architectures and Languages, Lecture Notes in Artificial Intelligence 1365, pages 215–229. Springer-Verlag, 1998. 8. K. V. Hindriks, F. S. de Boer, W. van der Hoek, and J-J. Ch. Meyer. Control structures of rule-based agent languages. In Intelligent Agents V, Lecture Notes in Artificial Intelligence 1555. Springer-Verlag, 1999. 9. G. Kiss. Goal, values, and agent dynamics. In G. M. P. O’Hare and N. R. Jennings (eds), editors, Foundations of Distributed Artificial Intelligence, pages 247–268. John Wiley and Sons, 1996. 10. M. Luck and M. d’Inverno. Structuring a Z specification to provide a formal framework for autonomous agent systems. In J. P. Bowen and M. G. Hinchey, editors, ZUM’95: The Z Formal Specification Notation, 9th International Conference of Z Users, Lecture Notes in Computer Science 967, pages 48–62. Springer-Verlag, 1995. 11. M. Luck, N. Griffiths, and M. d’Inverno. From agent theory to agent construction: A case study. In Intelligent Agents III: Proceedings of the Third International Workshop on Agent Theories, Architectures and Languages, Lecture Notes in Artificial Intelligence, 1193, pages 49–63. Springer Verlag, 1997. 12. P. Maes. Agents that reduce work and information overload. Communication of the ACM, 37(7):30–40, 1994. 13. A. S. Rao. Agentspeak(l): BDI agents speak out in a logical computable language. In W. Van de Velde and J. W. Perram, editors, Agents Breaking Away: Proceedings of the Seventh European Workshop on Modelling Autonomous Agents in a Multi-Agent World, Lecture Notes in Artificial Intelligence 1038, pages 42–55. Springer-Verlag, 1996. 14. Y. Shoham. Agent-oriented programming. Artificial Intelligence, 60(1):51–92, 1993. A Substitutions Here, we provide further details of the standard definitions of binding and unification, described in Z. First we define a substitution. This maps variables to terms, as well as mapping goal variables to goals. We therefore introduce a new type in order to define a substitution which we call SubTerm . A substitution is represented as a partial function between variables and terms since, in general, only some variables will be mapped to a term. (Remember that fovars is a function that returns the variables of a term, as defined earlier, at the end of Section 4.1.) SubTerm ::= term hhFOTerm ii j goal hhGoal ii allvars : SubTerm ! (P Var ) 8 t : FOTerm ; g : Goal  allvars (term t ) = fovars t ^ allvars (goal g ) = goalvars fg g Substitution == f# : Var !7 SubTerm g The standard definition of a substitution is a mapping from variables to terms such that no variable contained in any of the terms is in the domain of the mapping [4]. 8 # : Substitution  (dom #) \ fs S : SubTerm j s 2 (ran #)  allvars s g = ? We also have the following predicate concerning substitutions. 8 # : Substitution ; v : Var ; s : SubTerm ; t : FOTerm j (v ; s ) 2 #  (v 2 FOVar , s 2 (ran term )) ^ (v 2 GVar , s 2 (ran goal )) A.1 Application of Substitutions The function, ASFOVar , applies either the identity mapping to a variable if the variable is not in the domain of the substitution, or it applies the substitution if it is in the domain. (Note that this function is only defined for elements of FOVar not of GVar .) ASFOVar : Substitution ! FOVar ! FOTerm 8 # : Substitution ; v : FOVar  (v 62 (dom #)) ) ASFOVar # v (v 2 (dom #)) ) ASFOVar # v = = var v ^ term 1 (# v ) We can then define what it means for a substitution to be applied to a term. ASTerm : Substitution ! FOTerm ! FOTerm : Fun Sym ; ts : seq FOTerm ; # : Substitution j fun tor (f ; ts )  t 2 ran onst ) ASTerm # t = t ^ t 2 ran var ) ASTerm # t = ASFOVar # (var 1 t ) ^ t 2 ran fun tor ) ASTerm # t = ( new : FOTerm j rst (fun tor 1 new ) = f ^ se ond (fun tor 1 new ) = map (ASTerm #) ts ) 8 t : FOTerm ; f t = A substitution to be applied to an atom and an action. ASAtom : Substitution ! Atom ! Atom ASA tion : Substitution ! A tion ! A tion 8 a ; a 0 : Atom ; a t ; a t 0 : A tion ; # : Substitution  ASAtom # a = a 0 , a 0 :head = a :head ^ a 0 :terms = map (ASTerm #)a :terms ^ ASA tion # a t = a t 0 , a t 0 :name = a t :name ^ a t 0 :terms = map (ASTerm #)a t :terms ASBelief : Substitution ! Belief ! Belief 8 b; : Belief ; l ; a : Atom ; s : Substitution  ASBelief s (pos a ) = (pos (ASAtom s a )) ^ ASBelief s (not a ) = (not (ASAtom s a )) ^ ASBelief s (true) = true ^ ASBelief s (false) = false A substitution to be applied to a goal. Remember, goals contain goal variables as well as terms variables so as well as using all our previous definitions for substitution application we must define what it means to apply a substitution to a goal variable. This is considered in the final two predicates. ASGoal : Substitution ! optional [Goal ℄ ! optional [Goal ℄ 8 s : Substitution ; a : A tion ; b : Belief ; at : Atom ; g1 ; g2 : Goal ; gv : GVar  ASGoal s ? = ? ^ ASGoal s fba a g = fba (ASA tion s a )g ^ ASGoal s fquery b g = fquery (ASBelief s b )g ^ ASGoal s fa hieve at g = fa hieve (ASAtom s at )g ^ ASGoal s fseq omp (g1 ; g2 )g = fseq omp (the (ASGoal s fg1 g); the (ASGoal s fg2 g))g ^ ASGoal s f hoi e (g1 ; g2 )g = f hoi e (the (ASGoal s fg1 g); the (ASGoal s fg2 g))g ^ gv 62 (dom s ) ) ASGoal s fgoalvar gv g = fgoalvar gv g ^ gv 2 (dom s ) ) ASGoal s fgoalvar gv g = fgoal 1 (s gv )g A.2 Composition of Substitutions Consider two substitutions  and  such that no variable bound in  appears anywhere in  . The composition of  with  , written  z  , is obtained by applying  to the terms in  and combining these with the bindings from  . For example, if  = fx =A; y =B ; z =C g and  = fu =A; v =F (x ; y ; z )g then, since none of the variables bound in  (u ; v ) appear in  , it is meaningful to compose  with  . In this case  z  = fu =A; v =F (A; B ; C ); x =A; y =B ; z =C g. The definition is a bit convoluted though because of the typing needed top include goal variables. z Substitution  Substitution ) ! Substitution 8 ;  : Substitution j Sft : FOTerm ; s : SubTerm j (dom  ) \ ((dom  ) [ (s = term t ) ^ (s 2 (ran  ))  fovars t g) = ?   z  = ( [ fx : Var ; t : FOTerm ; s : SubTerm j (s = term t ) ^ (x ; s ) 2   (x ; term (ASTerm  t ))g) :( A.3 Unification A substitution is a unifier for two terms if the substitution, applied to both of them, makes them equal. unifyterms : P(Substitution  (Term  FOTerm )) 8 t1 ; t2 : FOTerm ; s : Substitution  unifyterms (s ; (t1 ; t2)) , (ASTerm s t1 = ASTerm s t2 ) A substitution is a unifier for two goals if the substitution, applied to both of them, makes them equal. unifygoals : P(Substitution  (Goal  Goal )) 8 g1 ; g2 : Goal ; # : Substitution  unifygoals (#; (g1 ; g2 )) , (ASGoal # fg1 g) = (ASGoal # fg2 g) A substitution is more general than another substitution if there exists a third substitution which, when composed with the first, gives the second. mg 8 #; : : P(Substitution  Substitution ) Substitution  mg # , (9 ! : Substitution  ( z !) = #) The mgu of two goals is specified as follows. mgu : (Goal  Goal ) ! Substitution 8 g1 ; g2 : Goal ; : Substitution  mgu (g1 ; g2 ) = , (unifygoals ( ; (g1 ; g2 )) ^ : (9 ! : Substitution  (unifygoals (!; (g1 ; g2 )) ^ (! mg ))))