Entity Linking and Knowledge Graph Construction › The Entity Linking Task

Formally, let a document $d$ contain annotated entity mentions $M = \{m_1, \dots, m_n\}$. A mention has a half-open character span $[start_i,end_i)$ and a surface form $surf_i$. Given a fixed KB entity inventory $\mathcal{E}$, the target assignment is a total function $\Phi: M \to \mathcal{E} \cup \{\text{NIL}\}$. Each mention receives one entity identifier or the label NIL.

NIL means that the referent has no matching entry in the specified KB snapshot. It is distinct from uncertainty: a mention may have a KB referent even when the model cannot choose among candidates. An application may abstain and send such a case for review without claiming that the referent is absent. A nonentity span is a mention-detection error and should be rejected under the annotation policy, rather than automatically labeled NIL.

Three things make this hard.

Name variation. One entity can have several names or abbreviations. A catalog might record Apple Inc., Apple, and a translated name as aliases of the same entry. The exact accepted aliases depend on the catalog and the task. Storing only a canonical title misses any alternative spelling that exact lookup cannot normalize to that title.

Name collision. A string such as Mercury can name different entities. Normalization that helps retrieve spelling variants can also collapse distinctions between names. A string match can retrieve candidates. When the string is ambiguous, use context or other evidence before accepting a link, or abstain.

Unlinkable mentions. A document may refer to a newly created organization or another entity outside the KB. The proportion of these mentions depends on the corpus and KB snapshot. Evaluation must include them when the intended deployment permits out-of-KB referents.

For this chapter, group the decisions into four stages so their errors can be evaluated separately:

1. Mention detection: find the spans that refer to entities.
2. Candidate generation: propose a small set of KB entities that the mention could refer to.
3. Disambiguation (ranking): score candidates and pick one.
4. NIL prediction and acceptance policy: distinguish an out-of-KB referent from a link that the application will not accept.

The stages have different error sets. Detection determines which spans reach the linker, retrieval determines which IDs a restricted reranker can choose, and ranking orders those IDs. NIL prediction concerns KB absence; an acceptance policy may also abstain on an uncertain in-KB case. Measure the stages separately to identify which decisions an improved component could repair.

For a reranker restricted to a retrieved candidate list, a missing gold entity cannot be selected. On a fixed set of gold in-KB mentions, linking accuracy is therefore no greater than candidate recall@k. Every correct prediction requires the gold entity to have been retrieved, so the inequality follows by counting those cases. This bound does not directly cover mention-detection F1, NIL classification, or systems that generate additional candidates after retrieval. Measure these stages separately.