Persistent Identifier¶

Version: v1 · 2026-08-24 · History
Prime #: 1061
Origin domain: Biology & Ecology
Subdomain: scientific data infrastructure → Biology & Ecology

Core Idea¶

A persistent identifier is a designed handle assigned to an entity with the explicit commitment that the handle will continue to resolve to that entity across changes in the entity's location, representation, custodian, or version. The structural pattern is separating the identity-bearing token from the resolvable substrate it points into, so that the substrate can change freely — move, fork, rename, migrate, be re-issued — without breaking the references already made to it elsewhere in the world.

Three commitments travel with the pattern. A stable token: the identifier is opaque and assigned once, not derived from any mutable property of the entity such as its title, location, or custodian; opacity is what protects it from being invalidated by content change. Resolution machinery: a separate, maintained mapping from token to current location, representation, or canonical record — the identifier is useless without an operator who guarantees the resolver. And a scope of identity: an explicit answer to "the same what?" — same intellectual work versus same expression versus same manifestation versus same file — so that the persistence guarantee attaches only to the scoped identity the token was minted for.

The structural payoff is decoupling the act of reference from the act of storage. A citation, a foreign key, a link, a record-locator, a catalogue number all become safe to copy, forward, and embed because the resolver — not the embedded token — absorbs the cost of every subsequent change to the referenced object. The cost is that the resolver itself becomes a piece of critical infrastructure whose failure invalidates every reference that depends on it. This is the prime's defining trade: it shifts an unbounded distributed maintenance burden onto a single maintained mapping, converting many fragile references into one durable institution.^[1] Because the resolver is a designed, operated thing, the pattern does not occur outside engineered reference systems — but within them it recurs wherever stable reference must survive substrate change.

How would you explain it like I'm…

The Never-Break Name Tag

Imagine your friend gets a special name tag that always points to them, even if they move to a new house or change their clothes. People who want to find your friend look up the name tag, and it always shows where they are now. So the tag never breaks even when everything about your friend changes.

The Handle That Follows

A Persistent Identifier is a special handle given to a thing with a promise: the handle keeps pointing to that thing even after it moves, gets renamed, changes hands, or gets a new version. The trick is to keep the name separate from where the thing is actually stored, so the storage can change without breaking all the links people already made. The handle is plain and fixed, never built from anything that might change, like a title or a location. And it only works because someone keeps a lookup list that turns the handle into the current location. That lookup keeper becomes really important, because if it ever fails, every link that depended on it breaks.

Stable Resolvable Token

A Persistent Identifier is a designed handle assigned to an entity with the explicit commitment that it will keep resolving to that entity across changes in the entity's location, representation, custodian, or version. The structural pattern is separating the identity-bearing token from the resolvable substrate it points into, so the substrate can move, fork, rename, or migrate without breaking references already made elsewhere. Three commitments travel with it: a stable token, opaque and assigned once rather than derived from mutable properties like title or location, because opacity is what protects it from content change; resolution machinery, a separate maintained mapping from token to current location; and a scope of identity, an explicit answer to the same what (work, expression, manifestation, or file). The payoff is decoupling reference from storage, but the cost is that the resolver becomes critical infrastructure whose failure invalidates every dependent reference. Because the resolver is a designed, operated thing, the pattern does not occur outside engineered reference systems.

A Persistent Identifier is a designed handle assigned to an entity with the explicit commitment that the handle will continue to resolve to that entity across changes in the entity's location, representation, custodian, or version. The structural pattern is separating the identity-bearing token from the resolvable substrate it points into, so the substrate can change freely, move, fork, rename, migrate, be re-issued, without breaking references already made to it elsewhere. Three commitments travel with the pattern. A stable token: the identifier is opaque and assigned once, not derived from any mutable property such as title, location, or custodian, and opacity is what protects it from being invalidated by content change. Resolution machinery: a separate, maintained mapping from token to current location, representation, or canonical record, since the identifier is useless without an operator who guarantees the resolver. And a scope of identity: an explicit answer to the same what, same intellectual work versus expression versus manifestation versus file, so the persistence guarantee attaches only to the scoped identity the token was minted for. The structural payoff is decoupling the act of reference from the act of storage: a citation, foreign key, link, record-locator, or catalogue number becomes safe to copy, forward, and embed because the resolver, not the embedded token, absorbs the cost of every later change to the object. The cost is that the resolver itself becomes critical infrastructure whose failure invalidates every dependent reference. That is the prime's defining trade: it shifts an unbounded distributed maintenance burden onto a single maintained mapping, converting many fragile references into one durable institution, which is why the pattern occurs only inside engineered reference systems.

Structural Signature¶

the referenced entity — the stable opaque token — the separately-maintained resolver — the scope of identity — the reference-decoupled-from-storage relation — the resolver-as-critical-path consequence

A persistent identifier is present when these roles and relations hold:

A referenced entity. The thing references are made to, whose location, representation, custodian, or version may change.
A stable token. An opaque handle assigned once, not derived from any mutable property of the entity (title, location, custodian). Opacity is what protects the token from being invalidated by content change.
A resolver. A separate, maintained mapping from token to the entity's current location, representation, or canonical record. The load-bearing relation: the identifier is useless without an operator who guarantees the resolver.
A scope of identity. An explicit answer to "the same what?" — same work versus expression versus manifestation versus item — bounding what the persistence guarantee covers.
The decoupling relation. References become safe to copy, forward, and embed because the resolver, not the embedded token, absorbs every subsequent change to the referenced object — converting an N-citers-by-M-changes problem into N-to-1.
The critical-path consequence. The trade-off: maintenance burden is relocated and concentrated onto a single resolver, which becomes long-lived critical infrastructure whose failure invalidates every dependent reference.

These compose so the pattern occurs only within engineered reference systems, and the design discipline — opacity, declared scope, maintained resolver, tombstoning rather than deletion, representable aliasing and merging — follows from the three roles.

What It Is Not¶

Not versioning. Versioning manages an evolving artifact's successive states. A persistent identifier keeps one stable reference resolving across those states (or across location/custodian change) — it may name a version, but its job is durable resolution, not state management.
Not provenance. Provenance records an entity's origin and chain of custody. A persistent identifier is the stable handle that lets such a record stay referenceable; provenance is content the resolver may hold, not the token-plus-resolver mechanism itself.
Not indirection. Indirection is the general technique of pointing through an intermediate level. A persistent identifier is a specific, committed, institutionally-maintained indirection with opacity, declared scope, and a guaranteed resolver — far more than a bare extra pointer.
Not a naming_convention. A naming convention encodes meaning in the name (date, type, author) for human legibility. A persistent identifier mandates opacity — no semantics in the token — precisely so content change cannot invalidate it. The two pull in opposite directions.
Not idempotence. Idempotence concerns an operation producing the same result on repetition. A persistent identifier concerns a token resolving to the same entity across substrate change — a property of reference durability, not of operation repeatability.
Common misclassification. Treating any durable-looking string (a URL, a path, a title) as a persistent identifier. Catch it by asking the three questions: what is the resolver, who funds and operates it, and at what scope of identity is persistence promised? Without a maintained resolver, the string is a link waiting to rot.

Broad Use¶

The stable-token-plus-resolver-plus-scope pattern recurs across substrates that all turn out to be reference infrastructures. In scientific data infrastructure it is the family of resolver-backed identifier systems for publications, datasets, researchers, institutions, sequences, and structures.^[2] In publishing and bibliography it is the identifier schemes for books and serials, and the discipline of distinguishing work from expression from manifestation from item is one long discussion of what scope of identity the identifier persists across. In web architecture it is identifiers intended as names rather than locations, and the doctrine that good identifiers do not change, designed precisely so that citation does not break when a server moves. In databases it is surrogate keys — opaque, system-assigned — chosen over natural keys precisely to insulate references from natural-key change, with foreign keys as the inter-table version of the same discipline.^[3] In museums and archives it is accession numbers that follow an object through cataloging, conservation, loan, and storage while its attribution and location all change.^[4] In logistics it is serial numbers, asset tags, and container codes designed to survive repainting, re-registration, and ownership change. In healthcare it is medical record numbers and master-patient-index discipline; in animal husbandry it is ear tags and ring-band IDs assigned to individuals across capture-recapture; in software supply chains it is package and coordinate names intended to survive repository moves.^[5] In each, the three pieces are present: a stable opaque token, a resolver maintained as separate infrastructure, and an explicit scope of identity the persistence is promised to.

Clarity¶

The prime forces a distinction the surface vocabulary obscures. Most things people call identifiers are not persistent: filesystem paths, locator URLs, titles, and custodian-internal record numbers all change under ordinary operation, and references to them silently break. Asking "is this a persistent identifier?" surfaces three questions that are otherwise easy to skip — what is the resolver, who operates it, and at what scope of identity is persistence promised.

Naming the prime also clarifies the failure mode that link rot, lost-dataset, and broken-citation epidemics all share. The root structural failure is not that anyone made a mistake; it is that something was used as if it were a persistent identifier when no resolver was maintained behind it. The remedy is infrastructural, not editorial. This is the clarifying force at its sharpest: the prime separates the appearance of a stable reference (a string that looks durable) from the substance of one (a token backed by an operated resolver at a declared scope), and it relocates responsibility for broken references from the people who made them to the absence of the resolver commitment. A second clarification concerns scope: a persistent identifier that promises persistence at one scope — the work — survives changes that one promising persistence at a finer scope — this exact byte sequence — does not, so the scope question is not pedantry but a determinant of what the token can actually guarantee.

Manages Complexity¶

A persistent identifier absorbs every downstream consequence of moving, renaming, re-formatting, re-issuing, or transferring custody of an entity. Without it, each consumer of a reference must be updated whenever the entity changes; with it, only the resolver must be updated, and every existing citation, link, foreign key, or label remains valid. The compression is structural: an N-to-M problem — N citers and M changes — becomes an N-to-1 problem, in which each citer points to the resolver and the resolver absorbs each change.

The cost of this compression is concentrated, not eliminated: it lands on the resolver, which becomes a piece of long-lived critical infrastructure with its own governance, funding, and continuity requirements. This is why durable identifier schemes are invariably backed by long-lived institutions — the resolver burden is real and unsubtle, and the prime makes it explicit rather than letting it be discovered when an unfunded resolver lapses. The deeper complexity-management insight is that the prime does not make maintenance cost disappear; it relocates and consolidates it, trading an unbounded, distributed, uncoordinated burden (every reference-holder tracking every change) for a single, concentrated, governable one (one operator maintaining one mapping). That trade is favorable only when the resolver is genuinely maintained, which is exactly why the prime foregrounds the institutional question as structural rather than optional.

Abstract Reasoning¶

The prime licenses several portable inferences. Opacity discipline: any identifier with semantics encoded in it — containing the title, the date, the custodian, the current location — is fragile at exactly those points, so opacity is what makes persistence achievable, not an aesthetic preference. Scope-of-identity discipline: persistence is meaningful only relative to a stated scope, and the work/expression/manifestation/item ladder ports as a general design choice whenever an identifier must be minted. Resolver as critical path: every persistent-identifier scheme produces a long-lived institution that operates the resolver, so who funds, governs, and guarantees it, and what happens on failure, are structural questions rather than optional ones.

Two further moves concern withdrawal and change of identity. Tombstoning rather than deletion: when an entity is withdrawn, the discipline says the token must still resolve — to a record explaining the withdrawal, not to a dead reference — so that citations made before withdrawal remain diagnosable. And aliasing and merging: when two entities turn out to be the same, or one splits, the resolver must handle the redirection, so both the same-as and split-from relations must be representable. Each inference is stated over the three roles — token, resolver, scope — and therefore transfers to any designed reference system that instantiates them, which is why the same reasoning that governs a publication identifier governs an asset tag, a primary key, and an animal ring-band.

Knowledge Transfer¶

The prime's reach is visible in documented cross-substrate borrowings. The library discipline of separating work, expression, manifestation, and item ported into web architecture's discussion of what an identifier denotes, the same scope-of-identity question underlying both.^[6] The database-theory recognition that natural keys are unstable and surrogate keys insulate references ported, structurally unchanged, into biological accession numbering, where an accession persists when an organism is reclassified or a sequence's annotation is revised. The publication-identifier infrastructure ported to research-software citation once software was recognized as a citable output, the structural move being to make the resolver responsible for the moving target.^[7] And the museum discipline of an opaque accession number surviving every custodial change ported into asset management as tags that survive redeployment and re-purposing.

What makes these genuine transfers is that the resolver-token-scope triple maps cleanly each time, surviving the strip-the-jargon test: it is the triple that travels, not any particular vocabulary. A reasoner who has internalized the prime in one substrate reads a new one by locating the three roles and inheriting the full discipline — opacity to protect the token, a declared scope to bound the promise, a maintained resolver as the critical path, tombstoning rather than deletion on withdrawal, and representable aliasing and merging. Because the entire pattern is a human-institutional infrastructure that does not exist outside designed reference systems, the transfer stays within that substrate family — library science, web architecture, scientific data, databases, museums, asset management, healthcare, animal husbandry, software supply chains. But within that family it is broad and well-documented, and the prime's distinctive value is that it lets a practitioner who understands why publication identifiers survive a publisher's site migration immediately understand why an ear tag survives an animal's transfer between programs and why a surrogate key survives a customer's name change: all three decouple reference from substrate through a maintained resolver at a declared scope, and all three concentrate the resulting maintenance cost into a single institution that must be funded and governed to keep the guarantee real.

Examples¶

Formal/abstract¶

A relational-database surrogate key is the cleanest formal instance, because it isolates each role of the prime in code. The referenced entity is a logical record — a customer, say — whose every natural attribute (name, email, address, even the "natural key" of a national ID) may change. The stable token is an opaque, system-assigned primary key, typically an auto-incremented integer or a UUID, deliberately carrying no semantics: it is not derived from the customer's name or email precisely so that a name change or email change cannot invalidate it.^[3] This is the opacity discipline the prime names, made concrete — natural keys are rejected as primary keys exactly because their semantic content makes them fragile at the points where the content changes. The resolver is the table itself: the mapping from surrogate key to the current row is the maintained lookup, and the database engine guarantees it. The scope of identity is declared by the schema — "the same customer," not "the same customer-with-this-address" — so an address update preserves identity while the row mutates underneath the unchanged key. The decoupling relation is visible in foreign keys: every other table references the customer by the opaque surrogate, so when the customer's natural attributes change, only the customer row is updated and every foreign-key reference remains valid — the prime's N-to-1 compression, where N referencing rows point at one resolver rather than each embedding mutable natural attributes. The critical-path consequence is equally concrete: the integrity of every foreign-key reference depends on the surrogate-key column and its uniqueness constraint, so corruption or re-use of a surrogate key (the resolver failing) invalidates every dependent reference at once. The prime's tombstoning discipline appears as the soft-delete pattern — marking a row inactive rather than deleting it so that historical foreign-key references still resolve to an explanatory record — and its aliasing/merging discipline appears as the merge problem when two customer records turn out to be one entity, requiring the resolver to redirect.^[3]

Mapped back: The surrogate key realises every role — opaque token, resolver-as-table, declared scope, reference-decoupled-from-storage via foreign keys, and resolver-as-critical-path — and the rejection of natural keys is the opacity discipline, while soft-delete and record-merge are tombstoning and aliasing in executable form.

Applied/industry¶

A scholarly-publishing infrastructure assigning Digital Object Identifiers to articles is the applied instance where the prime's institutional commitment becomes unmistakable. The referenced entity is a published article whose hosting location, file format, and even publisher may change over decades. The stable token is the DOI string, opaque and assigned once — crucially not a URL, because a URL encodes the article's current location and therefore breaks the moment the publisher migrates servers, which is exactly the link-rot failure the prime diagnoses as "used as if persistent when no resolver was maintained behind it."^[8] The resolver is the central DOI resolution service, which maps the DOI to the article's current URL, so a reader who clicks a decade-old DOI citation is silently forwarded to wherever the article now lives.^[2] The scope of identity is declared at the level of the published version of record — the same intellectual contribution as published — distinguishing a DOI's promise from a finer-scoped content hash that would change with any byte-level revision. The decoupling relation is the entire value proposition: a citation embedding a DOI is safe to print, forward, and archive because the resolver, not the embedded string, absorbs every subsequent publisher migration, reorganization, or format change. The critical-path consequence is the prime's sharpest applied lesson and the reason it foregrounds the institutional question as structural rather than optional: the resolver is long-lived critical infrastructure, and durable identifier schemes are invariably backed by long-lived, funded registration agencies precisely because an unfunded resolver that lapses takes every dependent citation down with it.^[2] The identical resolver-token-scope triple governs a museum accession number — an opaque token that follows an object through cataloguing, conservation, loan, and storage while its attribution and location all change, with the museum's registry as the maintained resolver — and a livestock ear tag persisting across an animal's transfer between monitoring programs, so a curator, a publisher, and a wildlife biologist are running the same infrastructure pattern, each trading an unbounded distributed maintenance burden for one governed institution.^[4]

Mapped back: The DOI system instantiates the opaque token (deliberately not a URL), the central resolver, the version-of-record scope, the decoupling that makes citations migration-proof, and the resolver-as-funded-institution critical path — link rot is the prime's failure mode of a token with no maintained resolver, and accession numbers and ear tags are the same triple in non-publishing substrates.

Structural Tensions¶

T1 — Temporal: Persistence Is a Promise Across Time the Present Cannot Verify. The prime's whole value is the commitment that the token keeps resolving across future change, but that commitment is unfalsifiable at mint time — persistence is only ever demonstrated retrospectively, and a scheme is "persistent" exactly until the resolver lapses. The failure mode is treating the persistence guarantee as a property of the token (it looks durable) rather than a standing obligation of an institution that may not outlive the references. Diagnostic: ask not whether the identifier is persistent but whether the resolver is funded and governed for the horizon the references need; persistence is a forward promise whose collateral is institutional continuity, and a token from a defunded registry is a dead link that has not failed yet.

T2 — Coupling: Opacity Versus Human Usability. The prime mandates opacity — no semantics in the token — to protect it from content change. But opacity trades against usability: humans cannot sanity-check, deduplicate, or detect errors in a fully opaque string, and the temptation to encode a hint (a year, a type, a custodian) is constant. The failure mode is smuggling semantics back into the token for convenience, reintroducing the fragility opacity was meant to remove at exactly those encoded points. Diagnostic: ask whether any substring of the token carries meaning a consumer might rely on; where it does, that meaning is a future break point, and the resolution must be to carry semantics in the resolver's metadata, never in the token itself, however inconvenient.

T3 — Scopal: The Scope of Identity Determines What Survives, and Is Easy to Mis-Set. The prime requires declaring "the same what" — work, expression, manifestation, item — but the scope choice silently bounds every persistence guarantee, and a scope set too fine or too coarse breaks references that assumed otherwise. The failure mode is minting at one scope (the version of record) while consumers cite as if at another (this exact byte sequence), so a legitimate revision either breaks finer-scoped references or silently changes what coarser-scoped ones resolve to. Diagnostic: ask what change the identifier is promised to survive and what change should mint a new identifier; the scope is the contract, and references made under a different assumed scope are mismatches waiting for the first revision to expose them.

T4 — Scalar: The Resolver Concentrates Risk It Was Meant to Distribute. The prime's N-to-1 compression is its efficiency claim — many fragile references collapse onto one maintained mapping. But the same move concentrates catastrophic risk: the resolver becomes a single point of failure whose compromise, capture, or lapse invalidates every dependent reference at once, a failure mode no distributed scheme has. The failure mode is celebrating the compression while ignoring that it converted many independent small risks into one correlated total-loss risk. Diagnostic: ask what happens to all references if the resolver fails, is captured, or is censored; the concentration that makes the scheme efficient also makes it a high-value target and a systemic dependency, and resilience (mirroring, federation, succession planning) must be designed for the resolver specifically.

T5 — Sign/Direction: Tombstoning Versus the Right to Erasure. The prime's withdrawal discipline says the token must always resolve — to a tombstone explaining withdrawal, never to nothing — so prior reliance stays diagnosable. But this collides with legitimate demands for actual erasure (privacy law, defamation, safety), where the requirement is that the entity become genuinely unreferenceable. The failure mode is mechanically tombstoning where erasure was required, leaving a resolvable trace of what was supposed to vanish. Diagnostic: ask whether the withdrawal requires diagnosability of prior reliance (tombstone) or non-referenceability (erasure); the two are opposite obligations, and the persistent-identifier default of always-resolve is wrong for the erasure case, where the scheme must support genuine removal with controlled breakage.

T6 — Coupling: Aliasing and Merging Strain the One-Token-One-Entity Model. The prime's clean model is one stable token per scoped entity, but reality forces splits and merges — two identifiers found to denote one entity, or one entity that forks into two — and the resolver must represent same-as and split-from relations the simple model omits. The failure mode is treating identity as fixed at mint time, so when entities merge or split the scheme either creates duplicate authoritative tokens or destroys references by collapsing them. Diagnostic: ask whether the resolver can represent "these two tokens now denote one entity" and "this token's entity has split" without breaking existing references; where it cannot, the one-token-one-entity assumption will be violated by the first merge or fork, and identity must be modeled as a maintained relation, not a permanent fact.

Structural–Framed Character¶

Persistent Identifier sits in the mixed-framed band of the structural–framed spectrum, consistent with its grade of 0.6. There is a real relational skeleton — a stable opaque token, a separately-maintained resolver, and a declared scope of identity, with the decoupling of reference from storage as the structural payoff — but the prime is constitutively a human-institutional infrastructure pattern that does not exist outside designed reference systems, which places it past the middle.

Two diagnostics drive the grade, both at the top of the scale. Institutional origin is maximal: the resolver is, by the prime's own central claim, long-lived critical infrastructure with its own governance, funding, and continuity requirements — durable identifier schemes are invariably backed by long-lived institutions, and the pattern is a designed, operated commitment rather than a formal relation. Human-practice-boundedness is likewise maximal: a persistent identifier does not occur in physical or biological substrate; it requires an operator who guarantees the resolver, so the entire construct presupposes a maintaining institution. The remaining diagnostics sit at the midpoint, each leaning framed. Vocabulary-travel is mid: the token/resolver/scope triple survives the strip-the-jargon test across DOIs, ORCIDs, accession numbers, surrogate keys, and ear tags, but applying it pulls along a reference-infrastructure lexicon. Import-versus-recognize is mid: invoking the prime recognizes a real decoupling structure but also imports the institutional-continuity apparatus that is its distinctive cargo. The one diagnostic that reads clean structural is evaluative weight: a persistent identifier is value-neutral, a durable-reference contract carrying no inherent approval. The relational skeleton is genuine — and even reaches into administrative-biological cases like ear tags — but the prime's constitutive dependence on a funded, governed resolver, an artifact of human institutions, places it correctly past the middle, as mixed-framed.

Substrate Independence¶

Persistent Identifier is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. Its domain breadth is real but bounded: the stable-token-plus-resolver-plus-scope pattern recurs across scientific data infrastructure (DOIs, ORCIDs, accession numbers), publishing and bibliography (ISBN/ISSN and the work/expression/manifestation/item distinction), web architecture (names-not-locations), databases (surrogate keys and foreign keys), museums and archives (accession numbers), logistics (serial numbers, container codes), healthcare (medical record numbers), and animal husbandry (ear tags) — but every one of these is a reference infrastructure, an essentially administrative or infrastructural substrate. Its structural abstraction sits at the middle because, while the three-piece signature (stable opaque token, separately-maintained resolver, explicit scope of identity) is relational, the resolver-machinery commitment is constitutively a human practice — someone must maintain the resolver as infrastructure — so the pattern carries an institutional commitment rather than running medium-free. Transfer evidence runs higher: the surrogate-key-over-natural-key discipline and the scope-of-identity contract carry identically across DOIs, primary keys, and accession numbers. What caps the composite at the middle is that there is no physical or biological substrate where persistent identification operates absent a maintained resolver and an institution promising durability — the pattern travels broadly but only within reference-infrastructure domains.

Composite substrate independence — 3 / 5
Domain breadth — 3 / 5
Structural abstraction — 3 / 5
Transfer evidence — 4 / 5

Relationships to Other Abstractions¶

Current abstraction Persistent Identifier Prime

Parents (3) — more general patterns this builds on

Persistent Identifier is a kind of Indirection Prime

A persistent identifier is a specific, committed, institutionally-maintained indirection (opaque token and declared scope and guaranteed resolver) — a specialization of the bare indirection technique with a standing institutional obligation.
Persistent Identifier presupposes Identifier Assignment Prime

A Persistent Identifier presupposes the prior Identifier Assignment that minted its opaque handle and installed the authoritative entity binding.
Persistent Identifier presupposes, typical Traceability Prime

The stable handle is what lets provenance/traceable records stay referenceable across substrate change; presupposes the traceability infrastructure it underwrites.

Children (4) — more specific cases that build on this

Community Identification Number Domain-specific is a kind of Persistent Identifier

The proposed strict upward parent is prime:persistent_identifier.
SoftWare Hash IDentifier Domain-specific is a kind of Persistent Identifier

The proposed strict upward parent is prime:persistent_identifier.
Authority Record Domain-specific is part of Persistent Identifier

A Persistent Identifier is the record's strict machine-stable constituent, cited by descriptive records so name edits propagate without rewriting citations.

▸ Show 1 more

Neighborhood in Abstraction Space¶

Persistent Identifier sits among the more crowded primes in the catalog (20^th percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.

Family — Naming, Reference & Identifiers (8 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-10

Not to Be Confused With¶

The embedding-nearest confusion is with versioning, and the two genuinely interlock — a persistent identifier often names a version — but they solve different problems. Versioning is the machinery for managing an artifact's successive and parallel states: it tracks what changed, when, and how the states relate, and its central concern is the evolution itself. A persistent identifier's central concern is the opposite: keeping a single reference resolving durably across change, whether that change is a new version, a server migration, a custodian transfer, or a reformatting. The distinction is sharpest in the cases where one exists without the other. A retracted paper, a repealed statute, or a museum object has a persistent identifier but no versioning structure — there is no evolving sequence of states, just one entity that must stay referenceable. Conversely, a versioning system can manage states without any commitment to durable external reference. They compose cleanly (a persistent identifier can be minted per version, at a declared scope), but conflating them leads to two errors: treating a persistent identifier as if it must track state (and breaking when it is asked to resolve a standalone entity with no versions), or treating a version control system as if it guarantees durable reference (when it makes no resolver commitment to the outside world). The prime's scope-of-identity role is exactly what mediates the relationship — it declares which changes the identifier survives and which mint a new one — but that role is a property of the reference contract, not of version management.

A second genuine confusion is with indirection. A persistent identifier is, mechanically, an indirection: a token that points through a resolver to the entity, rather than naming the entity's location directly. So it is tempting to say it is "just indirection." But indirection is a general technique — any extra level of pointing, from a pointer in memory to a DNS lookup to a forwarding address — whereas a persistent identifier is a specific, committed, institutionally-maintained indirection with three additional load-bearing commitments the bare technique lacks: opacity (the token carries no mutable semantics), a declared scope of identity (the persistence promise is bounded to "the same what"), and a guaranteed, funded, governed resolver whose continuity is the whole point. Plain indirection adds a level of pointing; a persistent identifier adds a standing institutional obligation that the pointing keeps working across decades of substrate change. The distinction matters because reasoning about a persistent identifier as mere indirection misses the critical-path consequence — that the resolver becomes long-lived infrastructure requiring funding and governance — which is exactly the part that fails in practice (link rot is a maintained-resolver failure, not a missing-pointer failure).

A third confusion worth drawing is with naming_convention, and here the two are not merely distinct but opposed in design philosophy. A naming convention deliberately encodes meaning into the name — a filename with a date and project code, a variable named for its type — so that humans can read, sort, and sanity-check the identifier at a glance. A persistent identifier mandates the reverse: opacity, no semantics in the token, precisely because any encoded meaning (a year, a custodian, a location) becomes a future break point the moment that meaning changes. The prime's T2 tension is exactly this collision — the constant temptation to smuggle a human-readable hint into the token, reintroducing the fragility opacity was meant to remove. The distinction is load-bearing because the two answer different needs: a naming convention optimizes for human legibility and error-detection, a persistent identifier optimizes for durability against content change, and you cannot maximize both in the same string. The resolution the prime prescribes — carry semantics in the resolver's metadata, never in the token — is precisely a recipe for keeping the naming-convention benefits without sacrificing the persistence the opaque token provides.

For a practitioner these distinctions determine whether the durability guarantee is real. Mistake a persistent identifier for versioning and you either over-burden it with state tracking or wrongly trust a VCS to guarantee external reference; mistake it for bare indirection and you forget the resolver is funded critical infrastructure; mistake it for a naming convention and you encode semantics that become the break points. The prime earns its keep by binding the opaque token, the declared scope, and the maintained resolver into one durable-reference contract that none of these neighbors supplies alone.

Solution Archetypes¶

Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.

Built directly on this prime (7)

Also a related prime in 6 archetypes

Collision-Free Mapping Design: Protect source distinctions by ensuring that no two distinct inputs map to the same target unless an explicit, reviewed merge is intended.
Deferred Fulfillment Placeholder: Create a first-class placeholder for a committed future value so dependent work can proceed, compose, wait, cancel, or fail explicitly before the value exists.
Entity Individuation Criteria Design: Make entity identity explicit by defining unity, same-as, persistence, split/merge, and countability rules before records, identifiers, rights, measurements, or decisions depend on them.
Event-Log-Centered Modeling: Preserve happenings as the primary record and derive entity state, relationships, places, periods, timelines, and summaries as reproducible projections of the governed event log.
Evidence-Bound Authentication: Grant trust, access, or evidential weight only after an asserted identity or origin is bound to admissible evidence and returned as a scoped authentication verdict.
Open Reuse Publication Infrastructure: Make an artifact reusable by strangers by publishing it as a stable, openly accessible, license-clear, machine-readable, versioned, and maintained public dependency rather than as a private handoff.

References¶

[1] Kahn, Robert, and Robert Wilensky. "A Framework for Distributed Digital Object Services". International Journal on Digital Libraries, vol. 6, no. 2 (2006): 115–123 (orig. D-Lib Magazine, 1995). Defines digital objects identified by a handle, with a distributed system of handle servers mapping handles to network resources — opaque token plus separately operated resolver as durable-reference infrastructure. registry ↩

[2] Paskin, Norman. "Digital Object Identifier (DOI) System". In Encyclopedia of Library and Information Sciences, 3^rd ed., 1586–1592. Boca Raton: CRC Press, 2010. Describes the DOI as a managed, opaque, resolver-backed identifier maintained by funded registration agencies, contrasted with location-bound URLs and link rot. registry ↩a ↩b ↩c

[3] Date, C. J. An Introduction to Database Systems. 8^th ed. Boston: Addison-Wesley, 2004. Standard treatment of surrogate versus natural keys, foreign-key referential integrity, and why opaque system-assigned keys insulate references from attribute change. registry ↩a ↩b ↩c

[4] ICOM/CIDOC. Statement of Principles of Museum Documentation. International Committee for Documentation (ICOM-CIDOC). Establishes the accession number as an opaque, permanent identifier that follows an object through cataloguing, conservation, loan, and storage. registry ↩a ↩b

[5] GS1. GS1 General Specifications. Brussels: GS1, 2015. Defines GTINs, Serial Shipping Container Codes (SSCC), and serial-number schemes designed to persist across repainting, re-registration, and ownership change. registry ↩

[6] IFLA Study Group on the Functional Requirements for Bibliographic Records. Functional Requirements for Bibliographic Records (FRBR): Final Report. Munich: K. G. Saur, 1998. Establishes the work/expression/manifestation/item distinction — the scope-of-identity ladder for bibliographic identifiers. registry ↩

[7] Smith, Arfon M., Daniel S. Katz, and Kyle E. Niemeyer. "Software Citation Principles". PeerJ Computer Science, vol. 2 (2016): e86. Extends persistent-identifier/resolver infrastructure to research software as a citable, moving-target output. registry ↩

[8] Berners-Lee, Tim. "Cool URIs Don't Change". W3C Style note, 1998. Argues that good identifiers are designed for simplicity, stability, and manageability — as names not locations — so that citation does not break when a server moves. registry ↩