这部分的结构较之前三篇庞大很多。之前的三种顶多几个小时就能完善成型，但是这一次，从初次构思到结构基本定型，总共应该说是花了几天时间（除去其间置之不理的几个月……）。目前为止，基本形成了一套相对完善的信息互联网络，其中也包含一些在当前无伤大雅的、尚未找到方案解决而暂时被搁置的问题，会在每一部分的末尾列出，将来解决了的话也会回来更新。

本部分原本想和上一部分（剪藏）合在一起作为一个大专题来写。但是这一部分有点复杂，一章搞不定，所以干脆独立出来写。

用途简介

所谓大瀑布，就是……信息大瀑布……因为我设计这一部分的目的是创造一套方便随时取用的史料整理法，随着深入的补缺补漏，整个系统的总信息量会急速膨胀，所以，不光是信息总量庞大，整体结构也将是我的Notion中史无前例的立体和细致。

这些DB所涉及的历史资料中，包含事件、人物、团体和国家（暂时不包含时事，时事相关的资料主要还是收纳在剪藏板里）。同时，也能较为便捷地从各个角度切入、根据不同的范畴来读取相关的资料。当然，这一套系统中还可以加入更多类型的内容，也一定适用于更多不同的用途。我只是就设计它时的预期和目前达到的效果来展开介绍。

核心板块

为了避免单章篇幅冗长，本节将分为两个部分发布。第一部分主要介绍人物DB的结构，第二部分介绍其他三个DB的结构。

---

2021年1月25日更新。更改内容：
原人物db对国家&世界史的relation改为单向引用。

---

人物板块

上述四个板块中，人物db内部还增加了两个子db，用以整理人物的生平和作品表。将来可能在其他板块（比如国家）下也会按需增设新的子db。先尽量简单地介绍一下这已有的4+2个互联关系。直观起见，我画了一张图。

构成概述

以贝多芬的资料页为例，以下是经过初次调试后刚好能用的状态。先简单介绍一下页面的结构，后面会解释如此安排的考虑。

为了方便叙述，下文将database中每个页面的标题栏称为“根prop”。

年龄算法参考：

dateBetween(prop(“卒年”), prop(“生年”), “years”)

解释一下某些地方使用引用、某些地方使用relation的考虑。
①  国籍方面，考虑到有的早期国家在今日已被瓜分至不同的政权手中，如果仅仅录入今属国家而导致原本国籍相同的人物看上去具有了不同国籍，不太恰当。所以用引用的方式能比较灵活地作出标记。
②  历史事件方面，考虑到在人物页面中，经历同样事件的人物对该事件的影响力大小不一，有些人仅仅作为经历者，而有些人则是促成了这些事件的中坚力量之一，为了避免在事件页面堆积不必要的无关信息，所以取消了原来的relation，改为更灵活的单向引用（说是单向引用，其实被引用的页面上可以回溯，有需要的时候查看起来也很方便）。
③  至于团体之所以使用relation是因为，在我有限的认知里，人物所属的通常都是党派或者什么协会之类的团体。这类团体在网络上的资料不比国际联盟（总是会详细列出其成员国及附属国），通常只能考虑到其中最有存在感的几位。所以在这里使用relation，使其成员能无差别地在组织资料内显示，就有机会发现某些意想不到的历史关联。

一点思路&未决问题

通常情况下，根prop的默认名字“Name”以及它在页面中所处的位置，会导致潜意识地将它用作标题栏。但是，考虑到其在关联的db中所需要显示诸多的信息，全部用作标题显然会减损效率（比如基于relation的显示特征，它无法直接完整显示过长的文本）。

所以在大事记年表中，用根prop而非其他属性的Prop来显示年份，目前来看是一种较为有效的妥协。这样，在作品表prop中，关联大事记的prop直接可以标记作品年份，同时用rollup显示完整的背景资料。

尚未解决的问题主要集中在生平db和整个构架的脱节上。之所以会产生这个困难，主要是因为所有人物的子database都互相独立、且生平事件按照年份来划分。这种脱节导致的结果就是，在生平db中只能手动输入背景资料，不能直接从现成的史实db中提取信息。有利有弊。利在于录入的时候可以体现更多相关度更高的信息（比如更为小道的花边信息），因而更自由；弊端在于人物资料多了之后，必定存在一系列大事件同时对多人产生影响，你只能反复录入（被迫背书.gif，倒也不赖？🌝）。

暂时决定让它们互相独立的原因有三：

首先，历史人物的数量不必说，每人生命中的每一年都被重复统计，怕崩溃；
其次，跨领域的人物作品形式和相关信息都是不一样的，比如科学家就不存在作品号的问题，艺术家就不存在研究成果具体所属的学科、以及实验条件等问题，综合在一起的话，会牺牲单个页面的显示效率；
再次，如果为了读取世界时间线上的信息，将每个子db都与世界互联，那么总线程上的信息会过于杂乱冗余，同样影响显示效率（毕竟在那些页面内除了prop，下面偶尔还是会写一些笔记或者存点附加资料的）。

总之，目前对database容量极限（开始影响读取速度的极限）不了解，还是会避免进行巨量页面的集合。将来如果证实神奇的Notion在此方面并无障碍，可能尝试根据学科来汇总人物的子prop。

---

因为本套结构其实还没有彻底完善，有可能将来还会回来修改。所以把思路写出来，主要是为了让大家了解其中的一些尝试和取舍，同时也更容易发现我没主意到的问题，作出符合自己需要的取舍和改进。

下一篇应该是整个系列最后一篇。

本章主要分享相对（超级）简单的网页剪藏。原本是打算把上图整个资料库分两部分介绍完，结果写到第二部分的时候发现第二部分真的太庞大了……所以这一部分就独立出来，不作为资料库的一个局部，而作为剪藏来介绍。

我所参考的基本都是现成网页剪藏服务——如Instapaper, Pocket等等——所共有的基础功能。

模块介绍

通常情况下，转发剪藏后，page的原始状态是：标题为网页被分享后会显示的标题；网址将储存在链接属性的prop里（如果像我一样有多个链接属性的prop，在剪藏时可以手动选择要录入的位置）；被转录的内容（包含图文）会存储在页面里。有时候，内容会延迟一段时间才录入完毕，总之只要是能转录的，迟早都会自动提取好，所以不用管它。

一点经验&优缺点

我浏览网页使用的是ios原生safari，因此剪藏方式都是直接分享网页到剪藏板db。Chrome据说有很好的插件可以使用。MacOS的Safari还没找到剪藏的办法。至于其他系统的，就需要自己去摸索，不过我猜都是大同小异。

优点：

1. 阅读时可以随意编辑、标记文本。这在其他专业剪藏软件里，可能是付费版的功能，而且仅仅只能涂高光和做笔记。编辑，甚至插入什么相关资料，你想都不要想……
2. 页面互联的优势不用多提了。
3. 能够自由地重组和梳理资料，而不用像在其他软件里一样，受困于简陋的分类方式（文件夹和标签）。
4. 真正意义上的“剪报”，即使原文消失或被更改，都不影响已经剪藏的内容。当然，有的软件（比如Instapaper）也能做到这一点。

瑕疵：

1. 会有大约一成（或者更少）的网站，无法直接剪藏。这意味着，剪藏后只会转录标题和链接，内容是空的。我一般是定期处理这类的剪藏（反正有链接），挨个将原文本复制过来。
2. safari转发到Notion的话，无法默认目标db。就是说，或许你每次要发送网页到剪藏板的时候，都得重新定位到目标剪藏板。Chrome插件则不存在这个问题。我（用safari）在最初的几个月内也是不存在这个问题的，但是这两个月开始必须每次重新选择。目前还不知道症结所在。
3. 之前发现过一次（严格来说，只有一篇文章出现过此状况），带图片的内容转存之后，在手机端无法显示图片（提示提取失败），但是电脑端显示正常。询问过大佬，说是某些网站图片的源的问题。给出的方案是自己挨个把图存下来，重新上传。有（ji）点（qi）麻烦，不过后来也没再遇到过类似的情况，就没在意了。如果真的很重要的东西（比如某些随时会消失的资料……），费点劲存图也不是啥事。

---

差不多这样。

在用Notion之前，都在用豆瓣记录看过的书籍电影。其实现在豆瓣的移动端做得挺好的，ui设计得有模有样，各种形式的统计也层出不穷。唯一致命的就是审查，他们不得不随意关评的条目，不得不隐藏的内容。就跟嫌弃百度云一样，你把它当做数据库用，结果说没就没，存了个寂寞。

所以在熟悉Notion用法之后，果断搬家了。

本文和已经发布、即将发布的系列tips一样，都是进阶的、内容简洁的轻型分享，重点分享思路，不特别做基础知识普及。对notion不熟的人，如果对本用法有兴趣，需要自行搜索入门教程进行补习（推荐大佬177的视频教程）。

用途简述

平时读书的时候，总喜欢记录版本、阅读起止日期，回顾一下前一阶段读了多少书、都是哪些作者的书；还有多少翻开了没看完的书等等……

这些在Notion都得到了满足，更吊的是，它能有无限的方式为你的需求作出精确分类。

本分享涉及内容较上一篇多，可能有点长。

p. s. 本blog的菜单里有分享我的书库，随时来玩~

模块介绍

为了满足前面所提到的诸多功能，只用一个database是不够的，还需要原始database的诸多副本。所以原始database在以下简称为元database。

元Database：原始书库

因为副本众多，我以功能将它们分散在两个页面里，一个页面用来收集所有已读的书目，以及所有登记过的书目（包括未读的）；另一个页面用来给所有在读、未读的书目分类。

阅读进度有两种方式可以测算：

1. 如果你以阅读电子书为主，那么就有条件直接输入当前的百分比。（此时进度prop是Number属性）
2. 当你阅读的载体多样，就需要用到算法prop。为了能够计算阅读进度，两个number属性的property是不可少的：一个表示整本书的总量，一个表示当前进度。你可以选择以页码为参数，也可以kindle的位置作为参数，等等。

第二种方式的算法参考：

if(ceil(prop(“已完成”) / prop(“总量”) * 100) > 100, “error”, if(ceil(prop(“已完成”) / prop(“总量”) * 100) == 0, “🕒”, if(ceil(prop(“已完成”) / prop(“总量”) * 100) <= 5, “■ ” + slice(format(round(prop(“已完成”) / prop(“总量”) * 100)), 0, 4) + “%”, slice(“■■■■■■■■■■”, 0, round(prop(“已完成”) / prop(“总量”) * 10)) + ” ” + slice(format(round(prop(“已完成”) / prop(“总量”) * 100)), 0, 4) + “%”)))

待读书目Database

海量的副本来了= =+ 应该可以看出来我是个分类狂魔……

在这个db中，我通过3个层级对书目进行了分类：

1. 区分“计划要读”和“单纯的mark”
2. 在“计划要读”的内容中，区分“正在读”、“排队中”、“搁置”
3. 基于上述两大类的“文体方面”的分类

上述几个方面都是直接用filter分流（第一层）之后，以单选prop（状态prop与文体prop）来区分的。
想这么搞的请注意，因为每一层内的副本必须包含更高层级的filter，建议先设置第一层的filter，然后再以各自的副本创建第二层的副本，再以第二层副本生成第三层的副本，这样会自动复制已经设好的filter，就不用每个副本都重新设置了（挨个弄会疯的）。

截图中有一个模块的标题中均显示“🔆”，这个相当于我手动设置的“置顶”，用以标记需要优先阅读的书籍。
这个模块需要在上述filter的基础上，增加一个“标题里含有🔆”的条件。

已读书目Database

这个模块就简单很多，年度阅读时直接按照年份来显示，底下的归档是方便进行整个库的索引，保留默认设置就行。

关于按照年份来显示内容，有两个方案：

1. 直接从“完成阅读的prop（Date）”里读取年份，通过filter来实现
这种方案可以通过给副本创建不同视图来显示历年阅读记录。但弊端在于，如果你的date数据包含起止两个日期、且两个日期分属不同的年份的时候，会重复统计。可能有算法可以优化这个问题，需要研究。

2. 通过单选prop来录入年份
我就是使用这个方法，建立了一个记录完成阅读的年份的单选prop，然后直接基于这个prop来区分内容。弊端是如果你已经记录了阅读起止时间，就相当于得多记录一个重复的数据。

书单Database

先解释一下这个书单的逻辑。书单和书库联动，只需要将书目添加至相应的书单里，就能得到一个随着你的阅读完成度自动更新进度的书单。（菜单栏中同样有分享。）

从db名称可以看出来，这是新的db，它关联了书库db，并通过roll up显示了有必要的内容，为算法提供数据。

书单db的核心元素有：
书单名称、关联db（与书库关联）、roll up（统计已完成的数量）
此外我还添加了：
deadline（Date）、书单所包含的书籍总数（roll up）

关于统计完成百分比的Roll up如何选择：
用一个Prop.来将一本书标记为已完成的方案有很多，以下是两种思路：

1. “已读”复选框：
读完了就打个勾，统计已打勾的数量。从思路上最简便的方式，但如果你在书库里已经有统计阅读进度的prop，就相当于需要多操作一步。

2. 通过评分（或类似的）prop是否空白，来识别一本书是否读完：
我使用的就是这种方式，不需要进行多余的标记。但它涉及记录时的顺序问题，你需要确保在读完一本书之后才填写该prop，否则会造成数据失实；
这个方式的弊端在于，当有些书你再也不打算继续读并且想要给个差评的时候，它也会被识别成已读，因而无法与那些真正读完了的书籍作出区分。

关于视图选择

主要是想谈谈mark的书籍的视图选择。个人认为列表（List）视图的显示效率最高，同时视觉上最简洁。

据我观察，“买书如山倒”的心态一样投射在mark书籍上，甚至因为不占地方也不费钱，比买书的增长速度还快。mark的书多了，拖延得久了，自然就忘记了当初为什么mark。在List视图上，选择显示“mark的原因”这个property，应该可以在将来找书读的时候提高效率。

衍生

权限问题

如果想要公开自己的阅读记录给别人看，那么这个元db放在什么位置，需要斟酌。
元db开放权限是所有分享行为的前提。Notion的权限是自下而上的，也就是，如果你的元db没有开放权限，访客就无法读取它的副本和内页；其次，如果是想选择性公开内容、而将隐藏的内容放在元db的话，即便元db不在页面上，访客一样可以通过db标题的箭头访问到你的元db。
所以，建议将元db用作子模块来展示（比如阶段阅读、推荐书籍等等模块），设置好filter之后，将页面上锁，再创建一个副本放在后台，将副本作为替代的元db来展示全部的内容。

与论文资料摘录db关联

如果读过上一篇关于用Notion搭建论文文摘库的分享，那么这一篇的db其实也可以与上一篇的db建立relation，读论著的时候也可以将素材整合进那个db里。

用Notion断断续续已经一年了，自从半年前和几个朋友买了团队版之后，就开始密集使用，过程中逐渐演化出了许多用法，从打卡库，到基于打卡库的各种清单，到自动识别阶段的任务列表，到网页的剪藏……有些自己觉得很实用的用法想要总结，虽然写在WP，分享的效率差不多是0。但是在找到其它合适的分享地方之前，先发在这。

本文和之后有可能发布的系列tips都是进阶的，内容简洁的轻型分享，重点分享思路，不作任何基础知识普及。对notion不熟的人，如果对本用法有兴趣，需要自行搜索入门教程进行补习（推荐大佬177的视频教程）。

用途简述

正好最近在构思一篇论文，要阅读大量文献。我是一个不喜欢阅读过后整理笔记的人，但是无论是小说还是论著，阅读过程中确实会有一些值得标记的内容。所以一直苦于没有一个合适的方式和载体，去整合这些的内容，直到我发现下面的方式。

这个方式中，前期花费少量的时间，便可以将长期以来阅读过的文献中有可能有用的资料进行有效整合，以关键词（或议题）、出处等方式，随时进行索引，也能够使用database自带的搜索功能搜索特定的名词以提取所有相关内容。以上仅仅是它至少能满足的要求，diy的力量是无敌的。但是单单是以上的方式，就很适合学术研究的初期积累了。

可能它适用于某类人却不适用于其他人，所以只能期待它能给你一点启发拉~

模块介绍

衍生 & Tips

这种方式的退阶版还适用于灵感素材的收集。不少活跃在上世纪的作家，会习惯随身带一个“卡片盒”，记录随时随地的灵感什么的。这差不多和文摘是同一种功能。

一个小Tip：

当同一部著作（即同一个来源）里需要摘录的内容很多时，可以单独建立一个视图，在Filter里设置好引用来源和其他相同的信息（比如：如果大部分摘录，都会有某个相同的标签的话），然后直接在这个视图里进行条目添加，每个页面就会自带filter里设置好的条件，不需要再逐个编辑了。

刚才本来还想到什么类似的用法，忘了……回头再补吧。