standard: license and license_url both map to dcterms:license (mixed literal/IRI range)

[maehr]

Affected spec section

/standard/json-ld/ and public/contexts/v1.jsonld (license terms).

Motivation

The current JSON-LD context maps both license-related keys to the same dcterms:license predicate, but with different ranges:

"license":     "dcterms:license",                                  // SPDX literal string
"license_url": { "@id": "dcterms:license", "@type": "@id" }        // dereferenceable IRI

After expansion, RDF consumers see one predicate with two object types — sometimes a literal like "CC-BY-4.0", sometimes an IRI like https://creativecommons.org/licenses/by/4.0/. Compaction is awkward (the round-trip can collapse one key into the other depending on shape), and SPARQL queries against dcterms:license need to handle both ranges.

Low severity, but worth deciding before any stable/citable tag — context changes are expensive once IDs are published.

Proposed change

Three options; I have a mild preference for (1) but the review explicitly notes this is acceptable to decline.

Option 1 — map SPDX IDs to canonical SPDX IRIs (recommended).
Compiler converts CC-BY-4.0 → https://spdx.org/licenses/CC-BY-4.0 at emission time. The context keeps a single IRI-typed dcterms:license. license_url either becomes a redundant authored alias for the same field or is deprecated.

• Pros: one predicate, one range, clean RDF; SPDX IRIs are well-known and dereferenceable.
• Cons: requires a tiny SPDX-ID-to-IRI mapping in the compiler; behaviour for non-SPDX strings needs a fallback.

Option 2 — separate predicates.
Keep license as an SPDX literal under a distinct predicate (e.g. tr:spdxLicense, or schema:license with a literal range), and reserve dcterms:license for the IRI-typed license_url.

• Pros: each predicate has a single range; honours both the SPDX convention and dcterms semantics.
• Cons: context churn; consumers querying dcterms:license no longer see the SPDX shortcut without union queries.

Option 3 — document and decline.
Add a note to /standard/json-ld/ acknowledging the dual mapping; close as wontfix.

• Pros: zero churn.
• Cons: leaves an RDF rough edge in a published context.

Alternatives considered

The three options above are the alternatives. A hybrid (Option 1 plus keeping license_url as an alias for back-compat) is the most likely landing zone if Option 1 is picked.

Compatibility impact

additive (no breaking change)

(Assumes Option 1 — adds derived IRIs while keeping authored data unchanged. Option 2 would be a breaking context change; Option 3 is editorial only.)

Target spec version

v0.2.0-draft