Mobile and web-based services solving common tourist trip design problems are available, but only few solutions consider context for the recommendation of point of interest (POI) sequences. In this paper, we present a novel approach to incorporating context into a tourist trip recommendation algorithm. In addition to traditional context factors in tourism, such as location, weather or opening hours, we focus on two context factors that are highly relevant when recommending a sequence of POIs: time of the day and previously visited point of interest. We conducted an online questionnaire to determine the in uence of the context factors on the user's decision of visiting a POI and the ratings of the POIs under these conditions. We integrated our approach into a web application recommending context-aware tourist trips across the world. In a user study, we veri ed the results of our novel approach as well as the application's usability. The study proves a high usability of our system and shows that our context-aware approach outperforms a baseline algorithm.
• Information systems → Recommender systems;
Recommender Systems (RSs) are commonly known as software
systems that suggest certain items to users in a predictive manner [
In the tourism domain, CARSs are also being developed and
researched. Several relevant contextual factors (e.g., weather) and
their respective contextual conditions (e.g., raining) have already
been identi ed. For example, a CARS reduces the relevance of
outdoor activities while it is raining [
Most tourism CARSs focus on suggesting single points of interest
(POIs). Only few solve route-planning problems for tourists who
want to visit multiple interesting POIs consecutively. This
problem statement is summarized as the Tourist Trip Design Problem
(TTDP) [
In previous works, we aimed to solve the TTDP and introduced
a mobile application and web service for tourist trip
recommendations around the world. It takes the user’s preferences, time and
budget into account [
The rest of the paper is organized as follows. In Section 2 we present context factors that our CARS observes and explain how the respective contextual conditions ratings have been acquired. In Section 3, our novel context-aware route recommendation algorithm is presented. Section 4 describes the application TourRec, implementing our algorithm. In Section 5, the introduced CARS is evaluated against the RS from our previous work. Section 6 and 7 list related work and conclude the paper. 2
In this section we brie y discuss context and explain how context is relevant for our RS. In order to integrate context-aware information into a tourist trip RS, we rst have to identify appropriate context factors for the tourism domain and assess the in uence of selected context factors. Also, the e ects of each context factor under several contextual conditions on the user’s route satisfaction have to be investigated. Therefore, we conducted an online study to observe context factors speci cally relevant for sequences of POIs and derive information of similar pre-existing research for other context factors. 2.1
A common de nition describes context as "any information that
can be used to characterize the situation of a [...] person, place,
or object." [
Another relevant type of context which we do not yet consider
in this work is social context. Social context can be described as
the user’s social group composition at the time of taking the
recommendation. The user’s standing and role in the group is also an
important factor [
We designed an online questionnaire to acquire quantitative
measures of how selected contextual factors in uence a user’s decision
of going to a POI. The following approach assesses the context
relevance and is based on a methodology presented by Baltrunas et
al. [
For the preliminary questionnaire a set of possible context factors
should be selected by domain experts. The questionnaire
participants are asked to imagine certain conditions and whether a speci c
context factor (e.g., weather) has a positive or negative in uence
on the rating of a particular item [
With this methodology we observe the context factors time of
the day and previously visited POI. These are especially crucial
for sequences of POIs and have not yet been observed in related
work. For other context factors like day of the week, weather and
temperature, which are also relevant for single POIs, we can rely
on [
Preliminary, twelve POIs in Munich, Germany have been selected and mapped into six prede ned categories: Arts and Museum, Food, Music Event, Nightlife Spot, Outdoors and Recreation and Shopping. It is assumed that categories represent all their corresponding POIs. Figure 1 shows how participants are asked whether they would visit a certain POI just after they have been to a di erent POI. Additionally, we asked the participants at which times they would go to certain POIs.
The aim of this study was to evaluate the in uence of the selected context factors on their decisions to visit a category represented by a selected POI as well as the change of POI popularity precipitated by contextual conditions. In total, we received 324 responses by 27 participants.
The measured relevance (U ) for each context factor for all POI categories are computed and listed in Table 1. It is normalized to an interval »0; 1¼; where U = 0 means that the context factor does not have any in uence for this POI category. U is also relevant for the actual context-aware route recommendation algorithm and is there being utilized as a weighting factor for the context assessment in Equation 5.
In addition to the measured relevance (U ) of a context factor, our context-aware approach (cf. subsection 3.3) is also dependent on ratings for POIs under di erent contextual conditions. The dataset resulting from the previous conducted questionnaire can also be utilized to determine such a rating. To make the responses quanti able Yes, I don’t know and No are mapped to the values 2; 1; 0. A simple approach would be to use the mathematical expectation value as a rating of a POI category for each contextual condition. However, this does not respect the variation of the rating for a POI when a contextual condition holds or not. Informally speaking, if a POI category is typically very popular, except during night, the expectation value would not re ect the real value of the contextual condition night. For example, the expectation value for the category food is 1:3. However, if one only considers ratings for food under the contextual condition night, the expectation value is 0:749. Hence, we must present a comparison between the average ratings of POI and ratings of the same items assuming a certain contextual condition holds. We achieve this by dividing the expected value for a speci c contextual condition by the expected value over all ratings for this POI category. For the category Food during night time, the calculation is therefore: 0:7491:3 = 0:58. All computed
This section gives a detailed explanation of paradigms for incorporating context into RSs, the baseline path- nding algorithm and our approach for a context-aware path- nding algorithm. 3.1
This section describes how RS and CARS can be modeled and
which paradigms exist to integrate context into a traditional,
twodimensional (2D) RS. 2D RSs try to estimate the rating function R
by considering only the User and Item dimensions [
This rating function can be extended to model a three dimensional
(3D) recommendation [
The general idea is to combine as many single POIs as possible to maximize the entertainment for the user while still respecting existing constraints like time. The process of generating a path from an origin to a destination while suggesting relevant POIs in between can be generally divided into two subtasks:
The POI gathering and scoring, and executing a path- nding algorithm to nd the optimal route consisting of a subset of the gathered POIs.
For the POI gathering, we are using the Foursquare API2 to
search for POIs in the general area between the source and the
destination point. The gathered items are classi ed into six categories,
users can give preferences for these categories (see below). Our
algorithm then computes a score for each item. The score is based
on the total Foursquare rating and the number of votes, and also
the user preference for the corresponding category [
The algorithm to combine the POIs to a reasonable route is based on the well-known Dijkstra’s algorithm to nd the shortest path in a graph. Dijkstra’s algorithm is an iterative algorithm that provides the shortest path from one particular starting node to all other nodes in a graph with non-negative edge path costs. In our scenario, the nodes are the places with the associated score and the edges represent the distance between the places.
Prior to the graph spanning, each POI is assigned with a value for the time to spend there. Then, a weighted graph is created using an feasible time value to walk the direct physical distance between each vertex as edge weight. Prior to the comparison of a subpath with another path, it is checked whether the subpath exceeds the speci ed timeframe. If the timeframe is exceeded, the subpath will be rejected. If another valid subpath from the origin to the immediate vertex can be found prior to the current path, they are compared against each other.
To generate not the shortest, but the best path in the POI graph, we maximize the fraction entertainment/distance for each subpath. The entertainment value is the accumulated sum of the scores of all items on the subpath. To adapt the number of items per category, the baseline algorithm uses the following formula Equation 3.
S = ppr ef ;poiCat egor ies I nP ath entertainment (3) The idea is to maximize the product of entertainment and Pearson’s correlation coe cient between the user’s preferences and the amount of POIs per category in the observed path. Pearson’s coe cient p gives values between -1 (indicating perfect negative correlation) and +1 (perfect correlation), with 0 meaning no correlation exists between the datasets. Using the correlation coe cient 2https://developer.foursquare.com/start/search R : U ser
Item
Adding context in the rating function increases the complexity
of the recommendation algorithm. This is a non-trivial problem.
Adomavicius and Tuzhilin [
Contextual pre- ltering (or contextualization of recommendation input): The context is utilized to construct a dataset only with the most relevant data. After that, a traditional RS can generate the actual recommendations.
Contextual post- ltering (or contextualization of recommendation output): In contrast to contextual pre- ltering, the traditional RS is executed on the entire data rst and afterwards the context is applied on the resulting set. This can be achieved by: Filtering out recommendations that are irrelevant (in a given context), or Adjusting the ranking of recommendations on the list (based on a given context).
Contextual modeling (or contextualization of recommendation function): In this paradigm the 2D RS must be modi ed and directly incorporate context into the recommendation algorithm.
1 1.06 1.32 1.45 1.42 0.52 0.1 0.19 0.68 1.71 1.55 aims to balance the amount of POIs in each category more appropriate in relation to the user’s preferences. The extension of this adapted POI score with context-awareness is explained in the following subsection. 3.3
The rst challenge that arises is to determine how context-awareness can be calculated for a route. Our collected dataset includes two indications that can be utilizes for this task. First, ratings for categories in di erent contextual conditions as displayed in Table 2. A rating rT C1:::Ck indicates the evaluation for the POI category T made in the context C1; :::; Ck and must be in the interval »0; 2¼. Second, the relevance of contextual factors UC1:::Ck of each context C1; :::; Ck on a POI category T as displayed in Table 1. Like illustrated in subsection 2.2 the measured relevance must be in an interval between »0; 1¼.
Given this data we can calculate a context-awareness factor C with a simple weighted arithmetic mean:
C = Ík i=1 UCi rT Ci Ík
i=1 UCi
C can now be used to extend the 2D recommender baseline algorithm by scaling the result of its comparison function: S = ppr ef ;poiCat egor ies I nP ath entertainment
C (5)
According to the given constraints, also C is in the interval »0; 2¼ with 0 essentially nulling the score S while 2 would double its value.
To better explain the methodology we can illustrate it with an example comparison considering the two context factors time of the day and previously visited POI :
It is 5 pm and the user has just been to a restaurant. The CARS should now calculate the score for another restaurant. In this scenario the 2D comparison algorithm would calculate a score of 9:5. The context-aware comparison algorithm (Equation 5) extends the 2D comparison algorithm (Equation 3) by the context-awareness (4) factor C. To calculate C, we use the values 0:49 and 0:51 for relevance of the context factors from Table 1 and the values 0:19 and 0:85 for ratings for the category food in the current contextual condition from Table 2. After calculating C, the 2D score of 9:5 is downscaled to 5.
C = 0:526 = 0:19 0:49 + 0:85 0:49 + 0:51
0:51 S = 5 = 9:5 0:526 (6) (7)
According to 3.1, one could assume that this algorithm adheres to contextual post- ltering. However, the de nition explicitly states, that the traditional RS must be executed on the entire data rst. Since this is not the case, the paradigm contextual modeling was utilized to incorporate context into the baseline.
The full set of context factors considered in the current implementation and their values (contextual conditions) are: Previously visited POI (category): arts and museum, food, music event, nightlife spot, outdoors and recreation, shopping Time of the day: morning (8am - 12pm), midday (12pm 2pm), afternoon (2pm - 6pm), evening (6pm - 10pm), night (past 10pm) Day of the week: working day, weekend Weather: sunny, cloudy, clear sky, rainy, snowing Temperature: hot, warm, cold
Opening hours: open, closed
One bene t of the weighted arithmetic mean is the independence of the number of context factors. This list can easily be extended. Also the amount of context factors applied on POIs within a path can vary. For example, designing context factors only known for a speci c POI category, e.g. nightlife spot, is not a concern. On the other hand, one disadvantage resulting from considering multiple context factors for C is that a supposedly drastic condition, e.g. the POI is closed, can be balanced out by a di erent condition such as sunshine.
This section rstly presents the multi-tiered and service-oriented system architecture we introduced in (removed for review process). One of the main goals was to facilitate the integration of additional data sources, path- nding algorithms and clients. We then present the user interfaces of our web application TourRec 3. 4.1
The system is distributed across multiple physical devices o oading application logic, computation and storage onto multiple web services running in the cloud. The applications multi-tier architecture can be partitioned into the presentation tier, application logic tier and data tier, while the application logic tier itself is also partitioned. This architectural style decomposes an application into loosely coupled services, functionality can thereby be easily reused. For example, clients do not have to re-implement the whole application logic but rely on the application logic tier. Other advantages are an improved modularity and the fact that each segment is easier to understand, develop and test. It also simpli es further development since components can be assigned more precisely to experts in their respective elds. An iOS developer gets to develop the iOS app, the android developer the android application and the data scientists can improve the algorithm. Also multiple people can work parallel and independently on di erent components.
Additionally, the whole application has been containerized with Docker 4 containers. Containers consist of a complete and isolated run time environment: the software including all its dependencies, libraries and other binaries, and con guration les needed to run it. By containerizing our application, the di erences in OS distributions and underlying infrastructure are abstracted away. This makes it fairly easy for possible new contributors to run the whole project on their local environment. In addition, it enables continuous delivery and deployment.
In the following, the three tiers are presented.
4.1.1 Presentation Tier. The web application being demonstrated as well as the mobile application we have developed in our previous work is representative for the presentation tier. It is end user facing, aimed to provide high user satisfaction and is responsible to handle user input and display computed information. It utilizes services from the underlying application logic tier and external services like Google Maps.
4.1.2 Application Logic Tier. The two main functionalities of this tier are the gathering of POIs and executing path- nding algorithms. First, POIs are gathered from multiple external service providers such as Foursquare5 and normalized. Then, this data is passed over to the path- nding algorithms that are executed afterwards. Each path- nding algorithm is extracted into its own dedicated microservice and communicates with the application logic tier via HTTP in order to return a ordered list of POIs to visit. The path- nding microservices can be implemented using arbitrary programming languages, databases, hardware and software environment. 3https://tourrec.arubacao.com/ 4https://www.docker.com/ 5https://foursquare.com/ 4.1.3 Data Tier. User feedback is being stored and handled within this tier. As it might not seem urgent to dedicate an own tier for this data, the need increases when user accounts are introduced, for example. 4.2
The web application is built with help of the javascript framework Vuejs6 and the CSS framework Bulma7. It is mainly structured into three segments search, recommendation, feedback.
In the search segment, as seen in Figure 2, users can enter their preferences for all six prede ned categories, the origin and destination as well as the time frame for the route. The input is validated both client side as well as server side. For example, the maximum distance between origin and destination is 7 kilometers and the maximum time frame is 12 hours.
The recommendation segment, as seen in Figure 3, is structured as follows. A map with the suggested POIs and a rendered walking path on it is located on the left-hand side. On the top left-hand side some contextual information that has been acquired by the system and is relevant for the user for this situation is displayed. Finally an ordered list of POIs and their respective estimated time of arrival and departure can be found beneath the contextual information.
The feedback segment gives the user a short introduction into the feedback process. In essence, it is a simple table with multiple statements which can each be answered with radio buttons on a vepoint Likert scale ranging from strongly disagree to strongly agree. In section 5 we describe the feedback setup in greater detail. Note, that only one route per request gets displayed. The application logic tier randomly selects either the baseline or context-aware path- nding algorithm. The algorithm name is stored in conjunction with the feedback a user provides. 5
The research question of this paper is whether a context-aware algorithm distinguishing between several contextual conditions can improve the trip recommendations generated by a baseline. We conducted a user study to evaluate the performances of both algorithms. We spread the link to the TourRec application via mail and added questionnaires to the interfaces which the users were asked to complete. The participants could access the application on any device with an internet connection since it is publicly available. 5.1
The System Usability Scale (SUS) is a questionnaire for measuring
how people perceive the usability of a computer system [
19 participants completed the SUS questionnaire after using
TourRec, the average score was 84,167. With the help of Sauro’s
graph, the score approximately converts to a percentile rank of
6https://vuejs.org/
7http://bulma.io/
94% [
In addition to the SUS, we conducted an A/B test to measure the e ect of the novel approach on the user’s route satisfaction compared to the baseline system that does not exploit context at all. Hence, only one tourist trip recommendation is displayed after every request. Apart from the route, users are not able to distinguish between them. The recommendation screen shown in Figure 3 displays contextual information (e.g. the weather) whether or not the context is actually considered.
After every recommendation, a questionnaire for this part of the evaluation is presented to the user. It is composed of the following six statements and also with ve possible response options on a scale ranging from strongly disagree (1) to strongly agree (5): (1) Overall, I am satis ed with the recommended tour (2) The number of places in my route is well chosen (3) The selection of di erent categories in the trip is satisfying (4) Places are suggested at the right times during the tour (5) The tour is feasible for a walking tourist (6) I consider taking this route myself
In total, 15 forms were completed for the baseline algorithm and 9 for the context-aware approach. Figure 4 illustrates the performance of both algorithms for each of the six questions in subsection 5.2. Our novel approach for context-aware route recommendation performs somewhat better in the overall satisfaction ( : 3; 67, σ : 1; 41) and number of places ( : 3; 78; σ : 1; 39). In terms of feasible walking route and consider taking the route the context-aware algorithm is rated slightly lower than the baseline. However, for these four mentioned questions the actual di erence is almost neglectable. The biggest di erence can be seen for diversity of categories and especially right times where the context-aware algorithm outperforms the baseline.
A Mann-Whitney U test shows that the di erence in right times is signi cant for α = 0:01 while the other results we obtained are not yet signi cant. We conclude that our novel approach leads to improved recommendations but we have to conduct a larger user study in the future to verify our results. 6
Some applications solving the TTDP have been developed [
Gionis et al.[
Tour recommendation can also be formulated as a Generalized
Maximum Coverage Problem [
In this paper, we presented the web application TourRec that allows context-aware tour recommendations in arbitrary locations across the world. The system takes a starting point, a destination, a timeframe and user preferences for six prede ned categories into account. It solves a variant of the OP applied to the tourism domain. In a preliminary questionnaire, the in uence of the context factors time of the day and previously visited POI were measured as well as ratings for POI categories in di erent contextual conditions. The results are utilized within the context-aware algorithm.
Context-awareness is incorporated into the baseline algorithm as a scaling factor altering a POI’s score depending on the immediate contextual condition. The focus and innovation of our work is on recommending sequences of items. Therefore the in uence of an already visited POI on the score of additional items based on their category is important. Users may not be interested in another restaurant if they just had lunch or dinner, for example. In a user study we evaluated that the incorporation of context-awareness leads to a slightly improved user satisfaction and a signi cant improvement of recommending POIs at the right time.
One disadvantage of our approach is the possible equalizing of two or more extreme contextual conditions due to the weighted arithmetic mean. A modi ed version could solely consider the context factor that has the largest negative or positive e ect on a POI. Using one single factor could potentially characterize the POI’s score in a more user satisfying way. Another improvement can be achieved by increasing the number of prede ned categories or introduce subcategories. The current limitation of only six categories has led to issues in the route recommendation scenario.
We have designed our framework and architecture for easy
extension. We are working on a mobile solution [