Dominance testing represents a key operation when looking for the most preferred set of alternatives among a set of possible alternatives with regards to the user’s pref- erences. Different formalisms have brought different preferences languages which show increasing expressiveness capabilities. Different dominance semantics and ways of computing dominance were explored in the literature, e.g., (Benferhat et al. 2001, Brewka, Niemelä & Syrjänen 2002, Brewka et al. 2003, Boutilier et al. 2004a, Boutilier et al. 2004b, Brewka, Benferhat & Berre 2004, Kärger et al. 2008, Costantini & Formisano 2009, Bouveret et al. 2009a, Wilson 2011). These semantics offer vari- ous ways of considering the dominance relation as we may need to tighten or extend the set of models that we consider in order to confirm dominance between two out- comes. Different ways of dominance computation were presented in the literature in an attempt to reduce the computational complexity of the dominance testing as it is a computationally hard problem in general with the standard CP-nets semantics (Goldsmith et al. 2005, Goldsmith et al. 2008). We presented the preference language and the dominance semantics and computation we are using in this thesis. We also presented other dominance approaches that adopt different semantics of the domi- nance relation. We described in detail the dominance testing algorithm that we have used in this dissertation.
4
Preferences Deduction for
Conversational Recommender Systems
4.1
Introduction
In an era of overwhelming choices, recommender systems (RSs) are a new source of assistance, helping their users decide which goods, services or information to pur- chase or consume (Adomavicius & Tuzhilin 2005, Anand & Mobasher 2005, Bridge et al. 2006, Ricci et al. 2011a). RSs try to induce information about user preferences from data gathered either explicitly, for instance, in the form of product ratings, or implicitly by observing users’ behaviour. They have been successfully used to rec- ommend travel services, books, CD, financial services, insurance plans and news (Adomavicius & Tuzhilin 2005, Anand & Mobasher 2005, Bridge et al. 2006).
RSs aim at recommending the most suitable items to the user (Ricci et al. 2011a). However, it may happen that the recommended items proposed by the system do not match the users’ needs as RSs might miss the users’ preferences. Several cases of poor quality recommendations were described in (Zaslow 2002); the article also reported how affected users desperately tried to react and to change the deal and communicate their actual needs to the system but in vain. Examples of issues that might be raised are whether the system does understand why the user wants rec- ommendations and whether recommenders have their own “personalities” to which users need to interact with, were discussed in (Zaslow 2002).
“Single-shot” RSs, which recommend a set of products to the user only once (i.e., in one shot), are one category of RSs that may experience some inappropriate rec- ommendations since they are unlikely to guarantee that their first set of recommen- dations always satisfies the user. Figure 4.1 illustrates a single-shot recommendation scenario. Once the user’s preferences collected (or elicited), the preference manager induces the preference model which is represented by ratings, features values, etc. Given a user inquiry (i.e., request) and the user’s preferences, the request manager selects a set of recommendations (undominated options), retrieves the corresponding products from the database and presents them to the user. If one of the presented items suits the user, she selects and buys it. Otherwise, the user quits. Indeed, users are rarely satisfied with the first set of recommendations; they usually want to see more options and they exploit the initial recommendations to refine their prefer- ences and articulate new requests (Bridge et al. 2006). Therefore, one approach to ensure that the system realizes what users need would be to generate a conversa- tion between users and RSs as illustrated in Figure 4.2. This will be favorable for building or reinforcing the bridge between the two partners (i.e., the user and the RS). Figure 4.2 illustrates a conversational recommendation scenario. The difference with the single-shot recommendation scenario is that in the case where the user is not satisfied she can revise her request. Then, the preference manager captures the revision of the user request to update the elicited user’s preference and so the user model. Therefore, given the updated user model plus the revised request, the request manager selects again a set of recommendations and retrieves their corresponding products from the database. If the user is satisfied with one of the items presented to her she selects and buys it. Otherwise, the user can revise her query and send it again to the system.
Starting initially with a set of products and initial preference information about the user, conversational RSs allow for such a conversation, and recognise that their users may be willing and able to provide more information on their constraints and preferences, over a short dialogue, thereby moving away from “single-shot” inter- action. This is also an opportunity for the RSs to guide the user by asking ques- tions, giving advice, displaying candidate products, and giving explanations (Reilly et al. 2004, McSherry 2005, Bridge et al. 2006, Ricci et al. 2006, Schmitt 2002a, Thomp- son et al. 2004a, Pu et al. 2006).
In Section 4.2 we describe in detail a kind of recommender system that inspired a major part of the work presented in this chapter. Then, we present the framework of preference dominance and its rationale in Section 4.3. This framework is illus- trated through two instances that are described later in Section 4.4 and Section 4.5.