standard: JSON-LD output does not emit direct SKOS mapping triples

[maehr]

Affected spec section

/standard/json-ld/ and the mapping emission in scripts/compile.ts (lines ~430–445).

Motivation

The JSON-LD docs page says mapping relations map to SKOS, but the published JSON-LD output and the context don't actually emit a SKOS mapping graph for MappingAssertion.

Current state:

• public/contexts/v1.jsonld maps "relation": "tr:relation" (literal). It does declare aliases "exactMatch" / "closeMatch" → skos:exactMatch / skos:closeMatch with @type: @id, but the compiler never emits records that use those keys.

• scripts/compile.ts emits each assertion as:

  {
    "type": "MappingAssertion",
    "subject": "<Work IRI>",
    "relation": "exactMatch",      // string literal
    "target": { "identifier": "<IRI>", "conforms_to": "..." }
  }

• Expanded into triples, the consumer gets <mapping> tr:relation "exactMatch" plus a nested tr:target blank node — no <subject> skos:exactMatch <target.identifier> edge anywhere. A SKOS-aware client cannot follow mappings.

The spec promises SKOS alignment; the compiler doesn't deliver it.

Proposed change

Compiler-side, additive. For each accepted MappingAssertion, in addition to the existing reified record, emit a direct edge from subject to target identifier under the appropriate SKOS predicate:

// per accepted mapping, alongside the reified MappingAssertion record:
{
  "id": "<subject>",
  "exactMatch": "<target.identifier>"   // or "closeMatch"
}

(Or equivalently, attach the SKOS edge under the subject node in whatever shape the compiled artifact uses.) The reified MappingAssertion stays as-is for provenance, status, dcterms:source, etc.

Rationale for compiler-side over context-side:

• The published context URL should be treated as immutable; changing what relation expands to is risky for any existing consumer.
• A string-valued relation cannot be coerced into a typed IRI relationship from a single key — the SKOS edge needs both predicate selection and an object IRI (target.identifier), which is structural, not lexical.

Alternatives considered

• Context-side coercion of relation to an IRI-typed property. Doesn't work cleanly: the value is the string exactMatch/closeMatch, not an IRI, and the edge needs the subject→target.identifier shape, not subject→relation-literal.
• Drop the SKOS promise. Update /standard/json-ld/ to say mapping is via reified tr:relation only. Cheapest but loses the interop the docs already advertise.
• Mint a new context version (v2) that restructures mappings as SKOS edges. Larger blast radius; revisit only if other v2-level changes accumulate.

Compatibility impact

additive (no breaking change)

(Adds extra triples; removes nothing. Existing consumers reading tr:relation keep working.)

Target spec version

v0.2.0-draft

Related

Interacts with #10 (MappingAssertion subject vs. tombstone successors): if Option B (superseded_by) is chosen there, tombstone successor edges shouldn't go through this SKOS emission — provenance vs. equivalence. The SKOS edge stays for genuine MappingAssertion records only.