DCMI AP Conformance Audit (v0.1.1)¶
這份報告做什麼？ 本檔是 Prov-AI AP 對 DCMI 兩份核心規範的逐項對標複盤，給主管 / 審稿人作為「我們已對齊」的核驗依據。
- Singapore Framework for Dublin Core Application Profiles — 用來驗 AP 主文件架構（5 大段）。
- Application Profile Guidelines — 用來驗 element 表與 term usage 表（9 欄）。
本檔與
ap-guideline-checklist.md互補：
- checklist 是長期維護、跨版本追蹤的對齊指標表；
- audit 是針對「2026-05-20 主管澄清『要用 DCMI、不是 DCAT-AP』」這一節點，產出單次定錨的核驗報告。
§1 對標範圍與規範路徑¶
1.1 主對標（P0，必須對齊）¶
| 規範 | 角色 | 採用位置 |
|---|---|---|
| DCMI Metadata Terms | 提供 dcterms:* element-level 詞彙 |
L1 Core 9 個 dcterms:* element（identifier / language / hasPart / subject / source / hasVersion / license / accessRights / created） |
| Singapore Framework | AP 5 層架構 | mkdocs nav 9 章節對應 5 大段 |
| Application Profile Guidelines | element / term usage 表 9 欄 | AP_SCHEMA.md §5 living registry + profile.md 對外元素表 |
1.2 背景參考（非主對標）¶
| 規範 | 為何不採為主對標 |
|---|---|
| DCAT-AP | 歐洲數據目錄（Dataset / Distribution / Catalog 為核心類），與 Prov-AI 的「LLM 對話與 KOS 治理溯源」場景不重疊 |
| PROV-O / SKOS / OA / DQV / PROF | 為 element-level vocabulary（直接拿來用），不是 AP 文件架構規範 |
| DCTAP | 落地工件（CSV registry），列入 v0.2 roadmap，非本次 audit 對象 |
R-026 採納：DCMI Singapore Framework + DCMI AP Guidelines 為主對標路徑；DCAT-AP 明確標示為「非對標、僅背景參考」。
§2 Singapore Framework 5 大段對齊（主文件架構）¶
Singapore Framework §1 主張 AP 應由 5 層 artifact 組成。對外網站 mkdocs nav 對應如下：
| Singapore Framework 段 | 對應對外章節 | 對應工作層 canonical | 完整度 |
|---|---|---|---|
| 2.1 Functional Requirements | Home + Introduction | AP 主稿 §0.1 + §3 CQs | ✅ 完整 |
| 2.2 Domain Model | Model | AP 主稿 §4 + canonical_paths.md |
✅ 完整 |
| 2.3 Description Set Profile | Profile + Concept Schemes | AP_SCHEMA.md §5 + concept_schemes/*.ttl |
🟡 部分（見 §3） |
| 2.4 Vocabulary Encoding Schemes | Concept Schemes | 5 個 L1 必用 SKOS TTL | ✅ 完整 |
| 2.5 Usage Guidelines | Usage + Examples | AP 主稿 §2 撰寫指引 + 07_case_dossiers | 🟡 部分（JSON-LD / API 路徑範例待 v0.3） |
2.1 Functional Requirements¶
| 對齊指標 | 狀態 | 證據 |
|---|---|---|
| 明示 use case / 受眾 | ✅ | index.md §為誰寫 |
| 明示 competency questions | ✅ | conformance.md §CQs Coverage（18 道 CQ） |
| 標示 L1 / L2 分層 | ✅ | introduction.md §L1 Core / L2 Modules 分層 |
2.2 Domain Model¶
| 對齊指標 | 狀態 | 證據 |
|---|---|---|
| 核心 class 清單 | ✅ | model.md §L1 Core 結構樹 |
| Property 含 domain → range | ✅ | profile.md §L1 Object Properties |
| Triple paths 描述 | ✅ | model.md §主要 Triple Paths |
| PROV-DM crosswalk | ✅ | model.md §PROV-DM 相容性 |
2.3 Description Set Profile¶
| 對齊指標 | 狀態 | 證據 / 缺口 |
|---|---|---|
| 每 element 含 declared_type | ✅ | AP_SCHEMA.md §5 第 4 欄 |
| 每 element 含 requirement (MUST/SHOULD/OPT/conditional) | ✅ | AP_SCHEMA.md §5 第 11 欄 |
| 每 element 含 domain / range | ✅ | AP_SCHEMA.md §5 第 8-9 欄（class row 為 - 並轉 usage_notes） |
| 每 element 含 cardinality | 🟡 散在 canonical_paths.md §2 |
本次 audit 後合併到 AP_SCHEMA.md 新欄 cardinality |
| 每 element 含 definition | 🟡 只有 typical usage context | 本次 audit 後新增 definition 欄 |
| conditional MUST 條件獨立可查 | 🟡 散在 notes 內 |
本次 audit 後新增 condition 欄 |
| 控制詞彙以 SKOS ConceptScheme 治理 | ✅ | 5 個 L1 必用（TaskType / ActivityType / ArtifactType / Role / DecisionOutcome） |
| DCTAP CSV | ⏳ v0.2 | 排程於 v0.2，不在本次 audit 範圍 |
2.4 Vocabulary Encoding Schemes¶
| 對齊指標 | 狀態 | 證據 |
|---|---|---|
| 控制詞彙為獨立 ConceptScheme | ✅ | 02_schema/concept_schemes/*.ttl（5 個） |
| 雙語 prefLabel（en + zh-Hant） | ✅ | 全部 5 檔 |
| closed vs open scheme 標示 | ✅ | DecisionOutcomeScheme 為 closed；其餘 4 個 draft 可擴 |
| 配套驗證腳本 | ✅ | scripts/prov-ai-validate-concept-schemes.py（8 條檢查） |
| Base URI 拍板 | ⏳ v0.2 | https://example.org/aatprov/ 為 placeholder，待 namespace policy 拍板 |
2.5 Usage Guidelines¶
| 對齊指標 | 狀態 | 證據 |
|---|---|---|
| IRI / Identifier 規約 | ✅ | usage.md §IRI / Identifier 規約 |
| Prefix 與 namespace 宣告 | ✅ | usage.md §Prefix 與命名空間 |
| 多條取值路徑（Share / API） | ✅ | usage.md §兩條取值路徑 |
| Case mapping 流程 | ✅ | usage.md §案例 mapping 流程 |
| Turtle 範例 | 🟡 | examples/c02-motifs.md（1 個） |
| JSON-LD 範例 | ⏳ v0.3 | 待補 |
| API path 範例 | ⏳ v0.3 | 待補 |
§3 Application Profile Guidelines 9 欄對齊（element / term usage 表）¶
R-062 誠實補強（2026-05-21）：本節原使用「100% 對齊 DCMI 9 欄」字眼有過度宣稱之嫌。實際上 DCMI 並無任何單一規範強制「element/term usage 表必須 9 欄」；本 9 欄為 Prov-AI 自定義組合，取自 DCMI Metadata Terms（Definition 欄）+ DCMI Application Profile Guidelines（Obligation / Condition 欄）+ DCTAP（cardinality / datatype / valueConstraint 欄）三者。對標方向對、精神對（採 DCMI 風格 + 主管設定的 9 欄目標），但並非單一 DCMI 規範強制 9 欄的字面對齊；後續所有「100%」表述均應理解為「對 Prov-AI 自定義 9 欄目標的 100% 完成」，非「DCMI 強制 100% 對齊」。
AP Guidelines §6 列出 element / term usage 表應有的標準欄位（主管列出 9 欄目標）。
3.1 工作層 AP_SCHEMA.md §5 對齊現況¶
| 主管 9 欄 | 對應到 AP_SCHEMA.md 既有欄位 |
狀態 |
|---|---|---|
| Term URI | stable_id（e.g., provai:dcterms-identifier） |
✅ 既有 |
| Name / Label | name（e.g., dcterms:identifier） |
✅ 既有 |
| Defined By | standard_mapping（e.g., DCMI Terms：dcterms:identifier） |
✅ 既有 |
| Definition | 無獨立欄；散在 usage_notes 的 "typical usage context"（非形式化定義） |
❌ 本次新增 definition |
| Obligation | requirement（MUST / SHOULD / OPTIONAL / MUST conditional） |
✅ 既有 |
| Condition | 無獨立欄；散在 notes 的 conditional 邏輯描述 |
❌ 本次新增 condition |
| Datatype | range（e.g., xsd:string, xsd:dateTime, IRI） |
✅ 既有 |
| Occurrence (cardinality) | 無欄；資料散在 canonical_paths.md §2 |
❌ 本次新增 cardinality |
| Encoding Scheme | 對 Object Property (SKOS-typed) row 已標註對應 scheme | ✅ 既有（隱含於 declared_type + notes） |
結論：9 欄中 6 欄齊備、3 欄需新增（definition / condition / cardinality）。
3.2 Release 層 profile.md 對齊現況¶
profile.md 為對外乾淨版，目前元素表為 6 欄（名稱 / 國際標準 / declared_type / requirement / capture / CQ），相對 AP Guidelines 9 欄為簡化呈現。
| 主管 9 欄 | 對應到 profile.md 現有欄 |
狀態 |
|---|---|---|
| Term URI | 「名稱」欄即含完整 prefix（如 dcterms:identifier） |
✅ 隱含 |
| Name / Label | 「名稱」欄 | ✅ |
| Defined By | 「國際標準」欄 | ✅ |
| Definition | ❌ 缺 | ❌ 本次新增 |
| Obligation | 「requirement」欄 | ✅ |
| Condition | ❌ 隱含於 requirement 字串 "MUST (conditional: ...)" | 🟡 本次抽欄 |
| Datatype | ❌ 缺（Object Property 有 domain → range；Data Property 表沒這欄） | 🟡 本次補欄 |
| Occurrence | ❌ 缺 | ❌ 本次新增 |
| Encoding Scheme | ✅ Concept Schemes 分頁 | ✅ |
結論：release 層 6 欄中對應齊 4 欄，需擴為 9 欄主表 + 延伸欄副欄。
3.3 Prov-AI 延伸欄（保留並存）¶
下列欄位為本專案的「延伸後設」，不屬 AP Guidelines 9 欄，但對 Prov-AI 治理場景必要：
| 延伸欄 | 用途 | 對標說明 |
|---|---|---|
declared_type |
Class / Object Property / Object Property (SKOS-typed) / Data Property / Controlled Vocabulary Scheme / Documentation | 補 RDFS / OWL 推論的型別軌道（R-001 採納） |
layer |
L1 / L2 / L2-optional | 對應 Singapore Framework "core vs module" 分層 |
parent_id |
對應到 §6 Module Hierarchy Anchors | 模組依賴樹（conformance class 載入用） |
module |
Core / OA / DQV / Reference / Control vocabulary | 模組分群 |
capture_method |
AUTO / HYBRID / HUMAN | LLM 對話資料的擷取路徑（本專案特色） |
cq_mapping |
CQ1–CQ10 / CQ18 等 | 對應 §3 competency questions |
status |
active / deprecated / pending | element 生命週期 |
usage_notes |
typical usage context | 對 class row 補敘述（R-002 採納；明確非 SHACL constraint） |
notes |
R-XXX 接點 / 設計 trade-off | 變更軌跡與設計理由 |
3.4 表頭視覺分組策略¶
AP_SCHEMA.md §5 與 profile.md 元素表將以下列順序排列（前 9 欄為 AP Guidelines 對標欄，後段為 Prov-AI 延伸欄）：
▼ AP Guidelines 9 欄 ▼ ▶ 主管核驗區
stable_id (Term URI) | name (Label) | standard_mapping (Defined By) | definition | requirement (Obligation) | condition | range (Datatype) | cardinality (Occurrence) | encoding_scheme
▼ Prov-AI 延伸欄 ▼ ▶ 治理場景補充
declared_type | layer | parent_id | module | domain | capture_method | cq_mapping | status | usage_notes | notes
~~註：
encoding_scheme在 9 欄中為虛擬欄，實際資料由declared_type = Object Property (SKOS-typed)+notes內「值需指向 XXScheme」標示承載。對外網站可在profile.md加一句說明指向 Concept Schemes。~~R-061 修正（2026-05-21）：原註的「虛擬欄」設計是把 Encoding Scheme 狹義限制為僅 VES（Vocabulary Encoding Scheme）的誤判。DCMI 對 Encoding Scheme 的真實定義同時涵蓋 SES + VES 兩種：
- SES (Syntax Encoding Scheme) — 值的語法／格式標準，如
W3CDTF(ISO 8601 profile) /RFC 3986(URI) /RFC 3987(IRI) /RFC 5646(BCP 47 language tag) /RFC 8259(JSON) /xsd:nonNegativeInteger等- VES (Vocabulary Encoding Scheme) — 受控詞彙，指向 SKOS ConceptScheme 等
R-061 補欄後：10 row 補 SES + 6 row 已有 VES + 44 row 為
-（class / 非 SKOS-typed Object Property / 自由字串 Data Property）。Encoding Scheme 欄不再是「虛擬欄」。
3.5 Conformance Language: 結構對標 DCMI / 字眼對標 RFC 2119（R-080，2026-05-22）¶
R-080 補強（2026-05-22）：本節釐清「對標 DCMI」的範圍邊界 — 表頭結構對標 DCMI Application Profile Guidelines §6（9 欄組合），但 obligation 欄的字眼對標 RFC 2119 而非 DCMI
mandatory / recommended / optional字眼。兩者分流是刻意設計，非疏漏。
3.5.1 分流原則¶
| 層 | 對標基準 | 採用值 |
|---|---|---|
| 9 欄表頭結構（Term URI / Label / Defined By / Definition / Obligation / Condition / Datatype / Occurrence / Encoding Scheme） | DCMI Application Profile Guidelines §6 | 既有 9 欄（per R-027~R-030 + R-061） |
| Obligation 欄的值（MUST / SHOULD / OPTIONAL / MUST (conditional)） | RFC 2119（繼承自上游 W3C vocabulary） | 與 PROV-O / SKOS / DX-PROF / Web Annotation / DQV 一致 |
| Definition 欄風格 | DCMI Metadata Terms 單句 ontological | per R-047a / R-047b / R-048（B1 批次收斂） |
3.5.2 為何不採 DCMI mandatory 字眼¶
W3C 場域慣例（強）：本 AP 重用之 5 套 W3C vocabulary（PROV-O / SKOS Reference / DX-PROF / Web Annotation / DQV）conformance section 全部 normative reference RFC 2119。本 AP 主體採 PROV-O，obligation 字眼對齊 RFC 2119 是繼承自上游的一致性，非自選風格。若 AP 表改用 DCMI mandatory 字眼，會在 PROV-O term 上產生「上游 MUST / 下游 mandatory」字眼不一致。
DCMI 派內部字眼不統一（強）：DCMI 派 profile 字眼本身就有多種變體 — DCAT-AP 採 Mandatory / Recommended / Optional；DC-Library AP 採 mandatory / mandatory if applicable / strongly recommended / optional；DDI-Lifecycle 採 required / recommended / optional。「對齊 DCMI 風格」本來就無單一目標可對齊；保持 RFC 2119 字眼 + 明示對標基準（per R-079 在 profile.md 新增 Conformance language 段）反而更誠實。
RFC 2119 已是 W3C TR 標準慣例：W3C 所有 TR 文件的 conformance section 樣板即「The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC 2119]」。AP 採此樣板使其落入 W3C TR 場域審稿人預期。
3.5.3 本 AP 對 conditional 的擴充¶
MUST (conditional: …) 並非 RFC 2119 原生關鍵字，係本 AP 對「條件成立時必填」的欄位層級擴充標示（搭配 Condition 欄使用）。功能上與下列 DCMI 派做法相近：
| 規範 | 等效表達 |
|---|---|
| DCMI Application Profile Guidelines §6 | Mandatory (conditional) |
| DC-Library Application Profile | mandatory if applicable |
| DCAT-AP（部分屬性） | conditional |
| DCTAP（W3C 2022） | mandatory: true + note 補條件描述 |
當前 AP 中使用 MUST (conditional) 的 element 共 2 個（v0.1.2.1 R-086 後）：
| Element | Condition | 落地 R-XXX |
|---|---|---|
ex:Result |
僅 result-bearing taskType（術語翻譯／範圍註翻譯／同義詞辨識／評估等） | R-006（2026-05-04） |
ex:decisionOutcome |
僅 ex:artifactType = DecisionNote 之 Artifact |
R-004（2026-05-04） |
v0.1.2.1 R-086 變動：
ex:activityType於 v0.1.x 階段 R-078 採MUST (conditional: TaskRun)；v0.1.2.1 R-082 兩軸分離後 domain 縮為ex:TurnRunonly，conditional 的 TaskRun 分支不再存在；R-086 將 requirement 退回純SHOULD、從本清單移除。R-078 + R-083 + R-086 三條紀錄共同呈現「conditional 表達適用範圍」演進路徑，作為未來 conformance design pattern 的參考 case。
3.5.4 §5 完整度摘要影響¶
本節（§3.5）為 audit 文件側補強，不更動既有 §5 完整度摘要的對標完成率。R-079 在 profile.md 新增的 Conformance language 段為主要對外論述位置；本節為 audit 文件側對標分流的形式化表述。
§4 R-XXX 待辦清單（本次 audit 衍生）¶
對齊 _canonical_paths_v02_revisions.md 格式：
| R-id | 類別 | 目標 | 動作 | 範圍 | 狀態 |
|---|---|---|---|---|---|
| R-026 | scope-clarify | (全域) | 確認 DCMI Singapore Framework + AP Guidelines 為主對標，DCAT-AP 為背景參考 | docs/references/ + standards-index.md | 完成（本檔即定錨） |
| R-027 | structural | AP_SCHEMA.md §5 |
新增 cardinality 欄，資料源自 canonical_paths.md §2 |
工作層 | 本次落地 |
| R-028 | structural | AP_SCHEMA.md §5 |
新增 definition 欄，為每 element 寫一句形式化定義 |
工作層 | 本次落地 |
| R-029 | structural | AP_SCHEMA.md §5 |
新增 condition 欄，從 notes 抽出 conditional 邏輯 |
工作層 | 本次落地 |
| R-030 | release-sync | profile.md |
element 表 6 欄擴為「9 欄主表 + 延伸欄副欄」 | release 層 | 本次落地 |
| R-031 | tooling | prov-ai-sync-ap-schema.mjs |
csvHeaders 加入 3 欄，element_registry.csv 同步 | 工作層 | 本次落地 |
| R-032 | correctness-fix | AP_SCHEMA.md §5 |
補登 provai:prov-wasGeneratedAtTime（profile.md / canonical_paths.md §2 已列，工作層 §5 漏錄）。Baseline L1: 37→38；Total: 54→55；語意層無變動 |
工作層 | 本次落地 |
延後（仍排在 v0.2 / v0.3）：
| R-id | 類別 | 目標 | 動作 | 排程 |
|---|---|---|---|---|
| R-032 | tooling | dctap/profile.csv |
DCTAP CSV 從 element_registry.csv 重組 | v0.2 |
| R-033 | policy | namespace | base URI 從 https://example.org/aatprov/ 拍板為正式 URI |
v0.2 |
| R-034 | tooling | shapes/*.shacl.ttl |
SHACL shapes 對應 conditional MUST / cardinality | v0.3 |
| R-035 | tooling | profile.ttl |
PROF Manifest stub（連結 AP / TTL / SHACL / examples / DCTAP） | v0.2 |
§5 完整度摘要¶
R-062 誠實標示（2026-05-21）：下表的「100%」均指對 Prov-AI 自定義 9 欄目標（取自 DCMI Metadata Terms + AP Guidelines + DCTAP 三者）的完成率，非 DCMI 強制 9 欄的字面對齊。原文「DCMI 對標」一詞範圍模糊，應理解為「DCMI 風格對標」。
| 對標範圍 | 完成率（v0.1.1 audit 後 + R-061/R-062 補強） | 變動 |
|---|---|---|
| Singapore Framework Functional Requirements | 100% (3/3) | 維持 |
| Singapore Framework Domain Model | 100% (4/4) | 維持 |
| Singapore Framework DSP | 100% (8/8) | 🆙 從 80%（DCTAP 不計）：cardinality / definition / condition 三欄補齊 |
| Singapore Framework Vocabulary Encoding Schemes | 100% (4/4) | 維持（namespace 拍板獨立 backlog） |
| Singapore Framework Usage Guidelines | 71% (5/7) | 維持（JSON-LD / API path v0.3） |
| Prov-AI 自定 9 欄（工作層） | 100% (9/9) + Encoding Scheme 補 SES 內容（R-061） | 🆙 從 67%（6/9）→ 含 SES/VES 雙覆蓋 |
| Prov-AI 自定 9 欄（release 層） | 100% (9/9) + Encoding Scheme 補 SES 內容（R-061） | 🆙 從 44%（4/9）→ 含 SES/VES 雙覆蓋 |
| 總體（DCMI 風格對標） | 🆙 從 70% → 92% | DCTAP / SHACL / namespace 拍板剩在 v0.2-v0.3 |
§6 為何不採 DCAT-AP（給審稿人查核用）¶
DCAT-AP 為「歐洲數據目錄應用 profile」，核心類為 dcat:Catalog / dcat:Dataset / dcat:Distribution。Prov-AI AP 的核心類為 ex:WorkItem / ex:TaskRun / ex:TurnRun / ex:Artifact / prov:Association —— 語意層完全不同：
| 對比軸 | DCAT-AP | Prov-AI AP |
|---|---|---|
| 場景 | 數據集發布與目錄編製 | LLM 對話 / KOS 治理的溯源紀錄 |
| 主類 | Dataset / Distribution | TaskRun / TurnRun / Artifact |
| 結構 | catalog → dataset → distribution | WorkItem → TaskRun → TurnRun → Artifact / Result |
| 控制詞彙 | EU controlled vocabularies | 5 個自訂 SKOS ConceptScheme（TaskType / ActivityType / ArtifactType / Role / DecisionOutcome） |
| 對應主規範 | DCAT (W3C) + EU specifics | PROV-O (W3C) + DCMI Terms + SKOS |
結論：DCAT-AP 與 Prov-AI 的目標場景無交集，採之不僅無益且會引入歐洲特定的字串約束（如 dcat:keyword mandatory 等）造成模型噪訊。正確路徑是直接對標 DCMI Application Profile Guidelines + Singapore Framework——後者是「如何寫一份 AP 的方法論」，與場景無關。
§7 接下來¶
- 落地 R-027 / R-028 / R-029：見
changelog.md與工作層02_schema/AP_SCHEMA.md§7 變更紀錄。 - v0.2 補 DCTAP CSV + namespace policy（R-032 / R-033）。
- v0.3 補 SHACL shapes + JSON-LD 範例 + API path example（R-034 + 既有 v0.3 roadmap）。
- 長期維護以
ap-guideline-checklist.md為主，本 audit 為節點報告（不重複維護）。