Replacement Relation¶

Record that a distinct successor resource takes over a predecessor's canonical standing and flags it obsolete, as a bidirectional machine-routable link, so consumers read currency off the chain rather than inspecting the artifacts themselves.

Core Idea¶

A replacement relation is a directed, time-asymmetric assertion that one resource — the successor — supersedes another — the predecessor — for a stated function or context, with the predecessor simultaneously marked obsolete and downstream consumers directed to migrate. Three structural roles are always present: predecessor (the thing being replaced), successor (the thing doing the replacing), and role-context (the function for which the successor now stands in). The defining feature is role-transfer with a deprecation flag: this is not the same resource revised in place (revision), not a second name added to the same resource (aliasing), and not a sequentially numbered edition with no obsolescence claim (versioning) — it is a new resource taking over a prior resource's canonical standing, with the prior resource explicitly retired from that standing. Operationalized in Dublin Core / DCMI Terms as the bidirectional pair dcterms:isReplacedBy (on the predecessor) and dcterms:replaces (on the successor), making the relation machine-routable in both directions.

The mechanism is the same across substrates: ISO 9001:2015 carries isReplacedBy pointing to the next edition and replaces pointing to ISO 9001:2008; RFC 8446 headers list "Obsoletes: RFC 5246"; a Python library deprecates a function with @Deprecated(replacement = "newFn"); a clinical-decision-support registry marks CDS-127 superseded by CDS-340 with a transitional banner for legacy charts. In each case the replacement relation encodes a governance decision — hard replacement (predecessor immediately invalid, forcing migration) or soft replacement (a transitional coexistence window) — and the choice between them trades migration disruption against fragmentation risk. The bidirectional pair lets any consumer either follow the chain forward to the current canonical resource or walk it backward to predecessors for archival, reproducibility, or legacy-compatibility purposes.

Structural Signature¶

Sig role-phrases:

the predecessor — the resource being superseded and stripped of its canonical standing
the successor — the distinct resource taking over the predecessor's role
the role-context — the stated function for which the successor now stands in (allowing partial, per-context obsolescence)
the deprecation flag — the obsolescence mark on the predecessor; role-transfer-plus-deprecation is the defining feature that picks replacement out
the bidirectional pair — dcterms:replaces / dcterms:isReplacedBy, making the relation machine-routable forward (live successor) and backward (predecessors)
the four-way cut — the boundary distinguishing replacement from revision (in-place edit), aliasing (added name, no time-arrow), and versioning (editions, no obsolescence claim)
the hard/soft governance choice — the recorded decision: hard (predecessor immediately invalid, forced migration) versus soft (transitional coexistence window), trading migration disruption against fragmentation risk
the read-currency-off-the-chain affordance — consumers judge authority by traversing the relation, not by inspecting artifact content
the cycle failure-check — a replacement cycle (A replaces B, B replaces A) visible in the chain as a modelling error (or a signal to inspect governance history)
the governance-convention limitation — DCMI machinery and lifecycle naming, not a substrate-independent force; off-substrate the content belongs to substitutability plus an emergent supersession pattern

What It Is Not¶

Not revision. Revision modifies the same resource in place; replacement introduces a distinct successor that takes over the predecessor's canonical standing and explicitly retires it. The test is whether the predecessor still holds its role (revision) or has been stripped of it (replacement) — and mislabeling a true supersession as a revision leaves obsolete resources presenting as current.
Not versioning. Versioning issues sequentially numbered editions of one resource family with no obsolescence claim; replacement carries a deprecation flag that marks the predecessor no-longer-canonical for the role. Numbered editions without an arrow of retirement are versioning, not replacement.
Not aliasing. Aliasing adds a second name to the same resource and is time-symmetric — neither name supersedes the other. Replacement is directed and time-asymmetric: predecessor → successor, with the predecessor demoted. An added name is not a role-transfer.
Not substitutability. Substitutability is the symmetric property that one component can fill another's role under a shared interface (interchangeable parts, polymorphic types); replacement is directed supersession carrying an arrow of time and a deprecation flag substitutability lacks. Mere role-fillability with no obsolescence and no time-order is not a replacement claim.
Not dependency or inheritance. A successor may normatively reference its predecessor, but the replacement relation is the succession claim itself, not the reliance; and inheritance is a child taking structure from a parent, whereas replacement is a successor taking a role with the predecessor's obsolescence. The succession arrow is neither a dependency edge nor a structural-inheritance edge.
Not a substrate-independent supersession force. The role-takeover content sits with substitutability and a broader (still-emergent) supersession pattern that would unify document replacement with paradigm change, technology S-curves, and species succession. The replacement relation is the document- and standards-governance instance with its dcterms:replaces/isReplacedBy pair and transitional-banner machinery; the time-asymmetric, obsolescence-flagged qualification is a lifecycle convention, not a new structural force, so the cross-domain lesson belongs to those parents.

Scope of Application¶

A replacement relation is a recorded metadata link rather than a mechanism, so it appears wherever its precondition holds: a distinct successor resource takes over a predecessor's canonical standing, the predecessor is flagged obsolete, and consumers need a machine-routable forward/backward edge to find the live resource or recover what it retired. The habitats below are genuine uses of the same construct (the directed dcterms:replaces / isReplacedBy pair, or its domain equivalent), not analogies; its edge is the precondition — the broader metaphor of one thing superseding another (paradigm change, S-curve generations, species succession) belongs to a more general supersession pattern, not to this recorded relation.

Standards and regulations — a core habitat. ISO 9001:2015 carries isReplacedBy/replaces against the 2008 edition with a transitional period; an RFC's "Obsoletes:" header points to the standard it supersedes; a new regulation supersedes an older directive.
Software versioning and deprecation. API v2 over v1, Python 3 over Python 2 with migration tooling, and source-level annotations like @Deprecated(replacement="newFn") all record a successor and retire the predecessor.
Technical-document and dataset versioning. A v2.0 release supersedes v1.0 while v1.0 is preserved for reproducibility, with the obsolescence recorded on the link rather than the artifact.
Taxonomic revision. Nomenclatural databases record a senior synonym superseding a junior one when a synonymy is resolved, with the predecessor retained in the literature record.
Industrial and product lifecycle. Parts catalogues maintain replacement links from a decommissioned part to its successor to support continued service.
Policy and procedure governance. An updated SOP supersedes an older one with a recorded cut-over date, marking the predecessor no longer canonical for the role.

Clarity¶

Naming a change as replacement — rather than the loose "update" or "new version" — separates four moves on a resource over time that governance practice constantly conflates. Revision is the same resource modified in place; aliasing adds a second name to the same resource with no temporal direction; versioning issues sequentially numbered editions of one resource family with no obsolescence claim; replacement introduces a distinct resource that takes over a prior one's canonical standing while explicitly retiring it from that standing. The defining feature that picks replacement out is role-transfer with a deprecation flag — and recognizing it tells a steward whether the predecessor still holds its role (revision, versioning) or has been stripped of it (replacement). Mislabeling here has teeth: treating a true supersession as a mere revision leaves obsolete resources presenting as current, and consumers acting on retired guidance.

The relation also makes a lifecycle navigable in both directions, which sharpens the questions a consumer can ask. Because obsolescence is recorded on the relation rather than only on the resource, one can resolve forward — "what is the live successor?" — to reach current canonical standing, or walk backward — "what did this replace?" — for archival, reproducibility, or legacy-compatibility purposes, and can express partial obsolescence where a predecessor stays valid for some contexts while retired for others. It further forces an explicit governance choice the field is built to encode: hard replacement, invalidating the predecessor at once and forcing migration, versus soft replacement, allowing a transitional coexistence window. Stating that choice in the relation turns "migration disruption versus fragmentation risk" from an implicit cost into a decision a registry can record and a consumer can read.

Manages Complexity¶

The history of an evolving artifact — successive standards editions, deprecated APIs, dataset versions, superseded rules — is, without an explicit relation, an undifferentiated pile of documents from which a consumer holding any one reference must somehow determine whether it is still authoritative and, if not, what now carries its standing, by reading and comparing the artifacts themselves. The replacement relation compresses that pile into a directed, navigable chain governed by a small fixed vocabulary. Each link records exactly three roles — predecessor, successor, role-context — plus an obsolescence flag, and because the relation is stored as the bidirectional dcterms:replaces / dcterms:isReplacedBy pair, the whole lifecycle becomes machine-routable in both directions. A consumer no longer inspects the artifacts to judge currency; he follows the chain forward to resolve the live canonical successor, or walks it backward to recover predecessors for archival, reproducibility, or legacy use, reading currency off the chain rather than re-deriving it from content. The relation also reduces the open question "how should this change be handled?" to a single recorded governance choice with a fixed branch structure: hard replacement invalidates the predecessor at once and forces migration, soft replacement opens a transitional coexistence window — and that one flag, plus an optional context-scope for partial obsolescence, is what the steward sets and the consumer reads to know whether to migrate now, migrate within a window, or keep using the predecessor for the contexts where it remains valid. The same reduction also exposes a clean failure check: a replacement cycle (A replaces B, B replaces A) is visible directly in the chain as a modelling error. So the high-dimensional "is this current, what superseded it, and must I move?" problem collapses to three roles per link, one hard/soft flag, and forward/backward traversal of a directed chain — and the chain's distinctness from revision, aliasing, and versioning, which the Clarity section draws, is exactly what keeps each tracked artifact in the right one of those four buckets so the traversal means what it says.

Abstract Reasoning¶

The replacement relation licenses a set of reasoning moves built on two structural facts: that the relation is directed and time-asymmetric (predecessor → successor, with an obsolescence flag), and that it is stored as a bidirectional pair, so the lifecycle can be traversed and reasoned over in both directions.

Diagnostic — read currency off the chain, not the artifact, and resolve forward or backward as the need dictates. The characteristic inference refuses to judge an artifact's authority by inspecting its content. Holding any one reference, the analyst follows the isReplacedBy edge forward to resolve the live canonical successor, or walks replaces backward to recover predecessors for archival, reproducibility, or legacy use — reading currency off the relation rather than re-deriving it from the documents. Because obsolescence is recorded on the relation rather than only on the resource, the move supports a sharper read than "current or not": a predecessor can be partially obsolete, retired for some contexts (current production, new contracts) while still valid for others (reproducing a historical recommendation, legacy compatibility), so the analyst infers validity per context from the relation's scope rather than treating the artifact as wholesale live or dead. The inference runs from "I have a reference" to "the chain tells me whether it still holds its role, and if not, what does."

Diagnostic of change-type — classify the move as replacement only when role-transfer-plus-deprecation is present, and route the other three elsewhere. The concept's sharpest move is to pick replacement out of four look-alikes by testing for its defining feature. Revision is the same resource modified in place; aliasing adds a second name with no temporal direction; versioning issues sequentially numbered editions with no obsolescence claim; replacement introduces a distinct resource that takes over a prior one's canonical standing while explicitly retiring it. The inference runs from the structure of the change to the right bucket: ask whether the predecessor still holds its role (revision, versioning) or has been stripped of it (replacement). The stakes are operational — mislabeling a true supersession as a mere revision leaves obsolete resources presenting as current and consumers acting on retired guidance — so the move is to withhold the replacement classification unless both role-transfer and the deprecation flag are present, and to route in-place edits, added names, and obsolescence-free editions to their own categories.

Interventionist — encode the hard/soft governance choice in the relation, and predict the trade-off each branch forces. Because the relation is where the governance decision lives, the move is to set the obsolescence flag deliberately and predict its consequences. A hard replacement invalidates the predecessor at once and forces migration, predicting eliminated fragmentation at the cost of migration disruption; a soft replacement opens a transitional coexistence window, predicting reduced migration shock at the cost of an extended maintenance burden and fragmentation risk. The choice is read as a position on "migration disruption versus fragmentation risk," and the move turns that implicit cost into a decision a registry can record and a consumer can read — so a steward sets hard-or-soft (plus an optional context-scope and transitional window), and every downstream consumer reads off whether to migrate now, migrate within a window, or keep using the predecessor where it remains valid.

Boundary-drawing and failure-check — separate succession from symmetric substitution, and detect cycles as modelling errors. Two further moves. First, the boundary against symmetric interchangeability: replacement is time-asymmetric supersession with deprecation, distinct from the symmetric property that one component can fill another's role under a shared interface — so the move is to reserve the replacement analysis for a directed succession claim and not conflate it with mere role-fillability that carries no obsolescence and no arrow of time. It is likewise distinct from a successor merely depending on its predecessor (the succession claim is not the reliance) and from transformation of the same artifact (replacement introduces a new artifact). Second, a clean failure-check the directed structure exposes: a replacement cycle (A replaces B, B replaces A) is visible directly in the chain as a modelling error, and the move is to flag it — while recognizing that real systems do produce them (a deprecation reversed after community pushback, a standard re-instated after a failed successor), so the cycle is read as a signal to inspect the governance history, not merely as malformed data.

Knowledge Transfer¶

Within resource governance and versioning the discipline transfers as mechanism, intact. The role-transfer-plus-deprecation test, the four-way cut that picks replacement out of revision, aliasing, and versioning, the read-currency-off-the-chain diagnostic, the hard-versus-soft governance choice, and the bidirectional forward/backward traversal carry without translation across any artifact ecosystem with a successor-supersession lifecycle: standards and regulations (ISO 9001:2015 replacing 9001:2008 with a transitional period; an RFC's "Obsoletes:" header; a regulation superseding a directive), software versioning and deprecation (API v2 over v1, Python 3 over 2 with migration tooling, @Deprecated(replacement=...)), technical-document and dataset versions (a v2.0 superseding v1.0 while preserving v1.0 for reproducibility), taxonomic revision (a senior synonym superseding a junior one while the predecessor remains in the literature), product lifecycle (a replacement part with catalogue links to support service over decommissioning), and policy/SOP cut-overs. The vocabulary (transitional period, deprecation notice, migration tooling, backward-compatibility window) travels with structure preserved, and a particularly clean within-domain transfer is software's semantic-versioning convention ("major increment = breaking replacement; minor/patch = revision") being adopted, under other names, by standards bodies governing dataset and document lifecycles. These are co-substrate governance/lifecycle settings, so the transfer is genuine.

Beyond resource governance the honest account is the third category, with thin daylight: the substrate-independent structural force — time-asymmetric supersession with an obsolescence flag — sits adjacent to existing primes and points at a more general one, while the entry's own DCMI machinery stays home. The role-takeover part is substitutability (one component filling another's role under a shared interface) — except that substitutability is symmetric and replacement is directed, carrying an arrow of time and a deprecation flag substitutability lacks; the time-asymmetric, obsolescence-flagged qualification is more a governance/lifecycle convention than a new substrate-independent force. The genuinely cross-domain pattern, if surfaced, is a broader supersession parent prime that would unify document/standard replacement with Kuhnian paradigm change (a theory superseding its predecessor), technology-generation S-curve replacements, biological-fitness displacement, and ecological species succession — co-instances in which one thing takes over another's canonical standing and the prior is retired. Where that cross-domain lesson is wanted it should be carried by substitutability (for the role-transfer) plus the emergent supersession pattern (for the directed obsolescence), not by "replacement relation" as named, whose distinctive cargo (dcterms:replaces / dcterms:isReplacedBy, the four-way revision/aliasing/versioning/replacement vocabulary, transitional banners, migration channels) is document- and standards-governance furniture. The entry's own negative-space limit confirms this: its distinction discipline ("do not collapse persistence, replacement, revision, and aliasing") operates at the level of resource-lifecycle naming conventions, a governance practice, not at the level of a substrate-independent pattern. So the replacement relation is the document-governance instance; the substrate-spanning content belongs to substitutability and the broader supersession pattern it would instance — exactly the split drawn in Structural Core vs. Domain Accent.

Examples¶

Canonical¶

The IETF's RFC "Obsoletes" header is the relation in its cleanest defining form. RFC 8446, which specifies TLS 1.3 (published 2018), carries in its metadata block "Obsoletes: 5246"; RFC 5246, which specified TLS 1.2 (published 2008), carries the complementary "Obsoleted by: 8446." An engineer holding a reference to RFC 5246 does not read the document to judge whether it is still the standard to implement — the header alone routes forward to 8446 as the live specification, while the reverse pointer lets an archivist or someone maintaining a legacy TLS 1.2 stack walk backward to what 8446 retired. The predecessor is not revised in place and is not merely a lower version number sitting alongside the new one: it is explicitly demoted from canonical standing for new implementations while remaining in the record.

Mapped back: RFC 5246 is the predecessor, RFC 8446 the successor, and "the current TLS specification" is the role-context. The "Obsoletes" / "Obsoleted by" headers are the bidirectional pair and carry the deprecation flag that makes this replacement rather than mere versioning — that presence of both role-transfer and obsolescence is exactly the four-way cut picking it out. An implementer resolving 5246 → 8446 by header is reading currency off the chain, not inspecting the artifact.

Applied / In Practice¶

When ISO published ISO 9001:2015, it superseded ISO 9001:2008, and the governing bodies attached a soft replacement: a three-year transition window (from the September 2015 publication to September 2018) during which certificates issued against the 2008 edition remained valid while organizations migrated their quality-management systems and were re-audited against the new edition. Certification registries and standards catalogues record the supersession as a machine-routable link — the 2008 edition marked "withdrawn" and pointed to its successor. A firm holding a 2008 certificate could read off the relation both that a successor now held canonical standing and that a coexistence window let it keep operating during migration, rather than facing immediate invalidation.

Mapped back: ISO 9001:2008 is the predecessor stripped of canonical standing; ISO 9001:2015 is the successor; "the certifiable QMS standard" is the role-context. The withdrawal-plus-pointer in the catalogue is the bidirectional pair carrying the deprecation flag. The three-year transition period is the paradigm soft branch of the hard/soft governance choice — trading fragmentation risk (two live editions at once) for reduced migration disruption — and a certified firm judging its status by the recorded relation rather than the document is reading currency off the chain.

Structural Tensions¶

T1: Hard versus soft replacement (migration disruption against fragmentation risk). The relation forces one governance choice with no free option. A hard replacement invalidates the predecessor at once, eliminating fragmentation — there is exactly one canonical resource — but forcing every consumer into an abrupt, disruptive migration on the steward's timetable. A soft replacement opens a transitional coexistence window, cushioning the migration shock, but at the cost of two live editions at once: fragmented authority, an extended maintenance burden, and consumers who may linger indefinitely on the predecessor. The RFC "Obsoletes" cut and the ISO 9001 three-year window sit at opposite ends of the same dial. The tension is that the flag cannot minimize both disruption and fragmentation; every setting buys down one by taking on the other, and the "safe" soft choice quietly imports the very fragmentation the replacement was meant to end. Diagnostic: Is the cost you most need to avoid here the shock of forced migration, or the fragmentation of a coexistence window — and does the flag you set match that priority?

T2: Read currency off the chain versus verify the artifact (an affordance only as trustworthy as its curation). The relation's central convenience is that a consumer never inspects the document to judge authority — he follows the edge. That economy is bought by total dependence on the record being correct. If a true supersession was mislabeled a revision, an obsolescence flag was never set, or a stale link points at a withdrawn successor, the consumer confidently reads the wrong currency off a chain that looks authoritative. The very move that saves re-deriving currency from content also removes the cross-check that would catch a bad record. The tension is that trusting the chain is the point and the exposure: the affordance is strongest exactly where the governance discipline behind it is weakest-tested, because no one is looking at the artifact anymore. Diagnostic: Is the chain's authority claim independently maintained and audited, or are you trusting a link precisely where no one still inspects the resource it describes?

T3: Directed acyclicity versus legitimate cycles (modelling error or governance history). The directed structure lets a replacement cycle — A replaces B, B replaces A — be flagged automatically as a malformed chain. But real governance produces such cycles legitimately: a deprecation reversed after community pushback, a standard reinstated after its successor failed, a rolled-back API. Treating every cycle as a data error would erase exactly the episodes most worth recording. The tension is that the same acyclicity assumption which makes the failure-check clean also mislabels valid non-monotonic history as corruption, so the check must be read as "inspect the governance history here," not "delete the malformed edge." Enforce acyclicity too strictly and the model cannot represent the reversals that actually happen; ignore cycles entirely and genuine modelling errors pass. Diagnostic: Is this cycle a bookkeeping mistake to repair, or a real reversal in the resource's governance history that the chain should preserve?

T4: The crisp four-way cut versus changes that blur the boundary (when is a big revision a replacement?). The concept's discriminating power rests on a clean partition — revision, aliasing, versioning, replacement — decided by one test: does the predecessor still hold its role, or has it been stripped of it? Real changes do not always answer cleanly. A "major version" can be so breaking that it is effectively a distinct successor; a revision so sweeping that the prior text no longer functions; a numbered edition that carries an implicit obsolescence no flag records. The tension is that the four buckets are discrete while the underlying continuum of change is graded, so the steward must force a categorical label onto a case that sits between them — and mislabeling has teeth, since a supersession filed as a revision leaves an obsolete resource presenting as current. The test is sharp but its input is a judgment. Diagnostic: Has the predecessor genuinely lost its canonical role (replacement), or is this a large-but-in-place change that keeps the role (revision) — and which way do the borderline features actually cut?

T5: Recorded currency versus de facto authority (the registry is not the practice). The relation records a governance decision — withdrawn, superseded, deprecated — but a recorded status can diverge from operational reality even when correctly entered per the steward's intent. A standard marked withdrawn may still be the one practitioners implement; a library function flagged deprecated may remain in overwhelming production use; a soft window may quietly become permanent as consumers never migrate. The tension is that the relation asserts canonical standing by fiat of the record, while actual authority lives in what consumers do, and the two drift apart precisely across long soft windows. Reading currency off the chain gives the de jure answer, which a consumer may mistake for the de facto one. Diagnostic: Does the chain report where authority has actually moved, or only where the steward has declared it should move while consumers remain on the predecessor?

T6: Single-successor routing versus per-context partial obsolescence (a clean forward answer against contextual validity). The relation's simplest promise is "follow the edge to the one live successor." Its richer expressiveness — partial, per-context obsolescence, where a predecessor stays valid for reproducing a historical recommendation or legacy compatibility while retired for new production — undercuts that simplicity. Once obsolescence is scoped to a role-context, there is no longer a single answer to "is this current?"; the consumer must know his own context to resolve validity, and the chain can say "retired here, live there" for the same artifact. The tension is that the feature which makes the relation honest about real lifecycles (things are rarely wholly dead) is the same feature that dissolves the clean single-successor routing that made it easy to consume. Expressive scoping and one-answer traversal pull against each other. Diagnostic: Does resolving currency here require knowing the consumer's specific context, or does the chain deliver a single live successor regardless of who is asking?

T7: Autonomy versus reduction (a named DCMI relation or an instance of substitutability plus supersession). The replacement relation is a precisely-specified governance construct with proprietary machinery — the dcterms:replaces / isReplacedBy pair, the four-way revision/aliasing/versioning cut, transitional banners, migration channels — and across the resource-governance subfields (standards, software, datasets, taxonomy, product lifecycle) it travels intact as mechanism. But its cross-domain content splits: the role-takeover is substitutability, except substitutability is symmetric while replacement is directed and obsolescence-flagged — and that time-asymmetric, deprecation-carrying qualifier is a lifecycle convention, not a substrate-independent force. The genuinely spanning pattern is a broader supersession parent that would unify document replacement with paradigm change, technology S-curves, and species succession. The tension is between a standalone, auditable, standards-bound relation and the recognition that its portable cargo belongs partly to substitutability and partly to an emergent supersession pattern — with the DCMI apparatus staying home. Diagnostic: Resolve toward substitutability plus the supersession pattern when carrying the one-thing-takes-over-another lesson off-substrate; toward the named replacement relation when routing an actual predecessor→successor link in a resource registry.

Structural–Framed Character¶

The replacement relation sits in the mixed band of the spectrum — pulled toward structure by an evaluatively neutral relational core, pulled toward frame by being an institution-coined governance convention rather than a fact of nature; it shares the profile of its sibling metadata-governance entries. On evaluative_weight it is decisively structural: dcterms:replaces records, it does not convict — asserting that one resource supersedes another passes no praise or blame, and even the "deprecation flag" is a lifecycle status, not a verdict on the predecessor's worth. This neutrality is its strongest structural credential and cleanly separates it from the framed-pole fallacy entries. But on the remaining criteria it leans framed, honestly. Human_practice_bound points framed: the relation is constituted by the human practice of stewarded resource governance and dissolves the instant that practice is removed — there is no "predecessor," "successor," "canonical standing," or "obsolescence" without stewards issuing editions and consumers reading currency; unlike a natural mechanism that runs observer-free, this construct has no referent absent the institution of versioning. Institutional_origin is thoroughly framed: the entry is a designed artifact of a specification body — the Dublin Core / DCMI Terms replaces/isReplacedBy pair, with domain equivalents like the RFC "Obsoletes:" header and ISO's withdrawal-plus-pointer — a made convention with a documented lineage, not a regularity discovered in the world.

Vocab_travels points framed: the operative vocabulary — the bidirectional DCMI pair, the four-way revision/aliasing/versioning/replacement cut, hard/soft transitional windows, migration channels, transitional banners — is pinned to the resource-governance-and-versioning substrate and loses its referents off it, which is why "one thing superseding another" in paradigm change or species succession blurs immediately into a more general pattern. Import_vs_recognize is bimodal and the entry is precise about it: within resource governance (standards, software deprecation, dataset versions, taxonomic revision, product lifecycle, SOP cut-overs) reuse is genuine mechanism-recognition — the identical directed construct recurs as the same thing, co-substrate, not analogy — whereas off the substrate the reach is metaphor carried by the parent primes, not by the dcterms:replaces link itself.

The portable structural skeleton is directed, time-asymmetric supersession: a distinct successor takes over a predecessor's canonical standing and flags it obsolete. That skeleton genuinely travels — to Kuhnian paradigm change, technology S-curves, biological displacement, ecological succession — but it does not make "the replacement relation" itself portable, because it is exactly what the entry instantiates from its parents: substitutability supplies the role-takeover (though only symmetrically), and the directed, obsolescence-flagged qualifier points at a broader, still-emergent supersession prime that would unify all those cross-domain cases. The cross-domain reach belongs to those umbrellas; the replacement relation's own distinctive cargo — the DCMI pair, the four-way cut, the transitional-banner-and-migration-channel machinery — is document- and standards-governance furniture that stays home. And the entry's own "governance-convention limitation" sharpens the framed side: the distinction discipline (do not collapse persistence, replacement, revision, and aliasing) operates at the level of resource-lifecycle naming conventions, a governance practice, not a substrate-independent force. Its character: evaluatively neutral in its core like a structural entry, but a standards-body-coined, versioning-practice-constituted metadata convention whose portable content is the directed-supersession skeleton it borrows from its substitutability and supersession parents — leaving it mixed, neither a convicting frame nor a free-floating prime.

Structural Core vs. Domain Accent¶

This section decides why the replacement relation is a domain-specific abstraction and not a prime, and it also carries the case for why it is domain-specific — so it is worth being exact about what could lift off the metadata substrate and what stays behind as governance convention.

What is skeletal (could lift toward a cross-domain prime). Strip the versioning machinery and a thin relational structure survives: directed, time-asymmetric supersession — a distinct successor takes over a predecessor's canonical standing and flags it obsolete. The portable pieces are abstract — a predecessor stripped of a role, a distinct successor assuming it, and an arrow of time carrying an obsolescence mark. That skeleton genuinely travels, which is why the entry rests on substitutability for the role-takeover — except substitutability is symmetric (one component can fill another's role under a shared interface), while replacement is directed, adding an arrow of time and a deprecation flag substitutability lacks. The directed, obsolescence-flagged qualifier points at a broader, still-emergent supersession parent that would unify document replacement with Kuhnian paradigm change, technology S-curve generations, biological displacement, and ecological species succession. But this is the core the relation shares with those parents, not what makes the replacement relation distinctive — and the time-asymmetric qualifier is itself a lifecycle convention, not a new substrate-independent force.

What is domain-bound. Everything that makes the concept the replacement relation in particular is resource-governance-and-versioning furniture: the bidirectional DCMI pair dcterms:replaces / dcterms:isReplacedBy (and domain equivalents like the RFC "Obsoletes:" header and ISO's withdrawal-plus-pointer); the four-way cut that picks replacement out of revision (in-place edit), aliasing (added name, no time-arrow), and versioning (numbered editions, no obsolescence claim); the hard/soft governance choice trading migration disruption against fragmentation risk; transitional banners and migration channels; and the read-currency-off-the-chain affordance. These are the worked vocabulary and instruments of a specification tradition. The entry's own governance-convention limitation sharpens the boundary: its distinction discipline (do not collapse persistence, replacement, revision, and aliasing) operates at the level of resource-lifecycle naming conventions — a governance practice — not a substrate-independent pattern. The decisive test: strip away stewarded resource governance and there is no "predecessor," "canonical standing," or "obsolescence" — nothing for the directed link to record.

Why this does not clear the prime bar. A prime is a relational structure whose vocabulary travels and whose transfer is recognition of the same mechanism, not analogy. The replacement relation's transfer is bimodal. Within resource governance the identical directed construct recurs as the same thing across standards and regulations, software deprecation, dataset versions, taxonomic revision, product lifecycle, and SOP cut-overs — co-substrate mechanism-recognition, not likeness, and even the semantic-versioning convention ("major = breaking replacement; minor/patch = revision") ports across document and dataset lifecycles under other names. Beyond the substrate — one thing superseding another in paradigm change, technology generations, or species succession — the reach is metaphor carried by the parents, not by the dcterms:replaces link, whose operative vocabulary loses its referents off-substrate. So the cross-domain reach belongs to substitutability (for the symmetric role-takeover) plus the emergent supersession pattern (for the directed obsolescence); the replacement relation is their document-governance operationalization, clearing the domain-specific bar for resource versioning while its portable skeleton is already carried, in more general form, by the primes it would instance.

Relationships to Other Abstractions¶

Current abstraction Replacement Relation Domain-specific

Parents (1) — more general patterns this builds on

Replacement Relation is a kind of Supersession Prime

Replacement Relation is the machine-routable resource-metadata species of Supersession: a distinct successor displaces a predecessor in one role.

Hierarchy paths (2) — routes to 2 parentless roots

Replacement Relation → Supersession → Relation

Show alternative path (1)

Not to Be Confused With¶

Deprecation (standalone). Marking a resource obsolete without naming a distinct successor to take over its role — a function flagged deprecated with no replacement= target, a standard withdrawn with nothing pointed to. The obsolescence flag is present, but the defining role-transfer is missing: replacement requires a successor assuming the predecessor's canonical standing, not merely the predecessor's retirement. Tell: does the record name a successor that takes over the role (replacement), or only mark the predecessor obsolete with no one stepping into its standing (bare deprecation)?
Withdrawal / retraction. Pulling a resource from canonical standing with no replacement at all — a retracted paper, a cancelled regulation, a discontinued part with no successor. Like standalone deprecation it carries retirement but, unlike replacement, supplies no successor for the forward edge to resolve to; the chain simply ends. Tell: can a consumer follow the link forward to a live successor (replacement), or does the predecessor terminate with nothing taking its place (withdrawal)?
Redirect (e.g. HTTP 301 / URL redirection). A routing mechanism that resolves a request for an old address to a new location. It moves access, not canonical standing, and need carry no obsolescence semantics, no role-context, and no backward replaces edge; replacement is a governance assertion that a distinct successor superseded a predecessor and retired it, machine-routable in both directions. Tell: is the pointer forwarding a request to a new address (redirect), or asserting a directed, deprecation-flagged supersession of one resource by another (replacement relation)?
Canonical link (e.g. rel=canonical). A designation of which of several coexisting equivalent or duplicate resources is the preferred one. It is time-symmetric and involves no retirement — the alternatives remain valid — so it resembles aliasing more than supersession; replacement is directed, time-asymmetric, and demotes the predecessor. Tell: does the link pick the preferred one among coexisting equivalents with none retired (canonical link), or retire a predecessor in favor of a distinct successor over time (replacement)?
Migration. The actual work of moving consumers, data, or implementations from the predecessor to the successor. Migration is the activity the governance choice provokes; the replacement relation is the recorded link that declares the supersession and against which migration is timed (the hard/soft flag sets its urgency). One is the process, the other the assertion. Tell: is this the labor of moving off the predecessor (migration), or the recorded predecessor→successor supersession edge that governs when and whether that labor happens (replacement relation)?
The role-takeover primes it instantiates (substitutability plus the emergent supersession pattern). The substrate-free content — a successor filling a predecessor's role, with a directed arrow of time and an obsolescence mark — that the relation composes from its parents; substitutability supplies the (symmetric) role-fillability and the emergent supersession pattern the directed obsolescence. These carry the one-thing-takes-over-another lesson off-substrate (paradigm change, S-curves, species succession); the replacement relation is the DCMI-governance operationalization, treated more fully under those umbrellas. Tell: strip away stewarded resource governance and the dcterms:replaces/isReplacedBy machinery — if a substrate-free supersession pattern remains, that is the parent, not the replacement relation.

Neighborhood in Abstraction Space¶

Replacement Relation sits in a sparse region of the domain-specific corpus (70^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Managing Exceptions & Change (5 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12