Repository navigation
Mapping projection uses a denylist, so draft and deprecated mappings emit unqualified direct edges #45
Description
Activity
- changed the title
[-]Work SKOS projection uses a denylist, so draft and deprecated mappings emit unqualified skos:exactMatch[/-][+]Mapping projection uses a denylist, so draft and deprecated mappings emit unqualified direct edges[/+]on Aug 12, 2026 Retitled for ADR-0006, which replaced the SKOS relations with
alternateOf/isReferencedBy. The behaviour this issue reports is unchanged — only the vocabulary moved, so this is not obsolete:for (const m of src.mappings ?? []) { if (TOMBSTONE_STATUSES.has(m.status)) continue; // withdrawn | blocked mappingEdges[m.relation].push(m.identifier); }
Still a denylist, so
draftanddeprecatedassertions still project into the direct edges onWork, still without a status qualifier on the edge itself. And since ADR-0004 keeps all registry data atdraft, every seed mapping inv0.1.0ships this way — a consumer following only the direct edges cannot tell a reviewed equivalence from an unreviewed draft one.The two options in the original description carry over verbatim; only the relation names change. The docs to update alongside are now
specification.md§6,json-ld.md§ Mapping relations,standard/schema/work.ts, and theWork.alternateOf/isReferencedBydescriptions inapi/openapi.yaml.Ships as-is in v0.1.0 — all data is
draftand carries no persistence promise, so nothing is frozen by the tag.- added a commit that references this issue
on Aug 24, 2026 Resolved on
stagingin f5a037f (#86), and split — one half fixed, one half declined.Fixed:
deprecatedno longer projects. The gate excluded onlywithdrawnandblocked, so a mapping the registry had retired kept emitting a live, unqualified edge. That contradicted the standard's own definitions —common.tscallsdeprecated/withdrawn/blockedthe states for records that have left active use, and specification §12 definesdeprecatedas "retained but no longer recommended". The projection is now gated on the set that already meant exactly that, renamedSUPERSEDABLE_STATUSES→RETIRED_STATUSES.TOMBSTONE_STATUSESstays for the two resolution-breakage checks; a deprecated record still resolves.Declined: the allowlist on
draft. TextRefs' guarantees attach toCanonicalReference— identity, persistence, resolution. TheWorkprojection is enrichment and never claimed review, so gating it on promotion would buy a guarantee the standard does not make.It would also cost real capability. All 24 seed mappings are
draft, and the compiledWorkcarries no back-link to its assertions —/id/work/{key}.jsonpublishes the record verbatim and there is no/reg/mapping/index. Under an allowlist, v0.1.0 works would lose their only machine-readable path to Wikidata, and restoring it would mean adding amappingsfield, a context term, and an ADR — a large change to repair damage the allowlist itself caused.So the docs now say what the arrays are for instead of implying a promise: specification §6 and
json-ld.mdstate that the arrays enrich the work, make no claim about review, and that a consumer needing status reads theMappingAssertion.Nothing ships differently. Every record in
data/isdraft, so no assertion is deprecated today —dist/dump/works.jsonlis byte-identical before and after (b35b36e2…). The fix closes the hole before a demotion ever happens. #68 §4 needed no revision.
Found while reviewing #4.
scripts/compile.tsderives the directexactMatch/closeMatcharrays onWorkby skipping only tombstoned assertions:A denylist means
draftanddeprecatedmappings also project into the published SKOS edges. Since ADR-0003 demoted all registry data todraft, every seed mapping currently ships as an unqualifiedskos:exactMatch/skos:closeMatchfrom the work IRI — with no status qualifier attached to the edge itself, unlike the reifiedMappingAssertionit came from.A consumer that only follows the direct edges cannot tell a reviewed equivalence from an unreviewed draft one.
Two ways out:
candidate/active), so drafts stay visible only as reified assertions. This is the behaviour the docs originally described ("accepted mapping assertions") and would emit no direct edges at all until the first promotion.Option 1 seems right — the projection exists to be a convenience for consumers who trust the edge, and a draft edge is precisely the one that should not be trusted. Worth deciding before any consumer starts relying on the arrays.
Docs to update alongside whichever way this goes:
specification.md§6,json-ld.md§ Mapping relations,standard/schema/work.ts, and theWork.exactMatch/closeMatchdescriptions inapi/openapi.yaml.