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)

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

以今天的知識來看，某項事實在 2025 年何時有效？
在 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 的每日領域資訊為例，一則完整歷史紀錄可以經過以下生命週期：

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。最小可行系統可以只包含八類物件：

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

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

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

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

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

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

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

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

最小時間欄位則包括：

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

04_從每日資訊流到可查詢歷史_領域記憶的累積機制_v0.1.0