An Argumentation-Based BDI Personal Assistant

An Argumentation-Based BDI Personal Assistant Federico Schlesinger, Edgardo Ferretti, Marcelo Errecalde, and Guillermo Aguirre Laboratorio de Investigaci´on y Desarrollo en Inteligencia Computacional Universidad Nacional de San Luis. San Luis, Argentina [email protected], {ferretti,merreca,gaguirre}@unsl.edu.ar

Abstract. BDI models and argumentation-based approaches are powerful tools that can play a fundamental role in implementing intelligent systems for complex business and industrial problems. Some recent works have started studying the integration of both approaches from a theoretical point of view. However, little effort has been made to analize how these technologies can be effectively integrated in complex systems which require the use of well-known development resources, such as agent development platforms and other programming tools. This work addresses that problem, showing how an argumentation-based reasoning service can be used in different components of a BDI agent implemented with a Jadex platform. All the concepts involved in our proposal are exemplified by designing and implementing a travel assistant agent that allows to observe how BDI and argumentation approaches can be effectively integrated in a working system developed with freely available technologies.

1 Introduction Belief-Desire-Intention (BDI) models and argumentation processes are central concepts in human intelligence, which have gained considerable attention as powerful tools to build artificial intelligent systems. On one hand, BDI is considered as one of the most influential practical reasoning architectures, i.e., an architecture to decide what action (or actions) should be carried out. On the other hand, argumentation is a major component of Artificial Intelligence [1] and supports non-monotonic reasoning, providing rationally justifiable conclusions when the problem involves incomplete and potentially inconsistent information. Both techniques have very solid theoretical foundations [2,3] but their use is not only restricted to the academic area. Recent works have shown the potentials of these technologies to deal with very complex business and industrial problems [4,5]. Likewise, different studies [6,7,8] have recognized the benefits that an integration of BDI and argumentation models could provide, but they tend to focuss on formal aspects of the problem using very specific formal frameworks. Therefore, it is not always straight to understand how these proposals could be implemented in complex practical systems which require the use of more accepted technologies and development tools. In this work, this problem is addressed by providing a framework and a personal assistant based on this framework, where the integration of both technologies can be easily understood and directly implemented. Other objectives of this work are: (a) the framework should be generic enough to introduce, with little effort, modifications and new N. Garc´ıa-Pedrajas et al. (Eds.): IEA/AIE 2010, Part I, LNAI 6096, pp. 701–710, 2010. c Springer-Verlag Berlin Heidelberg 2010

702

F. Schlesinger et al.

implementations of its different processes and components; (b) the framework should provide an adequate support to easily integrate different argumentation and BDI technologies as well as other essential development resources like agent platforms and programming tools and (c) higher priority should be given to freely available technologies. In [9], the WADEX (Web services, Argumentation and (BDI) Jadex) generic framework was proposed to provide support to integrate argumentation-based inference and web service technologies into the design of a BDI system. The present work complements and extends that proposal by focusing on the use of argumentation in two of the three main processes of the WADEX framework: the acceptability filter and the selection process. The feasibility of our proposal is shown by designing and implementing a travel assistant (TA) agent intended to help a human user that wants to go on a trip on a weekend to an undetermined destination in USA. The rest of the paper is organized as follows. Section 2 briefly introduces Defeasible Logic Programming, the language used for knowledge and preferences representation. In Sect. 3 the extended WADEX framework is proposed to integrate argumentation and decision rules in the framework’s decision component. Then, an example showing a concrete application of the extended framework is explained in Sect. 4. Finally, in Sect. 5 some general conclusions are drawn and possible future work is discussed.

2 Knowledge and Preferences Representation Language This section briefly describes Defeasible Logic Programming (DeLP) [10], the concrete formalism used as knowledge and preferences representation language. A DeLPprogram, denoted (Π , Δ ), consists of two sets: Π , the set of facts and strict rules (certain information) and Δ , the set of defeasible rules (uncertain information). Facts are ground literals representing atomic information. Strict rules are denoted L0 ← L1 , . . . , Ln and represent firm information, whereas defeasible rules are denoted L0 —< L1 , . . . , Ln and represent tentative information. In both cases, the head L0 is a literal and the body {Li }i>0 is a set of literals. Strong negation (“∼”) is allowed in the head of program rules, and hence may be used to represent contradictory knowledge. In DeLP, to deal with contradictory and dynamic information, arguments for conflicting pieces of information are built and then compared to decide which one prevails. An argument for a literal L, denoted A , L, is a minimal set of defeasible rules A ⊆Δ , such that A ∪ Π is non-contradictory and there is a derivation for L from A ∪ Π . To establish if A , L is a non-defeated argument, argument rebuttals or counter-arguments that could be defeaters for A , L are considered, i.e., counter-arguments that by some criterion are preferred to A , L. Since counter-arguments are arguments, defeaters for them may exist, and defeaters for these defeaters, and so on. Thus, a sequence of arguments called argumentation line is constructed, where each argument defeats its predecessor in the line (for a detailed explanation of this dialectical process see [10]). The prevailing argument provides a warrant for the information it supports. A literal L is warranted from (Π , Δ ) if a non-defeated argument A supporting L exists. Given a query Q there are four possible answers: YES, if Q is warranted; NO, if the complement of Q is warranted; UNDECIDED, if neither Q nor its complement are warranted; and

An Argumentation-Based BDI Personal Assistant

703

UNKNOWN, if Q is not in the language of the program. In DeLP, generalized specificity1

is used as default criterion to compare conflicting arguments, but an advantageous feature of DeLP is that the comparison criterion among arguments can be replaced in a modular way. Therefore, in this work, we also use a criterion based on priorities among literals.2 As implementation of the DeLP formalism, our work uses a DeLP-Server [11]; a Prolog implementation of a DeLP interpreter that provides a reasoning service for a group of agents. This service runs as an stand-alone program that can interact with the agents using the TCP/IP protocol. A query for a DeLP-Server is a pair [C, Q], where Q is the literal that DeLP will try to warrant and C is the context for that query. The context C of a query can be any DeLP-program.

3 The WADEX Framework The WADEX framework [9] conceptually consists of: (a) an integration archictecture which describes how the software components implementing these models interact, and (b) a general control structure that provides some general guidelines about how the main steps involved in a particular application can be programmed. The integration architecture is depicted in Fig. 1, where the agent platform and the communication channels between the different elements involved are shown. Most of the application logic is encapsulated in a Jadex agent, following its BDI model. This agent runs on top of a deployed JADE platform. There are other agents also running on the same JADE platform, which can be of diverse nature and can communicate through messages with the main Jadex agent, since Jadex provides facilities for sending and receiving messages from plans, whether in a synchronous or asynchronous way. A JADE agent with special characteristics is the Web Services Integration Gateway (WSIG) agent, which allows to extend these advantages of messaging to the use of invoking web services as well. A web service invocation process starts with a lookup for the service in the Directory Facilitator (DF), a JADE special agent implementing the yellow pages service (i.e., it allows agents in the platform to publish/retrieve descriptions of services that other agents are willing to consume/provide). Once the service has been located, the agent formats a request message in the body of a plan and sends it. Information obtained from the web service invocation can be stored in the agent’s belief base. Moreover, our Jadex agent can make queries to a DeLP-Server. The DeLP-Server runs a DeLP program containing part of the facts and decision logic that are supposed to be static. The possibility of including contextual information in the queries allows to have a piece of the DeLP program in the Jadex agent and / or dynamically generate it (or a part of it). In this case, queries are directly made from the executing code of the Jadex agent sending queries (via sockets) to the DeLP-Server, and receiving responses in the same plan without any agent messages involved.3 1 2 3

It prefers an argument with either greater information content or with less use of rules. It prefers an argument built from rules that contain the highest priority literals. An alternative implementation, e.g., with a JADE agent acting as interface, could have been easily implemented.

704


Fig. 1. The integration architecture

As the general application logic is controlled by a (BDI) Jadex agent which acts as initiator of all the interactions requiring distinct web services and inference processes, is important to analyze the steps involved in the WADEX’s general control structure shown in Fig. 2. It consists of a main cycle with three generic processes: the acceptability filter (acc- f ilt), the selection process (select), and the execution stage (exec). The acceptability filter, is the process which considers the whole set of available alternatives and discards those that do not satisfy essential requirements to be considered acceptable options. The selection process takes as input the options that survive the acceptability filter and compares them in order to decide which alternative will be selected. Three approaches can be used to face this issue: (a) to simply delegate this responsibility to the user, (b) making decision in an automatic way, or (c) using an hybrid approach mixing manual and automatic decisions. This latter approach is the one used in this work. Finally, the execution stage involves deciding how to accomplish the selected option and executing this plan to achieve the desired goals. At present, this stage involves to select and execute plans from a library of pre-compiled plans, following the standard approach adopted in most PRS-based BDI systems. Let A be the set of available alternatives Let O be the set of acceptable options Let o be the selected option While true do 1. O ← acc- f ilt(A ) 2. o ← select(O) 3. execute(o) endWhile Fig. 2. Control structure of a WADEX agent

For example, given the application domain sketched in the introductory section, the TA agent’s first task is helping to the user to decide his destination. Once the destination has been decided, it will make all the necessary steps to carry out the trip (i.e., buy tickets, make reservations, etc.). In this way, each one of the above-mentioned stages will be represented by a Jadex goal and thus will have at least one associated plan. The plan for calculating the acceptable options takes each potential destination and sets up a sub-goal for calculating its acceptability. Checking acceptability for a single


705

city involves using a web service to obtain its weather forecast and consulting a DeLPprogram, as it will be explained in Sect. 3.1. The candidate cities are stored in the agent’s belief base, in the form of Java objects containing the city name, its coordinates and an associated hash table to store the weather-related information of that city. A default set of cities is specified in the agent’s definition but more cities can be dynamically added. When the set of acceptable alternatives has been determined, an argumentation-based decision process compares the acceptable alternatives among each other, as described in Sect. 3.2. Both processes, filtering acceptable cities and comparing among acceptable cities to select one, have to reflect the user’s restrictions and preferences. These are captured through an screen with options that is presented to the user when the agent is loaded, and then translated into two DeLP programs that are saved into two different files. After the files generation, the agent starts two DeLP-Server instances, one loaded with each program. These DeLP-programs will be discussed later in Sect. 4. The necessary steps to travel to the selected city can depend on many factors. Our approach consists of having a set of plans with different courses of action to achieve this goal, and use meta-level reasoning to choose the most adequate. A central aspect of BDI architectures is the possibility of reconsidering intentions. In our example, it is assumed that once the agent has selected a city, the necessary steps for traveling to that city take a considerable amount of time, during which some conditions might change and make the agent discard the selected city and choose a different one. We consider here two possible situations: – The selected city ceases to be an acceptable option. – A new option arrives and is considered to be a better option than the current one. The first case could happen if for example the weather forecast changes. When a change is detected, the agent issues a sub-goal to recheck the acceptability of that city. If the city has turned unacceptable, the goal to perform the necessary steps to travel to the selected city must be dropped, and the main plan has to start over, recheck acceptability for all the cities and select a new one. The second situation might arise for example, if the agent receives information of a sale in flight tickets for a given destination different from the chosen one. In this case, the next step would be to issue a goal to check the acceptability of the new option. If the new option is acceptable, the agent issues the goal to select a city from a set of acceptable cities, but this time only the currently selected option and the new one are passed as parameters to the goal, to select among these two. If the new option is chosen over the current one, the goal for performing steps to travel to the selected city must be dropped. The main plan has to be repeated, but this time there is no need to check acceptability for the other cities and selecting one, as the selected city will now be the newly arrived option. So the main plan now begins from the moment of starting to carry out the trip (i.e., the third abstract step). This behavior can be easily implemented in Jadex. First, a belief in the belief base, called selected city is available, and stores the city that has been selected. Jadex allows the use of a drop condition in goals (i.e., a condition that tells the system to discard the goal when it holds true). We specify a drop condition for the goal of performing the steps to travel, stating that the goal must be dropped when the city passed as a parameter differs from the one stored in selected city. In case of a situation where the selected option ceases to be acceptable, selected city is set to null. In

706


case of a new option that is determined to be better over the current one, the new city is set in the selected city belief. In both cases the goal to travel is dropped. The three abstract steps in the main plan are inside a loop that is interrupted when the goal to prepare the trip successfully finishes. If that goal fails (e.g., because it is dropped), the loop starts over. The first two steps (calculating acceptable options and selecting one) are only performed when the value of the selected city belief is null; otherwise, they are skipped, and the main plan issues a sub-goal to perform the necessary steps to travel to the city stored in the selected city belief. 3.1 Filtering Acceptable Cities At present, the process which considers the whole set of cities and discards those that do not satisfy essential requirements to be acceptable options, only uses a web service to obtain its weather forecast. The web service invoked by our application corresponds to the National Weather Service of the United States’ National Oceanic and Atmospheric Administration (http://www.nws.noaa.gov/forecasts/xml/). This web service is relatively straightforward to use (e.g., invocations are not context-dependant), and provides extensive information in a well structured manner. Among the set of functions available from this service, we only make use of the one called NDFDgen, which receives as parameters two real numbers representing latitude and longitude of the geographical point, two dates stating the period of time for which the forecast is required, and a series of weather parameters indicating the required information. We only request the most common weather parameters, such as minimum and maximum temperature, probability of rain, etc. The agent has a goal that states the need of weather forecast information for a city (given as a parameter to the goal). When the service has been located, the plan sets up the request for the web service, taking the latitude and longitude from the parameter, and sends it to the Gateway Agent. After getting forecast information from the web service, the argumentation process takes place to determine the acceptability of a city. Our application relies on a DeLP program that runs in an instance of a DeLP-Server, and encapsulates the logic to decide whether a city is an acceptable option or not. As will be shown in Sect. 4, the acceptability of a city x in our DeLP program, will be given by a warranted argument supporting the conclusion acc(x). 3.2 City Selection After determining the set of acceptable alternatives, the next step in the agent’s control cycle is to select the destination city. At this stage, a device called decision rule [12] is used to perform the decision process. O

A decision rule is denoted (D ⇐ P, not T ), where P contains literals representing preconditions, T contains literals representing constraints, O represents the set of acceptable options, and D denotes those alternatives that this rule will decide to adopt from O. Decision rules rely on an argumentation formalism (DeLP in this case) to make them applicable. Given a DeLP-program KB representing the agent’s knowledge base,


707

O

a rule (D ⇐ P, not T ) is applicable with respect to KB, if every precondition pi ∈ P is warranted from KB and every constraint t j ∈ T fails to be warranted from KB. In Sect. 4 it will be exemplified how argumentation is used in the acceptability filter and in the selection process, with two different aims. In the former case, argumentation provides reasons in favor or against an alternative to determine if it is acceptable depending on its own properties, while in the latter a pair of alternatives is compared among each other to select one of them, depending on their properties.

4 Application Domain: Travel Assistant Agent Let us suppose that John (our tourist) is in New York, and the weekend of November 12th wants to visit another city of USA. New york is the only city he has visited, and he has no particular preference for visiting any other specific city. Since he is leaving USA on November 14th from JFK airport, he has only two days to travel. This fact, maybe a reason for considering only New York’s nearby cities. Besides, John has no much extra money to spend in expensive flight tickets; therefore, if there is an offer of a cheap flight for a distant city, this might change his mind about travelling only to nearby cities. John is not a hard-to-please person, but as he has little time for travelling he really wants to visit a place with nice weather to be able of visiting as much as possible from that place. As discussed in Sect. 3, this situation could be modeled by two DeLP-programs. Figure 3(a) shows an excerption of the DeLP-program used to determine the acceptability of the cities, while Fig. 3(b) presents the DeLP-program which states John’s preferences. In Fig. 3(a), rules (1) and (2) are defeasible rules stating that, by default, a city is acceptable if it is a nearby city, and is not recommendable if it is distant. Rules (3)−(5) exemplify more complex considerations: a distant city can be acceptable if there is a cheap flight to that city, but a city with bad weather is not acceptable, whether it is a nearby or a distant city with a cheap flight to it. The definition of what constitutes a nearby or a distant city is given by rules (6) and (7) (in this case, the limit was fixed to 500 Km). Next, rules (8)−(12) define the predicate bad weather, exemplifying a way in which the agent could deal with partial and potentially contradictory information. Bad weather is first defined in terms of the forecast (information obtained from the web service) using strict rules. However, forecast information might not be available for some reason, like the date for the trip being very distant from the current date. The last two rules in the extract define bad weather in terms of climate: for example, one might suppose that there is a high probability of very low temperatures in Boston during winter, or that Miami usually has good weather. These last rules are defeasible, because forecast information could contradict them (e.g., the forecast could announce a tropical storm heading to Miami). Figure 3(b) shows a DeLP-program representing the preferences expressed by John from the interaction with the screen with options (discussed in Sect. 3).4 As it can be observed, there are six defeasible rules, two for each comparison literal: nearer city, 4

For further details about how this translation is perfomed and its related properties from a classical decision theory point of view, please refer to [12].

708


[...] (1) acc(X) -< nearby city(X). (2) ∼acc(X) -< distant city(X). (3) acc(X) -< distant city(X), travel date(Y), origin city(Z), cheap flight(Z,X,Y). (4) ∼acc(X) -< nearby city(X), travel date(Y), bad weather(X,Y). (5) ∼acc(X) -< distant city(X), travel date(Y), origin city(Z), cheap flight(Z,X,Y), bad weather(X,Y). [...] (6) nearby city(X)