释放图谱的力量——KG笔记法

赞同这个观点,附件确实应该少用,会导致思维上隐性的偷懒

你好,看了 KG 筆記法覺得很受用,請問還能加入微信群嗎 ?

大佬~申请加入微信群~

大佬,申请加入KG笔记法实践wx群~

对KG笔记法非常感兴趣,和我近期实践的方法很多地方类似,申请加入微信群。谢谢。

大佬,现在还能加群吗

看过KG笔记法后准备试试,想问问看还能加群吗?

大佬,求申请加入KG笔记群:joy:

随着 KG 实践的深入,我现在有一些疑惑,就是 KG 好像并没有提到如何处理程序性知识或者问题的解决方法,例如《安装 WSL2》和《解决 WSL2 中 Z Shell 的卡顿问题》。

虽然在其他地方提到过《白切鸡制作》,但这与以动词开头的程序性知识或者问题的解决方法不太一样。「白切鸡制作」是一个名词短语,与 KG 中表示概念或实体的各种名词更为契合,而包含谓词和客体则显得非常不和谐。

我目前可以想到两种解决方法:

  1. 在对应概念或实体的笔记中盖高楼。
  2. 每个完成独立目标的程序性知识都是一篇独立的笔记。

对于第一种方法,在某些情况下,例如《安装 WSL2》中,我并不需要去关系其主体《WSL 2》是什么,更关心如何完成目标,解决了什么问题。在例如楼主在 B 站中所提到的《git clone》,有人可能更关心如何去克隆项目,即怎么用 git clone,而不是 git clone 是什么。再比如《使用 git 回退》,它可能包含多个指令的组合,我们不用去关心那些命令能回退,只需要关系如何回退,回退到何种地步。在这种关注如何操作的情况下就没有对应的主体。

对于第二种方法,每篇笔记的标题至少包含谓词和客体两部分,例如《安装 WSL2》,更甚者将包含多个状语,例如《在 Ubuntu 中基于 DEB 包安装 cuDNN》,它包含「在 Ubuntu 中」和「基于 DEB 包」两个状语。随着发展,笔记的标题可能会变的越来越复杂。或者忽略状语,仅保留谓语和客体,进行笔记的合并,例如《在 Ubuntu 中基于 DEB 包安装 cuDNN》和《在 Ubuntu 中基于 TAR 包安装 cuDNN》合并为《安装 cuDNN》。

因此,我很想了解楼主是如何看待程序性知识或者问题的解决方法,以及如何去做的。

首先先明确一个原则,kg的核心是定义了一个具有可操作性的"知识单元"的定义,并通过为其赋予一个具有高检索性能的名称以提高该知识单元的后期查找和应用效率。所谓高检索性能,基本要求就是名称固定,并且能适用于不同别名的检索。不管程序性知识还是陈述性知识,都可以根据这个原则进行处理。

以《安装Wsl2》为例。这一笔记主要讲述的是wsl2这一主体安装方面的内容。那就有你说的两种处理方法。

方法一把wsl2视为主体,安装仅是《wsl2》的一个章节。这种做法的好处就是具有非常高的检索性,毕竟"wsl2"对于你来说就是一个非常非常固定的、符合认知的知识概念,在任何场景下都可以轻松地检索这个标题,从而找到对应的安装内容。缺点就是找到的信息会很多,毕竟"wsl2"的方方面面都会记录在《wsl2》下面。(当然这个在其他场景下不见得算是缺点,因为你的目标可能是获得wsl2的知识结构。)

另一种做法那就是把"wsl2的安装"视为一个单独的知识(笔记),与《wsl2》分开保存,但又被《wsl2》链接。这样就既能保证《wsl2》中知识结构的完整性,又能在检索某一方面的时候不会拿到太多无关信息。

需要注意的是,虽然第二种方法看上去很好,我也比较推荐,但是它这些优点只有遵循严格的命名规则才能发挥出来。很多新手朋友没有注意到这一点,而是一味地去使用,很多这样的笔记后期就再也找不到了。

为什么第二种方法很难像第一种方法那样形成固定的名称?原因就在于第二种方法的笔记标题基本由两个以上的名词结构构成,假设每个名词存在N种别名,那么这篇笔记标题的检索式可能有N1*N2种,并以此类推。如果再纳入动词结构或者介词结构,可能性就更多了,后期难以被检索基本就成为了必然。

所以,在多数情况下,我优先推荐使用第一种方法。因为第一种方法的唯一缺点也只是找到的内容有点多,但我们可以通过笔记内部的大纲来轻松定位所需内容,所以这个小缺点也就可以无视了。这怎么说都比用第二种方法但后期找不到来得强。

那什么时候用第二种方法?就是等到《wsl2》里的"安装"内容扩充得足够多,或者是这部分内容要被别的笔记引用了,再去把安装部分的内容独立出来。因为这时候,你基本上就能形成一个关于"wsl2 的安装"的固定名称,这样后期找不到的问题就不会有了。

同理,对于"在xxx系统中安装wsl2"这样的内容也是遵循上述的方式处理:先是放《wsl2》安装章节,然后是《wsl2安装》的"xxx系统"章节,最后才是《wsl2xxx系统版安装》。所以说,只要把握基本的原则,所有类型的笔记处理都是一样的。

1 个赞

明白了,感谢楼主的回答,在处理程序性知识上以在主体上「盖高楼」为核心。

对于第二种方法,无法轻松定位的问题可以用楼主另一篇讲 tag 的文章解决,例如《在 Ubuntu 中基于 DEB 包安装 cuDNN》,可以分解为「cuDNN」「安装」「Ubuntu」「DEB」四个标签,前三者可以分别表示内容的主体、方面和地点,「DEB」则作为补充性词汇。

此外,我还有一个疑问,就是楼主遇到相同符号表示不同概念是如何处理的,例如物理上的空间和数学上的空间,楼主是命名为《空间 (物理)》和《空间 (数学)》,还是命名为《物理/空间》和《数学/空间》。前者以后缀区分,后者以路径区分。对于该疑问,楼主只需要做出选择,无需解答。如果楼主有第三种不同的建议,还希望楼主能详细的解释 :grinning:

其实不算是以盖高楼为核心啦 :rofl:而是说在没法确定一段内容是不是独立知识,或者无法确定知识的命名的时候,先盖楼,确定了再独立出来。

标签的方式不是不可以,但是不推荐。原因一是慢,搜索的时候找到合适的标签和回忆命名其实都差不多。二是很容易造成冗余,因为用标签法的时候你是先建立笔记,再去打标签。你不会先去搜索看看库内有没有类似内容,就很容易重复了。反过来kg新建笔记都是用快速切换器,创建笔记的时候就已经在搜索有没有类似知识了,从而避免了冗余。

关于同名异义问题,采用括号注释的第一种方法,然后在别名中写下"空间"方便搜索。这样的好处在于括号内你可以写自己想写的内容对名称进行解释,也不依赖文件夹管理体系。

R佬,申请加入KG笔记法实践群

1 个赞

您好,请问您可以开源部分库吗?我想看看您具体的尝试。看您的方便

请问大佬这个GIF图是用什么软件做的哇?

您好,申请加入微信群

大佬,申请加入KG笔记法实践群

大佬,申请加入微信群

非常感谢楼主分享。

一篇帖子,硬生生被你们弄成了学术研究 :stuck_out_tongue_closed_eyes: :call_me_hand: