Deprecations

Current state: no active deprecations

CASRAI Dictionary v2026.1 (released 17 May 2026) ships with the preserved 2020 vocabulary mirrored from the federation stewards and adds no editorial changes that supersede existing terms. There are therefore no entries in the deprecation log at this release. When v2026.2 ships in September 2026, any deprecations introduced by working-group output will be logged here with the pattern documented below.

For the broader vocabulary picture see the all releases catalogue and the dictionary changelog; for the policy that governs how and when deprecation happens, see the versioning policy.

The deprecation contract, in one sentence

Every URI we have ever published continues to resolve, and every deprecated URI carries a forward pointer to its successor — for the lifetime of the vocabulary.

That sentence is the operative commitment. The remainder of this page unpacks what it means in practice.

The deprecation chain pattern

When a CASRAI term, picklist entry, object template, or domain identifier is superseded, the change is recorded as a chain: the deprecated URI points forward to its replacement via a typed relationship, and the replacement carries a reciprocal back-pointer to the term it replaced. The chain can extend: if a replacement is itself later replaced, the original URI is updated to point at the most recent successor while preserving the intermediate chain in the chain's history. Implementers traversing the chain reach the current canonical successor; implementers checking the history can see how the concept evolved.

Typed relationships

Each deprecation is annotated with a relationship type that tells implementers what kind of change has occurred. The relationship vocabulary draws on SKOS and the conventions used by NISO standards. The types used in CASRAI:

• replacedBy — the deprecated entry is superseded by a single new entry that captures the same concept under a different identifier (typically because the slug was inaccurate or the concept was renamed).
• splitInto — the deprecated entry was found to conflate two or more distinct concepts; it is replaced by a set of new entries, each capturing one of the previously conflated concepts.
• mergedInto — the deprecated entry was found to be a near-synonym of another entry; both are deprecated and a single combined entry takes their place.
• movedTo — the deprecated entry has been transferred to a different steward's vocabulary (typically a federation steward) and the canonical version now lives at the steward's URI. The CASRAI URI continues to resolve and points at the canonical external URI.
• withdrawn — the deprecated entry is removed without a successor. This is the rare case used when an entry was added in editorial error. The URI continues to resolve to a placeholder explaining the withdrawal; the changelog carries the explicit rationale.

Payload shape

The JSON-LD payload for a deprecated entry carries the relationship and the successor URI in machine-readable form, so implementers can traverse the chain without scraping the human-readable page:

{
  "@context": "https://casrai.org/context/v1",
  "@id": "https://casrai.org/dictionary/term/<deprecated-slug>",
  "@type": "DefinedTerm",
  "name": "<term name at time of deprecation>",
  "deprecated": true,
  "deprecatedAt": "2026-09-15",
  "deprecatedInVersion": "v2026.2",
  "replacedBy": {
    "@id": "https://casrai.org/dictionary/term/<replacement-slug>"
  },
  "deprecationNote": "<one-paragraph rationale linking to changelog and (if applicable) board decision>"
}

HTTP behaviour

Crucially, a deprecated URI returns 200 OK with a visible deprecation banner — not a301 redirect. This is a deliberate choice: a silent 301 would break any implementer that stored the original URI and treated the redirect as identity-preserving. By returning 200 with a banner and a machine-readablereplacedBy pointer, we let implementers see the deprecation explicitly and choose how to handle it (update their store now, defer the update, leave historical records unchanged). The same convention is used by well-maintained vocabularies including the GeoNames dataset and the ISO 639 language codesregistry.

Why deprecation rather than removal

The single most important promise this vocabulary makes to its implementers is that identifiers are identifiers — they identify a thing for the long term, not for the duration of one release. Implementer trust in that promise is what makes the vocabulary useful at scale: publishers can bind submission-system fields to CASRAI URIs without fear that the next release will pull the rug out; CRIS vendors can build long-lived integrations against terms they expect to remain resolvable; evaluation systems can cite vocabulary in long-term records. This promise is incompatible with deletion. Even bad terms — terms added in error, terms that turned out to conflate concepts, terms that should never have shipped — get the deprecation treatment rather than the removal treatment. The history is durable. The full policy is documented on the versioning policy page.

Federation deprecations

When a federation steward — NISO for CRediT, euroCRIS for the Catalogue of Elements, CODATA for the RDM Terminology — deprecates an entry in their canonical vocabulary, the corresponding CASRAI mirror entry is updated to reflect the steward's deprecation. The CASRAI URI continues to resolve and shows the steward's deprecation note alongside its own changelog entry. We do not deprecate federation mirrors unilaterally; the steward's authority controls the upstream identifier.

Future deprecation log

When the first formal deprecation occurs (anticipated in or after v2026.2), the entry will appear on this page as a table row showing the deprecated URI, the successor URI, the relationship type, the release in which the deprecation took effect, and a link to the changelog entry with the rationale. The log is sorted reverse chronologically and is intended to be the single canonical place an implementer can check for "what's changed since I integrated."

Reporting concerns about a term

If you have integrated against a CASRAI URI and discover what looks like a problem with the term (the definition is wrong, the examples are misleading, the scope is ambiguous), the contribute pathway is the right channel. Where the editorial board judges the report warrants a deprecation, the change is processed at the next release.