Two records say “A. Rahman”. One gives a 1988 birth year and an old address. The other says “Abdul Rahman”, gives a full date of birth and a new address. Are they the same person?
A computer can compare strings in milliseconds. The difficult part is deciding what a similarity means. Names change. Addresses move. Dates contain typos. Identifiers are missing. Families share surnames. Businesses merge. Publications acquire new editions. A wrong link can combine two lives; a missed link can split one history into fragments.
Record linkage and entity resolution are methods for deciding which records refer to the same underlying entity and which do not. They use identifiers, attributes, probabilities, rules, machine learning and human review to reconstruct identity across imperfect data. The output is not merely a joined table. It is a claim about sameness, with error, provenance and privacy consequences.
This article owns the general methodological problem. Administrative Registers owns public-record infrastructure. Persistent Identifiers owns durable identifier systems. Master Data owns organisational canonical records. Knowledge Graphs owns graph representation. Human-participant research ethics and data privacy own the conditions under which identifiable human data may be used. Linkage sits between them.
The linkage evidence loop
LINKAGE QUESTION → DEFINE ENTITY + TIME BOUNDARY → INVENTORY SOURCES + RIGHTS → PROFILE IDENTIFIERS + ATTRIBUTES → STANDARDISE WITHOUT ERASING SOURCE → GENERATE CANDIDATE PAIRS → COMPARE FIELDS → SCORE OR CLASSIFY → RESOLVE CONFLICTS → REVIEW UNCERTAIN CASES → EVALUATE FALSE LINKS + MISSED LINKS → PROPAGATE LINKAGE UNCERTAINTY → CREATE VERSIONED LINKAGE OUTPUT → DOCUMENT PROVENANCE → USE DOWNSTREAM → CHECK FOR LINKAGE BIAS → CORRECT + RE-LINK WHEN SOURCES CHANGE
The final steps matter because linkage is not finished when two rows are joined. A linked dataset becomes a new information asset. Its quality and sensitivity can differ from either input.
1. A row is not an entity
A row is one representation of something at some time. A person may appear in a school register, survey, library membership file and historical address table. A company may appear under its legal name, trading name and former name. A book may appear as a work, edition, manifestation and individual copy.
Entity resolution asks which of these representations belong to one underlying identity. That is an ontological question before it becomes a technical one.
See When Are Two Things the Same Thing? for the deeper identity boundary.
2. Define the entity before defining a match
“Same school” can mean the same legal institution, campus, operating site, historical organisation or current administrative unit. “Same publication” can mean the same intellectual work or the same edition.
A linkage system cannot repair an undefined object. Write the entity type, identity rule and temporal boundary before matching.
3. Unique identifiers make linkage simpler—but only when they are trustworthy
If both datasets carry the same stable, correctly recorded unique identifier, linkage can be a direct equality operation. This is one reason identifier infrastructure is so valuable.
But identifiers can be missing, duplicated, recycled, mistyped or assigned at different entity levels. A household ID is not a person ID. An ISBN identifies an edition or format, not necessarily an abstract work. A company registration identifier may not survive a merger in the way a business historian expects.
Use How Persistent Identifiers Work for durable identifier design.
4. Identity fields have different evidential strength
Name, date of birth, address, phone number, email and organisation can all support linkage. They differ in stability, uniqueness, missingness and error patterns.
A rare full name plus exact birth date may be strong evidence. A common surname plus city may be weak. An old address disagreement may be expected if people move. A date-of-birth disagreement may be more serious—or simply a transposed digit.
Good linkage models field behaviour rather than treating every agreement as equally informative.
5. Standardisation improves comparability without creating truth
Before comparing records, systems often standardise case, punctuation, whitespace, dates, telephone formats and address components. “21 Jln Besar” and “21 Jalan Besar” may become easier to compare after normalisation.
Never overwrite the source representation merely because a standard form is convenient. Preserve the original and record the transformation. Standardisation is a derived view.
The U.S. Census Bureau’s Statistical Quality Standard C4 explicitly includes standardisation of linking variables among the specifications that automated record-linkage systems may need.
6. Cleaning and linkage should remain distinguishable
Correcting an impossible date after checking an authoritative source is data cleaning. Deciding that two slightly different names refer to the same person is linkage. Both can occur in one pipeline, but their evidence and audit trails differ.
If a matching algorithm silently “corrects” source fields to make a link possible, later users may be unable to reconstruct what evidence actually existed.
7. Deterministic linkage uses explicit rules
A deterministic rule might say: link records when national identifier agrees exactly, or when full name, date of birth and postal code all agree.
Rules are transparent and can perform extremely well when data is standardised and high-quality. They can also be brittle when minor spelling differences, missing fields or historical changes are common.
A cascade of rules can use strongest evidence first and weaker combinations later. The order and conflict policy should be documented.
8. Exact matching can have high precision and low recall
Requiring exact agreement on several fields may produce very few false links while missing many true links affected by typos or changes. That means high precision can coexist with low recall.
There is no universal best threshold. The cost of a false link and the cost of a missed link depend on the downstream job.
9. Probabilistic linkage weighs patterns of agreement and disagreement
Probabilistic methods recognise that some agreements are more surprising than others. Matching on a rare surname can carry more evidence than matching on a common one. A disagreement on address may be less damaging when address changes frequently.
The classic Fellegi–Sunter framework compares the probability of observing a field-agreement pattern if the pair is a true match with the probability of observing it if the pair is a non-match.
The original paper is Fellegi and Sunter, A Theory for Record Linkage, Journal of the American Statistical Association, 1969.
10. m and u probabilities encode different worlds
For a comparison field, m is the probability of the observed agreement pattern given that the records truly match. u is the probability of that agreement pattern given that they do not match.
If exact birth-date agreement occurs for nearly all true matches but only rarely among random non-matches, it is powerful evidence. If city agreement is common among both matches and non-matches, it contributes less.
11. A linkage weight is evidence, not identity
In a simple Fellegi–Sunter formulation, an agreement can contribute a log weight proportional to log(m/u), while a disagreement contributes log[(1−m)/(1−u)]. The scores across fields are combined.
A high weight indicates that the observed pattern is much more characteristic of matches than non-matches under the model. It is not a metaphysical probability that two people are “the same” unless additional modelling justifies such a probability interpretation.
12. Estimating linkage parameters is itself an inference problem
m and u probabilities may come from labelled training pairs, known identifiers, clerical review, expectation–maximisation or other estimation strategies.
The Office for National Statistics working paper on standard data-linkage tools describes using the expectation–maximisation algorithm to estimate m and u probabilities for probabilistic linkage.
Parameter uncertainty should not disappear merely because the final system emits one score.
13. Candidate generation prevents impossible all-to-all comparison
Two files with one million records each contain one trillion possible cross-file pairs. Comparing every pair in depth can be computationally wasteful.
Candidate generation narrows the search to plausible pairs. Blocking might compare only records sharing birth year, postcode prefix or phonetic surname code. More modern systems can use approximate-nearest-neighbour retrieval or learned representations.
Blocking improves scale but creates a new failure mode: if a true match never enters the candidate set, no later classifier can recover it.
14. Blocking recall belongs in the quality audit
A linkage team can build an excellent classifier over candidate pairs while missing many true matches at the blocking stage. Evaluate the complete pipeline, not only the final classifier.
The ONS tools paper treats candidate-link generation as an essential stage of the probabilistic pipeline, alongside metadata generation and weight estimation.
15. String similarity is not semantic identity
Edit distance, Jaro–Winkler similarity, token overlap and phonetic encodings can recognise spelling variations. “Mohamad” and “Mohammad” may look similar. “John Smith” and “John Smith” are identical strings.
Neither result proves identity. String metrics supply comparison features whose meaning depends on the population and accompanying evidence.
16. Exact disagreement can be less important than contextual agreement
A person’s surname may change after marriage. An address may differ because one record is five years older. A business may move headquarters.
Temporal information can turn apparent contradiction into expected evolution. A linkage model that ignores time can penalise legitimate changes.
17. Temporal identity needs valid-time logic
Linking a historical register to a current database requires asking whether attributes were true at compatible times. An address recorded in 2015 should not be expected to match an address from 2026 exactly.
Store observation date, valid-from and valid-to fields where available. Identity persists through some changes; attributes do not.
18. Thresholds turn scores into operational decisions
A probabilistic system often defines a high threshold above which pairs are accepted as links, a low threshold below which pairs are rejected, and an uncertain region for review.
Moving the threshold trades false positives against false negatives. The right point depends on downstream consequences and the prevalence of true links among candidate pairs.
19. Clerical review is a model component, not a shameful fallback
Ambiguous cases can require trained human judgement. A reviewer may inspect contextual fields, historical records or source images unavailable to the automated system.
The Census Bureau’s Standard C4 explicitly covers automated and clerical record linkage and calls for documented criteria, staff training, testing and quality control.
Human review itself needs reliability monitoring. Different reviewers can disagree.
20. Review instructions should define escalation
A reviewer should know what constitutes sufficient evidence, which fields can override others, when to refer a case and when to leave identity unresolved.
Forcing every case into match or non-match can turn honest uncertainty into fabricated certainty.
21. False positives combine entities that should remain separate
A false-positive link says two records belong to one entity when they do not. For a person, this can combine health, education, financial or administrative histories incorrectly. For a business, it can merge transactions from separate firms.
False positives can create invented biographies and invented correlations.
22. False negatives split one entity into fragments
A false negative misses a true link. The same person may appear as two people, breaking a longitudinal history. A customer can appear to be new when they are returning. An author can receive two profiles.
The cost differs from false positives but can be equally consequential.
23. Precision asks whether accepted links are correct
Precision is the proportion of accepted links that are true matches in the evaluated set. High precision means relatively few false-positive links.
The ONS Data Linkage and Matching Policy explicitly requires linkage quality to be assessed with false-positive and false-negative errors and states that precision and recall should be reported.
24. Recall asks how many true links were found
Recall is the proportion of all true matches that the linkage process successfully identifies. High recall means relatively few false negatives.
A conservative threshold can raise precision while reducing recall. A permissive threshold can raise recall while introducing more false positives.
25. Match rate is not linkage quality
A system that links 95% of records may look impressive. It could also be wrong frequently. Another system may link only 70% but be extremely precise.
ONS explicitly warns that match rates indicate the quantity of matches, not their quality, and should not be used as a quality metric by themselves.
This is one of the most important lessons in the field: coverage and correctness are separate dimensions.
26. A gold standard is rarely pure gold
Evaluation requires knowing, or approximating, which pairs truly match. A trusted unique identifier can provide labels for some cases. Clerical review can create labels for others.
But identifiers contain errors and reviewers disagree. Evaluation data therefore needs its own quality controls.
27. Evaluation samples must represent the difficult cases
If a validation sample contains mostly easy exact matches and obvious non-matches, reported performance can look excellent while the ambiguous operational region remains untested.
Stratify evaluation across score ranges, missing-data patterns, common names, rare groups, languages and other conditions relevant to deployment.
28. Pairwise accuracy is not the same as entity accuracy
Suppose A matches B and B matches C, but A and C conflict on date of birth. Pairwise decisions now create an entity cluster with an internal contradiction.
Entity resolution must decide how pairwise evidence becomes groups. Transitivity constraints, cluster optimisation or graph methods may be needed.
29. Transitivity can propagate one bad link
If linkage declares A=B and B=C, a system may infer A=C. When one edge is false, an entire cluster can merge incorrectly.
Audit cluster structure, not only individual pairs. High pairwise precision can still permit consequential entity-level failures in large clusters.
30. One-to-one, one-to-many and many-to-many are different problems
A person may have multiple addresses. A household can contain multiple people. A business can have multiple branches. A publication can have multiple authors.
Do not impose a one-to-one matching constraint merely because the software defaults to it. The cardinality belongs to the entity relationship.
31. Deduplication is linkage within one dataset
Deduplication asks whether multiple records inside the same source represent one entity. It uses many of the same tools as cross-file linkage.
The Census Bureau’s Person Identification Validation System supports linking across files and un-duplicating files through probabilistic person matching.
32. Deduplication can erase legitimate repeated events if the object is wrong
Two identical transactions may be duplicates—or two genuine purchases. Two survey responses may be duplicate submissions—or repeated measurements at different times.
Deduplicate entities only after separating entity identity from event identity.
33. Entity resolution often creates a canonical or master record
After clustering records, systems may choose a surviving name, address or identifier for a master record. That is a second operation after linkage.
“Most recent value wins” may be appropriate for a current address and wrong for a legal birth name. “Most frequent value wins” can preserve a repeated error.
Survivorship rules belong to Master Data and Reference Data and should retain source provenance.
34. Linkage provenance should preserve every contributing source
A canonical record should not make its source records disappear. Preserve source IDs, source-system names, observed values, transformations, linkage method, score, review status and linkage version.
Use Metadata and Data Lineage for the wider provenance architecture.
35. Linkage error can bias downstream statistics
Suppose records with common names are more likely to be linked incorrectly, while migrants with changing addresses are more likely to be missed. The linked sample can become selectively distorted.
A regression or population estimate run afterward may then inherit linkage error. Treating linkage as a perfect preprocessing step understates uncertainty.
36. Unlinked records are data, not waste
Compare linked and unlinked records on available characteristics. If linkage success varies by age, geography, language or socioeconomic status, the linked dataset may represent some groups better than others.
Do not delete unlinked cases before asking what their absence means.
37. Linkage failure can become a missing-data mechanism
If an outcome is obtained only by linking to another file, failed linkage makes that outcome missing. The probability of missingness can depend on identity-data quality and on characteristics related to the outcome.
The downstream analyst should know which outcomes were directly observed, which were linked and which remained unlinked. Route to How Missing Data Analysis Works.
38. Linkage uncertainty should propagate when it matters
A hard threshold turns uncertain scores into binary links, which is operationally convenient. For some analyses, retaining alternative plausible linkages or probabilistic weights can better reflect uncertainty.
Methods such as multiple linkage, Bayesian linkage or joint linkage-analysis models attempt to propagate uncertainty. Their suitability depends on the research problem and software validation.
39. Sequential linkage can make order matter
Some systems first link high-confidence exact matches, remove them, then probabilistically link the remainder. Others combine all rules in one model.
Order can change the remaining candidate pool and therefore later links. ONS policy notes that each new linkage project creates a new pattern of matching errors even if constituent datasets have been linked elsewhere before.
40. Longitudinal linkage is a moving-target problem
Following people or organisations through years requires handling name changes, relocations, deaths, mergers, splits and new identifiers.
Current ONS work on longitudinal census linkage illustrates that linkage completeness itself is an object of measurement rather than a hidden technical constant.
41. Address linkage can require geospatial reasoning
Addresses contain unit numbers, building names, street abbreviations, postal codes and historical changes. Geocoding can convert textual locations into spatial evidence, but a coordinate is not automatically a household identity.
Use How Maps and Geospatial Evidence Work for coordinate and geocoding fundamentals.
42. Organisational linkage must account for mergers and subsidiaries
Companies can change names, merge, spin off divisions or operate many brands. “Same business” may depend on legal entity, economic enterprise or brand.
A good organisational resolver stores the relationship—parent, subsidiary, predecessor, successor—rather than forcing every related organisation into one identity.
43. Publication linkage needs work–edition–author distinctions
Bibliographic systems resolve authors, titles, editions, publishers, DOIs and citation strings. A DOI can identify a particular scholarly object while an ORCID identifies a researcher.
Linking “J. Lee” citations to one author without considering affiliation, co-authors and topic can merge different researchers.
Use Citations, References and Scholarly Linking for the research-graph owner.
44. Knowledge graphs need resolved identity before edges become trustworthy
If two names for the same organisation are treated as separate nodes, its relationships fragment. If two different organisations are merged, unrelated edges become attached to one node.
Entity resolution therefore sits upstream of many graph-quality problems. See Knowledge Graphs and Semantic Data.
45. Machine learning can learn comparison patterns
Supervised classifiers can use name similarity, address similarity, date differences and other features to classify candidate pairs. Gradient-boosted trees, neural networks and embedding models can capture interactions more flexibly than hand-built rules.
They still require reliable labels, representative training data and calibrated thresholds. A powerful classifier trained on one naming culture may perform poorly in another.
46. Embeddings improve retrieval but can blur identity
Semantic embeddings can retrieve records that are textually different but conceptually similar. That helps candidate generation for organisations, products or publications.
Similarity is not sameness. Two competing companies can have extremely similar descriptions. An embedding should generate evidence or candidates, not silently define identity.
47. Active learning can spend human review where it matters most
An active-learning system can send uncertain or information-rich pairs to reviewers, then retrain the classifier. This can reduce labelling cost.
But repeatedly labelling only ambiguous cases changes the training distribution. Preserve an evaluation sample that represents the operational population.
48. Domain shift changes linkage behaviour
A model trained on contemporary Singapore addresses may not work on nineteenth-century place names. A resolver trained on English personal names may perform unevenly across naming systems.
Evaluate by language, time period, geography and other relevant subgroups. Performance averages can hide systematic failure.
49. Fairness matters because identity error can be unequally distributed
People whose names change more often, whose addresses are unstable, whose records use transliteration or whose communities contain common name structures may experience different linkage errors.
Measure subgroup precision and recall where lawful and appropriate. A high overall score does not guarantee equitable performance.
50. Privacy risk can increase after linkage
A school dataset may know attendance. A survey may know family circumstances. Linking them creates a richer profile than either holder possessed before.
ONS policy explicitly treats linked data as newly created information assets and places linkage within data ethics and security governance. The ethical question is not only whether a match is accurate but whether the linked asset should exist and who may use it.
51. Pseudonymous keys reduce exposure but do not erase governance
The Census Bureau describes a controlled process in which personally identifying information is used inside a restricted environment to probabilistically link incoming records to a reference file, after which a protected identification key can support later analysis.
See the Census Bureau’s Data Ingest and Linkage documentation.
Replacing PII with a key can reduce routine exposure. It does not make the linked dataset ethically consequence-free.
52. Privacy-preserving record linkage has trade-offs
Techniques such as cryptographic encodings, secure multiparty computation and privacy-preserving comparison aim to link records without revealing raw identifiers across organisations.
These approaches can reduce disclosure but may lose matching information, introduce new attack surfaces or complicate error analysis. “Encrypted matching” is not a substitute for legal authority, data minimisation and governance.
53. Human research linkage needs an ethical basis as well as a technical method
Linking education, behavioural or participant datasets can create research questions beyond the original collection. Consent, waiver, lawful basis, institutional approval and privacy safeguards may need review.
Use How Human-Participant Research Ethics Work for the general participant-ethics owner and Data Security and Privacy for information protection.
54. Minimal-access architectures reduce identity exposure
Not every analyst who uses a linked dataset needs access to raw names and addresses. Separate linkage functions from analysis functions where feasible. Give each role only the data needed for its job.
This is both a privacy principle and a systems-design principle.
55. Linkage needs a reproducible specification
Record input file versions, preprocessing, field mappings, blocking rules, comparison functions, model parameters, thresholds, review rules and software versions.
Census Standard C4 requires documentation sufficient to replicate and evaluate linkage operations, including programs, parameters, problems and evaluation results.
56. A linkage run should have an edition identity
Run 2026-09 with source files A-v3 and B-v5 is a different linkage object from run 2027-01 after addresses and identifiers change.
Preserve a run ID, timestamp, source versions, model version and output identifier. Do not silently overwrite old links when the resolver is updated.
57. Corrections should propagate without erasing history
If a source corrects a birth date or a reviewer finds a false link, mark the affected entity cluster for re-evaluation. Record the old and new linkage state.
A correction should improve the current representation without pretending the earlier linked dataset never existed.
58. Linkage systems need monitoring after deployment
Name distributions change. Address formats change. New source systems arrive. A classifier’s precision and recall can drift even when the code is unchanged.
Monitor match rates as an operational signal, but separately monitor quality through labelled review or other validated estimates.
59. Scaling changes the base-rate problem
When candidate space becomes enormous, non-matches vastly outnumber true matches. Even a small false-positive rate can produce many incorrect links.
Blocking, thresholds and precision therefore become increasingly important at scale. Evaluate counts of expected errors, not only percentages.
60. A worked pairwise example
| Field | Record A | Record B | Comparison |
|---|---|---|---|
| Name | Nur Aisyah Bte Ali | Nur Aisyah Ali | Strong similarity |
| Date of birth | 14-03-2008 | 14-03-2008 | Exact agreement |
| Postal code | 540123 | 540321 | Disagreement |
| Mobile | 9123 4567 | 9123 4567 | Exact agreement |
| Record dates | 2024 | 2026 | Two-year interval |
A deterministic rule may accept the pair because birth date and phone agree. A probabilistic model may assign strong positive weights to those fields, moderate evidence to the name and a negative weight to the postal-code disagreement. A reviewer may note that the two-year interval makes an address change plausible.
None of these steps proves identity in isolation. The final decision depends on the validated linkage system, field error rates and downstream threshold.
61. A worked precision–recall example
Suppose a labelled evaluation set contains 1,000 true matching pairs. The system accepts 950 links, of which 900 are true matches and 50 are false positives. It therefore found 900 of the 1,000 true matches.
Precision = 900 / 950 ≈ 94.7%.
Recall = 900 / 1,000 = 90%.
There are 100 missed true links. Reporting only “950 records matched” conceals both types of error.
62. A match-rate target can create perverse incentives
If staff are rewarded only for increasing the percentage of records linked, they can lower thresholds and create false positives. If rewarded only for avoiding false positives, they can leave difficult cases unresolved and destroy recall.
Quality governance needs balanced metrics tied to real downstream harm.
63. Confidence should travel with the link
Where downstream systems can use it safely, retain link method, score, confidence category and review status. A high-confidence exact-ID link and a borderline probabilistic link should not become indistinguishable merely because both receive the same entity ID.
Consumers can then apply stricter thresholds for high-consequence uses.
64. But a score without calibration can mislead
A similarity score of 0.92 does not necessarily mean a 92% probability of correct identity. It may simply be a normalised model output.
If probability language is used, validate calibration against representative labelled data.
65. A linkage audit should work backwards
DOWNSTREAM CLAIM → LINKED DATASET → ENTITY ID / LINK TABLE → LINK DECISION → SCORE / RULE / REVIEW → COMPARISON FEATURES → STANDARDISED VALUES → RAW SOURCE RECORDS → SOURCE AUTHORITY + TIME → REAL ENTITY
The audit route should remain available after publication. If the final claim cannot be traced back through the linkage decision, an important part of the evidence chain is missing.
66. A practical pre-linkage checklist
- Define the entity and temporal identity rule.
- State why linkage is needed.
- Confirm authority, rights and privacy basis for each source.
- Inventory unique identifiers and attribute quality.
- Profile missingness, duplication and formatting.
- Preserve raw source values.
- Design standardisation rules.
- Choose deterministic, probabilistic, ML or hybrid strategy.
- Define candidate-generation rules and blocking recall checks.
- Define thresholds and uncertain-review region.
- Prepare representative evaluation data.
- Define false-positive and false-negative consequences.
- Version code, parameters and sources.
- Define output provenance and confidence fields.
- Define correction and re-link triggers.
67. A practical post-linkage checklist
- Report precision and recall or justified equivalents.
- Report match rate separately from quality.
- Inspect performance by relevant subgroups and data conditions.
- Inspect unlinked records.
- Audit large or contradictory entity clusters.
- Record clerical-review error and disagreement where relevant.
- Quantify linkage uncertainty that can affect downstream inference.
- Preserve source and linkage provenance.
- Protect the newly linked asset according to its increased sensitivity.
- Document the exact linkage run used by downstream analysis.
68. The Library ownership boundary
This article owns the methodological bridge from imperfect records to resolved entity identity. It crosswalks adjacent owners without absorbing them.
- Administrative Registers and Record Systems owns institutional record infrastructure.
- Persistent Identifiers owns durable identifier systems.
- Master Data and Reference Data owns canonical organisational records and survivorship.
- Knowledge Graphs and Semantic Data owns graph representation.
- Data Integration and Interoperability owns system-to-system exchange.
- Data Quality owns general accuracy, completeness, consistency and timeliness.
- Data Security and Privacy owns information protection.
- Human-Participant Research Ethics owns participant-level ethical governance.
69. What a learner should remember
Entity resolution is not “fuzzy join until the rows fit”. It is a disciplined identity claim. Strong linkage defines the entity, preserves source evidence, compares fields according to their information value, evaluates false links and missed links, protects privacy, carries uncertainty downstream and keeps a route back to the original records.
The most useful question is simple: what evidence would convince us these two records are one thing—and what evidence would convince us we accidentally merged two things that should remain separate?
Sources and further reading
Authoritative public sources were checked for this edition in September 2026. Operational linkage involving protected personal data requires the current legal, institutional and security framework for the relevant jurisdiction.
- Office for National Statistics, Data linkage and matching policy.
- Office for National Statistics, Developing standard tools for data linkage: February 2021.
- U.S. Census Bureau, Statistical Quality Standard C4: Linking Data Records.
- U.S. Census Bureau, Record Linkage and the Person Identification Validation System.
- U.S. Census Bureau, Data Ingest and Linkage.
- Fellegi and Sunter, A Theory for Record Linkage, 1969.
Continue through eduKate: Persistent Identifiers → Administrative Registers → Master Data → Knowledge Graphs → Research Collections Directory.