+75 -83

docs/2apl-doc.tex

reviewed

··· 30 30 31 31 \tableofcontents 32 32 33 33 - \section{Introduction} %%%%%%% BORJA HERE 33 33 + \section{Introduction} 34 34 35 35 - The 2APL (pronounced double-a-p-l) Platform is a development tool that is designed to support the implementation and execution of multi-agent systems programmed in 2APL Language. 2APL has been designed and developed at the Intelligent Systems Group at the University of Utrecht. 2APL language is a BDI-based agent-oriented programming language that supports an integration of declarative programming constructs such as belief and goals and imperative style programming constructs such as events and plans. The 2APL platform 35 35 + 2APL has been designed and developed at the Intelligent Systems Group at the University of Utrecht. The \emph{2APL Platform} is a development tool that is designed to support the implementation and execution of multi-agent systems programmed in \emph{2APL Language}. 2APL language is a BDI-based agent-oriented programming language that supports an integration of declarative programming constructs such as belief and goals and imperative style programming constructs such as events and plans. The 2APL platform 36 36 provides a graphical interface through which a programmer can develop and execute 2APL multi-agent systems using several facilities. The platform allows communication among agents and can run on several machines connected in a network. 37 37 - In section~\ref{sec:lang} we will introduce the 2APL language describing its syntax, operational and formal semantics for specifying a multi-agent system and individual agents. Also, the deliberation cycle will be discussed. In section~\ref{sec:platform} we will discuss the 2APL Platform ... 38 37 38 38 + The rest of the report is organized as follows. Section~\ref{sec:lang} gives an introduction to the 2APL language describing its syntax along with both operational and formal semantics. Section~\ref{sec:platform} introduces the 2APL platform describing the tools available for development. Finally, Section~\ref{sec:concl} offers our concluding remarks and a short overview about future features. 39 39 40 40 - \section{2APL Language}\label{sec:lang} %%%%%%% BORJA HERE 41 40 42 42 - 2APL language is a BDI-based agent-oriented programming language that realizes an integration of declarative and imperative style programming. The declarative style programming supports the implementation of the mental state of agents allowing them to reason about their mental states and update them accordingly. The imperative style programming supports the implementation of processes allowing programming constructs to implement both the flow of control as well as mechanisms such as procedure call, recursion, plan revision, and interface to existing imperative programming languages. In this section, we will proceed illustrating the syntax of the language and both the operational and formal semantics. We will conclude the section discussing the execution of a multi-agent system and the 2APL deliberation process. 41 41 + \section{2APL Language}\label{sec:lang} 42 42 + 43 43 + 2APL language is a BDI-based agent-oriented programming language that realizes an integration of declarative and imperative style programming. The declarative style programming supports the implementation of the mental state of agents allowing them to reason about their mental states and update them accordingly. The imperative style programming supports the implementation of processes allowing programming constructs to implement both the flow of control as well as mechanisms such as procedure call, recursion, plan revision, and interface to existing imperative programming languages. In this section, we will proceed illustrating the syntax of the language and both the operational and formal semantics. % We will conclude the section discussing the execution of a multi-agent system and the 2APL deliberation process. 43 44 44 45 \subsection{Syntax and operational semantics} %%%%%%% FABRIZIO HERE 45 46 46 46 - There are 2 distinguished set of programming constructs for specifying a multi-agent system and individual agents. Our approach will be to illustrate the formal syntax little by little providing the explanation of operational semantics through simple fragments of code. 47 47 + There are 2 distinguished set of programming constructs for specifying a multi-agent system and individual agents. Our approach will be to illustrate the syntax little by little providing the explanation of operational semantics through simple fragments of code. All the examples provided here will be related to a environment modeled as a grid and called \texttt{blockWorld}. In this environment, there are two agents named \texttt{harry} and \texttt{sally} which objective is to clean the environment from bombs. 47 48 48 49 \subsubsection{Multi-agent system specification} %%%%%%% FABRIZIO HERE 49 50 50 50 - A multi-agent system is specified as a set of couples, each of them, specifying an agent of the society and a set of environments it has access to. The formal syntax for specifying a multi-agent system is provided in Figure~\ref{fig:ebnf_mas}. 51 51 + A multi-agent system is specified as a set of couples, each of them, specifying an agent of the society and the set of environments it has access to. The formal syntax for specifying a multi-agent system is provided in Figure~\ref{fig:ebnf_mas}. 51 52 52 53 \begin{figure}[htbp] 53 54 \begin{verbatim} ··· 99 100 \label{fig:ebnf_agent} 100 101 \end{figure} 101 102 102 102 - The basic building elements of the language are \texttt{<atom>} that denotes a Prolog like atomic formula starting with a lowercase letter used for stating Prolog atomic formulas, \texttt{<Atom>} that, again, denotes a Prolog like atomic formula starting with a capital letter but, in this case, it is used for invoking functions, \texttt{<ground\_atom>} that denotes a Prolog ground atomic formula\footnote{Prolog formula that does not contain variables}, \texttt{<Var>} that denotes as a string with a capital letter and it is used for variables and, finally, \texttt{<ident>} that denotes a string with a lowercase letter and it used for identifiers. 103 103 + The basic building elements of the language are \texttt{<atom>} that looks like a Prolog like atomic formula starting with a lowercase letter and it used for denoting Prolog formulas, \texttt{<Atom>} that looks like a Prolog like atomic formula starting with a capital letter but, in this case, it is used for denoting functions, \texttt{<ground\_atom>} that looks like a Prolog ground formula\footnote{Prolog formula that does not contain variables} and it used for denoting Prolog ground formulas, \texttt{<Var>} that looks like a string with a capital letter and it is used for denoting variables and, finally, \texttt{<ident>} that looks like a string with a lowercase letter and it used for denoting identifiers. 103 104 104 105 \paragraph{Beliefs and Goals} 105 106 ··· 123 124 \label{fig:ebnf_beliefbase} 124 125 \end{figure} 125 126 126 126 - Figure~\ref{fig:example_beliefbase} shows an example of a belief base for an agent that believes that there is a bomb at position $(3,4)$ and that \texttt{blockWorld} environment is clean if does contain no bombs anymore and the agent itself is not carrying a bomb. Actually, looking back to the basic elements of the language, it can be easy to realize that a belief base is a Prolog program where each belief is either a Prolog rule or fact that must be ground. 127 127 + Figure~\ref{fig:example_beliefbase} shows an example of a belief base for an agent that believes that there is a bomb at position $(3,4)$ and that \texttt{blockWorld} environment is clean if does contain no more bombs and the agent itself is not carrying a bomb. It is easy to realize that a belief base is a Prolog program where each belief is either a Prolog rule or fact that must be ground. 127 128 128 129 \begin{figure}[htp] 129 130 \begin{verbatim} ··· 175 176 \label{fig:ebnf_actions} 176 177 \end{figure} 177 178 178 178 - A \emph{belief update action} updates the belief base exploiting the \emph{precondition-delete-add} formalism. An agent can 179 179 - execute a belief update action if the precondition of the action is entailed by its belief base. The execution of the action then modifies the belief base in such a way that after the execution the post-condition of the action is derivable from the belief base. It is worth noting that the execution of a belief base has as side-effect that goals that become believed to be achieved are removed. The formal syntax of a \emph{belief base update action} is provided in Figure~\ref{fig:ebnf_beliefupdate}. 179 179 + First, a \emph{belief update action} updates the belief base exploiting the \emph{precondition-delete-add} formalism. An agent can 180 180 + execute a belief update action if and only if the precondition of the action is entailed by its belief base. The execution of the action then modifies the belief base in such a way that after the execution the post-condition of the action is derivable from the belief base. It is worth noting that the execution of a belief base has as side-effect that goals that become believed to be achieved are removed. The formal syntax of a \emph{belief base update action} is provided in Figure~\ref{fig:ebnf_beliefupdate}. 180 181 181 182 \begin{figure}[htp] 182 183 \begin{verbatim} ··· 199 200 \label{fig:ebnf_beliefupdate} 200 201 \end{figure} 201 202 202 202 - Figure~\ref{fig:example_beliefupdate} provides an excerpt of belief update actions available in agent \texttt{harry}. For instance, the agent can pickup a bomb if the agent believes it does not already carrying a bomb and, if the action will succeed, the agent will believe that it is carrying a bomb. %It important to see that the agent cannot pickup a bomb consecutively. 203 203 + Figure~\ref{fig:example_beliefupdate} provides a fragment of code from the belief update actions currently available in agent \texttt{harry}. In this case, for instance, the agent can pickup a bomb if the agent believes it is not already carrying a bomb. If the action succeeds, then the agent will believe that it is actually carrying a bomb now. %It important to see that the agent cannot pickup a bomb consecutively. 203 204 204 205 \begin{figure}[htp] 205 206 \begin{verbatim} ··· 213 214 \label{fig:example_beliefupdate} 214 215 \end{figure} 215 216 216 216 - A \emph{communication action} is used to pass a message to other agents. Figure~\ref{fig:ebnf_sendaction} provides the formal specification of the action. Let consider the action \texttt{send(harry, inform, La, On, bombAt(X\_1, Y\_1)}. In this case, the agent \texttt{sally} is sending a message to the agent \texttt{harry} using the perfomative of informing him that there is a bomb at position $(X_1, Y_1)$ using the content language \texttt{La} and the ontology \texttt{On}. 217 217 + Second, a \emph{communication action} is used to pass a message to other agents. Figure~\ref{fig:ebnf_sendaction} provides the formal specification of the action. Let consider the action \texttt{send(harry, inform, La, On, bombAt(X\_1, Y\_1)} for agent \texttt{sally}. In this case, the agent \texttt{sally} is sending a message to the agent \texttt{harry} using the perfomative of informing him that there is a bomb at position $(X_1, Y_1)$ using the content language specified by \texttt{La} and the ontology specified by \texttt{On}. 217 218 218 219 \begin{figure}[htp] 219 220 \begin{verbatim} ··· 227 228 228 229 Actually, a send action can be also performed omitting the specification of the content language and ontology, if it reasonable to assume that all the agents in system share the same content language and ontologies. 229 230 230 230 - An \emph{external action} is supposed to change the state of an external environment. The effects of external actions are, in fact, assumed to be determined by the environment. Thus, a sense action (that is also an external action) has to be performed in order to determine the effect of a previous external action. The formal syntax is provided in Figure~\ref{fig:ebnf_extaction}. An example of external actions is \texttt{@blockworld(east(), L)} that would try to get the agent one step to the east in the \texttt{blockWorld} environment. 231 231 + Third, an \emph{external action} is supposed to change the state of an external environment. The effects of external actions are, in fact, assumed to be determined by the environment. Thus, a sense action (that is also an external action) has to be performed in order to determine the effect of a previous external action. The formal syntax is provided in Figure~\ref{fig:ebnf_extaction}. An example of external actions is \texttt{@blockworld(east(), L)} that would try to get the agent one step to the east in the \texttt{blockWorld} environment. 231 232 232 233 \begin{figure}[htp] 233 234 \begin{verbatim} ··· 237 238 \label{fig:ebnf_extaction} 238 239 \end{figure} 239 240 240 240 - An \emph{abstract action} is used to instantiate a new plan when the action is executed in the way a procedure call would instantiate a new procedure. The formal syntax is provided in Figure~\ref{fig:ebnf_absaction}. A example of this action will be shown later in a concrete scenario. 241 241 + Fourth, an \emph{abstract action} is used to instantiate a new plan when the action is executed in the way a procedure call would instantiate a new procedure. The formal syntax is provided in Figure~\ref{fig:ebnf_absaction}. A example of this action will be shown later in a concrete example. 241 242 242 243 \begin{figure}[htp] 243 244 \begin{verbatim} ··· 247 248 \label{fig:ebnf_absaction} 248 249 \end{figure} 249 250 250 250 - \emph{Test actions} are query expressions used to check if an agent can derive certain beliefs and goals from its bases. The formal syntax is provided in Figure~\ref{fig:ebnf_testaction}. 251 251 + Fifth, \emph{test actions} are query expressions used to check if an agent can derive certain beliefs and goals from its bases. The formal syntax is provided in Figure~\ref{fig:ebnf_testaction}. 251 252 252 253 \begin{figure}[htp] 253 254 \begin{verbatim} ··· 268 269 269 270 Let imagine that, for instance, an agent has a certain belief \texttt{p(a)} and it is pursing the goal of achieving a situation \texttt{q(b)} and we are querying first for \texttt{B(p(X)) \& G(q(X))} and then for \texttt{B(p(X)) \& G(q(Y) or r(X))}. In the first case the query will fail since no substitution is possible, while in the second case the query will succeed by the substitution $\rho=\{X/a, Y/b\}$. 270 271 271 271 - \emph{Goal dynamics action} are used to adopt and drop goals to and from an agent's goal base. The adopt goal action has two forms, the first one for adopting a goal giving it the maximum priority and another one for giving it the least priority. Also, the drop goal action has three different forms they are used to drop from an agent’s goal base, respectively, exactly the goal specified, all goals that are subgoal of the goal specified and all goals that have the goal specified as a subgoal. The formal syntax is provided in Figure~\ref{fig:ebnf_goalactions}. 272 272 + Sixth, \emph{goal dynamics actions} are used to adopt and drop goals to and from an agent's goal base. The adopt goal action has two forms, the first one is for adopting a goal giving it the maximum priority while the second one is for giving it the minimum priority. The drop goal action has three different forms as well and they are used to drop goals from an agent’s goal base: the first form is to drop exactly the goal specified, the second form is to drop all goals that are subgoal of the specified goal while the third form is to drop all goals that have the goal specified as a subgoal. The formal syntax is provided in Figure~\ref{fig:ebnf_goalactions}. 272 273 273 274 \begin{figure}[htp] 274 275 \begin{verbatim} ··· 285 286 \label{fig:ebnf_goalactions} 286 287 \end{figure} 287 288 288 288 - To illustrate the use of these three different actions to drop a goal the following three goals are considered: \texttt{a(1), a(1) and b(1), a(1) and b(1)}. Then a \texttt{dropgoal(a(1) and b(1))} action will drop exactly the \texttt{a(1) and b(1)}, the \texttt{dropsubgoal(a(1) and b(1))} will drop the goal \texttt{a(1) and b(1)} and its subgoal \texttt{a(1)} and, finally, the action \texttt{dropsupergoal(a(1) and b(1))} will drop the goal \texttt{a(1) and b(1)} and its supergoal \texttt{a(1) and b(1) and c(1)}. 289 289 + To illustrate the use of these three different forms of drop goal actions the following three goals are considered: \texttt{a(1), a(1) and b(1), a(1) and b(1)}. Then a \texttt{dropgoal(a(1) and b(1))} action will drop exactly the \texttt{a(1) and b(1)}, the \texttt{dropsubgoal(a(1) and b(1))} will drop the goal \texttt{a(1) and b(1)} and its subgoal \texttt{a(1)} while the action \texttt{dropsupergoal(a(1) and b(1))} will drop the goal \texttt{a(1) and b(1)} and its supergoal \texttt{a(1) and b(1) and c(1)}. 289 290 290 291 \paragraph{Plans} 291 292 292 292 - In order to reach its goals, a agent needs to adopt \emph{plans}. A plan consists of basic actions that can be composed by using the following operators: sequence operator, conditional choice operators, conditional iteration operator and atomic operator for plans that must be executed atomically. The formal syntax for both specifying a plan and a plan base is provided in Figure~\ref{fig:ebnf_plans}. 293 293 + In order to reach its goals, a agent needs to adopt \emph{plans}. A plan consists of basic actions that can be composed by the use of the following operators: sequence operator, conditional choice operators, conditional iteration operator and atomic operator for plans that must be executed atomically. The formal syntax for specifying both a plan and a \emph{plan base} is provided in Figure~\ref{fig:ebnf_plans}. 293 294 294 295 \begin{figure}[htp] 295 296 \begin{verbatim} ··· 311 312 \label{fig:ebnf_plans} 312 313 \end{figure} 313 314 314 314 - Figure~\ref{fig:ebnf_planbase} shows an example of the implementation of an initial plan base of \texttt{harry} that let him enter the \texttt{blockWorld} environment by performing a test action and then an external action. It worth noting that during execution of the agent, the plan base will be filled with plans by means of reasoning rules. 315 315 + Figure~\ref{fig:ebnf_planbase} shows an example of the implementation of an initial plan base of \texttt{harry} where there is the plan to let him enter the \texttt{blockWorld} environment by performing a test action \texttt{start} followed by an external action \texttt{enter}. It worth noting that during execution of the agent, the plan base will be filled with plans by means of reasoning rules. 315 316 316 317 \begin{figure}[htp] 317 318 \begin{verbatim} ··· 326 327 327 328 There are three kind of \emph{practical reasoning rules} that are used to implement the generation of plans: planning goal rules (PG rules), procedural rules (PC rules) and plan repair rules (PR rules). 328 329 329 329 - PG rules are used to generate plans starting from certain beliefs and goals. The formal syntax is provided in Figure~\ref{fig:ebnf_pgrules}. 330 330 + First, PG rules are used to generate plans starting from certain beliefs and goals. The formal syntax is provided in Figure~\ref{fig:ebnf_pgrules}. 330 331 331 332 \begin{figure}[htp] 332 333 \begin{verbatim} ··· 339 340 \label{fig:ebnf_pgrules} 340 341 \end{figure} 341 342 342 342 - An example of a planning goal rule is provided in Figure~\ref{fig:example_pgrules} indicating that a plan to achieve the goal \texttt{clean(blockWorld)} can be generated if the agent believes there is a bomb at position $(X,Y)$. Note that \texttt{goto(X,Y)} is an example of abstract action, \texttt{@blockworld(pickup(), L1)} is an external action and \texttt{PickUp()} is a belief update action. 343 343 + An example of a planning goal rule is provided in Figure~\ref{fig:example_pgrules} indicating that a plan to achieve the goal \texttt{clean(blockWorld)} can be generated if the agent believes there is a bomb at position $(X,Y)$. It is worth noting that \texttt{goto(X,Y)} is an example of abstract action, \texttt{@blockworld(pickup(), L1)} is an external action and \texttt{PickUp()} is a belief update action. 343 344 344 345 \begin{figure}[htp] 345 346 \begin{verbatim} ··· 359 360 \label{fig:example_pgrules} 360 361 \end{figure} 361 362 362 362 - PC rules are used to generate plans as a response to the execution of abstract actions or the reception of messages from other agents or events generated from the environment. A procedural rule is applied if and only if the belief condition is entailed by the belief base. The formal syntax is provided in Figure~\ref{fig:ebnf_pcrules}. 363 363 + Second, PC rules are used to generate plans as a response to the execution of abstract actions or the reception of messages from other agents or \emph{events} generated from the environment. A procedural rule is applied if and only if the belief condition is entailed by the belief base. The formal syntax is provided in Figure~\ref{fig:ebnf_pcrules}. 364 364 + Figure~\ref{fig:example_pcrules} shows an example of two procedural rules for \texttt{harry}. The first PC-rule indicates that the abstract action \texttt{goto} is actually a certain sequence of actions that can be always executed independent from what it is entailed from the belief base (\texttt{true}). The second PC-rule indicates that if \texttt{harry} receives a message from \texttt{sally} informing him that there is a bomb at position $(X,Y)$ and \texttt{harry} does not believe there are any bombs, then harry updates his beliefs with this new fact and adds a goal to clean the \texttt{blockWorld} again. 363 365 364 366 \begin{figure}[htp] 365 367 \begin{verbatim} ··· 371 373 \caption{EBNF syntax for specifying PC rules} 372 374 \label{fig:ebnf_pcrules} 373 375 \end{figure} 374 374 - 375 375 - Figure~\ref{fig:example_pcrules} shows an example of two procedural rules for \texttt{harry}, the first one indicating that the abstract action \texttt{goto} is actually a certain sequence of actions, while second one indicating that if \texttt{harry} receives a message from \texttt{sally} informing him that there is a bomb at position $(X,Y)$ and \texttt{harry} does not believe there are any bombs, then harry updates his beliefs with this new fact and adds a goal to clean the \texttt{blockWorld} again. 376 376 377 377 \begin{figure}[htp] 378 378 \begin{verbatim} ··· 408 408 \label{fig:example_pcrules} 409 409 \end{figure} 410 410 411 411 - Finally, PR rules are used to replace a plan whose execution has failed. Plan repair rules can be applied if the following condition hold: the execution of a plan fails, there is a rule matching the failed action and the belief query expression is derivable from the agent's belief base. The formal syntax of PR rules is provided in Figure~\ref{fig:ebnf_prrules}. 411 411 + Third, PR rules are used to replace a plan whose execution has failed. Plan repair rules can be applied if the following conditions hold: the execution of a plan fails, there is a rule matching the failed action and the belief query expression is derivable from the agent's belief base. The formal syntax of PR rules is provided in Figure~\ref{fig:ebnf_prrules}. 412 412 + An example of a plan repair rule of \texttt{harry} is shown in Figure~\ref{fig:example_pcrules}. This rule is used for the situation in which the execution of a plan that starts with the external action \texttt{@blockworld(pickup(),L)} fails. Such an action fails in case there is no bomb to be picked up, may be because it has already been removed by another agent. The rule states that the plan should be replaced by a plan in which the agent updates its beliefs about the location of the bombs. It is worth noting that the rest of the original plan denoted by \texttt{REST} is dropped, as it is not used anymore within the rule. It is important to note that the execution of a plan fails if the execution of its first action fails. An action fails according to some causes that depends on the type of the action. Table~\ref{table:action_fail} provides a quick summary of possible causes for each kind of action. 412 413 413 414 \begin{figure}[htp] 414 415 \begin{verbatim} ··· 427 428 \caption{EBNF syntax for specifying PR rules} 428 429 \label{fig:ebnf_prrules} 429 430 \end{figure} 430 430 - 431 431 - An example of a plan repair rule of \texttt{harry} is shown in Figure~\ref{fig:example_pcrules}. This rule is used for the situation in which the execution of a plan that starts with the external action \texttt{@blockworld(pickup(),L)} fails. Such an action fails in case there is no bomb to be picked up, may be because it has already been removed by another agent. The rule states that the plan should be replaced by a plan in which the agent updates its beliefs about the location of the bombs. It is worth noting that the rest of the original plan denoted by \texttt{REST} is dropped, as it is not used anymore within the rule. 432 431 433 432 \begin{figure}[htp] 434 433 \begin{verbatim} ··· 443 442 \label{fig:example_pcrules} 444 443 \end{figure} 445 444 446 446 - Finally, it is important to see that the execution of a plan fails if the execution of its first action fail and, when an action fails, depends on the type of the action. Table~\ref{table:action_fail} provides a quick summary of possible causes for each kind of action. 447 447 - 448 445 \begin{table}[htp] 449 446 \begin{tabular}{|l| p{8.5cm}|} 450 447 \hline ··· 452 449 \hline 453 450 Abstract action & There is no applicable procedural rule \\ 454 451 \hline 455 455 - External action & The environment throws an \texttt{ExternalActionFailedException},the agent has no access to the environment, the actions is not defined in the environment \\ 452 452 + External action & The environment throws an \texttt{ExternalActionFailedException} or the agent has no access to the environment or the actions is not defined in the environment \\ 456 453 \hline 457 454 Test action & The test expression is no derivable from the belief or goal bases \\ 458 455 \hline 459 459 - Goal adopt action & The goal is already entailed by the belief base, the goal to be adopted is not ground\\ 456 456 + Goal adopt action & The goal is already entailed by the belief base or the goal to be adopted is not ground\\ 460 457 \hline 461 458 Atomic plan & If one of its actions fails \\ 462 459 \hline ··· 467 464 468 465 \subsubsection{Programming the environment} %%%%%%% FABRIZIO HERE 469 466 470 470 - A 2APL environment can be any Java class implementing the \emph{environment interface} that contains the following two methods: \texttt{addAgent(String name)} and \texttt{removeAgent(String name)}. Any external action like \texttt{@env($a_1, \ldots, a_n$, R)} is translated into a call to a method $m$ with arguments $a_1, \ldots, a_n$ in environment $env$. Java exceptions are the mechanisms used to inform an agent that an execution of an action has failed and let it apply plan repair rules. Figure~\ref{fig:example_env} provide an example of a \texttt{move} external action that can fail if an unknown direction is specified. 467 467 + A 2APL environment can be any Java class implementing the \emph{environment interface}. The environment interface contains the following two methods for adding and removing an agent from the system: \texttt{addAgent(String name)} and \texttt{removeAgent(String name)}. Any external action like \texttt{@env($a_1, \ldots, a_n$, R)} is actually translated into a call to a method $m$ with arguments $a_1, \ldots, a_n$ in environment specified by the $env$ Java class. It is important to note that the constructor of the environment must require exactly one parameter of the type \texttt{ExternalEventListener}. Such class has the method \texttt{notifyEvent(AF event, String... agents)} that should be used to notify agents of \emph{events} from the environment. The first argument of this method may be any valid atomic formula. The rest of the arguments may be filled with strings that represent local names of agents. If the programmer does not specify any agents in the argument list, all agents can receive the event. Finally, Java exceptions represent the mechanisms to inform an agent that an execution of an external action on the environment has failed. Figure~\ref{fig:example_env} provides an example of a \texttt{move} external action that can fail throwing an \texttt{ExternalActionFailedException} exception if an unknown direction is specified. 471 468 472 469 \begin{figure}[htp] 473 470 \begin{verbatim} ··· 486 483 \caption{Example of} 487 484 \label{fig:example_env} 488 485 \end{figure} 489 489 - 490 490 - Finally, it is important to state that the constructor of the environment must require exactly one parameter of the type \texttt{ExternalEventListener}. Such class has the method \texttt{notifyEvent(AF event, String... agents)} that can be used to notify agents of events from the environment. The first argument of this method may be any valid atomic formula. The rest of the arguments may be filled with strings that represent local names of agents. If the programmer does not specify any agents in the argument list, all agents can receive the event. 491 486 492 487 \subsection{Formal Semantics} %%%%%%% MARCOS HERE 493 488 494 494 - In this section we present the formal semantics of 2APL in terms of transition system. A transition system is a set of transition rules for deriving transitions. A transitionis is a transformation of one configuration into another and it corresponds to a simple computation/execution step. 489 489 + In this section we present the formal semantics of 2APL in terms of transition system. A transition system is a set of transition rules for deriving transitions. A transitions is a transformation of one configuration into another and it corresponds to a simple computation/execution step. 495 490 496 491 The execution of a 2APL multi-agent program modifies its initial configuration by means of transitions that are derivable from the transition rules. In fact, each transition rule indicates which execution step (i.e., transition) is possible from a given configuration. It should be noted that for a given configuration there may be several transition rules applicable. An interpreter is a deterministic choice of applying transition rules in a certain order. 497 492 498 493 \subsubsection{2APL Configurations} 499 494 500 500 - The configuration of an individual agent consists of its \textbf{identifier}, \textbf{beliefs}, \textbf{goals}, \textbf{plans}, \textbf{substitutions that are resulted from queries to the belief and goal bases}, and the \textbf{received events}. Moreover, additional information is assigned to an agent's plan. In particular, a unique identifier is assigned to each plan which can be used to identify and repair failed plans. Also, the practical reasoning rules by means of which plans are generated are assigned to plans in order to avoid redundant applications of practical reasoning rules, e.g., to avoid generating multiple plans for one and the same goal. 495 495 + The configuration of an individual agent consists of its identifier, beliefs, goals, plans, substitutions that are resulted from queries to the belief and goal bases, and the received events. Moreover, additional information is assigned to an agent's plan. In particular, a unique identifier is assigned to each plan which can be used to identify and repair failed plans. Also, the practical reasoning rules by means of which plans are generated are assigned to plans in order to avoid redundant applications of practical reasoning rules, e.g., to avoid generating multiple plans for one and the same goal. 501 496 502 497 \paragraph{Individual agent} 503 498 504 504 - The configuration of an individual 2APL agent is defined as $ A_{\iota} = \langle \iota, \sigma, \gamma, \Pi, \theta, \xi \rangle $ where $\iota$ is a set of belief expressions representig the agent's identifier, $\sigma$ is a list of goals expressions representing the agent's belief base, $\gamma$ is the agent's goal base, $\Pi$ is a set of plan entries representing the agent's goal base, $\theta$ is a ground substitution that binds domain variables to gound terms, and $\xi = \langle E, I, M \rangle$ is the agent's event base, where 499 499 + The configuration of an individual 2APL agent is defined as $ A_{\iota} = \langle \iota, \sigma, \gamma, \Pi, \theta, \xi \rangle $ where $\iota$ is a set of belief expressions representing the agent's identifier, $\sigma$ is a list of goals expressions representing the agent's belief base, $\gamma$ is the agent's goal base, $\Pi$ is a set of plan entries representing the agent's goal base, $\theta$ is a ground substitution that binds domain variables to ground terms, and $\xi = \langle E, I, M \rangle$ is the agent's event base, where 505 500 506 501 \begin{itemize} 507 502 \item $E$ is a set of events from the external environments, which has the form $event(A,S)$, where $A$ is a ground atom originated from the environment $S$. ··· 509 504 \item $M$ is the set of messages sent to the agent. 510 505 \end{itemize} 511 506 512 512 - Each plan entry is a tuple $(\pi, r, p)$, where $\pi$ is the executing plan, $r$ is the instatation of the PG-rule throug which $\pi$ is generated, and $p$ is the plan identifier. The belief base and each goal in the goal base are consistent as only positive atoms are used to represent them. 507 507 + Each plan entry is a tuple $(\pi, r, p)$, where $\pi$ is the executing plan, $r$ is the instantiation of the PG-rule through which $\pi$ is generated, and $p$ is the plan identifier. The belief base and each goal in the goal base are consistent as only positive atoms are used to represent them. 513 508 514 509 \paragraph{Multi-agents system} 515 510 ··· 517 512 518 513 \subsubsection{Transition rules for basic actions} 519 514 520 520 - A basic action can be executed at individual agent level. For some types of basic actions additional transition rules are given that specify when an action's execution fails and which transition an individual agent should make if the execution of the action fails. In general when the execution of a basic action fails, an exception with its corresponding plan identifier, is added to the set of failed plans. This exception can later be used to repais the corresponding plan by meabs of plan repair rules. 515 515 + A basic action can be executed at individual agent level. For some types of basic actions additional transition rules are given that specify when an action's execution fails and which transition an individual agent should make if the execution of the action fails. In general when the execution of a basic action fails, an exception with its corresponding plan identifier, is added to the set of failed plans. This exception can later be used to repair the corresponding plan by means of plan repair rules. 521 516 522 522 - Now, we present the differents transition rules that capture the execution of basic actions. We assume $\gamma \vDash_{g} \texttt{true}$ for any goal base $\gamma$. We use $G(r)$, $B(r)$ and $P(r)$ to indicate the head $\kappa$, the belief condition $\beta$, and the plan $\pi$ of a rule $ r = (\kappa \leftarrow \beta \vert \pi)$. 517 517 + Now, we present the different transition rules that capture the execution of basic actions. We assume $\gamma \vDash_{g} \texttt{true}$ for any goal base $\gamma$. We use $G(r)$, $B(r)$ and $P(r)$ to indicate the head $\kappa$, the belief condition $\beta$, and the plan $\pi$ of a rule $ r = (\kappa \leftarrow \beta \vert \pi)$. 523 518 524 519 \paragraph{Skip action} 525 520 ··· 528 523 529 524 $$ {{\gamma \vDash_{g} G(r)}\over{\langle \iota, \sigma, \gamma, \{(\texttt{skip}, r, id)\}, \theta, \xi \rangle \rightarrow \langle \iota, \sigma, \gamma, \{\}, \theta, \xi \rangle}}$$ 530 525 531 531 - This transition indicates that the execution of the plan entry $(\texttt{skip}, r, id)$ proceeds resulting in the removal os this entry from the plan base. This transition rule can be applied only if the goal that is assigned to the \texttt{skip} action is entailed by the agent's goal base. 526 526 + This transition indicates that the execution of the plan entry $(\texttt{skip}, r, id)$ proceeds resulting in the removal of this entry from the plan base. This transition rule can be applied only if the goal that is assigned to the \texttt{skip} action is entailed by the agent's goal base. 532 527 533 528 \paragraph{Belief update action} 534 529 ··· 540 535 541 536 where $T$ is a function that takes a belief update action and a belief base, and returns the modified belief base if the pre-condition of the action is entailed by the agent's belief base. 542 537 543 543 - The beliefs and goals of agents are related to each other. In fact, if an agent believes a 544 544 - certain fact, then the agent does not pursue that fact as a goal. This means that if an agent 545 545 - modifies its belief base, then its goal base may be modified as well. 538 538 + % REPETITION The beliefs and goals of agents are related to each other. In fact, 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. 546 539 547 540 \paragraph{Test action} 548 541 549 542 The objective of a test action is to check if the belief and goal queries within a test expression are entailed by the agent's belief and goal bases. Since we have the substitution $\theta$ that should be applied to the variables in the test expression, this can still contain unbound variables. Therefore, the test action results in another substitution $\tau$ added to $\theta$. 550 543 551 551 - A test action $\varphi$ can be exevuted successfully if $\varphi$ is entailed by the agent's belief and goal bases. 544 544 + A test action $\varphi$ can be executed successfully if $\varphi$ is entailed by the agent's belief and goal bases. 552 545 553 546 $$ {{( \sigma, \gamma) \vDash_{t} \varphi \theta \tau \& \gamma \vDash_{g} G(r)}\over{\langle \iota, \sigma, \gamma, \{(\varphi, r, id)\}, \theta, \xi \rangle \rightarrow \langle \iota, \sigma, \gamma, \{\}, \theta \cup \tau, \xi \rangle}} $$ 554 547 ··· 570 563 571 564 \paragraph{Abstract action} 572 565 573 573 - Abstract actions are representations of plans. The execution of an abstract action replaces the action with the plan it represents. The relation between an abstract action and the plan it represents is specified by means of a procedure call rule (PC-rule) that has a head unificable with the abstract action. 566 566 + Abstract actions are representations of plans. The execution of an abstract action replaces the action with the plan it represents. The relation between an abstract action and the plan it represents is specified by means of a procedure call rule (PC-rule) that has a head unifiable with the abstract action. 574 567 575 575 - Let $\alpha$ be an abstract action, $\varphi \leftarrow \beta \vert \pi$ be a variant of a PC-rule of agent and Unify be a function that returns the most general unifier of $\alpha$ and $\varphi$ if they are unificable, otherwise it returns $\bot$. A successful execution of an abstract action will replace it with a plan. 568 568 + Let $\alpha$ be an abstract action, $\varphi \leftarrow \beta \vert \pi$ be a variant of a PC-rule of agent and Unify be a function that returns the most general unifier of $\alpha$ and $\varphi$ if they are unifiable, otherwise it returns $\bot$. A successful execution of an abstract action will replace it with a plan. 576 569 577 570 $$ {{Unify(\alpha\theta, \phi = \tau_{1} \& \sigma \vDash \beta\tau_{1}\tau_{2} \& \gamma \vDash_{g} G(r) } \over {\langle \iota, \sigma, \gamma, \{(\alpha, r, id)\}, \theta, \xi \rangle \rightarrow \langle \iota, \sigma, \gamma', \{(\pi\tau_{1}\tau_{2}, r, id)\}, \theta, \xi \rangle}} $$ 578 571 ··· 655 648 656 649 \paragraph{Planing goal rules} 657 650 658 658 - A 2APL agent generates plans by applying PG-rules of the form $\kappa \leftarrow \beta \vert \pi$. There are two types of PG-rules. The first type of PG-rule, characterized by $kappa \neq \texttt{true}$, indicates that plan $\pi$ should be generated to achieve goal $\kappa$. The second tupe of PG-rule, defined by $\kappa = \texttt{true}$ indicates that plan $\pi$ should be generated when the agent believes $\beta$. 651 651 + A 2APL agent generates plans by applying PG-rules of the form $\kappa \leftarrow \beta \vert \pi$. There are two types of PG-rules. The first type of PG-rule, characterized by $kappa \neq \texttt{true}$, indicates that plan $\pi$ should be generated to achieve goal $\kappa$. The second type of PG-rule, defined by $\kappa = \texttt{true}$ indicates that plan $\pi$ should be generated when the agent believes $\beta$. 659 652 660 653 In general, an agent can apply one of its PG-rules $ r = \kappa \leftarrow \beta \vert \pi $, if $\kappa$ is entailed by one of the agent's goals, $\beta$ is entailed by the agent's belief base, and there is no plan in the plan base that has been generated (and perhaps partially executed) by applying the same PG-rule to achieve the same goal. 661 654 ··· 665 658 666 659 The transition rule for execution of abstract action is based on application of PC-rules that generate plans to be replaced for the executed abstract actions. The PC-rules are applied to generate plans in order to react to either the received events from the environments or the received messages from other agents. 667 660 668 668 - Events are broadcasted when the state of the environments change. These events are catched and included in the $E$ component of the event base. The messages received from other agents are included in the $M$ component of the event base. 661 661 + Events are broadcasted when the state of the environments change. These events are caught and included in the $E$ component of the event base. The messages received from other agents are included in the $M$ component of the event base. 669 662 670 663 $${ \psi \in E \cup M \& Unify(\psi, \varphi) = \tau_{1} \& \sigma \vDash \beta \tau_{1} \tau_{2} } \over {\langle \iota, \sigma, \gamma, \Pi, \theta, \xi \rangle \rightarrow \langle \iota, \sigma, \gamma, \Pi', \theta, \xi' \rangle}$$ 671 664 ··· 679 672 680 673 $$ {Plan Unify(\pi, \pi_{1}) = (\tau_{d}, \tau_{p}, \pi *) \& \sigma \vDash \beta\tau_{d}\tau \& id ºin I} \over {\langle \iota, \sigma, \gamma, \{(\pi, r, id)\}, \theta, \langle E, I, M \rangle \rangle \rightarrow \langle \iota, \sigma, \gamma, \{(\pi_{2}\tau_{d}\tau\tau_{p};\pi *, r, id)\}, \theta, \langle E, I/\{id\}, M \rangle \rangle}$$ 681 674 682 682 - Plan repair rules should be used cautiously. If the repaired part of a failed plan includes an action through which variables are bound (e.g., test or external actions), then the variables should not occur in the unrepaired part of the plan (i.e., plan part bound to plan variables or the plan part $\pi$*). 675 675 + Plan repair rules should be used cautiously. If the repaired part of a failed plan includes an action through which variables are bound (e.g., test or external actions), then the variables should not occur in the unrepairable part of the plan (i.e., plan part bound to plan variables or the plan part $\pi$*). 683 676 684 677 685 678 \subsubsection{Multi-agent transition rules} 686 679 687 680 The execution of a 2APL multi-agent system is the interleaved executions of the involved individual agents and the environments. We assume that the external shared environments can change either by the execution of an agent's external action in one of the environments or by the internal dynamics of the environments. 688 681 689 689 - Therefore, {\bf the configuration of a multi-agent system can be modified} when either the configuration of one of the involved individual agents is modified or when the shared environments change. 682 682 + Therefore, the configuration of a multi-agent system can be modified when either the configuration of one of the involved individual agents is modified or when the shared environments change. 683 683 + 684 684 + \subsubsection{Deliberation Cycle} %%%%%%% FABRIZIO HERE 685 685 + 686 686 + 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. The predefined deliberation cycle is provided in Figure~\ref{fig:deliberation_cycle}. 687 687 + 688 688 + \begin{figure}[htp] 689 689 + \centering 690 690 + \includegraphics[keepaspectratio,scale=0.35]{fig/rcycle.png} 691 691 + \caption{Predefined deliberation Cycle} 692 692 + \label{fig:deliberation_cycle} 693 693 + \end{figure} 694 694 + 695 695 + Each cycle starts by applying all applicable PG-rules, each rule only one time. The deliberation cycle proceeds by executing only the first actions of all plans. This is in order to allow all plans to get a chance to be executed. The next deliberation steps are to 696 696 + 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 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 to it. It is worth noting that the application of rules 697 697 + to process events generates and add plans to the corresponding agent’s plan base. 698 698 + 699 699 + 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. 700 700 + 701 701 + The predefined deliberation cycle has the two following properties: first, if the execution of a plan fails, then the plan will either be repaired in the same deliberation cycle or get re-executed in the next deliberation cycle, since plans are executed before internal events are processed. Second, if the first action fails and there is no plan repair rule for it, then the failed plan may be successfully executed in the next deliberation cycle, since the belief and a goal bases can be modified in one deliberation cycle such that belief and goal test actions may be executed successfully in the next cycle. 702 702 + 690 703 691 704 \section{2APL Platform}\label{sec:platform} %%%%%%% BORJA+MARCOS HERE 692 705 ··· 694 707 695 708 \subsection{JADE tools} 696 709 697 697 - The current 2APL platform comes with three JADE tools: the {\bf RMA} tool, {\bf sniffer} tool, and the 698 698 - {\bf introspecto}r tool. The RMA (Remote Monitoring Agent) tool can be used to control the life cycle of the agent platform and of all the registered agents. We can see this tool in the figure~\ref{fig:rma}. 710 710 + The current 2APL platform comes with three JADE tools: the \emph{RMA} tool, \emph{sniffer} tool, and the 711 711 + \emph{introspector} tool. The RMA (Remote Monitoring Agent) tool can be used to control the life cycle of the agent platform and of all the registered agents. We can see this tool in the figure~\ref{fig:rma}. 699 712 700 713 \begin{figure}[htp] 701 714 \centering ··· 705 718 \end{figure} 706 719 707 720 The sniffer (figure ~\ref{fig:sniffer}) can be used for tracking messages exchanged in a JADE based environment. 708 708 - You can select agents to be sniffed. Every message directed to this agent(s) or coming from this 709 709 - agent(s) is tracked and displayed in the sniffer window. 721 721 + You can select agents to be sniffed. Every message directed to or coming from the sniffed agent is tracked and displayed in the sniffer window. 710 722 711 723 \begin{figure}[htp] 712 724 \centering ··· 715 727 \label{fig:sniffer} 716 728 \end{figure} 717 729 718 718 - The introspector (figure ~\ref{fig:introspector}) allows to monitor and control the life-cycle of a running agent and its exchanged messages, both the queue of sent and received messages. It allows also to monitor the queue of behaviours, including executing them step-by-step. 730 730 + The introspector (figure ~\ref{fig:introspector}) allows to monitor and control the life-cycle of a running agent and its exchanged messages, both the queue of sent and received messages. It allows also to monitor the queue of behaviors, including executing them step-by-step. 719 731 720 732 \begin{figure}[htp] 721 733 \centering ··· 728 740 729 741 \subsubsection{The FGDC tool} 730 742 731 731 - The FGDC (Flexible Graphical Deliberation Cycle) tool (figure~\ref{fig:fgdc}) can be used to visualize and \textbf{program the deliberation cycle of an agent}. 743 743 + The FGDC (Flexible Graphical Deliberation Cycle) tool (figure~\ref{fig:fgdc}) can be used to visualize and program the deliberation cycle of an agent. 732 744 733 745 The agent's deliberation cycle is used to determine what the agent should do next, e.g., execute an action, or select a plan to reach a goal. By clicking on the FGDC button of the toolbar, an extra tab will become available in the agent panel. The left panel of the FGDC window shows the deliberation cycle of the currently selected agent. In this panel, the rectangles represent the steps, whereas the arrows represent the sequence in which the steps are to be executed. The panel on the right shows the predefined deliberation steps that can be used. A deliberation step can be added to the deliberation cycle by double clicking on a predefined deliberation steps. The selected predefined deliberation step will then appear in the left panel. Deliberation steps can be linked by arrows by right clicking on the source, dragging the arrow to its destination and dropping it there. The steps and arrows can be deleted by right clicking on them. Some appearance settings of the FGDC can be changed in the FGDC settings window that can be accessed via the settings button located on the right panel. Any modification of the deliberation cycle will be lost by reloading the agent. 734 746 ··· 756 768 757 769 The fact that 2APL platform is built on the top of JADE (Java Agent DEvelopment Framework) allows to use all the functionality that this framework has to communicate to other agents. Thus, as JADE, 2APL follows FIPA specifications. 758 770 759 759 - In order to be able to sending messages to running agent, 2APL implements {\bf the message agent}.The message agent can be accessed by clicking on the message agent button in the toolbar. We must specify the receiver, that can be in JADE format, the performatice and the content. Moreover, optionaly, we can specify the language and the ontology of the message. 771 771 + In order to be able to sending messages to running agent, 2APL implements the message agent.The message agent can be accessed by clicking on the message agent button in the toolbar. We must specify the receiver, that can be in JADE format, the perfomative and the content. Moreover, optionally, we can specify the language and the ontology of the message. 760 772 761 773 In figure~\ref{fig:message_agent} we can see the form to send a message to a running agent. 762 774 ··· 767 779 \label{fig:message_agent} 768 780 \end{figure} 769 781 770 770 - \subsection{Deliberation Cycle} %%%%%%% FABRIZIO HERE 782 782 + \section{Conclusion}\label{sec:concl} 771 783 772 772 - 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. The predefined deliberation cycle is provided in Figure~\ref{fig:deliberation_cycle}. 784 784 + In this report, we presented a BDI-based multi-agent programming language called 2APL, which provides practical constructs for the implementation of cognitive agents onto the 2APL platform that support the development and execution of multi-agent systems. The execution of a multi-agent system is the interleaving execution of individual agent programs and the shared environments. The execution of an individual agent program is based on the deliberation cycle where each cycle determines which transitions in which order should take place. The 2APL platform provides graphical tools to let a programmer load, edit, run, and debug a 2APL multi-agent system, browse through an agent’s states generated by the execution of its corresponding agent program and modify the deliberation cycle. The 2APL platform is built on the top of JADE and it complies with the FIPA specifications. Both 2APL language and platform are still under development. Future work includes improvements both at multi-agent level and individual agent level. At multi-agent level, future work counts the implementation of social and organizational issues such as norms, obligations, prohibition, permissions, power relation, delegations of tasks, responsibility, and trust. At individual level, future work counts the introduction of programming constructs for the implementation of various goals types such as perform, achieve and maintenance goals, the specification of conflicting goals and the implementation of various commitment strategies such as blindly-minded, single-minded, and open-minded through the introduction of intentions. 773 785 774 774 - \begin{figure}[htp] 775 775 - \centering 776 776 - \includegraphics[keepaspectratio,scale=0.35]{fig/rcycle.png} 777 777 - \caption{Predefined deliberation Cycle} 778 778 - \label{fig:deliberation_cycle} 779 779 - \end{figure} 780 780 - 781 781 - Each cycle starts by applying all applicable PG-rules, each rule only one time. The deliberation cycle proceeds by executing only the first actions of all plans. This is in order to allow all plans to get a chance to be executed. The next deliberation steps are to 782 782 - 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 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 to it. It is worth noting that the application of rules 783 783 - to process events generates and add plans to the corresponding agent’s plan base. 784 784 - 785 785 - 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. 786 786 - 787 787 - The predefined deliberation cycle has the two following properties: first, if the execution of a plan fails, then the plan will either be repaired in the same deliberation cycle or get re-executed in the next deliberation cycle, since plans are executed before internal events are processed. Second, if the first action fails and there is no plan repair rule for it, then the failed plan may be successfully executed in the next deliberation cycle, since the belief and a goal bases can be modified in one deliberation cycle such that belief and goal test actions may be executed successfully in the next cycle. 788 788 - 789 789 - 790 790 - \section{Conclusion} %%%%%%% BORJA HERE 791 791 - 792 792 - %Borja here: conclusion + connecting with other alternatives (jadex etc) 793 793 - The main objective of 2APL, a BDI-based multi-agent programming language, is providing practical constructs for the implementation of cognitive agents. One of the most important feature that 2APL provedes is the theoretical model . Other important feature is the use of Prolog resolution system, its brings a powerfull way to reasoning about the beliefs of the agent, the goals and the plans. 794 794 - 795 795 - %% TODO Complete the conclusion... Copy paste from the documentation? 786 786 + %The main objective of 2APL, a BDI-based multi-agent programming language, is providing practical constructs for the implementation of cognitive agents. One of the most important feature that 2APL provides is the theoretical model . Other important feature is the use of Prolog resolution system, its brings a powerful way to reasoning about the beliefs of the agent, the goals and the plans. 787 787 + %% 796 788 797 789 \section{Bibliography} 798 790 \nocite{*}

+12 -4

docs/2apl-pres.tex

reviewed

··· 1592 1592 \begin{itemize} 1593 1593 \item We have presented a brief description of the 2APL language. It is still a rather new language and thus is still fully in development: declarative goals, goal revision rules, nested beliefs, model checking, formal semantics, implementations, etc. 1594 1594 1595 1595 + \vskip 2.0ex 1596 1596 + 1595 1597 \item Already being used in several projects and thesis. 1596 1598 \end{itemize} 1597 1599 } ··· 1603 1605 1604 1606 \item More programming constructs on 1605 1607 \begin{itemize} 1606 1606 - \item Multi-agent level: to allow the implementation of social and 1607 1607 - organizational issues such as norms, obligations, prohibition, permissions, power relation, 1608 1608 - delegations of tasks, responsibility, and trust 1608 1608 + \item Multi-agent level 1609 1609 + \begin{itemize} 1610 1610 + \item allow the implementation of social and organizational issues such as norms, obligations, prohibition, permissions, power relation, delegations of tasks, responsibility, and trust 1611 1611 + \end{itemize} 1609 1612 1610 1610 - \item Individual agent level: to allow the implementation of various goals types such as perform, achieve and maintenance goals. 1613 1613 + \item Individual agent level 1614 1614 + \begin{itemize} 1615 1615 + \item implementation of various goals types such as perform, achieve and maintenance goals 1616 1616 + \item enable the specification of conflicting goals 1617 1617 + \item implementation of various commitment strategies such as blindly-minded, single-minded, and open-minded through intentions 1618 1618 + \end{itemize} 1611 1619 1612 1620 \end{itemize} 1613 1621 % \item Extending the 2APL platform with (visual) debugging tools that allow