Historical Entity Extraction: A Guide

This is a working guide to historical entity extraction — finding the people, places, and organizations named in a manuscript and linking each to a stable identifier. It is written for the historian who already has transcribed material and wants entities pulled from it in a way that survives peer review. The recurring lesson: recognition is the easy part, and the errors that sink you are the ones that arrive looking correct.

Historical entity extraction is the process of finding and typing the people, places, and organizations named in a historical text — and, where possible, linking each mention to a stable identifier in an authority file. It matters because a name in a manuscript is not searchable until a machine knows it is a name. The difficulty is that historical spelling varies, the referents of names drift over time, transcription noise corrupts the surface string, and most ordinary historical people appear in no knowledge base at all. Done well, entity extraction turns a corpus into a prosopography. Done carelessly, it manufactures confident errors that are hard to catch later.

This guide assumes you care more about defensibility than throughput. Most of the work is not the recognition step. It is knowing what that step can and cannot do, and building verification into the pipeline before the errors compound.

The vocabulary you actually need

The field carries more jargon than the task warrants, but a few distinctions do real work.

Named Entity Recognition (NER) identifies and classifies mentions in running text — most commonly person (PER), location (LOC), and organization (ORG), with time, occupation, and other types added as a scheme requires. The tags themselves follow conventions such as BIO/IOB, which mark where each span begins and ends. Recognition finds typed spans on a string, and nothing more.

Named Entity Linking (NEL), also called entity linking or disambiguation, is the separate and harder step of mapping each recognized mention to a unique identifier in a knowledge base — WikiData, VIAF, GND, GeoNames, Getty TGN, Pleiades. When people say NERC, they mean recognition plus classification treated together.

Two terms will save you grief. A NIL mention is one with no entry in any available knowledge base — common for the ordinary people who fill parish registers and account books. And entity drift (referential change) is the fact that a string's referent moves over time: Berlin in 1700 is not Berlin in 1900, France means something different before and after 1789, and personal-name forms shift spelling from one clerk to the next. A pipeline that ignores drift will silently link the wrong entity with complete confidence.

If your output is meant to be citable, the destination is usually TEI P5 — the Text Encoding Initiative Guidelines, chapter 14, which define the elements for names, dates, people, and places. TEI is where recognition, linking, and prosopographic grouping (`<listPerson>`) come together into something durable. More on that below.

Recognition is not the whole job

Treating recognition as the whole job is the most common mistake. NER only finds typed spans. Grounding those spans to real-world referents is a distinct task where silent errors accumulate. The ACM Computing Surveys review of historical NER and classification (Ehrmann, Clematide & Romanello, 2023) is blunt about this, and the practical implication follows directly: budget at least as much effort for linking and verification as for recognition itself. Teams that plan only for the recognition step discover the linking problem after the schedule is set.

A second habit belongs here. TEI encoding is not the same as NER output. A tagger produces a typed span. TEI additionally carries a resolving URI in `@ref`, standoff provenance, and prosopographic aggregation through `<listPerson>`, which groups every mention of one person across a corpus into a single biographical record. Conflating the two strips out exactly the citability that made TEI worth using. Recognize the span, attach a resolvable `@ref` from the right authority, and aggregate with `<listPerson>`. Those are three operations, not one.

Choosing an approach

There are four broad ways to extract entities from historical text, and the honest answer is that the best pipelines combine them.

Rule-based and gazetteer methods

Matching against curated lists of known strings still earns its place on closed, well-bounded vocabularies: administrative offices, controlled place types, occupational titles. These methods deliver high precision. The cost is recall and maintenance. You must hand-curate the variant forms and add fuzzy matching to catch historical spellings, or the list quietly misses half its targets.

Statistical sequence labellers

Tools such as Stanford NER and CRF-based taggers led the field through the mid-2010s and remain serviceable baselines. They are cheap to run and predictable in their failures.

Fine-tuned transformer encoders

These now lead accuracy wherever training data exists — and the important qualifier is period- and language-specific. Generic multilingual BERT is consistently beaten on historical registers by encoders trained on the right material: hmBERT (historical multilingual), CamemBERT for French, BERTje and GysBERT for Dutch, MacBERTh for Middle English, and the GermanBERT family. hmBERT reached state-of-the-art on three of four languages in the NewsEye dataset. The lesson generalizes: assume nothing off the shelf, pick the best available model per language, and accept that Spanish, Italian, and pre-modern Dutch are less well served than English, French, and German.

LLM-prompted extraction

GPT-4, Claude, Gemini, and open-weight equivalents are increasingly competitive for well-known entity types and low-resource settings. But the literature — Gonzalez-Gallardo et al. (2023) and Zhang & Colavizza (2025) among them — documents hallucinated people, places, and organizations on long-tail referents, and silent modernization of archaic surface forms, which quietly breaks the diffability of your text against the source. Results are mixed, and a definitive cross-model benchmark against fine-tuned specialists does not yet exist. The current scholarly consensus is to treat LLMs as candidate generation only: useful for a first pass, never as the record. Verify every span against the source.

Two corrections worth stating plainly

Both are widely gotten wrong.

A modern off-the-shelf NER model will not simply work on your seventeenth-century text. Contemporary NER is trained on present-day newswire — CoNLL-2003 is Reuters copy — and spelling variation, entity drift, lexical shift, and transcription noise all degrade it. Modern transformer systems report F1 in the low- to mid-90s on English newswire; historical benchmarks sit noticeably below that ceiling. The CLEF-HIPE shared tasks exist precisely to measure and close that gap.
No single model covers all your languages well. Multilingual generalists yield uneven quality across registers. The finding is consistent from hmBERT through Provatorova et al.'s Too Young to NER on Dutch historical newspapers.

If you want to know how the field measures itself, the HIPE-2022 shared task is the reference point: HIPE-2020 drew 13 teams and 75 runs across English, French, and German historical newspapers, and HIPE-2022 expanded to five languages in the newspapers track and three in the classical commentaries track, retaining both recognition and linking sub-tasks. For Italian specifically, NERMuD at EVALITA 2023 is one of the few historical benchmarks that exists.

The step that decides everything upstream: transcription quality

This is the part most guides bury, and it should be first. Entity extraction inherits every error in the text you feed it, and the inheritance is not linear — it collapses.

Huynh, Jeanneau & Doucet (ICADL 2020) quantified the effect: NER F1 degrades sharply once character error rate rises above roughly 20%, or word error rate above roughly 50%. Below that, correction may not be worth the effort. Above it, extraction becomes unreliable no matter how good your tagger is. A misread name is not a slightly wrong name — it is a name your recognizer cannot match, your linker cannot resolve, and your reader cannot trust. The practical rule: measure the transcription quality of your corpus before running NER, and where error rates are high, invest in correction or selective re-transcription first.

This is where the choice of transcription tool becomes an entity-extraction decision, not a separate one. Two failure modes matter here.

Garbled OCR produces visibly broken strings — the kind a tagger fails to match and a human immediately flags. That is recoverable. The dangerous failure is the fluent one. General-purpose LLMs, prompted to transcribe, tend to silently modernize archaic spelling and confabulate plausible readings, which means the surface form of a name is quietly rewritten into something that looks right and links cleanly to the wrong entity. Because the error is fluent, it survives review. The same trap recurs at the extraction stage, and it is worth understanding why fluent transcription errors are the hard ones to catch.

For the transcription layer that feeds extraction, this is the case for a specialist model trained on images of historical documents. Leo's ATR-1 is built to transcribe what is actually on the page rather than to normalize it — the archaic spelling of a surname survives, the long s stays a long s, an abbreviated place name is not silently expanded into its modern form. That source integrity is exactly what an entity pipeline needs, because the mention has to match the historical string for a gazetteer or a period-specific encoder to catch it, and it has to remain diffable against the source image for a reviewer to verify. On a randomized 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, ATR-1 scored around 5% character error rate at release — 61% fewer errors than the next-best model tested — with the full comparison published here. Against the Huynh threshold, that is comfortably inside the range where downstream NER holds up. ATR-1 reads Latin-script material in whatever language it is written — English wills, French notarial records, Dutch registers, German parish books — so the transcription that feeds your extraction is faithful before your tagger ever sees it.

Leo will also run an Extract named entities Transformation over a finished transcription, writing the result to a separate annotation tab so the base text is never altered — a serviceable first-pass candidate generator in the same workspace as the source. Treat its output as you would any automated extraction: candidates to verify against the image, not a finished record. For high-stakes downstream encoding — the resolving `@ref`, the `<listPerson>` aggregation, the standoff provenance — you will still be working in a dedicated TEI or annotation environment.

Linking: choosing authorities by period and type

Once you have verified spans, linking grounds them. The mistake to avoid is assuming the big general knowledge bases cover everything. They do not. GeoNames is not natively temporal — its own blog acknowledges the limitation — and WikiData's coverage of pre-modern persons and places is uneven.

Choose the authority by period and entity type:

Persons — VIAF (federated with national libraries), GND for German-speaking persons and corporate bodies, Nomen for multi-period prosopography.
Places — Getty TGN and GeoNames for the modern and near-modern; Pleiades as the curated authority for the ancient world.
General fallback — WikiData, with the caveat above.

And expect NIL. The ordinary historical person — the tenant in a deed, the witness to a will — has no authority-file entry and never will. A pipeline that forces every mention to a link is a pipeline that fabricates. NIL is a valid, honest result. Record it as one.

A defensible pipeline, end to end

Putting the pieces in order, the shape most scholarly projects converge on — and the shape operationalized by projects like impresso, NewsEye, and Living with Machines — runs: transcribe (OCR/HTR) → normalize → recognize (NER) → link (NEL) → encode (TEI or Linked Data). Each stage constrains the next, which is why the discipline of a source-faithful research workflow pays off most at the point where errors would otherwise compound.

A few principles hold across the whole pipeline.

Measure transcription quality first. If CER is above roughly 20%, fix the text before extracting from it.
Keep interpretation separate from the base record. Extraction and linking are annotations on a source, not edits to it. Standoff annotation — TEI supports it — stores your tags in a separate file pointing to character offsets, so the base text stays clean and multiple analytical layers can coexist.
Verify the high-stakes tokens by hand. Names and dates are where a silent error does the most damage and where automated confidence is least trustworthy. Verify against the image, not against the model's own certainty.
Encode for durability. Attach a resolvable `@ref`, aggregate with `<listPerson>`, and record NIL honestly.

The mature annotation tooling — Prodigy, INCEpTION, Label Studio for span work, Recogito for place and geo linking — assumes exactly this separation of layers, which is another reason not to collapse recognition and encoding into one undifferentiated pass.

Entity extraction rewards the same instincts that good historical work has always rewarded: skepticism toward a reading that arrives too fluently, patience with the name that resolves to nothing, and the discipline to keep your inferences visibly distinct from the words on the page. The machine can find the candidates. Deciding that this string, in this year, refers to that person — and being able to defend the judgment — is still yours.

Frequently Asked Questions

What is historical entity extraction?

Historical entity extraction is the process of finding and typing the people, places, and organizations named in a historical text and, where possible, linking each mention to a stable identifier in an authority file. A name in a manuscript is not searchable until a machine knows it is a name. The difficulty is that historical spelling varies, the referents of names drift over time, transcription noise corrupts the surface string, and most ordinary historical people appear in no knowledge base at all. Done well, it turns a corpus into a prosopography; done carelessly, it manufactures confident errors that are hard to catch later.

What is the difference between Named Entity Recognition and Named Entity Linking?

Named Entity Recognition (NER) identifies and classifies mentions in running text — most commonly person, location, and organization — marking where each typed span begins and ends. It finds typed spans on a string, and nothing more. Named Entity Linking (NEL), also called disambiguation, is the separate and harder step of mapping each recognized mention to a unique identifier in a knowledge base such as WikiData, VIAF, GND, GeoNames, Getty TGN, or Pleiades. Treating recognition as the whole job is the most common mistake; grounding spans to real-world referents is a distinct task where silent errors accumulate. Budget at least as much effort for linking and verification as for recognition.

Will a modern off-the-shelf NER model work on seventeenth-century text?

No. Contemporary NER is trained on present-day newswire — CoNLL-2003 is Reuters copy — and spelling variation, entity drift, lexical shift, and transcription noise all degrade it on historical material. Modern transformer systems report F1 in the low- to mid-90s on English newswire, while historical benchmarks sit noticeably below that ceiling. The best accuracy comes from period- and language-specific encoders: hmBERT for historical multilingual, CamemBERT for French, BERTje and GysBERT for Dutch, MacBERTh for Middle English, and the GermanBERT family. Assume nothing off the shelf and pick the best available model per language, accepting that some languages are less well served than English, French, and German.

How does transcription quality affect entity extraction accuracy?

Entity extraction inherits every error in the text you feed it, and the inheritance is not linear — it collapses. NER F1 degrades sharply once character error rate rises above roughly 20%, or word error rate above roughly 50%. Above those thresholds, extraction becomes unreliable no matter how good your tagger is. A misread name is not a slightly wrong name — it is a name your recognizer cannot match, your linker cannot resolve, and your reader cannot trust. Measure the transcription quality of your corpus before running NER, and where error rates are high, invest in correction or selective re-transcription first.

Can I use ChatGPT or Claude to extract entities from historical documents?

Use LLMs as candidate generation only, never as the record. GPT-4, Claude, Gemini, and open-weight equivalents are increasingly competitive for well-known entity types and low-resource settings, but the literature documents hallucinated people, places, and organizations on long-tail referents, and silent modernization of archaic surface forms — which quietly breaks the diffability of your text against the source. A definitive cross-model benchmark against fine-tuned specialists does not yet exist. The scholarly consensus is to treat their output as a useful first pass, verifying every span against the source image rather than trusting the model's own confidence.