虚拟引用是否支持自引及投票建议

本贴最后更新于 1105 天前,其中的信息可能已经水流花落

2021-12-13 声明:我反对自己的意见

才发现思源本身是有自己的方法论(daily notes 系列)建议或者说适配方法论的,思源的功能建议是依照该方法论来提供功能支持,因此我原本试图适配更多用户的建议可能会对该方法论产生困扰,思源似乎专门对愿意执行该方法论的人提供软件支持。

同时我自己也觉得该方法论具有先进性,觉得自己的理解不够深入,因此我反对以前提出的意见,并愿意看看该方法论的探索用户能把软件推进到什么程度。

原文:

对此问题 2021-11-25 二群有过比较激烈的讨论,之前也有两个帖子 提过这个问题并进行过对应的两次更改。其中有人完全不理解为什么要支持自引,并且可能以投票形式来决定最后改动,我可以提供具体的使用场景,并且希望投票结果仅供参考,由开发者决定最后的形式。

具体例子

例如我需要建立一个《睡眠-呼吸暂停综合征》的条目,而打鼾是其中最有代表性的特征之一,因此在别处我往往会使用“打鼾”这个锚文本来指向《睡眠-呼吸暂停综合征条目》。除此之外还有别的病因也会出现“打鼾”这种常见病症。对于各种常见的大量症状我并不会一个个去做块引,而提及能帮我把他们联系在一起,提醒我这个症状是被标注的,是常见或者特殊的,这样也很方便。

与此同时,在《睡眠-呼吸暂停综合征》条目下,如果虚拟引用支持自引,那么里面必然提到的“打鼾”也会被标注,这样可以提醒我“打鼾”他是常见或者特殊的,也能在此直接通过提及看到其他的出现“打鼾”或者指向本条目内容。支持自引是有使用场景的,一些解释内容更长的大段条目、更不适合用来当做锚文本的块都需要可自引的提及来帮助自己标注。

由开发者来决定与自定义

投票来决定删减局部小功能可能不是一种很好的方式,有几个难点需要解决:第一个是投票的人不一定代表依赖用户和未来用户的大多数,可能是活跃发言的大多数,也可能是关注消息的大多数,高质量样本的采集是统计的重点;第二个是今天的大多数明天可能就是少数,几次删减后满意的人数交集会少很多,没人能保证自己一直是大多数;作为二的延伸,即使是少数也是需要保障的,就像是某些选举里的最低名额保障,以及两派人拥有不同的投票权重。这里提一个公开发言常常会有的现象沉默的螺旋

当然不是说开发者就不允许删除功能,只是多考虑这个功能的使用场景是否符合自己的目标群体,删除或保留功能是仅仅让人不舒服,还是破坏了一部分使用场景?好不好实现自定义同时满足?由需要改变的用户说明使用场景和价值来说服开发者而最好不要简单投票决定,由开发者自己决定。

  • 思源笔记

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

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

    23020 引用 • 92599 回帖
2 操作
p1120 在 2021-12-13 15:51:15 更新了该帖
p1120 在 2021-12-13 15:49:43 更新了该帖

相关帖子

欢迎来到这里!

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

注册 关于
请输入回帖内容 ...
  • wcjj 1 评论

    我现在虚拟引用都当词典用。一般先去知网百科找个症状疾病鉴别比较全的文章,复制下来,然后命名。遇到要一对一信息传递的地方,我就直接用超链接了。

    1 回复
    如果打鼾只和睡眠呼吸暂停综合征联系,那就忽略太多东西了,比如扁桃体肥大,腺样体增生,等等,在特定场景下特定病人的已经相对确定的疾病症状中,我推荐用超链接,单向信息传递。)
    wcjj
  • 其他回帖
  • E-001

    我是觉得如果自引没有性能问题的话,还是挺不错的,能最大化给用户自由,像楼主这样的用法。对于不想支持自引的,使用的时候不在原地自引就好了,目前可能的问题是在使用(())的时候没办法很快判断搜索出来的是不是自己,尤其是长且复杂的文本或图片,如果搜索结果能明显分出来是自身还是其它,应该就不会有问题了

  • p1120
    作者

    即使不依赖锚文本,需要的人也会去促成原地自引,倒不是嫌要先引用一次麻烦。不过这个功能倒不是什么很重要的必需功能

  • p1120
    作者

    嗯嗯我明白你的意思,这里是举个特别具体好懂的例子,平时放一些专有名词。我也是当词典用,提及的自引是为了告诉我“这个词已经放进词典了,要看看它在别的地方的使用吗”

  • 查看全部回帖