Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Recommendation systems  [7, 33] provide suggestions for items that are of potential interest for a user. These systems are applied for answering questions such as which book to buy? [39], which website to visit next? [49], and which financial service to choose? [19]. In software engineering scenarios, typical questions that can be answered with the support of recommendation systems are, for example, which software changes probably introduce a bug? [3], which requirements to implement in the next software release? [25], which stakeholders should participate in the upcoming software project? [38], which method calls might be useful in the current development context? [59], which software components (or APIs) to reuse? [45], which software artifacts are needed next? [40], and which effort estimation methods should be applied in the current project phase? [50]. An overview of the application of different types of recommendation technologies in the software engineering context can be found in Robillard et al. [53].

The major goal of this book chapter is to shed light on the basic properties of the three major recommendation approaches of (1) collaborative filtering  [12, 26, 36], (2) content-based filtering  [49], and (3) knowledge-based recommendation  [5, 16]. Starting with the basic algorithmic approaches, we exemplify the functioning of the algorithms and discuss criteria that help to decide which algorithm should be applied in which context.

The remainder of this chapter is organized as follows. In Sect. 2.2 we give an overview of collaborative filtering recommendation approaches. In Sect. 2.3 we introduce the basic concepts of content-based filtering. We close our discussion of basic recommendation approaches with the topic of knowledge-based recommendation (see Sect. 2.4). In Sect. 2.5, we explain example scenarios for integrating the basic recommendation algorithms into hybrid ones. Hints for practitioners interested in the development of recommender applications are given in Sect. 2.6. A short overview of further algorithmic approaches is presented in Sect. 2.7.

2 Collaborative Filtering

The item-set in our running examples is software engineering-related learning material offered, for example, on an e-learning platform (see Table 2.1). Each learning unit is additionally assigned to a set of categories, for example, the learning unit l 1 is characterized by Java and UML.

Collaborative filtering [12, 36, 56] is based on the idea of word-of-mouth promotion: the opinion of family members and friends plays a major role in personal decision making. In online scenarios (e.g., online purchasing [39]), family members and friends are replaced by the so-called nearest neighbors (NN) who are users with a similar preference pattern or purchasing behavior compared to the current user. Collaborative filtering (see Fig. 2.1) relies on two different types of background data: (1) a set of users and (2) a set of items. The relationship between users and items is primarily expressed in terms of ratings which are provided by users and exploited in future recommendation sessions for predicting the rating a user (in our case user U a ) would provide for a specific item. If we assume that user U a currently interacts with a collaborative filtering recommendation system, the first step of the recommendation system is to identify the nearest neighbors (users with a similar rating behavior compared to U a ) and to extrapolate from the ratings of the similar users the rating of user U a .

Table 2.1 Example set of software engineering-related learning units (LU). This set will be exploited for demonstration purposes throughout this chapter. Each of the learning units is additionally characterized by a set of categories (Java, UML, Management, Quality), for example, the learning unit l 1 is assigned to the categories Java and UML
Full size table
Fig. 2.1
figure 1

Collaborative filtering (CF) dataflow. Users are rating items and receive recommendations for items based on the ratings of users with a similar rating behavior—the nearest neighbors (NN)

Full size image

The basic procedure of collaborative filtering can best be explained based on a running example (see Table 2.2) which is taken from the software engineering domain (collaborative recommendation of learning units). Note that in this chapter we focus on the so-called memory-based approaches to collaborative filtering which—in contrast to model-based approaches—operate on uncompressed versions of the user/item matrix [4]. The two basic approaches to collaborative filtering are user-based collaborative filtering [36] and item-based collaborative filtering [54]. Both variants are predicting to which extent the active user would be interested in items which have not been rated by her/him up to now.

Table 2.2 Example collaborative filtering data structure (rating matrix): learning units (LU) versus related user ratings (we assume a rating scale of 1–5)
Full size table

User-Based Collaborative Filtering. User-based collaborative filtering identifies the k-nearest neighbors of the active user—see Eq. (2.1)Footnote 1—and, based on these nearest neighbors, calculates a prediction of the active user’s rating for a specific item (learning unit). In the example of Table 2.2, user U 2 is the nearest neighbor (k = 1) of user U a , based on Eq. (2.1), and his/her rating of learning unit l 3 will be taken as a prediction for the rating of U a (rating = 3.0). The similarity between a user U a (the current user) and another user U x can be determined, for example, based on the Pearson correlation coefficient [33]; see Eq. (2.1), where LU c is the set of items that have been rated by both users, \(r_{\alpha,l_{i}}\) is the rating of user α for item l i , and \(\overline{r_{\alpha }}\) is the average rating of user α. Similarity values resulting from the application of Eq. (2.1) can take values on a scale of \([-1,\ldots,+1]\).

$$\displaystyle{ \mathrm{similarity}(U_{a},U_{x}) = \frac{\sum _{l_{i}\in \mathit{LU}_{c}}(r_{a,l_{i}} -\overline{r_{a}}) \times (r_{x,l_{i}} -\overline{r_{x}})} {\sqrt{\sum _{l_{i } \in \mathit{LU } _{c } } {(r_{a,l_{i } } - \overline{r_{a } } )}^{2}} \times \sqrt{\sum _{l_{i } \in \mathit{LU } _{c } } {(r_{x,l_{i } } - \overline{r_{x } } )}^{2}}} }$$
(2.1)

The similarity values for U a calculated based on Eq. (2.1) are shown in Table 2.3. For the purposes of our example we assume the existence of at least two items per user pair (U i , U j ), for \(i\neq j\), in order to be able to determine a similarity. This criterion holds for users U 2 and U 3.

Table 2.3 Similarity between user U a and the users \(U_{j}\neq U_{a}\) determined based on Eq. (2.1). If the number of commonly rated items is below 2, no similarity between the two users is calculated
Full size table

A major challenge in the context of estimating the similarity between users is the sparsity of the rating matrix since users are typically providing ratings for only a very small subset of the set of offered items. For example, given a large movie dataset that contains thousands of entries, a user will typically be able to rate only a few dozens. A basic approach to tackle this problem is to take into account the number of commonly rated items in terms of a correlation significance [30], i.e., the higher the number of commonly rated items, the higher is the significance of the corresponding correlation. For further information regarding the handling of sparsity, we refer the reader to [30, 33].

The information about the set of users with a similar rating behavior compared to the current user (NN, the set of nearest neighbors) is the basis for predicting the rating of user U a for an item that has not been rated up to now by U a ; see Eq. (2.2).

$$\displaystyle{ \mathrm{prediction}(U_{a},\mathit{item}) = \overline{r_{a}} + \frac{\sum _{U_{j}\in \mathit{NN}}\mathrm{similarity}(U_{a},U_{j}) \times (r_{j,\mathit{item}} -\overline{r_{j}})} {\sum _{U_{j}\in \mathit{NN}}\mathrm{similarity}(U_{a},U_{j})} }$$
(2.2)

Based on the rating of the nearest neighbor of U a , we are able to determine a prediction for user U a (see Table 2.4). The nearest neighbor of U a is user U 2 (see Table 2.3). The learning units rated by U 2 but not rated by U a are l 3 and l 8. Due to the determined predictions—Eq. (2.2)—item l 3 would be ranked higher than item l 8 in a recommendation list.

Table 2.4 User-based collaborative filtering-based recommendations (predictions) for items that have not been rated by user U a up to now
Full size table

Item-Based Collaborative Filtering. In contrast to user-based collaborative filtering, item-based collaborative filtering searches for items (nearest neighbors—NN) rated by U a that received similar ratings as items currently under investigation. In our running example, learning unit l 4 has already received a good evaluation (4.0 on a rating scale of 1–5) by U a . The item which is most similar to l 4 and has not been rated by U a is item l 3 (similarity(l 3, l 4) = 0.35). In this case, the nearest neighbor of item l 3 is l 4; this calculation is based on Eq. (2.3).

If we want to determine a recommendation based on item-based collaborative filtering, we have to determine the similarity (using the Pearson correlation coefficient) between two items l a and l b where U denotes the set of users who both rated l a and l b , \(r_{u,l_{i}}\) denotes the rating of user u on item l i , and \(\overline{r_{l_{i}}}\) is the average rating of the i-th item.

$$\displaystyle{ \mathrm{similarity}(l_{a},l_{b}) = \frac{\sum _{u\in U}(r_{u,l_{a}} -\overline{r_{l_{a}}}) \times (r_{u,l_{b}} -\overline{r_{l_{b}}})} {\sqrt{\sum _{u\in U } {(r_{u,l_{a } } - \overline{r_{l_{a } } } )}^{2}} \times \sqrt{\sum _{u\in U } {(r_{u,l_{b } } - \overline{r_{l_{b } } } )}^{2}}} }$$
(2.3)

The information about the set of items with a similar rating pattern compared to the item under consideration is the basis for predicting the rating of user U a for the item; see Eq. (2.4). Note that in this case NN represents a set of items already evaluated by U a . Based on the assumption of k = 1, prediction(U a , l 3) = 4.0, i.e., user U a would rate item l 3 with 4.0.

$$\displaystyle{ \mathrm{prediction}(U_{a},\mathit{item}) = \frac{\sum _{\mathit{it}\in \mathit{NN}}\mathrm{similarity}(\mathit{item},\mathit{it}) \times r_{a,\mathit{it}}} {\sum _{\mathit{it}\in \mathit{NN}}\mathrm{similarity}(\mathit{item},\mathit{it})} }$$
(2.4)

For a discussion of advanced collaborative recommendation approaches, we refer the reader to Koren et al. [37] and Sarwar et al. [54].

3 Content-Based Filtering

Content-based filtering [49] is based on the assumption of monotonic personal interests. For example, users interested in the topic Operating Systems are typically not changing their interest profile from one day to another but will also be interested in the topic in the (near) future. In online scenarios, content-based recommendation approaches are applied, for example, when it comes to the recommendation of websites [49] (news items with a similar content compared to the set of already consumed news).

Content-based filtering (see Fig. 2.2) relies on two different types of background data: (1) a set of users and (2) a set of categories (or keywords) that have been assigned to (or extracted from) the available items (item descriptions). Content-based filtering recommendation systems calculate a set of items that are most similar to items already known to the current user U a .

The basic approach of content-based filtering is to compare the content of already consumed items (e.g., a list of news articles) with new items that can potentially be recommended to the user, i.e., to find items that are similar to those already consumed (positively rated) by the user. The basis for determining such a similarity are keywords extracted from the item content descriptions (e.g., keywords extracted from news articles) or categories in the case that items have been annotated with the relevant meta-information. Readers interested in the principles of keyword extraction are referred to Jannach et al. [33]. Within the scope of this chapter we focus on content-based recommendation which exploits item categories (see Table 2.1).

Content-based filtering will now be explained based on a running example which relies on the information depicted in Tables 2.1, 2.5, and 2.6. Table 2.1 provides an overview of the relevant items and the assignments of items to categories. Table 2.5 provides information on which categories are of relevance for the different users. For example, user U 1 is primarily interested in items related to the categories Java and UML. In our running example, this information has been derived from the rating matrix depicted in Table 2.2. Since user U a already rated the items l 4, l 6, and l 10 (see Table 2.2), we can infer that U a is interested in the categories UML, Management, and Quality (see Table 2.5) where items related to the category UML and Management have been evaluated two times and items related to Quality have been evaluated once.

Fig. 2.2
figure 2

Content-based filtering (CBF) dataflow. Users rate items and receive recommendations of items similar to those that have received a good evaluation from the current user U a

Full size image
Table 2.5 Degree of interest in different categories. For example, user U 1 accessed a learning unit related to the category Java three times. If a user accessed an item at least once, it is inferred that the user is interested in this item
Full size table

If we are interested in an item recommendation for the user U a we have to search for those items which are most similar to the items that have already been consumed (evaluated) by the U a . This relies on the simple similarity metric shown in Eq. (2.5) (the Dice coefficient, which is a variation of the Jaccard coefficient that “intensively” takes into account category commonalities—see also Jannach et al. [33]). The major difference from the similarity metrics introduced in the context of collaborative filtering is that in this case similarity is measured using keywords (in contrast to ratings).

$$\displaystyle{ \mathrm{similarity}(U_{a},\mathit{item}) = \frac{2 \times \mathrm{categories}(U_{a})\: \cap \:\mathrm{categories}(\mathit{item})} {\mathrm{categories}(U_{a}) + \mathrm{categories}(\mathit{item})} }$$
(2.5)

4 Knowledge-Based Recommendation

Compared to the approaches of collaborative filtering and content-based filtering, knowledge-based recommendation [5, 14, 16, 23, 42] does not primarily rely on item ratings and textual item descriptions but on deep knowledge about the offered items. Such deep knowledge (semantic knowledge [16]) describes an item in more detail and thus allows for a different recommendation approach (see Table 2.7).

Table 2.6 Example of content-based filtering. User U a has already consumed the items l 4, l 6, and l 10; see Table 2.2. The item most similar—see Eq. (2.5)—to the preferences of U a is l 8 and is now the best recommendation candidate for the current user
Full size table
Table 2.7 Software engineering learning units (LU) described based on deep knowledge: obligatory vs. nonobligatory (Oblig.), duration of consumption (Dur.), recommended semester (Sem.), complexity of the learning unit (Compl.), associated topics (Topics), and average user rating (Eval.)
Full size table

Knowledge-based recommendation (see Fig. 2.3) relies on the following background data: (a) a set of rules (constraints) or similarity metrics and (b) a set of items. Depending on the given user requirements, rules (constraints) describe which items have to be recommended. The current user U a articulates his/her requirements (preferences) in terms of item property specifications which are internally as well represented in terms of rules (constraints). In our example, constraints are represented solely by user requirements, no further constraint types are included (e.g., constraints that explicitly specify compatibility or incompatibility relationships). An example of such a constraint is topics = Java. It denotes the fact that the user is primarily interested in Java-related learning units. For a detailed discussion of further constraint types, we refer the reader to Felfernig et al. [16]. Constraints are interpreted and the resulting items are presented to the user.Footnote 2 A detailed discussion of reasoning mechanisms that are used in knowledge-based recommendation can be found, for example, in Felfernig et al. [16, 17, 22].

Fig. 2.3
figure 3

Knowledge-based recommendation (KBR) dataflow: users are entering their preferences and receive recommendations based on the interpretation of a set of rules (constraints)

Full size image

In order to determine a recommendation in the context of knowledge-based recommendation scenarios, a recommendation task has to be solved.

Definition 2.1.

A recommendation task is a tuple (R, I) where R represents a set of user requirements and I represents a set of items (in our case: software engineering learning units l i  ∈ LU). The goal is to identify those items in I which fulfill the given user requirements (preferences).

A solution for a recommendation task (also denoted as recommendation) can be defined as follows.

Definition 2.2.

A solution for a recommendation task (R, I) is a set S \(\subseteq \) I such that \(\forall l_{i} \in S: l_{i} \in \sigma _{(R)}I\) where σ is the selection operator of a conjunctive query [17], R represents a set of selection criteria (represented as constraints), and I represents an item table (see, for example, Table 2.7). If we want to restrict the set of item properties shown to the user in a result set (recommendation), we have to additionally include projection criteria π as follows: \(\pi _{(\mathit{attributes}(I))}(\sigma _{(R)}I)\).

In our example, we show how to determine a solution for a given recommendation task based on a conjunctive query where user requirements are used as selection criteria (constraints) on an item table I. If we assume that the user requirements are represented by the set \(R =\{ r_{1}: \mathit{semester} \leq 3,r_{2}: \mathit{topics} = \text{Java}\}\) and the item table I consists of the elements shown in Table 2.7, then \(\pi _{(\mathit{LU})}(\sigma _{(\mathit{semester}\,\leq \,3\;\wedge \;\mathit{topics}=\text{Java})}I)\) = {\(l_{1},l_{2},l_{7}\)}, i.e., these three items are consistent with the given set of requirements.

Ranking Items. Up to this point we only know which items can be recommended to a user. One widespread approach to rank items is to define a utility scheme which serves as a basis for the application of multi-attribute utility theory (MAUT).Footnote 3 Alternative items can be evaluated and ranked with respect to a defined set of interest dimensions. In the domain of e-learning units, example interest dimensions of users could be time effort (time needed to consume the learning unit) and quality (quality of the learning unit). The first step to establish a MAUT scheme is to relate the interest dimensions to properties of the given set of items. A simple example of such a mapping is shown in Table 2.8. In this example, we assume that obligatory learning units (learning units that have to be consumed within the scope of a study path) trigger more time efforts than nonobligatory ones, a longer duration of a learning unit is correlated with higher time efforts, and low complexity correlates with lower time efforts. In this context, lower time efforts for a learning unit are associated with a higher utility. Furthermore, we assume that the more advanced the semester, the higher is the quality of the learning unit (e.g., in terms of education degree). The better the overall evaluation (eval), the higher the quality of a learning unit (e.g., in terms of the used pedagogical approach).

Table 2.8 Contributions of item properties to the dimensions time effort and quality
Full size table

We are now able to determine the user-specific utility of each individual item. The calculation of item utilities for a specific user U a can be based on Eq. (2.6).

$$\displaystyle{ \mathrm{utility}(U_{a},\mathit{item}) =\sum _{d\in \mathit{Dimensions}}\mathrm{contribution}(\mathit{item},d) \times \mathrm{weight}(U_{a},d) }$$
(2.6)

If we assume that the current user U a assigns a weight of 0.2 to the dimension time effort (\(\mathrm{weight}(U_{a},\mathit{timeeffort}) = 0.2\)) and a weight of 0.8 to the dimension quality (\(\mathrm{weight}(U_{a},\mathit{quality}) = 0.8\)), then the user-specific utilities of the individual items (l i ) are the ones shown in Table 2.9.

Table 2.9 Item-specific utility for user U a (i.e., \(\mathrm{utility}(U_{a},l_{i})\)) assuming the personal preferences for time effort = 0.2 and quality = 0.8. In this scenario, item l 4 has the highest utility for user U a
Full size table

Dealing with Inconsistencies. Due to the logical nature of knowledge-based recommendation problems, we have to deal with scenarios where no solution (recommendation) can be identified for a given set of user requirements, i.e., \(\sigma _{(R)}I = \varnothing \). In such situations we are interested in proposals for requirements changes such that a solution (recommendation) can be identified. For example, if a user is interested in learning units with a duration of 4 h, related to management, and a complexity level > 3, then no solution can be provided for the given set of requirements \(R =\{ r_{1}: \mathit{duration} = 4,r_{2}: \mathit{topics} = \text{management},r_{3}: \mathit{complexity} > 3\}\).

User support in such situations can be based on the concepts of conflict detection [34] and model-based diagnosis [13, 15, 51]. A conflict (or conflict set) with regard to an item set I in a given set of requirements R can be defined as follows.

Definition 2.3.

A conflict set is a set \(\mathit{CS} \subseteq R\) such that \(\sigma _{(\mathit{CS})}I = \varnothing \). CS is minimal if there does not exist a conflict set CS′ with \(\mathit{CS}^{\prime} \subset \mathit{CS}\).

In our running example we are able to determine the following minimal conflict sets CS i : \(\mathit{CS}_{1}:\{ r_{1},r_{2}\}\), \(\mathit{CS}_{2}:\{ r_{2},r_{3}\}\). We will not discuss algorithms that support the determination of minimal conflict sets but refer the reader to the work of Junker [34] who introduces a divide-and-conquer-based algorithm with a logarithmic complexity in terms of the needed number of consistency checks.

Based on the identified minimal conflict sets, we are able to determine the corresponding (minimal) diagnoses. A diagnosis for a given set of requirements which is inconsistent with the underlying item table can be defined as follows.

Definition 2.4.

A diagnosis for a set of requirements \(R =\{ r_{1},r_{2},\ldots,r_{n}\}\) is a set \(\varDelta \subseteq R\) such that \(\sigma _{(R-\varDelta )}I\neq \varnothing \). A diagnosis Δ is minimal if there does not exist a diagnosis Δ′ with Δ′ ⊂ Δ.

In other words, a diagnosis (also called a hitting set ) is a minimal set of requirements that have to be deleted from R such that a solution can be found for R −Δ. The determination of the complete set of diagnoses for a set of requirements inconsistent with the underlying item table (the corresponding conjunctive query results in \(\varnothing \)) is based on the construction of hitting set trees [51]. An example of the determination of minimal diagnoses is depicted in Fig. 2.4. There are two possibilities of resolving the conflict set CS 1. If we decide to delete the requirement r 2, \(\sigma _{(\{r_{1},r_{3}\})}I\neq \varnothing \), i.e., a diagnosis has been identified (Δ 1 = { r 2}) and—as a consequence—all CS i have been resolved. Choosing the other alternative and resolving CS 1 by deleting r 1 does not result in a diagnosis since the conflict CS 2 is not resolved. Resolving CS 2 by deleting r 2 does not result in a minimal diagnosis, since r 2 already represents a diagnosis. The second (and last) minimal diagnosis that can be identified in our running example is \(\varDelta _{2} =\{ r_{1},r_{3}\}\). For a detailed discussion of the underlying algorithm and analysis we refer the reader to Reiter [51]. Note that a diagnosis provides a hint to which requirements have to be changed. For a discussion of how requirement repairs (change proposals) are calculated, we refer the reader to Felfernig et al. [17].

Fig. 2.4
figure 4

Determination of the complete set of diagnoses (hitting sets) Δ i for the given conflict sets \(\mathit{CS}_{1} =\{ r_{1},r_{2}\}\) and \(\mathit{CS}_{2} =\{ r_{2},r_{3}\}\): \(\varDelta _{1} =\{ r_{2}\}\) and \(\varDelta _{2} =\{ r_{1},r_{3}\}\)

Full size image

5 Hybrid Recommendations

After having discussed the three basic recommendation approaches of collaborative filtering, content-based filtering, and knowledge-based recommendation, we will now present some possibilities to combine these basic types.

The motivation for hybrid recommendations is the opportunity to achieve a better accuracy [6]. There are different approaches to evaluate the accuracy of recommendation algorithms. These approaches (see also Avazpour et al. [2] and Tosun Mısırlı et al. [58] in Chaps. 10 and 13, respectively) can be categorized into predictive accuracy metrics such as the mean absolute error (MAE), classification accuracy metrics such as precision and recall, and rank accuracy metrics such as Kendall’s Tau. For a discussion of accuracy metrics we refer the reader also to Gunawardana and Shani [28] and Jannach et al. [33].

We now take a look at example design types of hybrid recommendation approaches [6, 33] which are weighted, mixed, and cascade (see Table 2.10). These approaches will be explained on the basis of our running example. The basic assumption in the following is that individual recommendation approaches return a list of five recommended items where each item has an assigned (recommender-individual) prediction out of {1.0, 2.0, 3.0, 4.0, 5.0}. For a more detailed discussion of hybridization strategies, we refer the reader to Burke [6] and Jannach et al. [33].

Table 2.10 Examples of hybrid recommendation approaches (RECS = set of recommenders, s  =  recommender-individual prediction, \(\mathrm{score}\) = item score)
Full size table

Weighted. Weighted hybrid recommendation is based on the idea of deriving recommendations by combining the results (predictions) computed by individual recommenders. A corresponding example is depicted in Table 2.11 where the individual item scores of a collaborative and a content-based recommender are summed up. Item l 8 receives the highest overall score (9.0) and is ranked highest by the weighted hybrid recommender.Footnote 4

Table 2.11 Example of weighted hybrid recommendation: individual predictions are integrated into one score. Item l 8 receives the best overall score (9.0)
Full size table

Mixed. Mixed hybrid recommendation is based on the idea that predictions of individual recommenders are shown in one integrated result. For example, the results of a collaborative filtering and a content-based recommender can be ranked as sketched in Table 2.12. Item scores can be determined, for example, on the basis of the zipper principle, i.e., the item with highest collaborative filtering prediction value receives the highest overall score (10.0), the item with best content-based filtering prediction value receives the second best overall score, and so forth.

Table 2.12 Example of mixed hybrid recommendation. Individual predictions are integrated into one score conform the zipper principle (best collaborative filtering prediction receives score = 10, best content-based filtering prediction receives score = 9 and so forth)
Full size table

Cascade. The basic idea of cascade-based hybridization is that recommenders in a pipe of recommenders exploit the recommendation of the upstream recommender as a basis for deriving their own recommendation. The knowledge-based recommendation approach presented in Sect. 2.4 is an example of a cascade-based hybrid recommendation approach. First, items that are consistent with the given requirements are preselected by a conjunctive query Q. We can assume, for example, that s(item, Q) = 1.0 if the item has been selected and s(item, Q) = 0. 0 if the item has not been selected. In our case, the set of requirements \(R =\{ r_{1}: \mathit{semester} \leq 3,r_{2}: \mathit{topics} = \mathit{Java}\}\) in the running example leads to the selection of the items {\(l_{1},l_{2},l_{7}\)}. Thereafter, these items are ranked conform to their utility for the current user (utility-based ranking U). The utility-based ranking U would determine the item order utility(l 1) > utility(l 2) > utility(l 7) assuming that the current user assigns a weight of 0.8 to the interest dimension quality (weight(U a ,quality) = 0.8) and a weight of 0.2 to the interest dimensions time effort (weight(U a ,time effort) = 0.2). In this example the recommender Q is the first one and the results of Q are forwarded to the utility-based recommender.

Other examples of hybrid recommendation approaches include the following [6]. Switching denotes an approach where—depending on the current situation—a specific recommendation approach is chosen. For example, if a user has a low level of product knowledge, then a critiquing-based recommender will be chosen (see Sect. 2.7). Vice versa, if the user is an expert, an interface will be provided where the user is enabled to explicitly state his/her preferences on a detailed level. Feature combination denotes an approach where different data sources are exploited by a single recommender. For example, a recommendation algorithm could exploit semantic item knowledge in combination with item ratings (see Table 2.7). For an in-depth discussion of hybrid recommenders, we refer the reader to Burke [6] and Jannach et al. [33].

6 Hints for Practitioners

In this section we provide several hints for practitioners who are interested in developing recommendation systems.

6.1 Usage of Algorithms

The three basic approaches of collaborative filtering, content-based filtering, and knowledge-based recommendation exploit different sources of recommendation knowledge and have different strengths and weaknesses (see Table 2.13). Collaborative filtering (CF) and content-based filtering (CBF) are easy to set up (only basic item information is needed, e.g., item name and picture), whereas knowledge-based recommendation requires a more detailed specification of item properties (and in many cases also additional constraints). Both CF and CBF are more adaptive in the sense that new ratings are automatically taken into account in future activations of the recommendation algorithm. In contrast, utility schemes in knowledge-based recommendation (see, for example, Table 2.9) have to be adapted manually (if no additional learning support is available [21]).

Table 2.13 Summary of the strengths and weaknesses of collaborative filtering (CF), content-based filtering (CBF), and knowledge-based recommendation (KBR)
Full size table

Serendipity effects are interpreted as a kind of accident of being confronted with something useful although no related search has been triggered by the user. They can primarily be achieved when using CF approaches. Due to the fact that content-based filtering does not take into account the preferences (ratings) of other users, no such effects can be achieved. Achieving serendipity effects for the users based on KBR is possible in principle, however, restricted to and depending on the creativity of the knowledge engineer (who is able to foresee such effects when defining recommendation rules). The ramp-up problem (also called the cold start problem ) denotes a situation where there is the need to provide initial rating data before the algorithm is able to determine reasonable recommendations. Ramp-up problems exist with both CF and CBF: in CF users have to rate a set of items before the algorithm is able to determine the nearest neighbors; in CBF, the user has to specify interesting/relevant items before the algorithm is able to determine items that are similar to those that have already been rated by the user.

Finally, transparency denotes the degree to which recommendations can be explained to users. Explanations in CF systems solely rely on the interpretation of the relationship to nearest neighbors, for example, users who purchased item X also purchased item Y. CBF algorithms explain their recommendations in terms of the similarity of the recommended item to items already purchased by the user: we recommend Y since you already purchased X which is quite similar to Y. Finally—due to the fact that they rely on deep knowledge—KBR is able to provide deep explanations which take into account semantic item knowledge. An example of such an explanation is diagnoses that explain the reasons as to why a certain set of requirements does not allow the calculation of a solution. Other types of explanations exist: why a certain item has been included in the recommendation and why a certain question has been asked to the user [16, 24].

Typically, CF and CBF algorithms are used for recommending low-involvement itemsFootnote 5 such as movies, books, and news articles. In contrast, knowledge-based recommender functionalities are used for the recommendation of high-involvement items such as financial services, cars, digital cameras, and apartments. In the latter case, ratings are provided with a low frequency which makes these domains less accessible to CF and CBF approaches. For example, user preferences regarding a car could significantly change within a couple of years without being detected by the recommender system, whereas such preference shifts are detected by collaborative and content-based recommendation approaches due to the fact that purchases occur more frequently and—as a consequence—related ratings are available for the recommender system. For an overview of heuristics and rules related to the selection of recommendation approaches, we refer the reader to Burke and Ramezani [9].

6.2 Recommendation Environments

Recommendation is an artificial intelligence (AI) technology successfully applied in different commercial contexts [20]. As recommendation algorithms and heuristics are regarded as a major intellectual property of a company, recommender systems are often not developed on the basis of standard solutions but are rather based on proprietary solutions that are tailored to the specific situation of the company. Despite this situation, there exist a few recommendation environments that can be exploited for the development of different recommender applications.

Strands is a company that provides recommendation technologies covering the whole range of collaborative, content-based, and knowledge-based recommendation approaches. MyMediaLite is an open-source library that can be used for the development of collaborative filtering-based recommender systems. LensKit [11] is an open-source toolkit that supports the development and evaluation of recommender systems—specifically it includes implementations of different collaborative filtering algorithms. A related development is MovieLens which is a noncommercial movie recommendation platform. The MovieLens dataset (user × item ratings) is publicly available and popular dataset for evaluating new algorithmic developments. Apache Mahout is a machine learning environment that also includes recommendation functionalities such as user-based and item-based collaborative filtering.

Open-source constraint libraries such as Choco and Jacop can be exploited for the implementation of knowledge-based recommender applications. WeeVis is a Wiki-based environment for the development of knowledge-based recommender applications—resulting recommender applications can be deployed on different handheld platforms such as iOS, Android, and Windows 8. Finally, Choicla is a group recommendation platform that allows the definition and execution of group recommendation tasks (see Sect. 2.7).

7 Further Algorithmic Approaches

We examine two further algorithmic approaches here: general critiquing-based recommendations and group recommendations.

7.1 Critiquing-Based Recommendation

There are two basic approaches to support item identification in the context of knowledge-based recommendation.

First, search-based approaches require the explicit specification of search criteria and the recommendation algorithm is in charge of identifying a set of corresponding recommendations [16, 57] (see also Sect. 2.4). If no solution can be found for a given set of requirements, the recommendation engine determines diagnoses that indicate potential changes such that a solution (recommendation) can be identified. Second, navigation-based approaches support the navigation in the item space where in each iteration a reference item is presented to the user and the user either accepts the (recommended) item or searches for different solutions by specifying critiques. Critiques are simple criteria that are used for determining new recommendations that take into account the (changed) preferences of the current user. Examples of such critiques in the context of our running example are less time efforts and higher quality (see Fig. 2.5). Critiquing-based recommendation systems are useful in situations where users are not experts in the item domain and prefer to specify their requirements on the level of critiques [35]. If users are knowledgeable in the item domain, the application of search-based approaches makes more sense. For an in-depth discussion of different variants of critiquing-based recommendation, we refer the reader to [8, 10, 27, 41, 46, 52].

Fig. 2.5
figure 5

Example of a critiquing scenario. The entry item l 7 is shown to the user. The user specifies the critique “less time effort.” The new entry item is l 9 since it is consistent with the critique and the item most similar to l 7

Full size image

7.2 Group Recommendation

Due to the increasing popularity of social platforms and online communities, group recommendation systems are becoming an increasingly important technology [29, 44]. Example application domains of group recommendation technologies include tourism [47] (e.g., which hotels or tourist destinations should be visited by a group?) and interactive television [43] (which sequence of television programs will be accepted by a group?). In the majority, group recommendation algorithms are related to simple items such as hotels, tourist destinations, and television programs. The application of group recommendation in the context of our running example is shown in Table 2.14 (selection of a learning unit for a group).

The group recommendation task is to figure out a recommendation that will be accepted by the whole group. The group decision heuristics applied in the context is least misery which returns the lowest voting for alternative l i as group recommendation. For example, the least misery value for alternative l 7 is 3. 0 which is the highest value of all possible alternatives, i.e., the first recommendation for the group is l 7. Other examples of group recommendation heuristics are most pleasure (the group recommendation is the item with the most individual votes) and majority voting (the voting for an individual solution is defined by the majority of individual user votes: the group recommendation is the item with the highest majority value). Group recommendation technologies for high-involvement items (see Sect. 2.6) are the exception of the rule [e.g., 31, 55]. First applications of group recommendation technologies in the software engineering context are reported in Felfernig et al. [25]. An in-depth discussion of different types of group recommendation algorithms can be found in O’Connor et al. [48], Jameson and Smyth [32], and Masthoff [44].

Table 2.14 Example of group recommendation: selection of a learning unit for a group. The recommendation (l 7) is based on the least misery heuristic
Full size table

8 Conclusion

This chapter provides an introduction to the recommendation approaches of collaborative filtering, content-based filtering, knowledge-based recommendation, and different hybrid variants thereof. While collaborative filtering-based approaches exploit ratings of nearest neighbors, content-based filtering exploits categories and/or extracted keywords for determining recommendations. Knowledge-based recommenders should be used, for example, for products where there is a need to encode the recommendation knowledge in terms of constraints. Beside algorithmic approaches, we discussed criteria to be taken into account when deciding about which recommendation technology to use in a certain application context. Furthermore, we provided an overview of environments that can be exploited for recommender application development.