【Obsidian最適化の旅 #8】分類するのは何のため?
どうも、趣味でObsidianをたしなむ者です。
このnoteを含む一連の記事は、私が新しいVaultに求めるものを明確にし、Obsidianの機能を改めて深掘りした上で、私のためだけに存在するObsidian環境を作り上げるまでの旅の記録になります。
本記事は第8弾です。興味のある方はこちらもあわせてお読みください。
前回までの記事ではObsidianで環境を再構築するにあたって、改めてフォルダ、タグ、プロパティの持つ機能について深掘りしました。
今回はその結果「あれ?分類って何のために必要なんだっけ?」と思索迷子になる哀れな男のお話です。
どうぞお付き合いください。
新Vault運用での気づきなどを少々。
現在、新しいVaultでObsidianを運用しながらこの一連のnoteを投稿しています。
運用がだいぶ先行しているのではやく記事にしたい部分が沢山あるのですが、一先ずはここまで書いてきた内容に関する気づきや学び、考えたことなどを少々。
タグなどを短くするために絵文字が便利。そしてかわいい。
ネストタグでもフォルダでも、ノートをその属性によって分類しようとすると、階層化されてテキストが長くなりがちです。
フォルダであればあまり気にならないかもしれませんが、例えばタグの場合
#project/private/obsidian/note
とかなると鬱陶しくなってきます。
こういう場合は抽象的な概念を絵文字に置き換えると多少スッキリします。
#🚀/🙎/obsidian/note
下層ほど具体的で絵文字にしづらくなるので、上層の抽象的なものを絵文字に置き換えてみてください。
可愛くキャッチーになります。
ネストタグの罪
ネストタグはフォルダよりも自由にノートを分類できる機能ですが、気に入らない点があります。
Graph Viewではネストの親と子は別物として扱われる
QueryやDataviewでは親だけを抽出しづらい
Graph Viewではネストの親と子は別物として扱われる
前者について、下の図は私のグラフビューの一例です。右側の四角部分にネストタグがあるのですが、グラフを見ていただくと親タグに子タグがぶら下がらないのがわかっていただけると思います。(見えますか・・・?)
親タグだけがついたノートを抽出できるのは良いのですが、やはり子と繋がって欲しいとは思ってしまいます。
以前のVaultでは ”#読了/2023/08” というように読書ノートを分類していましたが、親子でタグ同士が繋がらないので2022年のグループ、2023年のグループ、みたいなものをグラフビュー上で表現することはできませんでした。
QueryやDataviewでは親だけを抽出しづらい
一方で後者は、親を抽出しようとすると子が必ずついてくる問題になります。
↓ こう書くと
```dataview
table file.tags
from #📝
```
↓ こうなる。
例えば疑問を持ったことに "#Question" のタグをつけて、解決したら "#Question/Answered" とネストしようかと思いましたが、親タグだけをクエる※ことができないので、タグを置き換えるしかなさそうです。
グラフビューとの不一致がにくい。
※ クエる:クエリによりノートを抽出するの意。流行らせようとしている。
実はノートに分類は要らない説
そういえばフォルダを開いてノートを探していない
フォルダ分けはノートを分類してはいますが、フォルダを開いてノートを探すことはしていません。
ほぼクイックスイッチャーでMoCへ移動し、そこからリンクを辿って移動しています。
タグを使ってノートを探してもいない
タグは文章の抽出に使用しており(#5参照)、ノートを探すために使いたいと思ったことはありません。
現時点ではタグをノートの分類に使ってはいないのだからそれはそうなのですが。
プロパティを使って(ry
プロパティは主にDataviewでの活用を想定していますが、他にもIDとDateを記録しています。
でもこのIDとDateもそこにあるだけで機能はしていなくない?
「この日に作成されたメモ」とか抽出してるけど、自分、見てないな・・・。
WeekNumberは週ノートに情報を抽出するのに役立っています。
振り返り用に週・月・四半期・年は抽出できるようにしておくのは良さそうです。
分類はクエリのためのもの?
ノートをリンクさせに行く場合などは、結局クイックスイッチャーを使ってノートを移動していることに気がついてしまいました。
メモ、そしてZettelkastenを機能させる点について言えば、「ノートは必ず他のノートとリンクさせる」という原則を守ってさえいれば良いのでは、という気がしている昨今です。
ノートを分類したい欲求は、ノートをとるためではなくクエるためのもの、ということでしょうか。
MoCってノートの分類と階層化なのでは?
まだ理解が浅い気がしていますが、ObsidianにおけるMoC(Map of Content)はノートもしくはキャンバス上に関連するノートを集め、その中でも近しい内容のものを集めてグループにしてみて、グループが大きくなればノートを分離してまた地図になって・・・という作業と理解しました。
これって、ノートの分類と階層化ですよね。
じゃあ分類のためにタグ付けとかフォルダ分けとかするまえに、ノートをマップに置いてしまえば良いのでは。リンクすれば良いのでは。
それでしまいでは。
MoCの一番上の階層のものだけはわかるようにしておく必要がありそうです。
この実践例として以下のような例が考えられます。
専用フォルダをつくる
専用タグをつくる
ホームページを作ってそこにリンクを置く
ホームページも考えてみると、ここにリンクされているものは「いま興味あること・取り組んでいること」として分類していることになりますね。
わたしは今のところフォルダ派です。
・・・と書いたところで、クイックスイッチャーで移動するならファイル名にMoCとわかる文字列なり絵文字なりを入れておけば良いと気が付きました。
ファイル名で分類できる説
議事録には「議事録」と名前つけがちですし
MoCにはファイル名にMoCと書くか、🗺(絵文字の「地図」)とか書いておけばいいし
これらはDataviewで以下のように記述すれば抽出できます。
```dataview
LIST
WHERE contains(file.name, "議事録")
```
もちろんフォルダ・タグ・プロパティで分類してもいいのですが、前述の通りクイックスイッチャー多用派の私にはファイル名での分類が適しているように思いますし、ある程度のクエリにもこれだけで十分耐えます。
特定のプロジェクトの議事録だけを抽出、といった場合にはファイル名以外にも分類方法が必要かもしれません。ファイル名が長くなってしまうので。
新しい分類をつくる手軽な方法はやっぱりタグ?
結局分類は多くの場合、今の自分のためではなく、将来ノートを確認しやすくしたり、新しい繋がりを見つけるために使われるものなのでしょう。
たぶん。
そのためには「この情報はこう分類しておくと良さそう」という勘であらかじめ分類しておいてみる、という運用が重要でしょうか。
気軽に分類を新設できること
新しいノートに対し「この分類に属するかも」と確認しやすいこと
後から修正がしやすいこと
この3点を考慮すると、実用性が高いのはMoCかタグになりそうです。
MoCであれば専用フォルダの閲覧、タグであればタグペインを閲覧しながら「このノートが属しそうな分類は・・・」と探すことになるでしょう。
MoC化による運用はMoCの乱立を引き起こす可能性があり、そうなるとMoCの分類が必要になってきます。
MoCを統合して親MoCをつくるのは多少面倒な作業に思えます。
タグの場合は、とりあえず階層など気にせずノートにタグ付けしていき、後からまとめられそうなものをネストタグによってまとめる。タグにぶら下がったノートが増えたらMoC化する。
これが今の私の頭の中で具体的にイメージできる、比較的負荷の少ない運用方法です。
次回予告
とっ散らかりましたが、次回はまたObsidianの機能に焦点を当て、グラフビューとキャンバスの深掘りをしていきます。
乞うご期待。
この記事が気に入ったらサポートをしてみませんか?