我们需要重新审视块引用并提出其方法论

本文还在创作中,目前展示的是阶段性成果。期待大家的讨论。

首先,我们要明确块(block)的概念。我具体不清楚这概念的源头为何,如何发展。但目前块的特征就是“行”,类似于Notion中的块。

其次,应该认识到,块引用的概念不存在于卢曼笔记和zk笔记。卢曼本人使用的是纸质材料,无电子化的可能,所以当时不可能存在块,不存在块引用。后续zk笔记,特征为以zettrl等zk软件作为实践,这些软件也并没有存在块的概念。

Ryooo评论:由于我们是从印刷载体时代进入网络载体时代时代,所以虽然现在“信息”包括了网络的碎片化信息,但是信息的组织仍然是以文献组织方法(分类与主题)为主。但是这种文献组织方法对于普通人来说组织成本又太高了,不是谁都有这种前置知识,能把分类法主题法用得明明白白。那就民间造一个“block”概念,主要靠链接管理,降低一下大家的组织成本,毕竟大家也不是得自己造一个图书馆。

7 个赞

个人建议是抛弃块的概念, 纠结它是啥没用, 关键要看它能干啥.
在我看来, 块的用处就是两个, 块引用和块嵌入. 所以重点不在于块是什么, 而在于认识到它就是一个给对某些内容的引用和嵌入服务的东西.
但目前块的存在严重限制了这两项功能, 因为它被规定为引用和嵌入的最小粒度. 比如我想引用某一段落A之中的某四个字B, 对不起不允许, 要么进行整块引用, 要么把它单独成块.
再看看其它软件是怎么处理的, 比如OneNote, 它允许对任意被划选的内容设置索引链接, 还是上例, 它允许我划选A之中的B, 然后复制指向B的链接, 接着可以将这个链接赋给任意其它文字, 比如另一段落C. 然后当我点击C的时候就能跳转到B, 跳转之后还可以便捷地返回C. OneNote的缺陷是只能通过跳转的方式来比较笨拙地实现引用功能, 没有obsidian的浮窗显示与嵌入, 但其中并没有所谓的块的限制, 你划选什么, 什么就是块.
事实证明, 引用功能完全可以在不需要块的概念的情况下实现, 所以obsidian目前的块引用机制完全就是在自我设限. 为了适配这个块引用, 我现在行文被迫全用列表, 毕竟如果不用列表那就得每段前后各空一行, 还不如列表瞅着顺眼.
目前英文论坛里也有一些人呼吁细化到支持行一级的引用, 但其实都不如OneNote的方案一步到位, 你想对什么做引用或嵌套, 就划选什么, 然后软件负责给你生成相应部分的索引链接, 这样不就好了么, 不需要顾及划选内容成不成块. 而且这是一个非常基础的思路, 就连word里都有相应的雏形(插入链接-本文档中的位置).
我不知道在markdown编辑器上这么做是比较有难度还是怎样, 如果可以, 先开发行引用过渡一下也好, 毕竟obsidian目前的块引用实在是难用, 它是在强迫用户改变自己的笔记结构, 否则就几乎用不了引用和嵌入功能.

1 个赞

我这里可能是更偏向学术向的呼吁,即是从概念入手,成体系论述。因为如果有一个事物存在,可以去论述。同时我也观察到目前,块引用的使用者群体中,对于块的认识存在相互之间的误解。 既然用块的人那么多,应该有人期待一个关于块的系统性讨论。
当然,日常使用中,可以不用去分辨。

呃, 块不就是被引用和嵌入的最小粒度么, 块应该没有什么其它用途了吧.
所以块就是一个僵化死板的文本框选范围, 不成块就无法被引用和嵌套. 这个好像也没有太多值得讨论的东西吧, 个人感觉值得讨论的是引用和嵌入功能本身, 以及块的存在的合理性.

我首先就有几个个问题:

  • notion、RoamResearch、思源(?我没用,但有看到)、ob对块的定义都不同,那么你所说的块,在技术上是怎样的,是怎样的客观存在,形式上是怎样,功能上是怎样的?
  • 块的概念最早由谁提出,这些软件之间是如何继承和发展这一概念?
  • 除了笔记软件之外,在更广泛的范围内,这概念是否也存在。即笔记软件是否借鉴了其他软件关于块的概念?

关于这个定义,也有2个问题:

  • 如果一个软件被引用和被嵌入的粒度不同,那么块是指其中的哪个?
  • 块就是最小粒度的同义词吗?

对于第一个问题, 假如一个软件被引用和被嵌入的最小粒度不同, 那就得把引用和嵌入分开讨论, 引用的块和嵌入的块不再是同一概念. 你分别叫它们阿猫阿狗都行, 被引用的最小粒度叫阿猫, 被嵌入的最小粒度叫阿狗, 反正本质就是两套限制死了的文本范围.
对于第二个问题, 块不是最小粒度的同义词, 而是能被引用和嵌入的最小粒度, 起码在obsidian里是这样. 脱离引用和嵌套, 谈块毫无意义, 块的引入就是为了服务于引用和嵌套的. 我总感觉你是想脱离引用和嵌套给块找点什么存在的意义…
而且我更欣赏onenote那种实现引用的方式, 你想引用什么, 就划选什么, 什么就是块, 这种情况下的最小粒度是一个字符, 此时任意多个字符都可以成块, 当然这个时候块的概念就可以直接消失了, 因为已经达到了极限, 在文档编辑的过程中, 已经没有比单个字符还小的单位了. 至于其它各软件的块, 本质上都是对若干字符的不同封装, 形式可以不同, 比如是固定封装一行还是固定封装一段, 但本质都是一样的, 块说白了不就是某种限定的文本范围么.

其实很容易实现你所谓的onenote的引用方式,静态网页中有text fragment,ob把这移植过来就好了。本质还是一个静态页面的搜索,类似于标签这样,只不过是唯一标签。

我是希望obsidian能做到集引用, 嵌入, 跳转于一身, 就在当前的索引地址的基础上改进一下即可, 这些功能本身也不相互冲突, 都是连携的.
现在obsidian的问题就是限制了这些功能的最小单位. 还是那个例子, 我就想引用一段话里的一个字, obsidian就是不允许, 要么你把整段全引用了, 要么你把这个字单独弄成一段.
也不知道是不是markdown编辑器有什么限制, 这个东西感觉在技术上应该没什么难度才对, 都能给一段文字添加索引地址了, 难道不能支持一下给任意文字添加索引地址么. 比如"一段文字 ^testindex", 这种是给整个块添加索引. 那完全也可以开发一个语法, 专门给被选中的文字添加索引, 比如"(段文) &testindex".

1 个赞

你可能没搞懂我的意思,甚至连我提到的关键词都没搜索一下。

查了一下, text fragment是基于谷歌内核浏览器的网页定位技术, 所以你的意思是我在obsidian里能通过这种语法实现对任意文字的引用嵌入与跳转?
请问我怎么引用这个单一的啊字?


我该往哪加#:~:text=, 直接加索引后面不好使.

我也这么考虑过,也是前一段时间使用Logseq的感受。

像Logseq这样的基于块的编辑工具,有如下几个优势:

  1. Live Preview,编辑完一个Block后就立即显示,大大缩短了原来 编辑-预览-修改 的循环
  2. 基于块的链接,颗粒度更小,而且支持块的嵌入,一次编辑多处使用。嵌入功能提供了非常多的可能性
  3. 基于块的严格和清晰的层次结构,逼着自己把要写的东西各段的逻辑关系理清楚,是上下级关系还是并列关系?
  4. 因为块的颗粒小,所以可以随时写点东西(一个可大可小的块),之后再进行组合就是了。用Obsidian这样的工具是“自顶向下”,先有文章然后写内容;而用Logseq这样的工具,可以很容易实现“自下而上”,随时随手写点什么,对记录零碎的想法非常有优势。也有利于克服拖延症。

其核心,大概也是题主所想讨论的,使用这样的基于块的编辑工具,和使用当前Obsidian的区别。我觉得用Logseq时,其实不是直接在写文章,而是将要写的内容拆分成树状结构,然后写各个块。和直接写文章的思路完全不同。使用Logseq,写的时候比较爽,可以完全只关注内容的层次结构和当前编辑的块,之后再考虑转化成文章,进而输出成各种格式。简言之:

  • 使用文章编辑软件,如Obsidian,流程是 写文章-输出成各种格式
  • 使用Logseq这种块编辑工具,流程是 写内容-转成文章-输出成各种格式

我没有用过Roam Research。

用了一段时间之后,发现Logseq的问题有:

  1. 思维负担太重,过多的考虑块的结构–理论上可以无限深的层次,容易迷失
  2. 写的内容和输出之间的距离太远,有标题表示的层次关系还好,无标题的层次关系和文章的呈现完全对不上(如果没有标题,多段文章本身是线性的),所以如果确定要写一系列相关文章,或写一本书,还是Obsidian这样的工具更自然,更接近最终输出(只有格式区别)
  3. Logseq本身工具链的不成熟,特别是是我常用的Excalidraw插件bug太多,同时不支持Diagrams(drawio)
  4. 块结构的bullet表示和块内的bullet,实际使用中很容易混淆,也是思维负担

因为这些问题,后来发现Obsidian支持Live Preview后,就果断的切换回来了。如果要在Obsidian实现类似块的功能,其实有间接的办法,就是章节。唯一希望就是Obsidian目前Outline里拖动移动章节的操作不太顺手,希望以后能优化。

顺便说一下我目前的workflow(和本问题关系不大):

  1. 使用Obsidian写markdown
  2. 用自己写的脚本把markdown转成R markdown
  3. 基于R markdown使用blogdown输出成blog,或者用bookdown输出成pdf或gitbook

daryl,谢谢你的分享。我这里先讨论你回复中的一句话

用Obsidian这样的工具是“自顶向下”

摘要:我的观点是,obsidian是“自下而上”(bottom-up)软件。但需要注意的是我们常常讨论的“自下而上”(bottom-up)的概念似乎也有所偏差,一个Ahrens在《How to take smart notes》一书中阐述的概念,另一个是在RoamResearch出现后才出现的概念。

我猜测这里的“自顶向下”应该说的是“自上而下”(up-bottom),对应的另一个词是“自下而上”(bottom-up)。

就我个人的经历,我第一次接触这对概念是在Ahrens-2017-How to take smart notes一书中。我不清楚是否还有比这本书更早、并引起广泛讨论这两种知识组织的文献?如果有,欢迎大家分享。

这本书后面也被翻译成中文。因为中文版我没怎么做笔记,我这里还是以外本原版为参考。

“自下而上”(bottom-up)在该书出现3次(我检索的结果,可以见文后的检索结果),其中自下而上是用于形容slip-box,也就是卢曼的笔记系统。但都并没有提到块(block)这个概念。另外,全书中block也没有作为名词出现,仅仅作为动词(“block out”)出现了一次(在“9.3 Give Each Task the Right Kind of Attention”)。

而在该书成书的时候(2017年),卢曼的笔记系统的实现软件就是zk笔记软件(主要指在 Tools • Zettelkasten Method 罗列和讨论的),而obsidian可以算是zk笔记软件的最新形态,所以理应继承上述“自下而上”的评价。

“自下而上”(bottom-up)的检索结果

第1次在“6 Simplicity Is Paramount”一节。

The biggest advantage compared to a top-down storage system organised by topics is that the slip-box becomes more and more valuable the more it grows, instead of getting messy and confusing. From Ahrens-2017-How to take smart notes(下同)
与按主题组织的自上而下的存储系统相比,最大的优势是slip-box越长越有价值,而不是变得混乱不堪。(Deepl机翻,有能力请看原文,下同)

第2次在“9.3 Give Each Task the Right Kind of Attention”

We need a structure all the time, but as we work our way bottom-up, it is bound to change often. And whenever we need to update the structure, we need to take a step back, look at the big picture and change it accordingly.
我们一直需要一个结构,但随着我们自下而上的工作方式,它必然会经常改变。而每当我们需要更新结构时,我们需要退一步,看一看大局,并作出相应的改变。

最后一次在"10.2 Keep an Open Mind"一节中

Developing arguments and ideas bottom-up instead of top-down is the first and most important step to opening ourselves up for insight. We should be able to focus on the most insightful ideas we encounter and welcome the most surprising turns of events without jeopardizing our progress or, even better, because it brings our project forward.
自下而上而不是自上而下地发展论点和想法,是为洞察力开放自己的第一个也是最重要的步骤。我们应该能够专注于我们遇到的最有洞察力的想法,并欢迎最令人惊讶的事件转折,而不危及我们的进展,甚至更好,因为它使我们的项目向前推进。

多谢你,我自己没有那么关心学术方面,只是从自己使用的感受出发。

当然最理想的情况是基于块的组织,但现实中有交流需求和工具支持的问题。