同意标签树完全被引用标签代替。代替方法是提供标签转引用功能，让使用标签用户转移出来，然后逐渐增强引用标签体系。

还有我需要一个类似标签的彻底删除这个引用标签的功能：删除逻辑是，是动态描文本引用中可以完全删除，是静态描文本就删除引用保留文本文字。

有了数据库标签功能我都已经用不上了，只是用在memos导入的时候那边的标签会被带进来，把标签和块引弄在一起是个很好的想法，非常支持。

目前的标签只能在搜索时作为一种筛选条件，并不好用（尤其是搜索不好用，显得标签更没用了），支持讨论与重构

标签在思源中是时候过时的了（笑

我希望所有的标签全都能变为双链，包括但不限于标签、书签、database的单选、多选。

这里的问题是
如何找到一个文章里所有的标签
你删了标签功能 后面就没法达成这个功能了啊!

这里的问题是
如何找到一个文章里所有的标签
你删了标签功能 后面就没法达成这个功能了啊!

不是说没有标签功能了，而是形式不一样，相当于在目前标签的基础上拓展更多功能，原来的标签还是在的。

我希望所有的标签全都能变为双链，包括但不限于标签、书签、database的单选、多选。

赞同。目前的标签、书签，的确不太好用。

支持重构，有了双链这个超集，再另外搞一套标签没什么意义他

补充一篇文章：双向链接时代的快速无压记录 - 语雀

不太认同块引可替代标签的方案。块引本质为对一个信息块的引用，但当仅需要对一个信息块打标时，为了创建这个标签而创建一个page作为块引，反而违反了奥卡姆剃刀原则。
展开来说，双链块引首先是一个块，作用在于更简洁，快速的链接两块信息，而标签则是概括，可以是一块内容的概况，可以是一个page的概括，也可以对应信息的延伸锚点，在搜索的使用场景下，块引是无法替代标签的（为了实现搜索的场景而强行丰富块引的功能复杂度有点舍本逐末了），因此个人认为市面上主流的双链笔记软件中将标签与双链混为一谈反而是错误的方案。
如果想要将双链当做标签来使用，现在的功能即是支持的，为何还要将现有的标签去掉呢

不太认同块引可替代标签的方案不太认同块引可替代标签的方案

不存在替代，而是为标签增加双链特性

为了创建这个标签而创建一个page作为块引

感觉说反了。现在是希望在引用时不需要先创建一个 page ，直接使用标签就能达到与块引相同的效果，但目前的标签仅能作为搜索的筛选条件，没有块引的双链功能，所以才要将「标签」升级为「具有双链功能的标签」，如果将标签本身升级为一个可以被引用的文档，那就不需要先创建一个 page 再去引用，直接打标签就好了。

这样，标签不仅能被用于搜索，还能汇总所有被打上同样标签的块。

在搜索的使用场景下，块引是无法替代标签的

并不需要用块引替代标签，块引是块引，标签是标签。不是将标签改为块引，而是给标签增加块引的双链特性

如果想要将双链当做标签来使用，现在的功能即是支持的，为何还要将现有的标签去掉呢

正是因为标签不好用，才会衍生出将双链当做标签的用法，而这种用法又比单纯使用标签更为曲折（需要创建一个 page），所以改进标签功能才是解决问题的根本办法。

况且，即使改进了标签的功能也并不影响其他用户，改进后的标签功能应该是现有功能的超集

目前的标签的确是缺乏功能性了，剩下在段落块中可能会使用一下而已，其实有很多改进方法的，例如

• 将标签视为新数据库的原生查询条件之一，可以稍微解决以前遗留的标签问题，也可以让标签稍微有点用处
• 或者像改成tana note 的超级标签功能，将标签视为传递到一个集合当中，基于此其实可以将标签做成快速传递到新数据库的功能，将标签集合与新数据库功能结合其实也是一个更多维度的筛选与查询，例如可以直观的看见建立时间或是修改时间，甚至在这个集合中可以再次使用数据库当中的其他功能
• 又或是像上面说的类logseq与remnote那般将#标签也用于双链建立一个页面，但我觉得这个提案比较没有意义，因为跟你在文档块前面打个#字号接着输入名称是一个意义，并没有带来什么改变

又或是像上面说的类logseq与remnote那般将#标签也用于双链建立一个页面，但我觉得这个提案比较没有意义，因为跟你在文档块前面打个#字号接着输入名称是一个意义，并没有带来什么改变

改变就是，过去打的标签有用武之地了，以及不需要为了双链而每次新增一个标签就要新建一个 page

标签树完全用文档树替代，标签功能用块引功能替代

@Achuan-2 你的这句话有歧义啊，大家都觉得你想完全移除标签功能

标签树完全用文档树替代，标签功能用块引功能替代

@Achuan-2 你的这句话有歧义啊，大家都觉得你想完全移除标签功能

说了可以保留标签树了

我不觉得可以取代标签 请给出实际的用法！！

我不觉得可以取代标签 请给出实际的用法！！

不是取代标签，是增强标签。原来的用法还在，是增加新的用法

我不觉得可以取代标签 请给出实际的用法！！

我的想法是创建标签、管理标签功能都和之前一样，但是标签底层实际上是块引，标签树底层实际上是文档树，文档树的层级代表标签层级。想要改进的原因主要是标签功能用处有限，双链对文档的管理功能缺失，两者合并，可以增强标签和双链的功能

有了数据库标签功能我都已经用不上了，只是用在memos导入的时候那边的标签会被带进来，把标签和块引弄在一起是个很好的想法，非常支持。

我不使用memos。看到这点产生了疑问：
有的用户用memos，或者其它什么导入功能，需要在导入的时候保留原文章中的标签，现在的思源，还有相关插件挂件是怎么处理的？把#标签/标签文字改成#标签/标签#文字吗？

或者换个方向想，现在思源导入含有大量井号#的笔记/剪藏，会把这些内容都认作标签吗？有用户需要这种功能吗？

如果有这样的功能、想保留对这种功能的支持，那在我看来现有的标签体系就不能和块引挂钩。因为这显然会引入大量不确定性，导入的标签全部自动生成块引文档，如果一篇文章标签，或者井号特别多怎么办。
思源和logseq、ob在块引上一个很大的不同是，思源里块引用必须要指向一个具体存在的块，如果没有就得新建一个；而logseq、ob可以引用一个不存在的文档，所以它们不存在“导入的标签全部自动生成块引文档”的问题，但思源就得面对。

导入的标签全部自动生成块引文档

我倾向于保留标签文档树的方案，这样就不会在文档树里生成一堆文档

思源里块引用必须要指向一个具体存在的块，如果没有就得新建一个

不过标签并不是块引（只需要指向一个标签 id 就可以了），不需要及时创建，完全可以在用户点击标签的时候才创建标签文档

打开标签文档，底部能显示那些文档引用了此标签，与现在的反链区别开（参考logseq，见sheep的分享）

还有就是一楼的这点，原贴说实话有点误导没用过logseq的人……这其实是页面属性的写法，就是properties:: 关键词这样的形式，想怎么写都行。具体见 https://limboy.me/posts/logseq/ 的 Properties 一节。
比如这样的写法：

safari:: macOS
safari:: [[macOS]]
safari:: #macOS

都可以。

导入的标签全部自动生成块引文档

我倾向于保留标签文档树的方案，这样就不会在文档树里生成一堆文档

你是说生成的文档只能在标签树面板里查看，不能在文档树面板里看到？

我的Memos就当随笔用不到十个标签所以改了也没影响，我觉得在文档树应该要支持设置标签文档新建的位置，然后在标签树删了要有对应提示(会将标签文档同步删除)，对应的标签文档也要有额外标识与普通文档区分

导入的标签全部自动生成块引文档

我倾向于保留标签文档树的方案，这样就不会在文档树里生成一堆文档

你是说生成的文档只能在标签树面板里查看，不能在文档树面板里看到？

是的，在现有标签功能上增强，而不是去掉标签树。

与其改文档树（要区分标签文档和普通文档，可能会引入很多 BUG），不如只改标签树

与其改文档树（要区分标签文档和普通文档，可能会引入很多 BUG），不如只改标签树

想想也可以，不会超出现有对标签的认知，就是我如果我想管理标签文档的时候需要多一步打开进去管理，如果在文档树有一份可以直接右击名称管理，然后定位打开的文档这个功能需要加上自动把标签文档跳转到标签树里，不知道会不会有实现难度。

假设现在思源没有标签树面板和标签功能，重新开始设计，我觉得可以直接合并到文档树里，多一个无法删除的标签文件夹，然后用# 创建的标签自动在这下面创建文档，标签文档不能移出这个文件夹外面，这样也能区分是标签文档，也不用引入额外文档属性，软件做限制就行，这样标签文档就归入文档树一起管理了。个人感觉如果要重构合并到文档树里面合适点，因为实际上是个带标签功能的文档。

感觉用块引代替标签的想法和改进方案还不成熟（因为我没用过logseq等其他软件），另一方面，目前我认为用数据库来代替标签貌似更好用，目前也正在实践中，暂时先关闭这个issue了。有其他想法的朋友可以再建立一个issue。

导入的标签全部自动生成块引文档

我倾向于保留标签文档树的方案，这样就不会在文档树里生成一堆文档

你是说生成的文档只能在标签树面板里查看，不能在文档树面板里看到？

是的，在现有标签功能上增强，而不是去掉标签树。

与其改文档树（要区分标签文档和普通文档，可能会引入很多 BUG），不如只改标签树

那按我的理解，这就是单纯给标签树功能加了个页面吧，离logseq那种标签还差得远，我感觉实用性很受限啊。
而且这个页面就只能是“一种特殊的文档块”了，不能转换成标题块。
要不你提几个使用场景？

导入的标签全部自动生成块引文档

我倾向于保留标签文档树的方案，这样就不会在文档树里生成一堆文档

你是说生成的文档只能在标签树面板里查看，不能在文档树面板里看到？

是的，在现有标签功能上增强，而不是去掉标签树。
与其改文档树（要区分标签文档和普通文档，可能会引入很多 BUG），不如只改标签树

那按我的理解，这就是单纯给标签树功能加了个页面吧，离logseq那种标签还差得远，我感觉实用性很受限啊。 而且这个页面就只能是“一种特殊的文档块”了，不能转换成标题块。 要不你提几个使用场景？

我是觉得传递型双链必须要建一个文档非常麻烦，要是能用标签来传递就好了。

我个人是希望标签能用来汇总，而不只是搜索。

导入的标签全部自动生成块引文档

我倾向于保留标签文档树的方案，这样就不会在文档树里生成一堆文档

你是说生成的文档只能在标签树面板里查看，不能在文档树面板里看到？

是的，在现有标签功能上增强，而不是去掉标签树。
与其改文档树（要区分标签文档和普通文档，可能会引入很多 BUG），不如只改标签树

那按我的理解，这就是单纯给标签树功能加了个页面吧，离logseq那种标签还差得远，我感觉实用性很受限啊。 而且这个页面就只能是“一种特殊的文档块”了，不能转换成标题块。 要不你提几个使用场景？

我是觉得传递型双链必须要建一个文档非常麻烦，要是能用标签来传递就好了。

我个人是希望标签能用来汇总，而不只是搜索。

那你这个用sql筛选能解决吗？我对obsidian比较熟悉，用标签筛选这个dataview完全能做到。sql应该也能做到吧，筛选出含某些双链&标签的块。

那你这个用sql筛选能解决吗？我对obsidian比较熟悉，用标签筛选这个dataview完全能做到。sql应该也能做到吧，筛选出含某些双链&标签的块。

SQL 做不了，只能通过文档的反链面板实现（反链可以直接编辑块、拖拽块）

感觉用块引代替标签的想法和改进方案还不成熟（因为我没用过logseq等其他软件），另一方面，目前我认为用数据库来代替标签貌似更好用，目前也正在实践中，暂时先关闭这个issue了。有其他想法的朋友可以再建立一个issue。

我创建了一个 issue ：#11025