Recommender systems have been around for decades to help people nd the best matching item in a pre-de ned item set. Knowledge-based recommender systems are used to match users based on information that links the two, but they often focus on a single, speci c application, such as movies to watch or music to listen to. In this paper, we present our Interest-Based Recommender System (IBRS). This knowledge-based recommender system provides recommendations that are generic in three dimensions: IBRS is (1) domain-independent, (2) language-independent, and (3) independent of the used social medium. To match user interests with items, the rst are derived from the user's social media pro le, enriched with a deeper semantic embedding obtained from the generic knowledge base DBpedia. These interests are used to extract personalized recommendations from a tagged item set from any domain, in any language. We also present the results of a validation of IBRS by a test user group of 44 people using two item sets from separate domains: greeting cards and holiday homes.
H.4.2 [Information Systems Applications]: Types of Systems|Decision support
The aim of a recommender system (RS) is to help people
nd the items they are most interested in. A requirement
to provide personalized recommendations is that the RS has
knowledge of the person using it. In 2013, Facebook claimed
to have 1.11 billion active users [
Copyright remains with the authors and/or original copyright holders
alone currently have a total of 5.87 billion facebook-likes [
But what people express their preference for on social media,
cannot always directly be related to commonly used tags or
words in descriptions in an existing item set. These items
are often example instances of broader concepts. For
example: Cristiano Ronaldo has 103 million facebook-likes at the
time of writing, whereas Soccer (66 million) and Football
(46 million) have considerably fewer facebook-likes.1 Tag
sets or descriptions, on the other hand, are more likely to
contain these broader concepts, as for example is the case
in greeting cards, sports equipment, or campsites with
soccer elds. In fact, one of our validation item sets contains
tagged greeting cards with practically only generic terms
such as soccer/football. To bridge this generalization gap in
a domain- and language-independent way, we use the
multilingual, generic knowledge base DBpedia to automatically
detect broader concepts. We call these concepts the user's
interests. In this paper, we validate our hypothesis that
automated user interest detection can also be used to select
preferred items in an item set, independent of the item set
domain, language and used social medium. As a boundary
requirement to our solution, the cold-start problem, as for
example discussed by Bobadilla et al. [
This paper is further structured as follows: related work is discussed in Section 2, the motivation behind this research is discussed in Section 3, the IBRS technology is presented in Section 4, while the validation approach and results are laid out in Section 5, and Section 6 nally contains concluding remarks and hints at future work.
The creation of a RS that makes use of social media or
DBpedia is not a new ambition. Social media have especially
received much attention in the eld of content-based
recommender systems. Fijalkowski and Zatoka presented an
architecture of a recommender system for e-commerce based on
Facebook pro les [
The creation of a RS based on DBpedia has also received
quite some attention already, especially in the eld of
music [
What distinguishes our approach from other RS research,
is that we use both social media pro les and DBpedia data
to create a generic RS. Passant and Raimond, for
example, created a RS based on exported social media pro les
and DBpedia data in [
Our work is inspired by Shi et al.'s HeteRecom [
In this work, we aim to extract recommendations that are generic in three dimensions: the recommendation approach shall be independent of the item set domain, the item set language, and the used social medium. As a fourth criterium, it shall not su er from any of Bobadilla's three cold-start problem categories. Below, we discuss the motivation for all of these challenges:
As discussed in the previous section, currently most recommender systems based on knowledge bases and social media are focused on one speci c domain. Independence of the item set domain only allows us to reuse the solution and its future improvements for multiple applications.
Similar to domain-independence as a requirement for
reusability, a language-independent solution improves the RS's
potential to be used in multiple applications. A sub-requirement
of of language-independence is synonym-independence. As
Zanardi and Capra pointed out in [
From the rst form of genericity, domain-independence, follows another requirement. Several social media, such as Facebook, LinkedIn, Twitter, Instagram, and Pinterest, are widely used, and each of these has its own focus. When one decides to create a RS for job vacancies, LinkedIn may be a more logical social medium to base the recommendations on than any of the other, while a RS for touristic hotspots will most likely lead to another choice. Therefore, to create a RS based on social media content that is domain-independent, it shall also be independent of the underlying social medium.
The cold-start problem has been widely discussed in RS
literature. Bobadilla et al. categorized it into three
subcategories: the new item problem, the new user problem,
and the new community problem [
Overcoming all of these four challenges at the same time has motivated us to create IBRS: a domain-independent, language-independent, social medium-independent, knowledge-based RS.
The foundation of IBRS is the idea that people are more likely to be interested in items that have a not too distant relation with things we know they like. Although things people express a preference for on social media are typically in a di erent domain than our item set, they may still give hints towards a person's interests. In IBRS, we link the preferred items on social media to resources in the DBpedia Resource Description Framework (RDF) graph. We use this graph to explore related concepts, which are then matched with a known tag set, that is used to label the item set. As a nal step, we rank the item set based on the number of matched tags. This concept is illustrated, using the holiday home domain, in Figure 1. In this example, the user facebook-liked the Colosseum, pizza, and Francesco Totti. These facebook-likes are mapped onto DBpedia, and the DBpedia RDF graph is explored to detect the broader concepts Rome, Italy, and Stadio Olimpico. These items are mapped onto holiday home tags, to ultimately match the user with a speci c holiday home.
The remainder of this section is structured as follows: RDF graph exploration is discussed in Section 4.1. The data model of the IBRS abstraction layer is presented in Section 4.2. Section 4.3 presents a method for automated tag generation from descriptions. In Section 4.4 the ranking mechanism and Facebook-DBpedia mapping approach are presented. Section 4.5, nally, presents a short introduction of the IBRS prototype.
After matching a facebook-like with a DBpedia resource, we traverse the RDF graph in exactly two steps. Since RDF tuples have a subject, predicate and object, RDF graphs are directed. Therefore, there are four possible di erent direction combinations to travel from node A through node B to its second neighbor C.2 In Table 1, we show the top-10 of second neighbors when traversing the DBpedia graph starting from the Ei el Tower as node A, using all four possible direction combinations. DBpedia pages in italics also occur as tags in at least one of our two validation sets, which are discussed in detail in Section 5. The rst approach, A ! B ! C, leads to results describing France, in uential French people, and several other buildings in France. The second approach, A B ! C, has some overlap with the rst approach, but also contains several results unrelated to France, such as Los Angeles and the United States. The third approach, A B C, shows some remarkable buildings throughout Europe, but also very unrelated lists towards the bottom of the top-10. The fourth and nal approach, A ! B C, results in several famous French people, especially scientists. Other starting points show similar results: the third approach, A B C, shows promising results for single domain recommendations, whereas the rst approach shows the best results for broader concept detection. Since our aim is to match these second neighbors with a tag set, we use the rst approach, A ! B ! C.
To ensure IBRS genericity, an abstraction layer is used on top of the underlying data source, such as a product database. This abstraction layer can consist of physical tables, views, or a mix thereof, but we will refer to its items as tables from here on. The abstraction layer contains two entity tables: abstract items and tags, and one relationship table: abstract items tags, as depicted in Figure 2. The abstract items table contains the id and object type 2Depending on the directions of the relationships, and the existence of bi-directional relationships, node A may be equal to node C, as can also be seen in Table 1. of the items in the item set. The object type eld allows us to use one IBRS instance for the recommendation of multiple item sets.
The tags table contains the tag's id, name, and dbpedia resource id. The name eld can be used in the language of the item set tags. Since we have one item set that is tagged in Dutch, and one item set that is tagged in English, we added the name eng eld for English tags. The dbpedia resource id is cached in the database for better performance.
The abstract items tags table is a regular relation table containing the abstract item id and tag id. It also contains the abstract item type for improved join executions.
In case an item set is not tagged, but does contain
descriptive texts, tags can be extracted automatically. Natural
language processing algorithms can be used for this purpose,
such as the named entity extraction and disambiguation
approach by Habib et al. [
The IBRS ranking method consists of four steps: (1) retrieving preferred items from social media, (2) matching these items with DBpedia resources, (3) extracting abstracts from DBpedia, (4) ranking items based on matched tags. For performance reasons, several items are cached o ine.
To map social media items while remaining independent of the social medium, we must take into account that not all APIs are the same. Some social medium APIs allow developers to nd out what a user's friends prefer, while others limit the developer to information about the logged in user. Therefore, when using the Facebook Graph API, we limited ourselves to the name and category elements of each facebook-liked page.
Facebook-likes are mapped onto DBpedia resources through their name. Those facebook-pages that mapped onto ambiguous terms in DBpedia were ltered out. To create a more complete mapping, we used the category element to post x the name of those pages pages for which the category element was lled with \movie," \tv show," or \musician/band." In these cases, we also checked if a page exists with the additional su x \ (movie)," \ (TV series)," or \ (band)" respectively. This leads to the following SPARQL query: PREFIX dbpont: <http://dbpedia.org/ontology/> PREFIX dbpres: <http://dbpedia.org/resource/> # We use the prefixed versions here for readability SELECT ?uri ?label WHERE { # Find exact match with category suffix { ?uri dbpont:wikiPageID [].
FILTER(?uri = dbpres:The_Net_(movie)) } # Or exact match without category suffix UNION { ?uri dbpont:wikiPageID [].
FILTER(?uri = dbpres:The_Net) } # Or the label version UNION {?uri rdfs:label "The_Net"@en.} # Check if page has redirect UNION { dbpres:The_Net_(movie)
dbpont:wikiPageRedirects ?uri} UNION { dbpres:The_Net
dbpont:wikiPageRedirects ?uri} ?uri rdfs:label ?label. ?uri dbpont:wikiPageID ?wikiPageid.
FILTER (langMatches(lang(?label),"en")). # Filter out ambiguous terms FILTER NOT EXISTS { ?uri dbpont:wikiPageDisambiguates ?disambiguates } . # Filter out Wikipedia categories MINUS {?uri rdf:type skos:Concept} } LIMIT 1 Using this approach on a test set of 11,674 unique Facebook pages, obtained from the likes of 309 users, we were able to match 2,240 (19.2%) Facebook-pages with a DBpedia resource.
For all matched DBpedia resources, the abstracts are
retrieved from the SPARQL endpoint provided by DBpedia
[
?p2 ?o3 . # Second neighbor object has Wikipage ?o3 dbpont:wikiPageID ?o3id ; dbpont:abstract ?abstract ; rdfs:label ?label . # English is used as an example FILTER(langMatches(lang(?abstract), 'en')) .
FILTER(langMatches(lang(?label), 'en')) . # Second neighbor object must not be a category MINUS {?o3 rdf:type skos:Concept} } # `Only' the 1000 most important abstracts ORDER BY DESC(?count) LIMIT 1000
Each tag that (1) has a dbpedia resource id and (2) is
contained in at least one of the downloaded abstracts, is
marked as a matched tag. The item set is then ranked on the
basis of the number of matched tags. As a nal step, those
items that are too close to a higher ranked item, based on a
pre-de ned distance function, are removed from the ranking.
This last step is added to ensure diversity among the
recommended items. For the recommendation of geographic
objects, as for example in a geo-social RS like the one discussed
in [
For demonstration and validation purposes, we have created a prototype of IBRS, using the Cake PHP platform. The prototype can be used with either one's own Facebook prole, or by manually combining several DBpedia resources. It can be accessed through http://ibrs.ewi.utwente.nl.
To validate our ranking mechanism, as well as to determine the user perception of recommendations with explanations, we validated IBRS in a carefully designed user study with a test user group of 44 people. We used two product sets from di erent domains to demonstrate its domainindependence: greeting cards and holiday homes. The greeting card set contains Dutch tags, while the holiday homes did not contain any tags, but only descriptions. From the holiday homes, we used the English descriptions to extract (English) tags, to emphasize the potential to use IBRS in a language-independent way.
This section is further structured as follows: Section 5.1 describes the item set details. In Section 5.2, we present the approach taken to validate both our ranking mechanism and the recommendation explanation interface. Section 5.3 nally, discusses the validation results.
The rst item set contains greeting cards from the Dutch company Kaartje2Go (\Card2Go"). People search through a collection of cards electronically, which are distributed through regular (non-electronic) mail by Kaartje2Go in name of the customer. The customers can choose between sending greeting cards to one or multiple people at once. 75% of the purchases are of the latter type, for which the preferences of the sender are more relevant than those of the (potentially many) recipients. To facilitate the search, users can search for tags that have been entered manually by the Kaartje2Go employees. These tags, which are mostly in Dutch, are inconsistent in their completeness: for example some of the soccer cards are also tagged using the names of popular Dutch soccer teams, but not all of them. Less popular teams are never mentioned as tags. The top-10 of the translated greeting card tags can be found in Table 2.
The second item set contains holiday homes from the holiday home portal EuroCottage. This item set did not contain tags, but a description in one, two or three languages (Dutch, English and/or German). We followed the approach discussed in Section 4.3 to extract mentions of geographic places from the English holiday home descriptions. The top-10 of resulting tags can be found in Table 3. The advantage of extracting geographic places is that these also often have Wikipedia pages, which makes them suitable for the requirement that the tags need to have a dbpedia resource id. Many pages of the holiday home descriptions were in German, even though they were entered into the system by the holiday home owners as English descriptions. As a result thereof, many German words or phrases were extracted as geographical references, since the model was trained for English descriptions. However, the impact of these terms was practically zero, as these extracted tags were not matched with an English DBpedia resource.3 For the validation, the holiday homes were plotted on a map that was zoomed in on Europe, since most holiday homes in the set are located there. A relatively small subset of homes outside Europe could therefore not be displayed on the map, and were removed from the validation set, just as those without a coordinate pair. This coordinate pair was also used for the diversity function: all top-10 holiday homes had to be located at least 250 kilometers away from higher ranked items.
Our test users were requested to participate through Facebook, and used their own existing Facebook account for the recommendations. The test users were not aware of what they were testing, except for the information that they were testing a RS. Most test users do not have a background in computer science, and none of them were aware of how IBRS works. We asked our test users to validate our algorithm through a total of 30 questions, split up into three batches of 10. Once a question had been answered, users could not return to that question. The rst two batches were intended 3Even though the approach can be applied to any language contained in the knowledge base, the tags are still matched with knowledge base resources in the tag language. to validate our ranking mechanism, the third batch was intended to determine the user perception of recommendations with explanations, as compared to recommendations without explanations.
For the rst ten questions, users were asked to select their favorite greeting card from a greeting card pair using the interface of Figure 3. On one side of the screen, an item from the top-10 greeting cards according to IBRS was shown. On the other side, a card was shown that was not tagged with any of the matched tags. We called these recommendations Inverted IBRS. IBRS and Inverted IBRS were shown on the left or right side at random. For the second batch of ten questions, our test users were presented with the choice between two holiday homes, in a similar way. Again, IBRS and Inverted IBRS were shown on the left or right side at random. For each holiday home, its location was shown on a map, with the name of the holiday home and the rst 1000 characters of its description, as shown in Figure 4. The nal batch of ten questions required the test users to rate a recommendation. Each of the holiday homes was one of the top-10 holiday homes according to IBRS. At random, a user was assigned to the group of users who received recommendations with an explanation, as shown in Figure 5, or without an explanation.
IBRS (47%)
Inverted IBRS (31%)
In test runs of the validation process, we determined that in a set-wise comparison of the two systems, users tended to prefer the set that was spread out over the map, rather than one that contained clusters of recommendations. Since Inverted IBRS is extremely spread out, due to the fact that items had no relation with the users or each other, this caused a bias in the validation results. Therefore, we decided to only compare the results item-wise. Furthermore, we removed tags with a negative connotation, such as \die," or \death."
The rst two batches of the validation were used to determine the potential of the IBRS ranking mechanism. The results are shown in the pie charts of Figure 6. Figure 6a shows which system was the test user's preferred system, based on a majority vote between the two systems. Most users participated in the validation of both the recommendation of greeting cards and holiday homes. Each batch was counted separately. 47% of the users preferred IBRS, 22% voted equally often for both of the systems, and 31% of the users preferred Inverted IBRS. In the pie chart of Figure 6b, the results are shown when the results of holiday homes with the greeting cards are combined per user. Since this increases the number of votes per user, ties are less common. In this scenario, 55% of the users preferred the IBRS results, while 34% preferred Inverted IBRS.
The nal batch of the validation was used to determine the usefulness of the proposed recommendation explanation interface for holiday homes. The results of this batch are shown in the histograms of Figure 7. Contrary to our expectations, users preferred to receive recommendations without explanations. Using the 5-point Likert scale, the users who were presented with an interface with explanations rated (a) Split out between (b) Overall (batches comgreeting cards and holiday bined) homes (batches counted separately) Figure 6: Most frequent choices per user for the rst two batches of questions the recommendations with an average score of 3.3772, while users without recommendation explanation rated the recommendations with a 3.4709 on average. From this validation, we can conclude that people that receive recommendations based on tags that do not describe them well, are more likely to reject a recommendation with a \strongly disagree," when they see the rationale behind the recommendation. Despite satisfying results with respect to the system's potential to rank recommendations for users, we should not forget that many aspects play a role in the decision-making that cannot (yet) be detected from Facebook pro les. When choosing either a greeting card, a holiday home, or anything else, one will always look at domain-speci c item characteristics. For a greeting card, the user looks at colors, style, and the occasion the card is sent for. Similarly, for a holiday home, he looks at price, number of beds, the picture of the home, and the distance to the beach. For this reason, this approach shall only be used as a feature of a larger system. (a) With recommendation (b) Without recommendaexplanation; average rat- tion explanation; average ing: 3.3772. rating: 3.4709.
Figure 7: Recommendation ratings split out by recommendation presentation interface
In this paper, we presented the approach behind IBRS. We discussed the concept of mapping items marked as preferred or liked in social media onto a generic knowledge-base, and query expansion using DBpedia. We presented the technology, including the abstraction layer, tag generation approach, and ranking mechanism. We also presented the validation results of a test user group. As said, we recommend to use the proposed and validated approach from this paper as a feature of a larger recommender system. In a more complete system, one also needs to take domain-speci c features, as well as item popularity and other collaborative ltering features, into account. However, these features would contradict with our objective to create a generic RS that overcomes the cold-start problem, and therefore were not taken into account in this work.
Currently, IBRS uses all paths in the knowledge base graph as an indication for a useful recommendation. However, some paths in the graph actually form a reason not to recommend that item. For example, in the holiday home domain, a user is less likely to book a home in his own town, even though there may be many paths between him and that holiday home based on his local likes. Furthermore, some nodes are more useful than other for recommendation. DBpedia nodes like \European Central Time" have a lot of incoming paths, while it is unlikely that this actually forms an interest for this user. The next step for IBRS is to further improve the ranking mechanism by incorporating these characteristics and explore the possibility to automatically detect (negative) weights of paths.
This publication was supported by the Dutch national program COMMIT/. We also thank Mena Habib for his support in the tag generation process.