Surface text gives us names. Entity systems try to discover what those names point to. The words “Apple”, “Singapore”, “Mercury” or “Jordan” can refer to different real or conceptual entities depending on context. Entity tokenisation is the higher-level move that turns a mention into an addressable identity.
This is not the same as ordinary subword tokenisation. A language-model tokenizer may split a name into several pieces. An entity layer can still map the entire mention to one canonical entity ID. The two granularities coexist.
This article continues the eduKateSingapore Representation and Tokenisation series and connects directly to Token Granularity.
The Entity Route
SOURCE TEXT → SURFACE TOKENS → ENTITY MENTION → CANDIDATE ENTITIES → CONTEXTUAL DISAMBIGUATION → CANONICAL ENTITY ID → ATTRIBUTES + RELATIONSHIPS + PROVENANCE → REASONING / RETRIEVAL → SOURCE RETURN
1. A Mention Is Not Yet an Entity
The string Paris is a mention. It may refer to the capital of France, a person, a place in another country, a mythological figure or something else entirely.
Entity resolution begins only after the system asks which referent this mention points to in this context.
2. Names Are Surface Representations of Identity
A person, organisation or place can have several names. One name can also belong to several different entities.
Therefore the surface string is evidence about identity, not identity itself.
3. Canonical IDs Create Stable Machine Identity
A knowledge system can assign one stable identifier to an entity and attach all known labels, aliases and properties to it. The ID becomes the machine address even when surface names change.
This is analogous to a token ID, but at a higher semantic scale.
4. Entity IDs Must Not Be Confused With Token IDs
A token ID identifies a tokenizer vocabulary entry. An entity ID identifies a real or conceptual object inside an entity registry, knowledge graph or database.
The word Singapore can have one or several text-token IDs while the country itself can have one canonical entity ID.
5. Aliases Preserve Naming Diversity
Entities can have abbreviations, former names, nicknames, transliterations, local-language labels and legal names. A robust entity system stores these as aliases rather than creating a new entity for every string.
Alias management separates naming variation from identity variation.
6. One Alias Can Still Be Ambiguous
United can refer to an airline, a football club, a company name fragment or an ordinary adjective. Alias dictionaries alone cannot settle reference.
Context is required.
7. Entity Linking Is Contextual Disambiguation
Entity linking maps a mention in text to a candidate entity in a registry. The system uses surrounding words, document topic, known relationships and other signals to choose among candidates.
The task is not just recognition. It is reference resolution.
8. Named Entity Recognition Comes Before Linking in Many Pipelines
A named entity recogniser identifies spans such as person, organisation, place or date. Entity linking then decides which specific entity a recognised span refers to.
Recognition answers “this looks like a name.” Linking answers “which thing is it?”
9. Entity Boundaries Can Span Many Text Tokens
National University of Singapore can contain several words and several subword tokens. The entity layer can treat the entire span as one referent.
This is a clear example of hierarchical tokenisation.
10. Nested Entities Create Boundary Complexity
An organisation name can contain a place name. A book title can contain a person’s name. Entity systems sometimes need overlapping or nested spans rather than one flat segmentation.
Real identity structure does not always fit one linear set of non-overlapping tokens.
11. Coreference Extends Identity Across Mentions
After “Dr Lee entered the room,” later mentions such as “she”, “the doctor” or “Lee” may refer to the same entity.
Coreference resolution groups different mentions into one discourse identity even when the surface strings differ completely.
12. Pronouns Are Identity Links Without Names
A pronoun contains almost no lexical identity by itself. Its referent is supplied by context.
This shows why entity representation cannot be reduced to matching proper nouns.
13. Context Can Override the Most Famous Candidate
The most globally famous entity sharing a name is not always the correct one. A local school document mentioning Victoria may refer to an institution or person rather than the Australian state.
Popularity is one prior, not proof.
14. Document Topic Narrows Candidate Space
In a chemistry article, Mercury is more likely the element than the planet. In an astronomy article, the reverse may be true.
Domain context changes entity probability.
15. Relationships Help Resolve Ambiguity
If a sentence mentions Apple, iPhone and Tim Cook, the relationship graph strongly favours the technology company.
Entity linking can therefore use the neighbourhood of other resolved entities as evidence.
16. Time Can Change the Correct Entity Label
Companies rebrand, countries change names and organisations merge. A canonical identity can remain stable while its preferred label changes over time.
Entity systems should separate identity from time-indexed naming.
17. Historical Entities Need Temporal Boundaries
The same institution before and after a legal merger may be one continuous organisation for some tasks and distinct legal entities for others.
Identity criteria depend on the receiver’s question.
18. Jurisdiction Can Change Identity Meaning
A registered company name may be unique only inside one jurisdiction. The same name can belong to different legal entities elsewhere.
Canonical IDs should preserve jurisdiction where relevant.
19. Names in Different Scripts Can Point to One Entity
A city can be written in English, Chinese, Malay, Tamil or another script. A multilingual entity registry can treat these as labels for one underlying entity.
Entity identity creates a bridge across language-specific surface tokenisation.
20. Transliteration Can Create Several Valid Aliases
Names moved between scripts can have multiple transliteration conventions. Entity resolution should not assume one Latin spelling is universally canonical.
The authoritative identifier should sit below the alias layer.
21. Entity Normalisation Is Not Ordinary Text Normalisation
Lowercasing a name or removing punctuation can improve matching while also collapsing distinct entities. Entity normalisation needs rules informed by identity semantics.
Keep the original mention and the normalised lookup key separately.
22. Canonicalisation Needs Provenance
If the system maps a mention to an entity ID, it should record how confident the link is and which source registry established the identity.
A canonical ID without provenance can become an untraceable assertion.
23. Confidence Should Survive Entity Resolution
Some mentions are unambiguous; others remain uncertain. A pipeline that forces every mention into exactly one entity can create false precision.
Candidate sets and confidence scores can preserve uncertainty until more evidence appears.
24. “No Entity” Is a Valid Outcome
Not every capitalised phrase should link to a knowledge graph. A strong system can leave a mention unresolved rather than invent a referent.
Abstention is part of identity safety.
25. New Entities Need Open-World Handling
Knowledge bases are always incomplete. New companies, people, projects and places appear continuously.
An open-world entity system must distinguish “not yet in the registry” from “does not exist”.
26. Entity Creation Is a Governance Event
Creating a new canonical entity should require enough evidence to avoid duplicates. Otherwise several IDs can represent the same real thing.
Identity registries need deduplication just as corpora do.
27. Entity Merging Must Preserve History
If two database records are discovered to be the same entity, one ID may become canonical while the other redirects or remains as a historical alias.
Deleting the old identity without a crosswalk breaks historical references.
28. Entity Splitting Is Equally Important
A single record may later prove to contain two different people or organisations that were incorrectly merged.
Entity systems need correction paths in both directions.
29. Knowledge Graphs Make Entity Relationships Explicit
Once entities have stable IDs, relationships such as person → works_for → organisation or city → located_in → country can be stored as edges.
The representation moves from token sequence to graph structure.
30. Graph Neighbours Improve Retrieval
A user searching for one company can retrieve subsidiaries, founders, products or locations through graph relationships even when those names never appear in the query.
Entity identity expands retrieval beyond lexical overlap.
31. Entity-Aware Search Complements Text Search
Lexical search can match strings. Entity-aware search can match identity across aliases and languages.
This creates a higher-resolution retrieval route above Tokenisation in Search and Indexing.
32. Entity Mentions Should Return to Source Spans
Every resolved entity should retain offsets or pointers back to the exact mention that produced the link.
This allows humans to verify whether the system linked the correct phrase.
33. Entity Embeddings Create Another Representation Layer
Canonical entities can be mapped into vectors based on descriptions, graph neighbours or observed contexts.
Those embeddings support similarity and retrieval but should not be confused with the stable symbolic entity ID.
34. Stable IDs and Learned Vectors Serve Different Jobs
The stable ID says “this is the same entity.” The vector says “this entity is similar to these others under this learned representation.”
Identity and similarity must remain separate relations.
35. Entity Tokens Can Reduce Repeated Description
Instead of repeating a long company name and metadata throughout a structured system, one entity ID can act as a compact reference.
This is semantic compression through canonical identity.
36. But Compression Raises the Stakes of Wrong Linking
If the system links one mention to the wrong entity ID, every downstream attribute and relationship can become confidently wrong.
Coarse semantic tokens are powerful because they compress; they are dangerous for the same reason.
37. The Entity Tokenisation Audit
- What counts as an entity in this system?
- How are mention spans detected?
- What alias registry supplies candidate identities?
- How are multilingual and transliterated names handled?
- What context resolves ambiguity?
- Are time and jurisdiction represented?
- Can multiple candidates remain unresolved?
- Is “no entity” allowed?
- How are new entities created?
- How are duplicates merged or records split?
- Does every entity ID preserve source provenance?
- Can every link return to the original mention span?
- Are stable IDs separated from learned embeddings?
- How are identity-sensitive errors evaluated?
38. What Students Should Remember
- A name is a mention, not automatically an identity.
- Canonical IDs provide stable machine identity.
- Aliases let several names point to one entity.
- One name can still point to several entities.
- Context and relationships resolve ambiguity.
- Entity IDs and tokenizer IDs are different layers.
- Provenance and confidence should survive linking.
- Entity systems need correction, merging and splitting paths.
39. The Deep Principle
Text tells us what was written. Entity representation asks what the writing refers to. The move from mention to identity is therefore one of the most consequential jumps in the representation stack.
A name is a surface token. An entity ID is a claim of identity. The stronger the compression from many mentions into one thing, the stronger the evidence and provenance required to justify the link.