双链笔记与标签结构探讨

本贴最后更新于 427 天前,其中的信息可能已经斗转星移

与备受推崇的网状笔记记录方法相反,我是结构化笔记记录的坚定支持者。在我看来,任何无规则的记录方式一定会带来混乱。本文也是以结构化的思想来探讨双链笔记结构与使用的。

双链笔记结构

双链笔记结构是“隐形”的树状结构

  在我看来,双链笔记并非是网状结构,起码并不是无序的网状结构。即使不使用文档层级,以块为单位看待,其也是有树状结构的。其结构看起来如下图所示,a​节点引用了 b1​节点,而 doc1​和 doc2​是两个不同的文档。

graph LR subgraph doc1 a-->a1 a-->a2 end subgraph doc2 b-->b1 b-->b2 end a-.->b1

  但是我认为这还不够结构化,双链笔记的实际结构应该如下图所示:

graph LR root-->a root-->b subgraph doc1 a-->a1 a-->a2 end subgraph doc2 b-->b1 b-->b2 end b1-->a_ref subgraph doc1的引用 a_ref-->a1_ref a_ref--->a2_ref end

  从形式的角度出发,所谓”双链“,就是链接和反向链接。对于链接来说,并不是新事物,其就是在文本上增加了一个跳转到另外位置的功能,即使没有这个功能,也不影响我们理解文本本身。问题的关键在于如何看待反向链接。我认为,反向链接本质上就是在被引用块上增加了一个”虚拟“的下级节点,而这个下级节点,就是引用其的块。如此一来,笔记就被完全结构化了,笔记系统中不存在”网“,而是以一种嵌套或“隐形”的方式呈现树状结构。

  从内容的角度出发,双链所表示的关系一定是双向的。”父“对应”子“;”A 原因是 B“对应”B 的结果或影响有 A“,”某题的解使用了某方法“对应”某方法的实例或应用有某题“…一个块一定既可以放在其本身的位置,又可以放在其所引用块的下级位置。

基于笔记结构探讨的引用使用方法

  由于我将笔记结构视为完全的树状结构,所以我越来越不倾向于直接引用概念名,而是引用其子级或者说其属性。

  • 例如:

    • 华为[[手机]]​实际上引用的 手机​下的 手机品牌
    • 设立地役权当事人要求[[登记]]的,可以向登记机构申请地役权登记;未经登记,不得对抗善意第三人。​引用的是 登记对抗主义​下的 登记对抗主义的体现或践行​。

  引用子级的结果是,我笔记中存在大量的”空标题“,即标题下并没有直接的内容,相关内容全部在反向链接中。如果能够再将反向链接的内容显示在正文中,就笔记结构来说,这对我来说就是一个完美的笔记软件了。

当然,我还是自己动手写了一个思源笔记的插件实现了该功能(etchnight/siyuanPlugin-backLinkInDoc: 思源笔记插件,将反链指向块显示在文档中 (github.com))。但是由于这个插件修改了编辑器内的 dom 元素,尽管采取了一些方式,我仍无法确认这是否会带来副作用,如触发修改文档本身内容的事件(而不仅仅是修改展示的结果),这个插件可能永远不会上架插件市场。

标签系统

标签是离散块的集合

  表面上看起来,标签系统可能是下图所示的结构:

graph LR subgraph 笔记 a-->a1 a-->a2 a1-->a11[a1.1] a1-->a12[a1.2] end subgraph 标签 b_标签-->b1_标签 b_标签-->b2_标签 end a-.->b1_标签 a11-.->b1_标签

  是不是感觉很熟悉,这似乎与引用没有什么区别,但问题是,标签和引用是两个独立的系统,所以无法将 a​节点放在 b1_标签​节点下。所以,在我看来,标签系统更倾向于属于下图所示的结构,其中用圆表示的节点是两个具有相同标签的块:

graph LR a((a))-->a1 a-->a2 a1-->a11((a1.1)) a1-->a12[a1.2]

  也就是说,我将标签系统视为与树状结构完全不同的一种维度,它仅仅是一种标识,用来表示当前节点与其它节点的不同之处。如果去除树状结构,仅标签系统的结构如下图所示。即所有节点都是游离的,它们之间不存在树状系统中”父子“关系与”兄弟“关系。

graph LR subgraph b1_标签 a((a)) a1.1((a1.1)) end subgraph b2_标签 c[(一些其他块)] end subgraph b_标签 d([一些其他块]) end b_标签-->b1_标签 b_标签-->b2_标签 a1 a2 a1.2

  ​image

  由此,标签的使用意义更多为筛选具有某些特征的块,这与引用有很大的不同,如前所述,引用是为了建立树状结构。

关于“筛选”和“建立树状结构”的不同,请想象有一颗巨大的苹果树,苹果树上有红苹果和青苹果。

当我们要数树上红苹果的数量时,并不在意其属于哪个树枝,仅在树下数就可以了;但是当我们爬上树摘苹果的时候,我们就不得不查看苹果在哪个大树枝上,需要分别经过哪些树枝才能摘到,有些时候,我们还可以直接从一个树枝跳到另外一个树枝上。

数苹果时,我们使用的是“筛选”,此时颜色是标签;摘苹果时,我们使用的是树状结构;跳跃时,我们使用的是引用,我们当然希望一个树枝可以“复制”到另外的树枝上,但是这在物理上是不可能的,所以“引用”也是隐式的。

标签的使用方法及与引用使用场景的区分

  • 发挥标签的筛选作用,标签可能的使用场景有很多,比如:

    • 表示待办、进行中等流程
    • 文档元数据分类:如修改时间、期刊名,固定的元数据甚至不仅表示分类还可以表示分类内容,如 类型/会议论文​。
    • 表示日期、地点:如 日期/2021/5/5​、地点/河南/郑州​,这么做好处是即能用 #地点/河南/郑州#​搜索,也可以用 #地点/河南​搜索。
    • 表示块所表示的“属性”:如概念、原因、特征,意义同“XXX 的概念是”

  标签的查询方法与搜索类似,甚至更多是与搜索结合,区别在于具有相对的固定性,而且可以排除无关内容,相对较为精确。

标签与引用使用1场景的区分

  由于标签本身和笔记的树状层级均是树状结构,所以容易混淆。基于上述讨论,使用标签还是引用的判断方法就比较明朗了:块是否需要或者可以作为拟引用内容的子级,如果是,则使用引用;所引内容是否基于筛选意义,如果是,则使用标签。

麦克斯韦方程组的概念是XXX​,这段内容显然不需要作为 概念​的子级,但是可能需要在 物理学​文件夹中筛选一下 概念​,使用标签。

如果探讨 概念和定义​的区别,则既可以作为 概念​的子级,也可以作为 定义​的子级,使用引用。

1903年12月17日,莱特兄弟首次试飞了世界上第一架飞机“飞行者一号”。

1903年12月17日​,标签,要写”历史上的今天-1903-12-17“的话,用标签汇总就好了。

莱特兄弟​,引用或直接放在 莱特兄弟​节点下,可以引用 莱特兄弟的生平​,相关兄弟节点可能还有 莱特兄弟的后世影响​等。

飞行者一号​,引用或直接放在 飞行者一号​节点下,可以引用 飞行者一号试飞​,相关兄弟节点可能还有 飞行者一号尺寸​、飞行者一号性能​等。

在西安建立都城的十三个王朝是:西周、秦、西汉、新、东汉(汉献帝)、西晋(愍帝)、前赵、前秦、后秦、西魏、北周、隋、唐。西安​,引用,甚至直接放在 在西安建都的王朝​下更合适。

我的XX工程建设项目,建设地址西安市灞桥区西安​,标签,如果放在 西安的工程建设项目​下,似乎跟未参与的 西安地铁建设​之类关系有点远。

总结

  说了这么多,无非就是下面的结构 🐶🐶

//引用-->对象
let block1= {
  content: "...",
  children: [],
};
let block2 = {
  content: "...",
  children: [],
};
let block3 = {
  content: "...",
  children: [block1, block2],
};
let block4 = {
  content: "...",
  children: [block1],
};
//标签-->数组
let tag_1_1 = [block1, block2];
let tag_1_2 = [block3, block4];
let tag_1 = [...tag_1_1, ...tag_1_2];


  1. 基于笔记结构探讨的引用使用方法

2 操作
dualwind 在 2023-09-17 01:25:09 更新了该帖
dualwind 在 2023-09-17 00:42:57 更新了该帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • 说明我表达能力不够 😂

  • 其他回帖
  • LoneFireBlossom 1 赞同

    为什么说是上位替代,因为比如用[[A]]来代替#A#之后,我可以在[[A]]的页面写关于这个标签的补充信息,这点是普通标签做不到的。

    比如 Tana 就为了解决这点提供了 SuperTag 的功能(当然 tana 不止这些)

  • Bard
    1. 的确多数没看懂,存在误会楼主的可能性,也是出于本能性的反对
    2. 我签名就是关于标签和双链的主要观点
    3. 对于 地点/河南/郑州 标签的形式中我记得似乎不能单独使用 郑州 吧,我感觉太限制使用了,所以我一直不认可 Markdown 的标签,尤其是在双链出现后
    4. 在我看来双链的优势在标签面前是全方位的,至今也没有找到什么关键场景是“标签可以,双链不可以”的关键场景,看楼上说的标签可以看到层级的优点连我说的第 4 条的缺陷都覆盖不了
    5. 像 RR 等不少笔记软件把双链和标签进行内在统一的方式,我觉得是更加明智,也指明了道路
    1 回复
  • Xiavi93 1 赞同

    标签解决的痛点是我找不到自己想找的笔记在哪(笔记入口),双链解决的痛点是看到一篇笔记后不知道哪些其他笔记与它相关。

    其实笔记入口这一点我认为更重要的是笔记或者文档的标题如何命名,而不是标签。用体系化或者结构化的命名就可以解决这一点了。

    1 回复
  • 查看全部回帖