Entity resolution decides whether separate records, such as a CRM account and a billing customer, describe the same real-world company. Atlan gives every data asset a unique identity, a GUID and a qualifiedName, and serves it to agents over MCP. For customer and supplier records, keep each match as its own record with its evidence, and hold back owl:sameAs until the match is certain.
An ontology tells an agent what a Customer is. Entity resolution tells it which records are the same customer. In OWL, the statement “these two names are one thing” is owl:sameAs. A reasoner, the software that derives new statements from an ontology’s rules, treats it as transitive and copies every statement between the two names.
An agent working in the enterprise context layer needs both answers, and the evidence behind each match. Matching never finishes, because the sources feeding the context graph keep changing.
| What it is | Deciding which records describe the same real-world entity, and what each match becomes |
| Also called | Record linkage, de-duplication |
| Core steps | Standardize, block, score pairs, cluster, decide |
| Output | Match records, clusters, or a merged golden record |
| Why ontologies care | With a reasoner running, owl:sameAs is transitive and each assertion copies statements between names |
| Classic formal model | Fellegi and Sunter, Journal of the American Statistical Association, 1969 |
| Where it lands | Merges in the operational system of record; match records and provenance in the graph |
What is entity resolution?
Entity resolution is the process of finding records that refer to the same real-world entity, within or across datasets, and deciding what to do about each match. According to Binette and Steorts (arXiv, 2022), the work is “commonly known as record linkage, de-duplication, or entity resolution,” with roots in “foundational work that began in the 1940’s and 50’s.” The standard probabilistic model came from Fellegi and Sunter (JASA, 1969).
The database, semantic Web, and machine learning communities have each proposed entity resolution methods, according to a survey of end-to-end entity resolution (Christophides et al., arXiv, 2020).
Keep two things apart. A record is a row in one system; an entity is the company or person it describes. Entity resolution links records to entities, and two rows stay two rows.
One naming trap: schema.org V30.1 (2026) defines its sameAs as the “URL of a reference Web page that unambiguously indicates the item’s identity.” It points to a web page and carries none of OWL’s reasoning rules.
Where entity resolution shows up
The classic case is one company under three IDs in CRM, billing, and support. Operational teams resolve these into a single golden record in the system of record, which is where master data management fits.
Investigators run entity resolution in fraud and financial-crime graphs. Document pipelines use entity linking in documents to tie a name in a contract to a known party.
How does entity resolution work?
A typical entity resolution pipeline runs five steps: standardize the records, block them into candidate groups, score pairs, cluster the matches, and decide whether to link or merge. Standardizing makes “ACME HOLDINGS LIMITED” and “Acme Holdings Ltd” compare cleanly.
Blocking saves work: only records that share a cheap key get compared. Papadakis et al. (arXiv, 2020) note that “efficiency techniques are an integral part of Entity Resolution, since its infancy.” Scoring then uses rules, the Fellegi-Sunter probabilistic model, or machine learning.
Clustering is where errors compound. If A matches B and B matches C, a simple clustering step puts A and C together, with no OWL anywhere in the stack. Cap cluster size, and review any record that bridges two clusters.
Entity resolution is stage four of the five stages of knowledge graph construction. Merge into a golden record in the operational store; keep the match records and their evidence in the graph.
How do you know the matches are right?
Label a sample of candidate pairs by hand, then compute precision (the share of proposed matches that are correct) and recall (the share of true matches found). The two pull against each other, so decide which error your use case can least afford.
Set two thresholds. Matches above the upper one are approved. Matches below the lower one are dropped. A steward reviews the band in between, and each decision becomes a labeled example for the next run. Re-sample when a source or a rule changes.
What the 2023-2024 LLM research showed
Peeters, Steiner, and Bizer (arXiv, 2024) found the best LLMs “require no or only a few training examples to perform comparably to PLMs that were fine-tuned using thousands of examples.” They also found “there is no single best prompt,” so prompts need tuning per model and dataset.
| Aspect | Rules and probabilistic (Fellegi-Sunter, 1969) | Fine-tuned language models (Ditto, 2020) | Generative LLMs (Peeters et al., 2023-2024) |
|---|---|---|---|
| Training data needed | Hand-written rules or match weights | Labeled pairs for fine-tuning; Peeters et al. compare against PLMs “fine-tuned using thousands of examples” | “No or only a few training examples” |
| Unseen entities | Depends on how far the rules reach | Weaker on unseen entities than the best LLMs, per Peeters et al. | “Higher robustness to unseen entities” |
| Reported result | n/a | “A high F1 score of 96.5%” on company datasets of 789K and 412K records (Li et al., arXiv, 2020) | Comparable to fine-tuned PLMs; “no single best prompt” |
The results come from different datasets, so this is not a head-to-head score. Whichever matcher you use, your team still owns survivorship, provenance, and the identity construct, and data quality for LLMs limits how good the matcher can be.
Why does entity resolution matter for ontologies?
In an ontology, a match becomes an assertion a reasoner acts on. According to the OWL 2 Primer (W3C, 2012), “OWL does not make the assumption that different names are names for different individuals,” so declaring two names the same lets a reasoner apply facts about one to the other.
The OWL 2 Structural Specification (W3C, 2012) says an individual equality axiom (owl:sameAs in RDF) “states that all of the individuals … are equal to each other.” Under the OWL 2 RL rules (W3C, 2012), that link is transitive, and every statement about one name is copied to the other.
This happens only when an OWL reasoner, or a query engine that honors owl:sameAs, runs over the graph. When one does, a bad match spreads into how agents use an ontology at query time and into every answer built on grounding agents in an ontology. Without a reasoner, a bad match still causes a wrong join, but it stays where it was written.
On the public web, one corpus published as VU Amsterdam’s sameAs.cc dataset (2018) “contains 558,943,116 distinct owl:sameAs statements.” A survey on identity in the web of data (Raad et al., arXiv, 2019) starts from earlier work showing that “identity in the Web is broken.” Both describe the open web, and the count measures how widely owl:sameAs is used; it says nothing about how often it is wrong.
In any knowledge graph that agents read, including knowledge graphs built for AI agents, review an identity assertion the way you review a schema change.
A worked example: three records, two companies
Three synthetic rows describe “Acme.” Two are the same company; the third is a retail subsidiary with a similar name and the parent’s switchboard number. Each row stays an ex:SourceRecord. Each proposed pair gets an ex:MatchRecord. Each real company gets a cluster IRI, the web identifier the graph uses as that company’s name.
@prefix ex: <https://example.org/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
# Source records: rows from three systems, not companies
ex:crm-A-4471 a ex:SourceRecord ;
ex:legalName "Acme Holdings Ltd" ;
ex:phone "+44 20 7946 0000" .
ex:billing-4471 a ex:SourceRecord ;
ex:legalName "ACME HOLDINGS LIMITED" ;
ex:phone "+44 20 7946 0000" .
ex:support-T-982 a ex:SourceRecord ;
ex:legalName "Acme Holdings Retail Ltd" ;
ex:phone "+44 20 7946 0000" .
# Match records: one per proposed pair, with evidence; no identity asserted
ex:match-001 a ex:MatchRecord ;
ex:recordA ex:crm-A-4471 ;
ex:recordB ex:billing-4471 ;
ex:score "0.97"^^xsd:decimal ;
ex:method "normalized name + phone" ;
ex:status "approved" ;
ex:reviewedAt "2026-11-01T14:20:00Z"^^xsd:dateTime ;
prov:wasAttributedTo ex:steward-01 ;
prov:wasGeneratedBy ex:er-run-2026-11-01 .
ex:match-002 a ex:MatchRecord ;
ex:recordA ex:billing-4471 ;
ex:recordB ex:support-T-982 ;
ex:score "0.71"^^xsd:decimal ;
ex:method "fuzzy name + phone" ;
ex:status "rejected" ; # a retail subsidiary, a different company
ex:reviewedAt "2026-11-01T14:25:00Z"^^xsd:dateTime ;
prov:wasAttributedTo ex:steward-01 ;
prov:wasGeneratedBy ex:er-run-2026-11-01 .
# Real-world entities: one cluster IRI per resolved company
ex:org-cluster-17 a ex:Organization ;
ex:legalName "Acme Holdings Ltd" ;
prov:wasDerivedFrom ex:crm-A-4471 , ex:billing-4471 .
ex:org-cluster-18 a ex:Organization ;
ex:legalName "Acme Holdings Retail Ltd" ;
prov:wasDerivedFrom ex:support-T-982 .
ex:crm-A-4471 ex:describes ex:org-cluster-17 .
ex:billing-4471 ex:describes ex:org-cluster-17 .
ex:support-T-982 ex:describes ex:org-cluster-18 .
# Tripwire: a later owl:sameAs between the two clusters makes the ontology inconsistent
ex:org-cluster-17 owl:differentFrom ex:org-cluster-18 .
The block is plain Turtle with no named graphs. At load time, put each run’s match records (here, run ex:er-run-2026-11-01) in their own named graph, so a bad run can be dropped as one unit. An agent asking about ex:org-cluster-17 follows ex:describes back to its two source rows: one extra hop per query, and every match stays reversible.
The failure the example prevents. Suppose the matcher had written owl:sameAs for every pair scoring above 0.7. Both pairs qualify, so a reasoner would chain all three rows into one individual and copy “Acme Holdings Retail Ltd” onto the CRM record. An agent asked for Acme Holdings’ open tickets would also return the subsidiary’s.
A key does the same with no matcher involved. Declare ex:SourceRecord owl:hasKey ( ex:phone ), and the OWL 2 RL key rule derives owl:sameAs between all three rows, because they share one switchboard number. Declaring ex:phone an owl:InverseFunctionalProperty instead is not valid OWL 2 DL, which allows that only on object properties, and the OWL 2 RL rules would still derive the same merges.
Link, assert, or merge: which identity construct should you use?
Each construct makes a reasoner do something different. The table draws on the OWL 2 Structural Specification, the OWL 2 Primer and Profiles, the SKOS Reference (W3C, 2009), PROV-O (W3C, 2013), and PROV-CONSTRAINTS (W3C, 2013).
| Construct | What it says (spec) | Transitive? | Side effects on the two names | Undo cost | Use it when | Source |
|---|---|---|---|---|---|---|
owl:sameAs |
SameIndividual “states that all of the individuals … are equal to each other” | Yes (RL rule eq-trans) | Copies statements in subject, predicate, and object positions (eq-rep-s, eq-rep-p, eq-rep-o) | Depends on the store; answers already served and copies made downstream stay wrong | Identity is certain, reviewed, and holds in every context the graph serves | OWL 2 Structural Specification §9.6.1; OWL 2 Profiles §4.3 Table 4 |
owl:differentFrom |
Two individuals are distinct; with sameAs on the same pair, eq-diff1 yields false (inconsistent) |
n/a | None | Low | A tripwire between cluster IRIs a steward has kept apart | OWL 2 Profiles §4.3 Table 4 |
owl:hasKey |
“each named instance of the class expression is uniquely identified by the set of values which these properties attain”; takes data or object properties | Derived sameAs then chains |
Copies statements through the derived sameAs (RL rule prp-key) |
High, and nobody reviewed the merge | Only on keys that are truly unique and clean, such as an LEI | OWL 2 Primer §6.3; OWL 2 Structural Specification §9.5; OWL 2 Profiles §4.3 Table 5 |
owl:InverseFunctionalProperty |
One value identifies one individual; OWL 2 DL defines it for object properties only | Derived sameAs then chains |
Copies statements through the derived sameAs (RL rule prp-ifp) |
High | Object-valued identifiers; never a literal such as a phone number | OWL 2 Primer §6.1; OWL 2 Structural Specification §9.2.8; OWL 2 Profiles §4.3 Table 5 |
skos:exactMatch |
“a high degree of confidence that the concepts can be used interchangeably across a wide range of information retrieval applications” | Yes (“skos:exactMatch is a transitive property”) | No property copying, but S19, S20, S39, S40 and S42 make both ends skos:Concept |
Medium | Linking concepts across vocabularies (glossary terms), never records | SKOS Reference §8.3, §10 |
skos:closeMatch |
“sufficiently similar that they can be used interchangeably in some information retrieval applications” | No: “not declared to be a transitive property” to avoid “compound errors” | Domain and range skos:Concept (S19, S20 via S39, S40) |
Low | Near-equivalent concepts | SKOS Reference §8.3, §10 |
prov:alternateOf |
“Two alternate entities present aspects of the same thing” | Only under PROV-CONSTRAINTS: “reflexive, transitive and symmetric” (Inferences 16-18); the PROV-O OWL file declares no transitivity | Domain and range prov:Entity, so both ends are typed prov:Entity; no attribute copying |
Low, but clusters still grow under PROV inferences | Two records present aspects of one thing and you accept the prov:Entity typing |
PROV-O; PROV-CONSTRAINTS §5.5 |
Match record (your own ex:MatchRecord with score, method, status, reviewer, time, prov:wasGeneratedBy) |
No identity entailment; a plain resource | No | None for identity; PROV-O domains type it prov:Entity |
Lowest: change status, or drop the run’s named graph |
Default for every proposed match; the audit trail | PROV-O starting-point terms |
Cluster IRI plus your own ex:describes |
A project-owned predicate with no OWL characteristics | No | None | Low: move a record to another cluster | Serving the resolved entity to agents | Modeling practice |
| Physical merge / golden record | Outside RDF: rows collapse into one record via survivorship | n/a | Source values gone unless kept | Highest without lineage | Operational systems that need one record per entity | Binette and Steorts (“canonicalization”) |
A safe default: a match record for every proposed pair, a cluster IRI for each resolved entity, and owl:sameAs only for identity that is certain and true in every context. prov:alternateOf sits in between. A tool that applies the PROV-CONSTRAINTS inferences will chain it the way a reasoner chains sameAs.
Linking and merging work together. Merge in the system of record that needs one row per entity. If your MDM hub keeps a cross-reference from each golden record to its sources, put that crosswalk in the graph too, with lineage back to the source records.
For concepts, the SKOS Reference warns that OWL identity constructs “would typically be inappropriate for linking SKOS concepts in different concept schemes, because the formal consequences that follow could be undesirable.” Glossary concepts belong in SKOS, where taxonomy and ontology meet. Records belong in match records and clusters.
When designing an ontology for AI, pick the identity construct for each class up front, just as operational ontology objects and links get their types before data arrives. Promoting a match record later is cheap. Walking back a sameAs that a reasoner has already used is not.
What is the difference between entity resolution and ontology alignment?
Ontology alignment asks whether two classes or properties mean the same thing; entity resolution asks whether two records describe the same individual. The SKOS Reference draws the line: “owl:sameAs is used to link two individuals… owl:equivalentClass is used to link two classes… owl:equivalentProperty is used to link two properties.”
| Question | Kind of work | OWL/SKOS construct | Who decides | Example |
|---|---|---|---|---|
Is CRM Account the same concept as billing Customer? |
Ontology or schema alignment | owl:equivalentClass, rdfs:subClassOf, skos:exactMatch between glossary concepts |
Ontology owner, domain steward | One class or two? |
| Is CRM record A-4471 the same company as billing record 4471? | Entity resolution | Match record, then a shared cluster IRI or, rarely, owl:sameAs |
Matcher proposes, steward approves | One org or two? |
Is cust_id the same property as account_no? |
Property alignment | owl:equivalentProperty |
Data owner | Join key mapping |
Treat them as two work items with two owners. Class alignment belongs to whoever owns the semantic layer and the business glossary. Record identity depends on data contracts that pin identifiers, because a matcher can only be as stable as the keys it reads.
How to choose survivorship rules and keep provenance
Survivorship is the set of rules that picks which source value wins for each attribute when records combine. Provenance records where each winner came from. Adjust these defaults per domain.
| Attribute type | Default rule | Tie-breaker | Record the winner as | Example |
|---|---|---|---|---|
| Legal identifiers (LEI, tax ID) | Trusted reference source wins | Two different valid identifiers on one cluster: stop and send to a steward | prov:wasDerivedFrom the reference record |
LEI is “a unique 20-character alphanumeric code”; “Every LEI is unique and can represent only one entity” (GLEIF) |
| Legal name | Reference source, then system of record for the domain | Most recent verified | prov:wasDerivedFrom plus timestamp |
Registry name over CRM free text |
| Contact data (phone, email) | Most recent from an operational source | Highest-frequency value | Keep all values with source and time; serve the most recent | Never a match key on its own |
| Commercial attributes (segment, owner) | Owning domain’s system of record | None; flag the conflict | Source system IRI | CRM owns account owner |
| Relationships (parent, subsidiary) | Never inferred from a match; asserted from a reference source | n/a | Separate relationship with source | Parent and child stay two clusters |
| Derived metrics | Recompute on the cluster; never keep a stale copy | n/a | Lineage to inputs | Lifetime revenue |
Record each winner with prov:wasDerivedFrom, which PROV-O defines to include “the construction of a new entity based on a pre-existing entity.” In the example, ex:org-cluster-17 uses it to name the two rows it was built from. With every value tied to its source, AI-ready lineage can show an agent or an auditor why the record says what it says.
A phone number shared by parent and subsidiary is evidence of a relationship, never of identity.
What goes wrong when entity resolution feeds an ontology?
Most of the failures below start the same way: identity gets asserted before anyone checks it. Halpin et al. (ISWC, 2010) describe owl:sameAs as “one point on a scale of similarity, one that is often too strong for many of its current uses.”
| # | Failure mode | Why it happens (mechanism) | Fix | Source for the mechanism |
|---|---|---|---|---|
| 1 | Transitive over-merge: weak pairwise matches chain into one giant cluster | Connected-component clustering chains pairs; with a reasoner, owl:sameAs chains them again (eq-trans) |
Keep machine matches as match records; cap cluster size and review “bridge” records before anything is promoted | OWL 2 Profiles §4.3 Table 4 |
| 2 | Silent identity from keys | owl:hasKey (prp-key) and owl:InverseFunctionalProperty (prp-ifp) derive sameAs with no review step |
Declare owl:hasKey only on clean, truly unique identifiers (LEI-grade); never on email, phone, or address. Keep IFP to object properties |
OWL 2 Profiles §4.3 Table 5; OWL 2 Primer §6.1, §6.3 |
| 3 | Context-dependent identity asserted as universal | sameAs is “one point on a scale of similarity, one that is often too strong for many of its current uses” |
Use a match record and a cluster scoped by context and time; skos:closeMatch for concepts |
Halpin et al., ISWC 2010 |
| 4 | SKOS mapping on instance records | skos:closeMatch and skos:exactMatch have domain and range skos:Concept (S19, S20, S39, S40, S42), so records get typed as concepts |
Use SKOS for glossary concepts, and match records plus clusters for instances | SKOS Reference §8.3, §10 |
| 5 | Conflating class alignment with instance identity | owl:equivalentClass (same class extension) gets used as if it settled record identity, or the reverse |
Two separate work items: alignment (classes, properties) and entity resolution (individuals) | SKOS Reference §10.6.8 |
| 6 | Unmergeable merges | A physical merge drops source values and the reason for the decision | Keep source IRIs, record prov:wasDerivedFrom from each surviving value to its source, and keep match records with method and reviewer |
PROV-O (prov:wasDerivedFrom) |
| 7 | Contradiction instead of correction | Adding owl:differentFrom to a pair already inferred sameAs makes the ontology inconsistent (eq-diff1) |
Retract the source sameAs or drop the run’s named graph, then assert differentFrom |
OWL 2 Profiles §4.3 Table 4 |
| 8 | One-time entity resolution that decays | New sources arrive and the resolved set goes stale | Run entity resolution as a standing process and re-measure precision and recall when a source or rule changes | Judgment, not measured |
Prevention, in order:
- Declare
owl:hasKeyonly on reference-grade identifiers. - Feed rejected match records back to the matcher as negative labels, so it stops proposing them.
- Put
owl:differentFrombetween cluster IRIs a steward has kept apart. If a later key or match derivessameAs, the reasoner reports an inconsistency. - Load each matching run into its own named graph, so one bad run can be dropped whole.
- Retract a bad assertion before you correct it.
- Re-run matching, and re-sample quality, when a source or a rule changes.
Identity errors are one reason enterprise knowledge graphs stall. An active ontology changes as sources change, and match records move with it. The questions to ask an ontology vendor should include how a bad merge is retracted.
How does Atlan keep identity readable for AI agents?
Atlan handles identity for the data assets in its Enterprise Data Graph and serves it, with business meaning, to agents. According to Atlan’s search field reference (Atlan docs), each asset’s GUID is “guaranteed to uniquely identify only a single asset,” and the qualifiedName is “the unique fully-qualified name of any asset in Atlan.”
You can link glossary terms to data assets (Atlan docs), so one term carries its meaning to many tables while each table keeps its own identity. The Asset-term link app (Atlan docs) “connects glossary terms to matching assets automatically” by name and filter. Review what it links the way you would review record matches.
Agents read assets, terms, and lineage through Atlan’s hosted MCP server (Atlan docs), “available on every Atlan tenant,” where Atlan’s agent skills let them “traverse end-to-end lineage, access governed data definitions and glossaries.”
Record-level matching of customers and suppliers runs in your MDM hub or entity resolution pipeline. Once cataloged, the table it writes is an asset like any other, with its own GUID. It can carry lineage to its source tables and links to the terms that define it. Context engineering decides which of that reaches the agent.
The ontology defines the classes; see where the ontology sits in the context layer. Match records and clusters say which individuals are the same. For how the two fit together, read context graph vs ontology and querying the graph from an agent.
A match with evidence can be revisited when a source changes. A silent merge cannot, and the agent reading it has no way to know it happened.
FAQs about entity resolution
1. What is the difference between entity resolution and record linkage?
Mostly a naming difference. Researchers use record linkage, de-duplication, and entity resolution for one job: finding records that describe the same real-world entity. In practice, entity resolution also covers what each match becomes, such as a link or a merge.
2. What is survivorship in entity resolution?
Survivorship is the set of rules that picks which source value wins for each attribute when records for one entity are combined. A legal name might come from a reference registry and a phone number from the newest operational source. Record where each winner came from, so a wrong choice can be reversed.
3. Should I use owl:sameAs for entity resolution?
Only for matches that are certain, reviewed, and true in every context your graph serves. With an OWL reasoner running, owl:sameAs is transitive and copies every statement between the two names, so one weak match spreads. For machine matches, keep match records and attach approved records to a shared cluster IRI.
4. Can an LLM do entity resolution?
Yes, for scoring candidate pairs. A 2024 study found the best LLMs need few or no labeled examples and handle unseen entities better than fine-tuned pre-trained language models. Results depend on the prompt, which needs tuning per model and dataset. The LLM does not set survivorship rules, record provenance, or choose the identity construct. Those stay with your team.
5. What is a golden record, and does a knowledge graph need one?
A golden record is the single merged record an operational system keeps for one entity, built by picking a winning value for each attribute. Operational systems need it. A knowledge graph that agents query does better keeping the source records, the match records between them, and where each value came from, so every answer can be traced.
6. Should I run entity resolution before or after loading the graph?
Run the matching before identity reaches the graph, then load the source records, the match records, and the cluster each record describes. Keep each run in its own named graph so a bad run can be dropped as one unit. Assert owl:sameAs, if at all, only after review.
Sources
OWL 2 Web Ontology Language Primer (Second Edition), W3C
OWL 2 Web Ontology Language Profiles (Second Edition), W3C
SKOS Simple Knowledge Organization System Reference, W3C
PROV-O: The PROV Ontology, W3C
Constraints of the PROV Data Model, W3C
(Almost) All of Entity Resolution, Binette and Steorts, arXiv
The sameAs Problem: A Survey on Identity Management in the Web of Data, Raad et al., arXiv
When owl:sameAs isn’t the Same: An Analysis of Identity in Linked Data, Halpin et al., ISWC 2010
sameAs.cc - Dataset of 558M owl:sameAs statements, VU Amsterdam
A Theory for Record Linkage, Fellegi and Sunter, Journal of the American Statistical Association
End-to-End Entity Resolution for Big Data: A Survey, Christophides et al., arXiv
A Survey of Blocking and Filtering Techniques for Entity Resolution, Papadakis et al., arXiv
Entity Matching using Large Language Models, Peeters, Steiner, and Bizer, arXiv
Deep Entity Matching with Pre-Trained Language Models, Li et al., arXiv
The Legal Entity Identifier (LEI), GLEIF
Common search fields, Atlan docs
Link terms to assets, Atlan docs
