Skip to content

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, with the predecessor marked obsolete and consumers directed to migrate. Three roles are always present: predecessor, successor, and role-context. Its defining feature is role-transfer with a deprecation flag: not the same resource revised in place, not a second name added, and not a numbered edition, but a new resource taking over a prior one's canonical standing. It is operationalized in Dublin Core as the bidirectional pair dcterms:isReplacedBy and dcterms:replaces.

Scope of Application

A recorded metadata link rather than a mechanism, it appears wherever a distinct successor takes over a predecessor's standing, the predecessor is flagged obsolete, and consumers need a routable forward/backward edge.

  • Standards and regulations — ISO 9001:2015 replacing 9001:2008; an RFC's "Obsoletes:" header.
  • Software versioning and deprecation — API v2 over v1, @Deprecated(replacement=...).
  • Technical-document and dataset versioning — a v2.0 superseding v1.0 while preserving it for reproducibility.
  • Taxonomic revision — a senior synonym superseding a junior one, predecessor retained in the literature.
  • Industrial product lifecycle — replacement links from a decommissioned part to its successor.
  • Policy and procedure governance — an updated SOP superseding an older one at a recorded cut-over.

Clarity

Naming a change as replacement separates four moves governance constantly conflates: revision (same resource modified in place), aliasing (a second name, no time direction), versioning (numbered editions, no obsolescence claim), and replacement (a distinct resource taking over a prior one's canonical standing while retiring it). The picking-out feature is role-transfer with a deprecation flag. It also makes the lifecycle navigable in both directions — resolve forward to the live successor or walk backward to predecessors — and forces the explicit hard-versus-soft governance choice, turning "migration disruption versus fragmentation risk" into a recorded decision.

Manages Complexity

The history of an evolving artifact is, without an explicit relation, an undifferentiated pile from which a consumer must determine authority by reading the artifacts themselves. The replacement relation compresses that pile into a directed, navigable chain: each link records three roles plus an obsolescence flag, stored as the bidirectional pair so the whole lifecycle is machine-routable both ways. A consumer reads currency off the chain rather than the content. The open "how should this change be handled?" reduces to one hard/soft flag plus an optional context-scope, and a replacement cycle is visible directly as a modelling error.

Abstract Reasoning

The relation licenses diagnostic reasoning (reading currency off the chain, resolving forward or backward, and inferring per-context validity from partial obsolescence), change-type classification (picking replacement out of revision, aliasing, and versioning by testing for role-transfer plus deprecation), interventionist reasoning (encoding the hard/soft governance choice and predicting the migration-versus-fragmentation trade-off each branch forces), and boundary-drawing plus a failure-check (separating directed succession from symmetric substitutability and dependency, and detecting cycles as modelling errors or governance-history signals).

Knowledge Transfer

Within resource governance and versioning the discipline transfers as mechanism intact — the role-transfer test, the four-way cut, the read-currency-off-the-chain diagnostic, the hard/soft choice, and bidirectional traversal carry across standards, software, datasets, taxonomy, and product lifecycles, with the vocabulary preserved. Beyond it the entry's DCMI machinery stays home: the role-takeover content sits with substitutability (except that is symmetric while replacement is directed), and the genuinely cross-domain pattern — time-asymmetric supersession with an obsolescence flag — points at a broader emergent supersession parent unifying paradigm change, S-curves, and species succession. Carry those, not the named relation.

Relationships to Other Abstractions

Local relationship map for Replacement RelationParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Replacement RelationDOMAINPrime abstraction: Supersession — is a kind ofSupersessionPRIME

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

Neighborhood in Abstraction Space

Replacement Relation sits in a sparse region of the domain-specific corpus (70th 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