在Logseq中，信息组织涉及page、block和namespace三个概念，再结合daily note的工作流，相信很多用户会纠结于什么时候用page，block或namespace。本文谈谈我的看法。首先，它们的含义如下：page：就是传统的一篇文档，有title，有正文block：page中的段落，以-开头，page的基本组成单位namespace：在page的标题中使用/构建的page的父子关系，比如读书是读书/炒股的智慧的父page共同点它们的相同点：Logseq是大纲笔记，这三个概念都是在构建大纲。page其实就是其一级block的父block，内容就是page titlenamespace是在构建page和page之间的大纲关系，只不过散落在不同文件中，丢失了顺序（page中的block，block的子block都有顺序）如果进一步思考：库名，就是所有笔记的根节点，所以，Logseq库是一个存在根节点的有向树结构。page和block两个典型使用方法如下。第一种方式：为主题建立page，内容写在page中第二种方式：为主题建立page，但主题作为daily note中的一个节点，然后把主题内容放到子节点中。这两个方式，相信各有一批用户，估计也有不少人纠结用哪种方式。单纯从大纲组织上讲，没有任何区别。不同点1、graph view中，只有page的引用关系，没有block的引用这是根本区别，如果你希望两个概念构建关系，并能在graph view中查看，则必须为两个概念创建page，并在page中进行引用。我在强调必须在page中引用，继续基于前面提到的两种方式来讨论。第一种方式，读书/炒股的智慧和股票技术分析及其心理成因在graph view会形成连接，但第二种方式，则是孤立节点，没有连接。如下图所示。第二种方式，虽然graph view中没有连接，但在读书/炒股的智慧页面下，可以局部查看自身及子节点引用过的page。就是Linked References的Filter功能，如下图：我个人期待未来graph view中能提供一个开关，允许用户将Filter中的页面与当前页面的关系，展示在graph view中。2、所有标记语法只在block上有效换句话说，block既承载内容，又支持用缩进组织内容。page和namespace本质上只是组织内容，毕竟page和namespace的title能承载的信息量非常少。特别讲下任务，你只能将block设置为todo而不能将page设置为todo，如果需要把page设为todo，需要建一个todo的block再引用page。3、namespace的子节点没有顺序page下的block、block下的子block都有顺序，但namespace的子节点没有顺序。所以，namespace不适合有逻辑递进关系的内容组织。比如读书的章节笔记，不太推荐读书/炒股的智慧/第一章这种形式。小结我对Query的使用不深入，尚不清楚page和block在Query层面有没有显著差异，以我对Logseq数据结构的理解，猜测不会有太大区别。关于page和block的选择，我将所有的笔记都放在daily note的block中，按时间线组织，block会打上page标签，然后在子节点中丰富内容，一般不到page中去写东西。相应的，我也很少用graph view，而是为每个感兴趣的领域维护一个MOC（Map of Content），再embed到Contents目录中。我的Contents目录结构如下。相关阅读Obsidian和Logseq对比
用了2年Obsidian，Logseq以前也知道并试用过，当时只有web版，稳定性差就没关注了。不久前看了Randy Lu关于Logseq的视频分享，被吸引到了，于是试用了2周。这期间只用Logseq，没用Obsidian。现在，想基于经验分析下二者的功能差异及未来的可能的迭代方向。需要说明的是，这不是一个教程，但如果你正在试用这两个软件，并在犹豫选择哪一个，本文或许能提供一些视角。这两个软件共同主打的特点是：本地存储+文本文件。这对在意数据安全、数据可迁移性的用户（比如我）来讲，非常有吸引力。它们的核心差异点有两个：Logseq强制使用大纲视图，Obsidian是自由格式的markdown文档Logseq没有文件夹结构，Obsidian有文件夹结构。一、首先讲讲自由格式与强制大纲带来的影响Logseq强制使用大纲视图，其实就是block优先，先有block，然后block组成page，并且block还有层级的关系。Obsidian自由格式，就是page优先，当它想去支持block的时候，只能从段落出发，每一段是个block，段落间当然也没有层级关系。（官方文档介绍：前后有空行包围的东西就是block）。从通用性来讲，Obsidian的自由格式，其实兼容Logseq大纲视图。网上有很多人分享二者共用一个库的方案，无一例外的都是以Logseq库为准，然后让Obsidian去兼容Logseq，充分佐证了这一点。以block为例，前方讲Obsidian的block是基于段落的，但大纲带也是支持的，如下图所示。Obsidian大纲中的反向链接相比Logseq的block，Obsidian的block有两个问题：Logseq能直接在反向引用中编辑和操作（比如点击链接）内容，Obsidian则必须跳转到原文档才能编辑和操作。Logseq的#标签和``引用，都是作用于块的属性，通过query能直接查询到块，Obsidian通用dataview的query只能查询到page。尤其是第2条，对task的管理非常重要。事实上，Obsidian的dataview社区已经在计划实现相关功能了。再看看Logseq，因为是强制大纲，所以不适合写长文，有趣的是，Logseq社区呼声第二高的Feature Request就是支持长文写作。这个帖子对Logseq应该如何处理长文block给出的建议，就是Obsidian基于段落的方案。按照这个畅想，Logseq支持定义page的类型，一类是大纲视图page，一类是长文视图page。长远来看，Obsidian在自由格式上支持更友好的block是顺理成章的事，但Logseq在现有强约束的情况下去支持自由格式的长文，需要打破框架。不清楚Logseq团队是否会考虑支持长文（目前roadmap中还看不到），但这确实是我无法放弃Obsidian唯一的原因。我个人比较期待二者最后殊途同归，Obsidian更好的支持block，Logseq打破框架支持长文写作。二、再谈谈文件夹支持这一点，同样体现了Obsidian对Logseq的兼容。至于哪个更好，这个见仁见智，我倾向于Logseq简化文件夹的方式，减轻分类的压力。Logseq的页面支持namespace层级，可以实现类似文件夹的功能。但需要注意，这是非常定制化的能力，离开了Logseq这样的关系就丢失了，所以，如果考虑数据的可迁移性，这个功能应该慎重使用。三、我最终的选择我希望在笔记软件中写长文，Logseq无法完全替代Obsidian，虽然Obsidian的大纲能力比Logseq弱但也完全够用，所以本着少折腾的原则，继续使用Obsidian。但在使用习惯上，会把Obsidian中的daily note大纲化。哪天Logseq支持长文了，会考虑迁移。也许那一天，Obsidian的block能力也能与Logseq并驾齐驱了。最后，本文使用Obsidian写成。相关阅读Logseq中page、block和namespace的用法