request, instead of providing a list of recommended tours. DIG also utilizes the content-based approach for building the recommendations(Burke, 2007), just as the previous one The George Square system Brown et al., 2005)runs on handheld tablet PCs. It is designed for supporting visitors to explore a city as well as share their visit experiences. As the user moves in the city and visits the attractions, her positions and activities are automatically recorded (logged )by the system. The user's activities include the attractions she encounters, the web pages (i.e, weblogs created by previous visitors she browses, and the photographs she takes. To build the recommendation list, the system makes use of patterns of co-occurrence of positions and activities, and employs the collaborative filtering recommendation technology(Adomavicius Tuzhilin, 2005). In particular, the system uses the user's recent activities (i.e, in the last few minutes) to define the user's current context, then finds in the previous visitors' log data those periods of time with similar contexts, and finally includes in the recommendation list the activities done in those periods of time by these visitors. In addition, when showing the recommended items (i.e, attractions, web pages, photographs) on the map, the system displays the positions of nearby visitors and supports their leisure collaboration. For instance, the system let the user to collaboratively producing pictures of the attractions, or to have(voice-over-IP)discussions on co-interested attractions and object Mobile Piste Map (dunlop et al., 2007)is designed to support mobile users in selecting ski routes,i.e dividual or combined runs appropriate to their level of ability, preferences, and current mood and track conditions. The system first asks the user to indicate her ski-run preferences, for instance the route difficulty level, and then uses the indicated preferences to compute a list of recommended routes. The system presents on the map the recommended routes and their suitability for the user Park et al.(2007) presents a restaurant Rs for mobile users. The system computes personalized recommendations using a Bayesian Network(Pourret et al., 2008 )that models the probabilistic influences of the input parameters, i.e., the user's personal and contextual information, in relation to the restaurant attributes. This approach represents a restaurant by three discrete-valued attributes: class (e.g, Korean or Italian restaurant), price(e.g, low or medium), and mood(e.g, romantic or tidy The Bayesian Network is defined by an expert, and is trained using a training dataset. To begin with, each user is required to provide personal information(e.g, age, gender, income, preferred restaurant class, etc. ) The users contextual information is automatically collected (detected) by the system, including season(e.g, spring), time in day (e.g, breakfast), position, weather(e.g, sunny), and temperature(e.g, warm). When a user requests for a restaurant recommendation, the system computes the recommendation score for all the restaurants in the database. A restaurants recommendation score is a weighted sum of the conditional probabilities of the restaurant's attribute values, where these conditional probabilities are derived (inferred) from the learned Bayesian network. The system presents on the map a small set of the restaurants,i.e, those achieving the highest recommendation scores Research Goals The main goal of our research work is similar to that addressed by the papers presented in the previous section,i.e, to provide personalized suggestions for travel products and services to mobile travelers, and to use the map as primary tool for visualizing these suggestions. However, our approach differs in the following aspects In our approach, the recommendation process begins with the user specifying explicit preferences, however, this user input is optional in our system, i.e., the user can obtain some recommendations even without explicitly providing any initial input. The main rationale for this esign solution is that the users preferences can be also acquired during the product search interaction phase, using the critiquing function( discussed in details in the next section) and exploiting the knowledge derived from the previous recommendations. We note that in all the referenced approaches either it is mandatory for the user to input initial preferences(Dunlop et
6/22 request, instead of providing a list of recommended tours. DTG also utilizes the content-based approach for building the recommendations (Burke, 2007), just as the previous one. The George Square system (Brown et al., 2005) runs on handheld tablet PCs. It is designed for supporting visitors to explore a city as well as share their visit experiences. As the user moves in the city and visits the attractions, her positions and activities are automatically recorded (logged) by the system. The user’s activities include the attractions she encounters, the web pages (i.e., weblogs created by previous visitors) she browses, and the photographs she takes. To build the recommendation list, the system makes use of patterns of co-occurrence of positions and activities, and employs the collaborative filtering recommendation technology (Adomavicius & Tuzhilin, 2005). In particular, the system uses the user’s recent activities (i.e., in the last few minutes) to define the user’s current context, then finds in the previous visitors’ log data those periods of time with similar contexts, and finally includes in the recommendation list the activities done in those periods of time by these visitors. In addition, when showing the recommended items (i.e., attractions, web pages, photographs) on the map, the system displays the positions of nearby visitors and supports their leisure collaboration. For instance, the system let the user to collaboratively producing pictures of the attractions, or to have (voice-over-IP) discussions on co-interested attractions and objects. Mobile Piste Map (Dunlop et al., 2007) is designed to support mobile users in selecting ski routes, i.e., individual or combined runs appropriate to their level of ability, preferences, and current mood and track conditions. The system first asks the user to indicate her ski-run preferences, for instance the route difficulty level, and then uses the indicated preferences to compute a list of recommended routes. The system presents on the map the recommended routes and their suitability for the user. Park et al. (2007) presents a restaurant RS for mobile users. The system computes personalized recommendations using a Bayesian Network (Pourret et al., 2008) that models the probabilistic influences of the input parameters, i.e., the user’s personal and contextual information, in relation to the restaurant attributes. This approach represents a restaurant by three discrete-valued attributes: class (e.g., Korean or Italian restaurant), price (e.g., low or medium), and mood (e.g., romantic or tidy). The Bayesian Network is defined by an expert, and is trained using a training dataset. To begin with, each user is required to provide personal information (e.g., age, gender, income, preferred restaurant class, etc.). The user’s contextual information is automatically collected (detected) by the system, including season (e.g., spring), time in day (e.g., breakfast), position, weather (e.g., sunny), and temperature (e.g., warm). When a user requests for a restaurant recommendation, the system computes the recommendation score for all the restaurants in the database. A restaurant’s recommendation score is a weighted sum of the conditional probabilities of the restaurant’s attribute values, where these conditional probabilities are derived (inferred) from the learned Bayesian network. The system presents on the map a small set of the restaurants, i.e., those achieving the highest recommendation scores. Research Goals The main goal of our research work is similar to that addressed by the papers presented in the previous section, i.e., to provide personalized suggestions for travel products and services to mobile travelers, and to use the map as primary tool for visualizing these suggestions. However, our approach differs in the following aspects. • In our approach, the recommendation process begins with the user specifying explicit preferences, however, this user input is optional in our system, i.e., the user can obtain some recommendations even without explicitly providing any initial input. The main rationale for this design solution is that the user’s preferences can be also acquired during the product search interaction phase, using the critiquing function (discussed in details in the next section) and exploiting the knowledge derived from the previous recommendations. We note that in all the referenced approaches either it is mandatory for the user to input initial preferences (Dunlop et
7/22 al., 2004, Burigat et al., 2005; ten Hagen et al., 2005; Dunlop et al., 2007)or the user is not even given the option to specify initial preferences( Brown et al., 2005; Park et al., 2007). In this respect, our approach is more flexible, since it give the option to the user to specify preferences if she wants In most of the systems described earlier, the user is not supported in providing feedback to the systems recommendations; or if supported, as in City Guide(Dunlop et al., 2004), such a feedback is exploited only in future recommendation sessions, but not immediately for personalizing the current one In our approach, various types of feedback are supported, i.e ritiquing the recommended items and rating the selected product(s). Moreover, critiquing is used immediately to refine the current user query Our approach allows the users to indicate their preferences at different levels, in particular as a wish or a must satisfy criteria, and it utilizes these preferences in computing the systems recommendation(s). None of the earlier mentioned approaches support such a real-time use of user's preferences and critiques Furthermore, none of the systems described earlier support the users in comparing two recommended items. In fact, given the systems recommended items, a user may first focus her interest on a few items, and then she may compare pairs of items by browsing their characteristics (see Figure 5, presented later on). Hence, our approach supports an item-to-item comparison, highlighting the differences between the two compared items, and hence provides additional support to users in selecting the best item In our approach, case-based reasoning and user-interaction mining methodologies are used to exploit the knowledge contained in the past recommendation cases for learning how to rank the recommendations. Of the systems discussed earlier, only City Guide(dunlop et al., 2004)and George Square(brown et al., 2005 )learn from past recommendation interactions; whereas City Guide exploits the users' ratings and implicit feedback, and George Square exploits the users past activities RECOMMENDATION METHODOLOGY In this section we summarize our proposed methodology for travel product recommendation in a mobile context, providing details about the product representation and the user preferences model. Moreover, we illustrate how the user can critique a product recommendation and how this action is interpreted exploited by the system. A more detailed description of the recommendation methodology is provided Ricci nguyen (2007) We observe that both Moby Rek -the system using text-based display of recommended items, and MapMoby Rek-- the system using a map-based interface, identify the recommendation set, i. e, the restaurants to suggest to the user, in the same way. The two systems differ only in the way they present the results to the user. i. e in their user interface Product Representation and User Preferences Model In our recommendation technology, a travel product is represented as a feature values vector x=(xl, xz xn), where a feature value xi may be numeric, nominal, or a set of nominal values. For instance, the restaurant x( Dolomiti, 1713, pizza, 10, fair-conditioned, smoking-room), ( Saturday, Sunday fcredit-card)) has: name xr"", distance from the user's position x2=1713 meters, type x=pizza, average cost xf10 Euros, characteristics xs=(air-conditioned, smoking-room), opening days x6(Saturday, Sunday), and payment method xf(credit-card)
7/22 al., 2004; Burigat et al., 2005; ten Hagen et al., 2005; Dunlop et al., 2007) or the user is not even given the option to specify initial preferences (Brown et al., 2005; Park et al., 2007). In this respect, our approach is more flexible, since it give the option to the user to specify preferences if she wants. • In most of the systems described earlier, the user is not supported in providing feedback to the system’s recommendations; or if supported, as in CityGuide (Dunlop et al., 2004), such a feedback is exploited only in future recommendation sessions, but not immediately for personalizing the current one. In our approach, various types of feedback are supported, i.e., critiquing the recommended items and rating the selected product(s). Moreover, critiquing is used immediately to refine the current user query. • Our approach allows the users to indicate their preferences at different levels, in particular as a wish or a must satisfy criteria, and it utilizes these preferences in computing the system’s recommendation(s). None of the earlier mentioned approaches support such a real-time use of user’s preferences and critiques. • Furthermore, none of the systems described earlier support the users in comparing two recommended items. In fact, given the system’s recommended items, a user may first focus her interest on a few items, and then she may compare pairs of items by browsing their characteristics (see Figure 5, presented later on). Hence, our approach supports an item-to-item comparison, highlighting the differences between the two compared items, and hence provides additional support to users in selecting the best item. • In our approach, case-based reasoning and user-interaction mining methodologies are used to exploit the knowledge contained in the past recommendation cases for learning how to rank the recommendations. Of the systems discussed earlier, only CityGuide (Dunlop et al., 2004) and George Square (Brown et al., 2005) learn from past recommendation interactions; whereas, CityGuide exploits the users’ ratings and implicit feedback, and George Square exploits the users’ past activities. RECOMMENDATION METHODOLOGY In this section we summarize our proposed methodology for travel product recommendation in a mobile context, providing details about the product representation and the user preferences model. Moreover, we illustrate how the user can critique a product recommendation and how this action is interpreted and exploited by the system. A more detailed description of the recommendation methodology is provided by Ricci & Nguyen (2007). We observe that both MobyRek -- the system using text-based display of recommended items, and MapMobyRek -- the system using a map-based interface, identify the recommendation set, i.e., the restaurants to suggest to the user, in the same way. The two systems differ only in the way they present the results to the user, i.e., in their user interface. Product Representation and User Preferences Model In our recommendation technology, a travel product is represented as a feature values vector x= (x1, x2, …, xn), where a feature value xi may be numeric, nominal, or a set of nominal values. For instance, the restaurant x= (“Dolomiti”, 1713, {pizza}, 10, {air-conditioned, smoking-room}, {Saturday, Sunday}, {credit-card}) has: name x1=“Dolomiti”, distance from the user’s position x2=1713 meters, type x3={pizza}, average cost x4=10 Euros, characteristics x5={air-conditioned, smoking-room}, opening days x6={Saturday, Sunday}, and payment method x7={credit-card}
8/22 Any recommender system, for generating personalized recommendations, requires a representation of the user's preferences. Preferences vary from user to user, and even the same user in different situations (contexts) may have different preferences. In our approach, the user preferences model, which is encoded in a product search query, includes both contextual preferences(such as the space-time constraints )and preferences on product features. Contextual preferences characterize a user's current context of request whereas product preferences express a user's taste and like. In the restaurant recommendation problem for example, space-time constraints guarantee that the recommended restaurants are open on the day of the request and not too far from the user's position. Preferences on product features may state that the ser, for instance, is interested in cheap restaurants, or prefers to go for pizza. The user preferences model incorporates both long-term and session-specific user preferences (Nguyen Ricci, 2008a; Ricci Nguyen, 2007). Long-term (stable) user preferences, such as a preference for non-smoking room, are inferred from the users recent interaction sessions with the system, and remain true throughout these sessions. In contrast, session-specific user preferences, such as a wish to eat pizza, are transient and specific to a session. Acquiring session-specific preferences helps the system to effectively capture the transient needs of the user, whereas exploiting long-term preferences allows the system to rely on more stable preferences, or default choices, and also avoids interrupting the user or requiring her effort in specifying preferences when these are not needed Session-specific and long-term preferences must be combined and used in the most appropriate way In our approach, the system acquires session-specific user preferences in two ways: by users initial specifications and by users critiques. The user's initial preferences explicitly specified at the beginning of the recommendation session help orient the system's initial search. Meanwhile, the user's critiques to the recommended products help the system refine its understanding of the users needs and preferences As noted earlier the initial preference specification is optional in our system In a recommendation session, the user query has the function of encoding the users preferences(both session-specific and long-term), and is used by the system to compute the recommendation list(more on this subject will be provided later). In our model, the user-query q consists of three components, (qi, p The logical query(qu models the conditions that must be satisfied by the recommended products The logical query is a conjunction of constraints: qF(cr AczA.. Acm), where c is a constraint on j-th feature. A constraint deals with only one feature, and a feature appears in only one constraint The favorite pattern (p) models the conditions that the recommended products should match as much as possible. The wish conditions allow the system to make trade-offs. The favorite pattern is represented in the same vector space of the product representation: P=(pl, P2,.,Pn), where x, and pi belong to the same feature type, Vi=l.n The feature importance weights vector()models how much each feature is important for the user with respect to the others: w=(w1, w2, .. Wn), where wi(E [o, 1]) is the importance weight of i-th feature. The system refers to the feature importance weights when it needs to rank the roducts or make trade-offs or to find relaxation solutions for over-constrained logical queries For instance, the query (q=(x2< 2000)A(x6(Saturday, Sunday D),=(,?,pizza,?,?,?,?), w=(0,0.4, 0.2, 0,0, 0.4, 0)) models a user interested only in those restaurants within 2 km from her position, open on Saturday and Sunday, and preferring pizza restaurants to the others. The user considers the distance and the opening day as the most important features and then the restaurant type, and she is indifferent to the other features Recommendation process In our approach, the overall model of a recommendation session is logically divided into three phases 1) initialization, 2)interaction and adaptation, and 3)retaining, as shown in Figure 1. Given a user's request
8/22 Any recommender system, for generating personalized recommendations, requires a representation of the user’s preferences. Preferences vary from user to user, and even the same user in different situations (contexts) may have different preferences. In our approach, the user preferences model, which is encoded in a product search query, includes both contextual preferences (such as the space-time constraints) and preferences on product features. Contextual preferences characterize a user’s current context of request, whereas product preferences express a user’s taste and like. In the restaurant recommendation problem, for example, space-time constraints guarantee that the recommended restaurants are open on the day of the request and not too far from the user’s position. Preferences on product features may state that the user, for instance, is interested in cheap restaurants, or prefers to go for pizza. The user preferences model incorporates both long-term and session-specific user preferences (Nguyen & Ricci, 2008a; Ricci & Nguyen, 2007). Long-term (stable) user preferences, such as a preference for non-smoking room, are inferred from the user’s recent interaction sessions with the system, and remain true throughout these sessions. In contrast, session-specific user preferences, such as a wish to eat pizza, are transient and specific to a session. Acquiring session-specific preferences helps the system to effectively capture the transient needs of the user, whereas exploiting long-term preferences allows the system to rely on more stable preferences, or default choices, and also avoids interrupting the user or requiring her effort in specifying preferences when these are not needed. Session-specific and long-term preferences must be combined and used in the most appropriate way. In our approach, the system acquires session-specific user preferences in two ways: by user’s initial specifications and by user’s critiques. The user’s initial preferences explicitly specified at the beginning of the recommendation session help orient the system’s initial search. Meanwhile, the user’s critiques to the recommended products help the system refine its understanding of the user’s needs and preferences. As noted earlier the initial preference specification is optional in our system. In a recommendation session, the user query has the function of encoding the user’s preferences (both session-specific and long-term), and is used by the system to compute the recommendation list (more on this subject will be provided later). In our model, the user-query q consists of three components, q= (ql, p, w). • The logical query (ql) models the conditions that must be satisfied by the recommended products. The logical query is a conjunction of constraints: ql= (c1 Λ c2 Λ … Λ cm), where cj is a constraint on j-th feature. A constraint deals with only one feature, and a feature appears in only one constraint. • The favorite pattern (p) models the conditions that the recommended products should match as much as possible. The wish conditions allow the system to make trade-offs. The favorite pattern is represented in the same vector space of the product representation: p= (p1, p2,…, pn), where xi and pi belong to the same feature type, ∀i=1..n. • The feature importance weights vector (w) models how much each feature is important for the user with respect to the others: w= (w1, w2, …, wn), where wi (∈ [0,1]) is the importance weight of i-th feature. The system refers to the feature importance weights when it needs to rank the products or make trade-offs or to find relaxation solutions for over-constrained logical queries. For instance, the query q= (ql = (x2 ≤ 2000) ∧ (x6 ⊇ {Saturday, Sunday})), p= (?, ?, {pizza}, ?, ?, ?, ?), w= (0, 0.4, 0.2, 0, 0, 0.4, 0)) models a user interested only in those restaurants within 2 km from her position, open on Saturday and Sunday, and preferring pizza restaurants to the others. The user considers the distance and the opening day as the most important features and then the restaurant type, and she is indifferent to the other features. Recommendation Process In our approach, the overall model of a recommendation session is logically divided into three phases: 1) initialization, 2) interaction and adaptation, and 3) retaining, as shown in Figure 1. Given a user’s request