Affected spec section
/standard/specification/ § 10 (MappingAssertion) and validation rule 11, in tension with the tombstone / versioning policy on /standard/versioning/.
Motivation
The specification requires MappingAssertion.subject to be a Work IRI:
https://textrefs.org/id/work/{work_key}
and validation rule 11 enforces the same shape.
The versioning / tombstone mechanism, however, requires re-minted records — including CanonicalReference tombstones and tombstoned citation-system records — to point to their successors via an exactMatch MappingAssertion whose subject is the old IRI and whose target is the new IRI.
A reference IRI like https://textrefs.org/id/ref/{uuid} is not a Work IRI. Likewise for system IRIs. A conforming validator that implements § 10 + rule 11 would therefore reject exactly the records the versioning policy mandates. This is a hard contradiction, not a wording problem — one side has to give before any stable/citable spec tag.
Use cases this blocks:
- Tombstoning a
CanonicalReference when its citation-system profile changes normalization rules.
- Retiring a citation-system record in favour of a corrected successor.
- Any consumer trying to follow
exactMatch from a tombstone to the live successor.
Proposed change
Surface both directions; defer the final choice to maintainers.
Option A — widen MappingAssertion.subject.
Allow any TextRefs registry IRI (Work, CanonicalReference, CitationSystem) as subject. Validation rule 11 is relaxed accordingly.
- Pros: smallest diff; enables reference-level and system-level mappings; tombstone story Just Works.
- Cons: overloads SKOS-aligned equivalence semantics — a
MappingAssertion from a tombstone to its successor is provenance, not equivalence in the conceptual sense SKOS intends; harder for consumers to tell "this is the same concept under a different identifier" apart from "this superseded that."
Option B (recommended) — add superseded_by; reserve MappingAssertion for equivalence.
Introduce a superseded_by field on tombstoned records pointing to the successor IRI. Keep MappingAssertion.subject constrained to Work IRIs. Mapping assertions remain reserved for genuine equivalence / close-match claims between distinct conceptual references.
- Pros: succession is modelled as provenance, not equivalence; SKOS interpretation of mapping assertions stays clean; consumers walk tombstones through a dedicated field; mapping seed logic largely untouched.
- Cons: adds a schema field and a small amount of validation behaviour; two separate mechanisms (provenance vs. mapping) where today there is intended to be one.
Alternatives considered
- Document the contradiction and forbid tombstones with successors. Rejected: that breaks the stated versioning guarantees and would force every breaking normalization change to be silent.
- Use a dedicated
tr:supersedes predicate scoped to the versioning vocabulary, distinct from both options above. Effectively a flavour of Option B; collapsing into it for brevity.
I'd like the maintainers to choose between A and B before I implement anything. Happy to draft spec wording and a JSON-LD context update once a direction is picked.
Compatibility impact
breaking — major version bump required
Target spec version
v0.2.0-draft
Affected spec section
/standard/specification/§ 10 (MappingAssertion) and validation rule 11, in tension with the tombstone / versioning policy on/standard/versioning/.Motivation
The specification requires
MappingAssertion.subjectto be a Work IRI:and validation rule 11 enforces the same shape.
The versioning / tombstone mechanism, however, requires re-minted records — including
CanonicalReferencetombstones and tombstoned citation-system records — to point to their successors via anexactMatch MappingAssertionwhose subject is the old IRI and whose target is the new IRI.A reference IRI like
https://textrefs.org/id/ref/{uuid}is not a Work IRI. Likewise for system IRIs. A conforming validator that implements § 10 + rule 11 would therefore reject exactly the records the versioning policy mandates. This is a hard contradiction, not a wording problem — one side has to give before any stable/citable spec tag.Use cases this blocks:
CanonicalReferencewhen its citation-system profile changes normalization rules.exactMatchfrom a tombstone to the live successor.Proposed change
Surface both directions; defer the final choice to maintainers.
Option A — widen
MappingAssertion.subject.Allow any TextRefs registry IRI (Work, CanonicalReference, CitationSystem) as subject. Validation rule 11 is relaxed accordingly.
MappingAssertionfrom a tombstone to its successor is provenance, not equivalence in the conceptual sense SKOS intends; harder for consumers to tell "this is the same concept under a different identifier" apart from "this superseded that."Option B (recommended) — add
superseded_by; reserveMappingAssertionfor equivalence.Introduce a
superseded_byfield on tombstoned records pointing to the successor IRI. KeepMappingAssertion.subjectconstrained to Work IRIs. Mapping assertions remain reserved for genuine equivalence / close-match claims between distinct conceptual references.Alternatives considered
tr:supersedespredicate scoped to the versioning vocabulary, distinct from both options above. Effectively a flavour of Option B; collapsing into it for brevity.I'd like the maintainers to choose between A and B before I implement anything. Happy to draft spec wording and a JSON-LD context update once a direction is picked.
Compatibility impact
breaking — major version bump required
Target spec version
v0.2.0-draft