反向链接 如何 区分链接到主题和链接到子节点

疑问解答
1

如题，在反向链接里，没有办法 区分链接到主题和链接到子标题以及链接到文件里的块
所有链接都是一样的重要程度
如 [[主题]] [[主题|标题1]]
这些都是一样的重要程度

2

简单结论是, 能区分 “链接到主题 vs 链接到子节点”,
但是很难拿自带反链面板把这信息表示清楚, 理由是, 元数据利用起来不那么方便, 以及反链面板不好轻易修改


元数据方面, 控制台查 app.metadataCache.resolvedLinks 可以看到, 实际上 Ob 解析出来的笔记之间互链计数, 它没考虑链接到小标题和 block-id 等细节

image
image1117×568 47.5 KB

而另一个携带了链接小标题和别名的元数据 app.metadataCache.getLinks(), 它不是专门按 “笔记名字” 来汇总的

难搞的另一个原因是, Ob 自带面板似乎是没法自由扩展的, 很难补充新信息进去


所以回到这需求, 本质还是 “为符合条件的笔记做精细统计”,
其中, 条件是当前笔记的反链笔记,
精细统计的是链接过来的次数, 链接过来的具体指向位置

目前个人觉得, 还是用 dv 合适干这事


```dataviewjs
const noteName = dv.current().file.name;
const allLinks = await dv.current().file.inlinks;
let info = [];
allLinks.forEach(async link => {
    if (link.path.split('/').pop().slice(0, -3) === noteName) { 
	    return; 
	}
    const linkMetadata = app.metadataCache.getLinks()[link.path];
    // 从 content 里统计
    // 命中 [[currentPageName]] 的次数
    // 命中 [[currentPageName#sub]] 
    // 命中 [[currentPageName#^blockid]] 的次数
    const link2fullnote = linkMetadata.filter(l => l.link.endsWith('.md') ? l.link.slice(0, -3) === noteName : l.link === noteName).length;
    const link2anchor = linkMetadata.filter(l => l.link.startsWith(noteName+'#')).length;
    const link2blockid = linkMetadata.filter(l => l.link.startsWith(noteName+'#^')).length;
    info.push([
	    link, 
	    link2fullnote+link2anchor,
	    link2fullnote,
	    link2anchor-link2blockid,
	    link2blockid,
    ])
});
info.sort((a, b) => b[1] - a[1]);
// 输出结果
dv.table(['反链笔记', '链接总次数', '链接到完整笔记', '链接到heading', '链接到blockid'], info)

```

效果如下 (文件路径细节挺复杂的, 可能有没考虑到的地方)

image
image1401×525 68.4 KB

具体怎么排序, 那就看需要了

2 个赞
3

大佬有心了！
感觉ob作为双链软件，似乎对链接并不是很上心
链接没做区分，内容移动链接也容易断，官方的移动内容插件在移动内容的时候也不维护链接

4

我其实也没搞明白这些链接细节, 如果以后弄懂一点了, 我再回来补充吧


感觉ob作为双链软件，似乎对链接并不是很上心

回到楼主具体这个评论, 我觉得自己能跟楼主在一些问题上有共识, 包括:

  • 链接到笔记自身或小标题, 蕴含着不同信息, 某些场景里其中的区别是有意义的
  • 链接移动时最好足够健壮, 能智能应对意外局面, 出问题了及时报警, 要做到别让用户操作时心有疑虑
  • 笔记重组功能应该给个预览, 让用户能事先看到将要发生什么

以上这些, 都是一个好软件应该做到的


但是从另一方面考虑:

如果官方真把 “链接到笔记自身, 小标题, 块id” 拿三种符号表达出来, 把这认知成本直接甩给广泛用户, 这是否真能被人好评, 我其实是怀疑的

而这个链接的设计以及对复杂场景的乏力, 则依然是几个经典 “权衡” 的结果:

  • 数据搁在强格式约束的数据库里 vs 数据搁在半结构化 md 里
  • 解读数据依赖外界规范 (schema) vs 数据是自明的 (自我描述的)
  • 所有修改都由软件自身操持 vs 笔记是公开的, 可同时被外界工具协助修改

事实上 Obsidian 在所有取舍中, 都选了后者

对于链接也是, Obsidian 就不想让用户有 “链接 id” 的概念, 就希望 “笔记名叫啥, 链接就叫啥” 这么简单用起来

  • 链接尽量要: 简单好懂, 易创建, 易协同修改, 对用户的错误书写宽容
  • 与此同时, 牺牲了链接的: 抗变动的稳定性, 搭建高级链接结构的潜力

这算是替 Ob 的 “缺陷” 辩护吗?
嗯, 一部分算吧,
另一部分的目的是, 说明这种设计的优势, 我们好尽量设法利用这些优势,
至于劣势, 我自然也是同意楼主的


官方的移动内容插件在移动内容的时候也不维护链接

我拿几个笔记相互链接到各自的 笔记自身, 小标题, 外加另一个旁观者笔记链接到所有的小标题, 然后以官方的 “笔记重组” 试了试各种重组, 简单场景下似乎还挺智能的, 没出啥乱子

但如果场景复杂了, 要出问题了还真不好说, 这个还得具体分析

5

9
不知道你怎么测试的
我测试的结果，将AAAA从aaa移动到CCC，所有链接到AAAA的链接都坏了

这是最基本的重组

6

测试100%不会修改移动的标题链接

7

还真是…

我刚知道这还有个 “直接迁移小标题” 的功能

发现 Ob 这个 “重组功能” 有几个入口

  • 命令行 - 笔记重组：将当前笔记合并到其他笔记中
  • 命令行 - 笔记重组：移动当前章节
  • 选中一些文本后右键 - 将所选内客移动到其他笔记中
  • 在小标题上右键 - 移动当前章节

image

image

我之前测试的是第一个 “将当前笔记合并到其他笔记中” 这在简单情况下正常

而之后的三个 “移动当前章节” 等等, 感觉都是同一份逻辑: “把指定一小段文字, 移动到别处”
这个我刚测试确实不会维护链接, 跟楼主现象一样


这个确实是问题 Note Composer: links to blocks and headers should be updated when extracting - Bug reports

底下有人写了个 Better Note Composer RyotaUshio/obsidian-better-note-composer 我试试的

– Better Note Composer 看着还不错,
就俩命令 Better Note Composer: Extract heading / Better Note Composer: Extract selection
实测简单场景下, 挪走某章节/某选中文本范围时, 会自动更新其中链接
特别常用的话, 可以考虑拿 Commander 把命令填到编辑器右键菜单里

8

是的，我也是依靠这个插件解决的，但这应该是obsidian核心插件要解决的问题才对，所以说ob对链接并不是很上心，ob都出来多少年了，还得靠插件来完善一个最基础的链接的稳定性，，，

1 个赞