Recommendation systems (RSs) are increasing their popularity in recent years. Many big IT companies like Google, Amazon and Netflix, have a RS at the core of their business. In this paper, we propose a modular platform for enhancing a RS for the tourism domain with a crowding forecaster, which is able to produce an estimation about the current and future occupation of diferent Points of Interest (PoIs) by taking into consideration also contextual aspects. The main advantage of the proposed system is its modularity and the ability to be easily tailored to diferent application domains. Moreover, the use of standard and pluggable components allows the system to be integrated in diferent application scenarios.
given item and to redirect people to other attractions, which are equally appreciated, but are
less in demand at the moment [
In this paper we present the architecture of a context-aware recommendation system
(CARS) [
The general architecture of the proposed solution is illustrated in Fig. 1. In the first phase
represented by box 1, the historical user data and the historical contextual data are integrated
and processed in order to produce an enhanced dataset of integrated contextual historical data
(operation 1). This new dataset is used as a training input for the deep learning crowding
forecaster discussed in [
Historical data op1 Historical contextual info
POIs op2
Context Contextual historical data training
M1 B1
Crowding Forecaster Model
B2
Real-time queries execution
M1
Crowding
Forecaster Model require retraining
Occupation Forecast
Analyze performances
B3
Context-aware Recommendation Apps
WFS
T-DB
User Preferences
POIs
Description Current Occupation
The remainder of this work is organized as follows: Sect. 2 formalizes the problem, Sect. 3 describes in detail the architecture of the developed system. Sect. 4 illustrates a possible application of the system in the touristic domain and finally Sect. 5 concludes the work.
This paper considers the touristic domain as the application scenario for our context-aware recommendation system. Therefore, the formulation that follows is tailored for that scenario, but can be easily extended to other domains.
Definition 1 (Touristic visit). Given a set of POIs and a set of users , a visit performed by a user is represented as: = ⟨, , , , ⟩ where: ∈ is the user identifier, ∈ identifies the POI, is a timestamp representing the date and time of the visit, and and is the spatial position (i.e., latitude and longitude) where the POI is located. The set of all touristic visits performed by users in is denoted as .
Historical data about past touristic visits can be enriched with some contextual information better characterizing the conditions in which the visit has been performed.
Definition 2 (Contextual information). Given a visit ∈ , we define its context as a tuple of values for some relevant dimensions as follows: = ⟨1, . . . , ⟩ where each is the value of a contextual dimension characterizing the problem at hand.
In our specific scenario regarding the touristic domain, we consider as meaningful contextual dimensions the tuple: = {, , , ℎ, , , , , ℎ} where is a predefined timeslot inside the day, is the day of the year, is the day of the week, ℎ is a boolean value representing the fact that the visit is performed in a public holiday and/or during a weekend, or not, is the atmospheric pressure, is the wind speed, is the amount of precipitation, is the temperature, and ℎ is the percentage of humidity. Definition 3 (Contextual touristic visit). Let = ⟨, , , , ⟩ a visit performed by a user in a specific context = ⟨1, . . . , ⟩, where ∀ ∈ {1, . . . , } is the actual value for the contextual dimension , a contextual touristic visit is defined as: = ⟨, , , , , 1, . . . , ⟩ (1) where the tuple representing the touristic visit is enriched with the contextual values in . Definition 4 (Crowding forecaster). A crowding forecaster is a system that once trained with historical data about contextual touristic visits is able to produce an estimate of the level of crowding for a PoI in a context .
The crowding forecaster is an essential ingredient for the development of a context-aware recommendation system.
Definition 5 (Context-aware Recommendation System). A context-aware recommendation system is a recommendation system which is able to produce useful recommendations by considering not only users’ preferences, but also the expected current (or future) level of crowding in the considered set of PoIs.
This section illustrated each component of the proposed framework.
The first operation performed by the CARS framework is the production of the contextual historical data which will be used to train the DL model. This operation is identified as 1 in Fig. 1. More specifically, besides collecting the past logs about users’ choices, it is necessary to identify the sources of information that represent the relevant context for the problem at hand.
In our target scenario, we consider historical data about past touristic visits and we enrich
them by deriving some semantic temporal information from the timestamp and by adding
information about the weather condition in each specific visit interval. Weather conditions are
extracted through the API of OpenWeather [
The integration of raw historical data and historical contextual information produces the enriched contextual historical data described in Def. 3 and reported in box 1 of Fig. 1 as the input for the training of DL model 1.
The crowding forecaster is implemented as a DL model trained with the contextual
historical data produced in the previous section. In [
The trained model is then used to forecast the occupation of each POI in a given context. More specifically, at specific intervals, the future context is retrieved (weather conditions and temporal characterization), and the model is queried in order to produce an estimation of the future level of occupation of each PoI. With reference to box 2 in Fig. 1, given the PoIs and the desired context, operation 2 is responsible to combine them in order to define a query for the forecast model 1. The execution of model 1 produces a collection of occupation forecasts, one for each PoI in the given context, which is stored in the database T-DB together with other information, like the POI descriptions and the user preferences. As regards to the PoI occupation, the database T-DB is filled not only with the obtained forecast but also with the current (or past) data about occupancy. This information can be made available to users, but it is also useful for evaluating the accuracy of past forecasts and eventually determining the need for a new training of 1, if the estimation becomes inaccurate.
A Web Feature Service (WFS) is an interface specified by the Open GIS Consortium (OGC) that
allows for the exchange of geographic data across the Web [
Occupation forecasts produced by model 1 and stored in T-DB can be used alone or in conjunction with information about the user preferences in order to produce a context-aware recommendation. In Fig. 1, box 3 contains diferent kinds of applications which can use the data stored in T-DB and exposed through a WFS. These applications are called context-aware recommendation apps, since they will produce tailored recommendations by combining user preferences with the expected level of occupation of the PoIs in the given context. In Fig. 1 we abstract from the details of the recommendation system which produces and stores the user’s preferences. Clearly, many diferent tools can be plugged here to obtain this kind of information.
For the demonstration of CARS, we use a real-world touristic dataset regarding the visits performed to a collection of PoIs in Verona, a city in northern Italy. First of all, for the operations in box 1 of Fig. 1, we collected about 2,1 million records spanning 6 years (i.e., from 2014 to 2019) regarding the visits performed in 9 diferent PoIs. Each of these records contains the timestamp and the location of the visited attraction, as well as a category (i.e., Museum, Monument and Church), see Tab. 1 for more details. This historical dataset is enriched with the contextual information regarding the weather conditions and temporal characterization described in Sect. 2. In order to produce a context-aware recommendation, CARS needs also to know the preferences of each user with respect to the various POI categories in the dataset. At this regard, we collect the preferences of a set of users and store them in the database.
Given the trained model 1, we use a Python script to periodically query the model for each PoI and in a desired temporal and weather context. The obtained results are stored in a PostgreSQL database with PostGIS extension. Fig. 2 illustrates the interface of the GeoServer (https://geoserver.org/) tool used to configure the WFS and expose the database content. preference of for a PoI ∈ is computed as
In order to illustrate the system functioning, we implement the recommendation application illustrated in Fig. 3. Each authenticated user can see his/her position on the map and can obtain a suggestion for the next PoI to visit based on his/her preference for the various attraction categories and his/her proximity of the various PoI. More specifically, given a user ∈ , the (, ) = (, ) · 1
1
(, ) · (1 + #)
where (, ) measures the spatial distance between the POI and the user , while (, )
is the preference of the user for the category of , and # is the number of times the user
has already visited in the past. The spatial distance is computed by considering the road
network and using the libraries OSMnx [
Given such definition of preference of a user for a PoI , we can also introduce the expected level of crowding produced by the model 1 in the final computation. Therefore, the contextual preference of the user for the PoI in the context becomes: * (, , ) = (, ) · ︂( 1 − (, ) )︂ () where (, ) is the static preference defined in Eq. 2, while () is the maximum capacity of the PoI , namely the maximum number of visitors it can host and (, ) is the estimated number of visitors determined by the crowding forecaster 1 for PoI in the context . (2) (3)
The web application illustrated in Fig. 3 allows us to demonstrate the potentiality of the framework and in particular to compare the diferent suggestions produced by using either Eq. 2 or Eq. 3, namely by considering only the users’ preferences or also the level of crowding. The general interface of the application consists on a web map where the user’s position is highlighted with a blue placeholder, while the location of each PoI is denoted with a placeholder whose color represents the diferent levels of occupation: green means quite empty, yellow means normally occupied, while red denotes an overcrowded situation. At the top of the map, there are some input fields that allow the user to specify the spatial and temporal context of the visit: the user identifier and position, and the desired date for the visit. The user position can be specified both textually or by performing a selection on the map. Finally, the button Suggest applies Eq. 2 and Eq. 3 for producing the static and contextual recommendation, respectively. The system returns two lists with the first three best PoIs for the user: each row has a color depending on the level of occupation of the PoI in the given date, and it reports the preference of the user for the PoI category as a set of stars, from 1 to 3, as well as the distance of the PoI from the current user position.
As an example we report in Tab. 3 the diferent suggestions produced in two diferent contexts 1 and 2. More specifically, for 1 we choose a sunny day during the weekend, while for 2 we consider a sunny Thursday, which is one of the quieter days in terms of tourist visits. The level of occupation of each PoI in the two contexts is described in Tab. 2. As you can notice in 1 there are some PoIs, like P7 and P13, that are overcrowded, while others like P2 and P11 that are average occupied. Conversely, in C2 all occupation rates are below 50%.
Tab. 3 shows diferent static and contextual recommendations suggested to two users 1 and 2 in these two contexts. Besides to the three suggested PoIs, it reports the distance of each PoI from the user position and the user preference for the PoI category (3 is the maximum value and 1 is the minimum value). We can notice that in context 1, PoI 7 has a level of occupation close to saturation; therefore, even if 1 has a greater preference for it, the system suggests 2 in place of 7. Similarly, for 2 even if 7 is spatially closer to user’s position, it does not appear in the contextual suggestions. Conversely, in context 2, PoIs are typically unloaded and the set of suggestions is the same for both static and dynamic approaches.
In this paper we have presented the possible architecture of a context-aware recommendation system enriched with a crowding forecaster. This system is able to produce a set of dynamic suggestions to users where the preference associated with each item depends also on its level of occupation in diferent contexts. The use of a contextual crowding forecaster allows producing more precise estimations and more personalised and useful suggestions. The system is currently under experimentation as a prototypical touristic application developed in conjunction with the Touristic Ofice of Verona, in Italy.