--- title: "What Is Entity Resolution and Why Does It Matter for Ontologies?" url: "https://atlan.com/know/ai-agent/ontology/what-is-entity-resolution/" description: "Learn what entity resolution is, how matching works, and why owl:sameAs, survivorship, and provenance decide what an ontology tells your AI agents." author: "Karthik Pasupathy" author_role: "Contributing Writer, AI Context & Agents" published: "2026-11-02" updated: "2026-11-02" --- ## What is entity resolution and why does it matter for ontologies? Entity resolution is the process of deciding which records, within one dataset or across several, describe the same real-world entity, and what to do about each match. A matcher standardizes records, groups them into candidate blocks, scores pairs, and clusters the results. In an ontology the decision carries further: with a reasoner running, each owl:sameAs copies every statement between two names, so a wrong match spreads. Keeping each match as a record with its evidence lets you review or undo it. Four decisions every entity resolution effort makes: - **Matching:** standardize, block, score, and cluster candidate record pairs. - **Identity construct:** keep a match record, attach records to a cluster IRI, or assert owl:sameAs. - **Survivorship:** choose which value wins per attribute when records merge. - **Provenance:** record the source, method, reviewer, time, and run behind every match. ## Key takeaways - Entity resolution decides which records describe the same real-world thing, and what each match is allowed to do. - With an OWL reasoner running, owl:sameAs is transitive and each assertion copies statements between two names. - Keep each match as a record with score, method, reviewer, and time; merge only in the system of record. - Keep provenance for each surviving value so a wrong merge can be traced and reversed. --- 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. ### Entity Resolution Plan Give it your entity type, sources and sample records. It returns link, assert or merge per source pair, survivorship with provenance, and a first test plan. [Read the skill](/skills/entity-resolution-plan.md). *Paste into a new chat* ``` Use the skill at https://atlan.com/skills/entity-resolution-plan.md to plan entity resolution for our ontology. Ask me for whatever it needs. ``` *Run once in a terminal* ``` curl -fsSL --create-dirs \ -o ~/.agents/skills/entity-resolution-plan/SKILL.md \ https://atlan.com/skills/entity-resolution-plan.md ``` *For an agent* ``` curl -fsSL https://atlan.com/skills/entity-resolution-plan.md ``` Human Agent ClaudeChatGPTGeminiCursorOther Copy --- 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](https://atlan.com/know/what-is-the-enterprise-context-layer/) needs both answers, and the evidence behind each match. Matching never finishes, because the sources feeding the [context graph](https://atlan.com/know/what-is-a-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)](https://arxiv.org/abs/2008.04443), 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)](https://doi.org/10.1080/01621459.1969.10501049). 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)](https://arxiv.org/abs/1905.06397). 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)](https://schema.org/sameAs) 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](https://atlan.com/data-catalog-vs-master-data-management/). Investigators run [entity resolution in fraud and financial-crime graphs](https://atlan.com/know/ai-agent/ontology/knowledge-graph-use-cases-for-fraud-detection-and-financial-crime/). Document pipelines use [entity linking in documents](https://atlan.com/know/ai-agent/data-for-ai/document-intelligence-for-enterprise/) 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)](https://arxiv.org/abs/1905.06167) 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](https://atlan.com/know/ai-agent/knowledge-graph/knowledge-graph-construction-for-ai/). 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)](https://arxiv.org/abs/2310.11244) 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](https://arxiv.org/abs/2004.00584)) | 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](https://atlan.com/know/data-quality-in-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)](https://www.w3.org/TR/owl2-primer/), "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)](https://www.w3.org/TR/owl2-syntax/) 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)](https://www.w3.org/TR/owl2-profiles/), 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](https://atlan.com/know/ai-agent/ontology/how-agents-use-ontology/) and into every answer built on [grounding agents in an ontology](https://atlan.com/know/ai-agent/ontology/ontology-ai-grounding/). 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)](https://research.vu.nl/en/datasets/sameascc-dataset-of-558m-owlsameas-statements/) "contains 558,943,116 distinct owl:sameAs statements." A [survey on identity in the web of data (Raad et al., arXiv, 2019)](https://arxiv.org/abs/1907.10528) 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](https://atlan.com/know/what-is-a-knowledge-graph/) that agents read, including [knowledge graphs built for AI agents](https://atlan.com/know/ai-agent/knowledge-graph-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. ```turtle @prefix ex: . @prefix owl: . @prefix prov: . @prefix xsd: . # 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](https://www.w3.org/TR/owl2-syntax/), the OWL 2 Primer and Profiles, the [SKOS Reference (W3C, 2009)](https://www.w3.org/TR/skos-reference/), [PROV-O (W3C, 2013)](https://www.w3.org/TR/prov-o/), and [PROV-CONSTRAINTS (W3C, 2013)](https://www.w3.org/TR/prov-constraints/). | 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 Sec. 9.6.1; OWL 2 Profiles Sec. 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 Sec. 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 Sec. 6.3; OWL 2 Structural Specification Sec. 9.5; OWL 2 Profiles Sec. 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 Sec. 6.1; OWL 2 Structural Specification Sec. 9.2.8; OWL 2 Profiles Sec. 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 Sec. 8.3, Sec. 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 Sec. 8.3, Sec. 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 Sec. 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](https://atlan.com/know/ai-agent/data-for-ai/data-lineage-for-ai/). 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](https://atlan.com/know/ai-agent/ontology/ontology-vs-taxonomy-what-is-the-difference/) meet. Records belong in match records and clusters. When [designing an ontology for AI](https://atlan.com/know/ai-agent/ontology/ontology-design-for-ai/), pick the identity construct for each class up front, just as [operational ontology objects and links](https://atlan.com/know/ai-agent/ontology/what-is-an-operational-ontology/) 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](https://atlan.com/know/semantic-layer/) and the [business glossary](https://atlan.com/know/ai-agent/how-to-manage-kpi-definitions-and-a-business-glossary-in-a-data-catalog/). Record identity depends on [data contracts that pin identifiers](https://atlan.com/know/ai-agent/data-for-ai/data-contracts-for-ai/), 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](https://www.gleif.org/en/organizational-identity/lei-vlei/the-legal-entity-identifier-lei)) | | 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](https://atlan.com/know/ai-readiness/ai-ready-data-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)](https://files.ifi.uzh.ch/ddis/iswc_archive/iswc/ab/2010/iswc2010.semanticweb.org/accepted-papers/261.html) 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 Sec. 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 Sec. 4.3 Table 5; OWL 2 Primer Sec. 6.1, Sec. 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 Sec. 8.3, Sec. 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 Sec. 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 Sec. 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: 1. Declare `owl:hasKey` only on reference-grade identifiers. 2. Feed rejected match records back to the matcher as negative labels, so it stops proposing them. 3. Put `owl:differentFrom` between cluster IRIs a steward has kept apart. If a later key or match derives `sameAs`, the reasoner reports an inconsistency. 4. Load each matching run into its own named graph, so one bad run can be dropped whole. 5. Retract a bad assertion before you correct it. 6. Re-run matching, and re-sample quality, when a source or a rule changes. Identity errors are one reason [enterprise knowledge graphs stall](https://atlan.com/know/ai-agent/knowledge-graph/enterprise-knowledge-graph-pitfalls/). An [active ontology](https://atlan.com/know/what-is-active-ontology/) changes as sources change, and match records move with it. The [questions to ask an ontology vendor](https://atlan.com/know/ai-agent/ontology/ontology-vendor-evaluation-questions/) 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](https://atlan.com/know/enterprise-data-graph/) and serves it, with business meaning, to agents. According to [Atlan's search field reference (Atlan docs)](https://docs.atlan.com/product/capabilities/build-apps/sdks/python/search/references/searchable-fields/common), 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)](https://docs.atlan.com/product/capabilities/governance/glossary/how-tos/link-terms-to-assets), so one term carries its meaning to many tables while each table keeps its own identity. The [Asset-term link app (Atlan docs)](https://docs.atlan.com/product/capabilities/governance/glossary/how-tos/automate-term-asset-links) "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)](https://docs.atlan.com/product/capabilities/atlan-ai/how-tos/atlan-mcp-overview), "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](https://atlan.com/know/what-is-context-engineering/) decides which of that reaches the agent. The ontology defines the classes; see [where the ontology sits in the context layer](https://atlan.com/know/ai-agent/ontology/ontology-and-context-layer/). Match records and clusters say which individuals are the same. For how the two fit together, read [context graph vs ontology](https://atlan.com/know/context-graph-vs-ontology/) and [querying the graph from an agent](https://atlan.com/know/ai-agent/how-to-query-context-graph-with-ai-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 Structural Specification and Functional-Style Syntax (Second Edition), W3C](https://www.w3.org/TR/owl2-syntax/) [OWL 2 Web Ontology Language Primer (Second Edition), W3C](https://www.w3.org/TR/owl2-primer/) [OWL 2 Web Ontology Language Profiles (Second Edition), W3C](https://www.w3.org/TR/owl2-profiles/) [SKOS Simple Knowledge Organization System Reference, W3C](https://www.w3.org/TR/skos-reference/) [PROV-O: The PROV Ontology, W3C](https://www.w3.org/TR/prov-o/) [Constraints of the PROV Data Model, W3C](https://www.w3.org/TR/prov-constraints/) [sameAs, schema.org](https://schema.org/sameAs) [(Almost) All of Entity Resolution, Binette and Steorts, arXiv](https://arxiv.org/abs/2008.04443) [The sameAs Problem: A Survey on Identity Management in the Web of Data, Raad et al., arXiv](https://arxiv.org/abs/1907.10528) [When owl:sameAs isn't the Same: An Analysis of Identity in Linked Data, Halpin et al., ISWC 2010](https://files.ifi.uzh.ch/ddis/iswc_archive/iswc/ab/2010/iswc2010.semanticweb.org/accepted-papers/261.html) [sameAs.cc - Dataset of 558M owl:sameAs statements, VU Amsterdam](https://research.vu.nl/en/datasets/sameascc-dataset-of-558m-owlsameas-statements/) [A Theory for Record Linkage, Fellegi and Sunter, Journal of the American Statistical Association](https://doi.org/10.1080/01621459.1969.10501049) [End-to-End Entity Resolution for Big Data: A Survey, Christophides et al., arXiv](https://arxiv.org/abs/1905.06397) [A Survey of Blocking and Filtering Techniques for Entity Resolution, Papadakis et al., arXiv](https://arxiv.org/abs/1905.06167) [Entity Matching using Large Language Models, Peeters, Steiner, and Bizer, arXiv](https://arxiv.org/abs/2310.11244) [Deep Entity Matching with Pre-Trained Language Models, Li et al., arXiv](https://arxiv.org/abs/2004.00584) [The Legal Entity Identifier (LEI), GLEIF](https://www.gleif.org/en/organizational-identity/lei-vlei/the-legal-entity-identifier-lei) [Common search fields, Atlan docs](https://docs.atlan.com/product/capabilities/build-apps/sdks/python/search/references/searchable-fields/common) [Link terms to assets, Atlan docs](https://docs.atlan.com/product/capabilities/governance/glossary/how-tos/link-terms-to-assets) [Automate term - asset links, Atlan docs](https://docs.atlan.com/product/capabilities/governance/glossary/how-tos/automate-term-asset-links) [Atlan MCP, Atlan docs](https://docs.atlan.com/product/capabilities/atlan-ai/how-tos/atlan-mcp-overview)