这倒是一个很好的例子，值得借鉴的是 GitHub Pages 各个模版中的标签功能。
文件夹 或许是因为 操作系统需要。
TODO 的存在形式是文件，但它是为链接服务的，它不承载其他功能。
而标签则是承载了一定的信息归纳总结抽象功能的。
这是基于它们两个的不同点的层次上来讲的“本质上”的不同。
这也是我不喜欢嵌套标签的一点，它看似是更高级的标签，但破坏了它抽象功能本该有的唯一性，引入了父子标签的依附关系。
再往上刨根问底就该研究哲学了。
在我看来做笔记是为了信息的整理，引入 Markdown 是为了降低排版对内容的影响，引入标签和链接功能也是服务于信息整理这个目标的。
如果文件夹、标签、链接不能帮助一个人更好的整理信息/笔记，那么就只有两种可能：要么是这个人的方法有问题，要么是这个功能有问题。要想改善就只有两条路可以走：改变思想和方法、改变工具和功能。
嘿，是的，操作系统需要管理文件，可是这不一定要被展示给所有用户。它可以被屏蔽起来，就像是很多其他的具体实现一样。文件夹很多时候并不就是指真正的文件夹，说是像目录一样的树状结构或许会更为贴切。
链接可以承载信息归纳总结抽象的功能，虽然貌似传统上不会去这样使用它。比如一篇关于烹饪的笔记，使用一个“烹饪”的标签，和使用一个“烹饪”的链接，其实是一样的。任何的标签都可以被替换为链接，即使当然这可能会比直接使用标签更为困难。然而，所被需要的或许仅仅只是一个插件。
我正在尝试对我自己的笔记这么做。
我更倾向于直接联系用链接，间接联系用标签。
比如 Emacs、Vim、Neovim、VSCode 都是编辑器，那么就可以链接到编辑器这个文件；它们互为竞品，则也可以建立链接；同时它们都支持多个操作系统，那么就使用标签：Linux、macOS、Windows。
文件越多，链接和标签对信息的整理能力越强。
Obsidian 本来就不是自由软件，再在此之上依赖插件更不自由，反而不如简单的双链和标签，反而可以随时跑路。
（接4楼）
谁是中心
文件夹->文件、标签->文件的关系：
- 文件夹与文件是层级关系
- 标签与文件也是层级关系
文件夹和标签都是突出了自己的上层中心地位，弱化了处于下层的文件本身。
而连接与文件的关系是，以每个文件为中心，通过连接辅助每个文件去扩展。
连接可以让每一个文件成为中心，文件在网络中的价值在于拓展了多少有意义的连接——这个才是我认为连接带来的最大变革
物理世界很难以文件（单个本体）作为中心去管理。
举例说明：比如一双袜子，你只能放在一个衣柜的某一个角落下（文件夹），袜子上有标签包含它的成分，产地等信息。但是，我们对这双袜子的用途，只是收藏它，知道它是用什么制作，产地是哪里吗？我们更希望的是这双袜子可以搭配什么鞋子，什么衣服，穿出我们喜欢的风格。如果你将每一种搭配记录下来，你也不会将搭配方案保存在衣柜里。你或者会写在一个纸质笔记本子上。这样，你花一些精力可以记录很多搭配方案。但你记在本子上的搭配方案，更可能是以场合，季节等为出发点（中心）去记录。以一双袜子为出发点去记录搭配方案值得吗，那我是不是也要以每一双鞋子，每一条裙子去记录搭配方案？但有些时候，我们就是想知道这双袜子可以多少种搭配，适合哪些场合。
计算机的出现，双链的出现，突破了这个物理限制，让我们以文件（单个本体）为中心去管理成为可能。借助双链概念，以及计算机的强大能力，每一个文件（单个本体）都可以成为中心，而成本几乎没有什么增加，设置忽略不计。
我们要转变过去以文件夹，标签作为中心的管理方法，改为以文件为中心去设计我们的组织管理方式（有“去中心化”那味）
（未完待续）
嵌套标签在我看来是对标签本身的抽象
比如有两篇文章各打上了“蔬菜”和“水果”的标签，当你想要提取“食物”主题的相关内容，你就要同时选中“蔬菜”和“水果”这两个标签才能把相应的文章都提取出来，但若采用了“食物”这级的抽象嵌套，就可以大大提高效率
这方面的应用我认为印象笔记做的较好（虽然我已没用它了，广告是真心多，即便是会员），你可以只选中当前标签或者选择中当前标签及其子标签；而且标签的结构可以随意调整
上面的例子比较简单，但是说白了都是在解决“内容”多了后如何处理更有效率的事情
汝之蜜糖，吾之砒霜。
我更愿意对两篇文章分别用食物 蔬菜、食物 水果而不是食物/蔬菜、食物/水果。
每个人习惯和见解不同，找到最适合自己的工作流就好了。
知识管理有四个步骤
知识获取、知识保存、知识整理、知识输出！
ob库的管理，更应该是去考虑如何更好的输出！如何更好的提取自己记的笔记。
所以：这个结构可以在心中建立，使用一个文章记录这个结构，在调整的时候，只改这个文章就可以了。在搜索的时候，就可以直接查找对应的 食物 蔬菜 水果 就可以了
1 个赞
我也受不了嵌套标签。我对于不同层次的标签也是像你这么处理的，分成两个就好。
选择对自己心智负担最小的方案就是对自己的最优解。
我觉得双链是 URL 针对本地文件的特化，所以很快就能接受并使用起来。
但是嵌套标签、块编辑这种东西于我实在难以接受，就好像我要吃猪蹄别人却问我是要吃猪左蹄还是猪右蹄一样难受。
1 个赞
所以我才没拿 obsidian 举例子，因为它的这种处理方式非常反直觉（我在 obsidian 中也没这样用）
相对较好的方式是标签的嵌套仅用于内容提取而不是内容中
比如原有“水果”“蔬菜”的标签还是原样，仅是在标签管理器中进行了“食物”的上级嵌套，这样使用起来就方便太多了；不用给内容打上大类的标签（这样可以少打好多标签），然而却可以很方便的调用大类标签（可以快速选择一个集合，而不是一大堆标签中一个个挑出需要的标签）
另，一个标签的上级抽象可以是多种多样的，即一个标签应该可以被作为多个标签的子标签，这样标签管理起来才方便易用
2 个赞
我也分享一下我的理解：
探究“ 文件夹，标签，与双向链接”，会涉及到文件（例如ob中就是md文件）。
如果不考虑比较高级的文件夹操作（例如Linux中），且假设大部分人不会复制文档的快捷方式，对于win和mac上普通使用者而言，一个文件只能归于一个文件夹中，一个文件夹中可以存放多个文件，文件和文件夹的关系是“多对一”。因为更偏向定量的描述，例如落山鸡的obsidian教程。
而文件和标签的关系，则是“多对多”的关系，文件可以归于多个标签，一个标签下也能有多个文件。因为更偏向定性的表述，例如图片、教程、视频、知识管理、obsidian、落山鸡。当然，教程还有其他种类，知识管理也有另外的延伸，这些都是可以在文件间扩展和关联的。
双向链接和标签类似，甚至可以完全替换它的功能，但标签不能替换双链。因为双链在整理文件的同时，会提供一些上下文的消息，具体的案例可以见ob的中文教程，或者一些成熟的双链文档。例如，在某个双链页面[[AAA]]里写到：[[BBB]]的方法很好，[[CCC]]的方法很差。这是无法使用标签#AAA来实现的。
双链的鼠标悬停预览可以当作卡片/词典来使用，前提是写好摘要。
双链的跳转是 URL 的本地化，跟标签完全不是一个路数，不存在谁替代谁。
如果非要二选一，我选择标签，人类语言的创造本就是从给事物贴标签（多对多映射）开始的。
上面所有的这些说法，都还在讨论关于具体实现的事情。这本身没有问题，因为看起来这将是更加实用的东西，可是好像很多人仍然对于我的看法存在误解。我说过：
我所说的创建快捷方式放在不同路径下指的是软件直接支持，或者通过插件支持。而且既然有了文件夹文件，也一定可以有标签文件。就算全部做成白板的样式，实际上还是内容地图。如果说文件夹和标签是从不同的角度去描述文件，那么其实本来标签的用法就不固定，可以有几类不同用处的标签。比如对于代办事项，描述其完成状态及任务内容，明显就相差甚远。
这样的意思我也有表达过：
要说标签就比文件夹更自由，那只不过是软件对于标签的支持更好。软件是如何管理文件的，细节未必就要暴露给用户。有的软件就是可以在目录般的树状结构里重复地在不同路径下放置同一篇笔记。
在这个回复之后，我不再在该帖子下做相关的发言。
所谓所追求的结果不一定就是要被理解，大家在一起交流心得，本身就是一件很美妙的事情。我也祝愿大家都能找到适合自己的方式，不要受到复杂与混乱的困扰。
我觉得搜索的功能应该是最大的。
标签可以看做基于关键字的的搜索；双链也是特殊的关键字，只不过将搜索结果用数据库存储起来以便于找到关联。
文件夹只能表示内容的一个方面（归类），也是本地笔记app的必须（notion应该不是用的文件夹，而是数据库）。
组织方式的服务对象
特定的应用场景。比如，我想每天 review 当天做过的任务，写的新笔记。这时无论用文件夹，标签，或者连接的哪一种组织方式，只要能用，都是 OK 的：
- 文件夹：以每天日期创建一个文件夹，所有今天创建的文件都放在下面
- 标签：以每天日期作为标签，当天创建的文件都加当天的标签
- 连接：以每天日期创建一个日志文件，当天创建的其他文件都连接到日志文件上
如果只是围绕每天 review 这个场景，对我来说1，2，3 都是 OK 的。黑猫白猫，抓到老鼠就是好猫。
未来的应用场景。但有一天，我打算按周来 review，这三种方式是否有足够的灵活性来面对新增的需求？
- 文件夹：我在日期文件夹上再加一层周文件夹，但我查找文件的时候就要点多一层
- 标签：我新建周标签，然后回到每一个文件里面加周的标签
- 连接：我新建周志文件，然后将文件都拉到周志里
方式 1 动了所有文件的存放位置，方式 2 动了所有文件（加标签），方式 3 只动了新的周志文件，因此从灵活性来说：3 > 2 > 1
在 Obsidian 有 Dataview 插件，方式3连拉的动作都省了，只需要掌握 dataview query，敲几句简单的代码，就可以全部自动显示在周志文件上。Dataview 插件是 Obsidian 里的黑魔法。
我们之所以纠结组织方式，是为了未来的应用场景。我们希望组织方式能够足够的灵活来应对未来不断增长的需求。
最低成本试错
因为未来有什么应用场景，我们现在也不知道。我们暂时用了一种组织方式，但后来发现不适合未来的应用场景，这会造成什么影响？
-
文件夹：从文件的角度出发，一个文件只能存放在一个文件夹之下，对文件夹有很强的依附性。且这个文件所能发生联系的，也只局限于同个文件夹下的其他文件。当有一天，我们认为这个文件夹所代表的分类不再适用，要删除时。那这个文件夹下的文件的命运有这几种：
- 找到可以归到新分类下的一个文件夹
- 没找到合适的分类，临时放到根目录下，等待分配
- 随原文件夹一起被删除
除此之外，如果不是所有文件都归到一个新文件夹下，它们还失去了跟原来同文件夹下与其他文件的联系。
-
标签：给文件加上各种可能标签，文件对标签没有文件夹那么大的依附性，即使有一天这个文件其中一个标签不再适用，删除了，这个文件也没有到重新找安身之所的窘境。但是这个文件失去的是与也有带这个标签的其他文件的联系。
-
连接：通常我们认为两个文件有一定的相关性，才会为它们添加连接。比如，给文件 A 连接到文件 B, C, D。有天我们发现 A 与 B 的连接不再合适，删除这个连接，那 A 只是失去这个当前认为不合适的连接而已。A 与 C, D 的连接没有任何变化。即使有一天，我们认为 A 不再适合存在了，我们在删 A 的时候，也可以通过连接快速找到 B, C, D，判断是否有影响，再为 B, C, D 因失去 A 造成的损失做相应的补偿处理。
从成本的角度，1 > 2 > 3 。连接降低了我们因组织方式错误不适合未来场景的成本。
2 个赞