=Paper=
{{Paper
|id=Vol-1724/paper3
|storemode=property
|title=An Intelligent System for Smart Tourism Simulation in a Dynamic Environment
|pdfUrl=https://ceur-ws.org/Vol-1724/paper3.pdf
|volume=Vol-1724
|authors=Mohannad Babli,Jesus Ibañez,Laura Sebastia,Antonio Garrido,Eva Onaindia
|dblpUrl=https://dblp.org/rec/conf/ecai/BabliISTO16
}}
==An Intelligent System for Smart Tourism Simulation in a Dynamic Environment==
https://ceur-ws.org/Vol-1724/paper3.pdf
An Intelligent System for Smart Tourism
Simulation in a Dynamic Environment
Mohannad Babli, Jesús Ibáñez, Laura Sebastiá, Antonio Garrido, Eva Onaindia 1,2
Abstract. In this paper, we present a smart tourism system for instance, a museum that closes, a restaurant which is fully
that plans a tourist agenda and keeps track of the plan exe- booked, a bus route that is now diverted, etc. This has critical
cution. A Recommendation System returns the list of places implications on the way tourists regard their experiences. Ac-
that best fit the individual tastes of the tourist and a planner tivities, even pre-designed in advance, must be dynamically
creates a personalized agenda or plan with indication of times adapted and personalized in real time. One essential prerequi-
and durations of visits. The key component of the system is site for smart technology is real time synchronization, which
the simulator in charge of the plan monitoring and execution. implies that information is not limited to a-priori collection
The simulator periodically updates its internal state with in- but can be collected and updated in real time [14].
formation from open data platforms and maintains a snapshot Creating an agile and adaptable tourist agenda to the dy-
of the real-world scenario through live events that communi- namic environment requires tracing the plan and checking
cate sensible environmental changes. The simulator builds a that activities happen as expected. This involves plan moni-
new planning problem when an unexpected change affects the toring and possibly finding a new tourist agenda organization
plan execution and the planner arranges the tourist agenda in case some particular activity can not be realized. In this
by calculating a new plan. paper, we relate our experience with a context-aware smart
tourism simulator.
From the monitoring and simulation perspective, there
1 INTRODUCTION exist many frameworks for different programming lan-
The exponential growth of the Internet of Things (IoT) and guages that support discrete event-based simulators (e.g.
the surge of open data platforms provided by city govern- http://jamesii.informatik.uni-rostock.de/jamesii.org,
ments worldwide is providing a new foundation for travel- http://desmoj.sourceforge.net/home.html,
related mobile products and services. With technology being http://simpy.readthedocs.io/en/latest/). Although
embedded on all organizations and entities, the application they can be programmed for very particular scenarios, they
of the smartness concept to address travellers’ needs before, fail to take a general domain description and simulate its
during and after their trip, destinations could increase their behavior in highly dynamic environments. At this stage,
competitiveness level [2]. planning technology can be very valuable. The Planning
Smart tourism differs from general e-tourism not only in Domain Definition Language (PDDL) provides a simple way
the core technologies of which it takes advantage but also in to define the physics of the domain (a tourism domain in
the approaches to creating enhanced at-destination experi- our case, although it is valid for any other scenario) and
ences [8]. In the work [14], authors identify the requirements the particular problem that instantiates such a domain. In
of smart technology integration in personalized tourism expe- PDDL we can define the activities to be executed similarly to
riences including information aggregation, ubiquitous mobile rules, with their preconditions, effects and other interesting
connectedness and real time synchronization. features like duration, cost, reward, etc. The result of using
Many tourism applications provide a personalized tourist planning in a tourism domain is a plan, represented as the
agenda with the list of recommended activities to the user agenda of activities the user will follow. The plan needs to
[12, 13, 5, 16, 15]. In many cases, these systems provide a dy- be validated, executed and adapted, if necessary, to new
namic interaction that allows the user to interact with such information. VAL is a plan validation tool [9] that can be
agenda by adding or removing activities or changing their used to validate and simulate a successful plan execution.
order. Additionally, the use of GPS in mobile devices al- However, VAL does not consider the dynamic changes of the
lows recommender systems to locate the future user’s location world and, consequently, it cannot react to them.
and recommend the most interesting places to visit. However, In this work, we present a smart tourism system that at-
most of these applications work with fixed and static infor- tempts to overcome the previous limitations. Particularly, we
mation throughout the execution of the activities. In other use a PDDL tourism description that can be easily adapted
words, they do not easily react before changes in the world; to many different scenarios with new activities, preconditions,
effects and points of interest. We run a planner to obtain a
1 Universitat Politècnica de València, Valencia, Spain, Email: plan and we simulate the plan execution like in a real con-
{mobab, jeibrui, lstarin, agarridot, onaindia}@dsic.upv.es text, dynamically simulating changes in the environment. The
2 This work has been partially supported by Spanish Government
simulator reacts to the changes by checking whether the real
Project MINECO TIN2014-55637-C2-2-R
15
would be also valid, such as OpenStreetMap6 . Third, there
exists a snapshot of the environment or real-world scenario
where the plan is executed. Since this world is highly dy-
namic and can change frequently (e.g. the opening hours of a
museum has changed, or a restaurant is fully booked and the
duration for having lunch is longer than expected), we get the
new information as live events.
On the other hand, the planning module takes the user
profile and the problem information to create a planning sce-
nario in a PDDL format, as described in Section 3. We need to
model the user preferences, constraints and the actions that
the user can do, such as visit or move. The output of this is
a plan, as a sequence of actions the user has to execute. As a
proof of concept, in GLASS we actually simulate that execu-
tion rather than having a real execution that would require
a true group of tourists equipped with sensoring information
to their current geographic positions, pending and already
satisfied goals, etc. This simulation process, more detailed in
Section 4, takes the plan and creates a timeline structure to
run a timed events based execution. It simulates and monitors
Figure 1. GLASS Architecture the resulting states of the world, according to the changes in
the plan, that is the effects that actions provoke and, proba-
bly, being also modified by the live events. This simulation is
world matches the expected one or not and reformulating the shown in a specially designed Graphical User Interface that
PDDL problem if a failure in the plan is detected, while trying shows what is happening at any time. If the expected state is
to reuse as many of the original set of recommended activities different to the real state, i.e. a discrepancy has been discov-
as possible. ered, because some live events prevent the remaining actions
This paper is organized as follows. Next section outlines the in the plan from being executed, a (re)planning module be-
architecture of the smart tourism system. Section 3 presents comes necessary. The idea is to reuse the same planning mod-
the planning description of the tourism domain and highlights ule, thus closing the loop, with a new PDDL domain+problem
the main components of a planning problem. Section 4 de- specification to adapt the plan to the new emerging scenario.
scribes the simulator behaviour with a special emphasis on
the reformulation of a planning problem. Section 5 presents a
case of study of a tourist plan in the city of Valencia in Spain
3 PLANNING MODULE
and last section concludes. The main goal of our system is to provide a personalized plan
to a given tourist. This resulting plan has to reflect the prefer-
2 GLASS ARCHITECTURE ences of the tourist according to his/her profile (demographic
classification, the places visited by the user in former trips and
This work is part of the ongoing GLASS3 (Goal-management
the current visit preferences). Moreover, in order to build this
for Long-term Autonomy in Smart citieS) project applied to
plan, the duration of the activities to perform, the opening
a tourism domain. The idea here is to apply different strate-
hours of the places to visit and the geographical distances be-
gies for dividing the set of goals (i.e. tourist recommendations
tween places (time to move from one place to another) needs
based on previous plans executions by other tourists) for each
also to be considered. Thus, solving this problem requires the
user by using different utility recommendations systems. The
use of a planning system capable of dealing with durative ac-
GLASS architecture is shown in Figure 1. As can be seen,
tions to represent the duration of visits; temporal constraints
the architecture simply consists of a two-process loop: plan-
to express the opening hours of places and soft goals for the
ning module and simulation+monitoring that share common
user preferences. Soft goals will be used to denote the prefer-
information.
able visits of the user, the non-mandatory goals that we wish
On the one hand, the input information is retrieved from
to satisfy in order to generate a good plan that satisfies the
different data sources. First, we need the user profile with
user but that do not have to be achieved in order for the plan
the explicit interests of the user, the goals and preferences
to be correct. In our case, the goal of visiting a recommended
(such as points of interest he/she wants to visit), and tem-
place according to the user profile (the list of potential places
poral constraints. Second, we need to access a different set
that the user can visit is returned by a Recommender Sys-
of databases that identify and categorize the points of in-
tem), is defined as a soft goal (more details in section 3.2).
terest (e.g. museums, restaurants, etc.), their timetable, and
Among the few automated planners capable of handling tem-
geographic sources to find out routes, distances and times be-
poral planning problems with preferences, we opted for OPTIC
tween points. Currently, we use standard APIs, such as Google
[1] because it handles the version 3.0 of the popular Planning
Places4 and Directions5 for this, but other open databases
Domain Definition Language (PDDL) [7], including soft goals.
3 More info at http://www.plg.inf.uc3m.es/~glass
4 More info at https://developers.google.com/places/web-service directions
5 More info at https://developers.google.com/maps/documentation/ 6 More info at http://wiki.openstreetmap.org/wiki/API
16
All the information required by OPTIC to build the plan is violation, of these preferences will affect the quality of a plan.
compiled into a planning problem encoded in PDDL3.0 lan- The penalties for violation of preferences (costs) will be han-
guage, as described in the following sections. dled by the planner in the plan metric to optimize at the time
of selecting the best tourist plan; i.e., the plan that satisfies
the majority of the tourist preferences and thereby minimizes
3.1 Initial state the penalties for violation.
The initial state of a planning problem describes the state The objective is to find a plan that achieves all the hard
of the world when the plan starts its execution. The initial goals while minimizing a plan metric to maximize the prefer-
state must reflect the opening hours of the places to visit, the ence satisfaction; that is, when a preference is not fulfilled, a
distances between them, the initial location of the user, etc. penalty is added to the metric. Specifically, we define penal-
Some information is expressed with predicates and functions, ties for non-visited POIs and for travelling times.
while other information is represented by Timed Initial Liter- The penalty for non-visited places is aimed to help the plan-
als (TILs). TILs, which were first introduced in PDDL2.2, are ner select the activities (tourist visits) with a higher priority
a very simple way of expressing a restricted form of exogenous for the user. Given a plan Π, this penalty is calculated as the
events that become true or false at given time points [3]. ratio between the priority of the activities not included in Π
The predicate (be tourist ?l) is used to represent the and the priority of the whole set of activities recommended
location of the user and the pair of TILs (at 0 (active to the user (RA):
tourist)) and (at tavailable (not (active tourist))) de- P
P ra
termine the available time of the user for the tour, where Pnon visited = a∈RA−Π
P aPr
tavailable is the difference between the time when the tour a∈RA
starts and finishes. The time indicated in the TILs is relative
For example, if the priority for visiting the Lonja is 290, and
to the starting time of the plan; that is, tavailable = 540 refers
the sum of the priorities of all the visits is 2530, the penalty
to 7pm if the plan starts at 10am. Another pair of TILs is
for not visiting the Lonja would be expressed in PDDL as: (
used to define the time window in which the tourist prefers
/ (* 290 (is-violated v3)) 2530). The priority of the ac-
to have lunch. For example, if the preference is between 2pm
tivities (P ra ) is calculated by a hybrid Recommender System
and 4pm, the TILs are (at 240 (time for eat tourist))
(RS) which returns a value between 0 and 300 according to
and (at 360 (not (time for eat tourist))).
the estimated degree of interest of the user in activity a. The
The duration of a particular visit ?v for a tourist ?t is de-
value of P ra is also used by the RS to return a time interval
fined through the numeric function (visit time ?v ?t). As-
that encompasses the minimum and maximum recommend-
signing a value to a numeric function gives rise to a numeric-
able visit duration following a normal distribution N µa , σa2 ,
valued fluent; for example, (= (visit time Lonja tourist)
where µa represents the average visit duration for a typical
80) (details about calculating the duration of the visit are
tourist [10]. Thus, the higher the value of P ra , the longer the
shown in the following section). The list of available restau-
visit duration.
rants is given through the predicate (free table ?r); for
The penalty for movements enforce a reduction in the time
example, (free table ricard camarena). For each restau-
spent in travelling from one location to another, so that closer
rant, we define the time slot in which it serve meals, which
activities are visited consecutively. This penalty is calculated
may depend on the type of restaurant, closing time of the
as the duration of all move actions of Π (Πm ):
kitchen or other factors. Both, places to visit and restau-
rants, have an opening hour and a closing hour that are P
a∈Πm
dur(a)
specified by a TIL: (at topen (open a)) and (at tclose (not Pmove =
dur(Π)
(open a))), to indicate when the place/restaurant is not
longer available. For example, (at 0 (open Lonja)), (at The function (total moving time tourist) accumulates
540 (not (open Lonja))). the time spent in transportation actions, so this penalty would
The distance between two locations ?a and ?b is defined by be defined in PDDL as: ( / (total moving time tourist)
the function (moving time ?a ?b), which returns the time 540). The plan metric to be minimized by the planner is ex-
in minutes needed to travel from ?a to ?b by using the pressed as the sum of both penalties: Ptotal = Pnon visited +
travel mode preferred by the user. The time to move between Pmove .
two places is represented through a numeric fluent (e.g., (=
(moving time caro hotel Lonja) 9)), where the value 9 is
taken from Google Maps. 3.3 Actions
We define three actions in the tourism domain. The action to
move from one location to another is defined in Figure 2. It
3.2 Goals and preferences
takes as parameters the user ?per, the initial location ?from
We handle two types of goals: hard goals, that represent the and the destination ?to. The duration of the action is set to
realization of an activity that the user has specified as manda- the estimated/actual time to go from ?from to ?to, which is
tory (e.g., the final destination at which the user wants to fin- stored in the database. The preconditions for this action to
ish up the tour (be tourist caro hotel)); and soft goals or be applicable are: (1) the user is at location ?from and (2) the
preferences, that represent the realization of a desirable but time window for the available time of the user is active during
non-compulsory activity (e.g., visiting the Lonja (preference the whole execution of the action. The effects of the action
v3 (visited tourist Lonja))). Preferences are expressed assert that (1) the user is not longer at the initial location, (2)
in PDDL3.0 so we need to define how the satisfaction, or the user is at the new location at the end of the action and (3)
17
(:durative-action move (:durative-action visit
:parameters (?per - person ?from - location :parameters (?per - person ?mon - monument)
?to - location) :duration (= ?duration (visit_time ?mon ?per))
:duration (= ?duration (moving_time ?to ?from) ) :condition
:condition (and
(and (at start (be ?per ?mon))
(at start (be ?per ?from)) (over all (be ?per ?mon))
(over all (active ?per))) (over all (active ?per))
:effect (over all (open ?mon))
(and :effect
(at start (not (be ?per ?from))) (and
(at start (walking ?per)) (at end (visited ?per ?mon))))
(at end (be ?per ?to))
(at end (not (walking ?per)))
(at end (increase (total_moving_time ?per)
(moving_time ?from ?to))))) Figure 3. Action visit of the tourism domain
Figure 2. Action move of the tourism domain (:durative-action eat
:parameters (?pers - person ?loc - restaurant)
:duration (= ?duration (eat_time ?pers ?loc))
:condition
the time spent in move actions is modified according to the (and
movement duration. In order to indicate the position of the (at start (free_table ?loc))
(at start (be ?pers ?loc))
user during the execution of the action, a walking predicate (over all (be ?pers ?loc))
is asserted at the start of the action and deleted at the end (over all (active ?pers))
of the action. In this paper, we only consider walking as the (over all (open ?loc))
(over all (time_for_eat ?pers)))
move action; however, more transportation modes according :effect
to the user’s preferences can be included; e.g., cycling, driving, (and
and public transport, as in [10] . (at end (eaten ?pers))))
The action to visit a place is defined in Figure 3, whose
parameters are the place to visit ?mon and the user ?per. The
duration of the action is defined by the function (visit time Figure 4. Action eat of the tourism domain
?mon ?per). The conditions for this action to be applicable
are: (1) the user is at ?mon during the whole execution of the
action; (2) ?mon is open during the whole execution of the
action and (3) the time window for the available time of the 4.1 Timed event simulation: the timeline
user is active. The effects of the action assert that the place A timeline is a simple structure that contains a collection
is visited. of unique timed events in chronological order that represents
The action to perform the activity of eat is defined in Fig- a sequence of world states and that need to be monitored.
ure 4, whose parameters are the user ?pers and the restaurant The timeline is generated with the actions of the plan, the
?loc. The duration of the action is defined by the function problem information and the live events, as depicted in Fig-
(time for eat ?pers) and specified by the user. To apply ure 1. A timed event is an event that happens at time t and
this action, the following conditions must hold: (1) the user is contains the following information: (1) the start, over all or
at ?loc during the whole execution of the action; (2) ?loc is end conditions to be checked at t; (2) the start or end ef-
open during the whole execution of the action; (3) the restau- fects to be applied at t; (3) TILs that represent exogenous
rant has a free table and (4) both the time window for the events but that are defined as part of the problem informa-
time to have lunch defined by the user and the available time tion, so they are known at the time of the plan simulation;
are active. The effects of the action assert that the user has and (4) live events, that dynamically appear during the exe-
had lunch. cuting/monitoring process and so they are unknown a priori.
This way, a timeline encapsulates the information about the
4 SIMULATOR plan (irrespective of it is a sequential or parallel one), TILs
and live events7 , and the corresponding world states. The time
The objective of the simulator is to execute the plan and mon- scale of the timeline will depend on the granularity of the
itor that everything works as expected. To accomplish this, we plan and the periodic steps we want to use for monitoring
first need to create the structures to perform the simulation. the timed events. In our implementation, live events can be
We use a timed event simulation, where events occur at par- manually supplied or they can be retrieved from a datasource
ticular times through a timeline, possibly provoking changes that keeps information about the real world.
in the world state. During the plan monitoring, we check the Given a plan with two actions (move and visit), of duration
predicates and functions and we visually show the plan trace 20 and 60, respectively, and a live event that indicates the
in a specially designed GUI. In case a failure that prevents
7 The information about the plan, problem information and
an action of the plan from being executed is found during the
live events is modeled in PDDL format. We used PDDL4J
plan simulation, we activate a replanning mechanism that re- (https://github.com/pellierd/pddl4j), an open source library
quires a knowledge-based reformulation of the new planning that facilitates the development of JAVA tools for automated
scenario. Next, we describe these tasks in more detail. planning based on the PDDL language
18
0.00 move person1 hotel museum [20.00]
20.01 visit person1 museum [60.00]
90.00 live event (not (open museum1))
Figure 5. An example of a timeline with five timed events.
Note the closed interval for the at start/end conditions and
effects, and the open interval for the over all conditions
museum is closed (not open) at time 90, the resulting timeline
is shown in Figure 5. Figure 6. Simulator graphical user interface
4.2 Plan execution simulation
The simulation of the plan execution requires to set the size the failure: the action that has failed and the conditions that
of the execution step that will be applied along the timeline have been violated. For instance, in the example of Figure 5,
explained in section 4.1. We can set the step size to the time let us suppose there is a live event at time 60 that indicates
granularity of the planner or choose a larger size. The smaller the museum will no longer be open from 60 onwards. In this
the size of the execution step, the more frequently access to case, the overall condition ]20.01,80.01[ (open museum) is
external databases (Google APIs) to acquire new information violated, which means the visit action cannot be successfully
and update the real-world state. Thus, the execution step size executed. Then, we need to invoke the replanning module as
specified by the user determines the update frequency of the described in Section 4.4
internal state of the simulator with respect to the real-world
state. If changes frequently occur in the domain, a small ex- 4.3 Graphical User Interface
ecution step will result in a more reliable simulation with a
proactive behavior. The simulation state is also updated at The graphical user interface (GUI) has been designed to pro-
each timed event, checking the conditions of the actions in vide information about the internal state of the simulator dur-
the state and applying the effects of the event. Additionally, ing the whole plan execution simulation and provides mech-
the simulator also interacts with the real-world through live anisms to control the next step of the simulation. The GUI
events, which may in turn modify or create new timed events is specifically designed to offer a smart-city orientation. It in-
in the timeline. cludes six distinguishable GUI parts:
The simulation of the plan execution starts at time zero,
with an initial state equal to the real-world state, and the sim- 1. Figure 6-section 1 shows the current simulation time
ulator advances through the timeline in every execution step 2. Problem objects (Figure 6-section 2): it displays the plan-
(see Figure 5). The simulator checks that conditions are sat- ning problem objects along with their types. This static
isfied, the current state matches the expected state, and then information will not change over the simulation process.
updates the current state accordingly — this whole process is 3. Current state (Figure 6-section 3): This graphical section
visually shown in our GUI, described below. More specifically, contains the PDDL description of the current state, which
every execution step involves two main tasks: can change after an action starts or ends, when a live event
arrives or when a user introduces a manual change (TILs).
1. processing the live events for changes and update the re- Propositions and numeric fluents of the current state can
spective timed events be separately consulted in two different tabs.
2. for every unprocessed timed event within the current step: 4. Figure 6-section 4 shows the problem goals. In later refine-
(1) update the simulation state with the TILs and effects ments, we intend to show the goals that are expectedly to
of the live events; (2) check the conditions of the timed be achieved with the plan under execution.
event to find differences between the current state and the 5. Figure 6-section 5 shows the dynamic list of plan actions,
expected state; and (3) update the state with the effects of their start time, the objects involved in the action execution
the actions. and the action duration. In addition, actions are shown
with a representative colour: actions currently in execution
If a difference between the current state and the expected are shadowed in yellow, past or already executed actions in
state is found and this difference leads to a situation where the red, and future actions in white.
plan is no longer executable, then a failure has been detected. 6. Representative map (Figure 6-section 6): The map depicts
In such a case, the GUI informs the user about the cause of with location icons the relevant places involved in the plan
19
due to an overall or an at end condition violation, we will
calculate the new initial state by simply rolling back the at
start effects of the failing action (if any).
Step 1.2: Update the time of TILs. When the new
problem is reformulated, we invoke the OPTIC planner, which
resets the time of execution and generates a plan starting
from time equal to zero. Consequently, we need to update the
occurrence time of the TILs to the result of its original time
minus the failure time. Let us assume that a failure occurred
at time 100, and that we have the TIL planned at time 235 (at
235 (not (open la paella))), meaning that the restaurant
la paella will close at 235. Therefore, in the new initial state
formulation, its time will be 135 (235 minus 100); and it will
be updated to (at 135 (not (open la paella))).
Step 2: Update preferences. When a failure occurs, we
come across a situation where we can distinguish two types
of preferences or soft goals:
1. Goals that have already been achieved at the time of the
failure by the actions that have been successfully executed
Figure 7. Reformulation steps before the failure. These preference goals along with their
penalties will not be included in the new reformulated prob-
lem.
2. Goals that have not been satisfied, and which can in turn
(places to visit, restaurant, hotel). These location icons
be divided into two sets:
change their colour when the corresponding action is ex-
ecuted. The map also displays distances between locations. (a) The problem goals that were not included in the original
7. Simulation control buttons (Figure 6-section 7): In the mid- plan;
dle of the top menu, the interface displays four buttons to (b) The problem goals included in the original plan that have
run the simulator step by step (the step size is defined by not been satisfied yet due to the failure.
the user), continue with the simulation, stop the simulation
• For the set of goals in (a), the penalties are kept intact
and reset the simulation.
as they were originally defined in the problem file.
• For the set of goals in (b), we want to keep the plan sta-
4.4 Reformulating the planning problem bility metric [4] similar to the concept of minimal per-
turbation [11], which is why we increase the penalties
Figure 7 shows the steps of the reformulation procedure.
of these goals in the new reformulated problem. Par-
Step 1: Create the New Initial State. The initial state
ticularly, we opt for assigning a relatively high prior-
will comprise the information known by the simulator at the
ity to these pending goals (twice as much as the max-
time of creating the new problem. This includes the infor-
imum penalty among all goals), in order to potentially
mation of the current simulation state plus the information
enforce these goals in the new plan. We have thus opted
about future TILs; that is currently known information about
for applying a stability strategy that gives more priority
some future events. Thereby, the occurrence time of the future
to goals that were already included in the original plan
TILs must also be updated.
than goals that were not. Other strategies such as keep-
Step 1.1: Update propositions and fluents. This step
ing a higher level of stability with respect to the failed
refers to the update of the current state. The propositions
prior plan can also be adopted. In the case of a tourism
and fluents after the failure are retrieved from the current
domain, we think that maintaining the original agenda
world state. However, this might not be an accurate state
of the tourist as far as possible is more advisable.
since we do not have sensing actions that provide us with a
precise picture of the real world. This may be particularly For example, let us consider that the preference
problematic when an overall or an at end condition of an (preference v2 (sometime (visited tourist
action is violated and the action has at end effects. Let us central market))) is one of the soft goals in the
take as an example the action (move tourist caro hotel set (b); this preference indicates that sometime during
viveros garden), with an at start effect (at start (not the execution of the plan the tourist wishes to visit
(be tourist caro hotel))), an at end effect (at end (be the central market. Assuming that the penalty of this
tourist viveros garden)), and an overall condition (over preference in the original problem file was 270, and that
all (active tourist)). Due to a failure that resulted from the highest among all preferences was 300, the new
a live event which violated the previously mentioned overall penalty for preference v2 will be 600.
condition, the tourist is neither in caro hotel because the Finally, two points are worth mentioning. First, we learn
at start effect were already executed, nor in viveros garden the soft goals that the planner decided to pursue in the
because the at end effects were not yet executed due to the original plan by simply executing the plan without any live
failure. For simplicity, and because of the lack of sensing ac- events. Second, the pending hard goals of the original prob-
tions in our current implementation, when a failure happens lem are kept as hard goals in the new problem file.
20
Step 3: Generate the new PDDL files. The last step set of goals includes two lists: (a) the pending goals of the
of the reformulation process consists in generating the new failed plan; that is, have lunch (4. have lunch) and the
PDDL files. In principle, the domain file remains unchanged, three remaining monuments that have not been yet visited
unless we wish to necessarily include some particular action in by the user (5. Lonja, 6. Central market, 7. Town Hall);
the new plan. In this case, we would need to encode a dummy plus (b) the goals of the original problem goals that were
effect that triggers the corresponding action. Otherwise, only not included in the first plan.
the problem file is generated taking into consideration the
Regarding penalties of the goals, the list of goals in (b)
modifications discussed in step 1 and step 2.
are included in the new planning problem with their original
In future implementations of the simulator, we will test a
recommended values (see the non-bold values RV’ in column
Constraint Programming approach [6] for reformulating the
2 of Table 1). As for the pending goals of (a), the penalty of
planning problem, as in [15], and compare the performance
these goals is increased with respect to their penalty in the
when relying on a scheduler rather than a planner.
first plan (see the bold values RV’ in column 2 of Table 1 for
the three pending monuments) accordingly to the stability
5 CASES OF STUDY concept explained in section 4.4.
The simulator invokes OPTIC and obtains a new plan, dis-
played in the middle snapshot of Figure 8. A few things must
The aim of this section is to show the behaviour of our
be noted in this new plan:
simulation system with a representative example. We have a
tourist who wishes to make a one-day tour in the city of Va- 1. OPTIC suggests a new restaurant (orange icon labeled with
lencia. Initially, the system retrieves a set of recommended number 4) which is rather far away from the prior restau-
places according to the user profile (table 1, column 1) and rant. The reason is that we have only included in the plan-
a set of restaurants. The list of recommended places is cal- ning problem the 10-top restaurants in Valencia suggested
culated by a Recommender System through the user profile. by Trip Advisor, and the closest one to the prior restaurant
This list of places comes along with a recommendation value is the one shown in the second map.
(Table 1, column RV) according to the interest degree of the 2. The places included in the new plan are marked with green
user in the particular place. This value will be used by the location icons as well as the paths between places. We can
planning module to obtain a plan that fits the user’s likes. observe that the new plan maintains the visit to Town Hall
The tour (plan) for the user calculated by the planner is (now represented with the green icon numbered as 5) and to
shown in the left snapshot of Figure 8. The visits included in the Lonja (now indicated with the green icon with number
the plan are marked with a red location icon in the snapshot. 6). However, the visit to Central Market has been discarded
The tour starts from the origin location of the tourist, i.e., in this new plan. This is likely due to the longer distance
the hotel in which the user is staying at (green location icon), to the new restaurant.
and includes six visits to monuments (red icons) and one stop
at a restaurant (orange icon). The simulation continues. Let us assume that when the
The simulator starts the plan execution simulation with tourist is visiting the Town Hall, a new live event announc-
the information provided above. Let us assume that at time ing the building closes before the scheduled closing time ((at
1:55 pm, a live event is received, (at 235 (not (free table 140 (not (open town hall)))) is received, the current time
el celler del tossal))), indicating that the restaurant cho- being equal to 140 . A new failure is detected in the middle of
sen by the planner, el celler del tossal, is completely full the execution of (visit tourist town hall) due to a viola-
and has no available table. At the time the live event ar- tion of an overall condition. As we explained in section 4.4,
rives, the tourist has already visited the first three monuments the simulator applies a rollback process to obtain the current
(1. Viveros garden; 2. Serrano towers; 3. Quart towers), and state before the last visit action but preserving the simulation
he is currently at the location of the restaurant el celler del time. Then, in the new reformulated problem, the user is lo-
tossal. When the user learns the restaurant is fully booked, the cated at the Town Hall, he has not visited the Town Hall and
simulator detects a failure because the action (eat tourist the live event causes the proposition (open town hall) to be
el celler del tossal) is not executable. Then, the simula- removed from the initial state. Note that the goal (visited
tor reformulates a new planning problem in order to obtain a tourist town hall) will be included as a goal in the new
plan that solves the failure: problem to maintain the plan stability but since the Town
Hall is no longer open for visits, the planner will not include
1. Initial state: the current location of the tourist is the point this goal in the new plan. The penalties of the goals for this
at which the previous plan failed; i.e., the restaurant el third problem are shown in column 3 of Table 1.
celler del tossal. Since the new initial state is initialized to The third plan (right snapshot of Figure 8), shown in light
time zero (tini = 0), the simulator updates the time of the blue colour, retrieves the visit to the Central market that
TILs in the current state, namely, the opening and closing was eliminated from the second plan. The new plan suggests
time of places, the time slot for having lunch and the TIL visiting La Lonja (5. la Lonja) and then the Central market
(at tavailable (not (active tourist))), where tavailable (6. Central market). Finally, the user returns to the hotel.
is set to the new time the tourist must get back to the hotel
from tini = 0. Additionally, the fluent (total moving time
tourist) is updated with the total time the tourist has
6 CONCLUSIONS AND FURTHER
spent in moves around the city.
WORK
2. Goals: the places that have already been visited (the first We have presented a context-aware smart tourism simulator
three monuments) are removed from the goal list. The new that keeps track of the execution of a tourist agenda. The sim-
21
Figure 8. The three simulated plans. Icons in PLAN1: (0) Caro hotel, (1)Viveros Garden, (2) Serrano towers, (3) Quart towers, (4) El
Celler del Tossal (RESTAURANT), (5)Lonja, (6) Central market, (7) Town hall. Icons in PLAN2: 1,2,3 are the same as PLAN1, (4) the
Pederniz (RESTAURANT), (5) Town hall, (6)Lonja. Icons in PLAN3: 1,2,3,4 are the same as PLAN2, (5) Lonja, (6) Central market
PLACES RV RV’ RV” [5] I. Garcia, L. Sebastia, E. Onaindia, and C. Guzman, ‘E-
Cathedral 280 280 280 Tourism: a tourist recommendation and planning applica-
Central market 270 600 600 tion’, International Journal on Artificial Intelligence Tools,
Lonja 290 600 600 18(5), 717–738, (2009).
Serrano towers 250 — — [6] A. Garrido, M. Arangu, and Eva. Onaindia, ‘A constraint
City of arts and sciences 280 280 280 programming formulation for planning: from plan scheduling
Oceanografic 300 300 300 to plan generation’, Journal of Scheduling, 12(3), 227–256,
Bioparc 210 210 210 (2009).
Quart towers 200 — — [7] A. Gerevini, P. Haslum, D. Long, A. Saetti, and Y. Dimopou-
los, ‘Deterministic planning in the 5th International Plan-
Viveros garden 250 — —
ning Competition: PDDL3 and experimental evaluation of the
Town hall 200 600 600
planners’, Artificial Intelligence, 173(5-6), 619–668, (2009).
[8] U. Gretzel, M. Sigala, Z. Xiang, and C. Koo, ‘Smart tourism:
Table 1. Recommended places foundations and developments’, Electronic Markets, 25(3),
179–188, (2015).
[9] R. Howey, D. Long, and M. Fox, ‘VAL: automatic plan vali-
dation, continuous effects and mixed initiative planning using
PDDL’, in 16th IEEE ICTAI, pp. 294–301, (2004).
ulator periodically updates its internal state with real-world [10] J. Ibañez, L. Sebastia, and E. Onaindia, ‘Planning tourist
information and receives sensible environmental changes in agendas for different travel styles’, in ECAI, (2016).
the form of live events. Events are processed in the context [11] S. Kambhampati, ‘Mapping and retrieval during plan reuse: A
of the plan and in case of failure, a new planning problem is validation structure based approach.’, in AAAI, pp. 170–175,
(1990).
formulated. This involves creating the new initial state and [12] F. Martı́nez-Santiago, F. J. Ariza-López, A. Montejo-Ráez,
updating the time of timed events. In the case of study, we and A. U. López, ‘Geoasis: A knowledge-based geo-referenced
have shown how the user can track the plan execution through tourist assistant’, Expert Syst. Appl., 39(14), 11737–11745,
a GUI that automatically displays the plan under execution. (2012).
[13] I. Mı́nguez, D. Berrueta, and L. Polo, ‘Cruzar: An applica-
As for future work, we intend to endow the system with
tion of semantic matchmaking to e-tourism’, Cases on Se-
a pro-active behaviour, analyzing the incoming of live events mantic Interoperability for Information Systems Integration:
that entail a future failure in the plan. Practices and Applications. Information Science Reference,
(2009).
[14] B. Neuhofer, D. Buhalis, and A. Ladkin, ‘Smart technologies
REFERENCES for personalized experiences: a case study in the hospitality
domain’, Electronic Markets, 25(3), 243–254, (2015).
[1] J. Benton, A. J. Coles, and A.I. Coles, ‘Temporal planning [15] I. Refanidis, C. Emmanouilidis, I. Sakellariou, A. Alexiadis,
with preferences and time-dependent continuous costs’, in R.-A. Koutsiamanis, K. Agnantis, A. Tasidou, F. Kokko-
ICAPS, (2012). ras, and P. S. Efraimidis, ‘myVisitPlanner gr : Personalized
[2] D. Buhalis and A. Amaranggana, ‘Smart tourism destinations Itinerary Planning System for Tourism’, in SETN, pp. 615–
enhancing tourism experience through personalisation of ser- 629. Springer, (2014).
vices’, in Proc. Int. Confernece on Information and Commu- [16] P. Vansteenwegen, W. Souffriau, G. V. Berghe, and D. V.
nication Technologies in Tourism, pp. 553–564, (2013). Oudheusden, ‘The city trip planner: An expert system for
[3] S. Edelkamp and J. Hoffmann, ‘PDDL2.2: The language for tourists’, Expert Syst. Appl., 38(6), 6540–6546, (2011).
the classical part of the 4th International Planning Competi-
tion’, IPC 04, (2004).
[4] M. Fox, A. Gerevini, D. Long, and I. Serina, ‘Plan stability:
Replanning versus plan repair’, in ICAPS, volume 6, pp. 212–
221, (2006).
22