|
|
##总结：打标签没啥用
打标签(tagging)过于随意和细碎会失去意义。既不能有效归纳，比如每次填的不一样(比如'KFC'和'肯德基')，系统不会自动认为是一类。也不能使得内容更利于查找。
tagging应该粗略些。应该预设一个比较固定的大类分类系统，然后每次新增笔记赋予大类即可。对应PARA Method中的Area。
## 讨论：分类系统的理想数据结构
关联可简单分2种：比如，TBP is written by LiuCixin; TBP is a sci-fi. 包含了一个著作和作者的关联,著作和文学类型的关联。
- 带名称的关联或带谓词的关联: 包含一个2个三要素的relation:('TBP','author','LiuCixin')，('TBP','genre','sci-fi')。这种等价于面向对象编程思想中的class attribute.
- 简单关联: 包含一个2个二要素的relation:('TBP','LiuCixin'),('TBP','sci-fi')。'author','genre'等这样的谓词信息丢失了。
### 总结：分类系统的理想数据结构形态应该是带谓词连接的有向图(DAG with named relations)
如果分类是DAG结构而不是简单的list，就需要笔记软件实现类似面向对象编程(OOP)中的继承(inheritance)和多重继承(multi inheritance)。可惜目前没有笔记软件能实现，包括anytype，估计是没必要搞这么复杂。
## 讨论：常见的内容组织架构
### tree-like
树形, 文件夹/目录形式的，是有向的，线性的，有层次的(hierarchical,linear)。比如windows文件系统，OneNote,印象笔记,Notion,Wikipedia。
### graph-like/flatten
比树更自由的形态，任意2个节点之间都可以有关联，是非线性的，扁平的(flat,non-linear)。比如RoamEdit,logseq,obsidian,TiddlyWiki等双向链接笔记。
### table-like
表格，二维矩阵。比如airtable,excel,pandas.Dataframe等工具
*以上举例的软件不完全对应每种结构，比如Notion也可以打tag,Obsidian文件架构就是文件系统。*
## 总结：表格是Obsidian的一大硬伤
在我的应用实践中，表格是非常重要的。无法用其他类型的数据代替。比如财务报表，时间序列。我认为对于涉及到数字统计场景时，表格才是更直观的，更精炼的，更有效的数据格式。
然而obsidian并没有很好的支持。obsidian一般用来构建基于Zettelkasten卡片盒笔记法之类的扁平知识节点网络，似乎更合适人文社科。
## 总结：flatten/graph-like不能完全代替tree-like
（以下简称tree和flatten) 使用时，应该兼顾两者形态的内容结构，tree和flatten相结合
tree是一种二次创作，一般是二次归纳或整合临时的内容节点，比较合适形成指导性的教程/手册/说明书，增强可读性，有序性。
flatten是首次创作，内容形态比较原始，没时间整理也可以一直放着不管。
总之，flatten更为原始和本质。tree是一时人为的偏好，有可能随着时间推移当时的tree层次结构不再适用，就需要调整。
不断地添加新的内容节点算是“增熵”，tree化算是一种"减熵"，两种行为孰多孰少看笔记使用者的心情。 |
|
发表于 2023-4-19 16:13:53