Diego Torres

Hala Skaf-Molli

Pascal Molli
email: pascal.molli@univ-nantes.fr

Alicia Díaz

Discovering Wikipedia Conventions using DBpedia Properties

Keywords: Semantic Web, Social Web, DBpedia, Wikipedia, Collaborative Recommender Systems

Wikipedia is a public and universal encyclopedia where contributors edit articles collaboratively. Wikipedia infoboxes and categories have been used by semantic technologies to create DBpedia, a knowledge base that semantically describes Wikipedia content and makes it publicly available on the Web. Semantic descriptions of DBpedia can be exploited not only for data retrieval, but also for identifying missing navigational paths in Wikipedia. Existing approaches have demonstrated that missing navigational paths are useful for the Wikipedia community, but their injection has to respect the Wikipedia convention. In this paper, we present a collaborative recommender system approach named BlueFinder, to enhance Wikipedia content with DBpedia properties. BlueFinder implements a supervised learning algorithm to predict the Wikipedia conventions used to represent similar connected pairs of articles; these predictions are used to recommend the best convention(s) to connect disconnected articles. We report on an exhaustive evaluation that shows three remarkable elements: (1) The evidence of a relevant information gap between DBpedia and Wikipedia; (2) Behavior and accuracy of the BlueFinder algorithm; and (3) Differences in Wikipedia conventions according to the specificity of the involved articles. Blue-Finder assists Wikipedia contributors to add missing relations between articles, and consequently, it improves Wikipedia content.

Introduction

Semantic Web technologies facilitate search and navigation on the Web, while they can be additionally used to extract data from the Social Web, e.g., DBpedia is built with data extracted from Wikipedia 3 infoboxes and categories. On the other hand, knowledge managed and encoded by Semantic Web technologies can enhance data published in the Social Web; for instance, semantic annotations DBpedia extracts information and stores it in a semantic representation. of data have been used to improve the Facebook graph search [START_REF] Lu | Desperately searching for travel offers? formulate better queries with some help from linked data[END_REF]. However, to the best of our knowledge, DBpedia [START_REF] Lehmann | DBpedia -a large-scale, multilingual knowledge base extracted from wikipedia[END_REF] has not been exploited to improve Wikipedia. In this paper, we propose BlueFinder an approach to enhance the content of Wikipedia with data inferred in DBpedia.

Although Wikipedia is collaboratively edited by large user communities, Wikipedia links are not semantically defined, e.g., no types are attached to these links. In the context of Semantic Web, Wikipedia links are translated into properties in DBpedia, and they are semantically described using RDF vocabularies, i.e., DBpedia encodes semantics that is not represented in Wikipedia and provides a more expressive representation of Wikipedia links. Therefore, DBpedia allows for retrieving information that is not available in Wikipedia [START_REF] Torres | Improving Wikipedia with DBpedia[END_REF]. To illustrate, Listing 1.2 presents a SPARQL [START_REF] Pérez | Semantics and complexity of sparql[END_REF] query named Q1 to retrieve people and their born place4 using db-prop:birthplace. Nevertheless, if Q1 is executed against the DBpedia endpoint 5 , the answer includes more people than those obtained by navigating from the Wikipedia place article. The evaluation of query Q1 retrieves 409,812 (place, person) pairs from the DBpedia endpoint. Meanwhile, if we navigate from places to people in Wikipedia, we only obtain 221,788 connected pairs. Two Wikipedia articles are connected if a regular Wikipedia user can navigate from one article to another through a navigational path. A navigational path with a length larger than five is unreachable by a regular user [START_REF] Landauer | Selection from alphabetic and numeric menu trees using a touch screen: breadth, depth, and width[END_REF][START_REF] Larson | Web page design: implications of memory, structure and scent for information retrieval[END_REF][START_REF] Otter | Lost in hyperspace: metrics and mental models[END_REF]; so those articles are considered as disconnected. Thus, only 54 % of places in Wikipedia have a navigational path to those people who were born there. In this paper, we aim at adding missing navigational paths in Wikipedia, and enhancing Wikipedia content. Thus, we contribute to complete the virtuous cycle of information flow between Wikipedia and DBpedia as illustrated in Figure 1b.

To measure how important the gap between Wikipedia and DBpedia, we choose the most popular classes of DBpedia defined in [START_REF] Lehmann | DBpedia -a large-scale, multilingual knowledge base extracted from wikipedia[END_REF], and the properties with the highest number of triples. We call these properties relevant properties. Listing 1.1 shows the SPARQL query that retrieves the relevant properties that relate instances of the classes db-o:Person and db-o:Place.

prefix db-o:< h t t p : / / dbpedia . o r g / o n t o l o g y/> s e l e c t ?p ( count ( d i s t i n c t ? o ) a s ? count ) where { ? s ?p ? o .

? s r d f : type db-o : Person . ? o r d f : type db-o : P l a c e } group by ?p Table 1: Results of 20 SPARQL queries for 20 properties and different classes. Some connected resources in DBpedia are disconnected in their corresponding Wikipedia articles, i.e., resources can be navigated in DBpedia while it is not possible to navigate equivalent resources in Wikipedia. We call this missing navigational paths information gap between Wikipedia and DBpedia. To illustrate the gap, we analyzed 1, 153, 652 connected pairs in DBpedia, and we found that 540, 434 pairs were disconnected in Wikipedia. Consequently, the value of the information gap between Wikipedia and DBpedia is important. Figure 2 details the number of information gap between Wikipedia and DBpedia for the properties detailed in Table 1. In order to evaluate the usefulness of adding these navigational paths, we carry out a social evaluation [START_REF] Torres | From dbpedia to wikipedia: Filling the gap by discovering wikipedia conventions[END_REF]. In this evaluation, we have manually added missing navigational paths for 211 disconnected pairs and after one month, we analyzed how many navigational pairs were accepted and how many were rejected by the Wikipedia community. As detailed in [START_REF] Torres | From dbpedia to wikipedia: Filling the gap by discovering wikipedia conventions[END_REF], 90% of new navigational paths were accepted and 10% were rejected. Although the rejected navigational paths had respected the semantics of the relation, they were more general than those used by the community. For example, the proposed navigational path to connect (Edinburgh, Charlie Aitken) 6 with the DBpedia property is birthplace of was Edinburgh / Category:Edinburgh / Category:People from Edinburgh / Charlie Aitken 7 . Wikipedia community argued that the category People from Edinburgh is too general and the more specific category Sportspeople from Edinburgh is a more appropriate link.

Gap Propor?on

Connected % Gap % Fig. 2: Gap proportion for the twenty DBpedia properties of Table 1 For adding missing navigational paths, it is mandatory to study how the Wikipedia articles are connected respecting the Wikipedia conventions 8 .

Wikipedia community has defined conventions that cover a wide diversity of topics: writing style, context of the articles and relations among articles.

Categories, List of pages, and Navigation templates are the conventions to design the navigation for one-to-many relations among Wikipedia articles. Additionally, the conventions could be defined by the community according to the specificity of the articles [START_REF] Torres | From dbpedia to wikipedia: Filling the gap by discovering wikipedia conventions[END_REF]. For example, the DBpedia property is birth-Place of that relates Boston9 and Tim Barsky10 is represented in Wikipedia by the navigational path Boston / Category:Boston / Category:Peoplefrom Boston / Tim Barsky. However, in case of Boston and Donna Summer11 , the same DBpedia property is represented by the navigational path Boston / Category:Boston / Category: People from Boston / Category:Musicians from Boston / Donna Summer. Donna Summer is a musician from Boston and most of the Boston's musicians belong to the category Category:Musicians from Boston. These differences in the convention used to express the birthplace of a person trigger the following new question: How to find the Wikipedia convention for a navigational path?

In this paper, we address the problem of finding Wikipedia convention(s) that represent a DBpedia property between pairs of Wikipedia articles. Then, it is possible to connect pairs of Wikipedia articles that used to be disconnected. Consequently, Wikipedia content will be improved. For example, according to DBpedia (and also Wikipedia), Boston is the birthplace of Robin Moore. However, a navigational path from Boston to Robin Moore does not exist in Wikipedia but does exist in DBpedia. Therefore, a user could ask Which is the convention to represent the "is birthPlace of " relation for (Boston, Robin Moore) in Wikipedia?

We introduce BlueFinder, a collaborative recommender system that recommends navigational paths that represent a DBpedia property in Wikipedia. Blue-Finder pays special attention to the specificity of the resource types in DBpedia. It learns from those similar pairs already connected by Wikipedia community and proposes a set of recommendations to connect a pair of disconnected articles. BlueFinder recommender system presented in this paper is an optimization of the previous version published in [START_REF] Torres | BlueFinder: Recommending Wikipedia Links Using DBpedia Properties[END_REF].

Summary of our contributions:

The paper is organized as follows. Section 2 presents related works in the field of discovering and recommending links. Section 2 describes basic definitions used in this work. Section 4 describes the problem statement. Section 5 presents the BlueFinder approach and the algorithm description. An exhaustive evaluation is described in Section 6. Finally, conclusions and future works are presented in Section 7.

Related Work

Want et al. [START_REF] Wang | Exploit semantic information for category annotation recommendation in wikipedia[END_REF] introduce a collaborative approach to recommend categories to Wikipedia Articles. The approach consists of a two-step model. The first step collects similar articles to the uncategorized one in terms of incoming and out coming links, headings and templates. The second step lies on ranking the categories obtained by the related articles and selecting the best ranked. BlueFinder uses categorization but in another context. Categorization is used to express properties of DBpedia. Less related to our approach but in line with combining recommender systems and DBpedia, MORE [START_REF] Mirizzi | Movie recommendation with dbpedia[END_REF] is a recommender system that uses DBpedia to recommend movies in a Facebook application. A Vector space model is used to compute semantic similarity. However, MORE uses DBpedia as a source data set to base the recommendations and not to improve Wikipedia. Panchenko et al. [START_REF] Panchenko | Extraction of semantic relations between concepts with knn algorithms on wikipedia[END_REF] propose to extract semantic relations between concepts in Wikipedia applying kNN algorithms called Serelex. Serelex receives a set of concepts and returns sets where articles are semantically related according to Wikipedia information and using Cosine and Gloss overlap distance functions. In addition to the lack of using DBpedia as semantic base, Serelex cannot describe the way that two concepts are related in Wikipedia according to a property. Singer et al. [START_REF] Singer | Computing semantic relatedness from human navigational paths: A case study on wikipedia[END_REF] compute semantic relatedness in Wikipedia by means of human navigational path. They analyze human navigation paths in order to detect semantic relatedness between Wikipedia articles. The main difference with Blue-Finder is the absence of DBpedia as a support to describe semantic relatedness between Wikipedia concepts, as is exploited in our work with the Semantic Pair Similarity Distance. Di Noia et al. [START_REF] Di Noia | Linked open data to support content-based recommender systems[END_REF] introduce a strategy to find similarity among RDF resources in the Linked Open Data. Di Noia et al. present a content-based recommender system approach based on the Web of Data. As in BlueFinder, the similarity between resources is computed by means of semantic relationships. However, in [START_REF] Di Noia | Linked open data to support content-based recommender systems[END_REF] it is mandatory to discover the semantic relation among the resources and then to analyze a potential similarity. In BlueFinder, we already know that the two resources in each pair are related by the same property and then we only have to compare the types of description. Finally, the Di Noia approach is applied in the Web of Data world, and BlueFinder we complement and augment the information of the Social Web with information from the Web of Data.

Nunes et al. [START_REF] Nunes | Combining a co-occurrence-based and a semantic measure for entity linking[END_REF] introduce a recommender system to discover semantic relationships among resources from the Social Web. The work presents an approach to measure the connectivity between resources in a particular data set based on semantic connectivity store and co-occurence-based measure. The first metric is based on graph relations among entities; the second one relies on an approximation of the number of existing Web pages that contain the same labels in their body. Although the approach of Nunes et. al. is closely related to BuleFinder, the main difference is the direction of the information flow. In Nunes et al work, the information of the Social Web is used to improve the Semantic Web and not in the opposite direction as in BlueFinder.

Other works [START_REF] Adafre | Discovering missing links in wikipedia[END_REF][START_REF] Sunercan | Wikipedia missing link discovery: A comparative study[END_REF] aim at fixing missing direct links in Wikipedia, while [START_REF] Hoffmann | Amplifying community content creation with mixed initiative information extraction[END_REF] proposes an approach to complete Wikipedia infobox links with information extracted from Wikipedia by using Kylin. Works in [START_REF] Adafre | Discovering missing links in wikipedia[END_REF][START_REF] Sunercan | Wikipedia missing link discovery: A comparative study[END_REF][START_REF] Hoffmann | Amplifying community content creation with mixed initiative information extraction[END_REF]

Preliminaries Definitions

DBpedia Knowledge Base: DBpedia knowledge base is a set of RDF triples built from data extracted from Wikipedia [START_REF] Lehmann | DBpedia -a large-scale, multilingual knowledge base extracted from wikipedia[END_REF]. This knowledge base has a set of general properties and a set of infobox-specific properties, if the corresponding Wikipedia article contains an infobox. Each resource in DBpedia has types definition (rdf:type) coming from DBpedia ontology and Yago [START_REF] Suchanek | Yago: a core of semantic knowledge[END_REF] ontology. The foaf:isPrimaryTopicOf property relates a DBpedia resource with its corresponding Wikipedia page. DBpedia provides a SPARQL endpoint to query DBpedia knowledge base. For example, the SPARQL query Q1 in Listing 1.2 retrieves from DBpedia the set of all pairs of Wikipedia pages (f rom, to) that are related by the DBpedia property birthplace. For each property in Table 1, we define a corresponding SPARQL query Q p that contains a triple pattern of the form: ?s db-p:p ?o where p is the property. We define Q p (D) as the result of the evaluation of Q p over D. In Listing 1.2, for the property db -p : birthplace, Q1 birthplace (D) is the result of evaluation of the query over DBpedia, i.e., the set of couples of Wikipedia pages that relates persons and their birthplace.

Wikipedia Mode:l Wikipedia can be described as a graph where nodes are the Wikipedia articles (regular articles and categories) and hyperlinks are the edges. For example, an extract of Wikipedia graph is represented at the top of Figure 3: boxes are the nodes and arrows are the edges.

Definition 1 (Wikipedia Graph). G = (W, E) where W is a set of nodes and E ⊆ W × W is a set of edges. Nodes are Wikipedia articles (wiki pages) and edges are links between articles. Given w 1 , w 2 ∈ W , (w 1 , w 2 ) ∈ E if and only if there is a link from w 1 to w 2 .

Definition 2 (Navigational Path). A navigational path

P (w 1 , w n ) between two Wikipedia articles is a sequence of pages w 1 / . . . /w n , s.t. ∀i w i ∈ W ∧ ∀i, j : 1 i < j n, w i = w j , ∀i : 1 i n -1 where (w i , w i+1
) ∈ E is a link between w i and w i+1 . w 1 and w n are called the source page and the target page respectively. The length of a navigational path is the number of articles in the sequence, length P (w 1 , w n ) = n. Definition 3 (Wikipedia Connected Pairs). Let Q p (D) denote the result of the execution of the query Q p against the dataset D. The set of pairs (f, t) in Wikipedia which are connected by a navigational path with length up to l, where

(f, t) ∈ Q p (D) is defined as : C p (l) = {(f, t) ∈ Q p (D) such that ∃P (f, t) and length(P (f, t)) <= l}.
A path query is a generalization of similar navigational paths. Usually, regular expressions are used for expressing path queries [START_REF] Alkhateeb | Extending sparql with regular expression patterns (for querying rdf)[END_REF]. Many works have been done on path queries in different domains [START_REF] Alkhateeb | Extending sparql with regular expression patterns (for querying rdf)[END_REF][START_REF] Abiteboul | Regular path queries with constraints[END_REF][START_REF] Arenas | Counting beyond a yottabyte, or how sparql 1.1 property paths will prevent adoption of the standard[END_REF]. We adapt the path query definition in [START_REF] Abiteboul | Regular path queries with constraints[END_REF][START_REF] Alkhateeb | Extending sparql with regular expression patterns (for querying rdf)[END_REF] to the context of Wikipedia. We use regular expression patterns [START_REF] Alkhateeb | Extending sparql with regular expression patterns (for querying rdf)[END_REF], i.e., patterns that include variables.

Definition 4 (Regular expression pattern [20]).

Let Σ be an alphabet, X be a set of variables, the set of regular expressions R(Σ, X) over Σ can inductively defined by: (1

) ∀a ∈ Σ, a ∈ R(Σ, X). (2) ∀x ∈ X, x ∈ R(Σ, X); (3) ∈ R(Σ, X). (4) If ∀A ∈ R(Σ, X) and ∀B ∈ R(Σ, X) then A.B, A * ∈ R(Σ, X); such that A.B

is the concatenation of A and B and

A * denotes the Kleene closure.

Definition 5 (Language defined by a regular expression pattern [START_REF] Alkhateeb | Extending sparql with regular expression patterns (for querying rdf)[END_REF]). Let Σ be an alphabet, X be a set of variables, and R, R ∈ R(Σ, X) be two regular expression patterns. L * (R) is the set of words of (Σ X) * defined by: (1)

L * ( ) = { }. (2) L * (a) = {a}. (3) L * (x) = Σ X. (4) L * (R.R ) = {w .w | w ∈ L * (R) and w ∈ L * (R )}. (5)L * (R + ) = {w 1 . . . w k | ∀i ∈ [1...k], w i ∈ L * (R). (6) L * (R * ) = { } L * (R+).
A path query is a generalization of similar navigational paths by regular expressions patterns. A path query is defined by: Definition 6 (Path Query).

A Wikipedia path query (in short path query) P Q ∈ R(Σ, X) is a regular expression pattern. A pair of nodes (x, y) of G covers (or satisfies) a path query P Q(x, y) over Σ and X if there exists a path P from x to y in G and a map µ from Σ X to term(G) such that Λ(P ) ∈ L * (µ(R)) where Λ(P ) = Λ(a 1 ) . . . Λ(a k ) over (Σ X) * is associated to the path P = (a 1 , ..., a k ) of G.

In the context of Wikipedia Σ = W . For the purpose of this work, we limit X to two variables X = {#f rom, #to}. For a pair of Wikipedia pages (x, y) then, Λ( #from ) = x, Λ(#to ) = y and Λ(w) = w , w ∈ W , in case w includes in its a literal occurrence of the symbol #from or #to they will replace by x or y respectively, otherwise w = w (for example, Λ(Category : #f rom) = Category : P aris for the pair (Paris, Pierre Curie). Given a Q p (D), C p (l) is the set of all pairs (f, t) ∈ Q p (D) that are connected in Wikipedia by a path with length up to l. We will use path queries and computes the coverage of path queries for a set of pairs of Wikipedia articles.

The grey box at the middle of Figure 3 shows the navigational paths and path queries that can be generated for (Paris, Pierre Curie) and (Rosario, Lionel Messi) Wikipedia pairs in the example. Notice both cases are covered by a same path query (#from / Category:#from / Category:People from #from / #to) instead of the fact that they have different navigational paths.

Definition 7 (Path Index). Given a C p (l), a Path Index (PI) is a bipartite graph (P Q, C p (l), I), it represents the coverage of path queries for a set of pairs of Wikipedia articles that are related by a DBpedia property p. PQ is an ordered set of path (descendent order by element degree),

I ⊆ P Q × C p (l) is the set of edges relating elements from PQ with elements from C p (l); (pq, v) ∈ I ⇔ pq ∈ P Q ∧ v ∈ C p (l) ∧ v covers pq.
The first path query in PQ is the general representation of the property p in Wikipedia.

Definition 8 (Rating). Given a Path Index P I = (P Q, C p (l), I) and a path query pq ∈ P Q the rating of the pq in the path index is defined by the degree of pq in the path index bipartite graph: rating(pq, P I) = |{e ∈ C p (l) : (pq, e) ∈ I}| Path Index are useful because they enable us to obtain the following information:

-Which is the most general path query? -Which path queries cover a connected pair of Wikipedia articles? -How many pairs are covered by a path query?

The Path Index for the examples of (Rosario, Lionel Messi) and (Paris, Pierre Curie) is shown at the bottom of Figure 3. The pink ellipses with the path queries are the PQ set, the yellow ellipses with the Wikipedia pairs are the C p (l) set, and the arrows in between is the set of edges I. Finally, the rating for #from / Category:#from / Category:People from #from / #to is 2, and the rating for #from / #to is 1.

The information disparity between DBpedia and Wikipedia is detected by comparing the difference between the set of connected pairs of resources in DBpedia and those corresponding pairs that are connected in Wikipedia.

Definition 9 (Wikipedia pair connection). Two Wikipedia articles (a, b) that are related by a DBpedia property with one-to-many cardinality are connected when at least one of the following conditions is true:

1. There is a navigational path from a to b through the category tree with length less or equal to five [START_REF] Landauer | Selection from alphabetic and numeric menu trees using a touch screen: breadth, depth, and width[END_REF][START_REF] Otter | Lost in hyperspace: metrics and mental models[END_REF]. 2. There is a direct link from a to b.

3. a has a direct link to a List of page that has a direct link to b.

For instance, Rosario, Santa Fe and Lionel Messi are connected according to the first condition since there is navigational path:Rosario, Santa Fe / Cat:Rosario, Santa Fe / Cat:People from Rosario, Santa Fe / Lionel Messi.

Rosario, Santa Fe / Lionel Messi are connected according to the second condition, and, finally, Al Pacino / List of awards and nominationsreceived by Al Pacino / Academy Award connects the pair elements (Al Pacino, Academy Award) following the third condition. We describe the problem of defining the best representation of missing links in Wikipedia as a collaborative recommender system problem. According to Adomavicioius and Tuzhilin [START_REF] Adomavicius | Towards the next generation of recommender systems: A survey of the state-of-the-art and possible extensions[END_REF], "collaborative recommender systems try to predict the utility of items for a particular user based on the items previously rated by other users". BlueFinder predicts links between Wikipedia articles based on links previously rated by the Wikipedia community. Thus, BlueFinder can be considered as a collaborative recommender system for enhancing content of Wikipedia. More formally, the utility function u(c, s) of item s for user c is estimated based on the utilities u(c j , s) assigned to item s by those users c j ∈ C who are "similar" to user c. In the context of Wikipedia, BlueFinder does not directly apply recommenders to suggest Wikipedia articles to users but to suggest links between articles. BlueFinder predicts the utility of path queries for a particular pair of Wikipedia articles based on those rated by the Wikipedia community. In other words, the pairs of articles (from,to) will play the role of users and the path queries will be the items. Then, the utility u(c, pq) of a path query pq for a pair c related by a semantic property p is estimated based on the utilities u(c j , pq) assigned to pair c by those pairs c j ∈ C p (l), u : Q p (D) × P Q → R, where R is a list of path queries sorted according to the rating (see Definition 8).

Given a property p in DBpedia, C p (l) and P Q path queries covered by the elements of C p (l). Then, for a given pair of Wikipedia articles (f rom, to), we have to recommend the path query that maximizes the utility function. The following use case illustrates this problem statement in a practical use.

Use Case 1 A user would like to know which is the best convention to represent the is birthplace of semantic relation for the pair of articles (Boston, Robin Moore) in Wikipedia. The expected result is a list of recommended navigational paths that could connect Boston and Robin Moore articles respecting Wikipedia conventions. Some possible answers could be the following navigational paths:

-Boston / * / Category: Writers from Boston / Robin Moore (High confidence)

-Boston / Robin Moore (Low confidence)

Algorithm 1 BlueFinder

Require: x : unconnected pair, maxR : maximum number of recommendations, Qp(D), k : number of neighbors, l:max path length Ensure: Recommendation path query set The first specifies a navigational path that starts in Boston article, then it could continue by several other articles but it has to finish in the category Writers from Boston and finally Robin Moore article. The second navigational path specifies the direct navigation from Boston to Robin Moore. Additionally, the first respects the Wikipedia convention with a higher level of confidence than the second one.

1: index = (P Q, Cp(l), I) ← W ikipediaIndex(Qp(D), l) 2: k neighbors ← kN N (x, Cp(l)) 3: knnP Q ← c i pq : (pq, ci) ∈ I, ci ∈ k neighbors 4: knnI ← c i (pq, ci) : (pq, ci) ∈ I, ci ∈ k neighbors 5: knnP I ← (knnP Q, k neighbors , knnI

BlueFinder

BlueFinder implements a four-steps pipeline process as shown in Figure 4. A preprocessing step DBpedia fetch configures the BlueFinder start-up information. It fetches from DBpedia SPARQL endpoint the set of pairs of Wikipedia articles Q p (D) that are related in DBpedia by a semantic property p. After having the Q p (D), BlueFinder algorithm is ready to start.

The BlueFinder Algorithm 1 receives five inputs: (1) the unconnected pair of Wikipedia articles x, (2) maximum number of recommendations maxR , (3) the Q p (D) set generated by DBpedia fetch step, (4) the number of neighbors k , and (5) the maximum length of a path l. BlueFinder algorithm starts by invoking the WikipediaIndex.

The WikipediaIndex Algorithm 2 builds a path index. It receives Q p (D) and computes the item set, user set and item ratings. The items are the path queries, and the users are the pairs of Wikipedia pages retrieved from DBpedia. In this case, for each pair of Wikipedia articles (f rom, to) included in a given Q p (D), the algorithm performs a depth-first search up to l starting from the f rom article and finishing in the to article in the Wikipedia graph (lines 1-4). For each reaching to article, it generalizes a path and builds the path index as a bipartite graph (lines 5-8). Finally, it returns the path index that is ready to be used in the next step of the BlueFinder algorithm 1. BlueFinder traverses Wikipedia graph starting from the f rom article and finishing in the to article in the Wikipedia graph until the maximum length of a path; consequently, a depth-first search is more appropriate than the breadth-first search for building path index.

Algorithm 2 WikipediaIndex

Require: Qp(D), l: path length Ensure: PI bipartite graph

1: index = (∅, ∅, ∅) 2: for all (f rom, to) ∈ Qp(D) do 3: allP aths ← ∅ , curL ← 0, curP ath ← ∅ 4:
GenerateAllP aths(f rom, to, l, curL, allP aths, curP ath)

5:
for all path ∈ allP aths do 6:

pathQuery ← BuildP athQuery(path, f rom, to)

7:
index ← InsertInIndex(index, pathQuery, (f rom, to))

8:
end for 9: end for 10: return index After indexing, BlueFinder performs the kNN step (line 2 in Algorithm 1). In this step, given a disconnected pair of articles in Wikipedia, BlueFinder identifies the k nearest connected pairs to the disconnected one.

Algorithm 3 GenerateAllPaths

Require: f rom, to : Wikipedia article, l, curL : integer, allP aths : setOf P aths, curP ath : path Ensure: All paths that start in f rom and end in to in Wikipedia Graph with length up to l. The results only include paths through the category tree, the use of Listof pages or direct links. The kNN algorithm uses a similarity measure function to select the nearest neighbors. We define the Semantic Pair Similarity Distance (SPSD) function to measure the similarity between pairs of article. SPSD is based on the well-known Jaccard distance [START_REF] Jaccard | Nouvelles recherches sur la distribution florale[END_REF], it measures the degree of overlapping in the DBpedia types that describe a pair of Wikipedia articles. The range of the SPSD is from 0 (identical pairs) to 1 (totally disjoint pairs). The Semantic Pair Similarity Distance function is defined as: Definition 10 (Semantic Pair Similarity Distance (SPSD)). Given two pairs of pages c 1 = (a 1 , b 1 ) and c 2 = (a 2 , b 2 ). Let t a1 , t b1 , t a2 , t b2 data types in DBpedia for a 1 , b 1 , a 2 and b 2 respectively. Data types are defined as:

t a1 ={t : < a 1 rdf:type t > ∈ DBpedia}, t b1 ={t : < b 1 rdf:type t > ∈ DBpedia}, t a2 ={t : < a 2 rdf:type t > ∈ DBpedia}, t b2 ={t : < b 2 rdf:type t > ∈ DBpedia}. SP SD(c 1 , c 2 ) = J(ta 1 ,ta 2 )+J(t b 1 ,t b 2 ) 2
where J is Jaccard distance between c 1 and c 2 .

J(c 1 , c 2 ) = |c1∪c2|-|c1∩c2| |c1∪c2| .
To illustrate, we consider two pairs of Wikipedia pages c1 = (P aris, P ierreCurie) and c2 = (P aris, Larusso). The data types are:

t paris = {EuropeanCaptialsOf Culture, P opulatedP lace}.

t P ierreCurie = {Scientist, F renchCheimists, P eopleF romP aris}.

t Larusso = {Artist, P eopleF romP aris}.

SP SD(c 1 , c 2 ) = J(tparis,tparis)+J(t P ierreCurie ,t Larusso Having the kN N step computed, the Path Queries Analysis step starts. It obtains the path queries that connect the k neighbors in a smaller path index than the original (from line 3 to 5 in Algorithm 1). Indeed, having a P I = (P Q, C p (l), I); the value for an unknown rated r c,s for unconnected pair in Wikipedia c and a path query s ∈ C p (l), can be computed as: r c,s = degree(s, P I ) + f eatured(pq, P I ) where P I = (P Q, C p (l) , I) and C p (l) = KN N (c, C p (l)) and f eatured(pq, P I ) = β if degree(pq, P I ) = |C p (l) |, otherwise f eatured(pq, P I ) = 0. β is a scalar used to promote those path queries that are a convention shared for all the k neighbors12 and we call featured predictions. BlueFinder has a high level of confidence in featured predictions.

The generated path index contains the path queries that will be recommended and its ratings. Before the recommendations are returned, in the step Clustering and Recommendation in Figure 4, BlueFinder cleans regular-user-unreachablepaths (e.g., paths that include administrative categories) by means of the noise-Filter (Algorithm 4) and similar path queries are grouped by StarGeneralization algorithm (Algorithm 5). Finally, BlueFinder returns the maxRecom best ranked path queries.

The N oiseF ilter Algorithm 4 deletes all the paths queries that are not accessible by a Wikipedia user. Wikipedia includes several administrative categories which are used by administrators. In order to recommend path queries that can be utilized by regular users, N oiseF ilter deletes those categories whose names begin with "Articles ", "All Wikipedia ", etc, such as Cat:Articles to bemerged.

Algorithm 4 NoiseFilter

Require: P I = (P Q, C, I): Path index Ensure: Set of regular user navigable path queries. noise = {"Articles ", "All W ikipedia ", "W ikipedia ", "N on f ree", "All pages ", "All non"} for all pq = (p1, .., pn) ∈ P Q; do if pi contains any c ∈ noise;

1 ≤ i ≤ n then P Q ← P Q -{pq} end if end for return P Q
BlueFinder filters path queries into star path queries in order to reduce data sparsity.

Definition 12. A star path query P Q * (f, t) is a group of similar path queries that meet the following rules: (1) P Q * (f, t) starts with #from and ends with #to. (2) The * element can only be placed between #from and #to variables and * represents any path query. (3) The * cannot be the penultimate element in the path query because it has to make explicit the last part of the path in order to make the connection with the #to page. Example 1. P Q * (f, t) =#from/*/Cat:People from #from/ #to is a star path query. P Q * (f, t) =#from/*/#to is not a star path query.

The StarGeneralization Algorithm 5 groups path queries into a star path query, if possible.

Solving the Use Case 1

We start by fetching from Wikipedia all the pairs of Wikipedia articles with the form (Place, Person) that are related by the semantic relation is birthplace of. The SPARQL query evaluated in the DBpedia endpoint is Q1 (Listing 1.2) and the result is the Q p (D) set. Later, we initialize the BlueFinder algorithm with the following parameters: (Boston, Robin Moore) as the unconnected pair x, the limit of recommendation with maxR = 3, in order to simplify the example only 2 neighbors (k = 2), and the maximum length of pairs with 5. In Section 6 we evaluate the behavior of BlueFinder with a combination of several values of k and maxR.

The Wikipedia Index step generates a similar but larger index than the one exemplified in Figure 3. This index includes 409,812 connected pairs (C p (l)), 65,262 path queries (P Q) and 648,631 edges (I). With the index, the next step selects the 2 connected pairs of articles that are most similar to (Boston, Robin Moore). The SPSD detects (Boston, Ursula Parrot) and (Boston, Tom Kratman) as the most similar pairs because both of them are sharing most of the DBpedia types with (Boston, Robin Moore). For example all of them are writers from Boston. After that, BlueFinder only analyzes the path queries that cover the k neighbors in a smaller index as shown in Figure 5 (a). Those similar path queries are generalized into star path queries in the Clustering and Recommendation step. The generalization generates the index shown in Figure 5 (b).

Finally, the path query #from / .../ Category: Writers from #from / #to will be a featured recommendation because it covers all the neighbors. The other path query covers only one. Then, it retrieves the following recommendations customized for Boston and Robin Moore.

-Boston / . . . / Category: Writers from Boston / Robin Moore (Featured Recommendation -High confidence) -Boston / Robin Moore (Low confidence) With this recommendations, the user publishes in Wikipedia a navigational path that starts in Boston article, and has to finish in the category Writers from Boston. For this case, the user only has to add the article Robin Moore to the category Writers from Boston.

Evaluation

In this section we analyze the behavior of our approach by means of measuring the prediction the accuracy of BlueFinder predictions over the 20 properties shown in Table 1. The evaluation is conducted to answer the following questions:

1. What is the best combination of k and maxRecom values to observe the best accuracy from BlueFinder? 2. Does BlueFinder retrieve path queries that can fix missing relations in Wikipedia? 3. Does the confidence level provided by BlueFinder correlate with the accuracy of the predictions? 4. Does the Wikipedia Community use different conventions to represent a DBpedia property?

In this section we describe the method of the evaluation, the evaluation metrics, and then the data sets used in the experimentation are presented. Finally, the results and discussions are introduced.

Algorithm 5 StarGeneralization

Require: P Q: set of path queries, P I: Path index Ensure: P Q * : set of star path queries P Q * ← ∅ for all pq = (p1, .., pn-1, pn) ∈ P Q; do if pn-1 starts with "Cat:" then P Q * ← P Q * {(p1, * , pn-1, pn)} else P Q * ← P Q * {pq} end if end for return P Q *

Method

In order to answer the questions described in the previous section, an offline evaluation was designed; user interaction is not considered in the study. The central idea of this evaluation is based on disconnecting connected pairs of articles in Wikipedia and then observing whether BlueFinder is able to recreate them. The important fact here is that BlueFinder has to recreate the Wikipedia community conventions that were defined to connect the pairs and not only to discover the disconnection. This approach is based on the assumption that all connected pairs in Wikipedia follow Wikipedian conventions. Figure 6 summarizes the idea of the evaluation method. For the purpose of this evaluation all the path queries A sample of 10% of the connected pairs was taken for the evaluation. They are randomly selected and kept in a set called N. For instance, for prop 1 in Table 1, 188,324 pairs are connected in Wikipedia (i.e. 409,812 -221,788), so 18,832 randomly selected of those pairs will be in the set N. After that, for each connected pair (w 1 , w 2 ) in N the evaluation repeats the following steps:

1. All paths currently connecting (w 1 , w 2 ) in Wikipedia are stored in the µ relevant set, and immediately all them are eliminated from Wikipedia to "disconnect" (w 1 , w 2 ). 2. BlueFinder is executed to predict the paths that could connect (w 1 , w 2 ). The resulting predictions are kept in µ predicted . 3. The µ predicted set is compared with µ relevant set in order to compute the metrics detailed below such as precision, recall and F1. 4. Finally, Wikipedia is restored up to the state before the pair disconnection.

This means that the (w 1 , w 2 ) pair is reconnected by means of µ relevant .

In this evaluation, BlueFinder behavior is evaluated in each property mentioned in Table 1, and then aggregates the values of all the metrics to have a general point of view. For example, the evaluation measures the precision metric for prop 1 , then for prop 2 and then it continues with the rest of metrics and properties. After all the metrics and properties are computed, the mean of all metric values is calculated.

In order to have an analysis of the best combination of the number of neighbors and the number of the BlueFinder recommendations, the BlueFinder execution is configured with many combinations of the parameter k and maxRecom for each disconnected pair. The values for k are from 1 to 10, and the values for maxRecom are 1, 3, 5 and unlimited. The limit of path queries l was fixed in 5 according to the analysis presented previously.

Evaluation metrics

We measured the accuracy of BlueFinder predictions based on the standard metrics of Precision (P), Recall (R), F-measure(F 1 ) and hit-rate.

Precision relates the number of correct path queries that are predicted by BlueFinder to the total of recommended path queries.

P = |µ relevant µ predicted | |µ predicted | (1)
where µ predicted is the set of predicted path queries and µ relevant is the set of expected path queries.

Recall computes the ratio of expected path queries to the total of recommended path queries.

R = |µ relevant µ predicted | |µ relevant | (2)
F 1 score is the combination of precision and recall.

F 1 = 2 × P × R P + R (3)
We also use the hit-rate recommendation accuracy [START_REF] Deshpande | Item-based top-n recommendation algorithms[END_REF][START_REF] O'sullivan | Improving the quality of the personalized electronic program guide[END_REF] that measures the number of cases where BlueFinder recommends at least one correct path query.

hit -rate = 1 if |µ relevant µ predicted | > 0 0 otherwise (4)
The previous measures are extended by studying the distribution of path queries predicted by BlueFinder. In this work, we measure the statistical dispersion of each path query i according to the proportion p(i) of a pair coverage using Gini index.

The Gini index [START_REF] Fleder | Recommender systems and their impact on sales diversity[END_REF] measures the distribution of recommended path queries. A value close to 0.0 indicates that all path queries are equally recommended while a value close to 1.0 represents that a particular path query is recommended always.

GI = 1 n -1 n j=1 (2j -n -1)p(i j ) (5)
where i 1 , ..., i n is the list of path queries ordered according to increasing p(i).

Finally, we combine the previous metrics to analyze the confidence of the predictions. A high level of confidence in a prediction means that the system trusts its prediction while a low confidence means the opposite [START_REF] Shani | Evaluating recommendation systems[END_REF]. BlueFinder determines confidence in two levels: featured predictions, and the position of each prediction in the recommendation set. In order to evaluate the confidence, we will compare the confidence with the hit-rate of each prediction.

Limitations In statistical terms, the µ relevant set is used as the gold standard for each pair (w 1 , w 2 ) in N . However, µ relevant could contain paths that are not related to a property in Table 1, or even a potentially correct prediction could be absent in the µ relevant set. For example, the µ relevant set for the pair (London , Richard Blanshard) with the property deathPlace was #from / * / Cat:People from #from / #to and the first two predictions in the prediction set were #from / * / Cat:People from #from / #to and #from / * / Cat:Death in #from / #to. The second prediction could be correct but, as it is not included in µ relevant , the evaluation rejects it as a correct one. Taking into account these considerations, the µ relevant set is an estimation of the actual path queries and in consequence the BlueFinder is evaluated in the context of the worst case.

Datasets We evaluate BlueFinder with the twenty semantic properties detailed in Table 1. For each property denoted by prop i , a SPARQL query was evaluated on the DBpedia SPARQL endpoint. The SPARQL query for each property follows the template showed in Listing 1.3 and the values of DBpediaSeman-ticProperty, fromType and toType are replaced in each property scenario for the specific values of the first, second and third column respectively that are detailed in Table 1. For instance, the SPARQL query in Listing 1.2 corresponds to prop 1 . The number of the Wikipedia connected pairs of each property is the difference between the numbers of the DBpedia connected pairs minus the number of the Wikipedia disconnected pairs (columns fourth and fifth of Table 1). The evaluation was run with a local copy of the English Wikipedia and DBpedia download in July 2013 and they were stored in a MySQL database.

prefix db-owl :< h t t p : / / dbpedia . o r g / o n t o l o g y/> prefix db-p:< h t t p : / / dbpedia . o r g / p r o p e r t y/> prefix f o a f :< h t t p : / / xmlns . com/ f o a f /0.1/ > s e l e c t ? f r ? t o where { ? db from a <fromType> . Evaluation results are described and discussed in the next section. The complete values of all the metrics values with the different values for k and maxRecom of this evaluation are in https://sites.google.com/site/bfrecommender/ publications/.

Results and discussion

We start by explaining the information gap presented in Table 1, then we report results for each evaluation metric.

Gap analysis

The last column in the in the Table 1 presents the gap of missing information in Wikipedia. By analyze the ratio of the gap, shown in Figure 2, we noticed that 9 out of 20 properties have more than 50 % of missing information. In addition, the number of disconnected pairs of the properties prop 1 (birthplace), prop 2 (deathplace), and prop 13 (recordlabel) shown in the Table 1, is equivalent to more than the 50 % of all disconnected pairs of other properties.

General for all scenarios

The smallest gap was in prop 20 (notableWork) and prop 12 (previousWork) with only 5 %. In both cases, this is because the links represent basic information of the connected articles and they are expressed as direct links (#from / #to) between the articles.

Accuracy To assess the best behavior of BlueFinder, we analyze the values of accuracy metrics for the 20 properties from a general perspective. Figure 7 shows four line-charts with the mean values of precision, recall, F 1 and hit-rate obtained for each property. Each chart describes the relation between maxRecom and k values for each metric.

BlueFinder is able to find, on average, between 75 % and 82 % of the relevant paths, and according to the hit-rate values it is able to fix around 88 % of the cases for k greater than 4 and maxRecom = 3, 5 or unlimited. However, the limitations is that the precision values decrease according to the variation of the k values and the number of recommendations.

To detect the best correlation between precision and recall we use the F1 metric. According to the Figure 7, all the maxRecom curves converge at k=5 with value 0.65. Therefore, maxRecom = 5 and k = 5 determine the best accuracy for BlueFinder. The number of correct path queries tips the scales in favor of recall and hit-rate rather than precision. This assumption is based on the fact that the recommendations are presented to the users in descending confidence order, and consequently, the users have extra information to determine the accuracy of the recommendation. Finally, the unlimited maxRecom was dismissed because it had similar recall than maxRecom = 5 but lower precision. Precision As presented in Figure 8 most of the precision curves decrease, due to BlueFinder introduced non-expected path queries in µ predicted set. This is because of the size of maxRecom has increased but also because the distant neighbors insert noisy paths. Nevertheless, the 70 % of the properties had precision higher than 0.5 at k=5 and maxRecom=5. This evidences that in general terms the precision of BlueFinder was considerably good taking into account that, as we have mentioned, the predictions are presented in confidence order bringing to the users better information (more details in Section 6.2). Properties prop 1 : birthplace(• line in charts), prop 2 : deathplace (line with ×), and prop 15 : country (line with ) have low precision less than 0.44 for any maxRecom value. This is because they have a high number of disconnected pairs and shows up that BlueFinder, as many recommender systems, is sensitive to the sparsity of data. On the other hand, property prop 12 : previousW ork (line with +) had a high precision: 0.93 with maxRecom = 1 and k = 5, but it sharply decreased when the maxRecom increased (0.44 with maxRecom = 3, 0.31 with maxRecom = 5 and 0.23 with maxRecom = unlimited). This is because although BlueFinder was able to predict the correct path query for this property, the other path queries that are included in the prediction set are not correct.

Recall and F1 As depicted in Figure 9, the recall of seventeen properties is greater than 0.7, and the recall of eleven properties is greater than 0.8; all of Hit-rate As depicted in Figure 11, 80 % of the properties (16 out of 20) have a hit-rate greater than than 0.84, and only two properties have values lower than 0.6. The properties with the lowest hit-rate are prop 15 and prop 2 ; both confirmed the same tendency that appeared in the previous accuracy metric. Although the hit-rate values are low, according to its high level of information gap, the average of hit-rate for the property prop 8 is greater than 75 %. These values are promising since 98 % of properties pairs were disconnected in Wikipedia.

The accuracy values demonstrated that BlueFinder retrieves good recommendations. The hit-rate curves confirmed the best combination of k and maxRecom values by setting k = 5 and maxRecom = 5. The BlueFinder predictions are sorted in confidence descendent order; consequently, first ranked predictions may have a better hit-rate than the following ones. In order to answer the third question of the evaluation Does the confidence level provided by BlueFinder correlate with the accuracy of the predictions? the hit-rate of BlueFinder featured predictions for the twenty semantic properties is shown in Table 2. As we can see, featured predictions made by BlueFinder are chiefly prominent: the lowest ratio was 0.84 for property prop 1 and the highest ratio was 1 for properties prop 6 and prop 15 . The mean of all the hit-rate values was nearly 0.95 and the geometric mean was similar ( 0.95). This means that BlueFinder is able to fix nearly all the cases where it recommends a featured prediction. Additionally, more than 50 % of the BlueFinder recommendation in this evaluation were featured recommendations. This means, making a projection over the unconnected cases, around 270,367 of new connections in Wikipedia. 12 extends the information from Table 2 to all the recommendation positions in a line-chart which compares the hit-rate to the first five positions of the BlueFinder recommendation. As we expected, the curve is in descending order while the first position has the best hit-rate (0.78) and the last position the lowest (0.17). This confirms the correlation between the confidence and hit-rate of the predictions. Unfortunately, the hit-rate curve descends more rapidly than we expected to second position and continues descending until the last position.

Distribution of the BlueFinder Recommendations Wikipedia editors mainly use one convention to represent 18 out of 20 properties in Table 1. Blue-Finder is able to predict one path query for these properties; in this case the Gini index is greater than 0.8.

However, because Wikipedia editors use more than one convention for properties such as prop 9 and prop 11 , the BlueFinder predictions have Gini index values between 0.474 and 0.778 for different k, and BlueFinder predicts several path queries. For instance, the convention for the property prop 9 : debutStadium is either a Standalone list or a Category such that #from / List of West Coast -Players / #to and #from / * / Category: West Coast Players / #to. In order to answer the third question, BlueFinder gives the user the recommendations in descending confidence order. The confidence is also correlated with the hit-rate of the prediction. This enables users to make a better choice of the predictions. The hit-rate of the predictions in the first position is accurate and it is also better when the prediction is a featured prediction. Wikipedia editors, in general, only use one convention to represent links in Wikipedia but in some cases; two in this evaluation; some communities define particular conventions. We can conclude this by taking into account that the prediction distribution is centralized in one convention. Additionally, the evaluations showed that those predictions are accurate.

BlueFinder gives good predictions even when the contributors have different conventions. Indeed, this can be concluded by taking into account that the Gini Index, in most of the cases, defined a centralized distribution of a path query in the recommendations, and also the accuracy level of BlueFinder in those cases.

Conclusions and Further Work

In this paper, we introduce the information gap between Wikipedia and DBpedia. To reduce this gap, we have to discover Wikipedia conventions to represent a DBpedia property between a pair of Wikipedia articles. We propose BlueFinder, a collaborative recommender system that recommends navigational paths to represent a DBpedia property in Wikipedia, while respecting Wikipedia conventions. BlueFinder learns from those similar pairs already connected by Wikipedia community and proposes a set of recommendations to connect a pair of disconnected articles. BlueFinder exploits DBpedia types to define a similarity function. Experimental results demonstrate that BlueFinder is able to fix in average 89 % of the disconnected pairs with good accuracy and confidence.

Currently, BlueFinder is tailored for Wikipedia/DBpedia where entities matching are well-defined. However, BlueFinder can be generalized to other datasets with established entities matching.

As a further work, we plan to update Wikipedia with BlueFinder recommendations. We have detected more than 50 % of the recommendation are featured recommendations. This means around 270,367 new links will be added to Wikipedia. The future work will be based on a crowdsourcing activity and a monitoring program which evaluates the community agreement of the new connections. Moreover, we are going to adapt this approach in combination with non-English versions of Wikipedia. Finally, we plan to extend the approach to any property in DBpedia in combination with other languages of Wikipedia and to offre the next generation of BlueFinder as a service for any Wikipedia editor.

Fig. 1 :

 1 Fig. 1: Information flow between Social Web and Semantic Web

Fig. 3 :

 3 Fig. 3: Example of Wikipedia Graph, Navigational Path, Path Queries and Path Index

Fig. 4 :

 4 Fig. 4: BlueFinder algorithm steps

) 6 :

 6 M ← N oiseF ilter(knnP I) {M ordered in rating descendent order} 7: M ← StarGeneralization(M, knnP I) 8: return maxRecom path queries of M

) 2 =

 2 (0 + 0.75)/2 = 0.375 Now, we can define the kNN [25] in our context as: Definition 11 (kN N ). Given a pair r ∈ Q p (D) and an integer k, the k nearest neighbors of r denoted KN N (r, Q p (D)) is a set of k pairs from Q p (D) where ∀o ∈ KN N (r, Q p (D)) and ∀s ∈ Q p (D) -KN N (r, Q p (D)) then SP SD(o, r) ≤ SP SD(s, r).

Fig. 5 :

 5 Fig. 5: BlueFinder: Similar path queries and star path queries in the execution of Use Case 1

Fig. 6 :

 6 Fig. 6: Evaluation method

  ? d b t o a <toType> . ? d b t o db-p:< DBpediaSemanticProperty> ? db from . ? db from f o a f : i s P r i m a r y T o p i c O f ? f r . ? d b t o f o a f : i s P r i m a r y T o p i c O f ? t o } Listing 1.3: SPARQL query template for evaluation scenarios.

Fig. 7 :

 7 Fig. 7: Precision, Recall, F1, and Hit-rate mean of all properties

Fig. 8 :

 8 Fig. 8: Precision all properties

Fig. 9 :

 9 Fig. 9: Recall for all properties

Fig. 11 :

 11 Fig. 11: Hit-rate for all properties

Fig. 12 :

 12 Fig.12: Confidence and hit-rate according to prediction order in the recommendation set

  do not use Semantic Web features as BlueFinder does, moreover, BlueFinder fixes navigation paths rather than only direct links.

	Extract of Wikipedia Graph	Paris	Paris Cat:	People from Paris Cat:	Pierre Curie
		Rosario				Lionel Messi
			Rosario Cat:	People from Rosario Cat:
	Navigational Paths & Path Queries
	(Paris, Pierre Curie)
	Navigational Path				Path Query
	Paris / Category: Paris / Category: People from Paris / Piere Curie	#from / Category: #from / Category: People from #from / #to
	(Rosario , Lionel Messi)
	Navigational Path				Path Query
	Rosario / Category: Rosario / Category: People from Rosario / Lionel Messi	#from / Category: #from / Category: People from #from / #to
	Rosario / Lionel Messi				#from / #to
	Path Index				PQ	I	Cp(l)
	#from / Category: #from / Category: People from #from / #to	(Paris,
						Pierre Curie)
				#from / #to	(Rosario,
						Lionel Messi)

  Again properties prop 12 , prop 2 , and prop 15 are out of norm. The lowest recall value with k=5 and maxRecom=5 is 0.473 for prop 2 property, and the maximum value is 0.972 for prop 14 property.Figure10presents the valus of F1 metric, although the values for the properties prop 2 , prop 12 and prop 15 are low, twelve properties out of twenty have F1 values greater than 0.6 at k=5 and maxRecom=5.

	/01/$"	/01/%"	/01/&"	/01/'"	/01/("
	/01/)"	/01/*"	/01/+2"	/01/,"	/01/$!"

/01/$$" /01/$%" /01/$&" /01/$'" /01/$(" /01/$)" /01/$*" /01/$+" /01/$," /01/%!" F1 Fig.

10

: F1 for all properties them with k=5 and maxRecom=5.

Table 2 :

 2 Confidence and hit-rate for High Confidence predictionsConfidence Additionally, Figure

Table 4 :

 4 Gini index of the properties prop 9 : debutstadium and prop 11 : training with maxRecom=5

http://www.wikipedia.org

A place could be a Country, Province, City, or State.

Charlie Aitken (footballer born 1942)

It must be read as from Edinburgh article, the user navigates through a link to the category Edinburgh then he or she navigates to People from Edinburgh category, and then to Charlie Aitken article".

http://en.wikipedia.org/wiki/Wikipedia:Conventions

http://en.wikipedia.org/wiki/Boston

http://en.wikipedia.org/wiki/Tim_Barsky

http://en.wikipedia.org/wiki/Donna_Summer

In this work, we use β = 1000.

1. We measure the information gap between DBpedia and Wikipedia for a set of twenty representative DBpedia properties. 2. We re-design and propose several optimizations for BlueFinder algorithm. 3. We propose a new Semantic Pair Similarity Distance (SPSD) function to measure the similarity between pairs of related articles based on the DBpedia types description. 4. We conduct an empirical evaluation that measures Precision, Recall, F1, Hit-rate, and the confidence of BlueFinder recommendations over the twenty properties of DBpedia. The results demonstrate that BlueFinder is able to fix in average 89 % of the disconnected pairs with good accuracy and confidence. Acknowledgements This work is supported by the French National Research agency (ANR) through the KolFlow project (code: ANR-10-CONTINT-025), part of the CONTINT research program.