Does OWL assume different names denote different individuals?

No. Explicit information or other applicable axioms can establish difference.

Does the absence of an equality assertion prove difference?

No. Without the unique name assumption or other supporting information, the relationship can remain unresolved.

Can removing the assumption perform entity resolution?

No. It permits shared identity but does not supply the evidence or matching process needed to establish it.

AI Glossary / Data engineering and architecture / Intermediate

Unique name assumption

Definition

The unique name assumption is a rule of interpretation under which different names denote different individuals. If a model uses names A and B, the assumption treats their referents as distinct simply because the names differ. Without this assumption, different names may refer to the same individual unless other information establishes equality or difference.

What it means

This matters when software reasons about knowledge rather than merely comparing character strings. Two departments can assign different identifiers to the same piece of equipment. A system must decide whether different identifiers automatically imply two machines or whether shared identity remains possible.

The assumption is about the meaning of names in a formal model. It is not the everyday claim that people's names are unique, nor a database requirement that a column contain no repeated values. A database can enforce different record identifiers while several records still describe one real-world entity.

How it works

An interpretation connects names to objects. Adopting the unique name assumption requires distinct names in scope to map to distinct objects. Omitting it leaves more interpretations available.

OWL does not generally make this assumption. It supports explicit statements that named individuals are the same or different. Other axioms can also establish distinctions. Failing to assert difference does not itself assert sameness; it may leave identity unresolved.

Before integrating a knowledge graph with a database or AI application, inspect the semantics used by each component. A displayed count of distinct identifiers and a reasoned claim about distinct entities can answer different questions, even when both use the same underlying records.

Three practical examples

1. Asset integration: Maintenance identifier M17 and purchasing identifier P82 both appear on one device. An integration team checks evidence before treating them as two assets or merging their information.

2. Research catalogs: A repository identifier and a publisher identifier may denote the same publication. A knowledge model can preserve the names while explicitly relating their referents when the identity claim is justified.

3. Business assistants: An assistant receives two supplier identifiers from different systems. Its explanation distinguishes “two records found” from “two separate suppliers confirmed” when the identity relationship remains unresolved.

Think of it this way

Think of two labels attached to luggage. Different labels might be attached to two suitcases, or two airlines might have attached labels to the same suitcase. Looking only at the label text does not settle which situation occurred.

The unique name assumption acts as a modeling rule that treats the labels as referring to different suitcases. The analogy does not provide an identification method or justify merging records. Real integration requires evidence about what each identifier denotes and its scope.

Worked example

Consider an original toy knowledge model containing names PumpA and Asset47. Both are described as pumps, but no equality or difference statement is supplied and no other axiom forces either conclusion.

Under the unique name assumption, the names denote two different individuals. Without it, at least two interpretations remain possible: they can denote the same pump or different pumps. Counting two strings does not select between these interpretations.

Add a justified statement that PumpA and Asset47 denote the same individual. Information about that individual can then be combined through identity reasoning. Alternatively, add a justified difference statement and the shared-pump interpretation is excluded.

Adding both equality and difference for the same pair creates a contradiction under the intended classical identity semantics. It does not mean the equipment changed identity overnight. A reviewer should inspect the claims, source mappings and time-related modeling rather than accept both as compatible facts.

Illustrative case study

Illustrative fictional case: NameOrchard builds an internal equipment assistant from purchasing and maintenance catalogs. The import initially reports every distinct identifier as a distinct physical machine. Staff notice that a serviced pump appears twice in the asset summary.

The team separates source-record identity from equipment identity. It keeps both record identifiers and asks a responsible employee to confirm which physical object each record describes. Only confirmed mappings become identity assertions; likely matches remain review candidates.

The pilot includes one genuine duplicate description and one pair of similar but different machines. Its acceptance criteria check both inappropriate splitting and inappropriate merging. The fictional case illustrates a modeling correction, without claiming that dropping the unique name assumption automatically discovers duplicates or improves a measured accuracy score.

Common misconceptions and mistakes

No unique name assumption does not mean every name refers to the same thing. It means difference cannot be concluded from different names alone.

A globally distinctive identifier string does not guarantee a globally distinctive real-world referent. Different organizations may name the same entity independently.

Similarity is weaker than identity. Matching labels, addresses or specifications can support investigation without justifying a statement that two names denote precisely the same individual. Finally, do not confuse the unique name assumption with the closed-world assumption: one concerns identity across names, while the other concerns how absent information is interpreted.

Business use

Teams building knowledge graphs, data catalogs and AI retrieval systems should decide what each identifier names: a source record, a physical object, an organization or a time-specific version. Many apparent identity conflicts arise because those categories were mixed.

Document when difference is assumed and when it requires evidence. Keep the origin of identity assertions so an incorrect merge can be investigated. Design user-facing counts and summaries to say whether they concern records or confirmed entities. These choices make an assistant's claims easier to evaluate and reduce hidden assumptions during integration.

Check your understanding

Two identifiers appear in a model without the unique name assumption. Can their different spelling alone prove two different entities exist?

Answer: No. Different spelling establishes different names, not necessarily different referents. Additional information is needed.

Related terms

Ontology
Closed-world assumption
Unique key
Entity resolution
OWL
sameAs
open-world assumption
knowledge graph

Learn next

Draw two source records and the real-world objects they might describe. Write separate statements for “same record,” “same object,” “different object” and “possible match.” Check that your integration process does not confuse these relationships.

Sources

W3C, OWL 2 Web Ontology Language Primer, section 4.7, Equality and Inequality of Individuals: https://www.w3.org/TR/owl2-primer/

The primary explanation and identity examples were read. PumpA, Asset47 and NameOrchard are original fictional teaching illustrations; no real organizational identity claims are made.

Previous: Unique key Next: Unique-names assumption