DYNAMIC CONFIGURATION OF A PERSONALIZED TOURIST AGENDA

Transcription

1 DYNAMIC CONFIGURATION OF A PERSONALIZED TOURIST AGENDA Anna Goy and Diego Magro Dipartimento di Informatica Univerità di Torino C. Svizzera 185 Torino - Italy {goy, magro}@di.unito.it ABSTRACT In this paper we claim that the new generation of Web-based systems should offer an intelligent, flexible and interactive support to their users, coupled with the ability to provide personalized solutions. We think that problem solving techniques could be exploited to face this challenge. In particular, we present STAR, a Web-based system that exploits the configuration technology in order to support a tourist in organizing a personalized agenda for a tour in a city. We describe the system architecture and the knowledge representation supporting this task. A first prototype of STAR is being implemented and it is instantiated on the city of Torino (Italy). KEYWORDS Adaptive Web Systems, Intelligent Agents, Internet Services, WWW/Internet Applications, Web Personalization. 1. INTRODUCTION The number of Web surfers is increasing and people relay more and more on the Internet to find any kind of information (from train timetable to medical news) and to solve almost any type of problem (buying a ticket for the theater, or finding an itinerary for spending a weekend abroad). Internet is highly preferred with respect to other traditional information sources, such as paper yellow pages, or newspapers thanks to the great amount of information immediately availabile with a few clicks and a small effort. This trend highlights three big challenges for the development of the new generation of Web-based systems: (i) People see the Internet as a big general problem solver: they require an active support even in complex tasks (e.g., financial or medical advice, leasure and entertainment offers). (ii) The large number of heterogeneous people interacting with the Web includes a lot of non-expert users, who need an intelligent and flexible support, coupled with a highly interactive user-friendly user interface. (iii) Many current offers on the Web apply a "one-fits-all" approach (e.g. pre-packed travel solutions provided by on-line tour operators) which do not fulfill the requirements of heterogeneous users having different goals. This highlights the need for personalized solutions, tailored on the specific requirements of single users. Tourist Web portals currently present in the Internet make the access to tourist information and services much easier, but we believe that equipping these services with problem solving capabilities would significantly improve their usefulness for the users. In the following we will describe STAR (Smart Tourist Agenda Recommender), a Web-based system which exploits a configuration engine to support the user in organizing a personalized tour in a given geographical area. In particular, Section 2 introduces a usage scenario of STAR; Section 3 discusses various aspects of the definition of a tourist agenda seen as a configuration problem; Section 4 illustrates STAR's architecture; Section 5 provides a comparison with related works; Section 6 discusses some possible future improvements of the system.

2 2. A USAGE SCENARIO Susan wants to organize a one day trip to Torino (Italy). She is interested in an exhibition about African art she heard of and she would like to spend the rest of the day in sightseeing, buying some gifts and eating good Italian food. Her favourite tour operator can support her with travel and hotel reservations and with information about tourist attractions and events in the area, but the organization of the tour is left to Susan's initiative. Scheduling the agenda for a tour is a quite complex task, which requires a detailed knowledge: the most interesting tourist attractions, their opening hours, the cultural events going on at that time, the places where you can find good food, or buy typical products. Susan connects to a tourist Web portal which offers many services, among which STAR. As a first step, STAR asks Susan some questions (e.g., the date of the trip; if she would like to try the famous "aperitivo"; if she is interested in a particular artistic style; see Figure 1a). Moreover, Susan can specify (a) a set of tourist attractions, events, restaurants, etc. she is interested in, by browsing the available categories; (b) the starting point of the tour, by providing the name of her hotel, or choosing a specific tourist attraction, or selecting an area in the city by means of an interactive map. Figure 1 (a) Initial questions asked by STAR; (b) An example of an agenda suggested by STAR STAR gathers the information provided by Susan and tries to suggest her a one-day agenda. The output of STAR reasoning activity is displayed in Figure 1b. If the proposed solution is partial, i.e. not all the time slots are filled in, Susan can select new items in order to fill them in. Moreover, Susan can "criticize" STAR's choices and modify them. For instance, if STAR proposed a visit to the Egyptian Musem in the morning, and Susan is not very happy with it, she can click on the corrisponding button ([m] in the figure): a pop-up window will appear, where Susan can select a new item (e.g. the Museum of Cinema) that will replace the Egyptian Musem. The system takes into account this new requirement and displays the modified agenda. 3. DEFINING A TOURIST AGENDA AS A CONFIGURATION PROBLEM The definition of a tourist agenda is an actual problem solving task and manually solving it can be annoying and time consuming: it requires to access different information sources (tourist guides, the Internet, local newspapers, etc.) and to mentally backtrack many times (e.g. when discovering that an interesting museum is closed, that two historical buildings are too far from each other to be visited in the same morning, and so on). In this section we show how this task can be automated by defining it as a configuration problem. Intuitively, a configuration problem is the task of assembling a (sub)set of pre-defined components in order to build a complex entity that meets a set of requirements. The component types are given a priori and

3 no new type can be introduced during the configuration process. Usually, a set of constraints define the valid combinations of components. These constraints may restrict the types or the number of components allowed as parts of the complex entity, or they may express more complex relations among the components. Automatic configuration is an important topic in AI research: in recent years a widely accepted configuration ontology has been defined (e.g., Soininen et al. 1998) and different ways of encoding configuration problems have been proposed, based on the Constraint Satisfaction Problem (CSP) framework and its extensions (see Mittal and Falkenhainer 1990, Sabin and Freuder 1996, Veron and Aldanondo 2000) or on logic and structured representations (see McGuinness and Wright 1998, Soininen et al. 2000, Magro and Torasso 2003) or on a combination of them (see Junker and Mailharro 2003). STAR exploits a configuration engine to help tourists in defining their agenda. STAR's configurator is based on the FPC framework (see Magro and Torasso 2003) which enables us to represent: the complex (i.e. configurable) components; the atomic components (the basic buildings blocks of the configurations); the components' features; the taxonomic relations between the classes of components; the partonomic relations between each complex component and its (sub)components; several kinds of constraints among the components. STAR s reasoning mechanisms are based on a declarative representation of a generic agenda as a complex entity (see Section 4.1) in which tourist items (e.g. buildings, restaurants, etc.) are the basic components and denote the corresponding activities (e.g. visits to buildings, lunch in a restaurant, etc.). When a tourist defines her agenda, not only she takes into account her interests, but she also has to consider various constraints. First of all, there are time constraints. Although a tourist agenda is not a strict schedule, however it usually includes the information about those activities that take place in the morning, in the afternoon, and in the evening. Obviously, for each part of the day, the scheduled activities should not exceed the available amount of time. A second type of constraints concern the periods in which the different activities are available: for instance, an historical building may be inaccessible for the time needed to restore it; a museum may be closed on Mondays; a restaurant may be open only in the evening, or every evening but Thursday. Finally, some constraints come from the physical locations in which the activities take place, e.g., it is not reasonable to plan to visit four different historical buildings far away from each other, during a single morning. Although, to the purpose of profitably spend a day as a tourist in a city, it is not necessary to find an optimal solution to the Travelling Salesman Problem, however, the agenda should at least satisfy a set of qualitative constraints arising from the distance between the physical locations of the activities. 4. SYSTEM ARCHITECTURE Figure 2 shows STAR's architecture, which is composed by five basic modules: the Frontend Manager (FE Mgr) and the User Interface (UI) represent the Frontend; the Configuration Problem (CP) Generator and the Configuration Engine represent the Backend. Moreover, the architecture includes a FPC knowledge base, representing the model of a generic agenda and consisting of three parts, i.e. the Taxonomy, the Partonomy and the Constraints. The prototype currently under development, based on STAR architecture, is instantiated on the tourist attractions and services within the city of Torino (Italy). Figure 2 STAR's architecture 4.1 Knowledge representation For a formal description of the FPC language see (Magro and Torasso 2003); here we introduce STAR's knowledge base in a more intuitive way. The Partonomy and the Taxonomy give an approximate but easy-tounderstand description of the domain, which is refined by means of constraints, that express complex relations among components. Figure 3a shows a portion of the agenda's Partonomy (the rectangles and the ellipses represent the classes of complex and of atomic components, respectively). The agenda is modeled as

4 a complex object composed by three parts that represent the time slots of a day 1 and play the partonomic roles hasmorning, hasafternoon, hasnight, which can be filled in by an instance of the classes MORNING, AFTERNOON, and NIGHT, respectively. The range of the possible cardinalities for these roles is expressed by the interval (0,1), meaning that there may be at most one component playing each role (e.g., in any agenda there can be only one morning) and that all roles are optional (e.g., one can plan no activities in the morning). The elements of MORNING, AFTERNOON, and NIGHT are complex components and their parts represent the activities that can be performed in these time slots. In the morning (the cases of afternoon and night are similar) a tourist can have breakfast, visit some tourist attractions, attend some events, do shopping and have lunch. In general, a visit to a tourist attraction can be short, medium length or long (see the description of the Taxonomy below). Since we assumed that a short visit takes approximately half an hour, it seems reasonable to schedule at most 10 visits in the morning, and therefore the maximum cardinality allowed for the partonomic role hasvisitm is 10. Similarly, since we can assume that shopping or attending an event takes at least a couple of hours (roughly), it is reasonable to plan to do shopping in at most two different shopping places or to attend at most two events in the morning. Figure 3 (a) A portion of STAR's Partonomy; (b) A portion of STAR'S Taxonomy The Taxonomy (a part of which is shown in Figure 3b) represents the knowledge about the entities involved in the tourist domain. The root (TOURIST-ITEM) has five features: location, which identifies an area within the city; three boolean features encoding the opening hours (openmorning, openafternoon, opennight); the feature timeunits representing the time that a tourist can spend visiting that attraction, or attending that event. timeunits takes its value in the set of the possible approximate durations of the tourist activities. In the current prototype, we considered a single unit of time roughly corresponding to half an hour (e.g., a short visit), thus the approximate durations available are 1, 4 and 8 time units, corresponding to half an hour, two hours and four hours, respectively. Therefore, when a "tourist item" (e.g. the Cathedral) is added to the agenda, the duration of the activity that it represents (e.g. a visit to the Cathedral) is encoded by the value taken by the feature timeunits (e.g. if the Cathedral is in the agenda with its feature timeunits set to 1, it means that a quick visit to the Cathedral is scheduled). The Constraints, refining the description of the domain provided by the Partonomy and the Taxonomy, are expressed in the FPC constraint language (see Magro and Torasso 2003). We will not focus on their formal representation, but we will try to give an idea of the logics they encode. The first kind of constraints mentioned in Section 3 are those arising from the time required by the activities. For instance, we can state that the total time spent in the morning for the tourist activities should preferably be less that 11 time units and it must not exceed 12 time units, with the following two constraints (one with k = 10 and w and the other with k = 12 and w = ) 2 : 1 In the current version, we assume that the agenda includes only one day. We will extend the representation in order to deal with multiple-day agendas as future work. 2 In expressions R like R { p11, p 1h, p r1, p rk }, each p i1, p ij is a path of partonomic roles in the Partonomy. The FPC predicate (R)(in C 1 C s ) (where C 1 C s are classes occurring in the Partonomy or in the Taxonomy) states that R (the set of (sub)components denoted by R) is a subset of the unions of the sets of components (denoted by the classes) C 1 C s. (R)[h,k] states that the cardinality of R belongs to the interval [h,k].

5 Σ({ hasbreakfast, timeunits, haslunch, timeunits, hasvisitm, timeunits, hasshoppingm, timeunits, hasattendingm, timeunits }) k, weight = w. The second type of constraints mentioned in Section 3 concern the periods in which the tourist items are actually available. To handle this aspect, some elements of STAR's Taxonomy are ''date sensitive'', i.e., they may change depending on the particular date the agenda refers to. In the current prototype, the date sensitive elements are some leaf classes and the values of the features openmorning, openafternoon, opennight. If a tourist item is not available in the day the agenda refers to, the leaf class representing this item in the Taxonomy is hidden. For instance, if the agenda refers to Tuesday, 24/08/04, all the restaurants closed on Tuesdays are logically deleted from the Taxonomy and they cannot be inserted into the agenda. It may be the case that some items are available only in some periods of the day, e.g., a restaurant may be closed in the morning either all the week days or in some particular days. Since the features representing the opening hours are date sensitive, they always reflect the situation in the particular day taken into consideration; therefore, these cases can be modeled by a set of constraints like the following: ({ hasbreakfast, haslunch, hasvisitm, hasshoppingm, hasattendingm }) (in σ openmorning = false [0;0]), weight =. which states that no activity involving a tourist item closed in the morning can be scheduled in that part of the day. The third kind of constraints come from the physical location of the tourist items. For instance, we may want to state that all the activities in the morning must be located in the city areas A, B or C and, preferably, all in the area A. We can express this fact by means of the following two constraints: (R) (in σ location=a σ location=b σ location=c ); weight = ; (R) (in σ location=a ); weight = 0.5; where R { hasbreakfast, haslunch, hasvisitm, hasshoppingm, hasattendm }. 4.2 Management of the interaction with the user The constraints represent common patterns in user reasoning about tourist agendas. However, since their format is definitely not "user-oriented", the user should not be exposed to the complexity of their internal representation. This is the reason why, in our architecture, the Frontend Manager (FE Mgr) takes the role of a mediator between the Backend reasoning activity and the interaction with the user. In particular, the FE Mgr manages the sequence of steps that represent the dialog with the user: 1. At the very beginning of the interaction the user is asked to express her requirements about the agenda, by answering a set of questions (see Figure 1a). 2. The user's answers are collected, interpreted and sent to the Backend (CP Generator). 3. When the Backend (Configuration Engine) has produced a solution (or a failure), this is sent to the FE Mgr, that displays it (see Figure 1b). 4. The user can modify the proposed solution; if this is the case, the FE Mgr sends the modified version back to the Backend (Configuration Engine), that checks it. The new solution is then sent to the FE Mgr for display. This step can be iterated until the user is satisfied with the proposed solution. (R)(in C 1 C s [h,k]) states that the cardinality of the intersection between R and the set of components denoted by C 1 C s belongs to the interval [h,k]. Σ(S) n, where S { p 11, p 1h,f 1, p r1, p rk,f r }, states that the sum of all the feature values denoted by S is less than or equal to n. S is similar to R, but each path in S ends with a numeric feature f i, instead of with a partonomic role. A weight (i.e. a real value in [0,1] or ) is associated with each constraint and represents the importance of the constraint (if the weight is, the corresponding constraint must be satisfied by the agenda). σ f=v denotes the union C 1 C t such that C 1 C t are the leaf classes in the Taxonomy in which the feature f is defined and it takes value v.

6 Figure 4 User's requirements In order to represent the information exchanged during the interaction, STAR exploits an internal format, based on XML. The first piece of information needed by the FE Mgr to handle the interaction is the set of questions exploited to elicit the user's requirements on the agenda 3. Figure 4 shows the internal format of one of the questions posed by the current prototype. Each question refers to a property of the agenda (see the PROPERTY element); the user's answers correspond to the selection of a particular REQUIREMENT within a PROPERTY. For example, the displayed question refers to artistic styles. In this case, there are n possible requirements, where n is the number of artistic styles encoded in the system. The user's answer corresponds to the selection of one of the requirements, i.e. one of the encoded styles. The interpretation of this answer is that the agenda should include (many) buildings of the selected style, and this is represented by the value asmanyaspossible in the CARDINALITY element. The user's requirements are sent to the CP generator (second dialog step) in order to be traslated into the corresponding constraints for the Configuration Engine (see Section 4.3). The internal representation of a solution (exploited in the third step) is based on the same language: we do not describe it here for space reasons. The fourth step can be iterated until the user is satisfied with the solution. Each time, the user can select an item she is not happy with and STAR displays a pop-up window (seefigure 1b) where the user can browse the Taxonomy and look for a new item. The user s choice is translated into a set of new constraints and the Configuration Engine recompute the agenda. In order to support the interactivity required by the process of building a personalized agenda, we conceived the User Interface (UI) as a sequence of dynamically generated Web pages. An XML-Schema (see defines the logical structure of each page type, i.e. the pieces of information it contains, their relations, and the elements enabling the user actions (e.g., buttons and links). The generation of a page is performed in two phases: (a) Dynamic generation of the content. For each page type, a different content is required: the list of questions in the initial page; the configured agenda produced by the Configuration Engine in solution pages. The output of this first phase is a XML object, validated onto the pre-defined XML-Schema, that represents the dynamic content of the page. (b) Surface generation. The Web page displayed to the user is generated by transforming the XML object to a standard HTML, by means of pre-defined XSL stylesheets (see which encode all the choices concerning the graphical layout (colors, fonts, images, etc.). 4.3 Backend reasoning activities The CP Generator translates the user's requirements into a set of FPC constraints. Given the space limitations, we do not illustrate all the types of requirements currently present in STAR prototype. Instead, we provide a sample translation of the first requirement in the style property (see Figure 4). This requirement denotes the set of all the baroque buildings (see the CID and the ATTRIBUTE elements) playing any (composite) partonomic role that a building can play in an agenda (see the value all in the ROLE_CHAIN element). The value asmanyaspossible states that this set should be as large as possible. The importance degree of this requirement is expressed by the weight value 0.5. Given that a visit to a building can be scheduled either in the morning or in the afternoon, this requirement is translated into the following set of FPC constraints (one for each value of k): (R) (in σ style=baroque [k;µ]) weight=w, where R { hasmorning, hasvisitm, hasafternoon, hasvisita } 3 Different instantiations of STAR can be configured with different sets of initial questions.

7 µ is the minimum between the number σ style=baroque of all the baroque buildings in the Taxonomy and the upperbound C max (R) to the number of components denoted by R, as it can be computed on the basis of the Partonomy; k ranges from 1 to µ and w=0.5/µ. It is worth noting that any agenda satisfying the constraint in which k=α also satisfies all the constraints in which 1 k α -1. Therefore, any agenda satisfying the constraint in which k=µ satisfies all these constraints, for each value of k, and it contains the maximum number of visits to baroque buildings that it is physically possible. The Configuration Engine takes as input the knowledge base and the FPC constraints representing the user's requirements and it searches for a particular agenda that respects the general description provided by the Partonomy and the Taxonomy, satisfies all the constraints whose weight is and minimizes the sum of the weights of the unsatisfied constraints. 5. RELATED WORK In the travel and tourist domain different systems have been implemented to support the users to plan long trips. In (Linden et al. 1997) a framework to acquire user models by means of interactive problem solving is presented. This technology has been applied in the Automated Travel Assistant system, which interactively builds flight itineraries. In (Torrens et al. 2002) a similar application is described. However, this work mainly focuses on the SmartClients technology which exploits the compactness of the CSP representation of the problem and the simplicity of the CSP resolution algorithms to migrate the problem solving process on the client. In (Knoblock 2004) the agent technology is used in a system that provides a support for planning a trip (flights, ground trasportation, hotels) and that is able to monitor and to react to the various events that may require some changes to the planned trip. Differently from these systems, STAR's goal is not the planning of a long trip (involving flights selection, hotel reservation and so on), but it aims at supporting the tourist in profitably spending her time in a more restrict area, such as a city. However, we think that it would be worth investigating to what extent the technology exploited by these systems can be applied to STAR. In (Ricci et al. 2002) the Intelligent Travel Recommender system is presented that uses both contentbased and collaborative filtering to recommend suitable travel products. ITR supports the user in building her travel bag containing locations, accomodations, activities and attractions, but the user is responsible to assure the coherence of the whole travel bag. Giving the user such a responsibility works well when the components (e.g. the elements in the travel bag) loosely interact or the constraints among them can be easily satisfied. In the case of STAR, a quite complex problem solving activity has to be performed in order to recommend a suitable and coherent agenda. Finally, many recent projects focus their attention on building an itinerary around a city and providing a dynamic, context-aware support to the user during the visit. A project which represents a milestone for intelligent electronic tourist guides is GUIDE (Cheverst et al. 2000), which provides a context-sensitive tourist guide for visitors to Lancaster city. The GUIDE prototype is able to construct a personalized walking tour within the city, to give the user directions from one location to the next, and to provide descriptions of what is being seen. Lol@ (Umlauft et al. 2002) provides a multimedia, location-aware, mobile guide within the city of Vienna. By exploiting a PDA or a smartphone, the user can build an itinerary and follow it on an interactive map, displayed on the screen of her mobile device. Crumpet (Schmidt-Belz et al. 2002) is a EU Project aimed at providing the users with a mobile tourist support in different European cities. The prototype developed within this project offers, among other services, an interactive map that can be exploited to create a dynamic itinerary. Crumpet also provides a list of recommended attractions, tailored to the user's interests. Finally, Deep Map (Malaka and Zipf 2000) is a long term research project aimed at developing a mobile system able to generate personalized guided walks through the city of Heidelberg and planning algorithms have been developed that generate tourist tours within the city. All the last mentioned projects focus their attention on mobility aspects: these systems support the user, mainly during the tour itself, to move around the city and often provide context-aware information about tourist attractions and services available, but the organization of a coherent agenda is totally left to the user. Every trip usually starts with a (rough) schedule of the day you are going to spent visiting a city: this important phase, which usually precedes the actual tour, is not fully supported by the current available systems. Thus, we claim that STAR could be viewd as complementary with respect to these approaches,

8 since it aims at supporting the user with reasoning mechanism that help her in this preliminary phase, thus it could be integrated with a context-aware mobile tourist guide which takes the agenda planned by STAR as input. 6. FUTURE WORK The prototype, based on STAR architecture, supporting the organization of tours within the area of the city of Torino, is currently under development. As soon as the implementation is complete, we will test it, in order to get feedback for improving the different aspects of the system, concerning both the configuration algorithms and the interaction with the user. Two main aspects require further attention. First of all, failure handling must be taken into account. Moreover, an interesting enhancement of the system would be to include a User Model, which could provide input to the FE Mgr on behalf of the user. The idea is that the set of requirements currently directly elicited by asking the user could be partially determined by asking the User Model, which could contain information about the user's interests, needs, and so on, thus significantly reducing the input needed from the user. REFERENCES Cheverst, K., Davies, N., Mitchell, K., Friday, A. and Efstration, C., Developing a context-aware electronic tourist guide: some issues and experiences. Proc. of CHI 2000: Human factors in computing systems. pp Knoblock, C., Building Software Agents for Planning, Monitoring, and Optimizing Travel. Proc. of ENTER Junker, U. and Mailharro, D., The Logic of ILOG (J)Configurator: Combining Constraint Programming with a Description Logic. Proc. of IJCAI-03 Configuration WS. pp Linden, G., Hanks, S. and Lesh, N., Interactive Assessment of User Preference Models: The Automated Travel Assistant. Proc. of 6th Int. Conf. on User Modeling. pp Magro, D. and Torasso, P., Decomposition Strategies for Configuration Problems. In AIEDAM, Special Issue on Configuration, Vol. 17, No. 1, pp Malaka, R. and Zipf, A., DEEP MAP - Challenging IT research in the framework of a tourist information system. Proc. of ENTER pp McGuinness, D. L. and Wright, J. R., An Industrial-Strength Description Logic-Based Configurator Platform. In IEEE Intelligent Systems, Vol 13, No. 4, pp Mittal, S. and Falkenhainer, B., Dynamic Constraint Satisfaction Problems. Proc. of AAAI-90. pp Ricci, F., Arslan, B., Mirzadeh, N., Venturini, A., ITR: a Case-Based Travel Advisory System. Proc. of ECCBR pp Sabin, D. and Freuder, E.C., Configuration as Composite Constraint Satisfaction. Proc. of Artificial Intelligence and Manufacturing. Research Planning Workshop. pp Schmidt-Belz, B., Nick, A., Poslad, S. and Zipf, A., Personalized and Location-based Mobile Tourism Services. Proc. of Mobile-HCI. Soininen, T., Niemelä, I., Tiihonen, J., and Sulonen, R., Unified Configuration Knowledge Representation Using Weight Constraint Rules. Proc. of ECAI 2000 Configuration WS. pp Soininen, T., Tiihonen, J., Männistö, T. and R. Sulonen, Towards a General Ontology of Configuration. In AIEDAM, Special Issue on Configuration, Vol. 12, No. 4, pp Torrens, M., Faltings, B. and Pu, P., SmartClients: Constraint satisfaction as a Paradigm for Scaleable Intelligent Information Systems. In Int. Journal of Constraints, Vol. 7, No. 1, pp Umlauft, M., Pospischil, G., Niklfeld, G., Michlmayr, E., Designing LoL@, a Mobile Tourist Guide for UMTS. Proc. of 4th Int. Symposium on Human Computer Interaction with Mobile devices. Veron, M. and Aldanondo, M., Yet Another Approach to CCSP for Configuration Problem. Proc. of ECAI 2000 Configuration WS. pp