Agent goals & autonomy in AOP

Development

1. Technologies presentation - which problem does each one address?

   1. JADEX

      Jadex BDI ( http://www.activecomponents.org/bin/view/Documentation/Overview ) is an agent-oriented reasoning engine for writing rational agents with XML and the Java programming language. Thereby, Jadex represents a conservative approach towards agent-orientation for several reasons. One main aspect is that no new programming language is introduced. Instead, Jadex agents can be programmed in the state-of-the art object-oriented integrated development environments (IDEs) such as eclipse. The other important aspect concerns the middleware independence of Jadex. As Jadex BDI is loosely coupled with its underlying middleware, Jadex can be used in very different scenarios on top of agent platforms as well as enterprise systems such as J2EE.

   2. 2APL

      2APL (A Practical Agent Programming Language, pronounced double-a-p-l http://apapl.sourceforge.net/?page_id=11 ) is a BDI-based modular agent-oriented programming language that supports an effective integration of declarative programming constructs such as belief and goals, and imperative (style) programming constructs such as events and plans. It also provides practical programming constructs to allow the generation, repair, and (different modes of) execution of plans based on beliefs, goals, and events. This programming language facilitates the implementation of multi-agent systems consisting of individual agents that may share and access external environments.

   3. 3APL

      3APL ( http://www.cs.uu.nl/3apl/publications.html ) is a programming language for implementing cognitive agents. It provides programming constructs for implementing agents' beliefs, goals, basic capabilities (such as belief updates, external actions, or communication actions) and a set of practical reasoning rules through which agents' goals can be updated or revised. 3APL was developed and is maintained by a team at the computer science department of the University of Utrecht in the Netherlands. In “Agent Programming in 3APL”, speaking about the metaphor of intelligent agent, the authors says: “To support this new style of programming, we propose the agent programming language 3APL. 3APL has a clear and formally defined semantics. The operational semantics of the language is defined by means of transition systems. 3APL is a combination of imperative and logic programming. From imperative programming the language inherits the full range of regular programming constructs, including recursive procedures, and a notion of state-based computation. States of agents, however, are belief or knowledge bases, which are different from the usual variable assignments of imperative programming. From logic programming, the language inherits the proof as computation model as a basic means of computation for querying the belief base of an agent. These features are well-understood and provide a solid basis for a structured agent programming language. Moreover, on top of that 3APL agents use so-called practical reasoning rules which extend the familiar recursive rules of imperative programming in several ways. Practical reasoning rules can be used to monitor and revise the goals of an agent, and provide an agent with reflective capabilities.”

   4. PRACTIONIST

      PRACTIONIST (PRACTIcal reasONIng sySTem http://is.eng.it/practionist/DOC_papers.htm ) is a framework built on the Bratman’s theory of practical reasoning to support the development of BDI agents in Java. The framework is built on top of JADE and agents are deployed within JADE containers and have a belief base implemented in Prolog. The objectives of PRACTIONIST are well explained in “PRACTIONIST: a new framework for BDI agents”: “We aims at reducing the gap between the expressive power of the BDI model and the difficulty of efficiently implementing its features. In PRACTIONIST we adopt a goal-oriented approach and stress the separation between the deliberation process and the means-ends reasoning, with the abstraction of goal used to formally define both desires and intentions during the deliberation phase. Moreover, PRACTIONIST agents are able to reason about their beliefs and other agent’s beliefs, since beliefs are not simple grounded literals or data structures but modal logic formulas.”

   5. JASON

      Jason ( http://jason.sourceforge.net/wp/documents/ ) is an interpreter for an extended version of AgentSpeak. It implements the operational semantics of that language and provides a platform for the development of multi-agent systems with many user-customisable features. The extensions are aimed at a more practical programming language in order providing a high level language to define agents (goal oriented) behaviour, while using Java as low level language to realize mechanisms (i.e. agent internal functions) and customize the architecture

1. Implementation of:

   1. agent

      • JADEX: To develop applications with Jadex, the programmer has to create two types of files: XML agent definition files (ADF) and Java classes for the plan implementations. The ADF can be seen as a type specification for a class of instantiated agents. The header of an ADF file is as follows: <agent xmlns="http://jadex.sourceforge.net/jadex-bdi"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://jadex.sourceforge.net/jadex-bdi
                                   http://jadex.sourceforge.net/jadex-bdi-2.0.xsd"
         name="Buyer" package="jadex.bdi.examples.booktrading.buyer">
          ...
        </agent> The elements that can be specified inside an agent definition file are (the order is significant): To modularize agent functionality, agents can be decomposed into capabilities. The core part of the agent specification regards the definition of the beliefs, goals, and plans of the agent, which are placed in the , , and tag, respectively. The events known by the agent are defined in the section. The tag allows to specify expressions and conditions, which can be used as predefined queries from plans. The tag is used for custom settings such as debugging and logging options. Finally, in the section, predefined configurations containing, e.g., initial beliefs, goals, and plans, as well as end goals and plans are specified. Source: http://www.activecomponents.org/bin/view/BDI+User+Guide/03+Agent+Specification
      • 2APL: At the individual agent level, 2APL agents are implemented in terms of beliefs, goals, actions, plans, events, and three different types of rules. The beliefs and goals of 2APL agents are implemented in a declarative way, while plans and (interfaces to) external environments are implemented in an imperative programming style. The declarative programming part supports the implementation of reasoning and update mechanisms that are needed to allow individual agents to reason about and update their mental states. The imperative programming part facilitates the implementation of plans, flow of control, and mechanisms such as procedure call, recursion, and interfacing with existing imperative programming languages. It should be noted that a 2APL agent can observe an environment either actively by means of a sense action or passively by means of events generated by the environment.
      • 3APL: A 3APL-agent is a tuple (B, G, P, A) where B is a set of beliefs (called belief-base), G is a set of goals (called goal-base), P is a set of practical reasoning rules (called rule-base) and A is a set of basic actions (called action-base). An agent is defined as follows and is composed by six main blocks that must be defined: PROGRAM “agentName”
        CAPABILITIES {}
        BELIEFBASE {}
        GOALBASE {}
        PLANBASE {}
        PG-RULES {}
        PR-RULES {} The architecture of a 3APL agent is shown in the figure:
      • PRACTIONIST: Agents are structured in two main layers: the framework defines the execution logic and provides some built-in services implementing such a logic, while the top layer includes the specific agent components to be defined in order to satisfy specific application requirements. Therefore, a developer who wants to design a PRACTIONIST agent has to specify: - the goals the agent could pursue and the relationships among them (Goal Model); - a set of plans (Plan Library) to pursue that goals or react to stimuli coming from environment; - a set of perceptors to receive such stimuli; - the Actions the agent could perform and the corresponding Effectors; - the set of beliefs and rules (Belief Base) to model information about both its internal state and the external world. Then the framework provides the required built-in services that define the computational model of PRACTIONIST agents such as the Belief Logic, the Deliberation mechanisms that produce agent intentions, the way the agent makes Means-ends Reasoning to figure out the means (i.e. plans) to achieve its intentions, and the support for the actual execution of such plans and management of perceptors and effectors. To develop applications with PRACTIONIST, the programmer has to create the class container of all their characteristics and components. To do this he simply has to: - create a new class extending the class AbstractAgent of the package org.practionist.core; - create a constructor with an array of objects as argument that specify all necessary arguments to start the agent; - implement the initialize() method and declare the agent’s plan library, belief set, perceptors, effectors, goal model and each potential goal. At design time it is possible to choose between two classes of agent: the AbstractAgentis endowed with a reasoning engine on beliefs fully implemented in Java (i.e. tuProlog), the other AbstractJPLAgent is endowed with the underlying reasoning engine of SWI-Prolog. Example: (PRACTIONIST Programming guide) package tileworld.player.advancedPlayer;
        import org.practionist.belief.*;
        import org.practionist.core.*;
        ...
        import org.practionist.goal.*;
        ...
        public class PlayerAgent extends AbstractAgent
        {
            public PlayerAgent(Object[] args)
            {
               super(args);
            }
            protected void initialize()
            {
              /** Put here the code to initialize the agent, in terms of initial
              * belief set, plan library, perceptors, effectors, initial goals.
              */
            }
        }
      • JASON: From the point of view of an (extended) AgentSpeak interpreter, and agent is: -a set of beliefs -a set of plans -some user-defined selection functions -a trust function (a “socially acceptable” relation for received messages), the Belief Update Function (which updates the agent’s belief base from perception of the environment, and can be customised by the user) and the Belief Revision Function, and a “circumstance” which includes the pending events, intentions, and various other structures that are necessary during the interpretation of an AgentSpeak agent. To develop a Jason multi-agent system the user must create two types of files. The first are configuration files that must have a name with extension .mas2j and the second is a file .asl which has the agent’s name. The BNF grammar below gives the syntax that can be used in the configuration file: The used after the keyword MAS is the name of the society; this is used, among other things, in the name of the scripts that are automatically generated to help the user compile and run the system. The keyword infrastructure is used to specify which of the underlying infrastructures for running a multi-agent system will be used. The options currently available in Jason’s distribution are either “Centralised” or “Saci”: the former is the default option, and the latter should be used if you need (some) agents to run on different machines over a network. Next an environment can be specified. This is simply the name of Java class that was used for programming the environment, normally. An optional host name where the environment will run can be specified. This is only available if you use SACI as infrastructure. Then there is an optional executionControl definition, which allows userdefined management of agents’ execution. Again what needs to be specified here is the name of a Java class that implements such control. Note that having an environment is optional; this might be useful e.g. for deploying a Jason system in a real-world environment. The keyword agents is used for defining the set of agents that will take part in the multi-agent system. An agent is specified first by its symbolic name given as an AgentSpeak term (i.e., an identifier starting with a lowercase letter); this is the name that agents will use to refer to other agents in the society (e.g. for inter-agent communication). Then, an optional filename can be given (it may include a full path, if it is not in the same directory as the .mas2j file) where the AgentSpeak source code for that agent is given; by default Jason assumes that the AgentSpeak source code is in file .asl, where is the agent’s symbolic name. There is also an optional list of settings for the AgentSpeak interpreter available with Jason. An optional number of instances of agents using that same source code can be specified by a number preceded by #; if this is present, that specified number of “clones” will be created in the multi-agent system. In case more than one instance of that agent is requested, the actual name of the agent will be the symbolic name concatenated with an index indicating the instance number (starting from 1). As for the environment keyword, an agent definition may end with the name of a host where the agent will run (preceded by “at”). As before, this is only available if the SACI-based infrastructure was chosen. Finally, user-defined overall agent architectures and other user-defined functions to be used by the AgentSpeak interpreter for each particular agent can be specified with the keywords agentArchClass, beliefBaseClass, and agentClass. Jason provides great flexibility by allowing users to easily redefining the default functions used in the interpreter.

   2. belief

      This is the part concerning the BELIEF in the BDI programming approach. Beliefs represent the agent's knowledge about its enviroment and itself.
      • JADEX: In Jadex the beliefs can be any Java objects. They are stored in a belief base and can be referenced in expressions, as well as accessed and modified from plans using the beliefbase interface. The belief base is the container for the facts known by the agent. Beliefs are usually defined in the ADF and accessed and modified from plans. To define a single valued belief or a multi-valued belief set in the ADF the developer has to use the corresponding or tags and has to provide a name and a class. The name is used to refer to the fact(s) contained in the belief. The class specifies the (super) class of the fact objects that can be stored in the belief. The programmer has access to the belief base from within a plan. Here is an example of using a Boolean belief: public void body
        {
         //...
         IBelief hungry = getBeliefbase().getBelief("hungry");
          hungry.setFact(new Boolean(true));
         //...
         Food[] food = (Food[])getBeliefbase().getBeliefSet("food").getFacts();
         //...
        } In the ADF the initial facts of beliefs are specified using expressions. Normally, the fact expressions are evaluated only once: When the agent is born. The evaluation behavior of the fact expression can be adjusted using the evaluationmode attribute. Possible values are 'static' (default), 'pull' and 'push'. Additionally, an updaterate may be specified as attribute of the belief that will cause the fact to be continuously evaluated and updated in the given time interval (in milliseconds). Here are two examples of dynamically evaluated beliefs: <beliefs>
         <!-- A belief holding the current time (re-evaluated on every access). -->
         <belief name="time" class="long" evaluationmode="pull">
           <fact>System.currentTimeMillis()</fact>
         </belief>
        
         <!-- A belief continuously updated every 10 seconds. -->
         <belief name="timer" class="long" updaterate="10000">
           <fact>System.currentTimeMillis()</fact>
         </belief>
        </beliefs> Source: http://www.activecomponents.org/bin/view/BDI+User+Guide/06+Beliefs
      • 2APL: An agent may have initial beliefs and goals that change during the agent’s execution. In 2APL, the initial beliefs of an agent are implemented by the belief base, which includes information the agent believes about itself and its surrounding world including other agents. The implementation of the initial belief base starts with the keyword ‘Beliefs’ followed by one or more belief expressions. Note that a expression is a Prolog fact or rule such that the belief base of a 2APL agent becomes a Prolog program. All facts are assumed to be ground. The following example illustrates the implementation of the initial belief base of a 2APL agent. Beliefs:
           pos(1,1).
           hasGold(0).
           trash(2,5).
           trash(6,8).
           clean(blockWorld) :- not trash(_,_).
      • 3APL: In 3APL beliefs can be expressed with any type of knowledge representation language, like a modal language or a first order language. The knowledge representation language thus is a plug-in feature of 3APL and the choice of such a language can be decided upon during the desing of an agent system. The beliefs, defined using Prolog syntax, are used to remember information and to perform logical computations. Beliefs can be read by each other, edited by the capabilities, and read by conditional statements in the plans. The initial beliefs of an agent can be defined in its belief base. An example of definition of the initial beliefs of an agent is: BELIEFBASE {
                status(standby).
               at(0,0).
               location(r1,2,4).
               location(r5,6,1).
                dirty(r1).
                dirty(r5).
        }
      • PRACTIONIST: The PRACTIONIST framework adopts the common approach of modelling agents’ beliefs by the doxastic modal logic. Thus, beliefs are expressed through the modal operator Bel(a,?), whose arguments are the agent a (the believer) and what it believes (?, the fact). Each fact ? may be believed true or false by a PRACTIONIST agent a, or moreover the agent may not have any belief about ?, i.e.: - Bel(a,?) : the agent a believes that ? is true; - Bel(a,-?) : the agent a believes that ? is false; - Ubif(a,?)= -Bel(a,?) AND -Bel(a,-?) : the agent a don’t have any belief about ?; It is possible to link agent’s beliefs to others’ beliefs, obtaining new entailed beliefs: Bel(tom,Bel(john,raining)) AND Bel(tom,trust(who:john))=>Bel(tom,raining) The agent’s initial belief base is expressed in a Prolog-like language. In order to make agents handle the belief base at run time, PRACTIONIST provides two interfaces, both contained in the org.practionist.belief package: one is the BeliefSet providing all methods to query the belief base; the other is the BeliefBase extending the former and providing also the methods to assert and remove beliefs. Thus, in order to add or remove a belief or simply query the belief base, the programmer has to create the belief and then use the methods of the aforementioned interfaces. PRACTIONIST also provides two instruments to create beliefs: - the factory of predicates: it is represented by the AbsPredicateFactory class contained in the org.practionist.belief package which makes available static methods to create a predicate supplying a string (i.e. java.lang.String) as parameter; - the factory of operators: it is represented by the BeliefOperatorFactory class contained in the org.practionist.belief package which makes available static methods to create an operator (Bel or Ubif) supplying a string (i.e. java.lang.String)as parameter. /* Create a belief. */
        AbsPredicate belief = AbsPredicateFactory.create("ableToOrder(who: self)");
        /* Create a belief holding a variable (Var). */
        AbsPredicate on = AbsPredicateFactory.create("on(over: block4, under: Var)");
        /* Create a belief and assign the value of the clear_obj string to the “object” role. */
        //String clear_obj = ...;
        //AbsPredicate clear = AbsPredicateFactory.create("clear(object: %)", clear_obj);
        /* Create the belief <this agent believes that <pippo believes that ‘block2’ is clear>>. */
        Bel bel1 = BeliefOperatorFactory.createBel("pippo", "clear(object: block2)");
        /* Create the belief <this agent believes that <pluto believes that <pippo believes that ‘block2’ is clear>>>. */
        Bel bel2 = BeliefOperatorFactory.createBel("pluto", bel1);
        /* Create the belief <this agent believes that <pippo does not any belief about the fact that the table is clear>> */
        Ubif ubif = BeliefOperatorFactory.createUbif("pippo", "clear(object: table)");
        Bel bel3 = new Bel(ubif);
        BeliefBase bb = getBeliefBase();
        bb.add(on);
        bb.remove(clear);
        bb.bel(bel1);
        bb.bif(bel2);
        bb.whatAbout(bel3);
        Operator o = retrieveUbif(ubif);
      • JASON: An AgentSpeak(L) agent is created by the specification of a set of base beliefs and a set of plans. A belief atom is simply a first-order predicate in the usual notation, and belief atoms or their negations are termed belief literals. An initial set of beliefs is just a collection of ground belief atoms. This part of BNF grammar below gives the AgentSpeak syntax that is accepted by Jason for beliefs: The belief base can be customised, which can be quite important in large-scale applications. There are two customisations available with the Jason distribution: one which stores the beliefs in a text file (so as to persist the state of an agent’s belief base) and another which stores some of the beliefs in a relational data base. This latter customisation can be used the access any relational data base (via JDBC). The AgentSpeak code remains the same regardless of the belief base customisation. The belief base can have Prolog-like rules.

   3. goal

      Goals make up the agent's motivational stance and are the driving forces for its actions. Therefore goals represent the DESIRE in the BDI programming approach.
      • JADEX: Currently Jadex supports 4 different goal kinds and a meta-level goal kind. Here is the XML schema for Jadex goals: A perform goal specifies some activities to be done. Therefore the outcome of the goal depends only on the fact, if activities were performed. In contrast, an achieve goal can be seen as a goal in the classical sense by representing a target state that needs to be achieved. Similar to the behavior of the achieve goal is the query goal, which is used to enquire information about a specified issue. The maintain goal has the purpose to observe some desired world state and actively reestablishes this state when it gets violated. Meta-level goals can be used in the plan selection process for reasoning about events and suitable plans. In Jadex, goals are strongly typed in the sense that all goal types can be identified per name and all parameters of a goal have to be declared in the XML. The declaration of parameters resembles very much the specification of beliefs. Therefore it is distinguished between single-valued parameters and multi-valued parameter sets. As with beliefs, arbitrary expressions can be supplied for the parameter values. The system distingiushes in, out, and inout, parameters, specified using the direction attribute. The following example shows the use of most of the features described above: <achievegoal name="eat_food">
         <parameter name="food" class="ISpaceObject">
           <value>$food</value>
         </parameter>
         <unique/>
         <creationcondition language="jcl">
            $beliefbase.eating_allowed
         </creationcondition>
         <dropcondition language="jcl">
            !Arrays.asList($beliefbase.seen_food).contains($goal.food)
         </dropcondition>
         <deliberation>
           <inhibits ref="wander_around"/>
         </deliberation>
        </achievegoal> The goal is named "eat_food" and has one parameter $food, which is assigned from binding options taken from the food belief set. It is created whenever there is food (in the $food parameter) and the creature is allowed to eat (see creation condition). The goal is meaning that the creature will not pursue two goals to eat the same food at the same time. Moreover, the settings specify that the eat_food goal is more important than the wander_around goal. Source: http://www.activecomponents.org/bin/view/BDI+User+Guide/07+Goals
      • 2APL: The goals of a 2APL agent are implemented by its goal base, which is a list of formulas each of which denotes a situation the agent wants to realize (not necessary all at once). The implementation of the initial goal base starts with the keyword ‘Goals:’ followed by a list of goal expressions. Each goal expression is a conjunction of ground atoms. Example of the initial goal base of a 2APL agent: Goals:
            hasGold(5) and clean(blockworld) , hasGold(10) The beliefs and goals of an agent are governed by a rationality principle. According to this principle, if an agent believes a certain fact, then the agent does not pursue that fact as a goal. This means that if an agent modifies its belief base, then its goal base may be modified as well. An agent’s beliefs and goals change during the agent’s execution. BASIC ACTIONS Basic actions specify capabilities of agents, i.e., actions that an agent can perform to achieve its desirable situation. Basic actions constitute an agent’s plan. Six types of basic actions are distinguished in 2APL: actions to update the belief base, actions to test the belief and goal bases, actions to manage the dynamics of goals, abstract actions, communication actions and external actions to be performed in an agent’s environment. - Belief update action: A belief update action updates the belief base of an agent when executed. This action type can be used to store information received from other agents (through messages) or environments (through sense actions and events), or to store temporarily data or the results of some computations. A belief update action is an expression of the form (i.e., a first-order atom in which the predicate starts with a capital letter). Such an action is specified in terms of pre- and post-conditions. An agent can execute a belief update action if the pre-condition of the action is entailed by its belief base. The execution of a belief update action modifies the belief base in such a way that the post-condition of the action is entailed by the belief base after the execution of the action.The post-condition of a belief update action is a list of literals. The update of the belief base by such an action removes the atom of the negative literals from the belief base and adds the positive literals to the belief base. The specification of the belief update actions starts with the keyword ‘BeliefUpdates:’, example: BeliefUpdates:
           {not carry(gold)} PickUp() {carry(gold)}
           {trash(X, Y) and pos(X, Y)} RemoveTrash() {not trash(X, Y)}
           {pos(X, Y)} ChgPos(X1, Y1) {not pos(X, Y), pos(X1, Y1)}
           {hasGold(X)} StoreGold() {not hasGold(X), hasGold(X+1), not carry(gold)}
        1. Test action: A test action performed by an agent checks whether the agent has certain beliefs and goals. A test action is an expression consisting of belief and goal query expressions. A belief query expression has the form B(f), where f consists of literals composed by conjunction or disjunction operators. A goal query expression has the form G(f), where f consists of atoms composed by conjunction or disjunction operators. A belief query expression is basically a (Prolog) query to the belief base and generates a substitution for the variables that are used in the belief query expression. A goal query expression is a query to an individual goal in the goal base, i.e., it is to check if there is a goal in the goal base that satisfies the query.
        2. Goals dynamic action: The adopt goal and drop goal actions are used to adopt and drop a goal to and from an agent’s goal base, respectively. The adopt goal action can have two different forms: adopta(f) and adoptz(f). These two actions can be used to add the goal f (a conjunction of atoms) to the beginning and to the end of an agent’s goal base, respectively. Finally, the drop goal action can have three different forms: dropgoal(f), dropsubgoals(f), and dropsupergoals(f). These actions can be used to drop from an agent’s goal base, respectively, the goal f, all goals that are a logical subgoal of f, and all goals that have f as a logical subgoal.
        3. Abstract action: The general idea of an abstract action is similar to a procedure call in imperative programming languages. The procedures should be defined in 2APL by means of the so-called PC-rules, which stands for procedure call rules, a PC-rule can be used to associate a plan to an abstract action. The execution of an abstract action in a plan removes the abstract action from the plan and replaces it with an instantiation of the plan that is associated to the abstract action by a PC-rule. An abstract action can be used to pass parameters from one plan to another one. In particular, the execution of an abstract action passes parameters from the plan in which it occurs to another plan that is associated to it by a PC-rule.
        4. Communication action: A communication action passes a message to another agent. A communication action sendaction can have either three or five parameters. In the first case, the communication action is the expression send(Receiver, Performative, Language, Ontology, Content) where Receiver is the name of the receiving agent, Performative is a speech act name (e.g., inform, request, etc.), Language is the name of the language used to express the content of the message, ontology is the name of the ontology used to give a meaning to the symbols in the content expression, and Content is an expression representing the content of the message. It is often the case that agents assume a certain language and ontology such that it is not necessary to pass them as parameters of their communication actions. The second version of the communication action is therefore the expression send(Receiver, Performative, Content). It should be noted that 2APL interpreter is built on the FIPA compliant JADE platform.
        5. External action: An external action is supposed to change the state of an external environment. The effects of external actions are assumed to be determined by the environment and might not be known to the agents beforehand. An agent thus decides to perform an external action and the external environment determines the effect of the action. The agent can know the effects of an external action by performing a sense action (also defined as an external action), by means of events generated by the environment, or by means of a return parameter. It is up to the programmer to determine how the effects of actions should be perceived by the agent.
      • 3APL: A 3APL-agent has basic and composite goals (plans). There are three different types of basic goals: basic action, test goal and the achievement goal. A basic goal can be a basic action that can be executed by the agent, a basic action do not allow the agent to introspect its beliefs. The test goal allows the agent to evaluate its beliefs (a test goal checks whether a belief formula is true or false). The third type is an achievement goal, which can be used as a label for a procedure call. The procedure itself is defined by a practical reasoning rule. Initial goals are defined in the goal base. Example: GOALBASE {
                cleanRoom(r1).
                cleanRoom(r5).
        } A basic action is the most primitive action a agent is capable of performing. There are three types of basic actions:
        1. Mental Action: these actions are actions which affect the mental state of the agent and are defined as updates on the beliefs of the agent. The effect of the execution of a mental action is a change in the agent's belief base. The conditions under which a mental action can be successfully executed are called the pre-condition of the mental action, and its effects on the belief base are called the post-condition of the mental action. Example: {on(X,Y)} Move(X,Y,Z) {not(on(X,Y)) , on(X,Z)}
        2. Communication Action: this type of action can be used to pass a message to another agent. A message contains the name of the receiver of the message, the speech act or performative (e.g. inform, request, etc.) of the message, and the content. If an agent sends a message Send(Receiver, Performative, Content) to another agent, the belief base of the sender is updated with the formula sent(Receiver, Performative, Content) and the belief base of the receiver is updated with the formula received(Sender, Performative, Content). Example: Send(seller,query,computer(3000))
        3. External Action: are means to change the external environment in which the agents operate. The effects of external actions are assumed to be determined by the environment and might not be known to the agents. The agent thus decides to perform an external action and the external environment determines the effect of this action. The agent can come to know the effects of an external action by performing a sense action. External actions are performed by 3APL agents with respect to an environment which is assumed to be implemented as a Java class. The external actions that can be performed by 3APL agents have the form Java(Classname, Method, List) where Classname is the name of the Java class that implements the environment, Method is the action to be performed in the environment, and List is a list of returned values. Example: Java(World,Clean(),L)
      • PRACTIONIST: The PRACTIONIST framework supports the explicit representation and implementation of goals with their properties and relations. This provides the ability to reason about them, in terms of believing if goals are impossible, achieved, incompatible with other goals. This in turn supports the commitment strategies of agents and their capability to autonomously drop, reconsider, replace or pursue goals. Formally, a goal g is defined as follows: where s_g is the success condition, p_g is the possibility condition stating whether g can be achieved or not, and ?_g is the cancel condition stating in which situations the agent should give up to pursue the goal g. The goal model is used by PRACTIONIST agents when reasoning about goals during their deliberation process. For them, desires and intentions are mental attitudes towards goals, which are in turn considered as descriptions of objectives. Thus, ”pursuing the goal g” is only a desire if the agent is not yet committed to it, due to some reason. On the other hand, ”pursuing the goal g” becomes an intention when the agent is committed to it and works to achieve it. In PRACTIONIST the following two families of goals were defined: state goals, which refer to some states of affairs the agent desires/intends to bring about, or cease, or preserve, or avoid; perform goals, which are not related to some world states but to some activities the agent desires/intends to perform. In addition, PRACTIONIST allows to customize goals by creating a new class implementing the Goal interface. PRACTIONIST framework also supports the explicit representation of relations among goals. This provides the ability to reason about them, in terms of believing if goals are impossible, achieved, incompatible with other goals, and so forth. Such relations among goals are as follows: - a goal G1 is inconsistent with a goal G2 if and only if when G1 succeeds, then G2 fails; (it is worth to noting that when two goals are inconsistent with each other, we can also specify that one is preferred to the other.) - a goal G1 entails a goal G2 (or equivalently G2 is entailed by G1) if and only if when G1 succeeds, then also G2 succeeds; - a goal G1 is a precondition of a goal G2 if and only if G1 must succeed in order to be possible to pursue G2; - a goal G1 depends on a goal G2 if G2 is precondition of G1 and G2 must be successful while pursuing G1. Example of registration of goals and their dependencies: protected void initialize()
        {
            registerGoal(new ScorePoints(), "This goal is to score agent points");
            registerGoal(new FindTile(), "This goal is to find a tile");
            registerRelation(new EntScorePointsFillHole(), "");
            registerRelation(new PreconditionFillHoleFindHole(), "");
           //....
        }
      • JASON: AgentSpeak(L) distinguishes two types of goals: achievement goals and test goals. Achievement and test goals are predicates (as for beliefs) prefixed with operators ‘!’ and ‘?’ respectively. Achievement goals state that the agent wants to achieve a state of the world where the associated predicate is true. (In practice, these initiate the execution of subplans.) A test goal returns a unification for the associated predicate with one of the agent’s beliefs; they fail otherwise. A triggering event defines which events may initiate the execution of a plan. An event can be internal, when a subgoal needs to be achieved, or external, when generated from belief updates as a result of perceiving the environment. There are two types of triggering events: those related to the addition (‘+’) and deletion (‘-’) of mental attitudes (beliefs or goals). More information on goal's sintax used in Jason is available below in the section regarding plans.

   4. plan / decisions

      Plans represent the agent's means to act in its environment. Therefore plans represent the INTENTION in the BDI programming approach. The plans predefined by the developer compose the library of (more or less complex) actions the agent can perform. Depending on the current situation, plans are selected in response to occuring events or goals. The selection of plans is done automatically by the system and represents one main aspect of a BDI infrastructure.
      • JADEX: In Jadex, plans consist of two parts: A plan head and a corresponding plan body. The plan head is declared the the ADF whereas the plan body is realized in a concrete Java class. Therfore the plan head defines the circumstances under which the plan body is instantiated and executed. For each plan head several attributes and contained elements can be defined. For each plan a name has to be provided. The priority of a plan describes its preference in comparison to other plans. Therefore it is used to determine which candidate plan will be chosen for a certain event occurence, favouring higher priority plans (random selection, if activated, applies only to plans of equal priority). Per default all applicable plans have a default priority of 0 and are selected in order of appearance (or randomly when the corresponding BDI flag is set). For each plan the corresponding plan body has to be declared using the element. The "impl" attribute is used for defining the implementation of the plan. In case of standard Java plans the classname is used to identify the implementation. The type attribute determines which kind of plan body is used. To indicate in what cases a plan is applicable and a new plan instance shall be created the tag can be used. Its subtags specify the goals, internal- or message events for which the plan is applicable. A plan body represents a part of the agent's functionality and encapsulates a recipe of actions. In Jadex, plan bodies are written in pure Java (or alternatively in bpmn) and therfore it is easily possible to write plans that access any available Java libraries, and to develop plans in your favourite Java Integrated Development Environment (IDE). The connection between a plan body and a plan head is established in the plan head, thus plan bodies can be reused within different plan declarations. For developing reusable plans, plan parameters in combination with parameter mappings from some triggering event or goal to/from the plan should be used. Plans that are ready to run are executed by the main interpreter. The system takes care that only one plan step is running at a time. The length of a plan step depends on the plan itself. The body() method of standard plans is called only once for the first step, and runs until the plan explicitly ends its step by calling one of the waitFor() methods, or the execution of the plan triggers a condition (e.g., by changing belief values). For subsequent steps the body() method is continued, where the plan was interrupted. Standard plans might be interrupted whenever the agent regards it as necessary, e.g., when a belief has been changed leading to the adoption of a new goal. Sometimes it is desireable that a sequence of actions is considered as a single atomic action. For example when you change multiple beliefs at once, which might trigger some conditions, you may want to perform all changes before the conditions are evaluated. In standard plans, this can be achieved by using a pair of startAtomic() / endAtomic() calls around the code you want to execute as a whole. EVENTS An important property of agents is the ability to react timely to different kinds of events. Jadex supports two kinds of application-level events, which can be defined by the developer in the ADF. Internal events can be used to denote an occurrence inside an agent, while message events represent a communication between two or more agents. Events are usually handled by plans. When an event occurs in Jadex and no plan is found to handle this event a warning message is generated, which can be printed to the console depending on the logging settings. Internal events are the typical way in Jadex for explicit one-way communication of an interesting occurrence inside the agent. The usage of internal events is characterized by the fact that an information should be passed from a source to some consumers (similar to the object oriented observer pattern). Hence, if an internal event occurs within the system, e.g., because some plan dispatches one, it is distributed to all plans that have declared their interest in this kind of event by using a corresponding trigger or by waiting for this kind of internal event. The internal event can transport arbitrary information to the consumers if custom parameter(set)s are defined in the type for that purpose. A typical use case for resorting to internal events is, e.g., updating a GUI. The following example shows the declaration of an internal event: <events>
         <internalevent name="gui_update">
           <parameter name="content" class="String"/>
         </internalevent>
        </events> All message types an agent wants to send or receive need to be specified within the ADF. The message event (class jadex.bdi.runtime.IMessageEvent denotes the arrival or sending of a message. Note, that only incoming messages are handled by the event dispatching mechanism, while outgoing messages are just sent. The native underlying message object (which is platform dependent) can be retrieved using the getMessage() method. In addition, the message type, which may be FIPA or some other message format, can be retrieved using the getMessageType() method. The message type (subclass of jadex.bridge.MessageType) is meant to represent the way a message is composed, i.e. it defines which parameter and parametersets exists and (partially) what their meaning is. Hence, the message type can e.g. be used to determine which parameter(set) contains the receivers of the message. The message type is comparable to metainformation of a specific kind of message such as FIPA. It represents an extension point is Jadex and allows for introducing new message types without having to modify underlying message passing infrastructure. An agent developer normally can ignore the message type and use the default FIPA for all messages. The following example shows the declaration of an internal event: <imports>
         <import>jadex.base.fipa.SFipa</import>
        </imports>
        ...
        <events>
         <!-- A query-ref message with content "ping" -->
         <messageevent name="query_ping" type="fipa" direction="receive">
           <parameter name="performative" class="String" direction="fixed">
             <value>SFipa.QUERY_REF</value>
           </parameter>
           <parameter name="content" class="String" direction="fixed">
             <value>"ping"</value>
           </parameter>
         </messageevent>
           
         <!-- An inform message where content contains the word "hello" -->
         <messageevent name="inform_hello" type="fipa" direction="receive">
           <parameter name="performative" class="String" direction="fixed">
             <value>SFipa.INFORM</value>
           </parameter>
           <match>((String)$content).indexOf("hello")!=-1</match>
         </messageevent>
        </events> Source: http://www.activecomponents.org/bin/view/BDI+User+Guide/08+Plans
      • 2APL: 2APL also provides a programming construct to implement so-called atomic plans. Because an agent can have a set of concurrent plans, an arbitrary interleaving of plans may be problematic in some cases. In order to reach its goals, a 2APL agent adopts plans. A plan consists of basic actions composed by sequence operator, conditional choice operator, conditional iteration operator, and a non-interleaving operator (atomic plans) because an agent can have a set of concurrent plans and an arbitrary interleaving of plans may be problematic in some cases. The sequence operator ‘;’ indicates that the first plan should be performed before the second plan. The conditional choice operator generates if plan plans of the form if f then p1 else p1, where p1 and p2 are arbitrary plans. The condition part of this expression (i.e., f) is a test that should be evaluated with respect to an agent’s belief and goal bases. The conditional iteration operator generates plans of the form while f do p, where p is an arbitrary plan. The condition f is also a test that should be evaluated with respect to an agent’s belief and goal bases. The iteration expression is then interpreted as to perform the plan p as long as the test f succeeds. The (unary) non-interleaving operator generates atomic plans, which are expressions of the form [p], where p is an arbitrary plan. This plan is interpreted as an atomic plan p, which should be executed at once ensuring that the execution of p is not interleaved with actions of other plans. Note that an agent can have different plans at the same time and that plans cannot be composed by an explicit parallel operator. As there is no explicit parallel composition operator, the nested application of the unary operator has no effect, i.e., the executions of plans [p1; p2] and [p1;[p2]] generate identical behaviors. The plans of a 2APL agent are implemented by its plan base. The implementation of the initial plan base starts with the keyword ‘Plans:’ followed by a list of plans. Example: Plans:
            [@blockworld(enter(5,5,red),L);ChgPos(5,5)],
           send(admin,request,register(me)) PRACTICAL REASONING The 2APL programming language provides constructs to implement practical reasoning rules that can be used to implement the generation of plans during an agent’s execution. In particular, three types of practical reasoning rule are proposed: planning goal rules, procedure call rules, and plan repair rules: - Planning Goals Rules (PG-rules):A planning goal rule can be used to implement an agent that generates a plan when it has certain goals and beliefs. The specification of a planning goal rule consists of three entries: the head of the rule, the condition of the rule, and the body of the rule. The head and the condition of a planning goal rule are goal and belief query expressions used to check if the agent has a certain goal and belief, respectively. A planning goal rule is of the form: [ goalquery ] "<-" belquery "|" plan. Note that the head of the rule is optional which means that the agent can generate a plan only based on its belief condition. The body of the rule is a plan in which variables may occur. These variables may be bound by the goal and belief expressions. The application of a planning goal rule generates a substitution for variables that occur in the head and condition of the rule because they are queried from the goal and belief bases. The resulted substitution will be applied to the generated plan to instantiate it. An example of PG-rule is: PG-rules:
           clean(R) <- pos(X1,Y1) and trash(X2,Y2) | {[goTo(X1,Y1,X2,Y2);RemoveTrash()]} - Procedure Call Rules (PC-rules): Besides their use as procedure definition (used for executing abstract actions), they can also be used to respond to messages and to handle external events. In fact, a procedure call rule can be used to generate plans as a response to (1) the reception of messages sent by other agents, (2) the reception of events generated by the external environments, and (3) the execution of abstract actions. A procedure call rule is of the form: atom "<-" belquery "|" plan. Like planning goal rules, the specification of procedure call rules consist of three entries. The only difference is that the head of the procedure call rules is an atom, rather than a goal query expressio. The head of a PC-rule can be a message, an event, or an abstract action. Note that like planning goal rules, a procedure call rule has a belief condition indicating when a message (or event or abstract action) should generate a plan. Thus, a procedure call rule can be applied if the agent has received a message, an event, or if it executes an abstract action, and moreover, the belief condition of the rule is entailed by the agent’s belief base. Examples of PC-rules are: PC-rules:
           message(A,inform,La,On,goldAt(X2,Y2)) <- not carry(gold) |
                { getAndStoreGold(X2,Y2) }
           event(gold(X2,Y2),blockworld) <- not carry(gold) |
                { getAndStoreGold(X2,Y2) }
           getAndStoreGold(X,Y) <- pos(X1,Y1) |
                { [goTo(X1,Y1,X,Y);@blockworld(pickup(),_);PickUp();
                 goTo(X,Y,3,3);@blockworld(drop(),_);StoreGold()]
                } - Plan Repair Rules (PR-rules): A plan repair rule consists of three entries: two abstract plan expressions and one belief query expression.We have used the term abstract plan expression since such plan expressions include variables that can be instantiated with plans. A plan repair rule indicates that if the execution of an agent’s plan (i.e., any plan that can be unified with the abstract plan expression in the head of a plan repair rule) fails and the agent has a certain belief, then the failed plan could be replaced by another plan (i.e., by an instantiation of the abstract plan in the body of the plan repair rule). A plan repair rule of an agent can thus be applied if (1) the execution of one of its plan fails, (2) the failed plan can be unified with the abstract plan expression in the head of the rule, and (3) the belief condition of the rule is entailed by the agent’s belief base. Example: PR-rules:
           @blockworld(east(),_);@blockworld(east(),_);X <- true |
               { @blockworld(north(),_);@blockworld(east(),_);
                @blockworld(east(),_);@blockworld(south(),_);X } DELIBERATION CYCLE In order to execute an individual agent, the 2APL interpreter follows a certain order of deliberation steps repeatedly and indefinitely. Each deliberation step is specified by a set of transition rules indicating which transitions an individual agent can make at each moment in time. This repeated and indefinite sequence of the deliberation steps can be generated by the agent’s deliberation cycle. Each cycle starts by applying all applicable PG-rules, each rule only one time. Note that a PG-rule can be applied more than one time since it can be applied to generate plans for two different goals. For example, for an agent with two goals g(a) and g(b) and g’(c), the PG-rule g(X)<-b(Y)|p(X, Y) can be applied to both g(a) as well as g(b) and g’(c). However, according to the 2APL deliberation cycle the PG-rule will be applied to the first goal g(a) in one cycle and to the goal g(b) and g’(c) in the next cycle. The deliberation cycle proceeds by executing only the first actions of all plans. This is in order to make the deliberation process fair with respect to the execution of all plans, i.e., in order to allow all plans to get a chance to be executed. The next deliberation steps are to process all events received from the external environment, all internal events indicating the failure of plans, and all messages received from other agents, respectively. An event from external environment is processed by applying the first applicable PC-rule (with the head event) to it. An internal event, which identifies a failed plan, is processed by applying the first applicable PR-rule to the failed plan. A received message is then processed by applying the first applicable PC-rule (with the head message) to it. Note that the application of rules to process events generates and add plans to the corresponding agent’s plan base. After these deliberation steps, it is checked if it makes sense to do a new cycle of deliberation steps. In fact, if in a deliberation cycle no rule could be applied, no plan could be executed, and no event could be processed, then it makes no sense to try again a new cycle of deliberation steps, except when a new event or message has arrived. Of course, the order of the deliberation steps in a cycle can be defined in different ways. For example, at each deliberation cycle one may apply only one applicable PG-rule (instead of applying all applicable rules), execute one plan (instead of the first action of all plans), and process one event. It is also possible to process events before applying PG-rules or execute plans after processing events.
      • 3APL: The concept of plan is implemented from composed goals built from basic goals. Basic goals can be put in a sequence with the operator ‘;’. In the original specification of 3APL the operators + and || for non-deterministic choice and parallel composition were introduced. These operators are not included in the operational version of the language. The absence of these operators implies that 3APL goals are deterministic and can not take place simultaneously. However, two new programming constructs are defined in the language, IF-THEN-ELSE and WHILE-DO. The following is an example of the initial plan base of a 3APL agent: PlanBase:
        while (on(X,fl) and not(on(V,X)) do {
         (on(Y,Z) and not(Z==fl))?;
         Move(X,fl,Y)
        } This plan base consists of one plan which will find all free blocks (blocks with no block on top) that are placed on the floor and move them to an existing block which itself is not placed on the floor. PRACTICAL REASONING RULES [14] To achive its goals and to monitor its plans, a 3APL agent uses practical resoning rules (or means-end reasoning). Whereas goals operate on the beliefs of an agent, rules operate on the goals. Practical reasoning rules can be used to build a plan library from which an agent can retrieve plans for achieving a goal. They also provide the means to revise and monitor goals and supply the agents with reasoning capabilities to reflect on their goals. [17] These rules are based on a belief that a plan is sufficient to achieve a goal. Can be divided in Reactive, Plan, Failure (replan), Optimization. Each rule consists in a: - Head which is a goal/plan (g) - Body which is a plan (p) - Guard wich is a belief (b) this means that when an agent has a goal g and find it self in situation b, it may consider replacing goal b with plan p. Practical reasoning rules are grouped in: - Planning goal rules: can be of the reactive or plan class. Its purpose is to generate a plan that satisfies a specified goal, if no goal is specified it’s a reactive rule that would occur every time the guard (the belief) condition is satisfied. Example: on(X,Z) <- on(X,Y) | move(X,Y,Z) - Plan-revision rules: can be of the failure or optimization class. The plan revision rules are used to revise plans from the plan base. Example: Move(X,Y,Z) <- not(clear(X)) | on(U,X)?;Move(U,X,fl);Move(X,Y,Z)  This plan revision rule informally means that if the agent plans to move block X from block Y onto block Z, but it cannot move X because (it believes that) there is a block on X, then the agent should revise its plan by finding out which block (U) is on X, moving U onto the floor, and finally moving X from Y onto Z. DELIBERATION PROCESS To execute a 3APL program a deliberation process is needed. This process is composed of deliberation operations and executed by a meta-level program, called interpreter. The interpreter uses a fixed procedure for selecting and executing reasoning rules, goals and capabilities and decides which changes are made to the belief and goal base. These are the only structures that can change during the execution of a 3APL-program, the rule base and the actions are static. A deliberation process is composed of a set of operation: - Select a Planning Goal Rule - Select a Plan-Revision Rule - Select a Plan - Execute a Plan The execution order of these operations can be setted by the system designer, of course different orders can give to agents different behaviours. The most used deliberation process in literature is represented int the figure:
      • PRACTIONIST: In the PRACTIONIST framework plans represent an important container where it is possible to define the actual behaviours of agents. Each agent may own a declared set of plans (the plan library), which specify the activities the agent should undertake in order to achieve its intentions, or handle incoming perceptions, or react to changes of its beliefs. Several information about plans can be specified in order to provide the agents with the capability to dynamically behave when selecting and executing plans. Thus, a plan represents a possible recipe to manage the trigger event, which in turn may be related to a goal, an external event, or an event which notifies a change of the belief set. How to actually handle a certain event is reported within the body, which is an activity that can contain a set of acts, such as desiring to pursue some goal, adding or removing beliefs, sending ACL messages, doing an action and so forth. After modelling plans it is necessary to register them in the plan library, in order to make them available of the agent; the registration of a plan may be done during the phase of initialization of the agent or during the execution of a plan. The class diagram shows the hierarchy of plans defined in PRACTIONIST: - Plan is the abstract class at the base of the hierarchy of plans defined in the framework and can be used to define any type of behaviour. - GoalPlan can be used to define the behaviour of the agent when it needs to pursue a goal. - PerceptionPlan can be used to define the behaviour of the agent when it needs to react to a perception. - MessageReceivingPlan can be used to define the behaviour of the agent to handle an incoming message. - ObjectReceivingPlan can be used to define the behaviour of the agent to manage an object as input. - BeliefUpdatePlan can be used to define the behaviour of the agent when the value of truth on one of its beliefs change and assumes a specific value. To create a new plan, the programmer has to extend the abstract class Plan and customize it, by implementing its methods, in addition to the body (to define its actual behaviour). But such plan will be never practical: the only way to make it practical is to define this condition in the plan description. To be more precise, an instance of the PlanDescription class may be created to declare the elements of a plan, by passing the plan type in the constructor (it is necessary to use one of the three constants defined in the Plan class): the methods not redefined will be retrieved in the plan description. protected void initialize()
        {
            ACLMessage msg = new ACLMessage(ACLMessage.REQUEST);
            msg.setOntology(BlockWorldVocabulary.ONTOLOGY_NAME);
            PlanDescription pd = new PlanDescription(Plan.PERCEPTION_PLAN_TYPE);
            pd.setPerception(new ACLMessagePerception(msg));
            pd.addSuccessBeliefAdd(AbsPredicateFactory.create("happy(who: self)"));
            pd.addSuccessBeliefAdd(AbsPredicateFactory.create("ordered(what: blocks)"));
            pd.addFailureBeliefAdd(AbsPredicateFactory.create("ableToOrder(who: self)"));
            pd.setInvariantCondition(AbsPredicateFactory.create("ableToOrder(who: self)"));
            addPlan(TopLevelPlan.class, pd, null, "TopLevelPlan");
           //…
        } ACTS As already specified, a plan represents a recipe to manage the Trigger Event, the real management of the event is charged to the body, which is an activity that can contain a set of acts, such as: - Querying and updating belief base: this act is used to assert and remove beliefs or query the agent’s Belief Base. - Sending and receiving messages: this act is used to provide the agent with the capability to send and receive messages. - Waiting for perceptions: this act is used to block the plan execution until the reception of a certain perception. - Desiring to pursue a goal: this act is used to desire to meet a goal - Doing actions: this act is used to execute an action.
      • JASON: Plans refer to the basic actions that an agent is able to perform on its environment. Such actions are also defined as first-order predicates, but with special predicate symbols (called action symbols) used to distinguish them from other predicates. A plan is formed by a triggering event (denoting the purpose for that plan), followed by a conjunction of belief literals representing a context. The context must be a logical consequence of that agent’s current beliefs for the plan to be applicable. The remainder of the plan is a sequence of basic actions or (sub)goals that the agent has to achieve (or test) when the plan, if applicable, is chosen for execution. These are two some examples of AgentSpeak(L) plans: They tell us that, when a concert is announced for artist A at venue V (so that, from perception of the environment, a belief concert(A,V) is added), then if this agent in fact likes artist A, then it will have the new goal of booking tickets for that concert. The second plan tells us that whenever this agent adopts the goal of booking tickets for A’s performance at V, if it is the case that the telephone is not busy, then it can execute a plan consisting of performing the basic action call(V) (assuming that making a phone call is an atomic action that the agent can perform) followed by a certain protocol for booking tickets (indicated by ‘. . .’), which in this case ends with the execution of a plan for choosing the seats for such performance at that particular venue. Follows the AgentSpeak(L) BNF syntax concerning plans: A plan in AgentSpeak(L) is given by p above, where te is the triggering event, ct is the plan’s context, and h is sequence of actions, goals, or belief updates; te : ct is referred as the head of the plan, and h is its body. Then the set of plans of an agent is given by ps as a list of plans. Each plan has in its head a formula ct that specifies the conditions under which the plan can be executed. The formula ct must be a logical consequence of the agent’s beliefs if the plan is to be considered applicable. A triggering event te can then be the addition or the deletion of a belief from an agent’s belief base (+at and -at, respectively), or the addition or the deletion of a goal (+g and -g, respectively). A sequence h of actions, goals, and belief updates defines the body of a plan. We assume the agent has at its disposal a set of actions and we use a as a metavariable ranging over them. They are given as normal predicates except that an action symbol A is used instead of a predicate symbol. Events for handling plan failure are already available in Jason, although they are not formalised in the semantics yet. If an action fails or there is no applicable plan for a subgoal in the plan being executed to handle an internal event with a goal addition +!g, then the whole failed plan is removed from the top of the intention and an internal event for -!g associated with that same intention is generated. If the programmer provided a plan that has a triggering event matching -!g and is applicable, such plan will be pushed on top of the intention, so the programmer can specify in the body of such plan how that particular failure is to be handled. If no such plan is available, the whole intention is discarded and a warning is printed out to the console. Effectively, this provides a means for programmers to “clean up” after a failed plan and before “backtracking” (that is, to make up for actions that had already been executed but left things in an inappropriate state for next attempts to achieve the goal). Events, which may start off the execution of plans that have relevant triggering events, can be external, when originating from perception of the agent’s environment (i.e., addition and deletion of beliefs based on perception are external events); or internal, when generated from the agent’s own execution of a plan (i.e., a subgoal in a plan generates an event of type “addition of achievement goal”).

1. Behaviour features

   1. reactivity

      	stimulus -> response rules
      Jadex	To monitor conditions, an agent observes the beliefs and automatically reacts to changes of these beliefs, as necessary. Jadex is aware of manipulation operations that are executed directly on beliefs, e.g., by setting the fact of a belief, and of changes due to belief dependencies (i.e., a dynamically evaluated fact expression referencing another belief). When an event occurs, and triggers an execution step of a plan, it may take a while, before the plan step is actually executed, due to many plans being executed concurrently inside an agent. Therefore, it is sometimes possible, that a subsequent event, which might be relevant for a plan, is not dispatched to that plan, because it still has to execute previous plan step, and does not yet wait for the event. To avoid this, each plan has a waitqueue to collect such events. The waitqueue for a plan is set up using the tag or the getWaitqueue() method in plan bodies. The waitqueue of a plan is always matched against events, although the plan may not currently wait for that specific event. The tag provides support for waiting for finished goals and the occurrence of message and internal events. Events that match against the waitqueue of a plan are added to he plans internal waitqueue. They will be dispatched to the plan later, when it calls waitFor() or getWaitqueue().getElements().
      2APL	To implements reactive behaviours, 2APL has introduced Events and Exceptions. Exceptions are strictly realated to the environment and are used to trigger Plan Repair Rules, while an event could be generated by environment and messages from other agents and are used to trigger Procedure Call Rules. Exceptions and events are processed during the deliberation cycle but don’t have any priority respect to plan execution, so the reactions may not be immediate. Note that 2APL does not provide programming constructs to implement the generation and throwing of exceptions. In fact, exceptions are semantical entities that cannot be used by 2APL programmers.
      3APL	The concepts of Events and Exceptions are not modeled in 3APL. To acquire informations an agent has to explicity perform a sense action on the environment and then using these informations inside the deliberation process to trigger a planning goal rule. Thus, reactive behaviours are only simulated and the reactivity of an agent is strictly dependent to the frequency of the deliberation cycle.
      PRACTIONIST	PRACTIONIST agent has a reactive behaviour based on the concept of event. Events can be of two different types, external events generated by perceptions, and internal events generated by beliefs update or goal commitments. Both type of events are collected in the Event Queue, at each cycle of execution an event is exctracted and a means-ends resoning is performed. By using a queue and without providing a way to define high-priority events it is possible to have delays on handling the urgent ones.
      JASON	-

   2. situatedness

      	relation with the environment
      Jadex	A Jadex agent is synchronized in the sense, that only one plan step at a time is executed (or none, if the agent is busy performing internal reasoning processes). Sometimes one may want to access agent internals from external threads. A good example is when your agent provides a graphical user interface (GUI) to accept user input. When the user clicks a button your Java AWT/Swing event handler method is called, which is executed on the Java AWT-Thread (there is one AWT Thread for each Java virtual machine instance). To force that such external threads are properly synchronized with the internal agent execution, every invocation on a BDI API component (the flyweights implementing e.g. IBelief, IGoal, etc.) is checked. If the agent calls these methods from its own thread the code is directly executed. Otherwise, if an external thread is the caller, the call is redirected to the agent thread and the external thread has to wait until the agent call returns. Please note that this call scheme can lead to deadlocks when agents try to invoke methods on other agents forming a cycle in the callgraph. To gain access to agents and call methods on them from an external thread the external access interface should be used. It can be fetched from the component management service (currently only for local agents) via the getExternalAccess(IComponentIdentifier cid, IResultListener listener) method. An alternative from within a plan is to use the methodgetExternalAccess() provided by the jadex.bdi.runtime.AbstractPlan class. The external access object for BDI agents implements the IBDIExternalAccess and ICapability interfaces. Together, they provide access to all important features of a capability (beliefbase, goalbase, etc.) as well as plan methods for directly creating and dispatching goals, message and internal events. The following code presents an example where a belief is changed when the user presses a button. public void body() {  //...  JButton button = new JButton("Click Me");   button.addActionListener(new ActionListener()  {    public void actionPerformed(ActionEvent e)    {      // This code is executed on the AWT thread (not on the plan thread!)      IBeliefbase bb = getExternalAccess().getBeliefbase();       bb.getBelief("button_pressed").setFact(new Boolean(true));    }  });  //... }
      2APL	External environments are implemented as Java classes that implemets the environment interface.The environment interface contains two methods, addAgent (String name) to add an agent to the environment and removeAgent (String name) to remove an agent from the environment. An agent can act on an environment by external actions, the environment can pass information back to the plan in which the action was executed . Note that the execution of a plan is blocked until the method m is ready and the return value is accessible to the rest of the plan. Information between agents and environments can also be passed through events and exceptions. When implementing a 2APL environment, the programmer should decide when and which information from the environment should be passed to agents. This can be done in an environment by calling the method notifyEvent(AF event, String... agents) in the ExternalEventListener which was an argument of the environments constructor. Such a mechanism of generating events by the environment and receiving them by agents can be used to implement the agents’ perceptual mechanism.
      3APL	A 3APL agent can interact with the environment through external actions, but to know which effects the actions had, he has to perform a sense action. Viceversa, the environment has no ways to interact with the agent, in other words in 3APL the environment is a completely passive entity.
      PRACTIONIST	The PRACTIONIST framework provides each developed agent with necessary facilities for interfacing with the environment in which it lives: cognitive capacities on the environment and of execution of actions. The agents also own an explicit, though partial and often not completely determined representation of the environment in which they live. Each PRACTIONIST agent has a perceptual system that allows it to collect the stimuli coming from the environment where it lives. This system is composed of a set of perceptors, in charge of detecting the stimuli coming from the environment and turning them into perceptions, and set of effectors in charge of executing action, actions are components that allow an agent to interact with the environment where it live.
      JASON	-

   3. pro-activeness

      	generate and achieve its own objectives
      Jadex	At runtime an agent may have any number of top-level goals, as well as subgoals (i.e. belonging to some plan). Top-level goals may be created when the agent is born (contained in an initial state in the ADF) or will be later adopted at runtime, while subgoals can only be dispatched by a running plan. Regardless of how a goal was created, the agent will automatically try to select appropriate plans to achieve all of its goals. The properties of a goal, specified in the ADF, influence when and how the agent handles these goals. There are four ways to create and dispatch new goals: Goals can be contained in the configuration of an agent or capability, and are directly created and dispatched as top-level goals when an agent is born or terminated. In addition, goals are automatically created and dispatched as top-level goals, when the goal's creation condition triggers. Subgoals may be created inside plans only, while top-level goals may be created manually from plans, as well as from external interactions.
      2APL	In matter of proactivity 2APL exetends 3APL with plan repair rules and exceptions. Plan repair rules are really similiar to 3APL’s plan revision rules, but are executed only when a plan fails. This is possible thanks to the exceptions that allow an agent to know when a plan fail.
      3APL	Proactivity in 3APL is implemented in two ways, basically an agent has a proactive behaviour because he choose which actions to do as result of a deliberation process based on his belief and goals. Moreover an agent is able to change his plans through plan revision rules.
      PRACTIONIST	In addition to pursuing a goal by selecting and executing a predefined plan after a reasoning phase based on his beliefs, a PRACTIONIST agent is able to dinamically generate a own plan if none of the existent ones can handle informations coming from a new event.
      JASON	-

   4. social ability

      	MAS interaction (communication), coordination (cooperation, collaboration, competition)
      Jadex	Agent listeners can be used to get informed whenever agent state changes happen. Normally, listeners will be employed in agent external components such as a GUI for getting information about declared elements. A GUI e.g. could use a listener to update its view with respect to belief changes in the agent. Generally, for all important agent attitudes such as belief, plans and goals as well as the agent itself different listener types exist. Here is a list of available listeners: Listener Element Listener Methods IAgentListener ICapability agentTerminating() agentTerminated() IBeliefListener IBelief beliefChanged() IBeliefSetListener IBeliefSet factAdded() factRemoved() factChanged() IConditionListener ICondition conditionTriggered() IGoalListener IGoalbase IGoal goalAdded(), goalFinished() IInternalEventListener IEventbase internalEventOccurred() IMessageEventListener IMessageEvent IEventbase messageEventReceived() messageEventSent() IPlanListener IPlan IPlanbase planAdded() planFinished()
      2APL	It’s possible to create a multiagent system consisting of different number of different agents. A 2APL multi-agent program consists of a set of module speci?cations each with a unique name. A module is an encapsulation of beliefs, goals, plans and reasoning rules that together specify a functionality, a capability, a role, or a behaviour. Initially, a subset of these module speci?cations is identi?ed as specifying the initial state of individual agents. The execution of a multi-agent program is then the instantiation of this subset of module speci?cations followed by performing a deliberation process on each module instance. During the execution of a multi-agent program each agent can interact with the others through communication actions and also through external actions on the environment, these actions allow agents to communicate and to cooperate.
      3APL	In multi-agent systems, individual agents must be able to do two things: they must be able to find other agents that offer some service and they must be able to communicate with one another. To this end, the 3APL multi-agent platform supports a service directory and communication facilities. Both of these facilities are implemented as functionalities of AMS. As said, there is no concept of event in 3APL, so the communication among agents are treated as a new belief in their belief base.
      PRACTIONIST	Interaction between PRACTIONST agents is based on a mechanism of messages exchange. Through messages, agents can exchange informations (beliefs) and goals.
      JASON	-

2. Intelligent agents - autonomy with respect to:

   1. other agents

      In [AgentAutonomy] agent’s autonomy is expressed in terms of autonomy degree and divided in three main categories: - Command-driven : The agent does not make any decisions about how to pursue its goal and must obey orders given by some other agent(s). - True Consensus : The agent works as a team member, sharing decision-making control equally with all other agents decision-making agents. - Locally Autonomous / Master : The agent makes decisions alone and may or may not give orders to other agents. Each one of the languages explored allow, through different mechanisms, to define agents with any kind of autonomy listed above.

   2. environment

      In matter of autonomy with respect to the environment, all the agents appear equally and fully autonomous. In fact, independently on how the environment is defined or how the agent interacts with it, there is no way for the environment to change the agent’s decision-making algorithm. It doesn’t matter how much the environment will change, the agent is autonomously adapting to its environment to carry out its goal. In Jason it isn't possible to call an internal action from the environment. Most of the internal actions (IAs) are developed from an agent perspective, since they are conceived to be called by agents. Thus the execute method needs an agent's TransitionSystem (TS) to be executed (e.g. .my_name only makes sense when called by an agent).

   3. humans: programmer, designer, technician

      All the frameworks illustrated are built on top of JADE and allow the programmers (or generally speaking the users)to send messages to agents during their execution. This feature ensures a level of autonomy at least equivalent to the inter-agent one. Here follow some specific features of each framework that allow either monitoring or even modifying the agent's control flow.

      Jadex	When an ADF is loaded, a model is created for the agent containing (e.g., beliefs, goals, plans) defined in the ADF. These model elements are kept hidden from the agent programmer who has access to the runtime elements only. From within a plan, the programmer has access to the beliefbase (interface IBeliefbase) using the getBeliefbase() method. The beliefbase provides getBelief() / getBeliefSet() methods to get the current beliefs and belief sets by name, as well as methods to create new beliefs and belief sets or remove old ones.
      2APL	There are three tools that can be used in the 2APL platform to monitor the execution of individual agents: Auto-update Overview, State Tracer, and Log. The Overview tab consists of three panels called Beliefbase, Goalbase, and Planbase. When this tab is active, the beliefs, goals, and plans of the current state of the selected agent are presented in their panels. The State Tracer tab is a temporal version of the Overview tab and stores the beliefs, goals, and plans of all agents during execution. Because an execution generates a trace of agents’ states (beliefs, goals, and plans), the tools and its corresponding tab are called state tracer. This tool allows a user to execute a multi-agent program for a while, pause the execution, and browse through the execution of each agent.
      3APL	3APL platform allow the programmer to monitor an agent status by the Agent Properties tab that shows the current belief base, goal base, plan base, capabilities, goal planning rules, and plan revision rules of the agent. In addition, if the agent is running,a text box called Inference Log is filled with the reasoning steps. The reasoning step includes selection and applications of rules and election and execution of plans.
      PRACTIONIST	One of the most useful PRACTIONIST’s tools is PAIT (PRACTIONIST Agent Introspection Tool). This tool is a visual integrated monitoring and debugging tool, which supports the analysis of the agent’s state during its execution. In particular, the PAIT can be suitable to display, test and debug the agents’ mental attitudes (i.e. beliefs, desires, and intentions) and their execution flow, in terms of active behaviours. Each of these components can be observed at run-time through a set of specific tabs. Thus, PAIT allow the programmer to monitor the agents’ execution but not to conditionate it, once started the agent can only be stopped but no goals or plans can be added at runtime.
      JASON	If the programmer needs to control the agents' execution, he has to implement an ExecutionControl sub-class and specify it in the .mas2j file. Most likely he will have to override the following methods: public void receiveFinishedCycle(String agName, boolean breakpoint) {   super.receiveFinishedCycle(agName, breakpoint);   //... your code ... } protected void allAgsFinished() {   //... your code ... } These methods are called by Jason when one agent has finished its reasoning cycle and when all agents have finished the current "global execution step". To signal the agents to "carry on", his class can use the following code: fJasonControl.informAllAgsToPerformCycle(); The ExecutionControlGUI class is an example of how to do this, and the API documentation contains informations for further available methods inherited from ExecutionControl. More over, the Jason Mind Inspector can be used to inspect the mind state of each single agent.

3. Case study -  technologies to confront

   1. what we expected

   2. what we discovered

   3. are solutions similar or different?

4. BIBLIOGRAPHY

   1. JADEX BDI USER GUIDE (24/10/2013): http://www.activecomponents.org/bin/view/BDI+User+Guide/01+Introduction
   2. JADEX BDI Tutorial (09/12/2013): http://www.activecomponents.org/bin/view/BDI+Tutorial/01+Introduction
   3. JADEX BDI V3 Tutorial (24/10/2013): http://www.activecomponents.org/bin/view/BDI+V3+Tutorial/01+Introduction
   4. 3APL Jeroen van der Ham’s thesis (24/10/2013): http://www.cs.uu.nl/3apl/thesis/vanderham/thesis.pdf
   5. 3APL Jeroen van der Ham’s thesis presentation (24/10/2013): http://www.cs.uu.nl/3apl/thesis/vanderham/hamslides.pdf
   6. Jason manual(4/12/2013): http://jason.sourceforge.net/Jason.pdf
   7. V. Morreale, S. Bonura, G. Francaviglia, M. Cossentino, and S. Gaglio, “Practionist: a new framework for bdi agents” in Proceedings of the Third European Workshop on Multi-Agent Systems (EUMAS’05), 2005, p. 236.
   8. V. Morreale, S. Bonura, G. Francaviglia, F. Centineo, M. Puccio, and M. Cossentino “Developing intentional systems with the practionist framework” in Proceedings of the 5th IEEE International Conference on Industrial Informatics (INDIN07), July 2007.
   9. V. Morreale, S. Bonura, G. Francaviglia, F. Centineo, M. Cossentino, and S. Gaglio, “Reasoning about goals in BDI agents: the PRACTIONIST framework” in Proceedings of Joint Workshop “From Objects to Agents”, 2006.
   10. 2APL User guide (24/10/2013): http://downloads.sourceforge.net/project/apapl/User%20Guide/manual.pdf
   11. Mehdi Dastani, “2APL: a practical agent programming language”, International journal of Autonomous Agents and Multi-Agent Systems (JAAMAS), 16(3):214-248, Special Issue on Computational Logic-based Agents, (eds.) Francesca Toni and Jamal Bentahar, 2008.
   12. Mehdi Dastani. “Modular Rule-Based Programming in 2APL”, In A. Giurca, D. Gasevic, and K.Taveter (eds.), Handbook of Research on Emerging Rule-Based Languages and Technologies: Open Solutions and Approaches (2 Volumes), ISBN: 978-1-60566-402-6, 2009.
   13. K.V. Hindriks, F.S. de Boer, W. van der Hoek and J.-J.Ch. Meyer, “Agent programming in 3APL”. Autonomous Agents and Multi-Agent Systems, 2(4):357-401, 1999
   14. Hindriks, Koen V., “Agent Programming Languages: Programming with Mental Models”, Ph.d Thesis, Utrecht University, 2001
   15. M. Verbeek, “3APL as Programming Language for Cognitive Robots”, Master Thesis, Utrecht University, 2003
   16. M. Dastani, B. van Riemsdijk, F. Dignum, J.J. Meyer, “A Programming Language for Cognitive Agents: Goal Directed 3APL”. Proceedings of the First Workshop on Programming Multiagent Systems: Languages, frameworks, techniques, and tools (ProMAS03) to be held at AAMAS'03, 2003.
   17. J. Vazquez, “Agent Language Analysis: 3APL” http://www-lehre.inf.uos.de/~bauffart/presentation-final.pdf
   18. K. S. Barber and C. E. Martin “Agent Autonomy: Specification, Measurement, and Dynamic Adjustment”