笔记体系设计
笔记体系设计思路
[!info] related notes atomic-notes
笔记体系设计
[!info] related notes
- 相关概念: atomic-notes, knowledge-base-flat-management-guide
- 相关规则: [[knowledge-map-and-atomic-note-spec]], [[knowledge-base-tag-system-design]]
笔记是什么
先明确。笔记的目的在于满足人的需求。我们为什么要做笔记？ 对于我来说，笔记的目的是为了整理知识，方便后续回顾。
具体一点：
- 购买产品时，了解学习相关参数，每次重新购买时都补充回顾
- 了解新技术、知识时，记录回顾；比如配置 pve、routerOS 系统，还有备份操作都记录下来，否则容易忘记自己做过什么操作、备份在哪里，怎么恢复。到时候都得重新上网搜集资料
总之，应该是融入工作流，遇到哪个就回顾。它本质上是大脑的延伸。
关键：
- 相关笔记的搜索
- 笔记的可读性
方案
方便搜索，有三种方案：
- 高精度标题
- tags 筛选
- 文件夹结构
这里可以给每个方案都写一篇 concept 笔记作为列表项，再来一个三种方案对比 或者 组合使用笔记
核心概念
上面说到的两个关键是耦合的
笔记承载的是知识，本质上是知识+知识展现形式。
知识是复杂的，难以精确分类的，比如 dailyuse开发 的笔记，它包含 electron、vue、frontend、backend、typescript 等多种技术，或者是 dev 领域 或者是 project 属性。 对于每个人，甚至每个人的不同时间，都会有不同的想法。 所以任意的 tags 或者 文件夹结构在我看来都是不优雅的。
还有如果把所有相关内容都放在一篇笔记里更是灾难，它的维度会更多（concept、howto），也不方便复用 链接。 所以应该使用 原子笔记，能够做到笔记之间相互链接复用。
总结
总之，knowledge-base-flat-management-guide 中的扁平化管理方案是一个不错的方案
个人实践
要用好 知识库扁平化管理，需要先明确好个人的标签 规划 和 笔记的拆分逻辑。
首先，笔记的 status(growing,evergreen,seed) 和 type 两个领域的标签需要基本达成共识并固定。
领域维度的则应该根据个人情况 斟酌
规范_standards
moc类笔记样例
moc 类应该只有在跨资源、跨领域时才应该使用。 不应该在同一个资源的总览笔记中使用，也不应该有这种笔记。因为同一个资源的相关笔记都应该包含 resource/{{resource-name}} 标签，完全可以使用 筛选功能获取。
资源类笔记样例_example
网站、app小工具、文章、开发库、语言（JavaScript）等现有的应该都属于 resource，似乎同时也是一个概念 笔记标题应该就是这个 resource 的名字
标签模板： type/resource，status/growing， resource/{{resource-name}}，video，download，website
可以在 002_Resource 笔记中使用 标签 dataview 来实现分类整理 有这个 type/resource 标签的笔记本质上应该是一个 Overview，介绍这个工具 然后 具体怎么使用内容 应该重新写一个 howto 类型的笔记，并且也要加上 resource/{{resource-name}}
tech/dev/vue 这样的标签不应该存在，应该拆分成 tech/dev 和 resource/vue3
对于资源类的笔记，如果包含网页端，还应该有 website 标签 以及类型标签（影视、游戏、下载、图书 等 tags）， 比如 website，video ， 用于 youtube，表示一个视频网站。 后续应该 确保分类标签有哪些。 同理，如果包含windows 版本就添加 windows。方便用于 网址索引页面 或者后续的 桌面应用台。
笔记名与笔记标题隔离
为了方便后续将笔记用于网页渲染或者知识分享，需要重构笔记：将文件名与title分析，在 yaml 元数据中使用 title 来作为名称，文件名则统一为kebab-case 模式。 详细见 title-and-file-name-in-obsidian-notes
title 和 alias 共存
由于使用了 特殊的文件名，双向链接就会受到影响， 所以需要使用 obsidian 中的 特殊 元数据 alias，就能实现快速双向绑定时显示 alias 中的名字，所以需要和 title 内容相同的 alias 属性。见 在 obsidian 中使用 alias 属性