A Multiagent Approach for Electronic Travel Planning - CiteSeerX

A Multiagent Approach for Electronic Travel Planning David Camacho

José Manuel Molina

Daniel Borrajo

Universidad Carlos III de Madrid Avda. de la Universidad 30, 28911 Leganés (Madrid) Telf: 91-6249416 E-mail: [email protected]



Abstract In the last years, the amount of information stored in Internet has grown exponentially. This article presents a new approach to cooperative problem solving that use the Web as a source of data. The architecture has been designed using two main Artificial Intelligence techniques: Multiagent System design, and problem solving (planning). Both are used to obtain a new architecture that dynamically obtains knowledge from Internet. The system uses two different types of agents: planning agents and web agents. Planning agents pay attention to the user’s queries and solve his/her problems at a high level of abstraction; web agents fill in the details obtaining the required information from Internet. Different partial solutions given by the web agents while combined by the planning agent to obtain a detailed solution (or solutions) to the user queries.

Keywords Multiagent Systems, Planning, Agent Architecture Modeling, Software Agents, Information Systems.

1.- INTRODUCTION In the last ten years the amount of the information stored in Internet, especially in the World Wide Web (WWW, Web), has grown exponentially. This vast amount of information is available for any user connected to the network. This situation has originated several problems, one of the most important one is how a user could use this information to obtain satisfactory results in problem solving. Actually, there are many systems that extract, filter and represent efficiently the information obtained from the Web. However, most of those systems are focused, mainly, on the amount of the information to be retrieved (Etzioni 1997). This paper presents a distributed multiagent system that obtains data from the Web. In order to design the multiagent system, we used Distributed Artificial Intelligence (DAI) techniques (Gasser 1992). Usually this field has been studying and designing systems that are able to interact with some other systems and with the world. In our case, the system uses the Web as a testing field where it is possible to experiment with difficult and complex situations. DAI considers that a problem can be solved simultaneously by several subsystems (agents). Integrating

and coordinating those different agents (including the human) is a complex problem (Gasser 1992), (Sycara 1998). This paper presents a distributed and cooperative Multiagent approach to problem solving in a dynamic environment (Web), applied to the electronic-tourism domain. The approach integrates traditional problem solving techniques, like planning, with the advantages that provide distributed systems, like Multiagent Systems (MAS). The system is designed to work with dynamic information, especially with information that could be stored in Internet. This paper analyzes what kind of information characteristics is necessary to use this information for problem solving. The main characteristics of the domain for our purposes are: the vast amount of data, and the time that the information is valid, given that the information stored in the Web could change over time. The designed MAS use the Web as the main source of data, but it could use any other type of information sources (like a database). This paper is divided into five sections: section 2 describes the Multiagent Systems main characteristics; section 3 defines the proposed Multiagent System; section 4 presents an application example over the Web using the designed architecture; and finally, section 5 shows the conclusions of the paper.

2.- MULTIAGENT SYSTEMS IN THE WEB We have decided to use MAS techniques because this type of systems is very flexible and highly adaptive. These characteristics are due to several reasons: the systems are made by several and heterogeneous elements; these elements (agents) can be programmed in several languages like LISP, Prolog, C, C++, JAVA, etc.; they could execute different functions; and they can modify its behaviour dynamically. The MAS use wrapping techniques (Ashish and Knoblock 1997) that allow adding a subsystem programmed in any language, and performing a particular task, to the whole system. The wrapper adds the characteristics that an agent should have (especially, the ability of receiving and sending queries to other agents). It is possible to include

some subsystems and programs (as described on (Wilkins and Myers 1998)) that originally were implemented on LISP or C, in only one day in a MAS. We use wrapping technique to add classical planning systems like Prodigy4.0 (Veloso et al. 1995) into a Multiagent System. The ability to include different software applications (or complex systems) into a MAS does not guarantee that this kind of new systems can achieve good results. Therefore, we need to emphasize another MAS characteristic: these kinds of systems provide methodologies to integrate distributed control algorithms and problem solving techniques into the system. Therefore, it is possible to design systems that cooperate to reach the desired goal (problem solution). Any MAS uses the agent concept. In (Brenner and Zarnekow and Wittig 1998) there exists a complete description about its principal characteristics. We could summarize them as follows: · · · ·

Each agent has an incomplete amount of information or does not have the accurate abilities to solve the whole problem. It does not exist a system global control. Data is not centralized, so all agents must share data. System execution is asynchronous; any agent can be working while it receives queries anytime.

MAS are successful due to several causes (we only mention those more relevant): · · · ·

They are able to solve big size problems, especially those where classical systems are not successful. They allow different systems to work interconnected and cooperate. They provide efficient solutions where information is distributed among different places. They allow software reusability, therefore its more flexibility to adopt different agent capabilities to solve problems.

In Fig.1 a graphic representation of a generic MAS is shown. In this representation, there is sets of agents that can communicate and cooperate among them to reach the problem solution are depicted.

Query User 2

Agent

Query User 1

World Wide Web

Agent

Data Base

Query User 3

Agent

Fig 1 General MAS structure. During the last years, people have developed a set of systems with several agents that try to solve a particular problem. To reach the goal efficiently, they use different techniques; such as competition (where the agents fight for the system resources); or cooperation (where the agents cooperate to reach the solution) (Barr and Cohen and Feigengaum 1989), (Ackerman et al. 1997). Some popular approaches used in the Web have been softbots and spiders (Etzioni 1997), and systems that are able to collect and filter the data that the Web offers. These systems named search engines or search meta-engines, have been very successful in the last years, because they allow a user to easily obtain useful information from the Web (Kautz and Selman and Shah 1997) Another approach, SIMS (Arens et al. 1996) is an implementation of a kind of systems (named Mediators) that try to integrate heterogeneous information sources to manipulate those data to reach new solutions. Other systems, like ARIADNE (Knoblock et al. 1998), try to obtain heterogeneous knowledge (acquired from different sources) to apply to a planning process (Ambite and Knoblock 1997).

3.- A Multiagent Architecture for Problem Solving in the Web Most of the MAS that work on the Web are basically software applications, that apply more or less complex filters over the answers obtained from the Web searchers (Etzioni 1997), or systems that believe the information is homogeneous and static (Wilkins and Myers 1998). Most of these systems have been focused on how to obtain information, more than its possible reusability. In the present work, we pretend to design multiagent architecture oriented to concurrent and cooperative

problem solving. We have chosen the Web as the working field because it is a very dynamic domain in several aspects: · · ·

The number of nodes (or links) is constantly growing, and new links can provide useful information to solve new problems. Older links may not be accessible in a period of time, or even have disappeared. The information given by a link can be modified in its structure or contents.

obtain new solutions without planning or accessing the 1 Web to search for this information . Another important characteristic of the planning agent is the ability to characterize the user. This ability provides customized answers to the user. The system will reach this objective creating different users profiles. The system characterizes the user in two ways. First, asking to the user to fill a Form (that defines an initial user profile). And second, automatically characterizing the user, by learning from his/her previous queries and his/her answers given to the system when a solution (or solutions) is provided.

3.1.- General Structure of the Architecture In Fig.2 a graphic description of the architecture is shown. The architecture has two kinds of agents: Planning agents and Web agents. Planning agents deal with user problems. The Web agents obtain useful information from the Web. The information is sent to the planning agents that could use it to solve problems. As Fig.2 shows, the planning agents can communicate among them or with the Web agents. The only way for a planning agent to access to Web stored information is through Web agents. The main task for the planning agents is to give answers to possible agents queries and to possible users queries. Therefore, they should simultaneously solve their own problems and try to help (cooperate) with other agents to solve the queries that they could receive. Dot arrows refer to the ability that Web agents have to connect directly to information sources like the Web. Continuous arrows indicate how the different agents will communicate using a protocol.

3.2.- Searching for Knowledge to Solve Problems It is possible to consider three different information sources where an agent could acquire knowledge for problem solving: ·

Query User 2

· Planning Agent

Query User 1

Web Agent

World Wide Web

Planning Agent

Web Agent

Data Base

·

Fig.2 MAS architecture This architecture includes most of the characteristics described on section 2, although some of them have been relaxed to pay more attention to some other aspects (like reasoning capability and cooperation). Planning agents could cooperate, sharing plans and detailed information to

One information can be acquired from another agent by posting questions or queries. Queries can be requested to all the agents or to a particular agent (if its ability {skill} to solve that specific kind of problems is known). A similar protocol to KQML (Knowledge and Query Manipulation Lenguage) (Finin et al. 1993) is used for the queries request/answer, because it provides a general frame for MAS communication and cooperation. KQML provides a set of protocols for: messages identification, connection establishment and interchange between agents. Thanks to those protocols the user can request a problem to be solved, and obtain a complete answer to the request sent (initially, and by simplicity, the queries are sent to all the agents on the system). The second information source is the agent itself. Each agent will try to reuse its own experience learned in previous cases, using reasoning techniques like Case-Base Reasoning (CBR) (Aamodt and Plaza 1994), (Veloso 1994). In the first approach, the system stores the complete solutions, although it is obvious that it will be necessary an accurate analysis to find out what parts of the solutions are really important. The third type of information source, is the Web. Many problems appear when any system tries to use Internet as a data source. Following are listed some of those problems:

q q

1

Management of the vast amount of information accessible in the Web. Information source characterization and/or structure. As it has been described in (Ashish and Knoblock 1997), most of the Internet data

Nowadays Planning agents shared detailed information or complete solutions, sharing parts of a plan is future work for us.

q

q

sources are usually loosely structured. The data structure consists on forms that must be filled by the user, and the results of the query are heterogeneous information. Filter properly the result information and obtain a useful representation for the agents.

It is possible to find systems that work with these information sources for building brokers for heterogeneous information sources integration (Knoblock et al. 1998), and Wrappers to make accessible the structured and semistructured information.

3.3.- Planning Agent Architecture The planning agent has a modular architecture, where each module has its owns capabailities and tasks.

· ·

Handle the partial solutions; they should be validated using the information acquired from other agents, or from other heterogeneous information sources. q Build an agenda that allows handling the questions asked by other agents and its own task. q Handle all possible answers given to questions asked by other agents/users. q Modify its behaviour in order to obtain different solutions, best solutions for user need, first solution obtained (minimize computation time), cheap (cost) solutions, etc. Learning modules. They can modify the system behaviour if the obtained solutions are successful to the user queries. Planning module. Works to solve the user problem. Because of its importance, the next section explains its details.

Planning Module. Planning agents use a planner as the main reasoning module (this work uses a non lineal planner: PRODIGY 4.0 (Veloso et al. 1995). The planner has been used to analize the problem, and obtain a very abstract solution description of the problem. In fact, it is possible to obtain multiple problem solutions from the planner. It is also possible to order those generic solutions according to some heuristics or cost functions. Fig.4 shows a graphical planning module description. The figure only shows the inputs/outputs that PRODIGY needs to work. Fig. 3 Planning agent architecture

Goal Operators

Some of its most interesting characteristics are: ·

· · ·

· ·

User Profile module. It allows customizing the user queries. With both the query and the user information, it is possible to provide a customized solution to the user. Internet automatic access. Allows achieving comunication with the Web agents. Communication with other planning agents. Implements the protocol communication among the planning agents. Storage of useful data (heterogeneous information). Store useful solutions for future queries as well as different user information or other agents characteristics. Plan server. It provides an old plan or subplan (stored by a plan agent, or sended by other agents) to find out a new solution. A control module, to manage the different agent modules. The following are some of the main functions that this module must perform:

Initial State

PLANNER

Solutions

(Prodigy 4.0)

Quality Function

Fig.4 Planning module Fig. 5 shows how PRODIGY has solved the problem consisting of a travel that a user wishes to do. The user departure is from a train station in a generic town (trst0) and his/her goal is to arrive to another train station in a different town (trst2). Let’s he/she assumes train2 was placed in train station trst2. The idea is to define a generic domain, that consists of a set of operators (transformations between states) that the planner uses to solve the problem, and an initial state describing the user starting point for a travel and a goal that describes where s/he wants to go. Once the generic problem has been solved, the control module takes (in order) those solutions (or solution if there is only one) and tries to validate some or all the possible solutions.

1.-Solution: 2.-Solution:

3.4- WEB Agents A Web agent handles questions from other agents (control module), and properly translates the questions into queries to access the Web (filter module). Answers from the Web will be filtered and stored in a database. This useful information will be sent later to planning agents. It is necessary for a module to store all the possible answers (DataBase module) until the agent can reply to the agent who needs the information. Web agents know several places to look for the requested information. Fig.7 shows a Web agent modular description.

Fig. 5 PRODIGY possible solutions to a given generic problem.

Agents Queries

A general solution can be divided into a set of subproblems. For instance, Fig. 6 shows two operators (given as a part of the planner solution), that will be translated into queries or goals to be reached by the agent. In this example, it is necessary to know if there exists a train connection between town0 and town2 (for the first operator), or if there exists a flight between both towns for the second operator. The agent could obtain that information from the Web (web agents), from other agents (planning agents), or from its own experience.

Fig. 6 Operators that will be translated into queries. Other authors build agents (or systems) that are able to interleave planning with execution of actions (Paolucci and Shehory and Sycara 2000). This ability is used to construct shared plans with other agents and to manage the negotiation process, or is used to extend classical planner representations and algorithms to deal with incomplete information, like in XII planner (Golden and Etzioni and Weld 1996), (Golden and Weld 1996). We follow a different approach using the abstraction to obtain a general plan. The planner can concentrate on the harder problems first, ignoring details, and when a set of solutions are founded can add the needed detail information (retrieved from the Web) to the general plan. We avoid the waste of resources because it doesn’t necessary make backtracking over execution when the detailed information it not unreachable to complete a particular plan, simply the plan (or plans) that need that information are refused.

Answers Web Agent

As it is shown in fig.5, the planner provides a solution using its own language. It is then necessary to transform this information for other agent modules (or perhaps the user) to be able to work with the planner solutions.

Control Module

Filter Web

Filter Web

Queries

DataBase from We b

Answers

Internet / Web

Fig. 7 Web Agent In the travel domain on the Web, requests will relate to flights, trains, or bus information, between two towns, or information about hotels in a particular town. Requests from the agents will be translated into understandable queries for Web sites.

4.- TRAVEL PLANNING IN THE WEB This section provides a detailed description of the domain representation, and an example of how the system works.

4.1.- Electronic Travel Planning An electronic travel agent must have the ability to manage a travel planning. In this kind of domain, the planning agent needs to represent several towns, transport staff, lodging places, etc. And the agent needs known how the user could travel between towns, airports, train stations, rent a car, or book a room in a hotel. Fig.8 shows the graphical representation of an example in this domain, where a user uses different travel transports and hotels to reach his/her desired goal.

T own_1

4.2.- Problem Description from a Planning Perspective

Hotel

Train Station

Airport

Hotel

Hotel

Train Station

Train Station

Airport

Airport

T own_2

T own_0

From the classical planning point of view, the previous problem could be described as a search in a state space. The system uses the planner to obtain a generic solution of the problem. The planner needs a set of operators to do all the possible user operations. Some of the operators to consider are: ·

Hotel

Train Station

Airport

·

T own_3

Fig. 8 Graphical description of the domain.

· ·

Travel in a town, using different local transport. Those operators usually will work according to the known information, which is more or less static (buses and subway maps, prices, etc.) Travel between different cities; we consider that this kind of information must be traduced. Book a hotel at town destination. Car rental reservation at town destination.

The most important points in the management of travel are: 1. Moving from the origin to the destination town. 2. Lodging at destination. 3. Transport posibility at target town. 4. Returning to initial (or other) town.

Each problem to solve is described by (see Fig. 4): an initial state that describes the user needs, like for example: source/target cities travel preferences, lodging preferences, etc. The planner will try to find a solution (plan), which provides to the user the information on how to setup the travel.

To handle item 1, so far we have considered the airplane as the main travel transport. It is very easy to generalizate it to other transports like trains, or buses by adding operators to the problem domain. Also, the user may need to take a local train, bus or taxi to move to the airport. This means that the agent needs to decide which local transport to use. This is an important and complex part of the problem because the number of possible solutions grows exponentially.

As Fig. 5 shows, the planner can help to find a set of solutions to the problem. Those solutions would be given in an abstract plan. The representation for an abstract plan that the system can use (Carbonel et al. 1992), does not have the details of the plan. It only contains the set of high level steps necessary to travel successfuly. Each of the possible solutions (abstract plans) must be validated using the information provided by the other sources. Each valid solution is stored and is available for the user to be evaluated.

Another important issue is that there are many different solutions to a problem, and all of them can be ordered according to several parameters. For example, the solutions could be ordered according to cost, amount of time to complete the travel, or user preferences (for example, if a customer decides not to travel by plane). The moving possibility around the target town refers to the possibility of renting a car, or to provide to the user information about public transport (bus, subway). The system may be able to reason without all the information, because many times not all the information is accessible, or part of the necessary information fails. That situation should not stop the problem solving task and should try to look for alternative solutions.

4.3.- Example of Application over Web Let’s assume that possible cities are [Madrid, London, Atlanta], and the user wishes to travel to Atlanta. The user starts the travel from Atocha train station (in Madrid), and the travel problem consists on planning travel to "Sheraton Inn Atlanta Airport" in Atlanta. The lodging will be for four days, and then, the user wants to come back to Chamartín train station (also in Madrid). The initial problem given by the user interface to the planner consists of an initial state, and a goal description. Fig. 9 shows an abstract specification of the problem.

;; Initial State= three towns ;; carrier = train, airplane (only one) ;; local carrier = bus ;; person = one (setf (current-problem) (create-problem (name agents2000) (objects (person person) (city0 city) (city1 city) (city2 city) (airport0 airport) (airport1 airport) (airport2 airport) (airplane0 airplane) (trst0 trainstation) (trst1 trainstation) (trst2 trainstation) (train0 train) (train1 train) (train2 train) (bus0 bus)) (state(and ;; Town0 (Madrid) (loc-at airport0 city0) (loc-at trst0 city0) ;Atocha (loc-at trst2 city0) ;Chamartin (at-train train0 trst0) (at-train train2 trst2) (at-airport bus0 airport0) (at-airport airplane0 airport0) ;; Town1 (London) (loc-at airport1 city1) (loc-at trst1 city1) ;; Town2 (Atlanta) (loc-at airport2 city2) at-train person trst0))) (goal (at-airport person airport2))))

Fig. 9 Abstract representation of a part of the given problem. Fig. 10 shows one of the possible abstract solutions given by the planner. Solution:

Fig. 10 PRODIGY solution to the given problem

Note here that there is no relation to Madrid or Atlanta, the cities have been translated to constants. With this solution, the agent selects the operators that must be translated to queries (to the Web or to some other agents). In this example, Fig. 11 shows these operators.

Fig.11 Operators in bold face need information stored in the Web. The first and second operators need local information to validate the plan. The agent should consult a Web agent whether there exists a bus to connect the train station with the departure airport or not. That information can be given to the user by telling, both the bus route and the bus schedule. On the other side, the third operator indicates that it is necessary to fly between both cities (Madrid, Atlanta). That information will have to be checked on line by the agent to other planning agents (in case they have solved the problem in the past), or with Web agents that can request the information about this flight to air companies that have the information in the Web. The operators must be validated to obtain a correct solution. Once all the operators have been validated, the user can have the complete detailed plan to travel. If a given solution is not the most adequate for the user, he/she might continue working on any other alternative solution give by the planner (if they exist). Fig. 12 shows how a Web agent translates the operator: into a query that is sent to different flight companies. Fig.13 shows the answer from one of the companies. The information is given back by the flight company in a HTML page. Then, the Web agent filters this page and stores the information on a database to that the rest of agents can access. Query = citydep=MADMadrid & cityarriv=ATLAtlanta & daydep=29 & monthdep=March & dayret = 2 & monthret = April

Fig. 12 Query to flight company.

A.Barr, P.R.Cohen, E.A.Feigenbaum. “The handbook of A.I.: Cooperative distributed problem solving”. Chapter 17, pages 84-147, ed. Addison-Wesley, 1989. W.Brenner, R.Zarnekow, H.Wittig. “Intelligent Software Agents. Foundations and Applications“. Springer-Verlag, 1998. ISBN: 3-540-63411-8. J.Carbonell et al. “Prodigy4.0: the manual and tutorial”. Carnegie Mellon, Computer Sciencies, 1992, Technical Report. CMU-CS-92-150. O.Etzioni. “Moving Up the Infomation Food Chain”. In AI Magazine, volume 18, nº 2, pages 11-18, summer 1997. Fig.13 Flight company answer.

T. Finin, J.Weber, et al. "Draft specification of the KQML agent communication language". June 15, 1993.

5.- CONCLUSIONS

L. Gasser. “An Overview of DAI. Distributed Artificial Intelligence: Theory and Praxis”. Kluwer Academic Publishers. 1992.

We have presented a multiagent approach to electronic travel planning, with planner agents and web agents that solve problems into a dynamic environment. The motivation for this work is to design a system that can work with dynamic information and study how this data affects the planning process. We also study how problem solving cooperative techniques can be used with a vast amount of data. We show a Web system application example, using data automatically obtained by the system to solve the problem.

6.- REFERENCES “Case-Based Reasoning: A.Aamodt, E.Plaza. Foundational Issues, Methodological Varations, and System Approaches”. AICom-Artificial Intelligence Communications, IOS Press, Vol.7, pages 39-59, 1994. M. Ackerman, D. Billsus, S. Gaffney, S. Hettich, G. Khoo, D.J. Kim, R. Klefstad, C. Lowe, A. Ludeman, J. Muramatsu, K. Omori, M.J. Pazzani, D. Semler, B. Starr, P. Yap. “Learning Probabilistic User Profiles”. In AI Magazine, volume 18, nº 2, pages 47-56, summer 1997.

K. Golden, O. Etzioni, D. Weld, “Planning with Execution and Incomplete Information”. UW Technical Report TR96-01-09, February 1996. K. Golden, D. Weld, “Representing Sensing Actions: The Middle Ground Revisited” (KR-96, Nov 1996) H.Kautz, B.Selman, and M.Shah. “The Hidden Web”. In AI Magazine, volume 18, nº 2, pages 27-35, summer 1997. C.A.Knoblock, S.Minton, J.L.Ambite, N.Ashish, et. al., “Modeling Web Sources for Information Integration”. In Proceedings of the Fifteenth National Conference on Artificial Intelligence, Madison, WI, 1998. M. Paolucci, O. Shehory, and K. Sycara. “Interleaving Planning and Execution in a Multiagent Team Planning Environment”. tech. report CMU-RI-TR-00-01, Robotics Institute, Carnegie Mellon University, January, 2000. K.P.Sycara. “Multiagent Systems”. AI Magazine, summer 1998.

J.L.Ambite, C.A.Knoblock. “Planning by rewriting: Efficiently generating high-quality plans”. In proceedings of the Fourteenth National Conference on Artificial Intelligence. 1997.

M.Veloso, J.Carbonell, A.Pérez, D.Borrajo, E.Fink and J.Blythe. “Integrating planning and learning: The Prodigy architecture”. Journal of Experimental and Theoretical AI, Vol.7, pages 81-120, 1995.

Yigal Arens, Craig A. Knoblock and Chun-Nan Hsu. “Query Processing in the SIMS Information Mediator”. Advanced Planning Technology, editor, Austin Tate, AAAI Press, Menlo Park, CA, 1996.

M.Veloso. “Planning and Learning by Analogical Reasoning”. Springer-Verlag, December 1994.

N.Ashish, C.A.Knoblock. “Semi-automatic Wrapper Generation for Internet Information Sources”. Second IFCIS Conference on Cooperative Information Systems (CoopIS), Charleston, South Carolina, 1997.

D.E.Wilkins, D.L.Myers. “A Multiagent Planning Architecture”. Proceedings on The Fourth International Conference on Artificial Intelligence Planning Systems. AIPS’98. June7-10, 1998.