为什么我们在笔记应用中加入了 provenance
I’m happy to translate the article for you, but I’ll need the actual text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and technical terms.
介绍
在现场记录的笔记非常适合记录结果和反思，但将导致这些结果的过程以结构化数据的形式保存下来却出奇地困难。那些只存在于某人脑中的程序、未写进页面的隐含假设，以及在会议演示稿中被概括掉的判断——当你多年后再次阅读这些笔记时，这些内容很少能完整保留下来。
我也有同感。离开活跃的实验工作已有十多年后，我试图回忆其中一次实验的流程。留下的只有零散的笔记和几份会议演示稿。结果仍在，但通向结果的过程已经随时间而变得模糊。
对结构化流程的需求
常见的方法论建议在笔记本中将过程绘制成流程图。即便如此，现场记录往往以结果为中心，而在此基础上再记录结构化的流程会比预期更费力。为了以后能够复现工作，拥有一种能够将流程以结构化数据形式记录在结果旁边的设置将非常有价值。
日本料理有一句关于 sa‑shi‑su‑se‑so 的说法——按顺序加入糖、盐、醋、酱油和味噌会改变味道。实验也是如此。你加入什么、何时加入以及加热多长时间——这些选择决定了结果。流程 是 结果。
因此，我想要一种方式来保存“什么来源于什么，通过什么流程”——这种因果数据——作为结构化记录。随着 AI 开始处理实验数据，这一点变得尤为有趣。
Provenance Data Model (PROV‑DM)
我偶然发现了 PROV‑DM（溯源数据模型），它是一个用于描述“由什么制成、从何而来以及如何制成”的 W3C 标准。它定义了三个原语——Entity（实体）、Activity（活动）、Agent（代理）——以及它们之间的关系。
学术数据系统会使用它，但个人笔记应用通常不会。然而，研究者的日常产出已经符合这种结构：“我对样本 A 进行热处理，得到样本 B”，字面上就是“实体 B 由活动（热处理）从实体 A 生成”。有了它，我就可以把实验流程——原本只存在于脑中的那部分——以结构化数据的形式保存下来。
进一步观察，同一模型同样适用于文档编辑历史，而不仅仅是内容溯源。事实上，这可能更接近 PROV‑DM 最初的设计初衷。
Graphium：两个层次的溯源
在 Graphium 中，溯源被分为两个层次：
层 1 – 内容溯源
实验工作流（Sample A → Sample B 等）。这将过程保存在笔记中作为因果结构，使研究者——或之后阅读笔记的 AI——能够以更高的分辨率追踪流程。
层 2 – 文档编辑溯源
谁在何时编辑了什么。编辑者（人类或 AI）映射为 prov:Agent，编辑操作映射为 prov:Activity，文档修订映射为 prov:Entity。将 “AI 与否” 记录为 Agent，可在重新阅读或共享工作时提供明确的区分。
随着 AI 成为工作的一部分，这两个层次的价值都会提升。结构化的流程成为可分析或复用的材料，而编辑溯源则阐明 AI 生成内容的来源。
Design Approach
要求用户直接创建图谱是行不通的。Graphium 将 PROV‑DM 映射到文档本身的语法上：
- Headings 变为 Activities。
- 标题内部的短行内高亮将被标记的词（例如 “NaCl”、 “80 °C”、 “clear solution”）转化为 Entities。
写作体验保持为 “输入标题，写段落，偶尔高亮一个词”。溯源图是计算得到的视图——永远不需要手动编辑。
并非所有链接都应是因果关系。像 “This paper was interesting” 或 “this concept resembles that one” 这样的陈述是非方向性的。强行赋予它们因果性不自然，因此 Graphium 将它们拆分：
@提及默认是 knowledge links（无方向，允许循环）。- 标题范围内的行内高亮之间的关系是 provenance links（有向，无环）。
因此，同一次写作会在底层生成两张不同的图谱。
更广泛的适用性
“什么来自于什么”这一问题远超实验室工作：食谱、软件变更历史、医疗记录——其形式相同。这也是本文标题图片是面包制作笔记而非化学实验的原因。
源代码
实现是开源的：