In this paper, we present the design and implementation of DrIveSCOVER, a recommender system for places and events in case of an in-car use, where the driving conditions such as weather and local tra c are taken into account. We integrate multiple data sources using semantic technologies and we devise recommending functions that are presented in a web-based application. Data is organized according to ve root classes: accommodation, car amenity, events, gastronomy and points of interest. An interest score is calculated from the weighted user inputs in terms of preferences of classes and driving conditions. The application is available at http://drivescover.eurecom.fr/.
Recommender systems in the context of driving mobility present a new
challenge when taking into account numerous real world external factors. This
topic is especially relevant considering the challenge of third-party integration
in location-based services that can support the driving experience, as well as
semantic mobility learning patterns that use places as nodes between trips [
We aim to integrate web data [
The remainder of this paper is organized as follows. Section 2 presents our approach for integrating multiple web data sources. Section 3 describes our recommender system and the interest score calculation.
We selected ve root classes that represent the traveler needs: { Accommodation: integrating data using the Foursquare API1 { Gastronomy: integrating data using the Foursquare API { Car amenity: integrating data using the LinkedGeoData SPARQL endpoint2 { Events: integrating data using the OpenAgenda API3 { Points of interest: integrating data using the DBpedia SPARQL endpoint4
We implemented a single-page web application called DrIveSCOVER5, built on top of a MEAN stack6 (MongoDB, ExpressJS, AngularJS, NodeJS). First, the user de nes an itinerary from an origin to a destination for a certain date and time. On the server side, the GoogleMaps APIs are used for computing the route that re ects the input. For each route point, we look for nearby places that belong to the selected classes. In order to consider places only around estimated break areas, we look for route points around the areas where the vehicle is expected to be after the regular driving time between breaks T 2hours with an uncertainty T . The resulting segments allow us to do query, integrate, score and recommend in a separate way for each cluster. Then, the results are displayed on a map, with the details on each selected place.
If the origin A and the destination B are located in di erent countries, DrIveSCOVER will take that into account and will retrieve information in English if possible, and in the local language if English is not available. 3
A JavaScript function calculates the recommendation score using di erent features: matching classes C with weights WC , tra c quality in the direction of the place t, quality of the weather w based on temperature wT and humidity wH , arrival during the opening hours h, and existing rating r.
score = [WC
C] h (w + r + t) 8 0 if arrivalT ime \ opening hours = ? h = < 1:5 if arrivalT ime \ opening hours 6= ?
: 1 else r = 0 if undef ined exisiting rating between 0 and 1 if available 1 https://developer.foursquare.com/ 2 http://linkedgeodata.org/About 3 https://openagenda.com/ 4 http://wiki.dbpedia.org/ 5 http://drivescover.eurecom.fr 6 https://www.mongodb.com/blog/post/the-mean-stack-mongodb-expressjs-angularjs-and w = jwT wT idealj + jwH 2
wT Hidealj wT ideal = 20 C; wHideal = 50%
Tra c and weather quality are extracted from the Here.com API. Some ratings for Accommodations and Gastronomy places are available for places described in the Foursquare database. In case of Points of Interest, the places are always linked to Wikipedia articles describing them and the page ranking7 is used as a rating.
If we study a trip from an origin A to a destination B that contains at least one break, and assume that every break i will happen in a short proximity from a town or city Ci. the application will suggest places at the beginning and end of a trip from Ci to Ci+1. For instance, a morning trip or an evening trip containing a need for an accommodation will result in di erent suggestions: in the rst con guration, the score will put forward restaurants for a lunch break and avoid cities if there is a break expected during the morning tra c congestion time, while in the second con guration, the same avoidance will happen at the end of the afternoon, and then places of type \accommodation" will likely be suggested.
More practically, DrIveSCOVER would recommend two places along a route between Paris and Lyon. It is illustrated in Figure 1 for a journey planned on the 28 July 2017 with sights and events as stop preferences. The rst cluster happens in an area with a small density of events and points of interests, so there are no alternatives suggested. In contrast, for the second cluster, numerous choices are proposed in the dense area of Lyon. 7 http://people.aifb.kit.edu/ath/
In order to validate the accuracy of DrIveSCOVER, users will be asked to ll static forms about places they would like to have been recommended. Since it is a problem of top N recommendations, we calculate the precision and recall de ned by: P recision = jLu(NN)\T Suj Recall = jLu(jNT S)\uTj Suj where Lu(N ) is the recommendation list up to the N th element, and T Su is a set of relevant test items. This quantitative evaluation will be completed with a qualitative one with two questions: Were the recommendation surprising? Would you have followed such a recommendation?
We will evaluate DrIveSCOVER on several pre-de ned routes:
Origin Destination Duration Number of stops Paris Lille 3 hours 1 Paris Lyon 4.5 hours 2 Nice Florence 5 hours 2 Paris Marseille 7 hours 3
Nantes Strasbourg 8 hours 3 5
We have seen that web data can provide useful information that can be combined to be really bene cial to a driver looking for places and events during breaks on a long trip. In order to improve our data coverage, we plan to use more complex data integration methods that make use of both static and live data streams. In order to increase the accuracy of the recommender system, we plan to use car simulators that generate numerous GPS traces in order to simulate alternative recommendations. Finally, a user evaluation is in progress.