---
title: "從每日資訊流到可查詢歷史：領域記憶的累積機制"
series: "網路資訊海動態秩序化"
series_id: "EML-IIODO"
document_id: "EML-IIODO-TH-04"
document_type: "公開理論文"
author: "Neo.K"
organization: "EveMissLab"
version: "0.1.0"
status: "公開初稿"
date: "2026-07-31"
language: "zh-TW"
license_note: "公開引用時請保留作者、文件編號、版本與來源。"
---

# 從每日資訊流到可查詢歷史

## 領域記憶的累積機制

## 摘要

當新聞被重新定義為領域知識狀態差分，並透過微觀、中觀與宏觀尺度、母站與領域觀測站持續輸出後，平台將自然累積大量每日資訊。然而，資訊的持續堆積不等於歷史。若系統只保存最新摘要、目前分類與最後版本，它仍然只是會更新的內容網站；若系統只把舊頁面按日期歸檔，它也只能提供檔案瀏覽，無法回答「當時知道什麼」、「後來改了什麼」、「某個判斷為何形成」以及「現在如何重新理解過去」等歷史問題。

本文提出領域記憶的累積模型，主張可查詢歷史必須建立在四個相互區分的層次上：原始來源與快照、事件與主張、版本與修訂、當時判斷與後設重算。系統不應用新內容覆寫舊內容，而應以追加式事件紀錄保存變化，再由投影函數重建不同時間點的可見狀態。本文進一步區分事件發生時間、來源發布時間、系統觀測時間與系統修訂時間，並提出「當時所知歷史」與「今日回看歷史」的雙重查詢模式。

本文借鑑 W3C PROV-O 對實體、活動與代理者的溯源描述、RFC 7089 Memento 對 Web 資源過去狀態的時間存取、Event Sourcing 的追加式事件儲存、雙時間資料模型對有效時間與交易時間的區分，以及 Crossref、DataCite 對更正、撤回與版本關係的處理。這些既有方法顯示：可追溯歷史的關鍵不在保存一個「正確的最後答案」，而在保存狀態如何產生、如何被修正，以及不同版本之間的關係。

本文的核心主張是：領域歷史不是文章集合，而是由來源快照、事件節點、時間關係、版本鏈、溯源鏈、判斷紀錄與可重算投影共同構成的動態記憶。每日三則只是注意力輸出；真正的長期資產，是一套能夠回放領域狀態、追蹤知識演化、辨識早期訊號並保留錯誤修正過程的可查詢歷史基礎設施。

**關鍵詞：** 領域記憶、可查詢歷史、事件溯源、版本鏈、時間資料、Event Sourcing、Memento、PROV-O、歷史回放、知識演化

---

## 1. 問題起點：累積不等於記憶

假設某個領域觀測站每天收集大量來源，並從中選出三則重要資訊。經過一年後，平台可能擁有：

$$
365\times3=1095
$$

則公開精選內容，以及更多未進入前端的候選事件。

直覺上，這似乎已形成一份領域歷史。但若系統只能依日期翻頁，它最多是一座新聞檔案館。使用者仍然無法可靠回答：

- 某個概念第一次出現於何時；
- 某項技術是在何時開始形成趨勢；
- 某則資訊後來是否被更正、撤回或取代；
- 當時為何把某事件列為每日三則；
- 同一事件後來如何被重新分類；
- 哪些早期訊號在當時被忽略，事後才顯得重要；
- 某個宏觀轉折由哪些微觀事件逐步累積而成。

因此必須區分：

$$
\text{資訊累積}
\neq
\text{歷史記憶}
$$

資訊累積只是保存內容；歷史記憶則要求系統保存內容之間的時間、版本、來源、因果候選、修訂與判斷關係。

可以先給出一個最小定義：

$$
\boxed{
\text{可查詢歷史}
=
\text{事件紀錄}
+
\text{時間語意}
+
\text{版本關係}
+
\text{溯源關係}
+
\text{可重建狀態}
}
$$

只有當平台能從紀錄中重建過去某個時間點的領域狀態，它才開始具有真正的領域記憶。

---

## 2. 三種常見的假歷史

在實作上，系統很容易誤把以下三種結構當成歷史。

### 2.1 日期排序的文章列表

文章依發布日期由新到舊排列，提供月份與年份篩選。這能回答「那天發布了什麼」，卻不能回答事件是否屬於同一條演化線，也不能辨識後來的更正與取代。

### 2.2 只保留最後版本

每次抓取新內容後，直接覆寫資料庫中的舊欄位：

$$
S_{t+1}\leftarrow\operatorname{Update}(S_t)
$$

如此雖能保持資料「最新」，卻失去狀態如何改變的證據。當分類、摘要或來源內容出錯時，系統也難以解釋錯誤何時發生。

### 2.3 靜態知識圖譜

系統把人物、機構、論文與概念連成圖，但只保存目前關係：

$$
G=(V,E)
$$

若邊沒有有效時間、建立時間與撤銷時間，圖譜只能表示「現在相信什麼」，無法表示「過去曾相信什麼」以及「這個關係何時失效」。

因此，真正的歷史系統必須把時間視為一級結構，而不是附在內容旁邊的一個日期欄位。

---

## 3. 歷史的最小單位：事件而不是文章

文章、論文、影片、程式碼提交與法規頁面都是載體。歷史真正需要追蹤的是載體中所描述或造成的事件。

令一個來源文件為：

$$
d_j
$$

其中可能同時包含多個事件：

$$
\operatorname{Extract}(d_j)
=
\{e_1,e_2,\ldots,e_n\}
$$

相反地，同一事件也可能被多個來源描述：

$$
e_i
\leftarrow
\{d_1,d_2,\ldots,d_m\}
$$

例如「某模型發布新版本」可能同時出現在官方公告、GitHub Release、研究報告、媒體報導與使用者測試中。若平台把每篇文章當成獨立歷史單位，就會將同一事件重複計算多次。

因此，領域記憶需要至少區分：

- **來源物件**：網頁、文件、影片、資料集或提交；
- **來源快照**：某一時間點取得的來源內容；
- **主張**：來源對世界所陳述的句子或命題；
- **事件**：可識別的狀態變化；
- **判斷**：觀測站對事件重要性、可信度與分類的評估；
- **投影**：系統在特定查詢條件下呈現的領域狀態。

可以表示為：

$$
\text{Source}
\rightarrow
\text{Snapshot}
\rightarrow
\text{Claim}
\rightarrow
\text{Event}
\rightarrow
\text{Assessment}
\rightarrow
\text{Projection}
$$

這條鏈也是從資訊流走向歷史記憶的基本轉換。

---

## 4. 一個事件至少有四個時間

歷史系統最常見的錯誤之一，是只保存單一 `published_at`。

實際上，一個事件至少可能涉及四個不同時間。

### 4.1 事件發生時間

$$
\tau_o(e)
$$

事件在世界中實際發生或有效的時間。例如法規生效日、模型發布日或實驗完成日。

### 4.2 來源發布時間

$$
\tau_p(d)
$$

來源公開陳述該事件的時間。事件可能先發生，數日後才被報導。

### 4.3 系統觀測時間

$$
\tau_i(e)
$$

觀測站首次取得、解析並寫入該事件的時間。系統可能在來源發布後一段時間才發現它。

### 4.4 系統修訂時間

$$
\tau_r(e)
$$

系統對事件分類、摘要、可信度或關係進行修改的時間。

因此，一個事件的時間向量可以表示為：

$$
\boldsymbol{\tau}(e)
=
(\tau_o,\tau_p,\tau_i,\tau_r)
$$

這四個時間不能相互替代。若只使用發布時間，系統無法分辨事件發生與資訊被知道之間的延遲；若只使用觀測時間，系統則會把遲到的舊事件誤認為新事件。

---

## 5. 有效時間與紀錄時間

時間資料庫通常區分兩種核心時間：

- **有效時間（valid time）**：某項事實在所描述世界中何時成立；
- **交易時間或系統時間（transaction time）**：資料庫何時知道、寫入或修改該事實。

對領域資訊平台而言，可以定義：

$$
T_v(c)=[t_s,t_e)
$$

表示主張 $c$ 在世界中被認為有效的時間區間；另以：

$$
T_x(c)=[t_{in},t_{out})
$$

表示該主張在系統資料庫中被接受為有效紀錄的時間區間。

兩者合併形成雙時間模型：

$$
B(c)=T_v(c)\times T_x(c)
$$

這能回答兩種完全不同的問題：

1. **以今天的知識來看，某項事實在 2025 年何時有效？**
2. **在 2025 年某一天，系統當時認為什麼是有效的？**

若不區分這兩種時間，事後修正會污染當時紀錄，使平台無法重建真正的歷史認知狀態。

---

## 6. 當時所知與今日回看

領域歷史至少應提供兩種模式。

### 6.1 當時所知歷史

令系統在時間 $t$ 已經觀測到的事件集合為：

$$
E^{\mathrm{known}}(t)
=
\{e_i\mid \tau_i(e_i)\le t\}
$$

由當時可用的模型、規則與資料建立狀態：

$$
K^{\mathrm{then}}_d(t)
=
\Pi_{d}^{(t)}
\left(
E^{\mathrm{known}}(t)
\right)
$$

這回答：

> 在那個時間點，平台當時看見了什麼、相信了什麼、選出了什麼？

### 6.2 今日回看歷史

今日已掌握更多資料、更正與後續事件，因此可重新投影同一段過去：

$$
K^{\mathrm{now}}_d(t)
=
\Pi_{d}^{(T)}
\left(
E^{\mathrm{all}}_{\le t},
E^{\mathrm{later}}_{>t}
\right)
$$

這回答：

> 以現在的完整資料重新觀看，那段歷史應如何理解？

兩者都重要，且不可互相覆寫。

$$
\boxed{
K^{\mathrm{then}}_d(t)
\neq
K^{\mathrm{now}}_d(t)
}
$$

前者保存當時決策環境，後者提供後見理解。成熟的歷史平台應允許使用者在兩者之間切換。

---

## 7. 追加式事件帳本

若系統每次更新都直接覆寫舊紀錄，歷史就會消失。更適合的基礎是追加式事件帳本。

令事件帳本為：

$$
\mathcal{L}
=
\langle a_1,a_2,\ldots,a_n\rangle
$$

每一筆 $a_i$ 表示一次不可被靜默抹除的狀態變化，例如：

- `SourceCaptured`；
- `ClaimExtracted`；
- `EventCreated`；
- `EventMerged`；
- `ClassificationAssigned`；
- `DailyTop3Selected`；
- `CorrectionLinked`；
- `RetractionRegistered`；
- `AssessmentRevised`；
- `ProjectionPublished`。

目前狀態不是唯一真實資料，而是帳本的投影：

$$
S_t
=
\operatorname{Fold}
\left(
S_0,
\{a_i\mid \tau(a_i)\le t\}
\right)
$$

這與 Event Sourcing 的核心精神一致：完整保存導致狀態改變的事件，再透過回放重建狀態。其優點包括：

- 可重建任何過去狀態；
- 可追查錯誤由哪次操作產生；
- 可使用新規則重新計算舊資料；
- 可保留更正與撤回過程；
- 可比較不同模型版本的判斷差異。

但追加式不等於永不刪除任何內容。隱私、授權、安全與法規仍可能要求移除原始內容；這時至少應留下經合法處理的刪除事件、原因與不可逆遮蔽狀態，而不是假裝內容從未存在。

---

## 8. 快照與事件帳本的互補

只使用事件回放，在事件量巨大時可能成本過高。因此系統可以週期性建立快照：

$$
\Sigma_k
=
\operatorname{Snapshot}(S_{t_k})
$$

重建時間 $t$ 的狀態時，先載入最近快照，再回放後續事件：

$$
S_t
=
\operatorname{Replay}
\left(
\Sigma_k,
\{a_i\mid t_k<\tau(a_i)\le t\}
\right)
$$

兩者分工如下：

- 事件帳本提供完整變化證據；
- 快照提供高效查詢與恢復；
- 原始來源快照提供外部證據；
- 領域狀態快照提供內部投影。

因此應避免把「網頁快照」與「系統狀態快照」混為一談。前者保存外部來源當時長什麼樣，後者保存平台當時如何理解整個領域。

---

## 9. Web 資源的時間存取

RFC 7089 Memento 提出一套以 HTTP 存取資源過去狀態的框架，使客戶端可透過時間協商取得某個 Web 資源在指定時間附近的版本，並以 TimeMap 枚舉歷史狀態。

對領域觀測站而言，這提供一個重要啟示：

> 歷史版本不應只是後台備份，而應能以穩定、可發現、可引用的方式被存取。

可以將一個原始資源表示為：

$$
R_0
$$

其在不同時間的保存版本為：

$$
\{R_{t_1},R_{t_2},\ldots,R_{t_n}\}
$$

平台不一定要完整實作 Memento 協定，但至少應提供：

- 原始網址；
- 擷取時間；
- 內容雜湊；
- 歷史版本列表；
- 前一版與下一版；
- 差異檢視；
- 永久引用識別碼。

如此一來，使用者才能驗證某則摘要所依據的來源，在當時究竟寫了什麼。

---

## 10. 溯源鏈：誰在何時以什麼方法生成了什麼

W3C PROV-O 以 Entity、Activity 與 Agent 描述資料如何產生及受到誰的影響。這很適合用來表示領域記憶的生成過程。

例如：

$$
\text{SourceSnapshot}
\xrightarrow{\text{used by}}
\text{ExtractionActivity}
\xrightarrow{\text{generated}}
\text{Claim}
$$

以及：

$$
\text{Claim}
\xrightarrow{\text{used by}}
\text{RankingActivity}
\xrightarrow{\text{generated}}
\text{DailySelection}
$$

每個活動還可以關聯：

- 執行的 AI 模型；
- 提示詞或工作流版本；
- 使用的 Domain Pack；
- 人工審核者；
- 執行時間；
- 信心分數；
- 輸入與輸出雜湊。

令一個判斷紀錄為：

$$
J
=
(e,m,p,w,h,t)
$$

其中：

- $e$ ：被判斷的事件；
- $m$ ：模型或 Agent 版本；
- $p$ ：提示詞、規則或政策版本；
- $w$ ：使用的重要性權重；
- $h$ ：人工修訂或批准資訊；
- $t$ ：判斷時間。

若沒有這層溯源，未來即使知道某事件曾被列為重要新聞，也無法解釋它是由哪套方法選出的。

---

## 11. 不可變證據與可變解釋

領域歷史不應把所有資料都視為同樣可修改。

可以區分兩個層次：

### 11.1 證據層

包括來源快照、內容雜湊、擷取時間、檔案、原始引用與執行日誌。這些資料原則上應追加保存，不能被後來的解釋靜默覆寫。

### 11.2 解釋層

包括事件分類、重要性、可信度、尺度、摘要、趨勢歸屬與敘事關係。這些資料應允許持續修訂。

因此：

$$
\text{Evidence}_{t_0}
\text{ remains addressable}
$$

而：

$$
\text{Interpretation}_{t_0}
\rightarrow
\text{Interpretation}_{t_1}
\rightarrow
\text{Interpretation}_{t_2}
$$

兩者之間的關係必須保留。系統可以承認「早期判斷錯了」，卻不應重寫成「系統從未做過那個判斷」。

---

## 12. 版本、修訂、更正、撤回與恢復

「更新」不是單一狀態。至少可以區分：

- **內容更新**：增加或修改資訊；
- **新版本**：形成可獨立識別的新版本；
- **更正**：原內容存在錯誤，但主體仍有效；
- **部分撤回**：部分主張失效；
- **完全撤回**：整個成果不再被支持；
- **關切聲明**：尚未確定，但存在重大疑慮；
- **恢復**：先前撤回或質疑後重新有效；
- **取代**：由另一份內容或事件狀態接替。

Crossref 的版本、更正與撤回實務強調，重大更新不應只悄悄修改原文件，而應建立可識別的更新文件並連結原項目；DataCite 也提供 `IsNewVersionOf`、`IsPreviousVersionOf` 等關係，讓版本鏈可被機器理解。

因此，事件或來源之間需要明確關係：

$$
R_v
\in
\{
\text{updates},
\text{corrects},
\text{retracts},
\text{reinstates},
\text{supersedes},
\text{isVersionOf}
\}
$$

並形成版本有向圖：

$$
G_v=(V_v,E_v)
$$

版本圖通常應保持無循環，避免出現「A 取代 B，B 又取代 A」的矛盾關係；若出現衝突，應以爭議狀態保存，而不是強行合併。

---

## 13. 歷史中的主張狀態

事件不只是存在或不存在。對尚未確定的資訊，平台應保存主張狀態。

令主張 $c$ 的狀態為：

$$
\sigma(c,t)
\in
\{
\text{reported},
\text{corroborated},
\text{disputed},
\text{corrected},
\text{retracted},
\text{superseded},
\text{unresolved}
\}
$$

並保存狀態變化：

$$
\sigma(c,t_0)
\rightarrow
\sigma(c,t_1)
\rightarrow
\cdots
$$

如此，系統不必在資訊剛出現時就假裝知道最終真相。它可以先記錄：

> 某來源在某時做出某主張，目前尚未被獨立確認。

之後再根據新證據更新狀態。這比直接刪除錯誤新聞更符合歷史記憶，也能保留資訊如何傳播與被修正的過程。

---

## 14. 從事件序列到事件鏈

單純按時間排序事件仍不足以形成歷史解釋。平台需要辨識事件之間可能存在的關係：

$$
R_e
\in
\{
\text{precedes},
\text{follows},
\text{enables},
\text{respondsTo},
\text{contradicts},
\text{supports},
\text{extends},
\text{causes?}
\}
$$

其中因果關係必須特別謹慎。時間先後不等於因果：

$$
\tau(e_i)<\tau(e_j)
\not\Rightarrow
e_i\rightarrow_{cause}e_j
$$

因此本文建議將關係區分為：

- 已由來源明確聲明；
- 多來源一致支持；
- 系統推定；
- 僅有時間鄰近；
- 存在爭議。

事件鏈可以形成敘事圖或事件中心知識圖譜，但系統必須保留每條關係的證據與信心，而不能為了生成順暢故事而虛構因果。

---

## 15. 每日三則本身也必須進入歷史

每日三則不是中立顯示，而是一次注意力分配決策。因此系統必須保存：

- 當日候選池；
- 每則候選的分數；
- 使用的權重與規則；
- 最終入選與未入選原因；
- 模型與 Domain Pack 版本；
- 是否有人工作業；
- 發布後是否修改。

令日期 $t$ 的候選事件集合為：

$$
C_d(t)=\{e_1,e_2,\ldots,e_n\}
$$

重要性函數版本為：

$$
W_d^{(v)}
$$

則當時選擇為：

$$
N_d^{\mathrm{then}}(t)
=
\operatorname{Top3}_{W_d^{(v)}}
\left(C_d(t)\right)
$$

未來可以用新權重重新計算：

$$
N_d^{\mathrm{replay}}(t;v')
=
\operatorname{Top3}_{W_d^{(v')}}
\left(C_d(t)\right)
$$

比較兩者，即可發現：

- 當時低估了哪些事件；
- 哪些事件只是短期熱點；
- 排序模型的偏差如何演化；
- 領域的重要性標準是否改變。

這使每日新聞平台開始具有自我反省能力。

---

## 16. 微觀、中觀與宏觀歷史的重建

前一篇已提出多尺度差分。本篇進一步指出，不同尺度的歷史不應各自獨立保存，而應能由底層事件重新聚合。

微觀歷史：

$$
H_{\mu}(x,T)
=
\{e_i\mid e_i\text{ relates to }x,\tau(e_i)\le T\}
$$

中觀歷史：

$$
H_m(D,T)
=
\operatorname{Cluster}
\left(
\bigcup_{x\in D}H_{\mu}(x,T)
\right)
$$

宏觀歷史：

$$
H_M(T)
=
\operatorname{Synthesize}
\left(
H_{m,1},H_{m,2},\ldots,H_{m,k}
\right)
$$

但中觀與宏觀投影不能只在事件首次進入時生成一次。當新資料出現後，事件聚類、趨勢邊界與轉折點可能改變，因此需要版本化的聚合結果：

$$
H_m^{(v_1)}(T)
\rightarrow
H_m^{(v_2)}(T)
$$

這正是可重算歷史與普通檔案館的差別。

---

## 17. 歷史查詢的七種基本模式

一個可查詢領域記憶至少應支援七類問題。

### 17.1 事件查詢

「某日期或時間範圍發生了什麼？」

### 17.2 狀態回放

「截至某個時間點，平台當時知道什麼？」

### 17.3 有效狀態查詢

「以今天的知識來看，某事實在何時成立？」

### 17.4 演化軌跡查詢

「某個概念、機構、專案或爭議如何演變？」

### 17.5 溯源查詢

「這項判斷依據哪些來源、模型、規則與人工決策？」

### 17.6 修訂查詢

「哪些內容後來被更正、撤回、取代或重新分類？」

### 17.7 跨尺度查詢

「哪些微觀事件累積成某個中觀趨勢或宏觀轉折？」

形式上，查詢可以寫成：

$$
Q
=
(d,x,[t_1,t_2],\ell,p,v,m)
$$

其中：

- $d$ ：領域；
- $x$ ：實體、事件或主題；
- $[t_1,t_2]$ ：時間範圍；
- $\ell$ ：尺度；
- $p$ ：溯源條件；
- $v$ ：版本或知識時間；
- $m$ ：當時所知或今日回看模式。

---

## 18. 早期訊號與後見偏誤

可查詢歷史的一項重要價值，是辨識早期訊號。但這同時容易產生後見偏誤。

事件在當時的重要性為：

$$
I_{then}(e,t)
$$

事件在後來回看時的重要性為：

$$
I_{now}(e,T)
$$

通常：

$$
I_{then}(e,t)
\neq
I_{now}(e,T)
$$

某篇小型論文、某次程式提交或某項不起眼政策草案，可能在多年後被視為重大轉折。平台可以將其辨識為「早期訊號」，但必須清楚標明這是事後評價，而不能把後來的重要性偽裝成當時已知。

因此應保存兩個欄位：

- `importance_at_observation`；
- `importance_reassessed_at`。

並允許建立重要性曲線：

$$
I_e(t)
$$

歷史價值不只是知道發生過什麼，也包括觀察一個事件如何逐漸獲得或失去重要性。

---

## 19. 遺漏、遲到與回填

任何資訊收集系統都會漏抓事件。可查詢歷史不能假設資料會按正確時間順序進入。

若事件發生於 $t_o$ ，但系統在 $t_i$ 才發現，且：

$$
t_i\gg t_o
$$

則它是一個遲到事件。

系統應允許回填：

$$
\mathcal{L}_{t_i}
\leftarrow
\operatorname{Append}
\left(
\text{LateEvent}(e,t_o,t_i)
\right)
$$

但不能把它偽裝成系統在 $t_o$ 就已經知道。回填後：

- 今日回看歷史可以把它放回正確事件時間；
- 當時所知歷史仍顯示當時並未觀測到它；
- 每日三則原始版本不應被靜默改寫；
- 系統可以另產生「歷史補遺」或重新計算結果。

這種處理能同時維持世界時間與知識時間的一致性。

---

## 20. 刪除、遺忘與歷史責任

歷史保存並不表示無限制永久保存所有資料。

平台需要面對：

- 個人資料與隱私；
- 著作權與授權；
- 來源要求移除；
- 危險資訊；
- 商業機密；
- 法律上的刪除或限制處理義務；
- 儲存成本與資料腐敗。

因此可建立多層保存：

$$
\text{Hot}
\rightarrow
\text{Warm}
\rightarrow
\text{Cold}
\rightarrow
\text{Tombstone}
$$

其中 Tombstone 不保存受限制內容本身，但可在合法範圍內保存：

- 曾存在某紀錄；
- 移除時間；
- 移除類型；
- 權限狀態；
- 是否仍可由授權角色查閱。

「可追溯」不等於「所有人永遠可見」。領域記憶必須同時具備歷史責任與存取治理。

---

## 21. 失敗模式

領域歷史平台至少有八種主要失敗風險。

### 21.1 覆寫歷史

新摘要直接取代舊摘要，使錯誤與修正過程消失。

### 21.2 時間混淆

把事件時間、發布時間與觀測時間混為一談。

### 21.3 來源漂移

原始網址內容改變，但平台沒有保存快照或雜湊。

### 21.4 事件重複

同一事件被多篇來源重複計入趨勢。

### 21.5 錯誤合併

將兩個相似但不同的事件合併成單一節點。

### 21.6 後見污染

用後來知識重寫當時判斷，使歷史看起來比實際更理性。

### 21.7 敘事過擬合

為了形成連貫故事，將時間鄰近誤寫成因果鏈。

### 21.8 永久化錯誤

錯誤分類或模型幻覺進入歷史後，未標示不確定性與修訂狀態。

因此，歷史系統的品質不只取決於收集量，而取決於它是否能誠實保存自身的不確定、錯誤與修正。

---

## 22. AGIRight 的具體例子

以 AGIRight Topics 的每日領域資訊為例，一則完整歷史紀錄可以經過以下生命週期：

```text
1. 官方來源發布文件
2. 系統擷取原始頁面並建立快照
3. AI 抽取一個或多個主張與事件
4. 事件被路由至 AI Rights / Governance 等領域
5. 系統計算重要性、可信度與尺度
6. 事件進入當日候選池
7. 入選每日三則並生成多語入口
8. 保存選擇理由、模型與規則版本
9. 後續來源發布更正或補充
10. 系統新增修訂事件，不覆寫原判斷
11. 中觀趨勢與宏觀歷史重新計算
12. 使用者可切換「當時所知」與「今日回看」
```

其資料關係可以寫成：

$$
SourceSnapshot
\rightarrow
Claim
\rightarrow
Event
\rightarrow
DomainProjection
\rightarrow
DailySelection
\rightarrow
Revision
\rightarrow
HistoricalReplay
$$

這使 AGIRight 不再只是每天新增三則內容，而逐步成為 AI 權利與治理領域的時序記憶。

---

## 23. 最小可行領域記憶

第一版不需要立即建立完整 Temporal Knowledge Graph。最小可行系統可以只包含八類物件：

```text
1. Source
   └── 原始網址、來源身分與授權資訊

2. Snapshot
   └── 擷取時間、內容雜湊與保存位置

3. Claim
   └── 來源提出的可識別主張

4. Event
   └── 去重後的領域狀態變化

5. VersionRelation
   └── 更新、更正、撤回、取代與版本關係

6. Assessment
   └── 分類、重要性、可信度與尺度判斷

7. DailySelection
   └── 候選池、入選結果及當時規則

8. AuditEvent
   └── 所有建立、修改、合併與發布操作
```

最小時間欄位則包括：

```text
event_time
published_time
observed_time
recorded_time
valid_from
valid_to
```

只要這些物件與時間能被可靠保存，平台就已經具備從新聞檔案進入可查詢歷史的基礎。

---

## 24. 從領域記憶到時序知識圖譜

當事件、實體、來源與版本逐漸增加後，資料可以進一步形成時序知識圖譜：

$$
G_t=(V,E,T,P)
$$

其中：

- $V$ ：實體、事件、來源、主張與版本；
- $E$ ：參與、支持、衝突、更新、取代及時間關係；
- $T$ ：時間點與有效區間；
- $P$ ：來源、信心與溯源資訊。

靜態三元組：

$$
(s,r,o)
$$

會擴充為時間化與溯源化陳述：

$$
(s,r,o,[t_s,t_e),p)
$$

其中 $p$ 指向證據與生成活動。

時序知識圖譜研究之所以重要，正是因為現實中的大量關係只在特定時間成立，而事件知識圖譜則把事件本身提升為可查詢節點。對本系列而言，這不是第一版必須完成的工程，而是領域記憶累積後的自然升級方向。

---

## 25. 核心命題

本文可以收斂為以下命題：

> 每日資訊流只有在保存事件身分、原始來源、時間語意、版本關係、生成溯源與當時判斷時，才可能累積成可查詢歷史。平台不應以最新內容覆寫過去，而應將每次觀測、分類、選擇、修訂與撤回記錄為可追溯事件，再透過投影與回放重建不同時間點、不同尺度與不同知識狀態下的領域世界。

形式化表示為：

$$
\mathcal{H}_d(T)
=
\left(
\mathcal{L}_{\le T},
\mathcal{S}_{\le T},
\mathcal{P}_{\le T},
\Pi_d
\right)
$$

其中：

- $\mathcal{L}$ ：追加式事件帳本；
- $\mathcal{S}$ ：來源與狀態快照；
- $\mathcal{P}$ ：溯源、版本與時間關係；
- $\Pi_d$ ：領域投影與重建函數。

並必須同時保留：

$$
\boxed{
\text{原始證據}
+
\text{當時所知}
+
\text{當時判斷}
+
\text{後來修正}
+
\text{今日重算}
}
$$

這五者共同構成領域記憶，而不是單一「最新答案」。

---

## 26. 與下一篇的關係

本篇解決了資訊如何從每日流量累積成可查詢歷史，但仍未回答更大的問題：當數百、數千個領域觀測站持續收集、分類、重算與保存時，網路資訊海是否真的會因此變得更有秩序？

下一篇將處理：

- 資訊混沌是否能被消除，或只能被局部結構化；
- 動態秩序與靜態分類的差異；
- AI 大規模整理如何降低資訊熵與導航成本；
- 多重秩序如何共存，而不形成單一分類霸權；
- 系統如何避免將錯誤、偏見與內容農場一併秩序化；
- 網路資訊海從被動搜尋走向持續感測的結構性轉變。

因此下一篇為：

# 《混沌之上的動態秩序：AI 時代網路資訊海的結構化》

---

## 參考資料

[1] W3C, “PROV-O: The PROV Ontology,” W3C Recommendation, 2013. 以 Entity、Activity、Agent 及其關係描述資料與成果的生成溯源。https://www.w3.org/TR/prov-o/

[2] W3C, “PROV-DM: The PROV Data Model,” W3C Recommendation, 2013. 定義溯源資料模型及實體、活動與代理者的核心關係。https://www.w3.org/TR/prov-dm/

[3] H. Van de Sompel et al., “RFC 7089: HTTP Framework for Time-Based Access to Resource States — Memento,” IETF, 2013. 定義 Web 資源過去狀態的時間協商與 TimeMap。https://www.rfc-editor.org/rfc/rfc7089.html

[4] Microsoft, “Event Sourcing pattern,” Azure Architecture Center, updated 2026. 說明以追加式儲存記錄造成領域狀態改變的完整事件序列，並由事件重建狀態。https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

[5] Martin Fowler, “Event Sourcing,” 2005. 說明將所有應用狀態變化保存為事件序列，並支援查詢與狀態重建。https://martinfowler.com/eaaDev/EventSourcing.html

[6] PostgreSQL Wiki, “SQL2011Temporal.” 說明 Application Time／Valid Time 與 System Time／Transaction Time 的差異，以及雙時間資料概念。https://wiki.postgresql.org/wiki/SQL2011Temporal

[7] Crossref, “Version control, corrections, and retractions.” 說明重大更正與撤回應建立可識別更新並連結原始項目，而非只靜默覆寫。https://www.crossref.org/documentation/principles-practices/best-practices/versioning/

[8] Crossref, “Relationships.” 定義研究成果之間的更新、更正、撤回、語言版本及其他關係。https://www.crossref.org/documentation/schema-library/markup-guide-metadata-segments/relationships/

[9] DataCite, “Versioning.” 說明以 `IsNewVersionOf`、`IsPreviousVersionOf` 等 RelatedIdentifier 關係連接不同版本。https://support.datacite.org/docs/versioning

[10] DataCite, “Connecting different versions, formats and more with Related Identifiers.” 提供研究資源版本與格式關係的機器可讀表示。https://support.datacite.org/docs/connecting-versions-with-related-identifiers

[11] L. Cai et al., “A Survey on Temporal Knowledge Graph: Representation Learning and Applications,” arXiv:2403.04782, 2024. 討論時間化知識圖譜對動態實體與關係演化的表示。https://arxiv.org/abs/2403.04782

[12] S. Guan et al., “What is Event Knowledge Graph: A Survey,” arXiv:2112.15280, 2021. 綜述事件中心知識圖譜的定義、建構與應用。https://arxiv.org/abs/2112.15280

[13] Z. Yan et al., “Narrative Graph: Telling Evolving Stories Based on Event-Centric Temporal Knowledge Graph,” IEEE Transactions on Visualization and Computer Graphics, 2023. 以事件中心圖譜與時間關係建立演化敘事。https://pubmed.ncbi.nlm.nih.gov/37128597/

---

## 版本紀錄

| 版本 | 日期 | 狀態 | 說明 |
|---|---|---|---|
| 0.1.0 | 2026-07-31 | 公開初稿 | 建立領域記憶定義、四時間模型、有效時間與紀錄時間、當時所知／今日回看雙模式、追加式事件帳本、快照、溯源、版本鏈、主張狀態、歷史回放與最小可行領域記憶。 |