One real thing can leave many records behind, and those records do not always agree on what the thing is called.
A person appears as “A. Rahman,” “Abdul Rahman,” “A Rahman,” an email address, a passport number and a customer ID. A company trades under a legal name, brand name and old name. One street has a formal address, historical name and local nickname. A book appears in several editions with different identifiers.
Entity resolution is the process of deciding when several records refer to the same underlying entity — and when similar-looking records should remain separate.
This article sits beneath How Metadata Works, How Databases Work and the existing How Library Authority Control Works. Authority control keeps names and identities coherent in library systems. Entity resolution owns the broader mechanism of matching records across heterogeneous data sources.
1. The Problem Has Two Opposite Errors
A false merge occurs when two different entities are treated as one. A false split occurs when one entity is represented as several unrelated records.
Both errors matter. False merges can attach one person’s history to another. False splits can make one customer appear as several customers or one author as several unrelated authors.
2. Exact Identifiers Are Strong — When They Are Trustworthy
A stable unique identifier can make resolution easy. But identifiers can be missing, mistyped, recycled, duplicated or scoped only within one system.
Entity resolution therefore rarely relies on one field without considering provenance and scope.
3. Names Are Useful and Ambiguous
Names can vary through spelling, transliteration, initials, punctuation, titles and ordering. Different people can share identical names.
Name similarity is therefore evidence, not proof. A strong resolver combines it with date, address, organisation, contact details, relationships or other discriminating fields.
4. Normalisation Removes Surface Difference
Before comparing records, systems often normalise case, punctuation, whitespace, abbreviations, dates, phone formats and character encodings.
Normalisation should remove irrelevant variation without erasing distinctions that matter. Over-normalisation can turn different records into misleadingly similar strings.
5. Blocking Reduces the Search Space
Comparing every record with every other record becomes expensive at scale.
Blocking groups plausible candidates using coarse keys such as postcode, surname prefix, organisation or date range. Detailed comparison then happens only inside those candidate sets.
The risk is recall: if a true match lands in different blocks, the later matcher never gets a chance to recover it.
6. Matching Combines Evidence
A resolver can score evidence from several fields: exact identifier match, fuzzy name similarity, shared phone number, address distance, date compatibility, organisation overlap and relationship consistency.
The score is useful only if the fields are weighted according to their reliability. Shared surname may be weak evidence. Shared verified account identifier may be strong.
7. Missing Data Is Not Negative Evidence
If one record lacks an address, that absence should not be treated as an address mismatch.
Entity resolution needs to distinguish different from unknown. Otherwise incomplete records are systematically split.
8. Relationships Can Resolve Identity
Sometimes the strongest evidence is relational.
Two author records may share the same coauthors, institution and research topic. Two company records may share directors, addresses and subsidiaries. Graph structure can therefore help disambiguate records when names alone are weak.
9. Temporal Logic Prevents Impossible Merges
Time can rule out matches.
A person cannot usually hold two incompatible birth dates. A company cannot use an address before the company exists. One physical asset cannot simultaneously occupy distant locations unless the data describes different times.
Temporal consistency turns entity resolution into a state-history problem, not merely a string-matching problem.
10. Human Review Belongs Near the Decision Boundary
High-confidence matches can be automated. Clear mismatches can be rejected. Ambiguous cases deserve review when the consequence of error is high.
The review interface should expose the evidence that drove the score rather than presenting a mysterious “89% match.”
11. Resolution Decisions Need Provenance
When records are merged, the system should record why, when and under which rules the merge occurred.
That allows later correction if new evidence shows the merge was wrong.
Entity resolution should therefore be reversible where operationally possible.
12. Worked Example: Library Authors
A catalogue contains “J. Smith,” “John Smith” and “John A. Smith.” Shared title history, publisher, subject and identifiers can help determine whether these records represent one author or several.
The library-specific owner How Library Authority Control Works handles the canonical-name side of this problem.
13. Worked Example: Customer Records
A bank acquires another institution and receives a second customer database.
Names, addresses and phone numbers overlap imperfectly. Some customers appear in both systems. Resolution must identify true overlaps without merging family members who share an address or people with common names.
14. Worked Example: Places
“Punggol,” “Punggol New Town,” planning-area boundaries, postal addresses and historical place names can refer to overlapping but not identical geographic entities.
Place resolution therefore needs spatial boundary, time and administrative context rather than text matching alone.
15. Worked Example: News and Public Figures
A news system ingests articles mentioning people with similar names. Attaching the wrong biography to the wrong person is a high-cost false merge.
Organisation, role, geography, date and co-mentioned entities provide contextual evidence that improves identity resolution.
16. Entity Resolution and Privacy
Linking records can reveal information no single dataset contained visibly.
That makes entity resolution powerful and privacy-sensitive. Systems should limit matching to legitimate purposes, control access to resolved identities and avoid constructing unnecessary profiles merely because data can technically be linked.
17. An Entity-Resolution Checklist
- Define the entity type and decision consequence.
- Identify strong identifiers and their scope.
- Normalise surface variation carefully.
- Use blocking without destroying recall.
- Combine multiple evidence fields.
- Distinguish missing from conflicting data.
- Use relationship and temporal consistency where useful.
- Set review thresholds according to error cost.
- Record merge provenance and permit correction.
- Protect privacy and purpose boundaries.
18. Read the Mechanism Forward, Backward and Sideways
Forward: records → normalisation → candidate blocking → evidence comparison → merge, split or review → canonical identity. Backward: start from a wrong profile and identify which evidence caused the false merge. Sideways: compare librarian, database engineer, investigator, privacy owner and receiver. Each values a different balance between recall and mistaken identity.
19. The Civilisation Lesson
Civilisation produces records faster than it produces stable identities. People move, organisations rename themselves, addresses change and systems create local identifiers.
Entity resolution is how information infrastructure tries to keep one continuing thing coherent across those changing representations without erasing real difference.
Entity resolution is the disciplined answer to a deceptively simple question: are these different records different things, or different shadows cast by the same thing?
Continue through How Metadata Works, How Library Authority Control Works and the master How X Works hub. Next: controlled vocabularies — how shared terminology keeps classification coherent across people and systems.