还没看过上篇的朋友，可移步至：Roam Research：一款为研习者而生的笔记工具 | 认知下一代信息管理系统（上）

奥林匹克格言：更快，更高，更强

前端式数据处理

Embedding：嵌入在 Graph | 跃然于纸上

镜像 {{embed: ((block ref))}

在 Roam 里，可以通过复制粘贴的形式，将块引用嵌入到 Graph 中的任何一个 Block 内。

通过粘贴该嵌入块 {{embed: ((block ref))}} 到任何一处，即可复现与原区块完全一致的“镜像版本”。

镜中镜

嵌入，嵌入，再嵌入

即便是涉及到对同一区块的「多重引用」，Roam 同样能够保证 100% 的同步率以及近乎 0ms 延迟的编辑体验。

任意门 {{embed: [[title]]}}

将嵌入块 (Embed-Block) 中的 ((block ref)) 替换成 [[title]]，以实现对于整一页 Page 的嵌入——这样一来，被嵌入的 Page 将看起来不再那么“独立”，而是变成了某一个区块的子级节点 (Children Node)。

实际上，对于 Page 的嵌入形式并不会使其原本“独立”的节点关系发生任何改变——你可以将这类嵌入页面 (Embed-Page) 仅看作是某种伪类的子级节点 (Pseudo-Children Node)

Searching 或 Querying：这是一个 Mention

无论是搜索 (Searching) 还是查询 (Querying)，都应该以「可检索 (Retrieving) 原文并提供上下文背景」为标准来衡量返回结果 (Returns)。

搜索 {{[[search]]: {keyword}}} 

搜索包含输入（关键词）的一切区块

在 Roam 中，你可以在某一页 Page 任意一处 Block 嵌入搜索块 (Search-Block)；然后输入关键词，即可返回所有包含「此关键词」的 Block(s)。

你还可以按一下 Show More，以展示更多返回的内容。

理论上说，Search Block 能够返回该 Graph 中所有涉及到「此关键词」的 Block(s)

查询 {{[[query]]: {and/or:[[title]]/((block ref))}}}

查询与之相关的一切区块

查询块 (Query-Block) 的功能类似，但查询的形式比起单纯的关键词搜索更加精确。

只需设置几个简单的查询条件，即可轻易返回与之相关的 Block(s)；

• 下面来简单说明一下 Query-Block 的四类基本条件：
  1. Query (and): 包括 A，B
  2. Query (or): 包括 A 或 B
  3. Query (and or): 包括A，包括 B 或 C
  4. Query (and not): 包括A，不包括 B

1、2 命令很好理解：如果说 Query (and) 条件是要求 A 与 B 位于同一 Block 中；那么 Query (or) 则只要求二者中的一个位于某一 Block 中，即可返回满足条件的 Block(s)。

3、4 命令类似，其中 Query (and or) 比较特殊：它要求 A 位于某一 Block 的前提下，B 或 C 两者之一也位于该 Block；而 4 命令 Query (and not) 里的 not 则是把 B 设置成排除项。

感兴趣的朋友可以自行了解：How Queries Work in Roam Research

不难发现，Query-Block 内输入的正是 [[title]] 形式的 Page 引用。

而当我们把标题引用 [[title]] 替换为块引用 ((block ref)) 时，Query-Block 的查询返回将同样有效！

提及 {{[[mentions]]: [[title]]/((block ref))}}

返回提及某一引用的一切区块

如果说，Search-Block 是内嵌了一个搜索框 (Search Box) 在某一 Page 内，那么 Mention-Block 则是拓展了关于其他 Page(Block) 的引用联系。

与 Query-Block 类似，Mention-Block 也可以通过输入 `((block ref))` ，用作「针对」Block 级别的查询返回。

原生应用的备份导出 - 简约主义的资源管理

EDN: 充分完备的导出格式

对于那些习惯 All-in-One 的个人来说，无论是面对跨笔记库 (Cross-Graph) 时的数据迁移；还是为了避免云端（本地）存储遇到意外而导致的数据损失——EDN 格式的备份导出，几乎成了唯一的最佳选项！

于 Roam 而言，包含 Graph 所有笔记的数据信息，全部被存储在同一份 EDN 格式文件当中——这也就意味着，最近时间的 EDN 文件即包含 Graph 在导出时刻的完整备份；至于之前时间（日期）的，则可看作是该 Graph 的历史版本。

也就是说，仅需导入最近时间的那一份 EDN 备份文件，即可复原整个 Graph 的全部数据信息。

即导即出 | 镜像迁移

EDN 作为应用程序的原生格式，无论是本地库还是云端库（包括加密库类型在内）的数据存储，都会加载到当前 Browser 的存储 (Storage) 内——真正做到了「存储在本地」的“就近原则”；因此，在导出 EDN 格式备份时，桌面端 (Desktop App) 和网页端 (Web App) 都能实现「即导即出」的即时备份。

反过来说，在新建的 Graph 中导入其他 Graph  的完整备份（仅支持 EDN 格式）时，仅有 EDN 格式的备份文件能做到最大程度上的数据复原——即在保真度上，EDN 格式备份不但可重建 Graph 整体的关系结构（各 Page/Block 之间的引用关系），还能够保留所有 Blocks 的非必要元数据 (Non-Necessary Metadata)。

整个导入三个数量级（100＜N＜1000）的笔记 (Page) 节点来算，所需的时间通常在一分钟以内——甚至不到 30 秒。

全自动备份 | 历史版本

通过 Roam Depot 里的插件 Page History，甚至而且更进一步的实现对单一 Page 的历史版本保留。

Hosting | 图床托管的灵活性

Roam Graph 通过对节点数据 (Page/Blocks) 与资源文件 (Uploads) 的分离式存储，既保证了 Graph 在加载到本地时不受媒体附件的影响，又维持了 Graph 自身数据结构的简致性——即无论上传或引入的媒体附件多少，都不会影响到 Graph 整体的结构关系。

Roam 本身提供创建本地库和云端库 (Local Graph/Hosted Graph)：

• Local Graph 支持 Uploads 存储到本地目录文件下方；

• Hosted Graph 则通过 Firebase 的网络传输上传至 Google Cloud 作云端存储。

对于 Hosted Graph 而言，挂载在 Google Cloud 的资源文件（即媒体附件）必须在联网的前提下才能下传到本地展示；Roam 则在设置 (Settings) 处提供了后台式的图床管理服务。

一次外链，多处引用

在 Roam 里，你只需上传一次资源文件，即可在异地 Block(s) 引用同一份附件并实现无损化复现。

扁平化的资源管理

在各种资源文件的页面 (![/video/audio/PDF) 下方 (Linked References) 即可查看到所有对应类型的资源文件。

![ 是 image 类 URL 用作「展示」的<充分文本>；实际应用上，则可通过创建 .jpg/.png/.gif 等更精确的 Page 来统一查看相应格式的媒体附件。

事实上，Roam 对于文本（字符串）以外的数据均作区分化存储，使得资源文件（媒体附件）的上下传几乎不受 Graph 自身的任何影响。

任何挂载在线托管网站的可访问资源文件，Roam 都能快速加载至本地浏览；

配合 Roam Depot 插件 Query Builder 设置简单的语法条件，甚至还能建立起高效的查询块（机制）——可锚定该资源 URL 的<网址域名>作更精细化的检索（如：查询挂载在 XX 图床上的所有图像）。

可以说，Roam 在节点内容的粒度上没有任何限制，也支持上传各种类型的资源文件——除了文本，块引用本身还能展示图像，音视频等外部链接的内容；

也就是说，对于同一份媒体文件的「复现」，Roam 能做到百分之百的利用率，进而使得整个 Graph 高度「精简」。

展望未来：一个更大的愿景 | 人人为之贡献的社区型知识图谱

在 Roam 中，每一个 Block 都会保存与之相关的编辑信息。

在导出的 JSON 文件里，甚至可以查看到「创建账户-创建时间/编辑账户-最近编辑时刻」的相关信息；

从软件开发的角度来看，存储这类数据似乎并没有什么意义——在 Graph 里的数据不都是属于用户（订阅邮箱）本人的吗？

让我们换个角度思考，Graph 何必拘泥于个人笔记内容，一个真正有助于实现个人/他人价值的社区型 Graph 应该是可以共享的，且满足于多人协作的编辑场景。

协作者的充分编辑权限

全权编辑许可

设置为 edit 权限的共享（协作）邮箱若默认不启用 Immutable blocks 选项，协作者（编辑邮箱）将可以随意编辑/删除由 Graph 所有者（订阅邮箱）创建的全部 Blocks。

限定导出授权

关于导出权限，Graph 所有者（订阅邮箱）还可以设置为仅限于协助者（编辑邮箱）。

在「全权编辑许可」与「限定导出授权」的双重加持下，协作者（编辑邮箱）可被视作 Graph 所有者以外访问权限最高的用户。

信任与非信任协作

信任协作场景下的版本控制

在共享（编辑权限）用户可信任的协作场景下，各用户可自行添加当前块的版本 (Add version)，以实现对同一位置的 Block 进行多版本编辑。

基于不可变动块的非信任协作

在启用 Immutable blocks 的前提下，各个用户（包括订阅邮箱）都不可以编辑或移除由其他人创建的 Blocks/Pages；但能在 Immutable block 下方创建 Block(s) 并通过缩进，或直接拖动至该区块下方，使其作为附属的（后代）节点。

除此之外，用户之间可正常引用（相对于自己）不可变动的 Blocks。

基于 Query Builder 的内容审计

还可以通过添加查询选项 (Add Selection) 来进一步查询关于编辑的时间信息：

协作者的参与度

在 Roam 里，协作者除了可以参与到 Graph 内容上的创作，还能通过 Slider 功能块 {{[[slider]]}} 与内置的评论页面 [[roam/comments]] 体现用户的活跃程度。

Slider 评分机制

滑动块 (Slider-Block) 本身可用于多种评分目的，比如让社区用户「共同表明对某一观点的认可程度」：

Comment 评论

每一位（编辑邮箱）用户都可以对某一特定的区块内容作出评论，Roam 会自动为每一位用户生成对应的评论块 (Comment-Block)。

结尾

至此，关于 Roam Research 主要内容的介绍就基本完毕了。

总结

在关系结构上，Graph 能够高效联络起各 Page 之间的 Blocks；而从数据存储的角度出发，Roam 对资源文件 (Files) 的管理又是相当明智的——将用户上传的媒体附件作分离式存储，且允许对同一份 Upload 的（引用）复现；

最终在实现 Graph 内部高度维稳的同时，还保证了应用程序在数据处理方面的高效运行。

感言

诚然，入门 Roam 是存在一定门槛的，无论是（对于国内用户）全英界面带来的「不适感」；还是初见 Roam 时的异常「空旷感」；又或是在第一次面对 Sidebar 时的不知所措——以上种种，都有可能成为新人用户「自我劝退」的缘由。

而当你真正上手后，便会不自觉的陷入其中，对于 Roam Research 的使用场景也会随着时间的推移，自然而然迎来新的开拓与发掘。

可令人遗憾的是，Roam 官方高昂的订阅价格实在是令人望而却步的——几乎成为了大多数人放弃（或离开） Roam 的主要原因。

对此，笔者想说：无论怎样优秀的笔记工具，最终都是要由人去使用的。

不过笔者始终坚信，Roam 真正要做的绝不只是一个 Note-taking tool 那么简单，而是要让人们在创建/编辑笔记的过程中尽可能得跳脱出"盲目的整理怪圈"。

人们应当认识到这一点：关于信息的分类本应是多维度，多模态的。

与其事先定义好一个个「层层嵌套的文件柜」去收纳文档；倒不如让笔记在输入-输出的过程中“自行生长”——以实现对知识图谱的网络模型整合，最终建立起长期的思维认知体系。

正如 Roam 团队在官网介绍的那样：

最后的最后，请允许笔者用一句话作为全文的总结：

人类的生命是短暂的，但知识却是永恒的，让我们在有限的人生里致力于无限的事业！

参考资料

【双向链接的前世今生】上都计划与 Roam Research 思维工具

Wikipedia - Project Xanadu
世外桃源计划

Deep Dive Into Roam's Data Structure - Why Roam is Much More Than a Note Taking App
【译】深度解析 Roam 数据结构 —— 为什么 Roam 远不只是一个笔记应用

The Datomic Information Model

White Paper
💡 Roam White Paper | Roam 白皮书

Roam Reserach 到底好在哪儿？