Usage Guidelines¶

本節說明怎麼把實際的 AI-assisted KOS editing 工作流對應到 Prov-AI AP 的 RDF 結構。

兩條取值路徑¶

Prov-AI AP 設計上支援兩條取值路徑共用同一份 schema：

從 ChatGPT、Claude、Gemini 等工具的 share URL 抓取對話紀錄。share path 通常會 redact 部分敏感欄位（如 request_id、reasoning_summary），用 import_warnings 表達，不分裂兩套 schema。

ex:taskrun/T001 a ex:TaskRun ;
    prov:atLocation <https://chatgpt.com/share/abc123-def456-ghi789> ;
    ex:metaJSON "{\"import_warnings\":[\"_pending_manifest\",\"_redacted_reasoning_summary\"]}" .

Path B：OpenAI / Anthropic API（後端工具呼叫）¶

從 API 的 request/response log 抓取完整紀錄。API path 通常有完整 request_id、response_id、usage metadata。

ex:taskrun/T002 a ex:TaskRun ;
    prov:atLocation <https://api.openai.com/v1/chat/completions/...> ;
    ex:metaJSON "{\"request_id\":\"req_abc\",\"response_id\":\"resp_xyz\",\"usage\":{\"prompt_tokens\":1234,\"completion_tokens\":567}}" .

Turn Header Contract¶

對於 share path / API path 兩者通用的 turn-level RDF parser contract：

## TurnN (@<iso> | id=<msg_id_short> | model=<slug> | reasoning=<sec>s)

N — turn 序號（從 1 開始）
@<iso> — ISO 8601 datetime（assistant 訊息的 msg.create_time）
id=<msg_id_short> — msg.id 的 UUID 前 8 字節短截
model=<slug> — 模型 slug（如 gpt-5-thinking）
reasoning=<sec>s — reasoning duration in seconds（如 12.4s）；無 reasoning 時填 0s

assistant-only 限制： 只有 msg.author.role=assistant 才產生 turn header。user / system / tool 訊息不獨立成 turn。

範例：

## Turn2 (@2026-05-12T14:23:45Z | id=a1b2c3d4 | model=gpt-5-thinking | reasoning=12.4s)

任何 RDF 轉換 parser MUST 遵守此格式。

IRI / Identifier 規約¶

資源類型	建議 IRI 模板	說明
`ex:WorkItem`	`{base}workitem/{workitem_id}`	`workitem_id` = 系統工作單號
`ex:TaskRun`	`{base}taskrun/{taskrun_id}`	`taskrun_id` 由工作流引擎產生
`ex:TurnRun`	`{base}taskrun/{taskrun_id}/turn/{turn_index}`	API 路徑可改用 `request_id`
`ex:Artifact`	`{base}artifact/{artifact_id}`	建議加 type 前綴
`ex:Result`	`{base}result/{result_id}`	由輸出封存或審查採納事件產生
`prov:Agent` (LLM)	`provai:agent-{provider}-{model_slug}`	扁平 slug；範例 `provai:agent-openai-gpt-5-thinking`
`prov:Agent` (human)	`provai:agent-{human_slug}`	範例 `provai:agent-jason`、`provai:agent-yin-rong`
`prov:Collection` (ContextPack)	`{base}contextpack/{pack_id}`	per-turn
`ex:Artifact` (CaseCorpus)	`provai:corpus-{year}-{aat-key}-{operation-key}`	範例 `provai:corpus-2025-aat-zh-localization`
`prov:Association`	`{base}assoc/{assoc_id}`	可由 (activity_id+agent_id+role) 可重現組合產生

Namespace 拍板： 本版（v0.1.1）使用 urn:prov-ai: 暫時前綴；正式 {base} URI 將於 v0.2 拍板。詳見 Changelog。

Prefix 與命名空間¶

@prefix ex:      <urn:prov-ai:> .            # 本專案 element prefix（v0.2 替換）
@prefix provai:  <urn:prov-ai:vocab/> .      # ConceptScheme / Agent prefix
@prefix prov:    <http://www.w3.org/ns/prov#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix oa:      <http://www.w3.org/ns/oa#> .
@prefix dqv:     <http://www.w3.org/ns/dqv#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .

ModelConfig per-turn instance¶

每個 TurnRun 對應一個 ModelConfig artifact instance（不是 case-level audit summary）。

ex:artifact/modelConfig/T001-2 a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/ModelConfig> ;
    dcterms:hasVersion "gpt-5-thinking" ;
    ex:metaJSON "{\"reasoningDurationSec\":12.4,\"reasoningEffort\":\"high\",\"request_id\":\"req_abc\"}" .

約束：

assistant-only：msg.author.role=assistant 才產 ModelConfig instance
同 turn 單一 model 假設凍結：若未來出現 multi-model turn，需額外修訂解凍
不對應 prov:duration（reasoning 時長 ≠ activity 全長）

Reasoning duration / effort： reasoning models（如 OpenAI o-series）的事後測得 duration（share path）與事前指定 effort（API path）屬 ModelConfig 的 optional implementation metadata，建議序列化於 ex:metaJSON 內（key：reasoningDurationSec xsd:decimal / reasoningEffort xsd:string in {"low", "medium", "high"}）。不作為 AP baseline element。

Manifest Override 機制¶

對於 share path，部分 metadata 從 share URL 抓不到（例如 prompt_version、prompt_attachments），需要從外部 manifest 補。

_url_manifest.csv
    workitem_id, share_url, prompt_version, prompt_attachments_override
    W001,        https://chatgpt.com/share/..., 2026-05-01, ["file1.pdf"]

Fetch 時若 manifest 命中：

emit prompt_version / prompt_attachments_override 進 RDF
空時留 TODO + warning _pending_manifest

案例 mapping 流程¶

把一個實際 ChatGPT / API 對話映射到 Prov-AI AP RDF 的 6 步驟：

1. 定錨 WorkItem¶

從 AAT 主題詞 + 任務類型確定 WorkItem：

ex:workitem/W-C02 a ex:WorkItem ;
    dcterms:identifier "C02" ;
    dcterms:subject [
        a skos:Concept ;
        dcterms:identifier "300010098" ;
        skos:prefLabel "motifs"@en
    ] ;
    dcterms:language "zh-TW" ;
    ex:taskType <provai:scheme/TaskTypeScheme/TermTranslation> .

2. 建立 TaskRun + case-level Association¶

ex:taskrun/T-C02 a ex:TaskRun ;
    dcterms:identifier "T-C02" ;
    prov:atLocation <https://chatgpt.com/share/...> ;
    prov:startedAtTime "2026-05-12T14:00:00Z"^^xsd:dateTime ;
    prov:endedAtTime "2026-05-12T14:35:00Z"^^xsd:dateTime ;
    ex:activityType <provai:scheme/ActivityTypeScheme/TermTranslation> ;
    prov:qualifiedAssociation [
        a prov:Association ;
        prov:agent <provai:agent-jason> ;
        prov:hadRole <provai:scheme/RoleScheme/Editor>
    ] .

3. 逐 turn 拆解 TurnRun¶

每個 assistant 訊息一個 TurnRun，含 turn header parsing + ModelConfig 抽取：

ex:turnrun/T-C02-1 a ex:TurnRun ;
    dcterms:identifier "T-C02-1" ;
    ex:turnIndex 1 ;
    ex:activityType <provai:scheme/ActivityTypeScheme/InitialPrompting> ;
    prov:used ex:artifact/promptInstance/T-C02-1 ,
              ex:artifact/modelConfig/T-C02-1 ;
    prov:generated ex:artifact/responseSnapshot/T-C02-1 ;
    prov:qualifiedAssociation [
        a prov:Association ;
        prov:agent <provai:agent-openai-gpt-5-thinking> ;
        prov:hadRole <provai:scheme/RoleScheme/ModelRunner>
    ] .

ex:taskrun/T-C02 dcterms:hasPart ex:turnrun/T-C02-1 .

4. 抽 PromptInstance + ResponseSnapshot artifacts¶

ex:artifact/promptInstance/T-C02-1 a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/PromptInstance> ;
    prov:wasGeneratedAtTime "2026-05-12T14:01:23Z"^^xsd:dateTime ;
    prov:atLocation <https://chatgpt.com/share/...#turn-1-user> .

ex:artifact/responseSnapshot/T-C02-1 a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/ResponseSnapshot> ;
    prov:wasGeneratedAtTime "2026-05-12T14:02:15Z"^^xsd:dateTime .

5. 來源證據與 Result¶

ex:artifact/sourceEvidence/aat-300010098 a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/SourceEvidence> ;
    prov:atLocation <https://vocab.getty.edu/aat/300010098> ;
    dcterms:license "CC-BY-NC 4.0" .

ex:result/R-C02-final a ex:Result ;
    ex:activityType <provai:scheme/ActivityTypeScheme/TermTranslation> ;
    dcterms:source ex:artifact/sourceEvidence/aat-300010098 ;
    prov:wasDerivedFrom ex:artifact/responseSnapshot/T-C02-3 .

6. DecisionNote¶

ex:artifact/decisionNote/T-C02-final a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/DecisionNote> ;
    ex:decisionOutcome <provai:scheme/DecisionOutcomeScheme/Adopted> ;
    ex:rationaleText "在 turn 3 確認 '紋飾' 為最貼近 AAT 300010098 的中文對應；'圖案' 偏向 patterns、'裝飾紋' 過於狹義。" ;
    prov:wasDerivedFrom ex:result/R-C02-final .

完整 worked example 見 Examples → C02 Motifs。

Element-level Capture Guidance¶

對應 DCMI Application Profile Guidelines 的「Usage Guidelines」文件層：元素規格在 Profile 主表只放 DCMI 風格單句定義；本節集中收納操作層次的指引（哪些情境採何種記錄模式、與其他元素的邊界邏輯、避免常見誤用），不在主表呈現。

DecisionOutcome vs Candidate-level status¶

ex:decisionOutcome 是 DecisionNote 對某項提議的決策行動（採納／否決／取代／延遲／需修訂），不是 candidate 的最終語意角色。後者（如 PT / NPT / rejected / historic-related 等領域終態）應透過 ex:metaJSON.candidate_role 或 candidate-specific 結構化欄位承載。

案例	DecisionNote outcome	candidate-level status（`metaJSON.candidate_role`）
C02 紋飾	Adopted	`PT`
C02 母題	Adopted	`NPT`
C02 圖案	Adopted	`rejected_for_motifs`（與 patterns 邊界混淆風險）
C02 文樣	Adopted	`regional_variant_internal_only`（日語色彩；不採正式 NPT）
L13 舂牘	Adopted	`NPT`（古代雅樂節樂語境）
L13 牘	Rejected	`historic_predecessor_retained`（不納入 NPT，但保留為歷史前身）

→ outcome 與 candidate_role 是兩個正交軸。把 outcome 當作 candidate 終態，會喪失「歷史前身保留」「日語色彩內部備註」這類治理細節。

DecisionNote multi-row 模式¶

當一個 Result 涉及多個候選詞或多個候選關係時，DecisionNote 可拆為：

1 筆總決策 — outcome 表整體治理方向；rationaleText 摘要整體邏輯
N 筆候選層 DecisionNote — 每候選詞各一筆；rationaleText 直引對應證據來源；metaJSON 承載 candidate_role / risk_type 等正交欄位

範例：C02 motifs worked example §11 採 1 + 8 = 9 筆 DecisionNote 結構。

ex:artifact/decisionNote/C02-overall a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/DecisionNote> ;
    ex:decisionOutcome <provai:scheme/DecisionOutcomeScheme/Adopted> ;
    ex:rationaleText "本案最終建議將「紋飾」升為中文 PT…（整體決策摘要）" .

ex:artifact/decisionNote/C02-wenshi a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/DecisionNote> ;
    ex:decisionOutcome <provai:scheme/DecisionOutcomeScheme/Adopted> ;
    ex:rationaleText "紋飾：最符合 AAT 範圍註所限定的 formal decorative-unit sense…（dossier §7 表 4 第 1 列直引）" ;
    ex:metaJSON "{\"candidate_term\":\"紋飾\",\"candidate_role\":\"PT\",\"baseline_state\":\"原 NPT (設計元素)\"}" ;
    dcterms:source ex:artifact/sourceEvidence/aat-300009700-scope-note .

RationaleText 直引證據句¶

ex:rationaleText 應直引或摘要對應 SourceEvidence 的關鍵語句／證據強度，便於審查回指。避免改寫成抽象結論句而失去原文連結。

C02 R-046 9 筆 DecisionNote 之 rationaleText 直引 dossier §7 表 4 對應列（如「最符合 AAT 範圍註所限定的 formal decorative-unit sense，也較能維持 motifs / patterns 的概念邊界」）
L13 expert-reconfirmation rationaleText 直引領域專家補充原句（如「舂牘是古代雅樂用以節樂的樂器，體型很大，其後才演變成小小的拍板代替節樂」）

→ rationaleText + dcterms:source 配對使用：rationaleText 引文 + dcterms:source 指向對應 SourceEvidence artifact，形成可審查回指的 evidence chain。

metaJSON 承載類型分類¶

ex:metaJSON 是 JSON 序列化承載槽，核心用於 ModelConfig artifact 的 vendor／實作層資訊——主答 CQ「使用了什麼模型、什麼模式（reasoning effort）、用了多少 token、API request metadata」這類「可重現對話或實驗結果」的問題。

核心承載對象 = ModelConfig（重現性焦點）

字段類別	典型欄位	範例值
模型識別	`provider` / `model` / `model_snapshot_date`	`"OpenAI"` / `"o3"` / `"2025-04-16"`
模型模式	`reasoning_effort` / `reasoningDurationSec`（vendor-specific）	`"high"` / `12.4`
Token 使用	`token_usage`（含 `prompt_tokens` / `completion_tokens` / `total`）	`{"prompt_tokens":1234,"completion_tokens":567}`
API 識別	`request_id` / `response_id`	`"req_abc"` / `"resp_xyz"`
API 參數	`temperature` / `top_p` / `max_tokens`	`0.7` / `0.95` / `4096`
Conversation 位置	`asst_idx` / `raw_turn` / `model_switch_point`	`10` / `22` / `"first_gpt5"`
啟用工具	`tools_used` / `function_calls` / `web_search_enabled`	`["web_search","code_interpreter"]`

ex:artifact/modelConfig/T001-2 a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/ModelConfig> ;
    dcterms:hasVersion "gpt-5-thinking" ;
    ex:metaJSON "{\"provider\":\"OpenAI\",\"model\":\"gpt-5-thinking\",\"model_snapshot_date\":\"2025-04-16\",\"reasoning_effort\":\"high\",\"reasoningDurationSec\":12.4,\"token_usage\":{\"prompt_tokens\":1234,\"completion_tokens\":567},\"request_id\":\"req_abc\",\"asst_idx\":2,\"raw_turn\":4}" .

次要承載對象（其他 Artifact case-by-case）

承載類型	用於 Artifact	字段範例
Baseline state snapshot	凍結時點的人工狀態（如 AI 介入前 PT/NPT）	`{"baseline_PT":"母題","baseline_NPT":["主題（設計元素）","紋飾（設計元素）"],"baseline_sources":["..."]}`
Candidate-level status	DecisionNote 候選詞領域終態（沿用 R-048-note）	`{"candidate_term":"紋飾","candidate_role":"PT"}`
Conversation counts	ContextPack 對話統計 snapshot	`{"raw_turns_total":78,"assistant_turns_total":18}`
Attachment metadata	PromptVersion 附檔角色與內容類型	`{"role":"prompt_attachment","contains":["AAT 範圍註","候選詞清單"]}`

反指引（不該放 metaJSON）

❌ 字段名撞既有 element local-name：如 acquisitionChannel 已是 provai:ex-acquisitionChannel（v0.1.2 deprecated by R-072）。若需要 element value，直接用 element triple（如 ex:acquisitionChannel "..."），不要塞進 metaJSON 形成 redundancy
❌ 跨 artifact 關係的聚合字段：如 model_slugs_used:["o3","gpt-4o",...] 應走 PROV graph 查詢（ContextPack dcterms:hasPart → TurnRun → prov:qualifiedAssociation → ModelRunner agent），不應在 ContextPack metaJSON 內聚合
❌ 大段敘事 / rationale：應用 ex:rationaleText（DecisionNote 決策理由）或 rdfs:comment（Artifact 敘事）；metaJSON 應為短小結構化字段集

新字段判斷樹

新字段 X 是否該放 metaJSON？
├─ Q1：X 是否已有 L1 / L2 element 可承載？
│   ├─ Yes → 用既有 element triple，不放 metaJSON
│   └─ No → 進 Q2
├─ Q2：X 是否描述跨 artifact 關係（多個 agent / 多個 artifact）？
│   ├─ Yes → 用 PROV graph 屬性（prov:wasAssociatedWith / prov:hadMember / prov:wasDerivedFrom 等）
│   └─ No → 進 Q3
├─ Q3：X 是否為大段敘事 / rationale？
│   ├─ Yes → 用 ex:rationaleText / rdfs:comment
│   └─ No → 進 Q4
└─ Q4：X 是否為 vendor-bound / artifact-bound / 短小結構化字段？
    ├─ ModelConfig 上的 vendor metadata → 核心承載 ✓
    ├─ Artifact baseline / candidate_role / counts / metadata → 次要承載（case-by-case 評估）✓
    └─ 其他 → 通常不該放 metaJSON

已知 antipattern 範例（待 R-072/R-073/R-074 修正）

位置	antipattern	修正方向
c02-motifs.ttl L109/L159/L262 + usage.md L16/L26	`metaJSON.acquisitionChannel` 與既有 `ex:acquisitionChannel` L1 element 重複	R-072 deprecation acquisitionChannel + R-073 完全移除 metaJSON 內 5 處
c02-motifs.ttl L109/L262	`metaJSON.model_slugs_used` 聚合跨 turn model 資訊	R-074 移除字段；PROV graph 透過 TurnRun.qualifiedAssociation 隱含支援

L 系列多對多 DecisionNote 表達邊界¶

C02 motifs（中文化術語翻譯）為一對多結構（單一 AAT 概念 → 多個候選詞 → 篩出唯一 PT + NPT 群）；L 系列（在地化 × 同義詞判定，如 L13 paiban）為多對多結構（多個候選詞 × 多種 relation_type × 多種 candidate status）。多對多場景的 DecisionNote 表達需特別注意 outcome × status 正交性。

多對多典型範例（L13 paiban dossier Table 5 中的舂牘 / 牘判定）：

舂牘與牘 同一 relation_type=historical-related（皆為歷史相關概念），但專家複審判定不同 outcome：

ex:artifact/decisionNote/L13-paiban-chuandu a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/DecisionNote> ;
    ex:decisionOutcome <provai:scheme/DecisionOutcomeScheme/Adopted> ;
    ex:rationaleText "舂牘可納入拍板中文同義詞。專家補述：舂牘是古代雅樂用以節樂的樂器，體型很大，其後才演變成小小的拍板代替節樂。"@zh-Hant ;
    ex:metaJSON "{\"candidate_term\":\"舂牘\",\"candidate_role\":\"NPT\"}" ;
    dcterms:source ex:artifact/sourceEvidence/L13-paiban-expert-reconfirmation-20260519 .

ex:artifact/decisionNote/L13-paiban-du a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/DecisionNote> ;
    ex:decisionOutcome <provai:scheme/DecisionOutcomeScheme/Rejected> ;
    ex:rationaleText "牘仍不建議納入為正式 NPT。專家補述：舂牘與牘都涉及節樂功能與歷史演變脈絡，但歷史相關性不等同於形式上的同義關係。"@zh-Hant ;
    ex:metaJSON "{\"candidate_term\":\"牘\",\"candidate_role\":\"historic_predecessor_retained\"}" ;
    dcterms:source ex:artifact/sourceEvidence/L13-paiban-expert-reconfirmation-20260519 .

承載分工（沿用 R-048-note）： - ex:decisionOutcome 表「決策行動」（Adopted vs Rejected） - ex:rationaleText 直引 dossier 對應段落 + 專家補述原句（沿用 R-049） - ex:metaJSON.candidate_role 承載「領域終態」（NPT / historic_predecessor_retained） - dcterms:source 連結至共同的 SourceEvidence（如 2026-05-19 專家複審）

relation_type 不入 AP：候選詞關係類別（亦稱 / 簡稱 / 改製 / 此外還有 / 滿族稱 / historical-related / orthographic-variant / Manchu-name 等）屬 dossier 分析框架；AP 透過 dcterms:source 連回 dossier 即完成溯源職責，不複製 dossier 分析框架進 AP。如需 SPARQL 跨案例查詢 relation_type，待 L08 + L13 + 2-3 個 L 系列案例累積後評估升 L2 SKOS scheme（R-068.1 反指引「領域 typed status 樣本充足、語義穩定時應升 SKOS scheme」）。

Expert reconfirmation capture pattern（R-085 起；R-067 supersede）¶

某些案例會出現「領域專家對 AI 結果的後續複審」事件（如 L13 paiban 2026-05-19 領域專家對舂牘 / 牘判定的回詢確認）。捕捉模式：建獨立 ExpertReview TaskRun（ex:taskType = Evaluation/ExpertReview），原 SourceEvidence Artifact 保留作為該 TaskRun 之 prov:generated 產出 entity。

設計理由（5 條論證；對應 SOP §4.4）：

#	論證
1	PROV-O Activity 對齊 — 專家在 2026-05-19 對 AI 結果做出判斷符合 W3C PROV-O §3 Activity 定義（時間軸 + 對 entity 作用）；不應 downgrade 為 `prov:Entity`
2	與 AI TaskRun 結構對稱 — 避免「AI 活動 = TaskRun / 人類活動 = Artifact」的人為非對稱；PROV-O 中性原則下兩者皆 `prov:Activity`
3	R-067 原避免動機已不成立 — R-067 主理由「避免新增 ActivityTypeScheme SKOS value」在 R-081 升 L1 `Evaluation/ExpertReview` 後 sunk cost；繼續用模式 A 反而產生「SKOS value 已建沒人用」cruft
4	CQ 機器可查 — 「哪些案例經專家複審 / 誰複審 / 時序」直接 SPARQL；模式 A 需 grep `rdfs:comment` 自由文字
5	證據 vs 活動本質不同 — AAT 詞條、辭海等 = 既存客觀資料（Entity）；專家當下做出的判斷 = 發生在時間中的活動（Activity）；R-067 把後者壓縮為前者喪失時間維度

# Domain expert Agent
<provai:agent-domain-expert-paiban> a prov:Agent ;
    skos:prefLabel "領域專家 — 中國音樂史學者"@zh-Hant ;
    rdfs:comment "2026-05-19 回詢確認的領域專家（匿名化處理）。" .

# ExpertReview TaskRun（R-085 新增；R-067 supersede）
<taskrun/T-L13-expert-review-20260519> a ex:TaskRun ;
    dcterms:isPartOf <workitem/W-L13> ;
    ex:taskType <provai:scheme/TaskTypeScheme/Evaluation/ExpertReview> ;
    prov:startedAtTime "2026-05-19T00:00:00+08:00"^^xsd:dateTime ;
    prov:endedAtTime   "2026-05-19T23:59:59+08:00"^^xsd:dateTime ;
    prov:wasInformedBy <taskrun/T-L13-strategy-A> ,
                       <taskrun/T-L13-strategy-B> ,
                       <taskrun/T-L13-strategy-C> ;
    prov:used <artifact/sourceEvidence/L13-paiban/textual-sources> ,
              <artifact/sourceEvidence/L13-paiban/linguistic-markers> ;
    prov:qualifiedAssociation [
        prov:agent <provai:agent-domain-expert-paiban> ;
        prov:hadRole <provai:scheme/RoleScheme/Reviewer>
    ] , [
        prov:agent <provai:agent-yin-rong> ;
        prov:hadRole <provai:scheme/RoleScheme/Editor>
    ] ;
    prov:generated <artifact/sourceEvidence/L13-paiban/expert-reconfirmation-20260519> .

# SourceEvidence（保留；新增 prov:wasGeneratedBy 指向 ExpertReview TaskRun）
<artifact/sourceEvidence/L13-paiban/expert-reconfirmation-20260519> a ex:Artifact ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/SourceEvidence> ;
    rdfs:label "L13 paiban 領域專家 2026-05-19 回詢確認紀錄"@zh-Hant ;
    prov:wasGeneratedAtTime "2026-05-19"^^xsd:date ;
    prov:wasGeneratedBy <taskrun/T-L13-expert-review-20260519> ;
    dcterms:bibliographicCitation "L13 paiban dossier Appendix B" .

# DecisionNote dcterms:source 連結點不變（仍指 SourceEvidence；R-085 不影響 DecisionNote 端）
<artifact/decisionNote/L13-paiban-chuandu>
    dcterms:source <artifact/sourceEvidence/L13-paiban/expert-reconfirmation-20260519> .
<artifact/decisionNote/L13-paiban-du>
    dcterms:source <artifact/sourceEvidence/L13-paiban/expert-reconfirmation-20260519> .

承載分工： - 專家身份透過 prov:Agent + prov:qualifiedAssociation + Reviewer role（不再藏在 rdfs:comment 自由文字） - 專家活動時間用 prov:startedAtTime / endedAtTime（activity-time，非 entity-time） - 專家複審產出記錄保留為 SourceEvidence Artifact（無語意降級）+ 新增 prov:wasGeneratedBy 連回 TaskRun - 專家複審輸入：3 strategies (prov:wasInformedBy) + 文獻證據 (prov:used) - DecisionNote 端不必改：dcterms:source 仍指 SourceEvidence

歷史脈絡（R-067 → R-085 supersede）： - v0.1.2（2026-05-22 R-067）原採 SourceEvidence-only 模式，主理由是 SOP §4.4 最簡 trade-off（避免新增 ActivityTypeScheme SKOS value） - v0.1.3（2026-05-22 R-081）升 L1 Evaluation + L2 ExpertReview 後，§4.4 trade-off 不成立；R-085 改為獨立 TaskRun 模式以對齊 PROV-O 與 CQ 機器可查需求 - R-067 在 changelog 標 superseded；歷史敘事保留作為設計演進可追溯性

Strategy structure patterns: 平行對照 vs 順序審查¶

L 系列在地化案例常含多策略平行對照結構（如 L13 paiban 三策略 Version A: Direct / Version B: AAT-guided / Version C: SPO Triple 並行執行），與 C02 motifs 的順序審查結構（Round 1 → Round 2 review，後輪基於前輪結果）不同。兩者用不同 PROV-O 關係表達。

模式 A：平行對照（prov:Collection + prov:hadMember）—— L 系列典型

3 個 TaskRun 互不依賴、各自獨立執行；用 Collection 容納顯示平行關係：

# Collection 容器：3 strategies parallel grouping
ex:artifact/case-L13-paiban-strategies a ex:Artifact , prov:Collection ;
    ex:artifactType <provai:scheme/ArtifactTypeScheme/ContextPack> ;
    rdfs:comment "L13 paiban 同義詞判定的 3 策略平行對照（Direct / AAT-guided / SPO Triple）；三 TaskRun 互不依賴。" ;
    prov:hadMember ex:taskrun/T-L13-strategy-A ,
                   ex:taskrun/T-L13-strategy-B ,
                   ex:taskrun/T-L13-strategy-C .

# 各策略 TaskRun 獨立（無 wasInformedBy 連結；R-083 後改用 ex:taskType 而非 ex:activityType）
ex:taskrun/T-L13-strategy-A a ex:TaskRun ;
    ex:taskType <provai:scheme/TaskTypeScheme/LocalCulturalConstruction/SynonymJudgement> ;
    # ... 各自 Editor association + TurnRuns

ex:taskrun/T-L13-strategy-B a ex:TaskRun ;
    ex:taskType <provai:scheme/TaskTypeScheme/LocalCulturalConstruction/SynonymJudgement> ;
    # ...

ex:taskrun/T-L13-strategy-C a ex:TaskRun ;
    ex:taskType <provai:scheme/TaskTypeScheme/LocalCulturalConstruction/SynonymJudgement> ;
    # ...

模式 B：順序審查（prov:wasInformedBy Activity → Activity）—— C02 典型

第二輪 TaskRun 由第一輪 TaskRun 告知 / 啟發，後輪 build on 前輪：

ex:taskrun/T-C02-r2 a ex:TaskRun ;
    ex:taskType <provai:scheme/TaskTypeScheme/ChineseLocalization/TermTranslation> ;
    # PROV-O 合規：wasInformedBy 為 Activity 層 communication 關係
    # (domain/range = prov:Activity)
    prov:wasInformedBy ex:taskrun/T-C02-r1 ;
    # 第二輪實際使用了第一輪的 ContextPack 作為輸入材料（Activity 使用 Artifact）
    prov:used ex:artifact/case-C02-motifs-term-translation .

兩種模式可同時並存（L13 paiban：3 strategies 平行 + ExpertReview 順序審查）：

L13 worked example 即為 A + B 混合範例： - 主任務為 3 strategies 平行（模式 A：prov:Collection + prov:hadMember） - 2026-05-19 領域專家複審為獨立 ExpertReview TaskRun（R-085 supersede R-067），用模式 B prov:wasInformedBy 連回 3 strategies TaskRun（表達「基於 3 策略結果做複審」） - 詳見 Expert reconfirmation capture pattern 段

選擇判斷：

情境	模式
多個策略 / 變體平行執行，互不依賴	A — `prov:Collection` + `prov:hadMember`
後一輪建立在前一輪結果上、序列關係	B — `prov:wasInformedBy`（Activity 層）+ `prov:used`（Artifact 層）
複合場景（平行 + 整合）	A + B 並用：策略 TaskRun 平行 + 整合 TaskRun 用 wasInformedBy

→ 違反 PROV-O prov:wasInformedBy domain/range 規格（必須 Activity → Activity）的常見錯誤為「掛在 Artifact 上」（如 C02 R-045 修正前的 Artifact → wasInformedBy → Artifact），詳見 Changelog R-045。

ContextPack vs SourceEvidence vs CaseCorpus¶

三者是同一 ArtifactTypeScheme 內三個 topConcept，承擔不同層級的「集合 / 個別 / 跨案例」分工：

概念	Granularity	結構	典型用法
ContextPack	within-case	`prov:Collection` 容器	(a) Turn-level：`ex:TurnRun prov:used → prov:Collection`；(b) Case-level：整段對話作為 Collection 承載 share URL 與 turn artifacts（C02 Artifact A/B）
SourceEvidence	within-case	個別 artifact（被 `dcterms:source` 指向）	上傳檔、外部資源、文獻、AAT scope note 等個別來源
CaseCorpus	cross-case	個別 artifact（被 `dcterms:source` 指向）	研究級 case 集合（如「2025 AAT 中文化案例」30 件 C 系列）

常見誤用 / 避免方式：

❌ 把整段對話標 SourceEvidence → ✅ 用 ContextPack（Case-level granularity）
❌ 把字串型 source（如「2025 AAT 中文化案例」）填入 dcterms:source → ✅ 建 CaseCorpus artifact，由 dcterms:source 指向
❌ 把 turn 內單一上傳檔包成 ContextPack → ✅ 用 SourceEvidence，加 prov:atLocation

詳細結構與選擇樹見 Concept Schemes → Artifact Type Scheme。

接下來¶

看完整 worked example：Examples → C02 Motifs
看符合性類別：Conformance
對標 P0 checklist：AP Guideline Checklist