跳轉到

Changelog

本檔記錄 Prov-AI AP 對外發布版本的變更摘要。

格式遵循 Keep a Changelog；版本號遵循 Semantic Versioning。

[Unreleased]

下一輪變更累積處。

[0.1.2.1] — 2026-05-22

Patch bump — 同案例（C02 motifs / L13 paiban）後續修訂；含 RDF consumer 接口變更，仍提供 migration path。 TaskTypeScheme + ActivityTypeScheme 兩軸分離重整 + C02/L13 worked example binding 升級 + R-067 supersede + R-086 conformance language 連動一致化。⚠️ 接口變動（不離開 C02/L13 案例範圍）：URI 變更（TaskRunType → TaskTypeScheme/L2）+ ex:activityType domain 縮為 ex:TurnRun only；RDF consumer 需 migrate（透過 owl:deprecated + dcterms:isReplacedBy 提供 migration path）。

版本命名邏輯：v0.1.2.1 patch 級命名基於「同案例（C02/L13）後續修訂」邏輯，而非 SemVer 嚴格意義。新案例（如 L08 編鐘 / C15 silhouette animation）落地時才升 v0.1.3 minor。完整 release notes 見 v0.1.2.1 Release Notes。

展開查看 v0.1.2.1 全部變更（點擊收合）

Fixed

  • R-078 — ex:activityType requirement 一致化：SHOULD（工作層）/ MUST/SHOULD（release 層） → MUST (conditional: TaskRun)
  • 動機：原 MUST/SHOULD 斜線複合值為 53 個 element 中唯一斜線值（Requirement 圖例未列），審稿人讀表造成困惑；MUST/SHOULD 亦非 RFC 2119 原生關鍵字也非 DCMI / DCAT-AP / DC-Library / DCTAP 等任一規範採用之 obligation 表達。降階為 MUST (conditional) 後與 ex:decisionOutcome（DecisionNote conditional）/ ex:Result（result-bearing taskType conditional）採同一表達模式
  • 修改位置：
    • 工作層 AP_SCHEMA.md §5 provai:ex-activityType row：requirement SHOULD → MUST (conditional: TaskRun)；condition「TaskRun MUST、TurnRun SHOULD（差別化）」→「適用於 TaskRun；TurnRun 為 SHOULD 差別化」；notes 補 R-078 接點
    • Release 層 profile.md L1 Data Properties 表 ex:activityType row：requirement MUST/SHOULD → MUST (conditional)；條件「TaskRun MUST、TurnRun SHOULD（差別化）」→「適用於 TaskRun；TurnRun 為 SHOULD 差別化」
  • 不變範圍：stable_id / range / cardinality（1..1 (TaskRun) / 0..1 (TurnRun) 維持）/ encoding_scheme（VES: ActivityTypeScheme 維持）；TurnRun SHOULD 差別化語意完整保留於 condition 欄 + cardinality 欄
  • 設計判斷：v0.2 DCTAP CSV 階段考慮拆 row（per-shape statement template）為精準對齊路徑；v0.1.x 階段維持「一 element 一 row」+ conditional 摺疊表達

[v0.1.2.1 R-086 部分修訂；conditional 退回 SHOULD] — R-083 把 ex:activityType domain 縮為 ex:TurnRun only 後，conditional 兩個分支退化為單一 case（TurnRun SHOULD），MUST (conditional) 表達失去語意作用。R-086 把 requirement 改回純 SHOULD + condition 欄清空；release 層「3 個 MUST (conditional)」清單同步降為 2 個（保留 ex:Result + ex:decisionOutcome）。詳見 R-086 條目。

  • R-086 — ex:activityType requirement 從 MUST (conditional: TaskRun) 降回純 SHOULD（R-078 + R-083 連動衍生副作用）
  • 連動鏈：R-078（2026-05-22）把 requirement 改為 MUST (conditional: TaskRun)，當時 conditional 兩分支 = TaskRun MUST / TurnRun SHOULD；R-083（2026-05-22）把 domain 縮為 ex:TurnRun only，TaskRun 場景已不存在；conditional 退化為單一 case（TurnRun SHOULD），MUST (conditional) 表達已無語意作用
  • 修訂內容：
    • requirement MUST (conditional: TaskRun) → SHOULD
    • condition 欄清空
    • cardinality 維持 0..1（不再差別化）
    • usage_notes 加 R-086 接點
  • Release 層連動：
    • conformance.md Conformance Language 段「當前 3 個使用 MUST (conditional) 的 element」清單 → 2 個（保留 ex:Result + ex:decisionOutcome；移除 ex:activityType）
    • profile.md L1 Data Properties 表 ex:activityType row 同步 + 「Requirement 圖例」段 MUST (conditional: …) bullet 移除 ex:activityType 範例
    • dcmi-ap-conformance-audit.md §3.5.3 對應 element 清單同步
  • 設計判斷：R-086 並非 R-078 設計錯誤，而是 R-083 兩軸分離後的自然清理；R-078 + R-083 + R-086 三條紀錄共同呈現「conditional 表達適用範圍」的演進路徑，作為未來 conformance design pattern 的參考 case
  • stable_id / range / encoding_scheme（VES: ActivityTypeScheme）不變

Restructured

  • R-081 — TaskTypeScheme 從 v0.1.1 flat 5 topConcept 重整為 v0.1.2.1 三 L1 + 7 L2 narrower（asymmetric）+ 5 deprecated stub
  • 新 L1：
    • ChineseLocalization（中文化；C 系列）— L2：TermTranslation, ScopeNoteTranslation
    • LocalCulturalConstruction（在地化；L 系列）— L2：SynonymJudgement, ScopeNoteWriting
    • Evaluation（評估；升 L1 取代原 flat EvaluationReport）— L2：HumanInteractionEvaluation, ExpertReview, AutomatedEvaluation
  • L2 分流標準（Evaluation 下）：依「提示詞固定性 + AI 介入與否」三分：
    • AutomatedEvaluation：AI + 固定提示詞模板（典型：C02 #3 範圍註自動評估 prompt AAT-SN-QA-v1）
    • HumanInteractionEvaluation：AI + 非固定提示詞（典型：C02 #2 第二輪人機互動討論）
    • ExpertReview：純人工、無 AI 介入（典型：L13 領域專家複審 2026-05-19）
  • 舊 5 flat topConcept 全部 deprecate + isReplacedBy：TermTranslation / ScopeNoteTranslation / ScopeNoteAuthoring / SynonymJudgement / EvaluationReport（保留 skos:inScheme 作歷史紀錄、移除 skos:topConceptOf）
  • asymmetric 設計理由（per SOP §4.4 最簡）：未做 5×2 mirror，僅按案例需求建 narrower；ChineseLocalization 下不建 SynonymJudgement（C 系列無此 case）、LocalCulturalConstruction 下不建 TermTranslation（L 系列無此 case）
  • 修改位置：
    • 工作層 TaskTypeScheme.ttl（153 triples / 15 concepts / 3 tops / 7 broader-narrower 對稱；驗證腳本 C1-C8 全綠）
    • Release 層 task-type.ttl 完整 mirror
    • Release docs task-type.md 概覽頁重組（active 主表 + 「Deprecated since v0.1.2.1」短段）

  • stable_id 維持：provai:scheme-TaskTypeScheme；scheme 角色不變

  • R-082 — ActivityTypeScheme 兩軸分離議題正式落地（v0.1.2.1 ttl L55 已標 §10.X1 議題）— 從「TaskRun + TurnRun 雙軸」縮減為「TurnRun only」

  • TaskRunType 分支整支 deprecate：TaskRunType / TaskRun_TermTranslation / TaskRun_ScopeNoteTranslation / TaskRun_ScopeNoteEvaluation 全部 owl:deprecated + dcterms:isReplacedBy → TaskTypeScheme 對應 L2（per R-081）
  • TurnRunType 中間層解除：原 3 narrower 直接升為 topConcept，URI 簡化為 /ActivityTypeScheme/{InitialPrompting,Probing,Revising}（移除 TurnRun_ 前綴 + topConcept 升級）；舊 /TurnRunType 中間層 + 舊 /TurnRun_* 路徑 deprecate + isReplacedBy 指新短 URI 維持向後相容
  • 動機：使用者明示心智模型中 ActivityTypeScheme 應只含 turn-level 3 軸（InitialPrompting / Probing / Revising）；TaskRunType 與 TaskTypeScheme 概念上 overlap，是歷史 cruft
  • CQ18 滿足度不變：InitialPrompting / Probing / Revising 仍滿足 CQ18 初答 / 追問 / 修訂三軸；scheme 縮減不影響 value 可用性

  • 修改位置：

  • R-084 — C02 motifs worked example binding 升級 + 第二輪重新分類為人機互動評估

  • WorkItem.taskType：TermTranslation → ChineseLocalization/TermTranslation
  • TaskRun T-C02-r1（第一輪術語翻譯）：ex:activityType + TaskRun_TermTranslation → ex:taskType + ChineseLocalization/TermTranslation（與 WorkItem 一致）
  • TaskRun T-C02-r2（第二輪術語轉譯討論；share 688718a6...）：重新分類為 ex:taskType + Evaluation/HumanInteractionEvaluation（原誤標為 TaskRun_TermTranslation）— 第二輪本質為「非固定提示詞之 AI–人類對話評估」，非翻譯任務
  • TurnRun activityType URI 短化：TurnRun_InitialPrompting → InitialPrompting 等 3 處
  • Result.activityType 移除：R-083 後 ex:activityType domain 縮為 TurnRun only，不適用 Result

  • 修改位置：c02-motifs.ttl（271 triples；驗證通過）+ c02-motifs.md 同步

  • R-085 — L13 paiban worked example binding 升級 + R-067 SourceEvidence-only capture pattern supersede

  • R-085 supersede R-067：把 2026-05-19 領域專家複審升為獨立 ex:TaskRun（taskType=Evaluation/ExpertReview），原 expert-reconfirmation-20260519 SourceEvidence Artifact 保留為該 TaskRun 之 prov:generated entity；DecisionNote dcterms:source 連結點不變
  • 5 條論證：
    1. PROV-O Activity 對齊 — 複審是有人類介入、有時序、有 generated entity 的活動，符合 prov:Activity 定義；用 Artifact 表達是降階
    2. 與 AI TaskRun 結構對稱 — 3 strategies 都是 TaskRun；同類分析活動的複審不該是 Artifact
    3. R-067 sunk cost 失效 — R-067 採 SourceEvidence-only 的核心理由是「避免新增 ActivityTypeScheme value 違反 §4.4 最簡」；R-081 升 Evaluation/ExpertReview L2 narrower 後 SKOS value 已存在，原避免動機失效
    4. CQ 機器可查 — 升 TaskRun 後 SPARQL ?tr ex:taskType <.../ExpertReview> 可直接找複審活動；原 Artifact 模式需走 ?ev ex:artifactType <SourceEvidence> + 過濾 expert-reconfirmation-* 路徑，不結構化
    5. 證據 vs 活動本質分流 — 專家提供的「確認紀錄」是 generated entity 性質的 SourceEvidence；專家進行的「確認活動」本身是 TaskRun — 兩者是不同概念，前一版 R-067 把活動壓縮為 Artifact 是模糊分界
  • WorkItem.taskType + 3 strategies TaskRun binding 升級：SynonymJudgement → LocalCulturalConstruction/SynonymJudgement（直接綁正確 L2，不再用 TaskRun_TermTranslation proxy）
  • 新增 ExpertReview TaskRun T-L13-expert-review-20260519：prov:wasInformedBy 連 3 strategies TaskRun + prov:qualifiedAssociation agent=domain-expert + role=Reviewer + prov:startedAtTime/endedAtTime=2026-05-19 純人工事件 + prov:generated 連原 expert-reconfirmation-20260519 Artifact（保留 SourceEvidence artifactType）
  • 修改位置：l13-paiban.ttl（278 triples；驗證通過）+ l13-paiban.md 同步（metadata 表 + §2 升級註記 + §9 整段重寫 + §10 移除 activityType 殘留）+ usage.md Expert reconfirmation capture pattern 章節整段重寫（章節名加 (R-085 起；R-067 supersede) + 尾段「歷史脈絡」3 點說明設計演進）
  • changelog v0.1.2 段 R-067 條目加 **[v0.1.2.1 R-085 supersede; see Unreleased]** 標記（v0.1.2 已 ship，歷史不可改）

Refined

  • R-083 — ex:taskType / ex:activityType 兩屬性對齊 R-081/R-082 兩軸分離後新角色定位（軸正交修訂）
  • ex:activityType：
    • domain 縮減 ex:TaskRun/ex:TurnRun → ex:TurnRun
    • requirement 從 R-078 之 MUST (conditional: TaskRun) 降回 SHOULD（R-083 supersede R-078 對本 row 之 conditional 表達 — domain 縮減後 conditional 失去基礎；後續由 R-086 連動清理 release 層 3→2 element 清單）
    • cardinality 1..1 (TaskRun) / 0..1 (TurnRun) → 0..1
    • definition「TaskRun／TurnRun 的活動類型（activity-level）」→「TurnRun 的對話回合行為（turn scale）」
  • ex:taskType：
    • domain 從 ex:WorkItem 擴為 ex:WorkItem/ex:TaskRun（task-level 類型承擔點）
    • definition「WorkItem 的子任務分類（task-level）」→「WorkItem 與 TaskRun 的任務類型（task scale）」
    • usage_notes 補「WorkItem 與其 TaskRun 可分別 binding 不同 L2 narrower」（如 C02 WorkItem=ChineseLocalization/TermTranslation；其下 TaskRun #1 同 binding，TaskRun #2=Evaluation/HumanInteractionEvaluation）
    • CQ 對應 CQ1–CQ3 → CQ1–CQ4（含 TaskRun 細分）
  • 設計理由（X1 選項）：使用者選擇 ex:taskType 涵蓋 WorkItem + TaskRun 兩域，而非新增 ex:taskRunType 屬性。理由：兩域共用同屬性 + 同 scheme 最簡單；TaskRun 可細分於 WorkItem（如評估子任務）；SHACL / DCTAP 階段可繼續走 per-domain shape 分流
  • stable_id / range 不變

Documented

  • R-079 — Conformance Language 對標分流（conformance.md 主位置 + profile.md 簡短指向）
  • 動機：使用者調查確認 W3C 重用 vocabulary（PROV-O / SKOS / DX-PROF / Web Annotation / DQV）conformance section 全部 normative reference RFC 2119；AP 主體採 PROV-O 故 obligation 字眼對齊 RFC 2119 是繼承自上游的一致性，非自選風格。前 53 row 使用 MUST / SHOULD / OPTIONAL / MUST (conditional) 字眼若無顯式 RFC 2119 reference 則仍屬「自訂風格」；加 conformance section 後即升格為「繼承 RFC 2119 normative semantics」
  • 主位置：conformance.md 新增「## Conformance Language」章節（位於「## Conformance Classes」之前；對齊 W3C TR 慣例 — PROV-O §1.3 / SKOS Reference §1.5 / DX-PROF §1.4 / DQV §1.3 均如此安排）。內容三層：
    1. W3C TR 標準樣板 — 標準 RFC 2119 normative reference 段（"The key words MUST, MUST NOT, REQUIRED... are to be interpreted as described in [RFC 2119], when, and only when, they appear in all capitals."）
    2. 結構 vs 字眼分流表 — 9 欄表頭結構對標 DCMI Application Profile Guidelines §6 / Obligation 欄字眼繼承 RFC 2119（與重用之 W3C vocabulary 一致）/ Definition 欄風格對標 DCMI Metadata Terms 單句 ontological 三層
    3. 本 AP 對 conditional 的擴充 — MUST (conditional: …) 並非 RFC 2119 原生關鍵字 + 與 DCMI / DC-Library / DCAT-AP / DCTAP 等效表達對照表 + 當前 3 個使用 MUST (conditional) 的 element 列舉（ex:Result / ex:decisionOutcome / ex:activityType）
  • profile.md 簡短指向：「### Requirement 圖例」段下方加 blockquote 一段（本表 obligation 欄 RFC 2119 解釋 + 結構/字眼分流摘要 + 指向 conformance.md § Conformance Language）；既有圖例 bullet list MUST (conditional: …) 條目補 TaskRun activityType 範例（呼應 R-078 conditional 用法擴大到 domain-differential 場景）
  • 位置重審觸發：使用者觀察 W3C TR 慣例 conformance language 段位於 Conformance 章節（非 Profile 章節）；本批落地後重審位置，主對外論述移至 conformance.md；profile.md 改為「該頁專屬指引 + 指向 conformance.md 主論述」分工。audit 文件側論述位置（dcmi-ap-conformance-audit.md §3.5）維持為 R-080

  • schema 結構不變；不更動 53 row 既有 obligation 字眼

  • R-080 — references/dcmi-ap-conformance-audit.md §3 新增 §3.5 Conformance Language 對標分流說明

  • 動機：R-079 在 profile.md 加 conformance section 後需有對應的 audit 文件側論述支撐
  • 新增 §3.5 四段：(3.5.1) 分流原則表（結構對標 DCMI / 字眼對標 RFC 2119 / 定義風格對標 DCMI Metadata Terms 三層）；(3.5.2) 為何不採 DCMI mandatory 字眼（W3C 場域慣例 + DCMI 派內部字眼不統一 + RFC 2119 已是 W3C TR 標準慣例三論據）；(3.5.3) 本 AP 對 conditional 的擴充（含當前 3 個使用 MUST (conditional) 的 element 對照表）；(3.5.4) §5 完整度摘要不更動（本節為 audit 側補強，主要對外論述位置在 profile.md R-079 段）
  • schema 結構不變；不更動既有 §1-§7 對標範圍與 R-026 / R-061 / R-062 既有結論

[0.1.2] — 2026-05-22

L 系列首例 worked example milestone — L13 paiban 加入 + metaJSON 承載類型分類重設計 + acquisitionChannel deprecation + 5 處 antipattern 清理。完整 release notes 見 v0.1.2 Release Notes。

展開查看 v0.1.2 全部變更（點擊展開）

Added (2026-05-22)

  • R-064 + R-065 — L 系列首例 worked example：L13 Paiban + l13-paiban.ttl
  • 動機：M2 backlog Round 3 第一項；L13 paiban（在地化 × 同義詞辨識）作為 L 系列首例 worked example，建立 L 系列骨架先例（L08 編鐘將沿用此結構）
  • md 結構（13 章節仿 C02 + L 系列調整）：
    • §0 設計挑戰 — 3 strategies × 多對多候選詞 × 專家複審
    • §1 AI 介入前 baseline state
    • §2 WorkItem + 3 strategies 平行 TaskRun（per R-069 模式 A）
    • §3-5 Version A: Direct / Version B: AAT-guided / Version C: SPO Triple 各自 TaskRun + Result
    • §6 SourceEvidence × 6 類（vs C02 motifs 的 4 類；含領域專家證據）
    • §7 核心概念張力 6 大維度
    • §8 4 review inflection points
    • §9 2026-05-19 領域專家複審（per R-067 SourceEvidence 模式）
    • §10 Result 衍生鏈 + dossier Table 5 候選詞治理狀態表
    • §11 DecisionNote × 11（1 overview + 10 per-candidate）
    • §12 Provenance Gap 7 條
    • §13 對 Paper A 的貢獻 + CQ Coverage 自檢
  • TTL 結構（~150+ named individuals）：1 WorkItem + 3 TaskRun + 1 Collection + 6 SourceEvidence + 1 Result + 11 DecisionNote + 3 Agent
  • 結構亮點：
    1. 3 strategies parallel via prov:Collection.hadMember（per R-069 模式 A）
    2. Expert reconfirmation 以 SourceEvidence 表達不創ExpertReview TaskRun（per R-067，避免新增 ActivityTypeScheme value 違反 §4.4 最簡）
    3. candidate_role 多態（NPT / historic_predecessor_retained / rejected）走 metaJSON（per R-068.1 次要承載 + R-048-note 沿用 + R-068 多對多 capture guidance）
    4. relation_type（historical-related / Manchu-name / possible-variant 等）僅出現在 rationaleText narrative + metaJSON 內部結構，不入 AP element 層（per R-068 邊界）
    5. 舂牘 vs 牘的關鍵分流（同 relation_type=historical-related 但不同 outcome）— L 系列同義詞邊界治理的關鍵案例
  • 撰寫限制：L 系列為 dossier-only SoT，無 raw md；user prompt / model_slug 描述引自 dossier 引述非 raw 校驗（worked example §開頭明示）
  • TaskRunType 缺口：當前 TaskRunType 無 TaskRun_SynonymJudgement narrower（僅 3 個 narrower：TaskRun_TermTranslation / TaskRun_ScopeNoteTranslation / TaskRun_ScopeNoteEvaluation）；L13 三 TaskRun 暫用 TaskRun_TermTranslation 作 task-level proxy + 透過 WorkItem.taskType=SynonymJudgement 表達精確任務類型。AP_SCHEMA §10.4 已標 TaskTypeScheme 5 處對應缺口待後續案例累積後重設計

Documented (2026-05-22)

  • R-068 — usage.md 新增「L 系列多對多 DecisionNote 表達邊界」章節
  • 動機：C02 為一對多（單一概念找 PT），L 系列（如 L13 paiban）為多對多（多候選詞 × 多 relation_type × 多 candidate status）；後者承載分工需明示

  • 內容：(a) 多對多典型範例 — L13 paiban 舂牘 / 牘 同 relation_type=historical-related 但不同 outcome；(b) 承載分工：outcome 表「決策行動」/ rationaleText 直引 dossier + 專家原句 / metaJSON.candidate_role 承載「領域終態」（沿用 R-048-note）/ dcterms:source 連 SourceEvidence；(c) relation_type 不入 AP — 屬 dossier 分析框架；待 L08 + L13 + 2-3 案累積後評估升 L2 SKOS scheme

  • R-067 — usage.md 新增「Expert reconfirmation capture pattern」章節

[v0.1.2.1 R-085 supersede; see Unreleased] — R-081 升 Evaluation/ExpertReview L2 narrower 後，R-067 採 SourceEvidence-only 模式的核心避免動機（「避免新增 ActivityTypeScheme value 違反 §4.4 最簡」）已失效；R-085 改為獨立 ex:TaskRun + prov:generated SourceEvidence。本段保留作 v0.1.2 ship 歷史紀錄。

  • 動機：L13 paiban 2026-05-19 領域專家對舂牘 / 牘判定的回詢確認事件需 capture pattern
  • 設計關鍵：當前 ActivityTypeScheme 無 TaskRun_ExpertReview value（TaskRunType 僅 3 個 narrower）；新增違反 SOP §4.4 最簡原則
  • 採 SourceEvidence Artifact 表達，不創建 ExpertReview TaskRun：專家複審本質是輸入 DecisionNote 的證據、非獨立決策活動；既有 SourceEvidence artifactType + dcterms:source 連 DecisionNote 即合適承載
  • 專家身份用 rdfs:comment 自由文字承載「提供者：領域專家（匿名化）」（避免創建 prov:Agent + qualifiedAssociation 連帶 TaskRun 結構）；時點用 prov:wasGeneratedAtTime；內容用 rdfs:comment / dcterms:bibliographicCitation

  • 不新增 ActivityTypeScheme value、不新增 RoleScheme value；schema 結構不變

  • R-069 — usage.md 新增「Strategy structure patterns: 平行對照 vs 順序審查」章節

  • 動機：L 系列在地化案例常含多策略平行對照結構（L13 paiban 三策略 Direct / AAT-guided / SPO Triple 各自獨立），與 C02 motifs 順序審查結構（Round 1 → Round 2）不同；兩者用不同 PROV-O 關係表達
  • 模式 A 平行對照：prov:Collection + prov:hadMember 容納互不依賴的 TaskRun
  • 模式 B 順序審查：prov:wasInformedBy（Activity 層 communication 關係，domain/range = prov:Activity）+ prov:used（Activity 使用 Artifact）
  • 可並存：L13 主任務 3 strategies 平行 + 專家複審以 SourceEvidence 表達（不觸發 wasInformedBy）
  • 反例引用：C02 R-045 修正前 Artifact → wasInformedBy → Artifact 違反 PROV-O 規格

Schema (2026-05-22)

  • R-066 — TaskTypeScheme/SynonymJudgement 補 skos:scopeNote（L 系列用法邊界）
  • 動機：L13 paiban worked example 撰寫過程確認 SynonymJudgement 與 TermTranslation 在任務結構上有顯著差異（多對多治理 vs 一對多翻譯），原 definition 單句未承載此邊界。補 SKOS 原生「用法邊界」欄位（scopeNote），不動 definition
  • scopeNote 內容（雙語）：(a) 任務本質 — 多對多候選同義詞篩選；典型場景 L 系列在地化案例；候選詞含正體變體 / 簡稱 / 物料命名 / 歷史關聯 / 方言譯名等多種 relation_type；(b) 與 TermTranslation 區別 — TermTranslation 多為一對多翻譯，SynonymJudgement 為多對多治理；(c) 承載分工 — relation_type 屬 dossier 分析框架不入 AP；candidate 終態走 ex:metaJSON.candidate_role（沿用 R-048-note）
  • 修改位置：
    • 工作層 TaskTypeScheme.ttl SynonymJudgement 補 scopeNote
    • Release 層 task-type.ttl 同步
    • Release docs task-type.md SynonymJudgement 章節擴段（用法邊界 + 與 TermTranslation 區別表 + 承載分工 3 條 bullet）
  • schema 結構不變；ConceptScheme 5 topConcept 不動

Cleaned (2026-05-22)

  • R-073 — metaJSON.acquisitionChannel antipattern 五處清理（連動 R-072 deprecation）
  • 動機：R-068.1 反指引「字段名不該撞既有 element local-name」+ R-072 acquisitionChannel deprecation；C02 + usage.md 共 5 處在 metaJSON 字串內承載 acquisitionChannel 為 antipattern（與 L1 element 重複；deprecation 後該欄位本身已不存在）
  • 清理位置：
    • usage.md L16（Path A share URL 範例）+ L26（Path B API 範例）—— 完全移除 metaJSON 內 acquisitionChannel key，不改寫為 L1 element triple（因 element 已 deprecated；資訊由 prov:atLocation URL pattern 隱含表達）
    • c02-motifs.ttl L109（Round 1 ContextPack）+ L159（Turn 1 ModelConfig）+ L262（Round 2 ContextPack）—— 同處理
    • c02-motifs.md L206 ttl fragment 同步

  • 驗證：grep 全 prov-ai-ap repo metaJSON.*acquisitionChannel zero 出現（僅留 changelog/usage.md 對應段落作為歷史紀錄與反指引舉例）

  • R-074 — metaJSON.model_slugs_used antipattern 兩處清理（採輕量路徑）

  • 動機：R-068.1 反指引「不該承載跨 artifact 關係的聚合字段」；C02 ttl L109/L262 在 ContextPack metaJSON 內承載 model_slugs_used:[...] 為跨 turn model 聚合，違反 4 條件 條件 2（不會跨 artifact 查詢）；正確路徑為 PROV graph TurnRun.qualifiedAssociation
  • 採輕量路徑：PROV-O prov:wasAssociatedWith domain 限制為 Activity（不能掛 Artifact ContextPack）；C02 ttl 既有 3-turn simplification 為 worked example 本質；既有 rdfs:comment 已表達「spans 4 model_slugs: o3 / gpt-4o / gpt-5 / gpt-5-thinking」narrative；PROV graph 查詢路徑透過既有 dcterms:hasPart → TurnRun → prov:qualifiedAssociation → ModelRunner agent 隱含支援
  • 清理位置：
    • c02-motifs.ttl L109（Round 1 ContextPack）+ L262（Round 2 ContextPack）—— 完全移除 metaJSON 內 model_slugs_used key；保留 raw_turns_total / assistant_turns_total；保留 L108/L261 既有 rdfs:comment narrative
  • 不改範圍：不新增 representative TurnRun（gpt-4o / gpt-5-thinking）；不掛 wasAssociatedWith 到 Artifact；C02 既有 3-turn simplification 維持
  • 驗證：grep 全 prov-ai-ap repo model_slugs_used zero 出現

Deprecated (2026-05-22)

  • R-072 — ex:acquisitionChannel status active → deprecated（走 R-008 sourceLocator 同樣 deprecation 路徑）
  • 動機：L13 paiban 撰寫過程中設計重審 — 比對 prov:atLocation（具體位置 IRI）vs ex:acquisitionChannel（取得管道分類），發現多數情境下後者可從前者推斷，且 v0.1（2026-01-23）原本即標 Provisional「待人工判斷」未真正 settle
  • 5 點 deprecation rationale：
    1. Redundancy — prov:atLocation URL pattern 已可推斷管道（chatgpt.com/share → ChatGPT share；api.openai.com → OpenAI API；等）
    2. 無 SKOS scheme — 自由字串 xsd:string 至今無對應 ConceptScheme，值漂移風險高（chatgpt_share_url vs chatgpt_share vs chatgpt）
    3. 設計歷史標 Provisional — v0.1（2026-01-23）即標「確認是否轉用 DCMI / rights vocabulary，或維持本欄。［待人工判斷］」；v0.2 archive 升「正式 OPTIONAL」但未真正 settle
    4. non-URL 情境替代存在 — manifest_upload / internal_compilation 等無 URL 來源，可改走 rdfs:comment（自由文字）或 dcterms:provenance（W3C 標準）
    5. DCMI 替代詞彙存在 — v0.2 archive 自註「未轉用 DCMI rights vocabulary」承認替代可能性
  • 修改位置：
    • 工作層 AP_SCHEMA.md §4 baseline 統計（active 54 → 53；deprecated 1 → 2）+ §5 row（status active → deprecated；cardinality 0..1 → -；definition 加「(deprecated v0.1.2)」前綴；condition 加替代指引）+ §7 變更紀錄 + §10.1 一頁量數表 + §10.3 增刪明細表 add Deprecated row + 01_sources/Provenance_Ontology_AP_v0.1.1_20260519.md L421 標 strikethrough deprecated
    • Release 層 profile.md：開頭句「54 個正在使用」→「53 個正在使用」+ Baseline 統計 L1 37 → 36 / Total 54 → 53 + L1 Data Properties 標題（18 → 17）+ 整 row 移除 ~~ex:acquisitionChannel~~（per R-060 release-cleanup 原則）
  • 連帶 antipattern 清理（R-073）：c02-motifs.ttl L109/L159/L262 + usage.md L16/L26 共 5 處 metaJSON.acquisitionChannel antipattern 完全移除（不改寫為 L1 element triple — 因 element 已 deprecated；資訊由 prov:atLocation 已涵蓋）
  • 不動的部分：工作層 living registry ex:acquisitionChannel row 保留 deprecated 狀態（完整歷史）；本檔（changelog）[0.1.1] Added 段保留不動（歷史變動紀錄）

Fixed (2026-05-22)

  • R-075 — L13 worked example 事實校正（基於 raw md frontmatter）
  • 動機：上一輪 R-064/R-065 撰寫 L13 worked example 時誤推「L 系列為 dossier-only」（Glob 對 Windows 中文路徑 06_test_cases/在地化/ 搜尋失敗 → 未確認實際有 L01-L21 共 21 個目錄）；導致 worked example 多處事實基於 dossier 推測而非 raw md frontmatter 校驗
  • 校正位置（基於 06_test_cases/在地化/L13_paiban/ 同義詞辨識 3 raw md frontmatter）：
    • human_agent_id：provai:agent-jason → provai:agent-yin-rong
    • model_slug：「ChatGPT general」→ 具體 gpt-4o（3 strategies 一致）
    • 3 TaskRun 各補 prov:atLocation share URL + prov:startedAtTime + prov:endedAtTime
    • 新增 3 個 PromptVersion artifact（synonymIdentification-a-direct-v1 / -b-aat-guided-v1 / -c-spo-v1）
    • L13 md 開頭「dossier-only SoT」聲明撤回 + 補 raw md 路徑引用
    • 案例背景表補 3 row（human_agent / model / 對話時間範圍）
    • §3-5 三 strategy md TTL fragment 對齊修正
    • CQ Coverage CQ9 ⚠️→✅

  • 未納入本輪：範圍註撰寫 3 個版本（B/C/D；作為 dossier scope 外資料保留）

  • R-076 — c02-motifs.ttl 移除 @base <urn:prov-ai:> 聲明（fix rdflib 嚴格 parse；不影響語義）

  • 動機：L13 worked example release 後 verification 跑 python -c "from rdflib import Graph; g.parse(...)" 時 C02 失敗，錯誤 ValueError: Base <urn:prov-ai:> has no slash after colon - with relative 'workitem/W-C02'。經 diff 確認非 R-073/R-074 引入：@base <urn:prov-ai:> 自 v0.1.0 即在 ttl L20，是 latent issue（rdflib 1.x 嚴格化後拒絕 URN scheme + relative reference 組合，per RFC 3986 §4.2 — URN scheme 無 path-absolute）
  • L13 不受影響：其 ttl 自始未用 @base，僅用 @prefix ex: <urn:prov-ai:> 同樣承載 ex: 前綴展開；rdflib 對 prefix 展開無 base 限制
  • 修改位置：
    • examples/c02-motifs.ttl L20 — 移除 @base <urn:prov-ai:> .；保留 @prefix ex: <urn:prov-ai:> 行供 ex: prefix 展開；加 comment 記註原因
  • 連帶：新增 scripts/prov-ai-validate-examples.py（rdflib parse 全 examples/*.ttl）進 verification pipeline 防同類 regression
  • 驗證：python scripts/prov-ai-validate-examples.py → c02-motifs.ttl 271 triples + l13-paiban.ttl 259 triples 全 [OK]

  • 不動：所有相對 URI 引用（如 <workitem/W-C02>, <artifact/...>）保持不變；rdflib 改以檔案路徑作 fallback base 解析，IRI 仍 unique

  • R-077 — SOP _SOP_case-ap-review.md 4 處反向修正（撤回「L 系列為 dossier-only」誤推）

  • 動機：R-075 校正過程確認 L 系列同樣有 raw md；SOP 4 處陳述需撤回
  • 修正位置：
    • §1.1 第 6 項註腳：「C 系列位於 06_test_cases/中文化/<case>/；L 系列位於 06_test_cases/在地化/<case>/」
    • §2 三種來源型態表：rebuild 為「raw md 必載 + 評估資產 3 種型態」框架；明示 L13 實際狀況為 dossier + raw md + GPT mapping
    • §4.2 事實校驗清單：合併 C/L 系列為單一表格；補 prompt_version / human_agent_id 兩 row
    • §8 升 skill 條件補「需在 trigger 後自動執行 ls 06_test_cases/<channel>/<case>/」工具陷阱防範
  • 新工具教訓記入 SOP §4.2：Glob 對 Windows 中文路徑搜尋會靜默失敗；當結果為空時必須用 Bash ls 二次確認；不可從 Glob 0 結果直接推斷「不存在」

Refined (2026-05-22)

  • R-068.1 — ex:metaJSON definition 擴大 + condition 三層分流 + usage.md 新章節「metaJSON 承載類型分類」
  • 動機：L13 paiban 撰寫過程中發現 v0.1.1 ex:metaJSON 的 definition「Vendor-specific implementation metadata 的 JSON 序列化字串」寫得過窄；實際使用已超出範圍 — c02-motifs.ttl 三處（L57 baseline state / L109 ContextPack metadata / L148 PromptVersion role）+ R-048-note 推薦 metaJSON.candidate_role 承載 candidate-level status，都不是 vendor-specific。經設計重審後拍板：不收緊回原 vendor-only 定義，而是擴為「結構化補充 metadata 承載槽」但明示三層分流避免無限擴張
  • 新 definition：「Artifact 的結構化補充 metadata 的 JSON 序列化字串；主要用於記錄能讓其他人重現對話或實驗結果的 vendor／實作層資訊」
  • 新 condition（三層分流）：
    • 核心承載對象 = ModelConfig（重現性焦點）：provider / model / model_snapshot_date / reasoning_effort / token_usage / request_id / response_id / API params / asst_idx / raw_turn / tools_used 等
    • 次要承載（其他 Artifact case-by-case）：baseline state snapshot / candidate_role（沿用 R-048-note）/ conversation counts / PromptVersion attachment metadata
    • 反指引：(a) 字段名不該撞既有 element local-name（如 acquisitionChannel）；(b) 不該承載跨 artifact 關係的聚合字段（如 model_slugs_used）；(c) 不該承載大段敘事 / rationale
  • 修改位置：
    • 工作層 AP_SCHEMA.md §5 row（definition + condition + usage_notes + notes 四欄）+ §7 變更紀錄 + §10.3 Definition-refined 增刪明細表 + _apply_ap_guidelines_cols.py L51 MAPPING（source-of-truth alignment）
    • Release 層 profile.md L101 row（definition + condition）+ usage.md 新增章節「metaJSON 承載類型分類」（5 子段：核心承載對象 + 次要承載 4 類 + 反指引 + 新字段判斷樹 + 已知 antipattern 範例）
  • 不動的部分：stable_id / requirement / range / cardinality / encoding_scheme 不變；R-048-note metaJSON.candidate_role 推薦不推翻（屬「次要承載」範圍）；C02 既有 acquisitionChannel / model_slugs_used antipattern 由後續 R-072 / R-073 / R-074 連帶處理

Added (2026-05-21)

  • R-063 — 新增 Competency Questions 對外頁面
  • 動機：對外網站此前僅在 Conformance §「CQs Coverage」放有「CQ 範圍 → 對應元素」的反向對映表，與 Profile §5 元素表第 9 欄 CQ 的反向標記；完整 18 題題目敘述、I1–I3 治理議題背景、設計流程均只在工作層 01_sources/Provenance_Ontology_CQs_V3.3_20260121.md 與主管中期報告草稿可見，對外無對應頁
  • 內容萃取來源：
    • V3.3 source（canonical）：18 題完整題目、I1–I3 背景、L1/L2 分層說明、Task/Turn/Result 粒度定義
    • 主管中期報告 §5.4：「工作流程、核心治理議題與 CQ 清單對應表」（5 階段流程）、「CQ 分群與對應表」（含對應議題、等級、粒度、使用對象）
  • 頁面結構（6 節）：
    1. CQs 三角色（設計輸入 / 範圍界定 / 驗證測試集）
    2. 三大治理議題 I1–I3 + 對應 CQ 群組
    3. CQs 設計流程：5 階段工作流程對齊表
    4. 分析粒度 T/U/R 定義
    5. L1 Core / L2 Modules 兩層設計 + 分群速查表
    6. 完整 18 題 CQs（每題附 anchor #cq1…#cq18，供他頁深層連結）
  • 連動修改：
    • mkdocs.yml nav 在 Conformance 之前插入 Competency Questions: competency-questions.md
    • Conformance §「CQs Coverage」表的每個 CQ 編號轉為錨點連結；§「最小可符合：Core-L1 only」段落 CQ1–CQ10 加連結
  • 純文檔擴充；schema 元素、cardinality、SKOS scheme、TTL 不動；無 R-XXX 結構性影響

Corrected (2026-05-21)

  • R-061 — Encoding Scheme 欄狹義化修正：補 SES（Syntax Encoding Scheme）內容
  • 動機：使用者指出 Encoding Scheme 欄大部分為空，質疑應該可填 xsd: / W3CDTF / IRI 等。檢視 dcmi-ap-conformance-audit.md §3.4 line 170 原註，發現當初設計把此欄狹義限制為僅 VES（Vocabulary Encoding Scheme，指向 SKOS scheme），未涵蓋 DCMI 對 Encoding Scheme 的真實定義中的 SES*（Syntax Encoding Scheme，值的語法／格式標準）
  • 修正範圍：
    • 工作層 AP_SCHEMA.md §5 新增第 19 欄 encoding_scheme，60 row 補欄值（10 SES + 6 VES + 44 -）
    • Release 層 profile.md L1 Data Properties 表補 9 個 SES + L2 Data Properties 表補 1 個 SES
    • 表頭欄位說明擴大：Encoding Scheme 同時涵蓋 SES + VES 兩種
    • sync 腳本 prov-ai-sync-ap-schema.mjs csvHeaders 加 encoding_scheme 為第 18 欄

  • 內容分布（共 16 row 有值 / 44 row 為 -）：

    類別 row Encoding Scheme
    時間型 prov:startedAtTime / prov:endedAtTime / prov:wasGeneratedAtTime / dcterms:created SES: W3CDTF (ISO 8601 profile)
    URI / IRI 型 dcterms:license SES: RFC 3986 (URI)
    prov:atLocation SES: RFC 3987 (IRI)
    語言型 dcterms:language SES: RFC 5646 (BCP 47)
    整數型 ex:turnIndex SES: xsd:nonNegativeInteger
    JSON 序列 ex:metaJSON SES: RFC 8259 (JSON)
    內容雜湊 ex:contentHash SES: hex digest（建議 SHA-256）
    SKOS-typed prov:hadRole / ex:activityType / ex:taskType / ex:artifactType / ex:decisionOutcome / ex:referenceRole VES: 對應 ConceptScheme

  • schema 結構零變動（element stable_id / requirement / range / cardinality / condition 不動）

  • R-062 — 「9 欄對標」宣稱誠實化

  • 動機：使用者質疑「目前 9 欄是否符合 DCMI 要我們著錄的」。檢視後承認 DCMI 並無任何單一規範強制「element/term usage 表必須 9 欄」；本 9 欄為 Prov-AI 自定義組合
  • 三規範混合來源：
    • DCMI Metadata Terms → Definition 欄
    • DCMI Application Profile Guidelines → Obligation / Condition 欄
    • DCTAP → cardinality / datatype / valueConstraint 欄
  • 修訂位置：
    • profile.md 開頭句「全部 54 個元素規格（含 AP Guidelines 9 欄對標）」→「採用 DCMI 風格 9 欄表頭」+ 補一段三規範混合來源說明
    • dcmi-ap-conformance-audit.md §3 + §5 補 R-062 誠實標示段；「100% 對齊 DCMI 9 欄」字眼修為「對 Prov-AI 自定義 9 欄目標的 100% 完成」

  • 不動的部分：對標方向對、精神對（採 DCMI 風格 + 主管設定的 9 欄目標）。修正的是「100%」的範圍標示，不是對標策略本身

  • 影響範圍：工作層 AP_SCHEMA.md §5 / §7（R-061 + R-062）+ sync 腳本 csvHeaders + 派生 csv/js / release profile.md 開頭句 + 表頭說明 + L1/L2 Data Properties 表 10 row / dcmi-ap-conformance-audit.md §3 / §3.4 / §5 三處

Cleaned (2026-05-21)

  • R-060 — profile.md 清除 deprecated 呈現
  • 動機：使用者指出 release 層讀者會被 deprecated 條目混淆「到底有幾個元素／棄用了什麼」，要求對外頁面以「清楚直觀」為原則，只呈現當前可用版
  • 5 處改動：
    • 開頭句「全部 55 個元素」→「54 個正在使用的元素」+ 補指引「Deprecated 元素僅保留於工作層 living registry 與 Changelog，本頁不呈現」
    • Baseline 統計表 4 欄（layer / count含deprecated / active / deprecated）→ 2 欄（layer / 元素數）；Total 55 → 54
    • L1 Data Properties 標題數字 19 → 18
    • 整 row 移除 ~~ex:sourceLocator~~（含 strikethrough 標示）
    • 「v0.1 → v0.1.1 變動明細」表移除 Deprecated 行
  • 不動的部分：工作層 AP_SCHEMA.md ex:sourceLocator row 維持 status = deprecated（living registry 完整歷史）；本檔（changelog.md）[0.1.1] Deprecated 段保留不動（歷史變動紀錄）
  • schema 結構零變動

Refined (2026-05-21)

  • R-047a / R-047b / R-048：三條 SKOS-typed L1 Object Property 的 definition 欄收斂為 DCMI Metadata Terms 撰寫風格（單句、ontological、不混 implementation 細節）
  • R-047a ex:taskType：「WorkItem 任務類型（指向 TaskTypeScheme）」→「WorkItem 的子任務分類（task-level）」
  • R-047b ex:activityType：「活動類型（指向 ActivityTypeScheme）」→「TaskRun／TurnRun 的活動類型（activity-level）」
  • R-048 ex:decisionOutcome：「DecisionNote 的決策結果（指向 DecisionOutcomeScheme 5 closed values）」→「DecisionNote 對某項提議的決策行動（採納／否決／取代／延遲／需修訂）」
  • 動機：對標 DCMI Definition vs Comment 分工（Definition 單句 ontological / Comment 用法指引）；「指向某 Scheme」屬 Encoding Scheme 欄職責，不應在 definition 重複。三方對照證據 = C02 motifs（taskType=TermTranslation；R-046 9 筆 DecisionNote outcome 全 Adopted 但 candidate-status 跨 PT/NPT/rejected/internal-note 5 種）+ L13 paiban（taskType=SynonymJudgement；牘 outcome=Rejected 但 candidate-status=歷史前身保留）
  • candidate-level status 與 outcome 正交的細部 capture guidance 留 R-048-note 進工作層 usage_notes（B2 批次）
  • stable_id / requirement / range / cardinality / condition 不變；schema 結構不動
  • R-053 / R-054 / R-055：profile.md L2 表 9 欄一致性
  • R-053 L2 Object Properties 表：7→9 欄（補 條件 + Encoding Scheme；現有 5 row 對應值全 -）
  • R-054 L2 Data Properties 表：8→9 欄（補 條件；現有 3 row 對應值全 -）
  • R-055 L2 Classes 表：6→7 欄（補 條件；現有 9 row 對應值全 -，並加 footnote「class row 通常不適用 Datatype / Encoding Scheme，是 DCMI 慣例」）
  • 動機：對標 DCMI Application Profile Guidelines §6 element/term usage 表 9 欄要求一致；L2 雖全 OPTIONAL，欄位仍應保留為 - 維持一致性，與 L1 三表結構對齊
  • 影響範圍：profile.md L1 Data Properties 三 row definition + L2 三表表頭結構 + 「v0.1 → v0.1.1 變動明細」表 / 工作層 AP_SCHEMA.md §5 三 row + §7 變更紀錄 5 條 + §10.3 Definition-refined 三條 / sync 腳本派生產物（element_registry.csv + prov_ai_ontology_data.js）；schema 結構不變

Documented (2026-05-21)

  • R-049 / R-048-note / R-051 / R-052 / R-059 — B2 + B4 批次，capture / authoring guidance 收納
  • 對應 DCMI Application Profile Guidelines 之「Profile vs Usage Guidelines」文件層分工：Profile 主表 9 欄只放 DCMI 風格單句定義；本批次把指引型內容集中到對外 usage.md 與工作層 usage_notes / skos:scopeNote
  • R-049 ex:rationaleText.usage_notes（工作層）+ usage.md 章節「RationaleText 直引證據句」：rationaleText 應直引或摘要對應 SourceEvidence 的關鍵語句／證據強度，與 dcterms:source 配對形成可審查 evidence chain
  • R-048-note ex:decisionOutcome.usage_notes（工作層）+ DecisionOutcomeScheme.ttl scheme-level skos:scopeNote + usage.md 章節「DecisionOutcome vs Candidate-level status」：outcome（決策行動）與 candidate-level status（PT/NPT/rejected/historic-related 等領域終態）正交，後者用 ex:metaJSON.candidate_role 承載
  • R-051 ArtifactTypeScheme.ttl 之 DecisionNote.skos:scopeNote + usage.md 章節「DecisionNote multi-row 模式」：1 筆總決策 + N 筆候選層 DecisionNote；範例直引 C02 R-046 之 1+8=9 筆結構
  • R-052 ArtifactTypeScheme.ttl 之 ContextPack 與 SourceEvidence topConcept 各補 skos:scopeNote + usage.md 章節「ContextPack vs SourceEvidence vs CaseCorpus」：三者「集合 / 個別 / 跨案例」分工 + 常見誤用避免表
  • R-059 usage.md 新增「Element-level Capture Guidance」章節作為對外 Usage Guidelines 文件層；4 子段（決策正交 / multi-row / 直引證據 / 三 artifact 邊界），含 C02 / L13 兩案範例
  • schema 結構零變動；ConceptScheme L1×9 / DecisionOutcomeScheme 5 closed values / element row stable_id 與 requirement / range / cardinality / condition 不變
  • 影響範圍：工作層 AP_SCHEMA.md §5 兩 row 的 usage_notes 補（rationaleText / decisionOutcome）+ §7 變更紀錄 6 條（新引入 3 個 change_type：usage-notes-update / scope-note-update / release-doc-section）/ 02_schema/concept_schemes/ArtifactTypeScheme.ttl 三 topConcept scopeNote + DecisionOutcomeScheme.ttl scheme-level scopeNote / release 層 usage.md 新增章節

Fixed (2026-05-21)

  • R-033 / R-035 / R-036：C02 motifs worked example 三項事實校正（基於 dossier S v4.7 與三方對照收斂報告 SoT）
  • R-033：AAT ID 300010098 → 300009700（原 ID 為 Claude 上一輪審查 repo 上下文污染遺留）
  • R-035：SourceEvidence 校正 — 移除 huang-1995-word-meaning（黃居仁〈詞義與義面〉為詮釋框架而非 dossier 證據）；補入 dossier 三證據 = 許雅惠〈東周圖像紋〉/ 邢義田〈猴與馬造型母題〉(保留) / 黃銘崇〈饕餮紋的再思考〉；rationale text 同步重寫 6 點理由
  • R-036：skos:altLabel 校正 — 將原寫 "圖案", "裝飾紋"（dossier 已 rejected）改為 "母題"（dossier §7 最終 NPT）；案例背景表「最終決策」欄改為 PT 升降敘述
  • R-034：Turn-level model + Artifact rdfs:comment 校正 — 改採 R-020.4 assistant-only filtered asst_idx：示範 turn 改為 T-C02-r1-1 (o3, InitialPrompting) / T-C02-r1-2 (o3, Probing — 紋飾/母題概念邊界釐清) / T-C02-r1-10 (gpt-5, Revising — 文樣 NPT 修訂；亦為首次切 gpt-5 的 model 切換點)；Artifact A rdfs:comment 補「跨 4 個 model_slugs：o3 / gpt-4o / gpt-5 / gpt-5-thinking」+ ex:metaJSON 補 model_slugs_used；新增 agent-openai-gpt-5 / agent-openai-gpt-5-thinking；Result.prov:wasDerivedFrom 從 T-C02-r2-67 改為 T-C02-r2-15
  • R-043：ChatGPT share URLs 校正 — 假 placeholder URL（...1234-5678...、...9abc-def0-1234...，共 10 處）替換為 raw md frontmatter 中的真實 URL：Round 1 686ccff9-6018-800e-8fae-2b2b552f6986 + Round 2 688718a6-4184-8005-bb76-f44a023b4c37
  • R-044：§3 user prompt 敘事 fabrication 校正 — 原寫的兩段 user 引文（「motifs 翻成『母題』...會跟『主題』混淆？」/ 「請改用『紋飾』而非『圖案』...」）為捏造，校正為 raw md 真實 user prompt：asst_idx=2 = 「請問分別中譯為『紋飾』、『母題』，是否有各自強調的特徵？」 / asst_idx=10 = 「『文樣』源自日語『文様』...目前不考慮作為非偏好詞，你建議我們怎麼做？」
  • R-038：補 PromptVersion artifact + 提示詞附檔 SourceEvidence — dossier 表 7 明列「術語轉譯提示詞_v1」+「術語翻譯字典擷取欄位與範例_20250623（資料處理後_上傳用）」，原 worked example 未呈現。新增 PromptInstance prov:wasDerivedFrom PromptVersion 鏈接 + TurnRun 1 prov:used 提示詞附檔；md 新增 §3.2「Prompt 版本與附檔」段含 dossier 表 7 blockquote
  • R-045：prov:wasInformedBy PROV-O 合規修正 — 原寫 Artifact → wasInformedBy → Artifact 違反 W3C PROV-O prov:wasInformedBy domain / range = prov:Activity 約束。改為三條 triple：(1) taskrun/T-C02-r2 prov:wasInformedBy taskrun/T-C02-r1（Activity 層 communication）/ (2) taskrun/T-C02-r2 prov:used artifact/case-C02-motifs-term-translation（Activity 使用 Artifact）/ (3) artifact/case-C02-motifs-review-round2 prov:hadMember artifact/case-C02-motifs-term-translation（Collection 層成員）
  • 影響範圍：examples/c02-motifs.md + examples/c02-motifs.ttl；schema / AP 主文不變

Schema (2026-05-21)

  • R-040a：R-017 LLMConversationLog 候選撤回（element-pending → decided-not-added）。觸發 = C02 motifs 案例驗證 R-017 條件 (2)「turn 組合是否本身即構成它（無額外語義則用 prov:Bundle / prov:Collection）」完全成立。prov:Collection + ContextPack SKOS value + prov:hadMember 列舉 turn artifacts 已等價表達 LLMConversationLog 語意，升 L1 只增 schema 噪訊。ArtifactTypeScheme 維持 L1×9
  • R-040b：provai:prov-Collection usage_notes 釐清 ContextPack 兩種 granularity 用法 — (a) Turn-level：ex:TurnRun prov:used → prov:Collection；(b) Case-level：整段對話作為 prov:Collection，承載 share URL 與所有 turn artifact（C02 motifs Artifact A/B 即為此用法）。原 usage_notes 僅寫 (a)，未明示 (b) 合法性。釐清後 C02 兩個 Artifact 維持 ContextPack 標籤，移除「ContextPack 暫代 LLMConversationLog」相關註腳
  • 影響範圍：examples/c02-motifs.md 兩處註腳改寫 + examples/c02-motifs.ttl 三處 comment 改寫 + AP 主文 candidate 段落更新

Restructured (2026-05-21)

  • R-046 + R-037（合併）：C02 motifs worked example 採「dossier 敘事 + RDF/TTL 對映」雙層結構完整重構
  • 動機：上一輪 R-033~R-045 雖修了事實 / 規格但把 dossier 人工分析敘事剝離成冷冰冰 TTL，違反「資料敘事」精神
  • 重構內容：
    • 每段配對 dossier 原文 blockquote：§2 baseline state / §3 SimRAG 設計 / §3.1 AI 雙重意義 / §3.2 motifs-patterns 邊界 / §3.3 中文學術用語框架 / §5 核心張力 / §6 兩個 Review moments / §7 候選詞治理表完整 8 列 / §7 決策摘要 / §8 五個 provenance gap 問題 + §8 核心 gap 命題 / §9 Paper A 三層貢獻 + 英文總結命題
    • 新增 5 個敘事段：§1 AI 介入前的原始對照狀態 / §4 Motifs/Patterns 邊界 / §6 中文學術用語與語意面向框架 / §7 核心概念張力 / §12 為什麼需要溯源 / §13 對 Paper A 的貢獻
    • R-037 合併：DecisionNote 改為 multi-row × 9（總決策 + 8 個候選詞獨立 DecisionNote artifact，rationaleText 直接引用 dossier §7 表 4 對應列，不再摘要改寫）
    • TTL 同步：新增 baseline state Artifact / 4 類 SourceEvidence（AAT scope note + 候選詞清單 + 三證據文獻 + 義面框架）/ 9 筆 DecisionNote / Result.prov:wasDerivedFrom 多重連結至 9 DecisionNote
  • 規模：md 280 行 → 約 620 行；ttl 同步擴充
  • 影響範圍：examples/c02-motifs.md + examples/c02-motifs.ttl；schema / AP 主文不變（DecisionOutcomeScheme 5 closed values 仍用；PT/NPT/rejected 細分用 ex:metaJSON candidate_role 欄位承載）

Added (2026-05-20)

  • DCMI AP Conformance Audit（references/dcmi-ap-conformance-audit.md）— 對 DCMI Singapore Framework + Application Profile Guidelines 的逐項對標複盤，明示 DCAT-AP 為背景參考、不採為主對標
  • R-027 / R-028 / R-029：工作層 AP_SCHEMA.md §5 與對外 profile.md element 表新增 cardinality / definition / condition 三欄，完成 AP Guidelines 9 欄對標（前 6 欄已存在，本次補滿後三欄）
  • R-030：profile.md element 表從 6 欄擴為 10–11 欄（9 欄主表對標 + capture / CQ 延伸欄）
  • R-031：scripts/prov-ai-sync-ap-schema.mjs csvHeaders 同步加 3 欄；同時修一 pre-existing bug — 原迴圈遇到 §5 內 HTML comment 即 break，導致 element_registry.csv 長期僅含 L1（37 row），現修為 pass-through，CSV 完整含 L1+L2+ConceptScheme 共 59 row
  • R-032：補登工作層遺漏的 provai:prov-wasGeneratedAtTime 元素 row（profile.md / canonical_paths.md §2 已列為 active SHOULD，但 AP_SCHEMA.md §5 漏錄）。Baseline 由 L1=37 / Total=54 修正為 L1=38 / Total=55（active 由 53 → 54）；L1 Data Properties 由 18 → 19 行。語意層無變動（沿用 v0.1.1 已採納的 R-020.3 artifact-time 規格），純屬 living registry 補登

Planned (roadmap to v0.2)

  • DCTAP CSV (dctap/profile.csv)
  • PROF Manifest stub (profile.ttl)
  • Namespace policy 拍板（URI pattern、版本 URI、term URI）
  • L13 paiban / L08 bianzhong worked examples
  • Cloudflare Pages 部署

Planned (roadmap to v0.3+)

  • SHACL shapes（Core-L1 + L2 modules）
  • CQ coverage matrix（人讀 + 機器讀 CSV）
  • SSCI figure 對應的 PROV-DM + VOWL 視覺化規格
  • 新對外 viewer（取代工作層 HTML viewer 的對外功能）
  • WebVOWL 上線

[0.1.1] — 2026-05-19

第一版對外乾淨版的 Prov-AI Application Profile。v0.1（2026-01-23 baseline）發展期間累積的 R-001~R-025 設計收斂後，整理為可直接對映實例的正式 AP 主文。

展開查看 v0.1.1 全部變更（點擊展開）

Added

  • AP 主文 v0.1.1（基於 Provenance_Ontology_AP_v0.1.1_20260519）
  • 元素 baseline 54 個：L1 active 36 + L2 active 17 + deprecated 1
  • L1 9 個 Class、10 個 Object Property、18 個 Data Property（含 SKOS-typed Object Property）
  • L2 9 個 Class（OA / DQV）、5 個 Object Property、3 個 Data Property
  • Deprecated：ex:sourceLocator（改用 OA selector + prov:atLocation + dcterms:source 三分工）
  • 5 個 L1 必用 SKOS ConceptScheme：
  • TaskTypeScheme（5 預期值）
  • ActivityTypeScheme（兩層：TaskRunType 5 + TurnRunType 3）
  • ArtifactTypeScheme（L1×9 含 CaseCorpus + L2-optional×5 + 候選×3）
  • RoleScheme（4 角色：Editor / Reviewer / ModelRunner / Evaluator）
  • DecisionOutcomeScheme（5 closed values：Adopted / Rejected / NeedsRevision / Deferred / Superseded）
  • 第一個 worked example：C02 Motifs（中文化 × 術語轉譯）
  • AP Guideline Checklist：P0 對標（Linked Art + Singapore Framework + DCTAP）
  • CaseCorpus 概念（ArtifactTypeScheme:CaseCorpus）— 解 dcterms:source range=ex:Artifact 對字串型 source 的違規

Design decisions(consolidated from v0.1 → v0.1.1)

  • Typed Artifact Pattern 全面採用（避免 class 與欄位爆炸）
  • Roles-as-SKOS Pattern：所有「類型／角色／狀態」走 ConceptScheme
  • Location Standardization 三分工：prov:atLocation / dcterms:source / oa:hasSelector (L2)
  • ContextPack vs CaseCorpus 區別：per-turn input 集合 vs cross-case research grouping
  • ModelConfig per-turn instance：每 turn 對應一個 ModelConfig artifact（不混 case-level audit summary）
  • Time / Agent / Role 三段式對齊 W3C PROV-O entity-vs-activity 語意
  • Turn header regex 凍結為 RDF parser contract：## TurnN (@<iso> | id=<msg_id_short> | model=<slug> | reasoning=<sec>s)
  • Share / API 雙路徑共用同一 schema：share-only redact 用 import_warnings 表達

Requirement adjustments

  • ex:activityType 補 SHOULD（TaskRun MUST、TurnRun SHOULD）
  • ex:decisionOutcome 補 MUST (conditional: DecisionNote)；補 5 closed values
  • ex:Result SHOULD → MUST (conditional: result-bearing taskType)
  • ex:metaJSON range：rdf:JSON → xsd:string（minimal capture；JSON 序列化字串）

Deprecated

  • ex:sourceLocator — 改用 OA selector + prov:atLocation + dcterms:source 三分工；v1.0 移除 alias

Decided NOT to add

  • provai:hadHiddenContext（chatgpt_memory_scope 不採 AP；frontmatter-only）
  • provai:reasoningDurationSec / provai:reasoningEffort（為 ModelConfig optional implementation metadata，序列化於 ex:metaJSON；不作正式 baseline element）

Pending (待 pilot / API trace 後決定)

  • LLMConversationLog（ArtifactTypeScheme 候選）
  • ToolResult 升 L1（觸發條件 = API 直連啟用 + 結構化 tool 內容外露）
  • ReasoningTrace（觸發條件 = OpenAI o-series reasoning_summary 外露 + ≥5 件樣本）

Pending (對外工件，roadmap to v0.2+)

  • DCTAP CSV（dctap/profile.csv）
  • SHACL shapes（shapes/*.shacl.ttl）
  • PROF Manifest（profile.ttl）
  • Turtle / JSON-LD 範例（至少 Chat UI 與 API 各 1 組）

版本演進軌跡

  • v0.1 — 2026-01-23 baseline
  • v0.1.1 — 2026-05-19（R-001~R-025 落地後的設計收斂；對外乾淨版於 2026-05-20 啟動）
  • v0.1.2 — 2026-05-22（L 系列首例 worked example milestone — L13 paiban + metaJSON 承載類型分類 + acquisitionChannel deprecation + 5 處 antipattern 清理）
  • v0.1.2.1 — 2026-05-22（本版；Patch bump — 同案例 C02/L13 後續修訂；TaskTypeScheme + ActivityTypeScheme 兩軸分離重整 + C02/L13 worked example binding 升級 + R-067 supersede + R-086 conformance language 連動一致化；⚠️ 含 RDF consumer 接口變動，但提供 migration path）

詳細的 R-001~R-025 修訂歷史軌跡保留於工作層（不對外）。