Pattern Recognition Letters 105 (2018) 121–134

Contents lists available at ScienceDirect

Pattern Recognition Letters

journal homepage: www.elsevier.com/locate/patrec

EventAware: A mobile recommender system for events

Daniel Horowitz a, David Contreras b,a,∗, Maria Salamó a
a
Dept. Mathematics and Informatics, University of Barcelona, Gran Via de les Corts Catalanes, 585,-08007, Barcelona, Spain
b
Facultad de Ingeniería y Arquitectura, Universidad Arturo Prat, Avenida Arturo Prat, 2120, Iquique, Chile

a r t i c l e i n f o a b s t r a c t

Article history: Developing a recommender system for events raises several issues that are different from other domains.
Available online 8 July 2017 Events rapidly disappear, users’ preferences quickly change over time, and direct feedback does not exist
for events that have not taken place. As the recommendations will not be further available, user’s context
Keywords:
become a key factor for providing accurate recommendations. In this paper we introduce EventAware, a
Recommender systems
Natural language processing
context-aware mobile recommender system to personalize the agenda of users attending to a congress.
Mobile technologies In particular, we first introduce the EventAware system, which includes an intuitive user interface with
an attractive design to enhance user experience. EventAware incorporates some implicit contextual infor-
mation, automatically initializes both the user’s profiles with minimal user interaction and the properties
of the items and it uses a context-aware tag-based recommender algorithm. We demonstrate its usability
through a live-user case-study in one of the biggest events of mobile technology in the world, held in
Barcelona.
© 2017 Elsevier B.V. All rights reserved.

1. Introduction context1 in which recommendations occurs in addition to the in-

formation that traditional recommender systems deal with: infor-
Recommender Systems (RSs) are software tools and techniques mation about the items to be recommended and information about
that allow users to identify the items that are likely to be more at- the users asking for recommendations. Although recent empiri-
tractive and useful [39]. The event recommendation problem is in- cal evaluations indicate that no context-aware approach is univer-
trinsically cold-start as Events are so called one-and-only items [12], sally dominant in the RSs literature [33], with the advent of mo-
which makes them harder to recommend. Events, by definition, are bile devices and ubiquitous computing RSs have begun to incorpo-
always in the future and are short-lived as they take place at a spe- rate Location Based Services2 into mobile applications to provide
cific moment in time and place to become irrelevant very quickly users with interesting items according to their contextual informa-
afterwards. For this reason, the development of a recommender tion [1].
system [2] for events raises several issues that are different from In this paper we describe in depth EventAware, a context-aware
other domains. In addition to the ephemeral nature of events, the tag-based mobile recommender system for events that personal-
users’ preferences quickly change over time, and direct feedback izes the agenda of users attending to a congress. EventAware has
does not exist for events that have not taken place. been specifically crafted to assist attending users to a congress
Traditional collaborative filtering [22] techniques cannot cope at by providing them with smart and personalized sessions and ex-
all with time-specific items, like events, which typically receive hibitors during the congress. EventAware includes an intuitive user
their ratings once they have finished. As a result, in the litera- interface with an attractive design to enhance user experience. In-
ture, most of the proposals for event recommendation are based stead of generating recommendations based on past events rated
on hybrid algorithms [4], which combine content-based (CB) [26] by the users in the past as in collaborative filtering, which are
and collaborative filtering (CF) [21] techniques. A special kind of in many cases difficult to obtain because the event may be com-
recommender systems are Context-Aware Recommender Systems pletely different each year, we propose to integrate a context-aware
(CARSs) [1], which take into consideration information about the and a tag-based approach for generating recommendations. Addi-

1
Context is defined as any information that can be used to characterize the sit-
uation of an entity [9]. An entity is a person, place, or object that is considered
∗
Corresponding author at : Facultad de Ingeniería y Arquitectura, Universidad Ar- relevant to the interaction between a user and an application.
turo Prat, Avenida Arturo Prat, 2120, Iquique, Chile. 2
A Location Based Service (LBS) is a software-level service that uses location data
E-mail address: [email protected] (D. Contreras). to control features.

http://dx.doi.org/10.1016/j.patrec.2017.07.003
0167-8655/© 2017 Elsevier B.V. All rights reserved.
122 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134

tionally, EventAware incorporates some implicit contextual infor- sented a system that extracts events from multiple data modalities
mation, automatically initializes both the user’s profiles with mini- and recommends events related to the user’s ongoing search based
mal user interaction and the properties (i.e., tags) that describe the on previously selected attribute values and dimensions of events
items. We demonstrate its usability through a live-user case-study being viewed. In [15] on Meetup investigated how social network,
in one of the biggest events of mobile technology in the world, user profiles and geo-locations affect user participation when the
held in Barcelona. social event is held by a single organizer. Another approach is a
The rest of this article is organized as follows: the next content-based recommender where cultural events metadata are
section reviews related work on event recommender systems; enriched with open linked data available on the web [34]. In [37] it
Section 3 describes the proposed event recommender; Next, has been proposed a standard matrix factorization approach, which
Section 4 discusses the usability of the proposal; the final section jointly models event, location, and social relation but they ignore
gives conclusions and future work. content and organizer information of events. Another approach has
considered spatial and temporal context to predict events [11]. A
2. Related work large-scale analysis of several factors that impact a user’s propen-
sity to reply positively future events in an EBSN has been con-
Event recommendation is an area of research relatively new. ducted in [28]. Considering this study, later, it has been proposed
Researchers have focused event recommendation on two main re- a context-aware approach [29] that exploits various contextual sig-
search areas: (1) Recommenders Systems [39] and (2) Event-based nals available from EBSNs, including social signals based on group
Social Networks [25]. memberships, location signals based on the users’ geographical
Firstly, a large amount of the research on event recommen- preferences, and temporal signals derived from the users’ time
dation investigated the core algorithms used for recommendation preferences. In the same direction, it has been proposed a social
generation [13]. Many of the proposals for generating event recom- event recommendation method [5] that exploits a user’s social in-
mendations are based on hybrid algorithms that combine content- teraction relations and collaborative friendships. In a large major-
based and collaborative filtering techniques. One of the first pro- ity of EBSNs users join groups unified by a common interest, and
posals towards event recommendation, that has not been evaluated events are organized by groups. Jhamb and Fang [14] have inves-
with experiments, uses a hybrid content and collaborative filtering tigated the effect of group information on event recommendation.
approach within a fuzzy relational framework [7]. In particular, the Outlife [35] is a mobile EBSN that offers users personalized sug-
underlying goal of this fuzzy relational approach is to recommend gestions for events, as well as suggestions for inviting a group of
future events if they are similar to past events that similar users friends to attend the recommended event together, based on the
have liked. individual preferences and the users’ Facebook profiles. The event
Alternatively, it has also been proposed a cultural event recom- recommendation is addressed by selecting the most appropriate al-
mender [23], based on collaborative filtering, that provides a way gorithm for each situation (with a decision tree) out of a set of rec-
for users to rate the trustworthiness of other users. Then, according ommender algorithms. If no ratings are available a content-based
to these ratings, a recommendation is generated. A similar princi- algorithm is used.
ple follows a recommender system for academic events [20], which Although the latter approach seems similar to EventAware, it
focuses on social network analysis in combination with collabo- is important to remark that our proposal is not an EBSN because
rative filtering. It is worth noting an approach [10] that compares it was conceived to be a mobile recommender to personalize the
event recommendation algorithms (i.e., CB, CF, CB+CF, among other agenda of users attending to a congress, where the users have not
combinations) with the aim of analyzing the user satisfaction in social interactions among them. In consequence, it is not possible
the end, by performing an online user-centric based evaluation ex- to use in the event recommendation process the social interactions
periment. that exists among users. However, similarly to some of the exist-
More recently, it has been also proposed a collaborative rank- ing proposals in EBSNs, EventAware exploits contextual informa-
ing of future events [31]. In this case, the user study conducted tion and uses multiple sources of information for defining items
concerned to the specific application of event recommendation to and users’ profiles with tags. As part of our future work, we plan
scientific talks. The event recommendations were presented on a to include in EventAware an ephemeral social network3 [6,17] of
web-based environment, from which they collected the users’ pref- attendees to the congress.
erences. Similarly to us, they identify topics from the seminar an- As far as we know, our proposal is the first mobile tag-
nouncements but they do not model implicitly the users’ areas of based recommender proposed for events. Most of the previous ap-
interest (i.e., they elicited explicitly feedback from users) and do proaches use past events rated by the users in the past to decide
not use contextual information for recommendation generation. which are the best recommendations and few of them consider
Secondly, with the advent of Event-Based Social Networks (EB- contextual information. It is worth noting that we do not use past
SNs), event recommendation has recently garnered increased at- experience of the users in past events and the proposal lacks of a
tention. EBSNs are online social networks where users can create, social network. We only generate recommendations based on the
promote and share upcoming events of any kind with other users. similarity of the tags that describe the items to the areas of inter-
For instance, Meetup.com, one of the largest EBSNs available today. ests described in the user’s profile. Moreover, we take into account
Several studies on EBSNs have utilized content information for contextual information to improve the proposed recommendations.
event recommendation. Qiao et al. [38] proposed a bayesian ma- In addition, our approach implicitly elicits the user’s preferences
trix factorization approach and employ social regularization fac- (i.e., areas of interests) by using their LinkedIn account.
tors inspired by user interactions in an EBSN. Khrouf and Troncy We consider that currently the most similar approach to our
[18] proposed a hybrid event recommender for recommending work is the proposal of Kaminskas et al. [16]. Although the two ap-
music-related events that combines linked open data, social infor- proaches differ in the domain (i.e., they recommend music and
mation and content features. Another approach [40] focuses on a we recommend events), both take into account tags and contex-
collective Bayesian Poisson factorization to jointly model user re- tual information for generating recommendations. Mainly, some of
sponse to events, social relation, and content text.
In addition to the content modeling, some recent work found
that multiple data modalities and contextual information are very 3
An ephemeral social network is a social network temporarily created ad-hoc at
useful in event recommendation. For example, Lu et al. [27] pre- a specific location for a specific purpose and lasting for a short period of time.
 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134 123

Fig. 1. Conceptual architecture of Event Aware framework.

the differences are: (1) we use Linkedin or Wikipedia for automat- 3.1. EventAware conceptual architecture
ically extracting tags and they use human-taggers for the content
tagging process; (2) they evaluated their proposal in a web-based Fig. 1 illustrates the client-server architecture of the proposal,
environment and we focus on a mobile environment. As a result, which consists of two main components: the Event Aware Server
the initial purpose of the recommender in both cases has been the and the Event Aware Client.
use of tags and context for generating recommendations but the First, the Event Aware Server, which includes the items tag
final recommenders are completely different from each other and base (ITB), the users knowledge base (UKB), the Event Aware
the tested environment too. System for generating recommendations, and the initial profile
builder. The ITB stores the items to be recommended to the user.
The UKB stores personal information of the users as well as their
3. Description of the EventAware recommender preferences (i.e., they are also called in this paper areas of in-
terest). The Initial Profile Builder is used for modeling both the
This section describes the EventAware architecture and its mo- items with tags and the initial users’ preferences, as described in
bile interface, how to model both users’ profile and items, and the Section 3.3. The Event Aware System contains the context awareness
process for generating recommendations. layer to collect contextual information, the context-aware pre-filter,
Before proceeding it is worth highlighting one important point: and the tag-based filtering algorithm, which are described in depth
the proposal is general enough to be adapted to any event do- in Section 3.4.
main, however, in this paper, we have focused the deployed mo- Second, the Event Aware Client is responsible for gathering
bile application on personalizing the agenda of users attending to both contextual information and user’s information, and communi-
a congress. In particular, the items to be recommended are ses- cating with the Event Aware Server. The Event Aware Client supports
sions and exhibitors. Sessions include conferences, seminars, spon- the building of the initial user profile, tracks user’s location based
sored events, and other several different programs. Exhibitors are on GPS, and requests and renders the recommendations provided
companies who display their products and projects at the event. by the server.
124 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134

Fig. 2. Initial profile building process in the Event Aware recommender system.

3.2. Event Aware mobile interface items are later inserted into the final recommendations set. These
recommendations are sent to the Event Aware Client and are pre-
The conceptual architecture of the Event Aware described above sented to the user. With this first display of recommendations, the
has been deployed with an Event Aware Client based on a mobile sign in process is finished.
environment. In this section, we describe how the user interacts The mobile interface displays the information in two different
with the mobile application. concept pages (see Fig. 3a) that the user can navigate through using
Briefly, the basic scenario that a new user faces when interact- the swipe gesture. On the left side is the Event Aware page, which
ing is as follows. First, the user is asked to sign in with his LinkedIn includes static information about the event such as the user’s ba-
account in order to retrieve his areas of interest and to automat- sic information and the current day agenda. Note that this page
ically model his initial profile (see Fig. 2a). A user receives the in- displays a small set of recommended sessions that contains infor-
formation of his LinkedIn account and confirms it. Once the sign mation of the Session’s name, the time remaining to the beginning
in is complete, the user provides information about the days that of the session, and the set of tags that matched in the recommen-
he is willing to attend to the event (see Fig. 2b). Later, the system dation process. It is important to note that the user may also visu-
presents to the user a set of possible areas of interest, which are alize the full agenda as a calendar, see Fig. 4a. On the right side of
the user’s preferences represented by tags (see Fig. 2c). Finally, the Fig. 3a is the Inside Event page that presents dynamic recommen-
user evaluates this set by editing these areas of interest (i.e., mod- dations that change according to the user’s current context (i.e.,
ifying the rating proposed) or deleting them if he finds necessary. location and time). The Inside Event page is also shown in Fig. 3b
After the user confirms their areas of interests, the application re- with the complete scroll down. This page contains a Don’t miss
trieves the user’s current context (e.g., location and time). section that displays the most popular items. Concretely, the Don’t
With the initial building process finished, the contextual infor- miss section presents a picture illustrating the item’s category, the
mation along with the user’s profile are sent to the Event Aware category name, and the name of the item.
Server in order to generate a set of recommendations. First, the Furthermore, the user is able to see the set of recommended
context pre-filtering module (see Fig. 1) filters the recommended exhibitors and sessions grouped by Hall, as shown in Fig. 4b. By
items (e.g., exhibitors and sessions) by discarding the items that clicking on the picture the user is able to visualize the item’s de-
do not match the current user context. The filtered set of items tails, see Fig. 5. At the top of the item’s details screen, the mobile
are sent to the tag-based filter, which is the recommender algo- interface shows the item’s score (represented as stars) in relation
rithm that uses the filtered set as input, as described in Section 3.4. to the user profile. Moreover, it displays the actions that the user is
The result is a set of recommended items that contains both ex- able to perform. One of these actions is adding to favorites, which
hibitors and sessions that matches both user’s preferences and the will be later stored in the users knowledge base enabling the com-
user’s current context. Furthermore, the Event Aware also selects putation of popular items. By scrolling down the user also sees the
two popular items from the items tag base, one from each cat- tags that describe the items that matched with his areas of inter-
egory (i.e., exhibitors and sessions). The popularity is defined by est. This information is illustrated on the right side of Fig. 5. The
items with the highest “likes” count from the initial filtered set. Sessions details contains almost the same information as the Ex-
In addition, popular items are labeled with a flag in order to high- hibitors details, but it also displays the speakers that are involved
light them when presenting the recommendations to the user. Both in the Session and the Session’s start time and end time.
 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134 125

Fig. 3. Description of the initial interaction pages at the Event Aware interface.

3.3. Modeling items and user profiles the items’ properties. Initially, the available information only in-
cludes: (1) a small set of general tags that describe the main top-
EventAware includes a context-aware tag-based recommender ics of the event; (2) a set of items’ properties described in natural
that represents preferences of the users as well as the properties language in which tags are not included; and (3) the basic infor-
of the items with tags. In our proposal, the recommender does mation of each user described in natural language and extracted
not rely on past user experiences or a complete description of from his LinkedIn profile. Thus, it is necessary to model items and
126 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134

Fig. 4. Description of the different interaction pages at the Event Aware interface.

Fig. 5. Exhibitor details page.

user profiles with the same set of tags. These tags used for de- 3.3.1. Defining the representation of the bases used in the
scribing the items, the preferences of the users, and for generating recommendation process
recommendations are automatically inferred from several external Let ITB ={i1 , . . . , in } be the items tag base, depicted in Fig. 6,
sources (i.e., Wikipedia and LinkedIn). In order to describe in depth which contains the set of items for recommendation, where ij is
the automatic tagging process of both the items’ descriptions and the jth item. Each item ij is described as a tuple ij = < properties,
the user profiles, we need to define first the representation of the TD > where properties includes general information about the item,
tag base, items tag base and the users knowledge base. such as name, description, location (i.e., hall and stand), Timetables
(e.g., a session’s start time), and contact information. In particular,
 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134 127

Fig. 6. Description of the tag base with its related tags, items tag base, and users knowledge base.

Event Aware recommends different items: exhibitors and sessions.

5. Store related tags in the Tags Base 4. Generate related
Exhibitors are companies who display their products and projects tags list
Tags Base
at the event. Sessions are conferences, seminars, sponsored events, (TB) Related Tags
and other several different programs. Typically, a session involves (RT)
one or more speakers that are divided into two different cate- 1. Send each general tag
gories: key speakers and chairs. TD = {td1 , ...tdk } is the tag descrip-
tion set of the item where each tdi is described as a tuple tdi = 2. Retrieve Tag’s 3. Convert page
< name, score > , where name ∈ TB is the name of the tag and the Wikipedia page into plain text
score is computed using the related tags, as described below. TD is General Tag Wikipedia Tags Extractor
the structure that stores the relation between tags and items. It is Page Module (TEM)
important to notice that the tag description set, TD, is structured
Fig. 7. Extracting related tags.
and generated by the system, as shown in Section 3.3.3.
Finally, let UKB = {up1 , . . . , upu } be the users knowledge base,
depicted in Fig. 6, which stores a set of user profiles, where ups is tions that are of interest for the users. Albeit the set of tags was
the sth user profile. It is described as a tuple ups = < basicInfo, already stored in TB, the set of related tags for each tag was empty.
UP > , where basicInfo includes general information about the user, The content-tagging process consists of extracting automatically
such as full name, contact information, and job title. Let UP = for each general tag a set of related tags (RT), as illustrated in Fig. 7.
{ut1 , ...utw } be the user profile, where utm is described as a tuple This process is performed in several steps:
utm = < name, pr ior ity_ f actor > in which name ∈ TB is the name
of the area of interest and the priority factor is computed using • First step sends each general tag to identify its Wikipedia page.
the related tags. UP is the structure that stores the preferences • Second step automatically identifies the Wikipedia page for
of the user in terms of tags. We infer the user’s interests by re- each general tag and converts it into plain text. For example, for
trieving information from the Professional Network LinkedIn,4 see the tag “Data Analysis” the Wikipedia page is Data_Analysis.5 If
Section 3.3.4. a page is not found, the RT for this general tag will be empty.
The contextual information (i.e., location and time) of each user, • Third step uses the Tags Extractor Module (TEM) depicted in
is obtained in real-time whenever the user makes a request for Fig. 1 for extracting related tags along with their scores, by us-
recommendations. This information is not stored in the UKB due ing text plain as input. In this case, the input has been the
to its ephemeral nature. Wikipedia page that has been converted into plain text by re-
moving unnecessary information, such as HTML tags, URL’s, or
Wikipedia tags.
3.3.2. Content-tagging process • Fourth and fifth steps use the generated related tag list from
Since our recommender departs from an initial and small set of
TEM to store them into RT and it also links the related tags in
general tags (see TB in Fig. 6) that describe the main topics of the
the corresponding general tag in TB (see Fig. 6).
event, one of the main challenges in our recommender has been
to represent appropriately both the items with tags and the users’ Concretely, as shown in Fig. 8, TEM carries out the following
preferences with tags in order to be able to make recommenda- process:

4 5
www.linkedin.com. http://en.wikipedia.org/wiki/Data_analysis.
128 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134

From TEM, the content-tagging process receives the top n scor-

ing tags along with their scores, as depicted in stage fourth and
fifth in Fig. 7. These related tags and scores are then inserted into
RT and linked to TB.
Furthermore, the related tags score will be later used to com-
pute the score of the user’s areas of interests and the highest scor-
ing items will be recommended to the user as his initial profile.
When the process of establishing the relation between the tags
and related tags is finished, that is, TB is completely defined, the
system is ready to assign tags to items.
Fig. 8. Process of the Tags Extractor Module.
3.3.3. Assigning tags to items
Initially the available information in EventAware only includes a
First, TEM tokenizes the text [30]. It is a process in which ev- set of item’s properties described in natural language in which tags
ery character sequence is chopped up into pieces, called tokens, are not included. Each item stored in ITB, includes the field descrip-
perhaps at the same time throwing away certain characters, such tion (see Fig. 6). The process for assigning tags to items is devoted
as punctuation. Second, it removes stop words (i.e., words that are to complete the ITB with a set of tags that describes the items and
very commonly used in a given language). For example, in the con- which will be stored in TD, as shown in Fig. 6. Fig. 9 describes the
text of a search engine, if the search query is “how to develop process for automatically assigning tags to items.
information retrieval applications”, the search engine is going to First step uses the description field of the item to serve as the
find more pages that contain the term “how” and “to” than pages input text in TEM to retrieve the item’s set of related tags (IRT).
with information about “develop”, “information”, or “applications” Concretely, in the second step, TEM performs the same process
as the term “how” and “to” are commonly used in the English lan- described in Fig. 8: it receives as input text the item’s description,
guage. Disregarding these two common terms, the search engine tokenizes it, removes stop words, applies a Part-of-Speach Tagger,
focus on retrieving pages that are of interest to the purpose of the stems the words, computes the score of each one, and generates an
search. In our case, the stop words removal helps to mitigate the item’s set of related tags named irt that contains the top n scoring
noise inflicted by these words and keeps only the words that could tags for the provided item’s description.
be relevant to identify the text’s tags. Third and fourth steps consist of matching irt to the tags stored
Third, TEM applies a Part-Of-Speech Tagger in order to assign in the tags base (TB). In the fifth step, the Tags Matcher generates
part of speech to each word such as noun, verb, or adjective. The the item’s set of tags descriptors, (TD), that matches the item’s re-
POS Tagger implemented for this purpose used the Penn Treebank lated tags (irt) with the tags stored in the TB. Initially, we define
Project6 tags. Fourth, we only extracted the tags that correspond that TD contains all the tags described in TB but with a zero value
to nouns (i.e., noun singular (NN), noun plural (NNS), proper noun on its score. Then, the matching is performed by searching for each
singular (NNP), and proper noun plural (NNPS)). related tag irty ∈ irt whether exists an equal related tag in one of
Fifth, TEM focuses on stemming. For grammatical reasons, doc- the tags tx ∈ TB. If the match exists, the score of tdi ∈ TD is updated
uments (e.g., Wikipedia pages) use different forms of a word, such with the score of the related tag in tx . The matching is performed
as “organize”, “organizes”, and “organizing”. The goal of stemming by the following rule:
is to reduce inflectional forms and sometimes derivationally re- If tx contains irty we add the score of irty to the total score of tx
lated forms of a word to a common base form. For example, con- and update it on TD
sidering the words “mobile” and “mobility”, after applying stem- Note that TD contains the matched tags and their corresponding
ming they are both converted to the stem “mobile”. By applying score. We repeat this matching rule for all extracted related tags in
stemming to words, we are able to perform the term frequency irt. The scores are useful in order to identify which related tag is
computation more effectively. Next, as sixth step, TEM computes more relevant to each tag. For example, the “Internet of things” tag
the term frequency in order to identify the main tags of the pre- contains the related tag “mobil” with a score of 20 and the “Mobile
processed plain text. The scoring mechanism computes a score that Application development” tag also contains the related tag “mobil”
is the sum, over the set of terms identified as possible tags, of with a score of 100, in this case the related tag “mobil” is clearly
the match scores between each term and the document. Towards more relevant to the “Mobile Application development” tag than
this end, we assign to each term in a document a weight for that it is to the “Internet of things” tag. Finally, in the sixth step, we
term, that depends on the number of occurrences of the term in select the top n = 20 tags from TD and add them to ITB.
the document. The simplest approach is to assign the weight to be
equal to the number of occurrences of term t in document d. This
3.3.4. Building user’s initial profile
weighting scheme is referred to as term frequency and is denoted
One of the most difficult tasks in terms of usability and user ex-
tft,d .
perience is to construct an initial profile to the user. The difficulty
Finally, seventh step is devoted to select and return the top n
lies in retrieving the information about the user without hinder-
scoring tags along with their scores. In particular, we have opted
ing the user experience. We have opted for inferring implicitly the
for defining empirically n = 20. The scores are useful in order to
user’s profile from an external source of information (i.e., the Pro-
identify which related tag is more relevant to each tag. For exam-
fessional Network LinkedIn7 ) and we refine the user’s profile with
ple, the “Internet of things” tag contains the related tag “mobil”
the help of the user.
with a score of 20 and the “Mobile Application development” tag
In order to build the user’s initial profile, we have taken the
also contains the related tag “mobil” with a score of 100, in this
LinkedIn’s profile page of the user. This page stores a wide array
case the related tag “mobil” is clearly more relevant to the “Mobile
of information regarding the user professional, social, and personal
Application development” tag than it is to the “Internet of things”
tag.
7
LinkedIn (www.linkedin.com) is a business-oriented social network service
mainly used for professional networking and it has more than 259 million users
6
https://www.cis.upenn.edu/treebank/. in more than 200 countries and territories [32].
 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134 129

Tags
5. Generate item’s tags (TD) Matcher
Set of Item’s Tags
(TD) 3. Match irt
with tags in the TB
4. Retrieve all
tags from TB
6. Store TD in the ITB

Item’s
Related
Tags (irt)
1. Send 2. Generate item’s
Item’s description set of related tags (irt)
Items Tags Extractor Tags Base (TB)
Tags Base Module
(ITB) (TEM)
Fig. 9. Process of assigning tags to items.

Fig. 10. Process of building the user profile.

life. Concretely, we have selected several fields8 from this array of LinkedIn profile and add them to UP (see Fig. 6). Initially, we define
information and have introduced weights to each relevant field in- that UP contains all the tags described in TB but with a zero value
volved in the LinkedIn user profile modeling. The fields we have on its score. Next, we perform the process depicted in Fig. 10.
included in the user modeling and their corresponding relevancy The process for building the initial user profile resemblance in
-in parentheses- are the following: Interests (4), Skills (2), Summary some respects to the process for extracting tags from Wikipedia
(1), Positions (0.5), and Groups (0.1). For each type of information but are also different in others. Both processes use TEM and the
included in the model, we assigned priorities according to the field Tags Matcher. They differ in the source of information used to ob-
empirically observed relevancy. The relevancy takes into account tain the related tags and that, in this case, the user is able to eval-
the profile fields that better define the user’s preferences. uate and update the result of this process before storing it to their
The main goal of the process of building the initial user’s profile personal user’s profile.
is to infer the most relevant areas of interest of the user from his In first step, the process asks for the user’s authentication on
LinkedIn (see step 1 and 2 in Figs. 2a and b). Since security and pri-
vacy are one of the main concerns nowadays for online services,
8
Most of the profile fields are accessible using the LinkedIn API [24]. the user is asked for his allowance that a LinkedIn application is
130 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134

asking for his profile information. Next, as a second step, we trans- the priority factor of the area of interest. which was defined in the
form the LinkedIn profile information into plain text and pass it to number of stars assigned to it (see Section 3.3.4).
TEM, which generates the set of related tags, with its correspond- In Algorithm 1, the first two steps (lines 3 and 4) are devoted to
ing score, called prt. Third and fourth steps are devoted to match the contextual pre-filtering, by taking the full set of items ITB and
prt to the related tags stored in TB. The Tags Matcher performs the retrieving only those that match the user’s current context: loca-
same process described in Section 3.3.3. It generates in fifth step a tion and time. The first one only retrieves the items that matches
set of profile’s tags preferences (i.e., areas of interest of the user). the user’s current location and inserted them into ITB1 . The loca-
Each area of interest contains a priority factor that is the normal- tion is obtained using the mobile’s GPS sensor. Then, we also ap-
ized score to the range 1 to 5. The normalization helps to repre- ply an algorithm using geofencing in order to determine in which
sent later this information as stars at the user’s interface. Finally, hall is located the attendee. If he is outside the Geofence perime-
as sixth step, UP is presented to user (see step 3 in Fig. 2c), who ter of the event venue, we use the GPS information. The second
evaluates the areas of interest. Note at the interface that we rep- step takes ITB1 and filters out the items that match the user’s cur-
resent, as mentioned above, the score obtained in the matching rent time information obtained using the time of the mobile oper-
process by stars (from 1 to 5). Afterwards, to finish the process in ational system and the result is ITB2 . In summary, the pre-filtering
the seventh step, the evaluated set is added to UKB as the current steps reduce the set of possible recommendations according to the
user profile, UP. user’s current context.
It is important to note that the set of areas of interest gener- The third step, see lines 5 and 9–27 in Algorithm 1, consists of
ated is evaluated by the user before storing it on UKB and, in this generating the item recommendations, IR, based on the compati-
way, the user is able to delete them using the swipe gesture or bility of the areas of interests of the user (UP) and the score of
to change the scoring to his real preferences. Note that the tags each item in ITB2 . Formally, let RI = {ri1 ,…, riz } be the set of rec-
from TB have been used for defining both item’s properties and ommended items to the user. Each recommended item x is rep-
the user’s profile. resented by the tuple rix = < i, us > where i is the item, (an Ex-
The contextual information of each user, is obtained in real- hibitor or a Session), i ∈ ITB, and us is a computed score that re-
time whenever the user makes a request for recommendations and flects the compatibility of an item i for a user profile, UP. For each
it is not stored in the UKB due to it’s ephemeral nature. item I, in the ITB2 , first of all we verify in line 14 if its tag descrip-
tor set, ITD , contains one or more tags from the user profile, UP,
and store the matching tags in TM. If TM is not an empty set, we
3.4. Context-aware tag-based recommender compute the score of the matching tags of this item, using Eq. (1),
and we add this item as a new recommendation item to RI (see
Until now, we have been describing how the EventAware sys- lines 18–20).
tem automatically retrieves and updates with the same set of
tags both the items and the users’ profiles, which are the main |T
M|
Relevancy(T Mi , UP )
sources of information for the context-aware tag-based recom- i=1
mender. With all the information, context, items, and users’ pro- computeScore(UP, T M ) = , (1)
|UP|
files, the recommender algorithm generates the list of items that
is recommended to the user. where TM is the set of matching tags and Relevancy(TMi , UP) re-
Algorithm 1 depicts the process for generating recommenda- trieves the relevancy of the matched tag, TMi , at the user profile,
tions. The goal of the recommendation algorithm is to match the UP. That is, the priority factor of the area of interest in UP that co-
tags that represent the areas of interest of the user, defined in UP, incides with the matched tag. After computing the score of I, we
with the tags that describe the items TD. For each item that con- add the item and its score to RI (see lines 18–20). Once added all
tains one or more of the areas of interest of the user, we compute items that matched with the user preferences, the RI is sorted in
it’s score taking into account the number of tags that matched and decreasing order (see lines 23–25).
 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134 131

Table 1
Post test questionnaire.

ID Question Statement

Q1 The items recommended to me matched my interests

Q2 The items recommended to me took contextual factors into consideration
Q3 I found easy to tell the system about my preferences
Q4 Finding an item with the help of the recommender is easy
Q5 I feel supported to find what i like with the help of the recommender
Q6 I understood why the items were recommended to me
Q7 Overall, I am satisfied with the recommender
Q8 If a recommender such as this exists, I will use it to find items
Q9 I will use this recommender again
Q10 I will tell my friends about this recommender

Finally, as fourth step, we add the two most popular items,

which are not already included, to the set of recommended items
RI (see lines 6 and 28–40). As our recommendation process applies
several filters and, in consequence, we have several item knowl-
edge bases (ITB2 , ITB1 , and ITB), we select the first non-empty item
knowledge base that best satisfies the user context and the user’s
preferences. From the selected item knowledge base we extract the
two most popular items that have not been already included in RI,
see lines 32, 34, and 36. It is worth mentioning that the popu-
lar items are displayed separately from the other items in RI, for
this reason, they are not included in the sorting process. Once the
RI is complete, we send it to the mobile application (see Fig. 1).
Note that, in this way, we present to the user not only items that Fig. 11. Usability analysis of the context-aware tag-based mobile application inter-
matched the user’s preferences but also items which are “out of face.
the box” from the user’s perspective. The client application is re-
sponsible for displaying a subset of RI, with the maximum length
of 20 items per hall ordered by their score in descending. based on well known usability evaluation models [36], includ-
ing TAM [8] and SUMI [19]. The questionnaire was answered us-
4. Evaluating the usability of the mobile application ing a five-point Likert scale where 1 corresponds to strongly dis-
agree and 5 to strongly agree.
We evaluate the usability of EventAware with real users. Given
the high fidelity of our application, we used the summative usabil- After the test, we analyzed the posttest questionnaire to extract
ity evaluation method [3]. relevant data concerning usability. The next section describes this
evaluation analysis.
4.1. Setup and methodology
4.2. Analysis of usability
In our experiment, we recruited 15 participants, diverse in fea-
tures such as age, gender, computer skills, and experience in mo-
Figs. 11 and 12 depict the results obtained from the posttest
bile environments. The test was performed during a mobile tech-
questionnaire (shown in Table 1). Note that these results are re-
nology congress that took place at a conventions pavilion in the
lated to the subjective perception of users but are quantitative
city of Barcelona. The test was conducted by a moderator and an
data, which gives us valuable information about users’ perceptions
observer. The moderator welcomed the users and briefly explained
in terms of usefulness and usability of EventAware mobile applica-
test objectives. Users were requested to use the mobile applica-
tion. Overall, the quantitative results obtained are very satisfactory
tion to locate the events they are willing to attend. Each partici-
(see Fig. 11), as 99.3% of the responses were ranked with 3 or more
pant owned an Android device with Internet and Location services
points, 0.7% relied to a question with value 2, and 0% of responses
enabled. The test protocol consisted of four stages:
correspond to a minimal score (1 value).
1. Pretest interview: In this stage the moderator welcomed the Considering the context compatibility (i.e., question Q2),
user, briefly explained test objectives and asked about their pre- Fig. 11 shows that 86.7% of participants’ responses show that the
vious experience with mobile applications and recommender users perception is that the system takes into consideration con-
systems. textual factors and evaluated this aspect with 4 or more points and
2. Training: During this stage users were asked to create their ini- none of participants replied to this question with a minimal score
tial profile and then they were freely navigating on the mobile (i.e., 2 or 1 values). The details of question Q2 are in Fig. 12b, which
application. They were asked to locate a predefined event. shows that 13.3% of the participants ranked with 3 (Neither agree
3. Test: In this stage users performed, without guidance, a test or disagree) points, 60% ranked with 4 (Agree) points, and 26.7%
task that consists of using freely the mobile application. They ranked with 5 (Strongly agree) points. Moreover, the obtained re-
roam freely through the event venue in order to receive con- sult for Q3 is satisfying, too, as 14 participants ranked over 3 points
text aware recommendations for both exhibitors and sessions (i.e., 93.3% of participants) our initial profile builder, 1 participant
the days they are attending to the congress. During the task, respond with value 2, and none of them replied to this question
we recorded the test session. with value 1 (see Fig. 11). This result is positive considering that
4. Posttest questionnaire: After the test, users were asked to we build automatically the initial user profile with the information
fill out a web form that contains a satisfaction questionnaire stored at LinkedIn. In fact, as shown in Fig. 12c, 6.7% of participants
consisting of 10 questions (see Table 1). The questionnaire is ranked it with 2 (Disagree) points, 20.0% ranked with 3 (Neither
132 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134

Fig. 12. Detailed responses to the usability questionnaire of EventAwar.

agree or disagree) points, 46.7% ranked it with 4 (Agree) points, and ipants in Fig. 12d), and no one respond with 2 or 1 points. That is,
26.7% ranked with 5 (Strongly agree) points. 26.7% ranked Q4 with 5 (Strongly agree) points, 60% of participants
With regard to the easy of decision making in question Q4, ranked it with 4 (Agree) points, and 13.3% ranked it with 3 points
Fig. 11 shows that 86.7% of the participants positively evaluated (see Fig. 12d).
this aspect with 4 or more points. Moreover, Fig. 11 shows that the In this way, the result in the perceived usefulness (Q5) shows
remaining percentage corresponds to 3 points (i.e., 13.3% of partic- that 100% of participants perceive that the recommender supports
 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134 133

them to find what they like (i.e., all participants evaluate this ness of the EventAware. Moreover, 100% of participants also had
question with over 3 points, see Fig. 11). In particular, as shown a good perception (with 3 or more points) about the usefulness of
in Fig. 12e, 13.3% of participants ranked Q5 with 3 (Neither agree EventAware.
or disagree) points, 80% ranked it with 4 (Agree) points, and 6.7%
ranked it with 5 (Strongly agree) points. Acknowledgments
In addition, another very important aspect of the recommen-
dation process, is to build a certain amount of trust between the D. Contreras is supported by a doctoral fellowship “Becas Chile”.
user and the system. In this way, a 73.3% of participants replied to This work has been supported by projects: SGR-623-2014 and
the question Q6 with over 4 points, see Fig. 11. Thus denoting that TIN2015-71147-C2-2 from the Spanish Ministry of Science and In-
they mostly understand the items that have been recommended to novation.
them. Specifically, 26.7% of participants ranked Q6 with 3 (Neither
agree or disagree) points, 46.7% ranked it with 4 (Agree) points, and Supplementary material
26.7% ranked it with 5 (Strongly agree) points (see Fig. 12f).
Moreover, the results in Q7 indicate that the majority of users Supplementary material associated with this article can be
were satisfied with the system (i.e., 100% ranked Q7 with 3 or found, in the online version, at 10.1016/j.patrec.2017.07.003.
more points, see Fig. 11. Specifically, Fig. 12g shows that 73.3% of
participants ranked Q7 with (Agree) points and 26.7% ranked it References
with 5 (Strongly agree) points.
We were also very interested in users’ opinions regarding [1] G. Adomavicius, B. Mobasher, F. Ricci, A. Tuzhilin, Context-aware recommender
systems, AI Mag. 32 (2011) 67–80.
whether they will use in the future a recommender system as the [2] G. Adomavicius, A. Tuzhilin, Toward the next generation of recommender sys-
one tested; responses to Q8 depict that 100% of the participants tems: a survey of the state of the art and possible extensions, 2005.
evaluated it with 4 and 5 points (see Fig. 11). Concretely, Fig. 12h [3] D. Bowman, J. Gabbard, D. Hix, A survey of usability evaluation in virtual envi-
ronments : classification and comparison of methods, Presence: Teleoperators
shows that 66.7% of participants ranked Q8 with 4 (Agree) points
and Virtual Environonments. 11 (2002) 404–424.
and 33.3% ranked it with 5 (Strongly agree) points. [4] R. Burke, Hybrid recommender systems: survey and experiments, User Model.
It is also worth noting that in the case of Q9 all of partici- User-Adapted Interact. 12 (2002) 331–370.
[5] C.C. Chen, Y. Sun, Exploring acquaintances of social network site users for ef-
pants ranked this question with 3 or more points, which means
fective social event recommendations, Inf. Process. Lett. 116 (2016) 227–236.
that users have a good perception about the usefulness of the mo- [6] A. Chin, H. Wang, B. Xu, K. Zhang, H. Wang, L. Zhu, Connecting people in the
bile application (see Fig. 11). Moreover, Fig. 12i shows that 13.3% of workplace through ephemeral social networks, in: Privacy, Security, Risk and
participants ranked Q9 with 3 (Neither agree or disagree) points, Trust (PASSAT), IEEE Third Int. Conf. on Social Computing, 2011, pp. 527–530.
[7] C. Cornelis, X. Guo, J. Lu, G. Zhang, A fuzzy relational approach to event rec-
53.3% ranked it with 4 (Agree) points, and 33.3% ranked it with 5 ommendation, in: Proc. 2nd Indian Int. Conf. on Artificial Intelligence, 2005,
(Strongly agree) points. pp. 2231–2242.
Additionally, when users answer about their intention to tell [8] F.D. Davis, Perceived usefulness, perceived ease of use, and user accep, MIS Q.
13 (1989) 319.
their friends about this recommender (question Q10) only 3 par- [9] A.K. Dey, Understanding and using context, Pers. Ubiquitous Comput. 5 (2001)
ticipants ranked Q10 with 3 points, the remaining ones replied to 4–7.
this question with 4 or more points. As detailed in Fig. 12j, 20.0% [10] S. Dooms, T. De Pessemier, L. Martens, A user-centric evaluation of recom-
mender algorithms for an event recommendation system, in: Workshop on
of participants ranked Q10 with 3 (Neither agree or disagree) points, User-Centric Evaluation of Recommender Systems and Their Interfaces, 2011,
66.7% ranked it with 4 (Agree) points, and 13.3% ranked it with 5 pp. 67–73.
(Strongly agree) points. [11] R. Du, Z. Yu, T. Mei, Z. Wang, Z. Wang, B. Guo, Predicting activity attendance
in event-based social networks: content, context and social influence, in: The
Finally, with regard to the perceived effectiveness by users dur-
2014 ACM Conference on Ubiquitous Computing, UbiComp ’14, Seattle, WA,
ing the recommendation process, results of question Q1 show that USA, September 13–17, 2014, 2014, pp. 425–434.
100% of participants evaluated positively this aspect with three or [12] X. Guo, G. Zhang, E. Chew, S. Burdon, A hybrid recommendation approach for
one-and-only items, in: AI 2005: Advances in Artificial Intelligence, in: LNCS,
more points (see Fig. 11). In fact, participants have expressed that
volume 3809, Springer, 2005, pp. 457–466.
they have approved the recommended items, 6.7% of the testers [13] D. Jannach, M. Zanker, A. Felfernig, G. Friedrich, Recommender Systems: An
ranked Q1 with 3 (Neither agree or disagree) points in the Likert Introduction, 1st, Cambridge University Press, New York, NY, USA, 2010.
scale, 80% ranked it with 4 (Agree) points, and 13.3% ranked it with [14] Y. Jhamb, Y. Fang, A dual-perspective latent factor model for group-aware so-
cial event recommendation, Inf. Process. Manage. 53 (2017) 559–576.
5 (Strongly agree) points, as shown in Fig. 12a. [15] J. Jiang, C. Li, Analyzing social event participants for a single organizer, in: Proc.
of the Tenth Int. Conf. on Web and Social Media, 2016, pp. 599–602.
5. Conclusions [16] M. Kaminskas, F. Ricci, M. Schedl, Location-aware music recommendation us-
ing auto-tagging and hybrid matching, in: Proc. of the 7th ACM Conf. on Rec.
Systems, ACM, 2013, pp. 17–24.
In this article we have described in depth EventAware, a mo- [17] A. Kermarrec, E.L. Merrer, Offline social networks: stepping away from the
bile recommender system for events. Our proposal integrates a internet, in: Proc. of the Fifth Workshop on Social Network Systems, 2012,
pp. 14–15.
context-aware and a tag-based recommendation algorithm into [18] H. Khrouf, R. Troncy, Hybrid event recommendation using linked data and user
a mobile application for recommending events. To the best of diversity, in: 7th ACM Conf. on Recommender Systems, 2013, pp. 185–192.
our knowledge, this is the first mobile recommender system for [19] J. Kirakowski, M. Corbett, SUMI: the software usability measurement inventory,
Br. J. Educ. Technol. (1993) 10–12.
events. Specifically, we have described the conceptual architecture [20] R. Klamma, P. Cuong, Y. Cao, You never walk alone: Recommending academic
and the intuitive user interface with an attractive design that en- events based on social network analysis, in: Complex Sciences, in: Lecture
hances user experience. Moreover, EventAware initializes automat- Notes of the Institute for Computer Sciences, Social Informatics and Telecom-
munications Engineering, volume 4, Springer, 2009, pp. 657–670.
ically both the user’s profiles with minimal user interaction and
[21] J. Konstan, J. Riedl, Recommender systems: from algorithms to user experience,
the properties of the items and generates recommendations us- User Model. User-adapt Interact. 22 (2012) 101–123.
ing a context-aware tag-based recommender algorithm. The us- [22] Y. Koren, R. Bell, Advances in collaborative filtering, in: Recommender Systems
Handbook, Springer, 2011, pp. 145–186.
ability of this novel mobile application for recommending events
[23] D.H. Lee, Pittcult: Trust-based cultural event recommender, in: Proc. of the 2nd
has been evaluated by life users. Overall, the results obtained are Conf. on Recommender Systems, ACM, 2008, pp. 311–314.
very satisfactory, as 99.3% of the responses were ranked with 3 or [24] LinkedIn Corporation, L., Linkedin API documentation, 2015, (https://developer.
more points and 0% of responses correspond to a minimal score linkedin.com/docs).
[25] X. Liu, Q. He, Y. Tian, W. Lee, J. McPherson, J. Han, Event-based social net-
(1 value). Concretely, our results show that 100.0% of participants works: linking the online and offline social worlds, in: The 18th ACM SIGKDD
evaluated positively (i.e., with 3 or more points) the effective- Int. Conf. on Knowledge Discovery and Data Mining, 2012, pp. 1032–1040.
134 D. Horowitz et al. / Pattern Recognition Letters 105 (2018) 121–134

[26] P. Lops, M. Gemmis, G. Semeraro, Content-based recommender systems: State [34] T.D. Pessemier, S. Coppens, E. Mannens, S. Dooms, L. Martens, K. Geebelen,
of the art and trends, in: Recommender Systems Handbook, Springer, 2011, An event distribution platform for recommending cultural activities, in: Proc.
pp. 73–105. of the 7th Int. Conf. on Web Information Systems and Technologies, 2011,
[27] D. Lu, C.R. Voss, F. Tao, X. Ren, R. Guan, R. Korolov, T. Zhang, D. Wang, H. Li, pp. 231–236.
T. Cassidy, H. Ji, S. Chang, J. Han, W.A. Wallace, J.A. Hendler, M. Si, L.M. Kaplan, [35] T.D. Pessemier, J. Minnaert, K. Vanhecke, S. Dooms, L. Martens, Social recom-
Cross-media event extraction and recommendation, in: Proc. of the 2016 Con- mendations for events, in: Proc. of the Fifth ACM Workshop on Recommender
ference of the North American Chapter of the Association for Computational Systems and the Social Web co-located with the 7th ACM Conf. on Rec. Sys-
Linguistics: Demonstrations, 2016, pp. 72–76. tems, 2013.
[28] A.Q. Macedo, L.B. Marinho, Event recommendation in event-based social [36] P. Pu, L. Chen, A user - centric evaluation framework for recommender sys-
networks, in: Proc. of the 1st Int. Workshop on Social Personalization, tems, in: Proc. of the 5th Conf. on Recommender Systems, 2011, pp. 157–164.
CEUR-WS.org, 2014. [37] Z. Qiao, P. Zhang, Y. Cao, C. Zhou, L. Guo, B. Fang, Combining heterogenous
[29] A.Q. Macedo, L.B. Marinho, R.L. Santos, Context-aware event recommendation social and geographical information for event recommendation, in: Proceed-
in event-based social networks, in: Proc. of the 9th ACM Conf. on Recom- ings of the Twenty-Eighth AAAI Conference on Artificial Intelligence, 2014a,
mender Systems, ACM, 2015, pp. 123–130. pp. 145–151.
[30] C.D. Manning, P. Raghavan, H. Schütze, Introduction to Information Retrieval, [38] Z. Qiao, P. Zhang, C. Zhou, Y. Cao, L. Guo, Y. Zhang, Event recommendation in
Cambridge University Press, 2008. event-based social networks, in: Proceedings of the Twenty-Eighth AAAI Con-
[31] E. Minkov, B. Charrow, J. Ledlie, S. Teller, T. Jaakkola, Collaborative future event ference on Artificial Intelligence, 2014b, pp. 3130–3131.
recommendation, in: Proc. of the 19th Int. Conf. on Information and Knowl- [39] F. Ricci, L. Rokach, B. Shapira, P. Kantor (Eds.), Recommender Systems Hand-
edge Management, ACM, 2010, pp. 819–828. book, Springer US, Boston, MA, 2011.
[32] D. Nishar, 200 million members, Official LinkedIn Blog at http://blog.linkedin. [40] W. Zhang, J. Wang, A collective bayesian poisson factorization model for
com/2013/01/09/linkedin- 200- million/. cold-start local event recommendation, in: Proceedings of the 21th ACM
[33] U. Panniello, A. Tuzhilin, M. Gorgoglione, Comparing context-aware recom- SIGKDD International Conference on Knowledge Discovery and Data Mining,
mender systems in terms of accuracy and diversity, User Model. User-adapt. 2015, pp. 1455–1464.
Interact. 24 (2014) 35–65.