=Paper=
{{Paper
|id=Vol-1685/paper2
|storemode=property
|title=Learning the Popularity of Items for Mobile Tourist Guides
|pdfUrl=https://ceur-ws.org/Vol-1685/paper2.pdf
|volume=Vol-1685
|authors=Patrick Hiesel,Matthias Braunhofer,Wolfgang Wörndl
|dblpUrl=https://dblp.org/rec/conf/recsys/HieselBW16
}}
==Learning the Popularity of Items for Mobile Tourist Guides==
https://ceur-ws.org/Vol-1685/paper2.pdf
Learning the Popularity of Items for Mobile Tourist Guides
Patrick Hiesel Matthias Braunhofer Wolfgang Wörndl
Technical University of Munich Free University of Technical University of Munich
Boltzmannstraße 3 Bozen-Bolzano Boltzmannstraße 3
85748 Garching, Germany Piazza Domenicani 3 85748 Garching, Germany
hiesel@in.tum.de 39100 Bolzano, Italy woerndl@in.tum.de
mbraunhofer@unibz.it
ABSTRACT to further improve the item suggestions made to a user [1].
A context-aware recommender system incorporates the know- These systems seek to better match users and their current
ledge of different contextual factors such as time or weather context with items that are popular in the same or similar
information to improve item suggestions made to a user. contexts.
This requires the system to have a large knowledge base for One major application area of context-aware recommender
inferring contextual information and enabling accurate and systems is travel and tourism, where scenarios are signifi-
timely recommendations. We present a versatile approach cantly more complicated than traditional user-product match-
for a context-aware recommender system in the tourism do- ings [3]. In addition to the general preferences of a user, the
main by crawling publicly available information from a va- utility and relevance that a point of interest (POI) has to
riety of sources and learning the contextual popularity of a user heavily depends on the user’s current context. A
points of interest based on a generalized check-in model. We beer garden, for instance, would provide a higher value to
have deployed a test instance of our system for the greater the user on sunny summer days rather than on rainy winter
area of Munich and the German state of Bavaria. Analyz- days and a car that knows a driver’s route, fuel level and gas
ing the results from the offline learning has led to interesting prices can make better suggestions for gas stations to refuel.
insights including when and in which weather conditions cer- This is especially important in the scenario of a proactive
tain items are popular. recommender system [14], i.e., a recommender that pushes
item suggestions to the user based on the current situation
(e.g. location, time of day or weather) without explicit user
CCS Concepts request.
•Information systems → Recommender systems; In our research, we propose, implement and evaluate a
novel approach for a context-aware recommender system in
Keywords the tourism domain by aggregating publicly available in-
formation from a variety of sources and learning the con-
Recommender systems; context; data analytics; mobile guides textual popularity of POIs based on a generalized check-in
model. We aggregate different types of data, including POIs,
1. INTRODUCTION check-ins and contextual information to build a knowledge
Recommender systems are a composition of software tools base and infer knowledge about the contextual popularity of
and techniques that suggest items to users that are likely to items focussing on aspects of temporal and geographic con-
be interesting to them and relevant to their needs [10]. Tra- text. The gained knowledge can also be utilized to mitigate
ditional recommender systems consider items liked/rated by cold-start problems when no or little information about the
users in the past and possibly some additional information user is available.
such as item characteristics to estimate the ratings for items In the following, we first explore related work (Section 2),
that the users have not yet consumed [1]. Applications range describe the context model, data sources and system design
from suggesting products that have been bought together by of our implementation (Section 3) and then present the pro-
other users in the past over suggesting people a user might cess and results of analyzing the data (Section 4). Finally,
know based on their existing list of friends to suggesting Section 5 draws conclusions and discusses open future work
music based on genres listened to. directions.
Context-aware recommenders enhance traditional recom-
mender systems by incorporating the knowledge of different 2. RELATED WORK
contextual factors - such as time or weather information -
Context-aware recommender systems have been a topic
of growing research interest in the recent years and aim at
generating more relevant recommendations by adapting to
the specific contextual situations of the user and the rec-
ommended items (e.g., weather, temperature, season and
mood) [1]. There exist numerous commercial and research
systems, such as Foursquare, Yelp, South Tyrol Suggests
Copyright held by the author(s).
(STS) [4] and ReRex [2], that have already been success-
RecTour 2016 - Workshop on Recommenders in Tourism held in conjunc-
tion with the 10th ACM Conference on Recommender Systems (RecSys), fully implemented and that exploit the current user’s and
September 15, 2016, Boston, MA, USA. item’s context when recommending items. These systems
use different approaches to incorporate context into the rec- 3.1 Context Model
ommendation process. Roughly, these approaches can be Our research is based on a context model for proactivity in
divided into three categories [1]: (i) contextual pre-filtering, mobile recommender systems defined by Wörndl et.al. [14].
where context is used for selecting the relevant set of rat- The model relies on domain-dependent context modeling in
ings before computing predictions with a traditional, two- four distinct categories: user context, temporal context, ge-
dimensional prediction model; (ii) contextual post-filtering, ographic context and social context. The recommendation
where context is used to adjust the recommendation list re- process itself is divided into two phases to first analyze the
sulting from a two-dimensional rating prediction model; and current situation and then examine the suitability of par-
(iii) contextual modeling, where context is directly incorpo- ticular items. This allows for both a proactive and passive
rated into the prediction model. recommender system.
Most current context-aware recommender systems work The context model defines the data we need to aggregate
in pull mode, i.e., the user has to explicitly make a request and the features that should be extracted. In particular, we
(pull) for recommendations, possibly by entering informa- want to infer the temporal and geographic context of items.
tion about her preferences, needs and constraints. A new The user context is extracted directly in our mobile app pro-
generation of context-aware recommender systems, called totype in a later stage. The social context is neglected in our
proactive recommender systems, are instead pushing rec- prototype but could be integrated in our approach. Based
ommendations to users without their specific request, when on this context model, we focus on the following contex-
they are in a contextual situation that the system considers tual features: weather condition, temperature, season, day
as suitable for the recommendations [14]. Despite the ad- of week, time of day and time of year.
vantages of proactive recommender systems - especially in
mobile usage scenarios - relatively little research has been 3.2 Data Sources
conducted specifically on this topic. One example is [14], The overall goal of this work to recommend POIs in a mo-
where the authors proposed a proactive recommender sys- bile tourist guide based on publicly available data sources.
tem model consisting of two phases: (i) the situation as- We therefore need to acquire and aggregate data in three
sessment phase, which evaluates whether or not the current categories: items (the POIs), check-ins (to determine the
contextual situation calls for a recommendation; and (ii) popularity of items) and context.
item assessment phase, which is only executed when the first
phase indicates a promising situation and assesses the candi- 3.2.1 Items
date items to finally decide which items should be pushed to
the user as recommendations. Subsequent work in [13] has The POIs form the foundation of our system as the user’s
evaluated the effectiveness of the proposed model by apply- overall perception of the system first and foremost depends
ing it to a restaurant recommender system, and found that on the quality and suitability of the recommended items. We
users highly appreciate proactive recommendations if they therefore designed a general model for an item in our domain
are relevant and properly timed. that can then be populated with data. Core data fields
In another work, Dali et al. [5] presented different tim- include: name, description, location, images, phone, rating,
ing models based on random forest to classify user contexts street, city, country. While the core fields should always be
that are suitable for recommendations and user contexts in populated, each data source’s crawler can define additional
which users are highly likely to refuse any recommendations. fields it wants to persists. Based on this model, we examined
Results from a user study revealed that a hybrid model that different, publicly accessible data sources: Foursquare, Yelp,
first decides whether it should use a personal or non-personal Quermania, Facebook, Wikipedia, Open Street Maps. We
timing model, and then classifies whether the context is suit- designed and implemented crawlers for each of those sources
able for recommendations is superior to both the personal and aggregated over 175,000 items for the German State of
or non-personal timing models. Bavaria.
In another study, Pielot et al. [9] showed that boredom
can be inferred from patterns of mobile phone usage and
3.2.2 Check-ins
that users are more likely to appreciate proactive recom- Based on this knowledge base of 175,000 items, we want
mendations during inferred phases of boredom. Hence, they to infer the popularity in accordance to the context model.
concluded that using boredom as trigger independent from Our premise is that a place is popular if many people visit it.
content might help to make proactive recommendations a It follows that a place is popular in a certain context (e.g. on
more pleasant experience for users. a sunny Saturday evening in summer) if many people visit
Finally, Borrı́s et al. [3] survey intelligent recommender it when this context condition applies.
systems in travel and tourism and also mention context and To infer this knowledge, we must first define a model for
proactivity as important factors. determining how popular a place is at a given time or any
other context. We base this model on a generalized check-
3. CONTEXT, DATA SOURCES AND SYS- in. In our model, a check-in can be any evidence that a
user visited a place at a certain time. This includes an ex-
TEM DESIGN plicit check-in on Foursquare or Facebook, as well as implicit
In order to create a versatile system that can gather rele- check-ins by taking a picture or generating a GPS trace on
vant data for any geographic area and infer the contextual a smartphone. A check-in marks a singular point in time.
popularities of POIs, we first discuss the context model that To make an educated judgement on how many people are
our work is based on. This leads to the features we need to present at any point in time, we must further make an as-
extract from the data we crawl. We then discuss different sumption about the average duration of a visit. There has
data sources for items, check-ins and context and present a been research on the activity duration of different activities
brief system design of both the backend implementation and [8] that we use to infer the number of present users from
a corresponding mobile client. check-ins at any point in time based on the POI type.
We looked at different publicly available data source to
crawl check-ins from including Flickr, Twitter and Foursquare.
Flickr is a photo sharing platform with a rich set of geo-
tagged photos. A geo-tagged photo contains the latitude
and longitude of the place it was taken as well as a level
of accuracy of this information. In addition, a textual de-
scription is provided for most of the images. We used Flickr
as the primary source of check-ins for rural areas, establish-
ing a place-to-check-in mapping in a sparsely populated area
which is more straightforward given the geo coordinates of
both places. In our research, we have sampled about 249,000
images to be used as check-ins.
Twitter offers a large number of tweets that can be associ-
ated with a place and hence counted as a check-in. There
are two main features, that can be used for association: geo-
tagged tweets and Twitter Places. Geo-tagged tweets carry
a latitude and longitude and can be associated to places
using geo-fencing. While this is a valid approach in rural
areas, it is insufficient for cities due to the number of places
being close to each other. Twitter places specify a specific
geographic place, such as a city or a restaurant and can be
mapped to a POI directly. In our research, we have sampled
29m tweets in about eight weeks using Twitter’s Streaming
API.
Foursquare has an explicit check-in feature - similar to Face-
book - that would let users check-in at a place using a button
in their app. In addition, Foursquare samples the user’s lo- Figure 1: Screenshot of the Mobile App with the
cation on the smartphone to proactively recommend POIs. Popularity Graph for Time of Day
While this data seems promising, none of it is publicly acces-
sible and was therefore not used for our prototype. On the
contrast, some users link their Twitter account with their framework offers a modern web MVC architecture with a
Foursquare account resulting in each explicit check-in trig- simple control flow and the advantage of using templates
gering a public tweet. Following the approach proposed by in the views. We have combined this with Slick - a func-
Melia and Segui [8], we extracted this information from the tional relational mapper - to have a persistent database layer
tweets we collected and linked them to Foursquare venues in based on a performance-tuned MySQL instance. Slick offers
our database. Based on our Twitter dataset of 29m tweets, a clean way of accessing and filtering persistent data sets
we successfully linked 2.9m tweets to a Foursquare Swarm using Scala’s functional API.
POI. The association rate for the German state of Bavaria Data aggregation is either done through a REST API (if
was 8 check-ins (tweets) per 1,000 POIs and enriched our available) or through one of our crawlers. In the course of
dataset for cities. this research, we have created multiple crawlers and spiders
on top of JSoup to extract knowledge from publicly available
sources. We used Amazon AWS resources to carry out parts
3.2.3 Context of these tasks with on-demand resources, while maintaining
Based on the aggregated knowledge base of items and only one dedicated server at all times. We used SQS, a dis-
check-ins we now want to add a third data source to en- tributed pipe service, to communicate between the different
rich our data with context. We hereby focus primarily on servers.
dimensions of the geographic and temporal context. Given
the timestamp of a single check-in we can infer all attributes 3.4 Mobile Application Design
of the temporal context using a static calendar library. We We have also designed, developed and tested a user in-
therefore use java.util.Calendar to infer season, day of week, terface concept to investigate how to communicate contex-
time of day and time of year. To infer the weather condi- tual information about recommended items to the user in a
tion and temperature of check-ins we added Wunderground’s mobile tourist guide [7]. Thereby, the user can retrieve in-
Weather History API that can be used to provide the weather formation about interesting POIs and review various graphs
for a place at any given time in the past. Using these two about the item popularity in an item detail screen. We show
sources, we were able to infer the temporal and geographic a textual summary of the popularity peak for both weather
context for all check-ins. and day/time. We also render line and bar charts to show
the popularity across different context dimensions, such as
3.3 System Design and Server Implementation day of the week, time of day (see Figure 1 for an example)
We implemented our prototype in Scala using the Play! and season. The mobile application was implemented using
framework. Scala is a language that is executed on top of the cross-platform framework Ionic and is fully functional.
the Java Virtual Machine and is fully interoperable with To receive early feedback for our concept, we evaluated
Java. The language combines object-oriented programming our system in a user study with 14 subjects. The partici-
with functional programming which makes operations on ar- pants were asked to test the application for two weeks and
rays and lists easy to implement. On top, all Java libraries then complete a survey about their experience with the user
are usable in Scala which is a major benefit. The Play! interface elements. The study results indicated that the pop-
ularity inference and graphs provide benefits for users. Users Merging co-referent POIs has been extensively studied
stated that popularity graphs assisted them while deciding and there are multiple approaches to the problem, e.g., us-
which place to visit. More detailed results of this prelimi- ing a fuzzy set and probability theory [12] or a DBSCAN,
nary study can be found in [7]. a common clustering algorithm [6]. The fuzzy set approach
The focus in this paper is not on the user interface but on assumes, that the majority of POIs are user-generated and
how to analyze the collected data and infer insights that can therefore has large differences in between two versions of a
then be integrated in a mobile tourist guide. We present our POI’s name. Our data differs from the assumptions of these
course of action and the gained results of the offline learning papers in a way, that it is already pre-filtered by Yelp and
in the next section. Foursquare. We therefore take a simple approach matching
POIs from different sources: we compare the Levenshtein
4. OFFLINE ANALYSIS AND PROBABIL- distance of the names of the two POIs in question and in-
vestigate their geographic distance.
ITY LEARNING
To infer basic popularities for different conditions we fol- 4.2 Associating POIs with Check-Ins
low the data analytics process proposed by Runkler [11].
Associating POIs with check-ins is a non-trivial task, given
The process decomposes the data analytics pipeline into
that the data comes from entirely different sources. De-
four steps: preparation, preprocessing, analysis and post-
pending on the source of the POI and the check-in, we have
processing. Following this process, we have identified the
identified several ways of creating an association:
following tasks for each step:
1. Preparation: identifying goals and research question; 4.2.1 POIs with Flickr/Twitter Check-ins
data collection. Flickr and Twitter both provide data records that have
2. Pre-processing: merging POIs from different sources; coordinates, a timestamp and some textual data like the
associating POIs with check-ins filtering, sampling and tweet’s content or the Flickr image’s caption. Associating
discretization, normalization. these records with a POI presents a hard problem that can
be tackled in many different ways:
3. Analysis: visualization, popularity inference and pre- Simple Geofencing: The computationally easiest op-
diction. tion is to use a rectangular geofence around a POI and as-
sociate each check-in record within this area with the POI.
4. Post-processing: evaluation. This works well for exposed POIs (i.e., satellite POIs that
To follow this process, we define an overall research ques- have no other POIs around them), but is inapplicable to the
tion and subquestions that we seek to answer. majority of POIs in cities including restaurants and bars.
Advanced Geofencing: To improve both the FPR (false
• Overall research question: how can we learn (infer) the positive rate) and FNR (false negative rate) of the simple
popularity of POIs for a context-aware recommender geofencing approach, we propose a more complex way of
system? setting up the geofence. Depending on the POI’s type, a
more complex geofence structure can range from a smaller
• Subquestion 1: how can POIs from different sources circle (suitable, e.g., for bars or restaurants in cities) to a
be matched and duplicates be eliminated? polygon following the shape of ski slopes or trails.
• Subquestion 2: how can POIs be associated with check- Clustering: can be done in a supervised, unsupervised or
ins? semi-supervised fashion. A supervised clustering approach
would assume that we have a couple of check-ins per POI
• Subquestion 3: given a set of check-ins for a POI, how where we have obtained evidence that they belong to this
can we infer the popularity under different temporal POI. Other nearby check-ins could be associated using algo-
conditions? rithms like KNN (see Evidence-based Clustering below). An
unsupervised approach could use algorithms like DBSCAN
• Subquestion 4: given a set of check-ins for a POI, how to discover clusters in unclassified data. Once the algorithm
can we infer the popularity under different geographic has discovered clusters, we could use different techniques to
conditions? associate POIs with clusters.
• Subquestion 5: given a set of check-ins for a POI and Evidence-based Clustering: As mentioned with simple
the base popularities, which algorithms are suitable for clustering, one approach could be to use supervised or semi-
making a compound decision/recommendation? supervised clustering for association. To start this algorithm
we would need a base dataset of check-ins that are associated
In the following, we present our approaches and results on with POIs. One approach to generate such a dataset would
these tasks according to the subquestions we are trying to be to use evidence from the metadata. Most tweets/Flickr
answer. descriptions contain the topic of the tweet or image such
as ”Neuschwanstein”. Using simple word-matching or more
4.1 Merging POIs from Different Sources complex NLP techniques we would obtain a base set of
We have added different POI sources to our system, in- check-ins to use for clustering and association.
cluding Foursquare, Yelp and Quermania. Especially Four- We use Flickr and Twitter check-ins for exposed sights to
square and Yelp provide a lot of overlapping data, since both deliver a proof of concept for our pipeline and model and
have restaurants and bars in their database. This leaves could therefore use simple geofencing to associate check-ins
us with the problem of identifying and merging co-referent with POIs (by a square whose size depends on the POI type).
POIs, as we do not want to show or recommend the same Our approach has linked 280,983 check-ins with 177 sights.
POI multiple times. While this approach was sufficient for our use case, future
work could lie in exploring other association techniques to ble to infer.
make using these check-in sources viable for more densely We therefore explored related work on activity duration
populated areas. [8] to assign a presence window to each check-in accounting
for the time a user was present at the POI. The activity du-
4.2.2 Foursquare POIs to Check-ins using Twitter ration depends on the POIs category and ranges from 7:43
As briefly outlined before, Melia and Segui [8] proposed an min for breakfast to 19:01 min for dinner. Parks and out-
approach to aggregate public Foursquare (Swarm) check-ins door have a mean activity duration of 11:21 min. Given
using Twitter. Foursquare users that have linked their ac- this knowledge, we set a bucket-size of 5 min and count the
count with Twitter will automatically publish a tweet if they check-in towards three buckets for sights. In this approach
check-in publicly. By analyzing the corresponding tweets we model a user’s presence at a given time by adding 1 to
using our data processing pipeline, we obtain the unique three buckets. With this information, we can accurately an-
Foursquare ID of the POI where the user checked-in. In ad- swer questions in the form of ”How popular is this POI at
dition, we obtain the timestamp of the tweet and hence the 10:11am?”, as we have a bucket ranging from 10:10:00am to
check-in. 10:14:59am. However, with this model we neglect the uncer-
This approach is promising, as it established a definitive tainty at the beginning and end of the activity interval. The
relation between a check-in and a POI (i.e., there are no source of this uncertainty is the fact, that we only know one
false-positives). We have aggregated a mixed data set of timestamp and infer the user presence window through (as-
tweets containing both geo-located tweets and tweets linked sumed) activity durations yielding a high uncertainty at the
to public Foursquare and Swarm check-ins using the stream- beginning and end of this interval. An alternative modeling
ing API over eight weeks. The dataset has 29m tweets approach could be to use Gaussians to augment presence
in total, 2,9m of which we have successfully linked to a intervals. This way, we can model the uncertainty in a sta-
Foursquare or Swarm POI. tistically correct way.
Our prototype only incorporates POIs in the German State We regard the Gaussian modeling as future work and
of Bavaria. We could therefore only use a small subset of base our presence interval on activity durations without aug-
the 2.9m tweets that link to a POI in our region. We could menting Gaussians. We introduce feltTemperature as a dis-
match tweets and POIs at a rate of 8 check-ins (tweets) per cretization of the continuous temperature as this simplifies
1,000 POIs. This number is relatively low compared to the inference and makes our predictions easier to understand for
effort it took to obtain the data using the pipeline we out- users. Table 1 shows our set of inferred contextual variables
lined earlier. While this was not an ideal fit four our use case, for both the geographic and temporal context.
the approach can be a better choice in regions with higher
Foursquare adoption (such as New York or San Francisco). Variable Type Domain
dayOfWeek D {Mon,...,Sun}
4.3 Filtering, Sampling and Normalization timeOfDay C [0,23]
Until this point, we have crawled POIs, check-ins and con- season D {Spring,Summer,Fall,Winter}
text and associated POIs with check-ins. The next step is to {Hot,Warm,Pleasant,
feltTemperature D
filter the dataset to increase its quality, decide on sampling Mild,Cold,Freezing}
for context parameters and perform normalization if needed. weatherCondition D {Sunny,Cloud,Rainy,Snowy}
Filtering: For the qualitative evaluation and our mobile
app prototype we focus on exposed sights out of our large Table 1: Temporal/Geographic Dimensions for Sam-
POI dataset and have identified 176 sights with a high POI pling. D=Discrete, C=Continuous
to check-in matching having both a low FNR and FPR. Fur-
thermore, we filter out POIs that have less then 400 check-
ins (on average each POI has 1570 check-ins) to retain a Normalization: Figure 2 shows an aggregation of all of
good accuracy for all contextual popularities. All contextual our check-ins on a weekly basis using the presence window
popularity groups partition the remaining check-ins into a approach based on a presence window of 1 hour. One can
maximum of 7 groups yielding 57 check-ins on average per clearly see from the graph, that about twice as much check-
group. This filtering gives us a set of 114 sights in the greater ins are made during weekends, than there are on a weekday.
area of Munich and the German State of Bavaria that we use We have therefore thought about normalizing the data as
for further processing. a whole to have the same relative amount of check-ins per
Sampling: The next step to aggregate the popularity is discrete bucket (e.g. Mon-Fri).
to define what dimensions should be explored and if a dimen-
sion is continuous or discrete. We hereby explore temporal
and geographic dimensions separately. Discrete variables are
easy to handle when it comes to inferring the popularity, as
they can be represented by a fixed number of buckets (e.g.,
seven for Day of Week ) and assigning check-ins to buckets is
trivial. Continuous variables however, are more difficult as
questions like ”How popular is this POI at 10am?” can not
be holistically answered using sampling and buckets, since
when settling on a fixed bucket size (e.g., half an hour) the Figure 2: All Check-ins Aggregated on a Weekly
question ”How popular is this POI at 10:11am?” can not View
be answered accurately. When decreasing the bucket-size,
buckets will only have a few check-ins as a check-in only After investigating our data in close detail, we decided
marks a specific timestamp making the popularity impossi- against normalization as users tend to visit more POIs on
Figure 4: Popularity
into temporal and geographic dimensions and their respec-
tive parameters (temperature t, weather condition wc, sea-
Figure 3: Geofilter Analysis son s, weekday wd, etc.). This yields probabilities of the
form:
the weekends/evenings when they spend leisure time. We p(P |t), p(P |wc), p(P |s), p(P |wd) (2)
therefore anticipate, that the weekend cliffs (as well as some
Having these base popularities would allow for compound
other data patterns) are correct and beneficial for the sake
calculations yielding the probability for a visit V to a certain
of popularity inference.
POI given a situation with fixed contextual parameters:
4.4 Visualization, Popularity Inference and Pre- p(V |C, P ) (3)
diction
The concept of a visit is that given that a user will cer-
4.4.1 Visualization tainly visit a POI, what is the probability that the visit will
happen at the context C.
To effectively visualize our data, we created multiple anal-
There are different approaches to model the statistical de-
ysis tools based on our server-side software. For effective
pendence of context factors like weather condition and tem-
analysis of the check-in data we build a tool to visualize dif-
perature (e.g., it does not snow when having 20◦ C) including
ferent features of geo-based check-ins without an association
Bayesian networks. While a full Bayesian model can increase
to any POI. Our tool, as depicted in Figure 3, is able to ap-
accuracy, it requires a high degree of domain knowledge
ply a geofence to filter check-ins and compare the selected
about the data and all parameters that is hard to obtain.
area to a baseline of all known check-ins which makes it easy
We therefore use summation to infer the plain popularities
to spot interesting patterns. Figure 3 shows all check-ins on
for each context parameter:
a weekly level for the northern end of Starnberger See. This
is a good example for the effectiveness of our tool, showing p(P |wd = M onday, V = W alhalla) (4)
that this part of the lake is popular on Friday afternoon as = p(wd = M onday|V = W alhalla) (5)
well as on the weekend.
After an initial analysis using these tools, we started to
model the popularity inference. For this purpose, we created p(wd = M onday|V = W alhalla) (6)
P
different views, such as the one depicted in Figure 4, to vi- CheckinsF orP OIOnM onday
sualize the inference outcome. Our view shows the probabil- = P (7)
CheckinsF orP OI
ities (popularities) under different temporal and geographic
conditions highlighting them with a gradient in red color
such that one can easily spot patterns in the data. This approach yields a probabilistic distribution for each
POI and each context dimension as depicted in Figure 4
4.4.2 Popularity Inference which lets one judge under which conditions a place is pop-
Until this point, our analysis and visualizations yielded ular. We can use prediction and the Bayes’ theorem to make
promising patterns. We now take a probabilistic approach compound recommendations.
to infer popularities for different contextual situations. The
outcome we seek is the popularity P of a POI given a context 4.4.3 Prediction
C: With prediction or recommendation, we seek to answer
p(P |C) (1) the question ”Where should I go (given the current times-
tamp and weather)?”. With respect to our model, this would
When thinking about context and different dimensions as mean: what is the probability (or score) that I should choose
described before it would be most beneficial to split up C a POI for my visit V given the inferred popularities of all
POIs P and the current context C: when being relatively unpopular and therefore used weighted
additive scoring.
p(V |C, P ) (8)
Using either one of those strategies leaves us with a prob-
We propose two different approaches to answer this question: ability (popularity) for each POI in the database, which can
weighted additive scoring and using the Bayes’ theorem. be used for ranking in combination with a standard weighted
additive scoring approach for recommending a POI based on
Weighted Additive Scoring. the different context factors.
The first approach to obtain a popularity score given a
context situation C is to use weighted additive scoring.
4.5 Evaluation of Post-Processing
We discussed different types of evaluations for this part of
X our research with peers from the field of machine learning.
S(C, V ) = αi p(i, V ) (9) While machine learning and data analytics applications are
i∈[wc,t,d,s,h] usually evaluated using cross-validation or any other sort of
For each POI we add the popularity for a specific set of quantitative offline evaluation, we did not see a fit for these
context dimension (weather condition wc, temperature t, types of evaluations given our data and inference schema.
day d, season s, hour h) that we want to predict a score for. We therefore decided to first evaluate our research by qual-
Furthermore, we multiply each dimension by a weighting itatively assessing inferred popularities for selected results
factor α to make the model flexible. While we used static in a case study and discussing interesting findings and pat-
weights, future work could include learning of α through terns. The ultimate goal is to integrate the results about
online of offline learning techniques. item popularities into the mobile application (see Subsec-
While this model works well, it does not respect the dif- tion 3.4) and conduct a large-scale user study to get real
ferent number of check-ins between POIs. Thus a POI with feedback.
only 400 check-ins might outperform a POI with 4,000 check-
ins, as the popularity values are better, while - in absolute Inferred Seasonal Popularity.
visitor numbers - the second POI outperforms the first. This The inferred seasonal popularity performed best among all
issue is addressed by an approach using Bayes’ theorem. our inferred parameters. An excerpt of the POI data with
seasonal popularity is shown in Table 2. While cities like
Bayes Theorem. Bad Tölz or Nürnberg are equally popular throughout the
Bayes’ theorem can be used to inverse a dependent prob- year, other sights peak in certain seasons. Kehlsteinhaus for
ability. Using summation to obtain the base probabilities as instance - a tea house built for the Third Reich government
outlined in the previous section yields probabilities in the that has been turned into an exhibition - is closed during
form of: spring and winter (November - April), as the road can not
be maintained as soon as there is snowfall. It can be easily
p(wd = M onday|V ) (10) seen that this shutdown persists in the data making the
sight less popular during winter and spring. Other places for
In other words, this means: ”given that I visit a POI, what
outdoor activities show a clear tendency towards the warmer
is the probability I would visit it on Monday?” (or: ”what
periods of the year, including Walchensee (being popular
is this POI’s Monday popularity”). When recommending
during Summer and Fall), Starnberger See (Summer) and
items, we would like to answer questions of ”It is Monday,
Königssee (Summer and Fall).
which POI should I visit?”:
p(V |wd = M onday) (11) POI Name Spring Summer Fall Winter
Bad Tölz 0.215 0.202 0.215 0.368
So for a concrete POI (Walhalla) we can use Bayes’ theorem
Nürnberg 0.238 0.242 0.295 0.226
to get the probability for a visit given our limited set of POIs
Walchensee 0.076 0.456 0.291 0.177
and the premise that the user will visit one of these:
Kehlsteinhaus 0.044 0.572 0.35 0.034
p(V = W alhalla|wd = M onday) Starnberger See 0.003 0.932 0.045 0.019
p(wd = M onday|V = W alhalla)p(V = W alhalla) Kloster Andechs 0.314 0.253 0.365 0.067
= (12) Königssee 0.193 0.367 0.305 0.135
p(wd = M onday)
All of the parameters from this model can be retrieved from Table 2: Excerpt of Inferred Seasonal Popularity:
our dataset: p(V |s, P ). µ = 1, 660 Check-ins
p(wd = M onday|V = W alhalla) (13)
(as obtained in the previous section)
P Inferred Weather Condition Popularity.
CheckInsAtW alhalla
p(V = W alhalla) = P (14) The weather condition overall has a clear tendency to-
AllCheckIns wards sunny weather, with more then 90% of the dataset
P having a sunny popularity of 0.5 or higher. Nonetheless,
AllCheckInsOnM onday there are still some patterns to get indications if the infer-
p(wd = M onday) = P (15)
AllCheckIns
ence technique is correct. While cities like Munich are within
our average (mostly sunny), places for outdoor activities like
Starnberger See, Andechs or Almbachklamm have a notably
We found, that using a Bayesian approach disproportion- higher sunny popularity. Table 3 shows an excerpt from
ally favors POIs that have a high number of check-ins even inferred weather condition popularities.
POI Name Sunny Cloudy Rainy Snowy Unkn.
Munich 0.532 0.138 0.324 0.005 0.001
Andechs 0.711 0.072 0.209 0.006 0.002
Roseninsel 0.796 0.127 0.072 0.005 0
Almbachkl. 0.907 0 0.093 0 0
Table 3: Excerpt of Inferred Weather Condition
Popularity: p(V |wc, P ). µ = 1, 750 Check-ins
5. CONCLUSIONS AND FUTURE WORK
In this work, we have designed and implemented a data
analytics process to infer the popularity of POIs for a context-
aware recommender system using publicly accessible data
from various data sources. We have elaborated different ap-
proaches on individual subtasks, e.g., applying probabilistic
modeling to learn the popularity for POIs in different con-
textual situations such as weather condition, day of week
and time of day. We qualitatively evaluated our approach Figure 5: Heatmap for Neuschwanstein Castle
in a case study and also implemented a corresponding mobile Based on Check-in Data
application with a brief preliminary user study [7].
In addition to the explained results, we discovered other
useful purposes for the dataset and the inferred information. [6] M. Daszykowski and B. Walczak. Density-Based
For example, to determine and visualize popular areas on Clustering Methods. Comprehensive Chemometrics,
a map. This could be useful for visitors to find spots for 2:635–654, 2010.
taking iconic pictures or maybe find a less-crowded spot and [7] P. Hiesel, W. Wörndl, M. Braunhofer, and D. Herzog.
avoid the most popular areas. To do so, we filtered our data A User Interface Concept for Context-Aware
by first selecting the check-ins associated with a POI and Recommender Systems. In Mensch und Computer
then applying another filter to eliminate check-ins with an 2016 Tagungsband. De Gruyter, 2016.
accuracy worse then 10 meters. Then this filtered dataset is [8] J. Melià-Seguı́, R. Zhang, and E. Bart. Activity
fed into a heatmap algorithm for visualization using Google duration analysis for context-aware services using
Maps’ heatmaps extension. Figure 5 shows popular (photo) foursquare check-ins. In Proceedings of the 2012
spots around Neuschwanstein Castle as an example. international workshop on Self-aware internet of
Future work includes integrating the item popularities things, pages 13–18, 2012.
into the mobile tourist guide application and proactively [9] M. Pielot, L. Baltrunas, and N. Oliver.
recommending POIs based on the current user context. We Boredom-triggered proactive recommendations. In
then plan to conduct a larger user study to investigate whether Proceedings of the 17th International Conference on
this approach leads to useful and timely recommendations Human-Computer Interaction with Mobile Devices and
from a user’s perspective in a real setting. Another area for Services Adjunct, pages 1106–1110. ACM, 2015.
improvement is not to solely rely on explicit user check-ins [10] F. Ricci, L. Rokach, B. Shapira, and P. B. Kantor.
but also utilize tracking data from smartphones. Recommender Systems Handbook. Springer Verlag,
New York, NY, USA, 2010.
6. REFERENCES [11] T. A. Runkler. Data Analytics: Models and Algorithms
for Intelligent Data Analysis. Springer, 2012.
[1] G. Adomavicius and A. Tuzhilin. Context-aware [12] G. D. Tre and A. Bronselaer. Consistently handling
recommender systems. In Recommender systems geographical user data: Merging of coreferent POIs. In
handbook, pages 191–226. Springer, 2015. Proceedings of the 2010 Annual Meeting of the North
[2] L. Baltrunas, B. Ludwig, S. Peer, and F. Ricci. American Fuzzy Information Processing Society
Context relevance assessment and exploitation in (NAFIPS), 2010.
mobile recommender systems. Personal and [13] D. G. Vico, W. Wörndl, and R. Bader. A study on
Ubiquitous Computing, 16(5):507–526, 2012. proactive delivery of restaurant recommendations for
[3] J. Borrı́s, A. Moreno, and A. Valls. Review: Intelligent android smartphones. In ACM RecSys workshop on
tourism recommender systems: A survey. Expert Syst. personalization in mobile applications, Chicago, USA,
Appl., 41(16):7370–7389, Nov. 2014. 2011.
[4] M. Braunhofer, M. Elahi, and F. Ricci. Usability [14] W. Wörndl, J. Hübner, R. Bader, and
assessment of a context-aware and personality-based D. Gallego-Vico. A model for proactivity in mobile,
mobile recommender system. In E-commerce and web context-aware recommender systems. In Proceedings of
technologies, pages 77–88. Springer, 2014. the fifth ACM conference on Recommender systems,
[5] N. Dali Betzalel, B. Shapira, and L. Rokach. Please, pages 273–276. ACM, 2011.
not now!: A model for timing recommendations. In
Proceedings of the 9th ACM Conference on
Recommender Systems, pages 297–300. ACM, 2015.