How English Works | The Identifier

Three students are named Daniel.

A library owns two editions with the same title.

Two streets in different cities share the same name.

A website changes its headline without changing the underlying article.

A person changes their legal name but remains the same person.

Names are useful.

Names are not enough.

When a system must reliably refer to one thing rather than another, it needs a stronger distinction.

An identifier is language whose first job is not to describe the thing, but to distinguish the thing.

That distinction sounds small.

Modern information systems depend on it.

Quick Read

One-sentence answer: an identifier works when it distinguishes a resource from other resources within a defined scope, remains stable enough for its intended lifetime, and does not force readers to confuse the identifier’s characters with the nature or location of the thing identified.

RFC 3986 defines an identifier as information required to distinguish what is being identified from all other things within its scope of identification. It also warns against a common misunderstanding: an identifier does not necessarily define the identity of the resource, and a URI does not necessarily imply that the resource can be accessed.

This gives us the identifier’s main architecture:

• resource: the thing being referred to;
• identifier: the distinguishing token or sequence;
• scope: the domain inside which uniqueness matters;
• assignment: the act that binds identifier to resource;
• persistence: how long the binding should survive;
• resolution: any process that uses the identifier to find further information;
• alias: another reference that points to the same resource;
• canonical identifier: the preferred stable reference when several exist.

The Identifier Is Not the Name

A person can have several names.

One name can belong to several people.

A product name can change during rebranding.

A course can be renamed between academic years.

An identifier tries to survive these changes.

Name:

Secondary English Programme

Identifier:

COURSE-2026-ENG-0147

The name helps humans recognise.

The identifier helps systems distinguish.

name = human-facing description or convention
identifier = distinguishing reference within scope

This also separates Identifier from the newer controlled-label work elsewhere on eduKateSG. A preferred label may change while the underlying identity remains stable.

The Identifier Is Not the Description

Suppose:

Student ID 48319

What can we infer?

Almost nothing except that the token is intended to distinguish one student inside some system.

We should not infer:

• age;
• gender;
• class;
• ability;
• nationality;
• location.

A good identifier can be semantically boring.

That is often a strength.

identity should not depend on an attribute that may later change

The Identifier Is Not the Address

An address often tells us where something can be found.

An identifier tells us what reference we mean.

Sometimes one string performs both jobs.

RFC 3986 explains that a URI can function as a locator, a name, or both.

For example, an HTTP URL usually identifies a resource and provides a route for accessing it.

But the conceptual jobs remain separable.

identifier = which resource?
locator = where or how can I reach it?

If a resource moves, a location-dependent identifier may break unless redirection or another persistence mechanism preserves the reference.

Scope Determines What “Unique” Means

Identifier:

42

Unique?

Inside one classroom register, perhaps.

Across a school, probably not.

Across Singapore, certainly not by itself.

Uniqueness is always scoped.

identifier + namespace or authority = meaningful uniqueness boundary

This is why Namespace belongs immediately after Identifier in the series. “42” can be perfectly valid in thousands of separate systems without collision as long as the scope is explicit.

Global Uniqueness Costs More Than Local Uniqueness

Local systems can issue identifiers cheaply:

Student 001

Global systems need stronger coordination.

They may use:

• domain names;
• UUIDs;
• centrally allocated number ranges;
• URI schemes;
• registry authorities.

The stronger the uniqueness claim, the more assignment discipline usually sits behind it.

“unique” is an operational promise about collision control

Meaningful Identifiers Are Friendly Until Meaning Changes

Consider:

SEC3-ENGLISH-2026-MAYA

It is readable.

It may encode:

• level;
• subject;
• year;
• name.

What happens when Maya advances to Secondary 4?

Does the identifier change?

If it changes, historical references may break.

If it does not change, the identifier contains stale description.

This is the trap of semantic identifiers.

the more meaning an identifier contains, the more future change can make the identifier lie

Opaque Identifiers Trade Readability for Stability

Identifier:

7f4a9c32

Humanly unpleasant.

Operationally useful.

An opaque identifier does not try to teach the reader what the resource is.

Description lives in metadata.

Identity lives in the identifier.

opaque ID + rich metadata can be more durable than clever ID + changing reality

Not every system needs opaque IDs. The deeper principle is to avoid encoding attributes whose future change would force identity reassignment.

Reassignment Is One of the Most Dangerous Identifier Operations

Suppose Student ID 381 belonged to Amir in 2025.

Amir leaves.

In 2027, the system reuses 381 for Priya.

An old record says:

Student 381 received additional support.

Who?

The identifier no longer has one historical referent.

identifier reuse can turn old truth into new ambiguity

Many systems therefore avoid reassignment for identifiers expected to persist in archives.

Persistence Means the Binding Survives Useful Time

A persistent identifier does not need to live forever.

It needs to survive long enough for the system’s reference obligations.

A restaurant table number may last one evening.

An examination candidate number may need to survive the assessment cycle.

A scholarly DOI is designed for much longer reference.

The correct lifetime depends on use.

persistence is not immortality; it is alignment between identifier lifetime and reference lifetime

Tombstones Preserve the Fact That an Identity Existed

A resource is withdrawn.

Weak system:

404 — nothing here

Stronger archival system:

Record 7421 was withdrawn on 2 September 2026. The identifier will not be reassigned.

The second state preserves historical referential integrity.

A tombstone says:

the resource is gone or unavailable, but the identity slot is not free for reuse

This connects Identifier to The Empty State: absence can carry history.

Aliases Allow Several References to Converge

A resource may be known through:

• an old URL;
• a new URL;
• a database ID;
• a public DOI;
• a legacy catalogue number.

These references can all point to the same underlying entity.

A mature system records the relationship instead of pretending only one reference ever existed.

alias = another route to the same identity

The key is to identify which reference is canonical for future use and which remain only for backward compatibility.

Canonical Identifiers Concentrate Reference

If five URLs all represent the same article, internal links can fragment across all five.

A canonical identifier tells systems and people:

Prefer this reference when naming the resource now.

Older references may remain valid.

The canonical one concentrates future reference.

This is not the same as erasing history.

canonicalisation chooses a preferred present reference without pretending alternative historical references never existed

Identifier Collision Means Two Things Claim the Same Token

Two departments independently create:

PROJECT-17

One means a reading programme.

One means a building renovation.

The token itself is not broken.

The scope is.

Collision can be prevented through:

• central allocation;
• namespaces;
• randomly large identifier spaces;
• organisational prefixes;
• registries.

Identifier design is therefore also coordination design.

Identifiers Should Not Leak Sensitive Information

A public identifier such as:

PATIENT-HIV-2026-0041

has a serious design problem.

The identifier itself reveals information that may be sensitive.

Opaque identifiers can reduce this leakage.

Likewise, identifiers should avoid unnecessary birth dates, national ID fragments or other personal attributes when public exposure is possible.

the identifier may travel farther than the metadata it was designed beside

Identifiers Need Check Digits When Human Transcription Is Risky

Long numeric identifiers are easy to mistype.

Some systems add a check digit or checksum so common transcription errors can be detected.

The extra character is not part of the resource’s meaning.

It protects the integrity of the reference.

This reveals another design principle:

identifier syntax can be engineered for error detection as well as uniqueness

The Same Resource Can Have Different Identifiers for Different Purposes

A book can have:

• an ISBN identifying an edition or publication product;
• a library catalogue record ID;
• a shelf label identifying a local physical position;
• a barcode identifying a particular copy.

These identifiers are not redundant.

They identify different levels or operate in different scopes.

before comparing identifiers, ask what level of thing each identifier claims to distinguish

Identifiers Can Outlive Locations, Owners and Labels

A strong identifier lets other properties change around it.

Name changes.

Location changes.

Owner changes.

Status changes.

The reference remains.

This is why identifier design sits at the centre of archives, databases and linked data.

stable identity lets changing description accumulate around one continuing referent

Primary School: Why Names Are Not Enough

Put three fictional students named Alex into a class list.

Ask children how the school can distinguish them safely.

They may propose:

• full name;
• class;
• student number.

Then move one Alex to another class.

Which reference survives?

The activity teaches the difference between description and stable identification.

Lower Secondary: Design an Identifier That Survives Change

Give students:

Project: Secondary 2 Eco Garden 2026

Ask them to design an ID.

Then change:

• the project name;
• the year of completion;
• the teacher in charge.

Does the ID remain sensible?

This exposes which attributes were mistakenly encoded as identity.

Upper Secondary: Audit an Identity System

• What resource level is being identified?
• Within what scope is the identifier unique?
• Can the token be reassigned?
• How long should the binding persist?
• Does the identifier leak changing or sensitive attributes?
• Can aliases be represented?
• Which reference is canonical?
• What happens after deletion or withdrawal?
• Can transcription errors be detected?
• What namespace or registry prevents collision?

Ten Failure Modes of Identifier English

1. Name-identity confusion. A mutable human label is treated as the permanent identity.
2. Scope ambiguity. “Unique” is claimed without saying where uniqueness applies.
3. Semantic overloading. The identifier contains attributes that later change.
4. Reassignment. One token refers to different resources at different times without historical protection.
5. Locator dependence. Moving the resource breaks the reference.
6. Alias fragmentation. Multiple references exist with no canonical relationship.
7. Deletion amnesia. Old identifiers disappear and can no longer explain historical records.
8. Privacy leakage. Sensitive information is encoded directly into public IDs.
9. Collision. Independent issuers create the same token for different things.
10. Level confusion. One identifier for an edition is mistaken for an identifier of one physical copy, person, organisation or event.

How to Build a Better Identifier System

1. Define exactly what kind of resource is being identified.
2. Define the uniqueness scope.
3. Decide who has authority to assign identifiers.
4. Avoid mutable attributes unless their presence is genuinely necessary.
5. Set persistence and reassignment rules.
6. Provide aliases and canonical references where needed.
7. Preserve tombstones for archived identities.
8. Protect sensitive information.
9. Use namespaces or registries to prevent collision.
10. Document how old references resolve after system change.

Then perform the future-change test:

If the name, location, owner, category and status of this resource all change, should the identifier still refer to the same thing?

The Deeper Idea: Identity Lets Change Accumulate Without Becoming Chaos

Without stable identifiers, every description change risks creating a new apparent object.

With stable identifiers, systems can say:

this is the same thing we were talking about before, even though many things about it have changed

That gives time somewhere to attach.

stable identifier → changing metadata → continuous history

This is why Identifier belongs to How English Works.

It is the language layer that allows reference to survive description.

Reader Checklist

• What exactly is being identified?
• What is the uniqueness scope?
• Who assigns the identifier?
• Can it be reassigned?
• How long should it persist?
• Does it contain unstable attributes?
• Does it expose sensitive information?
• What aliases exist?
• Which identifier is canonical?
• What happens when the resource is gone?

Related eduKateSG Reading

• How English Works | The Schema
• How English Works | The Filename
• How English Works | The Link
• How English Works | The Timestamp

Research and Further Reading

• RFC 3986 — Uniform Resource Identifier: Generic Syntax

Final idea: an identifier is good when the world around a resource can change without forcing future readers to wonder whether they are still talking about the same thing.