2024w32

附件

我不爱用图片,但并不是不喜欢用图片表达,我只是不喜欢处理附件。相较于小尺寸的文本内容,各种附件简直是巨大的麻烦。但,这个问题好像有点回避不过去。开始思考怎么管理附件。

但如果叫附件,就会默认它们是笔记的附属品,依附笔记而存在。

是么?有一部分是的,比如一些笔记的插图,就是为了说明某一个特定问题的细节而存在的;某些配置文件,就是为了指定特定的工具的状态而存在的。当然,还有一部分是可以独立存在的内容。

如果,扩大一下来理解,这些都是文件,包括笔记,也是文件。那是不是我可以用一套文件管理方法来管理这一切呢。如果能将方法论统一,意味着管理规则的简化。

道理上,如果是记录一切的笔记,整体达到几个 GB 也一点都不奇怪。但如果真的到了这个大小,就得考虑一下同步问题了。虽然从长期的角度看,未来的网络速度下,几个 GB 的数据应该也只是小问题。

常见的处理方法是将笔记和附件分开,但我觉得同属于笔记,似乎还是放在一起更加符合我的直觉。但同步肯定是个问题。我觉得也许可以将它们放在一起,但是使用不同的同步策略。这肯定是可以做到的,但复杂度是不是我愿意接受的呢?

如果将附件放入笔记同名文件夹并和笔记同目录呢?是很合理,但是附件和笔记不是一体的,排序时文件夹和文件也是分开的,而且因为附件分散于各个目录,也不利于统一管理。但是附件远离笔记也会有很多问题。

而且一篇笔记可能引用多个附件,而一个附件也可能被多个笔记引用。Obsidian 可以处理第一种关系,但是对第二种关系却比较忽视。

归根结底——是人类对于描述和理解立体网状结构的无力感,但知识(相互间的引用关系)终究不是用一维或者或者二维可以清晰描述的。

如果说,我遇到的问题应该都不是新鲜问题,那我该参考什么呢……对了,网页中资源文件的处理方式。然后我开始理解:

  • 图片(附件)和笔记并不是相同地位的
  • 固然有一些图片能独立表达一个内容,基本可以看做卡片盒中的一张卡片,但多数图片可能还是到不了这一级别
  • 多数图片是被单次引用的,所以并不需要太重视对于图片的入链

思考了一大圈,结果一切又回到了最普通最常见的使用方法。对外的表现是几乎什么都没变化,但是我自己对这件事情的纠结减少了许多。

©2022~2024 稻米鼠. Last build at 2024-10-12 00:00:34