Notion进阶之【大瀑布】(1/2)

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

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

用途简介

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

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

核心板块

如左图所示,本资料库涉及4个核心Database:
1. 人物;
2. 组织与团体;
3. 世界史瀑布流;
4. 国家史。

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


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

人物板块

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

人物Database互联关系图

构成概述

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

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

人物DB内部的“希特勒”页面。
核心Prop有:中文译名(根prop)、原文名、籍贯(古属、今属)、领域、生卒年、曾加入的团体、有一定影响的历史事件。
其中,籍贯和历史事件都是单向引用(text属性),团体为relation的结果显示。

年龄算法参考:

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

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

人物独立的作品表Database。
“贝多芬”的这个DB的核心Prop有:作品名称(根prop)、创作年份、创作背景与时代背景。
其中,除了作品名称以外,所有的元素都是与下面这个DB——“贝多芬大事记”——互联的结果。年份是relation的直接显示,再通过rollup显示相对应的生平和时代背景。
此外可选的prop有作品号、学习状态等等,只要能想到的,都可以按需增减。

人物独立的大事记Database。算是两个子db中更为主要的一个,可以很直观地显示人物在每个阶段经历的事件及产出的作品。
核心prop有:年份(根prop)、生平事件、时代背景事件、作品和相关资料。
其中,作品是与上面的DB(“作品表”)互联的呈现,相关资料是与“剪报”db的互联呈现(以摘取平时读到的相关资料)。

一点思路&未决问题

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

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

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

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

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

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


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

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

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

您正在使用您的 WordPress.com 账号评论。 注销 /  更改 )

Google photo

您正在使用您的 Google 账号评论。 注销 /  更改 )

Twitter picture

您正在使用您的 Twitter 账号评论。 注销 /  更改 )

Facebook photo

您正在使用您的 Facebook 账号评论。 注销 /  更改 )

Connecting to %s