A document may include mentions of people, locations, organizations, films, product brands and other kinds of entities. Such mentions are often ambiguous, with no obvious way for a machine to map them to real world entities, due to reasons like homonymy and polysemy. The process of recognizing such mentions in unstructured texts and disambiguating them by mapping them to entities stored in a knowledge base is known as Named Entity Recognition and Disambiguation (NERD) or Entity Linking. In this paper, we introduce GEEK (Graphical Entity Extraction Kit), a NERD system that extracts named entities in text and links them to a knowledge base using a graph-based method, taking into account measures of entity commonness, relatedness, and contextual similarity. All relevant data is retrieved at runtime using public RESTful APIs. GEEK tries to push the performance limits of a straightforward disambiguation method, that doesn't require arduous training or a complex mathematical foundation.
• Information systems → Entity resolution; Information extraction; • Computing methodologies → Natural language processing; • Mathematics of computing → Approximation algorithms;
Most pieces of text one can find online are to a large extent unstructured and unlabeled. Extracting the mapping between named entities appearing in text and real world objects stored in a knowledge base contributes a great deal towards understanding unprocessed written word. As an example, consider the sentence: “Arizona and Oklahoma are two of the ships that sank in Pearl Harbor during Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).
LDOW2018, April 2018, Lyon, France © 2018 Copyright held by the owner/author(s). the events of World War II.” A human reader, even one that is not familiar with 20th century history, can easily deduce the mapping of Figure 1. However, if we try to reproduce the same results using automated methods, then considerable efort is required in order to overcome the inherent ambiguity of natural language.
Even though NERD is a challenging NLP task, it has been
extensively addressed in past research [
This paper introduces GEEK (Graphical Entity Extraction Kit), a pipeline of tools and methods to perform NERD. It relies on Stanford CoreNLP for the named entity mention extraction task, and on Google’s Knowledge Graph and Wikipedia APIs for collecting information on the extracted entities. The collected information is then mapped onto a graph, thus transforming the task of entity linking into a graph problem, which is easier to handle. The resulting graph problem is solved using a heuristic method, which incrementally reifnes the candidate entities. The entire pipeline is evaluated against established NERD systems on the GERBIL framework. GEEK is found to be competitive when compared against these systems in the NERD task, suggesting that it is a potent alternative to methods having a more complex analytical foundation.
The rest of the paper is structured as follows: Section 2 models the NERD process in general terms. In Section 3 we start the presentation of the proposed system by discussing how it performs the named entity recognition step, and in Section 4 we discuss the core of GEEK, the disambiguation step. Section 5 presents an extensive evaluation of the proposed system by comparing it to other state-of-the-art systems. Finally, Section 6 discusses related work, and Section 7 concludes the paper. 2
In this section we model NERD in a simple way that may serve as a general framework for NERD algorithms. We assume that we have a knowledge base K B, which contains a mapping between entities of the world and Unique Resource Identifiers (URIs), which are concise and unambiguous. We also assume that there exists a set N of all names that can be used in natural language texts Arizona and Oklahoma are two of the ships that sank in Pearl Harbor during the events of World War II. to denote said entities in K B. According to our natural language conventions, there is a mapping f between the entities in K B and those subsets of N that can be used to refer to them:
f : K B → 2N This means that every entity in K B can be referred to in texts using only a specific set of names. If we model a text T as a simple string consisting of characters, then the appearance of a name n ∈ N in T means that there is a possible mention of the corresponding K B entity. The process of finding named entities in unstructured texts is called named entity recognition (NER), and can be described as ifnding substrings of T that map to any name n ∈ N :
NER : T 7→ M where M = {m | m is a substring of T and ∃URI ∈ K B s.t. m ∈ f (URI)} The process of mapping the named entities in M to specific URIs of K B is called named entity disambiguation (NED). NED is required because the same name may be used for diferent entities, i.e. there may be distinct URIs e1, e2 s.t. f (e1) ∩ f (e2) , ∅. The first step for disambiguating a mention m is to generate an appropriate candidate entity set for m, denoted as Em . This is defined as the set of individuals in K B that can be referred to as m:
Em = {URI ∈ K B | m ∈ f (URI)} After we generate candidate entity sets for all named entities in a text T , NED selects the most appropriate entity from each of those sets:
NED : m 7→ e ∈ Em , for each m ∈ M
To sum up, NER identifies individual names in a text T and NED maps those names to the most appropriate candidates for them in K B. Clearly, to be more eficient, NED could disambiguate jointly the entire M. The process of named entity recognition and disambiguation (NERD) combines NER and NED:
N ER N ED NERD : T −−−−→ M −−−−−→ E where E is the set of URIs finally selected by NED.
Consider text T = “Arizona and Oklahoma are two of the ships that sank in Pearl Harbor during the events of World War II” of Figure 1. NER gives us the set of names M = {Arizona, Oklahoma, Pearl Harbor, World War II}. Next, we use Google Knowledge Graph (GKG) as knowledge base K B and apply NED to map these mentions to URIs in K B. The problem is the ambiguity of mentions. For example:
EArizona = {/m/0vmt, /m/019r32, /m/06rxnl, . . .}
In particular, “Arizona” could refer to the American state of Arizona1, a Pennsylvania-class battleship named Arizona2, and the beverage manufacturing company known as Arizona3, among other candidates. NED needs to identify the correct choice for the specific text T , one that abides with human understanding of written word:
Arizona 7→ /m/019r32
3
As the above-presented model suggests, the first step in any NERD
pipeline is the identification of the named entity mentions set M in
a given text T . This step is important, since the discovery of exactly
those noun phrases that denote named entities directly afects the
quality of the final disambiguation results. For the NER part of
GEEK we use Stanford CoreNLP4 [
Person, or Organization. • 4 class model, which discovers entities of type Location, Person, Organization, or Misc, so that there’s a category for entities that don’t match the first three (miscellaneous). • 7 class model, which discovers entities of type Location,
Person, Organization, Money, Percent, Date, or Time. Experimentation with the above CoreNLP models revealed that, while the 3 class model is able to capture most relevant entities, in some cases it can be complemented by the 4 class and 7 class models. Moreover, the 3 class model is relatively better in detecting the full span of multi-word named entities. Thus, aiming for maximum named entity recognition coverage, we combine Stanford CoreNLP’s models using the following three step procedure: (1) We extract named entities using Stanford CoreNLP’s 3 class model.
(2) We extract named entities using Stanford CoreNLP’s 4 class model, but keep only those entities that don’t overlap with the ones we got from the first step. (3) We extract named entities using Stanford CoreNLP’s 7 class model, but keep only those entities that don’t overlap with the ones we got from the first two steps. Furthermore, we reject any entities that have types of Money, Percent, Date, or Time, as we aren’t interested in quantitative or temporal entities.
We should note that the type Stanford CoreNLP provides for each detected named entity may not always be correct (people may be recognized as locations, locations as organizations, and so on). For this reason, we use Stanford CoreNLP only to identify the named entity mentions in the text, and we do not use the provided type information in the disambiguation process. 4 4.1
After discovering the set M of named entities in text T , the next step is to find the best mapping between those named entities and the canonical entities that reside in K B. To that end, for each m ∈ M we generate the set of candidate entities Em that contains only those entities that one could refer to by saying m, using Google’s Knowledge Graph (GKG)5 as our K B. Technically, we achieve this by using Google’s Knowledge Graph Search API (GKG API)6, Google’s replacement for their deprecated Freebase7. Using GKG API, one can get a ranked list of GKG entities related to a given query string. In particular, for each matching entity, GKG API returns its names, the corresponding Wikipedia8 information, its schema.org9 types, etc. In our case, we use the API to retrieve GKG entities that match a certain named entity mention. For example, querying for “Arizona” fetches a number of entities that match that string, like the state of Arizona, the Pennsylvania-class battleship, the beverage company, and so on.
Unfortunately, not all entities this method yields belong to the set of candidate entities Em for a mention m. For example, it’s not unusual that GKG API returns an entity that is missing fields critical for our disambiguation framework, such as the corresponding Wikipedia information. Entities missing such important response ifelds are deemed useless for our disambiguation pipeline, and are immediately rejected.
Another inconvenience is that GKG API is a general purpose tool that has not been specifically designed to serve as generator of candidate entities to be used for NED. For example, when we query for “Arizona”, GKG API returns, among other entities, Phoenix, the capital of the state of Arizona. It is pretty clear what happens here: GKG API returns not only those entities that could be referred to by saying “Arizona”, but also entities closely related to “Arizona”. That may make perfect sense for some applications, but in our case it poses a serious problem. Given that for a mention m we want Em to be comprised of only those entities that we can refer to 5https://www.google.com/intl/es419/insidesearch/features/search/knowledge.html 6https://developers.google.com/knowledge-graph/ 7https://developers.google.com/freebase/ 8https://en.wikipedia.org/wiki/Main_Page 9http://schema.org/ by saying m, we shouldn’t allow Phoenix to be a candidate entity for “Arizona”, as no one would use the name of a state to refer to its capital city. In order to mitigate the efect of this problem, we turn to Wikipedia for help. We try to make an educated decision about whether or not an entity can be referred to as m by querying Wikipedia’s disambiguation pages and redirects. This is achieved by consulting Wikipedia’s disambiguation pages for candidate entities and Wikipedia’s redirect pages for possible aliases of entities, and giving priority to those entities returned by GKG API that are also returned by Wikipedia (as GKG API returns each entity’s corresponding Wikipedia article). We fetch the required information using services provided by MediaWiki API10. We access the disambiguation pages and the redirects via the MediaWiki Links API11 and the MediaWiki Redirects API12 respectively.
By combining the aforementioned methods, we manage to
construct an approximation for a mention’s set of candidate entities.
Building the sets of candidate entities properly is crucial for a
successful disambiguation system [
After building the set of candidate entities Em for a named entity mention m, we need to select a concrete entity e ∈ Em to realize the mapping m 7→ e. As stated above, our goal is try to make the same mapping a human reader would make. In order to do that, GEEK employs three measures akin to human thinking patterns.
4.2.1 GKG resultScore. When we query GKG API with a string m, then each returned entity is accompanied with a resultScore field. This is a positive real number that indicates how good a match is the returned entity for the given request. In our framework, this value is used as an alternative measure of an entity’s popularity prior (also known as prior probability or commonness). Popularity prior is a measure of the conditional probability of one referring to an entity e, given the mention string m:
Popularity Prior[e |m] = P[m 7→ e |mention m appears in text]
This conditional probability can be approximated in various
ways, more prominently using Wikipedia and its links to deduce
how often each surface form is used to refer to a specific entity in
the encyclopedia. Popularity prior’s usefulness as a disambiguation
measure can be explained using what is seemingly a tautology: a
mention m usually refers to the entity e that is referred to by m
most of the time. However, it is one of the most widely used
measures in NED systems [
Simply comparing the words contained in two documents has the potential to guide the disambiguation process. For example, returning to Figure 1, the word “ship” would help a human understand that Arizona and Oklahoma are ships, and not states. The same goes for a system that uses this measure to calculate document similarity, as the word “ship”, as well as several of its derivatives, appear multiple times in the respective articleBody fields.
4.2.3 Entity Relatedness. In the literature, it is common to
assume that a text contains a few coherent topics [
log(|W P |) − log(min(|I N1 |, |I N2 |)) Returning to Figure 1, it is clear why relatedness is so important. It is much easier to disambiguate Arizona and Oklahoma as battleships, given that Pearl Harbor is the military strike, and, on the same note, it is pretty straightforward to disambiguate Pearl Harbor as the military strike, given the text talks about World War II. 4.3
Previously, we touched on the positive correlation that exists between the proposed NED measures and a disambiguation that seems 13https://www.mediawiki.org/wiki/API:Linkshere natural to a human reader. However, we need to find a way to combine those measures in a sensible way, as, more often than not, each of them favors a diferent disambiguation decision. For example, in the text shown in Figure 1, the GKG resultScore measure indicates that Arizona and Oklahoma are states, while document similarity and entity relatedness indicate that they are, in fact, ships.
We combine those three measures on a graph G, the cornerstone of GEEK, which we call candidate entity graph. Given a text T that contains k named entity mentions M = {m1, m2, . . . , mk }, we generate candidate entity sets E1, E2, . . . , Ek . Then, for each candidate entity set Ei = {ei1, . . . eini }, where ni = |Ei |, we add to G nodes ei1, . . . eini , where each node ei j corresponds to the j-th candidate entity for mention mi . We complete the construction of G, by connecting each node ei j to each node euv , where i , u, with an undirected weighted edge. The edge’s weight is calculated as a linear combination of the three NED measures introduced above, applied for both of the candidate entities ei j (j-th candidate entity for mention mi ) and euv (v-th candidate for mention mu ): weiдht (ei j , euv ) = a · b · rs(ei j ) + (1 − b) · sim(T , Tei j )
2 + b · rs(euv ) + (1 − b) · sim(T , Teuv ) 2 ! + (1 − a) · WLM(ei j , euv ) where rs ≡ normalized GKG resultScore sim ≡ binary document similarity 0 ≤ a, b ≤ 1 The candidate entity graph G is undirected, weighted, complete, and k-partite. That means G’s nodes are distributed among k independent sets. If two nodes belong to the same independent set, then they are not adjacent. If they belong to diferent independent sets, then they are adjacent and connected by an undirected weighted edge. The idea behind this is simple: there is no point in connecting two entities that are candidates for the same named entity mention mi , as they are mutually exclusive, that is, if ei j , eil ∈ Ei , then (mi 7→ ei j ) =⇒ ¬(mi 7→ eil ) and (mi 7→ eil ) =⇒ ¬(mi 7→ ei j ) The parameters a and b serve to add two degrees of freedom to the way we prioritize NED measures. In particular: • a determines how much we value the matching between a mention’s string (calculated as GKG resultScore) as well as the complete text’s string (calculated by document similarity) and the candidate entity’s attributes, versus how much we value W LM. • b determines how much we value GKG’s resultScore as a degree of entity commonness, versus how much we value term-overlap document similarity.
Given that all NED measures are normalized (their values range from 0 to 1), it follows from the way we calculate the weights of G’s edges that those weights are also normalized. 4.4
Building the candidate entity graph G is an important step towards disambiguating the named entities found in text T . That is because we transform an unstructured, hard to process piece of text into a well-defined, abstract data structure we can work with. Of course, building G is not the end of the story. We need to find a way to map G to a disambiguation for T ’s entities. This mapping represents GEEK’s main contribution when compared to the literature’s graph-based NERD solutions: a straightforward subgraph extraction method that incrementally eliminates unsuitable candidate entities. This leads to a sequence of candidate entity graphs G(1), G(2), G(3), . . ., where each G(x +1) better approximates the correct disambiguation result compared to G(x ).
Given that G is comprised of k independent sets of nodes, each
set Ei containing candidate entities for named entity mention mi , it
is clear that we need to select exactly one node ei j from each
independent set Ei . This process is equivalent to mapping each named
entity mention to exactly one of its candidate entities. However,
what is not clear is the optimal way to perform said mapping. In
our framework, we assume that the correct disambiguation lies in
G’s maximum weight k-clique, denoted as G∗. G∗ is the induced
subgraph of G that contains exactly one node from each
independent set Ei , such that the total weight of the connecting edges is
maximized. Hence, we face the problem of finding a maximum
weight k-clique in an undirected, weighted, complete, and k-partite
graph. Such combinatorial optimization problems have been
tackled by NERD frameworks in the past, and have been proved to be
NP-hard [
In this context, we need to come up with an approximation for G∗. To this end, we formulate a heuristic method that is tailored to our problem specifications. Our goal isn’t to find a general purpose solution for the maximum weight k-clique optimization problem, but only a way to solve the problem, given that it arises from a semantically coherent text and its candidate entities. The method we suggest is based on the fact that a lot of candidate entities seem outlandish for a specific textual context. Thus, finding these out of place entities is the key to our disambiguation algorithm. For example, in the text of Figure 1, the candidate entity Arizona Beverage Company seems to be a bad choice for the disambiguation of mention “Arizona”, as suggested by all three NED measures. Indeed, the Arizona Beverage Company isn’t usually what one refers to when one says “Arizona” (low commonness), the text doesn’t contain any terms that would suggest it’s talking about this company (low document similarity), and, finally, the beverage company isn’t related to the other entities in the text (low entity relatedness).
In order to identify those alien entities in the candidate entity space, we consider for each candidate entity ei j the disambiguation in which ei j has the maximum weight contribution. For each candidate entity ei j , we define its maximum contribution graph Gei j as the G∗ candidate in which node ei j has the maximum possible weight of incident edges. Calculating the Gei j graphs for all candidate entities is straightforward, as it only requires visiting ei j ’s neighbors in G. Each Gei j graph suggests a disambiguation for all entities in T , and those graphs can be used to identify the alien entities discussed above. To elaborate further, when we construct Gei j for a candidate entity ei j , it’s like we are forcing ei j in the given context, in order to see what happens with our objective function, which is the resulting graph’s total weight. We hypothesize that there are two cases: • ei j is the correct disambiguation choice for mention mi , which will be reflected on Gei j ’s increased total weight, as the NED measures’ values will be high. • ei j is not the correct disambiguation choice for mention mi , which will be reflected on Gei j ’s decreased total weight, as the NED measures’ values will be low.
Aiming for an incremental disambiguation process that eliminates said alien entities, we developed a worst out heuristic method, which removes the entity that seems most unfitting in each step, until we achieve disambiguation of all entities. This is more efective than a best in heuristic, as it is easier to identify the many entities that don’t fit, rather than those few entities that are correct. An outline of this method is presented by Algorithm 1. An example of building the maximum contribution graph for a candidate entity is presented in Figure 2. It’s important to note that after each removal step, we need to recalculate the maximum contribution graphs for our candidate entities, as demonstrated in Figure 3. Solving the candidate entity graph is the final step in the disambiguation process, and the entire pipeline is illustrated by a flow diagram in Figure 4.
1: function WorstOutHeuristic(G) 2: if |Ei | ≤ 1 ∀i = 1, 2, . . . , k then 3: return G ▷ disambiguation complete 4: end if 5: for each ei j ∈ G do 6: calculate Gei j 7: end for 8: tied_nodes = {ei j ∈ G : |Ei | > 1 ∧ euv with |Eu | > 1 such that weiдht (Gei j ) > weiдht (Geuv )} 9: ifnd e ∈ tied_nodes with minimum incident edges weight 10: return WorstOutHeuristic(G \ e) 11: end function Algorithm 1: Outline of the worst out heuristic method used to disambiguate named entities in text. Every function call isolates the “most outlandish” entity, which is then removed from graph G, until disambiguation is achieved. Note that the total weight of the maximum contribution graphs is the ifrst thing we take into account. However, we use the nodes’ incident edges weights to resolve ties. 5 5.1
We evaluated GEEK using three kinds of datasets: a small texts
dataset we manually generated, a medium-sized texts dataset
comprised of Reuters news articles, and a selection of two other datasets
provided by GERBIL [
Small texts dataset. In the interest of our system’s evaluation, we collected and compiled a dataset of small texts, which are dense in highly ambiguous named entities. The entities in this dataset were manually extracted and annotated. Each named entity was mapped to its best match in GKG and Wikipedia. This dataset was inspired from the KORE 50 NIF NER Corpus15. Its texts were gathered from online sources, such as encyclopedia articles, news feeds, blog posts, social media, and so on. It aims to test our system’s disambiguation capabilities given a limited context and a well defined semantic core. From now on, it will be denoted as SAT-300 (300 Short Ambiguous Texts). The SAT-300 dataset is available as part of this paper16.
Medium-sized texts dataset. The second part of our experimental
evaluation was performed using a standard benchmark dataset
in the field of NERD. This is a dataset of 231 Reuters news-wire
articles used by Hofart [
ϵ δ e21 E2
E3 e31 e32
Freebase (GKG’s predecessor) and Wikipedia. This dataset aims to test our system’s disambiguation capacity when it comes to longer texts, that may include a larger number of possibly unrelated topics. From now on, it will be denoted as Reuters-231.
Other datasets. To the end of further experimental evaluation of GEEK, we turn to GERBIL and use the KORE-50 dataset in order to assess its performance when it comes to short texts, as well as the complete CoNLL dataset to test our system on larger texts.
In order to assess the disambiguation that a system produces for a single text T , the precision, recall, F1 score, and accuracy measures may be used. In the context of NERD, precision is the fraction of correctly disambiguated named entity mentions that are generated by the system: precision =
|correctly disambiguated entities| |disambiguated entities produced by the system| Recall is the fraction of correctly disambiguated named entity mentions that should be disambiguated: recall =
|correctly disambiguated entities| |entities that should be disambiguated| The F1 score is the harmonic mean of precision and recall: NER
Use given mentions
NED
Yes
The evaluation measures of precision and recall are used when the NERD system is responsible for the step of NER. Oftentimes, that is avoided, when the named entities to be disambiguated have already been marked and are provided to the disambiguation system straightaway. In this case, only the NED part of the system is evaluated, and accuracy is used as the only evaluation measure: accuracy = |correctly disambiguated entities|
|entities marked in text|
In the case of a collection of texts, one could use precision and recall to evaluate a system’s NER + NED performance, and accuracy to evaluate its NED performance, for each and every one of the texts separately. However, this would turn the experimental results into a long, dificult to interpret list of numbers. That is why we use the Micro Average and Macro Average aggregation approach: • Micro Average: We assume that the dataset’s texts are combined to form a large text, on which we are able to use the above-provided definitions of precision, recall, and accuracy. • Macro Average: We evaluate the system’s performance on the dataset by averaging precision, recall, and accuracy calculated on each of the collection’s texts.
For the sake of space preservation, we use the abbreviations Micro Average F1 score ≡ µ AF1, Macro Average F1 score ≡ MAF1, Micro Average Accuracy ≡ µ AA, and Macro Average Accuracy ≡ MAA. Similarly to the case of a single text, we use the aggregated version of accuracy in cases where the named entities to be disambiguated are given to the disambiguation system as part of its input.
SAT-300 dataset. The performance of our system on the SAT-300 dataset in terms of the µ AF1 and MAF1 measures can be seen in the SAT-300 relevant parts of Table 1 and Figure 5. We used the F1 score, because in this experiment we fed the texts to the system as plain strings, and it was the system’s responsibility to recognize and then disambiguate the named entities.
For comparison, the results obtained from GERBIL for a sample of its available annotators on the same dataset using the A2KB task17 are displayed in Table 2. We note that our system outperforms other systems on small ambiguous texts. Based on this experimental analysis, we can draw several conclusions about our system: 17Full SAT-300 results: http://gerbil.aksw.org/gerbil/experiment?id=201801240021 • The system’s best configuration is a = 0.5. This means that balancing between GKG resultScore and document similarity versus entity relatedness yields the best results. • We notice from Table 1 and Figure 5 that a = 0.0 gives us better results than a = 1.0. This means that the most important measure is entity relatedness. This reflects the nature of our dataset. Indeed, we anticipate small, semantically coherent texts to contain highly related entities. We also observe that GEEK performs better on SAT-300 compared with Reuters231. That diference is due to the entities found in the two datasets: SAT-300 only contains entities stored both in GKG and Wikipedia, so there are rarely out-of-knowledge-base entities; this is not true for Reuters-231, as well as the larger CoNLL dataset below, where exist many entities that don’t exist in GKG. Those inevitably lead to false positives in the context of an annotator that always tries to map all mentions to entities. • Both Micro Average and Macro Average aggregation measures give us similar results.
Reuters-231 dataset. The results of the experimental evaluation
of our system using the Reuters-231 dataset can be seen in the
Reuters-231 relevant parts of Table 1 and Figure 5. For this dataset,
we only calculate accuracy because this is the measure used by
Hofart [
KORE-50 and CoNLL datasets. Setting a = 0.5, which from the experimental evaluation turned out to be the best overall performing value, we further tested GEEK by comparing its performance on GERBIL’s A2KB task against the service’s annotators on the KORE-50 dataset18, a dataset similar to SAT-300, but with a higher level of ambiguity, as well as the complete CoNLL collection of documents19. The results, in terms of the µ AF1 and MAF1 scores, can be found in Table 3. We conclude that GEEK outperforms other annotators on the small documents of KORE-50, but it does not achieve top performance when it comes to the larger texts of CoNLL. This is due to the nature of the disambiguation algorithm applied by GEEK, where in-document coherence is crucial, and this attribute is less prominent in larger documents.
To sum up, GEEK seems to outperform the state-of-the-art on short documents, while being competitive on longer documents. 6 6.1
As mentioned above, the subtask of NER is critical for a NERD
pipeline. When it comes to NER, two main approaches have been
followed in the literature:
• Building a dedicated tool. This could mean anything from
using a statistical approach [
In this paper we introduced GEEK, a framework that tackles the dificult task of NERD by combining well-established measures, such as commonness of entities and coherence, with new potent tools, such as the Google Knowledge Graph Search API. We proposed a graph representation of texts, which allowed us to model disambiguation as a concise graph-based problem and solve it using a heuristic method that finds the best clique in a stepwise manner.
The main strength of GEEK is that it is built on top of publicly available data sources and has a straightforward graph algorithm at its core. Moreover, the experimental evaluation on GERBIL showed that GEEK produces competitive scores in comparison with other state-of-the-art systems, which suggests that one does not always need specialized knowledge bases or sophisticated disambiguation algorithms to achieve a high quality disambiguation result.
We acknowledge support of this work by the project ”APOLLONIS” (MIS 5002738) which is implemented under the Action ”Reinforcement of the Research and Innovation Infrastructure”, funded by the Operational Programme ”Competitiveness, Entrepreneurship and Innovation” (NSRF 2014-2020) and co-financed by Greece and the European Union (European Regional Development Fund).