(sourcelume-spec) 03/04: Add three draft crosswalks (Croissant, SPDX AI Profile, OTDI)

[an...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

ANierbeck pushed a commit to branch minimal-mimir
in repository https://gitbox.apache.org/repos/asf/sourcelume-spec.git

commit 44f96f9d358b82ea64b2b240f10b71534fc2fe49
Author: anierbeck <ac...@codecentric.de>
AuthorDate: Tue Sep 8 20:54:29 2026 +0200

    Add three draft crosswalks (Croissant, SPDX AI Profile, OTDI)
    
    The site lists crosswalks as one of four architectural pillars
    (specification.md: JSON-LD foundation, structural+semantic validation,
    crosswalks for interoperability, immutable versioning). Adding the three
    draft crosswalks so the branch delivers all four pillars rather than
    three-of-four. Each file is short (1-1.7KB), opens with a 'Status: draft'
    note, and carries its open questions in-band:
    
    - Croissant (MLCommons): highest confidence. identifier/name/license/
      creator map directly (both borrow from schema.org); origin and
      custodyChain are Sourcelume's additions over Croissant. Open question:
      embed a Sourcelume record inside a cr:Dataset vs. keep them
      cross-linked.
    
    - SPDX AI Profile: medium confidence. license maps to licenseDeclared
      (not licenseConcluded) because Sourcelume publishes claims, not
      adjudications; creator maps to suppliedBy/originatedBy with role tags;
      custodyChain has no SPDX equivalent. Open question: should a future
      version split license into declared/concluded to match SPDX?
    
    - OTDI: lowest confidence. OTDI's public vocabulary is the thinnest of
      the three; strongest conceptual overlap is custodyChain. Open
      question: need a concrete OTDI schema/example to move past
      conceptual-only mapping.
    
    All three are explicitly drafts needing review from anyone who knows
    the target format; that review is a dev-list conversation, not something
    this commit resolves.
    
    Apache-ai: Yes
    Generated-by: Claude Code (Sonnet 5)
    Reviewed-by: anierbeck
---
 mappings/croissant-crosswalk.md       | 26 ++++++++++++++++++++++++++
 mappings/otdi-crosswalk.md            | 16 ++++++++++++++++
 mappings/spdx-ai-profile-crosswalk.md | 20 ++++++++++++++++++++
 3 files changed, 62 insertions(+)

diff --git a/mappings/croissant-crosswalk.md b/mappings/croissant-crosswalk.md
new file mode 100644
index 0000000..34f1701
--- /dev/null
+++ b/mappings/croissant-crosswalk.md
@@ -0,0 +1,26 @@
+# Crosswalk: Sourcelume ↔ MLCommons Croissant
+
+> **Status: draft.** Field-level mappings below are a starting proposal, not confirmed against
+> the current Croissant release. Discuss on `dev@sourcelume.apache.org` before treating any row
+> as final.
+
+Croissant (`http://mlcommons.org/croissant/`) is a schema.org-based JSON-LD vocabulary for
+describing ML datasets. Sourcelume records provenance/custody/licensing specifically, so most
+Croissant terms (`distribution`, `recordSet`, `field`) have no Sourcelume equivalent — the overlap
+is concentrated in dataset identity and licensing metadata, both of which Croissant itself borrows
+from schema.org.
+
+| Sourcelume field | Croissant / schema.org term | Notes |
+|---|---|---|
+| `identifier` | `schema:identifier` (on `cr:Dataset`) | Both typically hold a DOI or persistent URL. |
+| `name` | `schema:name` | Direct match. |
+| `license` | `schema:license` | Direct match — both expect an IRI or SPDX identifier. |
+| `creator` | `schema:creator` | Same schema.org property, but Sourcelume's `creator` is an array of role-tagged (`originator`/`curator`/`distributor`) parties as of 0.0.1, rather than Croissant's single value. |
+| `origin` | *(no direct equivalent)* | Croissant doesn't model a provenance narrative; stays Sourcelume-specific. |
+| `custodyChain` | *(no direct equivalent)* | Custody-chain modeling is Sourcelume's core addition over Croissant. |
+
+## Open questions
+
+- Should a Sourcelume record be embeddable as a property of a Croissant `cr:Dataset` (e.g. a
+  `sourcelume:provenance` extension property), or should the two stay as separate, cross-linked
+  documents? Needs dev-list discussion.
diff --git a/mappings/otdi-crosswalk.md b/mappings/otdi-crosswalk.md
new file mode 100644
index 0000000..7f74025
--- /dev/null
+++ b/mappings/otdi-crosswalk.md
@@ -0,0 +1,16 @@
+# Crosswalk: Sourcelume ↔ Open Trusted Data Initiative (OTDI)
+
+> **Status: draft, lowest confidence of the three crosswalks.** OTDI's public vocabulary is less
+> stable/documented than Croissant or SPDX as of this writing — treat every row here as a
+> placeholder pending confirmation from the AI Alliance's published OTDI artifacts.
+
+| Sourcelume field | OTDI concept (tentative) | Notes |
+|---|---|---|
+| `identifier` | dataset identifier | Needs confirmation of OTDI's canonical ID property name. |
+| `origin` | provenance narrative / data source description | OTDI is reported to emphasize consent and collection-method disclosure more heavily than Sourcelume's 0.0.1 free-text `origin` field does. |
+| `custodyChain` | chain-of-custody / handling event | Likely the strongest conceptual overlap between the two specs, but needs a real OTDI schema reference to map field-by-field. |
+
+## Open questions
+
+- Get a concrete OTDI schema/example on the dev list so this crosswalk can move past
+  conceptual-only mapping.
diff --git a/mappings/spdx-ai-profile-crosswalk.md b/mappings/spdx-ai-profile-crosswalk.md
new file mode 100644
index 0000000..864f7e2
--- /dev/null
+++ b/mappings/spdx-ai-profile-crosswalk.md
@@ -0,0 +1,20 @@
+# Crosswalk: Sourcelume ↔ SPDX AI Profile
+
+> **Status: draft.** Needs review against the current SPDX 3.0 AI profile release before being
+> treated as authoritative.
+
+The SPDX AI Profile extends SPDX 3.0 with AI-specific classes (`ai:AIPackage`,
+`ai:DatasetPackage`) and already has strong primitives for license expression, which Sourcelume
+should reuse rather than duplicate.
+
+| Sourcelume field | SPDX AI Profile term | Notes |
+|---|---|---|
+| `identifier` | `spdx:SpdxId` / external identifier on `DatasetPackage` | SPDX favors its own ID scheme; mapping needs a stable rule (e.g. always carry the original DOI as an `ExternalIdentifier`). |
+| `license` | `spdx:licenseConcluded` / `spdx:licenseDeclared` | SPDX distinguishes *declared* vs. *concluded* license — Sourcelume's single `license` field is closer to `licenseDeclared` since Sourcelume doesn't adjudicate accuracy. |
+| `creator` | `spdx:suppliedBy` / `spdx:originatedBy` | SPDX splits "who supplied this copy" from "who originated the data" as distinct relationships; Sourcelume's `creator` is an array of role-tagged parties (`originator`/`curator`/`distributor`) as of 0.0.1, which maps more directly now but still isn't a 1:1 term match. |
+| `custodyChain` | *(no direct equivalent)* | Closest SPDX concept is a `Relationship` between elements, but there's no first-class chain-of-custody event type. |
+
+## Open questions
+
+- Should `license` split into `licenseDeclared`/`licenseConcluded` in 0.0.2 to match SPDX more
+  closely, or is the ambiguity intentional (Sourcelume publishes claims, not adjudications)?


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@sourcelume.apache.org
For additional commands, e-mail: commits-help@sourcelume.apache.org