要管理海量 “标签”, 就要建设一个 “受控词表” 体系。建设 “受控词表” 体系, 就是明确标引出词项的如下属性的值
order |
ob-property-name |
name |
descriptor-prop-id |
1 |
主题词-英文 |
英文 |
03 |
2 |
主题词-同义词 |
同义词 |
05 |
3 |
主题词-上位词 |
上位词 |
06 |
4 |
主题词-下位词 |
下位词 |
07 |
5 |
主题词-相关词 |
相关词 |
08 |
6 |
主题词-分类 |
分类 |
31 |
7 |
主题词-来源 |
来源 |
|
所以,我创建了一个《汉语主题词表OB示例库》 ,托管在 github。其视图预览如下所示。
更多信息,请参见我的《汉语主题词表OB示例库》的网址:
2 个赞
Ryooo
(Roy)
2
好东西。其实不止 ob,现在的软件在标签管理方面缺陷都非常大。这么搞下来算是弥补了这一方面的缺陷了。
不过反过来说, 直接在每个主题词笔记下记录相应的内容,就可以抛弃标签、直接管理笔记了 
2 个赞
我认为,在每个主题词笔记下直接记录相应的内容不符合“高内聚低耦合原则”,可能会降低可维护性和可拓展性。
并且,在组织笔记文献的过程中,对笔记的 “标引” 和 “编目” 不仅仅要使用 “主题检索语言”,还需要 “分类检索语言” 和 “代码检索语言” 。
比如,我的管理方式就是将一个文件夹当成一个数据库的数据表来管理笔记。一个例子的具体过程如下
步骤一、写出数据库标准文档。
设计读书笔记数据库 book,约定将读书笔记文件放在 data/literature/book
, 构建出读书笔记的记录的范式 book(标题,摘要,关键词,分类号,配图,创建时间, 书籍作者,……其他属性)
,
字段名 |
字段内容的类型 |
标题 |
自由词(字符串) |
摘要 |
自由词(字符串) |
关键词 |
一个主题词表的受控词(如 软件技术 ) |
分类号 |
一个分类表的受控词 (如 TP393 ) |
配图 |
图片代码表的受控词 (如 [[图片01.png]] ) |
创建时间 |
时间代码表的受控词 (如 2025-01-02T13:04:05.678Z ) |
书籍作者 |
作者代码表的受控词 (如 [[作者01]] ) |
……其他属性 |
|
步骤二、对已有的读书笔记文献进行标引和编目
- 标引:填写相应的字段属性,如标题,摘要,关键词,分类号,配图,创建时间, 书籍作者,……其他属性
- 编目:根据自己的需要和库里已有的信息,创建存放书目或目录的笔记,
- 其形式可以是保存的动态查询 比如
```query
path: "data/literature/book/" [关键词:软件技术]
```
- 也可以是一些相关笔记链接构成的MOC(相当于综述论文,倒排索引)
1. [[软件技术书籍01]] | 书籍描述01
2. [[软件技术书籍02]] | 书籍描述02
3. [[软件技术书籍03]] | 书籍描述03
Ryooo
(Roy)
4
理解为 wiki 就好。我之前也是从你这套方法过来的,转为 wiki 式记录以后,在记录、整理和检索上都轻松了很多:
- 用受控语言来作为笔记标题。这样 ob 的别名功能就可以天然的处理语词同形异义和同义异形的问题。也方便了后期的检索,毕竟基于需要查找的主题就可以知道所需的标题,然后就可以仅通过快速切换到达所需笔记。同时也可以通过属性来构建笔记间的种属关系。
- 由于检索方便,就可以在记录新内容时轻松地知道库内是否已经记录过类似笔记,从而避免冗余记录。
- 基于受控的标题,双链笔记软件的出、入链功能也能被自然应用起来——在其他笔记的行文过程中,可以自然地提到一些词语,从而让相关笔记不经意间产生了联系。
我更倾向于把上述过程视为针对知识的管理,而对笔记加分类号、加主题词的管理方式视为文献管理。针对知识的管理比针对文献的管理,麻烦一些的地方就在于每篇笔记只应该聚焦于一个主题,而不能像文章一样随心所欲地记录不同主题的内容。
1 个赞