Conversational Query Revision with a Finite User Profiles Model Henry Blanco1,2 , Francesco Ricci1 , and Derek Bridge3 1 Faculty of Computer Science Free University of Bozen-Bolzano Bolzano, Italy fricci@unibz.it 2 Center of Medical Biophysics Universidad de Oriente Santiago de Cuba, Cuba 3 Department of Computer Science University College Cork Cork, Ireland Abstract. Information Recommendation is a conversational approach aimed at suggesting to the user how to reformulate his queries to a prod- uct catalogue in order to find the products that maximize his utility. In previous work, it was shown that, by observing the queries selected by the user among those suggested, the system can make inferences on the true user utility function and eliminate from the set of suggested queries those retrieving products with an inferior utility (dominated queries). The computation of the dominated queries was based on the solution of several linear programming problems, which represented a major com- putational bottleneck for the efficiency of the proposed solution. In this paper we propose a new technique for the computation of the dominated queries. It relies on the assumption that the set of possible user utility functions is finite. We show that under this assumption the computation of the query suggestions is simplified and the number of query sugges- tions is strongly reduced. Keywords: Recommender system, conversational system, user prefer- ence model. 1 Introduction Recommender Systems (RS) are intelligent tools and applications designed to support users in finding information, products or services that suit their needs and preferences [8]. Recommender system technologies are rooted in Machine Learning and Information Retrieval [4]. The core computational problem of a RS is to predict the user’s preferences, e.g. expressed as ratings for items, and recommend the items with maximal predicted preference [8]. Classical RS tech- niques, such as collaborative and content-based filtering, collect the user’s pref- erences in the form of ratings for items to meet the goals mentioned before. Their major limitation is that they present the recommendations in a single shot, and the user can either accept one of these recommendations or enter new prefer- ences and restart the process. Conversely, Conversational Recommender Systems (CRS) [2, 5, 6] not only rank and suggest products to users, but also guide them during the human-computer interaction to finally select the products that they may like. This guidance process is composed of several actions that depend on the underlying conversational technology (e.g., critiquing [7, 6]). In [1, 9] the authors first introduce and then extend a new conversational tech- nique relying on the idea of “Information Recommendation”. In this approach the user is supposed to query a product catalogue by issuing simple queries, such as “I want an hotel with AC and parking”. The system, rather than recommend- ing immediately the products that satisfy this query, assumes that the user may have also other needs and suggests some query revisions. These new queries, for instance, may add an additional feature to the query, e.g., the system may say: “are you interested also in a sauna?”. Products with more features, if available, will surely increase the user utility. But not all features are equally important for the user. So the goal of the system is to make “informed” suggestions, i.e., to suggest features that are likely to increase more the user utility. In fact, the system, observing the user queries, can deduce that certain features are more important than others, i.e., can infer constraints on the definition of the user utility function, even without knowing it. Hence, using this knowledge, it can suggest that the user try a query from a well-selected and small set of candidate queries . A similar idea, i.e., using a utility function estimation to select the more user relevant critiques (new queries), is described in [10]. In [1][9] it is shown that this approach is effective and provides good query suggestions and final recommendations. It guides the user to the query that selects the products with maximal utility in a short number of query revision interactions. The quoted papers describe the details of the approach: the query language, the possible preference models of the user, the inferences made by the system on observing the user’s query revisions, and the computation of the query suggestions for the user. Nevertheless some questions mostly related to the efficiency of the query suggestions computation and the size of the advice set are still open and require further investigation. In fact, the computational cost of query suggestion is playing a critical role in this approach. In [1] linear programming techniques were used for computing the query suggestions. Even if the computational complexity of that algorithm is polynomial, it must be invoked numerous times (to compare each pair of candidate queries), and in practice it takes too much time for a real online application. Moreover, the average size of the advice set, i.e., the queries suggested by the system to the user at each interaction step, remains large in many cases (more than 20). This is a critical issue for implementing a real application based on the proposed technique. In this paper we refine the proposed model by making the assumption that the user utility function is drawn from a set of finite possibilities. This set of “user profiles” represents the possible “different” users that the system may interact with. We will show that this assumption has a strong effect: it simplifies the search process for the query suggestions and reduces the average number of query suggestions made at each interaction step. This finite model assumption is realistic, as users tend to cluster in groups with similar preferences. Moreover, considering an increasingly large number of user profiles one can approximate all the possible ones. 2 Query Language In our model a product p is represented by an n-dimensional Boolean feature vector p = (p1 , . . . , pn ). pi = 1 means that the i-th feature (e.g., Air Condi- tioning) is present in the product, whereas pi = 0 means that p does not have feature i. A catalogue is a set of products {p(1) , . . . , p(k) }. The Boolean features could be keywords or tags found in the product description, and searching for products with these features can be viewed as kind of facet search [3]. Queries are represented similarly as Boolean vectors: q = (q1 , . . . , qn ). qi = 1 means that the user is interested in products that have the i-th feature. On the other hand qi = 0 does not mean that the user is not interested in products with that feature, but simply that he has not yet declared his interest on it. A query is said to be satisfiable if there exists a product in the catalogue such that all the features expressed in the query as desired (qi = 1) are present in that product. For example if the product p = (1, 1, 0, 1, 0) is present in the catalog then query q = (0, 1, 0, 1, 0) is satisfiable. We are considering a scenario where the user may be interested in refining an initial query. Moreover, we assume that the user is not likely to radically modify this query. This may also be a constraint imposed by the GUI of the query sys- tem, where the user can be offered with only a small number of easily understood editing operations. In the following we list the query editing operations that we assume the user can make when revising the current query: – add(q, i), where i ∈ idx0(q) – trade(q, i, j, k), where i ∈ idx1(q) and j, k ∈ idx0(q) where idx0(q) and idx1(q) are the set of indexes with value 0 and 1 in q respec- tively. The first operation generates a new query by requesting one additional feature. For example, (1, 1, 0, 0, 1) = add((1, 1, 0, 0, 0), 5) is extending a query where only the first two features were requested by adding also the fifth feature to the set of requested ones. The second operation generates a new query by dis- carding a feature, the i-th, in favor of two new ones, the j-th and k-th features. For example, (0, 1, 0, 1, 1) = trade((1, 1, 0, 0, 0), 1, 4, 5) Using the above-mentioned operators the system can generate a set of next queries and ask the user to select the preferred one. In our approach, the goal of the system is not to suggest all these possible next queries, as a standard “query by example” interface may implement, but rather only queries that could retrieve products with the largest utility. Hence, first of all, the unsatisfiable queries must not be suggested. This can be easily implemented with standard query processing techniques. But, as it will be shown later, also other types of queries can be discarded: those that can be proved to retrieve products with a smaller utility than those retrieved by another query in the suggestion list (dominated queries). 3 User Utility Function User preferences for products are represented here as a vector of weights: w = (w1 , . . . , wn ), 0 ≤ wi ≤ 1 (1) wi is the importance that a particular user, one having that set of preference weights, assigns to the i-th feature of a product. So if wi = 0, then the user has no desire for the i-th feature. If wi > wj , then the i-th feature is preferred to the j-th one. If wi ≥ wj then the i-th feature is at least as desired as the j-th one. If wi = wj , i 6= j then the user is indifferent between these two features. The user utility for a particular product p = (p1 , . . . , pn ) is given by the following: n X U tilityw (p) = wi × pi (2) i=1 A product p with a higher utility than another product p0 is always assumed to be preferred by the user, i.e., we assume that users are rational. We also define the Pn potential utility of a query q = (q1 , . . . , qn ) for the user as: U tilityw (q) = i=1 wi × qi . We call this utility “potential” if we do not know wether a product with the features specified in the query does exist, i.e., if the query is satisfiable. In case such a product exists, this potential utility is also a true utility. A user accessing the system may have any of the possible utility functions that can be defined by varying the feature weights wi . So, in principle, the set of all possible utility functions is infinite. But observing the queries selected by the user among those that he can make (i.e., those suggested by the system), the system can infer constraints on the definition of his utility function. Gener- ally speaking, features present in the selected query can be considered as more desired by the user than features that are present in the alternative queries. The constraints deduced by the system on the user utility function w = (w1 , . . . , wn ) are illustrated below. Initial query. If the current query q is the initial query, then the advisor may infer that wi ≥ wj , ∀i ∈ idx1(q) and ∀j ∈ idx0(q), unless q, with the i-th feature set to 0 and the j-th feature set to 1, is unsatisfiable. This means that if the user issued a query that requests the presence of a feature then the potential utility of this query is assumed to be larger than or equal to that of another query where this feature is not requested. But only if this “alternative query” is satisfiable. Adding a feature. If the current query q 0 results from an add() operation on the previous query, that is, q 0 = add(q, i), then the advisor infers wi ≥ wj , ∀j ∈ idx0(q), i 6= j, unless add(q, j) results in an unsatisfiable query. The rationale of this deduction is similar to the previous one. We assume that the user has extended the query by selecting a new query that includes an additional feature that brings a larger increase of his utility, compared to the other possible features that he may have included. Trading one feature for two. If the current query results from a trade operation on the previous query, i.e., q 0 = trade(q, i, j, k), the advisor may infer: 1. wj + wk ≥ wi , 0 2. wj +wk ≥ wj 0 +wk0 , ∀j 0 , k 0 ∈ idx0(q), {j, k} = 6 {j 0 , k } unless trade(q, i, j 0 , k 0 ) is unsatisfiable. The first constraint says that the current query does not have a utility inferior to the previous one. While the second constraint says that the selected trade operation must obtain a utility that is not inferior to that of alternative trade operations that the user may have applied (and are satisfiable). We note that unsatisfiable queries are never suggested, and therefore we never deduce that a query has a potential utility larger than that of a failing query. In the previous work [1], we called this “play safe” because we considered that the user might know that a query will fail and therefore he does not try it, hence we cannot assume that the potential utility of the query that was actually tried is larger than that of a query that the user did not try because he knew it would fail. In the current work we generalize and rephrase it by saying that the system can deduce only that the potential utility of the query that is tried is greater than or equal to the (potential) utility of the other queries that were suggested, or equivalently that the user could have tried (either because the system suggested them or because the user knows they are satisfiable). 4 Advisor The advisor is the intelligent entity in charge of observing the interaction pro- cess, the user movements (queries issued), and making inferences on the user preferences. As mentioned before, the user preferences are not known at the be- ginning of the interaction between the user and the advisor. The advisor, after the user’s first query, will generate a set of next candidates queries and will sug- gest only those with a utility that cannot be proved to be inferior to one of the other queries (undominated queries). At each user-system interaction step, the advisor accumulates some con- straints on the user utility function (see Section 3). We denote this set of con- straints by Φ. Moreover, given a set of next possible queries C = {q (1) , . . . , q (k) }, i.e., those that can be generated by applying the operations described in Sec- tion 2, and that are satisfiable, the advisor needs to understand which queries are worth suggesting to the user. These are the queries having a utility not in- ferior to the utility of another query that may also be suggested. These queries are obtained by removing from C all the dominated queries. A query q ∈ C is dominated if there exists another query q 0 ∈ C such that for all the possible weight vectors that are compatible with the set of constraints Φ this relation holds: U tilityw (q 0 ) > U tilityw (q). A weight vector w is said to be Table 1. Query utilities for the profiles w(1) and w(3) . q(1) q(2) q(3) q(4) w(1) 0.75 0.9 0.65 0.7 w(3) 0.9 0.65 0.7 0.75 compatible with the set of constraints in Φ if and only if all the constraints in Φ are satisfied when the variables w1 , . . . , wn take the values specified in w. Removing the dominated queries is meaningful because their utility is lower than the utility of another query (that is suggested) for all the possible user utility functions that are compatible with the preferences induced by observing the user behavior. In this paper we solve this problem under the assumption that the user’s true utility function is defined by one (unknown) vector among a finite set of weights vectors considered by the system. We call this finite set of all the possible utility function or “user profiles” P = {w(1) , . . . , w(m) }. We will consider in the experiments m ranging from some dozens to hundreds. With this assumption, having the set Φ we can prune from the set P the “incompatible profiles”, i.e., those not satisfying the constraints Φ. Then, the computation of the undominated queries proceeds as follow. Let’s assume that the set of user profiles compatible with the accumulated constraints is P 0 = {w(1) , . . . , w(t) } ⊂ P and C = {q (1) , . . . , q (k) } is the set of next possible queries, i.e., queries that are satisfiable and are generated by the considered operators starting from the last issued query of the user. The final set of queries that are recommended are computed using a linear time procedure in the number of queries in C and utility functions in P 0 , as follows: 1. A query q ∈ C, is labelled as dominated if and only if we can find another 0 0 Pn q ∈ C, query qP 6= q, such that ∀w ∈ P 0 , U tilityw (q 0 ) > U tilityw (q), i.e., 0 n i=1 wi × qi > i=1 wi × qi . 2. Build the Advice set - undominated queries - by removing from C the dom- inated queries. Example. Assume that Φ = {w1 ≥ w3 , w2 + w3 ≥ w4 }, P 0 = {w(1) , w(2) , w(3) } and C = {q (1) , q (2) , q (3) , q (4) }, w(1) = (0.35, 0.1, 0.25, 0.3), w(2) = (0.1, 0.35, 0.3, 0.25), w(3) = (0.3, 0.35, 0.1, 0.25), q (1) = (1, 1, 0, 1), q (2) = (1, 0, 1, 1), q (3) = (0, 1, 1, 1), q (4) = (1, 1, 1, 0). In this example only the profiles w(1) and w(3) satisfy the con- straints in Φ, so w(2) is an “incompatible profile”, and must be pruned from P 0 . Table 1 shows the query utilities. q (1) has a higher utility than q (3) and q (4) for every profile in P 0 , thus q (3) and q (4) are dominated by q (1) . These dominated queries are removed from the set C. Notice that the remaining queries q (1) and q (2) do not dominate each other, thus they represent meaningful advice that the advisor can provide to the user. Finally, the algorithm for query suggestions using a finite set of user profiles is described as follows: 1. Φ = ∅, P = all possible profiles, AdviceSet = all possible queries 2. Do 3. Present AdviceSet to the user; 4. currentQuery = query selected by the user in AdviceSet; 5. Infer constraints analyzing the currentQuery and add them to Φ; 6. Remove incompatible profiles from P ; 7. Compute candidate queries; 8. Remove dominated queries from candidate ones and generate AdviceSet; 9. while ((AdviceSet 6= null) and (user wants advice)) The advisor presents to the user a possible set of queries. At the beginning these are all the possible ones, i.e., the user is free to enter the first query. Then the advisor infers the constraints Φ according to the rules mentioned in section 3. The advisor then removes the user profiles that do not satisfy these constraints. Afterwards the set of candidate queries are generated from the current query, applying the operators mentioned in Section 2 and those that are not satisfi- able are removed. Finally, the advisor identifies the AdviceSet by removing the dominated queries and suggests the remaining ones to the user as potential new moves. If the user selects one from this advice and the AdviceSet is not empty then the selected query becomes the current query and the process is repeated. If the user does not want further advice then the system will suggest the products that satisfy the last query selected by the user. 5 Experiments We performed some experiments in order to compare the performance of the proposed approach with the results obtained in [1]. We simulated several inter- actions between a user and the advisor. We varied the following parameters in the simulations: the product database and the number and format of the user profiles. Three different product databases were used, each one describing real hotels by their amenities expressed as Boolean features. Details of the product databases are given in the Table 2; here an hotel may have the same product description in terms of features as another, which is why the number of distinct products is smaller than the number of hotels. We considered two kinds of user profiles as typical models of user preferences: “random-shape user profiles” and “exponential-shape user profiles”. A “user’s profile shape” refers to the distribution of the weights of the features in a user profile. Random-shape user profiles are created by first generating one initial user profile (weights vector) sampling the weights from a uniform distribution in [0,1]. Then the other profiles, in the same set P , are created by a random permutation of the feature weights of the initial user profile. Note that if the weights are sorted into decreasing order, the resulting sequence will decrease near linearly. This is because there is no special ‘preference’ for any number when you randomly select them. Conversely, the set of exponential-shape user profiles is created by generating first one initial user profile with an exponentially decreasing importance for the weights: e−αi , with a selected α ∈ [1, 4] and i = Table 2. Product databases Name Features Hotels Products Marriot-NY 9 81 36 Cork 10 21 15 Trentino-10 10 4056 133 1, . . . , n. The other user profiles are again obtained with random permutations of the initial user profile. Here we wanted to simulate users with a few important features and many less important ones. For each experiment, we generated three sets of user profiles P : small (24 profiles), medium (120 profiles) and large (720 profiles). We wanted to observe the effect of the assumed variability of the user profiles on the user-advisor interaction length and the size of the advice set. We assumed that the user is “Optimizing” [1], that is, one who confines his queries to the advice set provided by the advisor and he will always try the query with the highest utility in the advice set. The simulated interaction between a virtual user and the advisor is done considering the algorithm described in the previous section. One element of the set of predefined user profiles is randomly selected and considered as the user’s true profile (user’s utility). This is not re- vealed to the advisor, which interacts with the simulated user using the proposed methodology. The advisor deductions about the user’s true utility function are based only on the observation of the user queries submitted at each interaction step. The initial query submitted by the simulated user is created in accordance to his true utility function; thus, the initial query includes up to the k most important features for the user. In total, 18 experiments were performed corresponding to the combination of the variables mentioned before (product database, user profile shape and number of user profiles). In every experiment we ran 50 dialogues between a simulated user and the advisor. The observed measures were: the average number of queries issued per dialogue, the average size of the advice set and the average utility shortfall. The utility shortfall is the difference between the utility of the best query (selecting the product with the highest utility for the user) and the last query suggested by the system to the user. In this way we could measure if the system suggestions are close to the best query according to the user’s true utility function. Table 3 shows the values of the observed measures. We can observe that the average number of queries issued by the virtual user (interaction length) ranges between 3 and 7 almost independently from the “User Profile shape” and “User Profile set size”. The interaction length seems to be related to the number of product features and the available products in the data set. The higher the number of product’s features the longer will be the interaction. This happens because the user at each query editing step adds one feature to the previous query. In fact, the query suggestions are generated by the add() and trade() operations that extend the previous query by setting one additional feature to Table 3. Averaged values of the observed measures for 50 runs in the 18 experiments performed. Product User Prof. User Queries Queries Utility D.B. shape Prof. issued in Adv. Shortfall set size set 24 5.58 1.21 0.00281 Random 120 5.21 2.83 0.00491 720 5.64 4.71 0.00622 Cork 24 5.66 1.28 0.0082 Exponential 120 5.52 3.05 0.0062 720 5.31 3.37 0.0051 24 4 1.59 0 Random 120 4 3.41 0.00031 720 4 4.33 0.00083 Marriott 24 3.67 1.67 0.00636 Exponential 120 4 3.01 0.00097 720 4 5.73 0 24 6.62 1.08 0.00315 Random 120 6.58 2.06 0.00319 720 6.32 2.93 0.00757 Trentino 24 6.38 1.14 0.00019 Exponential 120 6.18 1.72 0.00197 720 6.48 2.89 0.00833 1. Hence, assuming that the best query has a certain number of features set to 1, then the user needs to pass through that number of steps (minus the number of features set to 1 in the initial query) in order to reach it, or to reach another query that does not provide the maximal utility but still cannot be further extended without reaching a failing query. Another factor to take into account is the number of products in the database. The smaller the number of products is, the more likely the process is to stop, because the current query cannot be further extended without building a failing query. The most important aspect of these values is that the interaction length is typically low and quite reasonable for real online applications. The “Average size of the advice set” is sub-linearly correlated to the profile set size, that is, to the number of predefined user profiles. The higher the number of predefined user profiles, the (slightly) higher is the number of query suggestions in the advice set on average. In fact, if there are more user profiles, the more difficult it is to find dominated queries, thus the set of undominated queries (the advice set) is more likely to be larger. In general the average advice set size ranges between 1 and 6. This number of query suggestions represents an acceptable value for real applications. The “Average size of the advice set” doesn’t seem to be related to the variables “User Profile shape” and “Product database”. In Fig. 1. Size of the Advice Set at different interaction steps. general the “User profile shape” doesn’t seem to influence either the “Interaction length” or the “Average size of the advice set”. The utility shortfall is very close to 0 on average. This cannot be 0 because the query suggestions are searched in a greedy way (always expanding the previous query), hence the advisor can fall into local maxima paths while searching for the best query suggestion [1]. Thus we cannot assure that the Advice Set will always contains the query with the largest utility that can be obtained by using the current query editing operations. Hence, limiting the query editing to the add(. . .) and trade(. . .) operators does not assure the user to reach the best query. Nevertheless at the end of the process the final query is very close to the best attainable given the user preferences. Figure 1 shows the evolution of the Advice Set size (averaged over 50 dia- logues) in the experiment that produces the highest number of average advices per suggestion (5.73 queries in table 3). That experiment corresponds to: Prod- uct Database = Marriott NY, Profile Shape = Exponential, and User Profile set size = 720. The curve labeled as “average” shows the average number of advices given to the user at the first three interaction steps. At the first step, the number of queries suggested is on average 10.4 ± 8.2(avg. ± stdv.); at the next interaction step, it is 5.3±3.9; and finally the system suggests only 1±0.7 queries (the best). The curves labeled as “Maximum” and ”Minimum” correspond to the maximum and minimum number of queries suggested at each interaction step to the user. In general we can see that the number of advices falls quickly in a short number of interactions. Still, it is clear that there are certain dialogues with a rather large number of advices, and this is an issue to consider in the application of this technique. We now compare our results with those presented in [1]. Table 4 shows the values of the variables “Average number of queries issued per Dialogue”, “Aver- age size of the Advice Set”, “Average Utility shortfall” obtained in the previous work, where an infinite number of profiles was considered and the query dom- Table 4. Comparison between the current (finite model) and previous work (infinite model) on the observed measures. Database Averaged measures Infinite model Finite model Queries issued 4.67 3.58 Marriott-NY Numb. Advices 45.96 4.33 Utility shortfall 0 0.0008 Queries issued 6.09 6.32 Cork Numb. Advices 69.88 2.93 Utility shortfall 0 0.0075 Queries issued 5.55 5.64 Trentino Numb. Advices 59.02 4.71 Utility shortfall 0 0.0062 inance relation was computed using linear programming techniques. It is clear that the average number of queries per dialogue is low in both approaches and very similar. This is due to the fact that the actual query editing operations are the same in the two approaches, and the dialogues converge to optimal queries with similar operations. The utility shortfall in the current approach is a bit larger than that measured previously. This is what one has to pay for the lim- iting assumption that the number of possible user utility functions (profiles) is finite. The major beneficial effect of the proposed approach is the significant reduction in the number of queries suggested by the advisor to the user by more than 10 times. This makes it much more suitable in real applications. Obviously this is again related to the assumption that the variability of the user utility func- tions is assumed to be smaller. We believe that in real scenarios approximating the set of all possible utility functions with a smaller, finite set, is a reasonable assumption and the small cost paid in terms of increased utility shortfall is com- pensated by the strong reduction in the size of the advice set, making it feasible for the user to browse the advice set and pick up his best query. 6 Conclusions and Future Work In this paper we have described and analyzed the performance of a new type of conversational recommender system that suggests query revisions to a user searching for products in a catalogue. The products are described by Boolean features. They can be for instance tags or keywords found in the product descriptions. In this paper we assume that the user utility function is one among a finite set of possible functions that are known to the system, but the system does not know which is the true utility function of the user. The results of our experiments showed that this assumption has a strong effect on the process of finding the best query suggestions that guide the user to the products that maximize his utility. In particular the number of user- advisor interaction steps (number of queries issued by the user) and the utility shortfall are low (as in our previous work where the user profiles were not limited to be finite). But, differently from the previous case, we have now observed a significant reduction in the number of advices provided at each user-advisor interaction step. We have also showed that having a good number of predefined user profiles is an important ingredient for improving the system performance and producing an effective support. In future work we will consider the case when the true utility function of the user is not one of those assumed by the system. This is the true general situation when a totally unknown user is approaching the system and the system has no knowledge about his preferences. In particular, we will measure how this impacts on the utility shortfall. Additionally we will implement this approach on a real online and mobile application, which will undoubtedly help to give a better understanding of user behavior and the true effectiveness of the proposed approach. References 1. D. Bridge and F. Ricci. Supporting product selection with query editing recommen- dations. In RecSys ’07: Proceedings of the 2007 ACM conference on Recommender systems, pages 65–72, New York, NY, USA, 2007. ACM Press. 2. M. H. Göker and C. A. Thomson. Personalized conversational case-based recom- mendation. In Advances in case-based reasoning: 5th European workshop, EWCBR- 2000, Trento, Italy, September 6–9, 2000: proceedings, pages 99–111. Springer, 2000. 3. M. A. Hearst. Search User Interfaces. Cambridge University Press, 2009. 4. P. Lops, M. de Gemmis, and G. Semeraro. Content-based recommender systems: State of the art and trends. In F. Ricci, L. Rokach, B. Shapira, and P. B. Kantor, editors, Recommender Systems Handbook, pages 73–105. Springer Verlag, 2011. 5. T. Mahmood and F. Ricci. Learning and adaptivity in interactive recommender systems. In ICEC ’07: Proceedings of the ninth international conference on Elec- tronic commerce, pages 75–84, New York, NY, USA, 2007. ACM. 6. L. McGinty and J. Reilly. On the evolution of critiquing recommenders. In F. Ricci, L. Rokach, B. Shapira, and P. B. Kantor, editors, Recommender Systems Handbook, pages 419–453. Springer Verlag, 2011. 7. Q. N. Nguyen and F. Ricci. User preferences initialization and integration in critique-based mobile recommender systems. In Proceedings of the 5th Interna- tional Workshop on Artificial Intelligence in Mobile Systems, AIMS’04, pages 71– 78, Nottingham, UK, 2004. 8. F. Ricci, L. Rokach, B. Shapira, and P. B. Kantor, editors. Recommender Systems Handbook. Springer, 2011. 9. W. Trabelsi, N. Wilson, D. Bridge, and F. Ricci. Comparing approaches to prefer- ence dominance for conversational recommender systems. In E. Gregoire, editor, Procs. of the 22nd International Conference on Tools with Artificial Intelligence, pages 113–118, 2010. 10. J. Zhang and P. Pu. A comparative study of compound critique generation in conversational recommender systems. In Proceedings of the 4th International Con- ference on Adaptive Hypermedia and Adaptive Web-Based Systems, AH 2006, pages 234–243, 2006.