关于嵌入块和 SQL 块的改进建议

本贴最后更新于 874 天前,其中的信息可能已经时移世改

当前对于嵌入块的处理是采用了 SQL 语句搜索特定块的方式,但是我认为 SQL 搜索和嵌入块其实是不同的东西,当前这样处理也会出现很多问题,比如下面的很多帖子(我自己也是老用户了,使用了非常多的嵌入块,同时也使用过其他软件)。这些帖子的问题大致分两类,一类是关于嵌入块的;一类是关于 SQL 查询块的。

下面主要想讨论一下嵌入块和 SQL 查询使用时的逻辑不同,以及由此带来的功能也应当不同。

嵌入块逻辑

由于其特性,嵌入块的使用场景一般是:该块对于两个父块都很重要,同时内容具有强关联(一模一样),下面是举例:

  • 文档块:春秋战国
    • ……
    • 嵌入块:秦朝的诞生(战国的结束)
  • 文档块:秦朝
    • 秦朝的基本特点
    • 秦朝的发展:
      • 秦朝的诞生(战国的结束)
      • 秦朝的兴盛
      • 秦朝的灭亡(汉朝的诞生)
  • 文档块:汉朝
    • ……
    • 嵌入块:秦朝的灭亡(汉朝的诞生)

所以由于这两个特性(对被嵌入文章的重要性和对所在原文的强关联),块嵌入在两个文档块之间建立了强逻辑关联(甚至强于块引用),而反链恰恰是这一逻辑关联的最好体现。

==因此我认为嵌入块主要应当提供以下几点特性==(父级结构反而没必要显示):

  • 提供反链(很重要)
  • 提供直接的编辑体验(这样更顺滑,但是浮窗也可以顶顶)
  • 提供页内搜索(我个人很少用,因为都是小文档,只是逻辑上应当有)

其他软件的做法

其他软件针对嵌入块(或类似概念)的做法

特性 Logseq Remnote RoamEdit
反链
直接编辑
页内搜索
显示父级结构 悬浮显示

SQL 块逻辑

SQL 块其实是起到了聚合内容的作用,并没有和原文产生强关联,这也是和嵌入块最不同的地方。大家往往想知道这个内容:

  1. 出现了多少次
  2. 在哪里出现了(因此这个帖子里有很多附和的 SQL 查询块显示内容的层级

而并不关心:

  1. 页内搜索(因为 SQL 本来就是搜索)
  2. 是否有反向链接

==所以我认为 SQL 块可以提供以下特性==:

  • 提供面包屑显示(比较重要)
  • 直接编辑(感觉这个对于编辑器顺滑很重要,而且误操作可能性真的不大)

其他软件的做法

其他软件针对搜索块相关概念的做法:

特性 Logseq Remnote RoamEdit
显示父级结构
直接编辑

页内搜索

针对思源的建议

目前思源不对嵌入块提供反链(以及其他特性)的原因是:反链是 SQL 查询的一种,因此不提供反链;这也就是说如果想让嵌入块提供反链,将要开发一种新的块。

我很能理解 D 大和 V 姐的开发压力,也非常感谢二位开发这么好的软件来帮助我们管理知识。但是因为双链笔记中,反链是非常重要的一环,也是要求符合思考逻辑的一环,所以我还是想说,这里的逻辑应当是:嵌入块逻辑上应当有反链(或其他特性),只不过可能开发难度较大,所以还没有;而不是:嵌入块就是 SQL 的一种。。。所以希望能开发一下其中比较重要的特性。。

在这里也非常真诚地邀请大家来讨论这个问题,以便思源更好的发展。

  • 思源笔记

    思源笔记是一款隐私优先的个人知识管理系统,支持完全离线使用,同时也支持端到端加密同步。

    融合块、大纲和双向链接,重构你的思维。

    18150 引用 • 66974 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • Clouder 1 4 赞同

    嵌入和查询确实应该区分开。

    对于原文嵌入,笔记之间的关联性是非常强的,甚至比稍微提及的引用还要强。而查看一个文本在何处被使用,无论是以关键词概括性提及,还是直接原文提及,都是有必要的。
    查询则更倾向于搜集汇总,是搜索的延伸,其主要功能是提供「视图」。

    最终分为三种类型:引用,嵌入(原文引用),查询。前二者是基础性的,而「查询」实际上是视图的一种,我觉得甚至可以作为挂件块提供。

  • 其他回帖
  • "((内容块引用))" 代表对其他内容块单纯的引用, 不需要出现反链

    "((SQL sql 语句))"或"((select 开头的语句))"等 代表查询 不需要出现反链

    "{{内容块嵌入}}" 代表对其他内容块的嵌入, 需要出现在反链中

    其实 ((内容块引用))((SQL sql 语句)) 是一回事, 可以用现在这种查询指定 ID 的形式实现, 结合目前的语义与用户已经养成的操作习惯, 下面这种更合适

    ((内容块嵌入)) 代表对其他内容块的嵌入, 需要出现在反链中

    [[内容块引用]] 代表对其他内容块的引用, 需要出现在反链中

    {{内容块查询}} 代表对其他内容块的查询, 不需出现在反链中

    这样可以保留 [[]]{{}} 完整的语义, 仅改变了 (()) 的语义, 对用户习惯的破坏程度也比较小

    PS: D 大 V 姐其实当初就不应该同时支持 (())[[]], 这样调整时包袱也小一些 😂

    引用的底层语法都是 ((id)),支持输入 [[ 只是在前端做了简单的转换。
    88250
    @88250 我不是指技术实现的难度, 而是指让用户改变习惯的的成本 👀
    shuoying 1 赞同
  • 现阶段暂时不做改变。

  • Belf

    这个帖子没人发表看法吗?

    @88250

    D 大,想问一下,你对这个问题是怎么考虑的?

    1 回复
  • 查看全部回帖