希望反向链接可以使用标签进行分类。

希望反向链接可以用标签进行分类显示。
我的流程大量使用到嵌入,并且标题都是时间戳,查看反向链接的时候,根本不知道链接了个什么。
如果能显示页面的标签,并且通过标签进行分类,可以更快的弄懂链接了什么地方。

1 个赞

或许可以把显示上下文打开。

如果是用的zettlekasten,那就需要考虑使用更有描述性标题,比如20220419-xxxxx

上下文一方面是双换行后,显示起来就需要点击上下按钮进行显示,另一方面则是我是嵌入,因此只有文件的时间戳数字。
我的流程里将所有的文件名都变成时间戳,通过别名的方式进行检索使用。
这样的好处就在于同名不同义的概念或者实体不会混淆。

同名不同义这个完全可以参考主题语言的词义控制相关方法,不一定需要采取时间戳这种比较丧失语义性的方式。比如

1 个赞

不过我个人还是比较好奇你是怎么仅通过时间戳来使用50w的笔记的,有可能的话希望在经验分享板块开个帖子说说自己的工作流,这样开发者也比较容易结合你详细的工作流发现你的本质需求,进而做出改进 :grinning:

其实也很简单。
无论哪个笔记,块引用都无法在图谱里显示,因此我直接把一个文件当作块。
如此一来,不仅在图谱里显示了,块的归属位置就独立了。


要构建大段内容就多个“块”嵌入。
通过这种嵌入,加上目录类型的文件就能构建树状结构。


比如我做阅读笔记。
将所有的段落拆分成单个文件。
将这些文件嵌入在另一个文件里,将这个文件添加章节标签。
同理,书籍可以引用章节文件作为目录列表。
对引文做笔记可以直接创建新文件,将原文和笔记文件都嵌入进去。
如此一来,进入原文,可以从反向链接去到章节页面或者笔记页面。
同时,存放了原文和笔记页面的笔记还可以集中到一个文件里作为其他用处。


不过,使用这种方法需要把嵌入的标题给display:none,如此在导出PDF或者使用插件导出HTML就可以去掉讨厌的标题。


这种流程目前还在探索中,对于存放嵌入内容的文件需要精心构建一种类结构。
比如,日常记录的结构比较松散,放什么都可以,线性的堆下去即可。
引用的内容就需要构建树状结构的节点链接。
多种结构混合在一起,在图谱里也会显示。
不过,图谱这方面我并没有太多考虑,所以怎么使用还没想好。


这种流程对于反向链接功能的需求还是挺强的,但是obsidian在这方面比较弱,我只能暂时用DataView来写一些代码来实现自己要检索的内容。
但,终归还是比较麻烦。


文件之所以多,一方面是因为所有段落都被拆分成块,还有一方面是作为目录或者文章的这种方式嵌入代码的容器文件不少。
目前,我的库文件还没到达50W的量级,但是像自己这么不加节制的增加文件,担心有一天到了这个量级,软件跑不动了。
所以,用代码拆分了三四本网络小说,并且设计了树状结构之后进行了测试。

1 个赞

了解了,和我的工作流是相似的。不过我的工作流不是以段落为单位拆分笔记,而是以主题为单位拆分笔记。简单的说就是讲述相同内容的段落,无论是否来自当前文章,都会被我聚合到某篇笔记中。这样一方面可以大幅度减少笔记数量,也能精确的检索笔记:因为主题的存在,我可以直接使用规范化的主题语言对笔记进行命名,这样我在其他地方链接笔记的时候就可以通过更有意义的符号来精确引用自己所需的内容,同时软件也能在反向链接面板中推荐更多潜在的链接。同时,标题又能进一步借助主题语言的词义结构,构建知识图谱,发挥图谱的作用。

目前我比较烦恼的点在于,反链和出链面板的潜在链接不能筛选(或者分类),有时候给我推了很多无意义的潜在链接…

实际上,我也曾经想过使用主题进行聚合。
但是经过一段时间的测试,以及考虑到单个文件可能会原来越大,因此放弃了这个方式。
另外,你说的规范化主题语言检索我也曾经尝试过,但是让我放弃的原因是codeing。
我个人会开发一下工具给自己用,但是写下来最烦的就是变量命名。
模块多了之后就更烦了,于是我干脆就直接使用a、b、c这些无意义的内容命名,然后在函数里进行注释就可以了。
这样写了一段时间后,我突然领悟到其实文件的名字真的无所谓,重要的是实实在在的内容。
尤其是写面向对象,在写代码之前就要做抽象,可以说烦得要死,所以我就更加厌恶抽象。


目前,反向链接做的最好的就是roam research,不过还是不够好。
obsidian我是想自己开发一个自己用的插件,但是开发文档实在是看得有点迷糊,也不想反反复复的测试。
还是懒的233