- 因为文件夹体系，文档是最小的粒度单位，而logseq下，block是最小的粒度单位
- block向上可以基于标签（文档标签、tag标签）汇总，并且可以通过查询语法与搜索，快速的定位同汇总
更进一步，可以看Roam的白皮书： https://roamresearch.com/#/app/help/page/dZ72V0Ig6
3 个赞
文件夹体系没有意义，但我不是说分类学研究没有意义。对知识的分类学研究应该后置进行，而不是在输入知识时就给它划定分类，而且像如果有个分类可以囊括所有知识这时候还真的就把所有知识都划到这个超级分类上？对知识的分类研究我觉得最好就是新建个page进行研究，而不是建立文件夹体系或者标签,这样也有利于研究者主动梳理知识、归纳总结、进行专业的分类学研究等。
要不要进行分类，如何分类？这件事还真可以深挖专业知识进行研究。
1 个赞
其实对于一个如果说特别对于文件和文件夹有那种细节要求的时候(类似于所有东西都必须通过自己来指定)的人来说，存在文件夹分层是好的，这里在下的拙见并不是说logseq这种方式不好，应为有全局搜索的功能以及标签，所以分级和分层的需求是可以变相通过这两种方式来补充的，而且个人认为文件记录的跨度一定不会只有一个文件夹(类似于java这个域就涉及的区域特别广泛)，不可能只通过一个文件夹就把这个笔记定义死了。个人认为tag+搜索要比文件夹树要强大很多，纯个人结合自己经历发言，每个人的使用场景不同，勿怼，感谢
思源已经全部开源了 
还是建议有，连幕布这种上一代产品都有，要不然单个文档过于臃肿必然影响加载、查询效率
1 个赞
赞成，仔细思考现在的双链软件，很多都有点过于强调双链而忽略了分类的作用了，在笔记量达到一定程度的时候，图谱就会变成一团乱麻，除了一时的观赏，其他作用并不大，相反作用更大的是页面图谱，也就是和当前页相关的节点组成的图。
一款软件做的怎么样，一方面是软件开发水平与效率，另一方面是开发团队对PKM的思考与理解了。
目前观察RemNote既有双链又有文件夹体系，在设计架构上的水平是比较高的，但是RemNote的开发迭代速度和中文支持是比较薄弱的。
相比之下logseq在开发迭代速度上是不错的，可以保证新功能的不断生成和已有功能的改进，架构上还需要多打磨和借鉴才行。
使用logseq半年了，期待后续logseq和RemNote的不断发展
1 个赞
我不太清楚为什么 “文件夹系统 = 分类”, 因为文件夹系统只不过是一种多层级的表.
既然是表, 那可以使用 map of content (MOC) 代替, 它比文件夹系统更自由: 可添加描述, 无限层级. logseq 提供的 content 页就是来干这些事的. 唯一的的缺点是无法批量操作文件.
说到图谱, 自动生成的图谱是最无用的, 因为只能看到联系, 但不知道是什么联系, 完全不如出链和反链直观.
在我用过的所有的笔记软件中, 这方面做的最好的是 trilium. 它可以给页面之间添加关系. 同时也是无限层级做的最好的. 它用的是数据库, 而我更喜欢 md 
. 还有这方面功能的是 ob 的 juggl 插件, 此外思源画过这方面的饼 (我知道的).
此外, 单个文档臃肿导致的加载速度慢是因为 md 不是为 “块” 而生的, 至少不如思源的 json. 而软件加载慢是因为它每次加载时会为所有的块建立索引, 你文件多不代表块就少. 这本质上是 logseq 加载模式决定的, 完全采用数据库应该会有极大提升 (至少加载快了).
在目录里做好层级后，可以在反链面板里看到路径导航，但是文档内容很多就没办法很容易在页面看到，所以我会建议在如果父节点只有一个可以在页面顶部也显示路径导航，另外让侧边栏也能显示反链
我支持不要文件夹。
- 添加笔记的时候，如果有文件夹会有阻塞，会去思考这个笔记放到哪，而这个阻塞很致命。
- tag + 目录已经很够用了。
1 个赞
可以看出，社区对不支持的功能会下意识进行排斥拒绝 
，文件夹功能很好用，不爱思考放哪的你就随便放，反正几个带文件夹又有双链的软件都有全局搜索功能和tag。
2 个赞
个人不支持文件夹体系，并且我也不认为这是一个简单的"不想用的可以不用，想用的可以有"的事情。
目前的"目录"对我来说完全够用。由于我是新上手的用户，不知道目录功能是不是在这跨度八九个月的讨论中间更新出来的，以下只是对这个话题的一点想法。
- 文件夹系统可能会大幅度地改变现在存储数据的架构和检索方式
- 在块→md的基础上变成块→md(→当前路径→父路径|父路径下其它同级路径→…→库根路径)，整体变成文件系统的树形结构
- 目前以page和block为核心，也是一种"一切皆文件"和"一切皆文本"的做法，"文件"本身是可以参与双链的一种信息
- 但文件夹没有"文件"属性，它只是用来放文件的收纳盒，文件夹本身失去了可以被双链的信息
- 由于文件夹本身无法参与双链，变成强制按文件系统的树形组织文件，而不再是纯网状组织
- 会大幅度改变数据架构和检索方式，相当于修改产品的核心设计
- 受限于OS的文件系统（不同OS不同的文件系统又是另一个问题，产品线复杂化，运营维护和开发维护成本都升高）这种app外部硬性条件
- 有了文件夹，猜猜会不会有人又想要导入任意位置md文件的功能，变成要跨工作区跨盘区访问文件，需求复杂度和产品复杂度进一步攀升→产品核心定位开始模糊
- 据我观察在管理asset功能上的需求已经有这种倾向了，但这是另外一个话题（我个人是支持管好asset的）
- 也许作为用户我很少需要去考虑1000个文档怎么分类，但作为产品设计可能真的会有100000个页面如何存储、读取和检索的问题。
- 无数据库的情况下影响检索和加载速度
- 但加上数据库不利于轻量化便携式的信息管理，而开放和轻量正是logseq的特点
- 专有数据格式不利于二次开发中的解析和使用，需要额外的数据库接口
- 封闭的数据库引发信息管理主动权不在用户自己手中的疑虑
- 数据库同步困难，失去用户自行版本控制的意义，会过于依赖产品自己的同步功能
- 目前面向用户的"目录"和logseq自己维护的meta文件已经基本足够
- 这两种方式已经可以看作文本化的超轻量"数据库"
- 让用户不用去管如何在logseq目录下管理文件，而是专注在logseq软件中管理文件中包含的"信息"
- 层级式和树形是有必要（而且基础的）的信息管理方式
- namespace和目录都是为此存在的一种"软"方式（区别于文件夹这种文件系统的硬方式）
- namespace和page的title属性直接绑定导致页面名称过于繁琐这一点，确实有必要改进
以及从楼主另一个插件区的帖子来看。
也许楼主真正想要的，不是文件夹体系，而是层级结构管理方式？
比如举例的文学→古代文学→红楼梦，这是一种显著的层级式分类管理。
但大纲式笔记中的节点→子节点结构不正是层级式的吗？
因此我认为目前的目录功能已经够用的。举例我自己的目录：
“Soul Drain"下面打算用来放近来我看的书、文章、视频、影片的记录。
但"Soul Drain"本身不需要被双链，因此没有用双方括号做成页面，有点类似不能被双链也不需要双链仅用来分类的"文件夹”（这个谜一样的名字本身就是我不知道该怎么分类概括下面子节点的内容想出来的）。
但它依然能在相关页面最下以面包屑的形式参与显示。
再加上目录也以大纲形式呈现，本身的强层级式结构就已经满足文件夹体系分类的要求了。
而它和文件夹体系/文件夹系统的区别之处在于，您可以想象一本海纳百川的巨大书本，或者一座图书馆，使用手写的索引卡来整理其中的信息。
信息的分类取决于在使用者的脑中所在的层级，而不是取决于要找的信息在物理上处于第几章节或者第几个书架上。
一开始就不定义分类，而是让使用者自己去整理分类，我觉得是logseq相较于有文件夹的大型软件记录压力更低的原因——可以分类，也可以不分类；即使不分类，日期天然地已经是一种索引，从而同时免去记录因不分类而丢失的焦虑。
但诸如搜索页面、搜索关键词、悬浮显示页面时不能显示结果页面的面包屑（搜索功能现在其实能部分体现信息的层级结构），这大概属于一些增强功能，也许插件能解决（或者直接做进功能中），个人认为还没有上升到探讨是否需要文件夹体系这个程度。
所以比起"为什么没有xx体系"，"想要在xx地方显示yy信息"可能是更具有可操作性的需求。
3 个赞
我觉得可以， 做成插件的话就既满足需要的人也满足不想要的人，自由度更高
2 个赞