In this paper, we present a prototype of a group recommendation system for concerts. The prototype is context sensitive taking the user's location and time into account when giving recommendations. The prototype implements three algorithms to recommend concerts by taking advantage of what users have listened to before: a collaborative ltering algorithm (K-Nearest Neighbor), a Matrix Factorization algorithm, and a Hybrid approach combining these two. The usability of the prototype was evaluated using the System Usability Scale and a user centered evaluation was performed to evaluate the quality of recommendations. The results from the usability evaluation shows that users generally were satis ed with the usability of the prototype. The results from the Quality Evaluation shows that the KNearest Neighbor and Hybrid approach produces satisfactory results whereas the Matrix Factorization implementation was experienced to be a bit poorer. The users testing the prototype were generally satis ed with the quality of recommendations.
Recommendation technology is becoming an increasingly
important part of large systems such as Amazon.com and
eBay.com, and also in the music industry for example
Spotify, iTunes and Last.fm recommendations are used in to an
increasing degree. A context-aware group recommendation
system is a recommendation system that recommends items
for groups of people instead of for a single person in the given
context [
In the next section, we present the main approach, data model and algorithms. In Section 3, the experiments and evaluations is presented. Related work is described in Section 4, before we conclude in Section 5, pointing to future work. 2.
DATA MODEL AND RECOMMENDATION ALGORITHM
Illustrating the problem of context-based group recommendation, we take the following scenario as an outset: A group of friends is traveling to a big city to stay there for a week. Here they wants to attend a concert. Their tastes in music are quite di erent, so choosing what concerts to attend is a challenge. Moreover, they may not be familiar with all the bands playing and would like to have an application that give them recommendations concerning which concerts to attend based on the type of music they have listened to before and their personal musical preferences.
We consider the following requirements for designing contextaware group recommendation for concerts:
Recommendations need to be based on the user's listening preferences The system should be location-aware (concerts close to a user are preferred) The system should be time-aware (not recommend concerts that already have taken place or concerts too far ahead in time) Context relaxation should be supported (recommendations for more widespread locations or time-period can be attempted if not enough concerts are found for the given location or time) 2.1
The main concepts used to support these requirements are depicted in the data-model in Figure. 1. Users have previously listened to music by existing artists. The artists are in addition tagged (with musical categories), and one have information about the tags/interests of users. Based on listening and tagging history, user-similarity is calculated. Artist play concerts. The concerts take place on venues at a certain time and space (geographically located) in a particular city.
Context captures information that is not part of the database,
such as the user location or the current time. A user would
probably want to get recommendations for concerts in
locations close to where he is located, and not get
recommendations for concerts too far ahead in time (unless planning
ahead for a later travel of course), or for concerts that
already have taken place. Therefore the de nition of these
context parameters should be a central part of any concert
recommendation system (CRS). In particular, a context
parameter can be relaxed upwards by replacing its value by a
more general one, downwards by replacing its value by a set
of more speci c ones or sideways by replacing its value by
sibling values in the a context-hierarchy [
We have retrieved listening history from the Last.fm music
discovery service. The algorithms in our work are based on
explicit feedback from users, subsequently there is a need
to normalize the listening counts to a prede ned scale so
that the algorithms can work optimally on Last.fm dataset.
Similarly to the approach taken by [
The K-Nearest Neighbor (KNN) algorithm was one of the
rst approaches used in user-based recommendation [
2.4.1
In a KNN approach, the K-Nearest Neighbors of u are used as a basis for recommendation. For simplicity reasons we state that a user that have not listened to any of the artists in A0 cannot be considered by the algorithm. This can be done because a user that has not listened to any of the artists in A0, could only contribute with a listening count of 0 to all of them, and therefore the user might be left out.
Since the set of artists that are considered in the algorithm has been reduced to the set of artists A0 playing at one of the concerts in C0, implicitly the set of users considered for the algorithm can be reduced to the set of users that have listened to one or more of the artists in A0.
U 0 = u0 : 8u0 2 U 9a 2 A0listenedT o(u0; a) (1) 2.4.2
In a KNN algorithm, the K most similar users to u are found, and their ratings are used as a basis for recommendation. To nd these similar users, we applied cosine similarity based on listening count of two users for each artist. So, the user vector wi for a user ui 2 U is de ned as the vector of the users listening counts to each of the artists in A. wi = flistenCount(i; a) : a 2 Ag (2)
In a normal K-Nearest Neighbor algorithm the K users with the highest similarity would now be identi ed and used as a basis for recommendation. For the purpose of a CRS, this is not enough. Here, a rating for each of the concerts, ci, in C0 have to be predicted. Therefore, a 3 step process is undertaken for each of the concerts: 1. Find the K users, U 00, with the highest similarity to u from the subset of U 0 that have listened to one or more of the artists performing at that concert. 2. Calculate the predicted rating for each of the artists a playing at the concert. T otalSimilarity is de ned as the sum of similarities to u from each of the users in U 00. Each of the users ui in U 00 will contribute to the sim(ui;u) predicted rating with a percentage of totalSimilarity . The actual contribution is in uenced by the rating given to a by ui, so this is multiplied with rating(ui; a). The predicted rating for an artist i will then be: artistRatingi = j=1 Xn sim(uj; u) listenCount(uj; ai) totalSimilarity (3) 3. The overall predicted rating for the concert ci as a whole for user u is given by the average of the predicted ratings to each of the m artists performing at ci.
KN N Ratingcui = k=1 m P artistRatingk m 2.5
Similarly to [
r^ua = BaT Vu We will refer to this model as P ureSV D. It uses f = 64 features which are optimized by running over 120 iterations. The implementation is based on Timely Developments2 implementation of the algorithm.
The overall predicted rating for the concert ci as a whole for user u is given by the average of the predicted ratings to each of the m artists performing at ci. m
P r^ua mf Ratingcui = a=1 m 2.6
The predictions given by the algorithms in the previous two sections are in this phase aggregated to produce the nal top N concerts to return to the user. For each of the concerts, ci, in C the nal rating for the concert for u, ruci 2 Ru is given by: r^uic = mf Ratingcui + knnRatingcui 2
The N concerts with the highest rating ruci in R are selected and returned to the user. 2.7
In this work, an average aggregation strategy (which computes the group preference for an item as the average of group members' preferences for that item) is used to aggregate individual ratings into a group rating for a concert. Since, in a music recommendation system we have to utilize implicit feedback, there is no such thing as a negative preference. For example, a listen count of 0 does not necessarily mean that a user does not like the artist, just that the user has not listened to the artist before. The user might like the artist, but he has not discovered it, or he might dislike it. Therefore, it is impossible to know for certain how to interpret a listen count of 0. Similarly, a low listening count may not mean that a user does not like the artist, he might just have discovered the artist or just joined the system. Again, it is impossible to know. Thus, we can safely assume that Least Misery ( which computes the group preference for an 2http://www.timelydevelopment.com/demos/Net ixPrize (4) (5) (6) (7) item as the minimum among all group members' preferences for that item) in an aggregation method would not be applicable thus we used the average strategy. 3.
We evaluate our group recommendation system from two major angles. First, from the usability perspective (Section 3.1), and second quality perspective (Section 3.2). We implemented our prototype system using Java and MySQL for the back end. The front end was developed in JavaScript and HTML5, and is based on the Durandal.js3 Model View Viewmodel framework.
Dataset description: We use the Last.fm dataset for evaluation purposes. Last.fm has become a relevant online service in music based social networking. In our particular CRS the data was fetched using Last.fm's publicly available API4.The dataset as seen in Table 1 consists of 2; 891 concerts in Vancouver, New York, London, Oslo, and surrounding areas, between 18. February 2014 and 6. June 2014. The dataset was built by rst fetching concerts within a 100km radius from the speci ed cities. Then, information about the artists performing at those concerts were fetched. Users that have listened to the artists found are then fetched, before the 30 most listened to artists for each user are fetched and saved. In addition to these data, information about the venue that each concert is held at and the most used tags for each artist is stored. When a new user was created where no existing data was present in Last.fm, he would need to rate at least 5 artist that are registered in Last.fm. In the quality experiments below, we have looked upon di erences when providing 5 or 10 ratings.
Artists
Concerts
Listening counts
Tags
Tags for artists
Artist concert participation
User similarities
Venues
User features
Artist features
Count
statement. Nielsen suggests that 5 users are enough to nd
the majority of usability problems of a system, those 5
participants could reveal about 80% of all usability problems
[
The results from the SUS survey yielded a SUS score of
79:83. [
To evaluate the quality of recommendations from the improved system, two groups consisting of two and three people respectively were asked to nd recommendations both individually and in a group setting, for di erent dates and places, and to rate how satis ed they were with the given recommendations. For this purpose, we showed three di erent lists where each list was the result of using the three di erent algorithms (k-NN algorithm, MF algorithm, the hybrid approach). Each of the lists are given "random" case ids and placed in a random order. The participants were asked to nd recommendations individually, in a group of two people, and in a group of three people, for two di erent timespans (18=02=2014 03=03=2014 and 05=03=2014 09=07=2014), and two di erent cities (London and New York). When
k-Nearest Neighbor Hybrid approach
As seen in Table 2, the MF algorithm were overall picked as giving the most appealing results 7 out of 40 times, the kNN algorithm 16 out of 40 times, and the hybrid approach in 17 out of 40 cases. Overall, the kNN algorithm received an average rating of 3.72 in the 40 responses, the Hybrid approach 3.62, and the MF algorithm an average of 2.87 as seen in Table 3. Table 4 shows statistics when recommendations were given for groups consisting of 1, 2 and 3 users respectively. From these results there is a clear trend that the kNN and the hybrid approach tend to produce more satisfying recommendations than the MF approach as the average ratings given to the two are generally lower, and they were picked as the favorite algorithms signi cantly more. An overall average rating of 3.72 and 3.62 out of 5 from the kNN and Hybrid approaches respectively, indicates that the participants were reasonably satis ed with the results given. In general, recommendations given for users created based on 10 of the user's favorite artists, produced more satisfying results than when 5 artists were used in the user creation process. Moreover, by increasing the number of users in a group from two to three users user satisfaction is decreasing. 3.3
Insight about Serendipity in Concert Recommendation Systems
Serendipity is concerned with the novelty of
recommendations and in how far recommendations may positively
surprise the user [
The quality evaluation was performed with only two groups of 2 and 3 people. This low number of participants means that each participant had a very large impact on the results. The statistics produced when a user was created with 5 and 10 favorite artists, were based on n = 10 samplings each; the same was the case with the statistics produced for the results with varying group sizes. By looking at the top tags used for the artists each of the users registered, it is apparent that the users' taste in music are quite di erent as they share few top tags amongst them. However, because of the low number of users and sample sizes, even with this diversity, it cannot be said that these ve users are representative for the whole potential user base, and therefore, further testing should be performed to measure the Quality of Recommendations created by the prototype. Even though more testing is needed, there still is a strong indication that the KNN and Hybrid approaches perform better than the MF approach as suggested with a sample size of n = 40. Similarly, it can be said that the ve users testing the prototype were reasonably happy with the resultss. 4.
Group Recommendation Systems try to provide
recommendations to a group of people instead of a single
individual. There are two main approaches of accomplishing
this: calculating recommendations individually for each of
the members of the group, and then aggregating the
individual results, or merging the preferences of each of the
members of the group, and then providing one set of
recommendations based on the merged pro le [
In this paper, a prototype of a context-aware group recommendation system for concerts was presented. The prototype implemented three di erent algorithms, a Matrix Factorization algorithm, a k-Nearest Neighbor algorithm and a Hybrid approach of the two. The usability of the prototype was evaluated using the System Usability Scale (SUS) and an Application Speci c Survey (AS). 15 people were asked to undertake these surveys. In total, the prototype got a SUS score of 79.83 which is a good indication on that the users found the usability of the prototype satisfactory. However, the comments from the free text answers shows that there where room for improvements. The AS mainly focused on the usability of the context relaxation part of the prototype, to nd out if it was easy to nd concerts close to the parameters speci ed when it comes to time and location. The results from the AS showed that the users in general were satis ed with how this process worked. The goal for this prototype was to recommend concerts to a user within the location and timespan given that the user could be interested in attending. To evaluate how well this was achieved, a Recommendation Quality Evaluation(QE) was undertaken with two groups consisting of 2 and 3 people respectively. Through a range of scenarios, the groups were told to nd recommendations for the dates and location asked about, and for each algorithm, rate how satis ed they were with the results. The results from the QE showed that the users generally were satis ed with the KNN implementation and the Hybrid approach, whereas they were less satis ed with the MF approach. The QE was also undertaken to see how different group sizes a ected the quality of recommendations. The results showed that the users became less satis ed when the number of members in the group increased from one to two and three respectively, which is to be expected as di erent preferences has to be taken into account in larger groups. However, the QE was only performed with ve participants, so there is a need for an evaluation with more participants to able to draw any further conclusions. Another way to go from here is to have a look at the context-aware part of the application. Is there any bene t in making relaxation of context an implicit part of the algorithm instead of something performed by the user explicitly? How would other context variables, such as listen recency a ect the satisfactions when recommending concerts? 6.