Apache Sourcelume 介绍与选型指南

Apache Sourcelume（AI 训练数据溯源基础设施）的定位、三仓库组织、v0.0.1 ProvenanceRecord 规范、基于 Apache Atlas 的 Registry 参考实现，以及截至 2026 年 10 月尚无正式发布版本这一现状下的同类方案选型对比

Apache SourcelumeApache Sourcelume2026/10/15

Apache Sourcelume 介绍与选型指南

目标：讲清 Apache Sourcelume 是什么、解决什么问题、由哪些组件构成、规范与代码的实际进度走到哪一步，以及在没有正式发布版本可依赖的当前时点应如何对待它、如何与同类方案选型。本文所有事实均来自 2026 年 10 月 15 日对官网、GitHub 三个仓库、downloads.apache.org、Maven Central 等信息源的真实查询（出网经代理 http://192.168.1.62:7897），并完成了一次基于规范校验工具的最小实测；凡未能核实的事项均如实标注，不做推测。

一、环境信息

本篇为 A1 介绍篇，此处的"环境信息"记录的是本文的调研环境与信息源核查清单，而非安装运行环境（项目尚无可安装的正式版本，见第五章）。

调研环境：

  • 调研日期：2026 年 10 月 15 日
  • 操作系统：Ubuntu 22.04.4 LTS（x86_64）
  • 调研工具：curl（出网经代理 http://192.168.1.62:7897）、git 2.34.1（clone 走同一代理）、Python 3.10.12 + pip 22.0.2（用于规范校验实测）
  • 本机未安装 JDK 与 Maven，因此 Registry（Java 21 基线，见 3.3 节）的构建未做实测，实测仅覆盖 Python 侧的规范校验环节（见 3.4 节）

信息源核查结果（均为 2026-10-15 逐项实查）：

信息源实查结果结论
https://sourcelume.apache.orgHTTP 200官网存在，含 Specification、Registry、FAQ、Get involved 等页面
https://github.com/apache/sourcelumeHTTP 404不存在单一同名仓库，项目采用多仓库组织
https://github.com/apache/sourcelume-specHTTP 200规范仓库已开放
https://github.com/apache/sourcelume-registryHTTP 200注册中心实现仓库已开放
https://github.com/apache/sourcelume-siteHTTP 200官网源文件仓库已开放
https://downloads.apache.org/sourcelume/HTTP 404ASF 官方下载目录下无本项目，即无官方发布分发包
https://repo1.maven.org/maven2/org/apache/sourcelume/HTTP 404Maven Central 无任何本项目构件
https://lists.apache.org/list.html?dev@sourcelume.apache.orgHTTP 200dev@ 邮件列表已建立且可访问
projects.apache.org 各 JSON 接口（projects.json、committees.json 等）HTTP 404该站 JSON 接口当前不可用，项目条目未能经此渠道二次核实；项目主页 project.html?sourcelume 返回 200 但为脚本渲染，内容无法在服务端确认

三仓库完整历史（clone 后按提交记录核对）：均以 2026-08-23 的初始提交起步；截至调研日，sourcelume-spec 共 23 个提交（最新 2026-10-11，"Add contentCreatedEnd and require @context (#9)"）、sourcelume-registry 共 58 个提交（最新 2026-10-12，合入 Community Over Code 2026 演示分支）、sourcelume-site 共 18 个提交（最新 2026-10-13）。三仓库均无 git tag，没有任何正式版本发布。

项目身份观察：官网各页面与仓库中均未出现 Apache 孵化器免责声明，官网社区页设有 PMC 成员表（列出 Jamie Goodyear、Andrew Musselman、Calvin Kirs、Dave Fisher、Jeff Genender、Achim Nierbeck、JB Onofré、Raúl Cumplido 共 8 人，均标注为 PMC 成员），这些特征与 ASF 顶级项目（TLP）一致；受限于 projects.apache.org 接口不可用，该结论以官网/仓库直接证据为准。

💡 技术拓展：Maven Central（repo1.maven.org）是 Java 生态事实上的构件分发渠道，Apache 项目进入正式版本后通常同步发布于此；对 Apache 项目做"是否已有可依赖版本"的快速判断，downloads.apache.org（官方分发包）与 repo1.maven.org（构建构件）两个路径的组合核查通常足够覆盖。

二、软件概述

Apache Sourcelume 是面向 AI 训练数据溯源（training-data provenance）的开源基础设施。官网定义其为：一套元数据规范（Specification）、一个参考注册中心（Registry）、一条签发与校验管线（Attestation）和一个公开检索前端（Explorer）。它让数据集策展方与模型生产方发布可密码学签名、可独立核验的结构化记录，声明一个数据集的来源（origin）、保管链（custody chain）与许可条款（licensing terms）。

它要解决的问题：训练语料的许可与溯源信息经常缺失、错误或无法核验——官网引用 2024 年的一项审计结论，主流数据集托管站点的许可信息缺失率超过 70%。当数据来源说不清、许可条款查不实，模型生产方就暴露在知识产权与合规风险之下，审计方也没有可下手的结构化凭据。

关键边界（官网 About 页的明确口径）：Sourcelume 不验证、不裁定、也不认证所声明条款是否准确或法律上充分。它是"中立管道"——提供让声明保持一致形态、从而可以被他人独立核验的工具与注册中心，而不是替任何人背书。

生态站位：官网明确其"构建于并 aligns with 既有标准而非与之竞争"，包括 MIT Data Provenance Initiative（DPI）的注释分类体系、AI Alliance 的 Open Trusted Data Initiative（OTDI）、MLCommons Croissant、SPDX AI Profile，以及 Content Authenticity Initiative 的 C2PA 工作；实现底座复用 Apache Atlas、Iceberg、Parquet、NiFi、Airflow 等既有 Apache 项目。官网同时链接了 ASF Responsible AI 倡议（总规模 1000 万美元、首笔 175 万美元捐赠）的新闻页，Sourcelume 是该倡议背景下的 AI 数据透明度方向项目。

💡 技术拓展：数据溯源（provenance）回答"这份数据从哪来、经过过谁的手"；数据透明度（transparency）进一步要求这些答案以机器可读、可核验的形态公开。AI 场景下二者直接对应模型合规：训练数据若拿不出来源与许可凭据，产出的模型在欧盟 AI Act 类法规与企业采购尽调中都难以过关。这也是 2025 年以来 DPI、OTDI、Croissant、SPDX AI Profile 等多个组织从不同角度切入同一问题的原因——Sourcelume 的差异化在于把"结构化记录 + 签名校验 + 可查询注册中心"做成一条完整链路。

三、核心架构

3.1 组件全景与实现进度

官网 North Star 架构图的目标形态如下（文字重绘）：

Specification（JSON-LD + JSON Schema + SHACL）
   │ 定义记录形态（shapes）
   ▼
Dataset producers & curators ──cli ingest / attest──▶ Attestation（签名与校验库）
   │ 签名后的 ProvenanceRecord（JSON-LD）
   ▼
Registry（参考实现基于 Apache Atlas）──REST / GraphQL──▶ Explorer（检索 UI）
                                      └──────────────▶ 机器消费方（训练器、审计方）

截至 2026-10-15 调研日，各组件的实际进度：

组件官网定位当前状态（实查）
Specification版本化 JSON-LD 元数据规范已有实质产出：v0.0.1 完整 schema/context/正文与校验工具（见 3.2）
Registry基于 Apache Atlas 的参考实现已有实质产出：0.0.1-SNAPSHOT，Quarkus 运行时 + Atlas 适配（见 3.3）
Attestation签发与校验库，C2PA 兼容尚无代码；官网 Get involved 页列为志愿者组队方向
CLI摄取与签发命令行尚无代码，同上
Explorer检索与溯源卡片 UI尚无代码，同上
Connectors对接既有数据源尚无代码，同上

另注意：官网架构图中的 REST / GraphQL 双接口是目标态，当前 Registry 实现仅提供 REST 接口。

3.2 Specification：v0.0.1 的 ProvenanceRecord

规范当前版本 v0.0.1（官网 Specification 页与仓库 schema/context/spec 三处 0.0.1 目录一致），正文自述状态为 Draft。核心类型是 ProvenanceRecord——"这是一个数据集：由这些角色方产出/策展/分发，按这些条款许可，来自这个源头，经过这样一条保管链"的结构化声明。规范反复强调：Sourcelume 不核验声明本身的真实性，只给声明一个一致形态，使其可以被他人核验。

sourcelume-spec 仓库实际结构（clone 后摘录）：

sourcelume-spec/
├── context/0.0.1/sourcelume.jsonld        # JSON-LD @context 文档，发布后不可变
├── schema/0.0.1/sourcelume.schema.json    # JSON Schema（结构校验）
├── schema/0.0.1/sourcelume.shacl.ttl      # SHACL shapes（RDF 层语义校验）
├── spec/0.0.1/index.md                    # 正文规范，逐字段说明
├── mappings/croissant-crosswalk.md        # 到 Croissant 的字段映射
├── mappings/spdx-ai-profile-crosswalk.md  # 到 SPDX AI Profile 的字段映射
├── mappings/otdi-crosswalk.md             # 到 OTDI 的字段映射
├── tools/validate.py                      # Python 参考校验器
├── tools/render-docs.py
├── tests/test_validate.py                 # 校验器单元测试
└── CHANGELOG.md / VERSIONING.md / SETUP.md / pom.xml / pyproject.toml

ProvenanceRecord 字段面（schema 0.0.1 实查）：

  • 必填 12 项：id、type（固定 ProvenanceRecord）、@context（仅接受规范 IRI）、identifier（数据集 IRI 或 DOI）、name、license（SPDX 许可 URL 类 IRI）、creator（带 originator/curator/distributor 角色标注的组织或个人，至少 1 个）、created（记录撰写时间）、added（数据集入库时间）、contentCreated（内容创作时间，可选配 contentCreatedEnd 表达时间段）、origin（来源自由文本）、custodyChain（有序保管事件，至少 1 跳）。
  • 许可细节字段：licenseScope（许可的司法辖区/适用范围）、licenseNote（许可 IRI 有误导性时的自由文本限定）、licenseCategory（七值枚举：open-source、open-data、public-domain、agreement-supplied、use-restricted、risk-based、other）、licenseHistory（历史许可变更轨迹）。
  • 保管链设计：custodyChain 每项为 agent（IRI）+ action + startTime；agent 可以指向另一条 ProvenanceRecord 的 id，此时按引用（图）解析而非嵌套——多跳溯源靠记录间引用拼接，单条记录不递归。

版本化与发布纪律：语义化版本（CHANGELOG + VERSIONING.md 明确 MAJOR/MINOR/PATCH 对规范变更的含义）；context 与 schema 文件一经发布不可变，命名空间固定为 https://sourcelume.apache.org/ns#，context URL 按版本钉死。两个如实的"未完成"信号：其一，规范正文的 context IRI https://sourcelume.apache.org/context/0.0.1/sourcelume.jsonld 当前返回 HTTP 404——发布流程尚未执行，校验器按设计改用仓库内捆绑副本；其二，README 中规划的 examples/ 目录（示例记录与跨映射实例）尚未出现在仓库中，README 描述略超前于仓库现状。

💡 技术拓展：JSON-LD 让 JSON 文档携带 @context，把普通字段名映射到带命名空间的语义 IRI（Sourcelume 的 context 复用 dct、schema.org、spdx、xsd 等既有词表），于是同一份记录既是给程序读的 JSON，也是给知识图谱读的链接数据；JSON Schema 管"结构对不对"（必填项、格式），SHACL 管"语义合不合规矩"（RDF 图层面的约束，如时间先后关系），二者叠加是语义网场景常见的双阶段校验组合。

3.3 Registry：基于 Apache Atlas 的参考实现

sourcelume-registry 仓库 pom.xml 版本为 0.0.1-SNAPSHOT。README 记载 2026 年 9 月 dev@ 邮件列表共识：代码按"框架无关的 Core/API + 运行时模块分层"组织。模块清单（仓库实查）：

模块职责
sourcelume-registry-typedefs后端类型定义（JSON 资源），注册为 Atlas 类型
sourcelume-registry-common从 spec 映射的 DTO 与 Jakarta Validation 注解，仅依赖 Jakarta API + Jackson
sourcelume-registry-core后端中立的 AtlasAdapter SPI、RecordValidator 校验 SPI、IngestService 摄取 SPI，零框架依赖
sourcelume-registry-validation-jsonschema校验插件：JSON Schema draft 2020-12（networknt 实现，含 format 断言）
sourcelume-registry-validation-shacl校验插件：SHACL（Apache Jena 实现，离线内联 context）
sourcelume-registry-atlas-adapterAtlasAdapter SPI 的薄 REST 实现（JDK HttpClient）
sourcelume-registry-runtime-quarkusQuarkus REST 运行时，端口 8082，启动时做规范校验与类型注册自举

REST API（README 实录，均挂在 8082 端口）：数据集端 /api/v1/datasets（创建/更新、按 qualifiedName 或 Atlas GUID 查询）、类型端 /api/v1/types（检视注册的 typedef）、记录端 POST /records（摄取）、GET /records/{id}（读取）、POST /records/validate（入库前预检）；就绪探针（反映 Atlas 连通性）与存活探针经 Quarkus Health 暴露，Prometheus 指标同步提供。后端元数据仓为 Apache Atlas（图谱式元数据管理与血缘），配置项集中在 sourcelume.atlas.*。为降低上手门槛，官方另附 examples/simple-demo——以内存存储替代 Atlas 的轻量实现，配套 Community Over Code Glasgow 2026 Hackathon 的端到端演练脚本（就绪核验、类型检视、数据集注册、记录摄取与查询），并演示完整生命周期语义：不完整记录入库为 INCOMPLETE、修订后晋升 VALIDATED、改写已校验记录返回 409 Conflict。

构建要求：JDK 21、Maven 3.9+，且需先对 sourcelume-spec 执行 mvn install。本机无 Java 工具链，此构建路径未做实测。

💡 技术拓展：Apache Atlas 是 Hadoop 生态沉淀下来的元数据治理与数据血缘框架，自带类型系统（typedef）与图谱查询，Sourcelume Registry 选择它做底座等于直接继承 lineage 能力；Quarkus 则是面向 JVM 的云原生框架，启动快、内存占用低，适合把注册中心做成常驻服务。Core/运行时分层的价值在于：AtlasAdapter 是 SPI 接口，未来可替换其他元数据后端而不动核心。

3.4 规范校验最小实测

本机未装 Java，但规范校验是纯 Python 路径，可以真实跑通。做法：复刻 sourcelume-spec 的 tools/validate.py 校验逻辑（JSON Schema 结构校验 + 捆绑 context 内联后跑 SHACL），对 sourcelume-registry/examples/simple-demo 目录下两个样本记录实测：

样本记录实测结果
sample-provenance-record.jsonld（完整记录，含许可、角色化 creator、保管链）JSON Schema 通过，SHACL conforms
sample-incomplete-record.jsonld（故意缺失许可元数据）JSON Schema 拒绝，报错 'license' is a required property

实测环境：Python 3.10.12 + jsonschema 4.26.0 + rdflib 7.6.0 + pyshacl + pyld（pip 安装）。两点说明：其一，这组实验同时验证了规范文件自洽可用，以及"不完整记录在预检阶段被结构化拒绝"的设计与 Registry 的校验链行为一致；其二，spec 的 pyproject 声明 requires-python >=3.11，本次在 3.10 上以库调用方式运行上述逻辑无兼容问题，正式使用建议遵循声明的 3.11+。

四、功能特性

以下只列当前实际具备的能力（均有仓库或官网出处），路线图项见 3.1 节表格。

  • 规范已有可执行形态：JSON Schema（结构）+ SHACL（语义）双阶段校验，Python 参考校验器与单元测试随仓库提供，schema/context/正文三处版本号一致。
  • 跨标准映射已成文：Croissant、SPDX AI Profile、OTDI 三份 crosswalk 映射文档入库，规范词表显式复用 dct、schema.org、spdx、xsd 既有词表，仅新增 sl: 私有命名空间承载真正独有的术语。
  • 许可表达贴近现实：licenseScope/licenseNote/licenseCategory/licenseHistory 四个字段覆盖辖区限定许可、IRI 误导、一眼分类、历史变更四类真实场景，并有两条临时许可 IRI 约定（公有领域主张、双边协议数据）在正文中明确标注为"待邮件列表定案的临时约定"。
  • Registry 内核框架无关：AtlasAdapter/RecordValidator/IngestService 三个 SPI 与具体框架解耦，校验插件经 ServiceLoader 发现、启动即装配（装配失败拒绝启动），验证阶段与 Python 参考校验器保持行为对等。
  • 记录生命周期语义完整：预检校验、INCOMPLETE 状态、修订晋升 VALIDATED、已校验记录防改写（409），配合 simple-demo 可端到端演示。
  • 可观测性就绪：健康探针（就绪项反映 Atlas 连通性）与 Prometheus 指标开箱即有。

五、适用场景与限制

5.1 适用场景（展望）

基于官网定位与已有产出，以下场景值得前瞻关注，但都应以"项目拿出正式版本"为前提：

  • 数据集发布方为语料建立可核验的许可与来源档案，降低下游使用方的尽调成本；
  • 模型训练团队在训练前批量校验训练集的溯源记录完整性，把合规检查前移到数据接入环节；
  • 审计与合规团队对已发布记录做独立核验与图谱式血缘追查（Registry 的 Atlas 底座天然支持）；
  • 既有数据治理平台（已在用 Atlas、Iceberg、NiFi、Airflow 的团队）以 Connectors 方式把溯源元数据接入自有栈。

5.2 限制（调研确认）

  • 没有任何正式发布：downloads.apache.org 无分发包（404）、Maven Central 无构件（404）、三仓库均无 git tag；Registry 停在 0.0.1-SNAPSHOT，规范停在 Draft。当前不存在可钉住依赖的版本号，任何生产引用都会随上游变更而失效。
  • 规范发布流程未跑完：规范声明的 context IRI 在线返回 404，仅仓库内捆绑副本可用；README 描述的 examples/ 目录尚未入库，文档与仓库内容存在少量超前。
  • 组件缺口明确：Attestation（签名校验库）、CLI、Explorer、Connectors 尚无代码；规范的 v0.0.1 自述非目标即"无签名块、无裁定字段、无使用/审计元数据"——即签名与核验这一卖点能力本身还未落地。
  • GraphQL 为目标态：官网架构图标注的 REST/GraphQL 双接口中，当前实现仅有 REST。
  • 文档基线很薄：官网 FAQ 仅两条且自述"将随邮件列表讨论增长"；安装、部署、运维文档需看仓库 SETUP/dev-support，且以开发态为主。
  • 本文实测覆盖有限：Java 构建与 Registry 运行（需 Atlas 与 JDK 21 环境）未在本机验证，Python 校验路径实测通过。

六、同类选型对比

AI 训练数据溯源/透明度方向的主流方案（现状栏为 2026-10 调研口径）：

方案类型关注粒度现状适用
Apache Sourcelume数据集级溯源规范 + 可查询注册中心数据集的来源、保管链、许可，强调签名与独立核验规范 Draft（v0.0.1），Registry 0.0.1-SNAPSHOT，无任何正式发布提前跟踪标准演进、参与共建或做原型验证
C2PA / Content Credentials内容级密码学溯源单个媒体文件的"出生证明"与编辑历史生态成熟，多厂商落地，工具链可用图片/音视频逐文件溯源与真伪核验
SPDX AI ProfileAI 系统/数据集物料清单（AI BOM）供应链合规清单，模型与数据成分规范持续演进，工具链逐步跟进合规清单交付、企业级供应链审计
MLCommons Croissant数据集描述元数据（机器可读 datasheet）让 ML 数据集可发现、可加载、可比较已被多家数据平台采纳数据集发现与描述，不含签发与核验链路
数据集卡片 / datasheets 惯例人读文档约定文档化最佳实践广泛使用轻量文档化，无需强校验与基础设施

💡 技术拓展：C2PA 与 Sourcelume 并不冲突而是粒度互补——C2PA 把签名溯源信息绑定进单个媒体文件（一份截图、一段视频），适合"这一帧是不是生成的"这类判断；Sourcelume 处理的是"数据集"这种由多文件构成的集合级资产，强调记录间的保管链引用与注册中心查询。SPDX AI Profile 与 Croissant 则分别从"合规 BOM"和"数据集描述"两个维度与 Sourcelume 的 crosswalk 打通——后者映射文档已入库即是证据。

选型结论：今天就要跑通生产级溯源管线的团队，Sourcelume 目前给不了可依赖的版本，务实路径是用 C2PA（内容级）或 SPDX AI Profile（清单级）先行；需要为组织内数据集溯源元数据定标准的团队，可参照其 v0.0.1 的 schema 与三份 crosswalk 起步，但必须接受 Draft 状态下的变更风险；对标准演进敏感、希望影响规范走向的团队，dev@ 邮件列表开放订阅，当前正是以极低成本输入意见的窗口期——规范正文明确把两条许可 IRI 约定等开放问题留给社区定案。

七、参考链接