一個一個独立して情報まとめる
- でないと邪魔されてうまくまとまらない
書くことで理解することが大事なのがwiki
覚えることはまた別、たまたまSRがwiki内の機能としてついてるだけ
使うなら検索、理路整然とまとめられたページが欲しいならタグよりリンク集でも作ったほうが良さげ……だが、Dataviewはタグで纏められてしまう。
リンク集だと互いに参照欲しい時に困るのだ……と思ったが、Dataviewでも上のファイルからの参照しか使ってなくね。
これこいつの発言だろ！ と思ったときは、発言側からそいつについていくのか、そいつから発言についていくのかの違い。
認知から見ると前者の方が楽そう。発言側から誰のものなのか？ を形作っていくイメージ戦略。
けど結局こいつはどんな発言をしているのか？ が人間を作るには大事なのであって。
だからタグ付けつつ、ここで必要と思ったやつを自動的にまとめられるのはかなり強いDataview。
人間を作るならそれでいいが、プログラムはそんな曖昧にするわけにいかない。
しかし、いちいち情報ページを開くわけにいかない以上、情報は断片的にならざるを得ず、後での検索オンリー頼りなら纏まった情報とかは作らなきゃ存在しない。それを作るのにDataviewによる自動生成とか考えるとああああああ
CS Unreal Engineとかにして情報側からリンクさせバックリンクを見るだけ、CSはタグで管理するけど情報個々のタグはめんどいから無視でいいんじゃない？
ぶっちゃけCheatSheetかErrorかなんて考えたくもなくね。いらんでしょここのくくり。
↑
ありっぽい、ただ日付はのこせ
つまりdateは全てに、大事な纏めファイルだけ別フォルダとかタグとかで管理、残りの断片ファイルはほぼそのままだけどリンク刺したか刺してないかだけで管理、CheatSheetやらは廃止？
ぽい
これならタグ特有の「どれが纏め用の特別ファイルかわからない」って言うのは無くなる
CheatSheetを導入したのもその流れだった気はする
プログラム側はこれでいい
Novel側はきつそう、まあ大体「アリスってどのアリスだよ」的な悩みだけど
つまりほぼ内容同じだけど知っている範囲に差があって、「このアリスはこのセリフ言わないじゃん」みたいな状況で詰む。
..…これは纏め用から新しい子の纏め用作って、子の方から改めてリンク刺すっていうのがいいか。
情報側からは、アリス親にしか刺さない。
アリス親側からは、アリス子に刺す。
アリス子から、改めて使う情報に刺す。
東方は世界ごと違うからこういう話になるが、普通の小説でも「この段階の高目こういうこと言わないじゃん」っていう時間ベースでの差異は生まれる。
情報を親に集め、子にその中だけから分け与える仕組み。
子は子であるっていう証明としてタグ付けたほうがよさそう。
と思ったけどいつ親が子になるかわからないしないほうがいい。
それより子からは親をはっきりさせよう。
でも親からしかもらえないって言ったってリンクに親子なんざないわけだし、インターフェースって言ったほうがよさそう。
これなら複数から読めるし
ただ、「情報を集める権限がある纏め用特別ファイル」と
「継承したインターフェースからしか情報を集められない纏め用特別ファイル」は分ける必要ありますか。
- 纏め用からは分けてた方がまとまった情報にアクセス出来てうま味
- が、情報ファイルからはその状態だとどの纏め用にリンクを刺せばいいかわからない。
- とりあえず一番親がいいんじゃね、となるけどさっきインターフェースって言っちゃったからどれが親かわからない。
インターフェース廃止して親子使うなら、親が分かるようにタグで親1,2って分けることになるが、それはもうLayerでは。
纏め用ファイルからは子が出るたびにレイヤーIDを増やし、親が増えるたびにレイヤーIDを減らす。直感的だが、これに引き連れられる情報ファイルはレイヤー何になるの？ 別枠？
纏めが０、纏めの纏めが-1、子が1。情報がA。
1以降は情報側からじゃなく、子側から情報にリンクを刺す必要がある。
ただ纏めが人間なら、纏めの纏めは組織になる。これに刺すリンクもあるとして、子は必ず親のvariantかな。variantって言ったほうがいいな。人間を細分化してるわけだし。本物の子なら別枠のLayer0だし。
……となるとなかなかvariant作るのめんどくさいな。しゃあないが。
検索結果へのリンクを一気に張るプラグインはあったはずだから、それで頑張る。
dateは全てに、大事な纏めファイルだけ別フォルダとかタグとかで管理、情報ファイルはほぼそのままだけどリンク刺したか刺してないかだけで管理、CheatSheetやらは廃止
纏めvariant以降は纏めvariant側から情報とまとめに刺す、纏めの纏めは纏めと同じルールに。
つまり情報ファイルはvariantに刺してはいけないのがルール。これ元のルールに加えてただvariantにタグ付けるだけだな？
プログラム側もよく考えればバージョンという概念がある以上、これが必須な気がする。
ところがそうすると、二つ以上のプログラムが重なる場合に、どっちのバージョンを刺してんだって話になる。versionUEとか、versionUnityとか、どっちのバージョンなのかを情報ファイル側に書くことになりそう。これは纏めファイル云々じゃなく、情報側が持ちえるプロパティだから……
……UE5.0.2っていうファイルに刺したりすればいいんじゃね？ Novel側で情報ファイルをvariantに刺しちゃいけないのは、纏めファイルに情報を一極集中させないとキャラがつかみにくいし扱いにくいから。
あと二つ以上のプログラムが重なるって言うのは、Novel側で言うと物語序盤の主人公と終盤の相棒が一緒に仕事する時があるみたいな状況。そんなん想定してないし、そうそうやらないだろうし。時間みたいに連続性があるものじゃなくて、バージョンで明確に断続的だから何とかなるさ。
要は状況が違うわけだからこっちでなら刺してもいいかもしれない。極力オリジナルフロントマターを避けていくスタイル。
とでも思っていたのか？
別世界線とか、結構いろいろある。
ただそうするとバージョン宣言時点でUEであることをすでに言及してしまい、アプリ宣言と合わせて二重情報になる。タグで表すならUE/5.0.2とすればいいだけな問題。
ここを気にするなら、情報ファイル側から纏めファイルUE5.0.2にだけ刺し、それらを纏めるファイルUnreal Engineを作ればいい予感。
……これ検索のときに困らない？
バックリンクでフィルタリングする機能は検討中っぽい。
Searching for text in note body · Issue 279 · blacksmithgu/obsidian-dataview · GitHub
まあ、もともと全文検索しか使わないし問題ないか。たぶん。
タイトルを真面目につける必要性が出てくる。
そこまでするならいっそ日付もデイリーノートに刺せばいい気もしてきた。
タグの利点：カウンター
被リンクの数数えればいいし
階層化
必要無いし
非表示で書ける
読んだ時の満足感でしかないし
フィルター検索が楽
……
書く時のコストを考えて、纏め用ファイルのみ整理するという性質のがよさそう
でもリンクもコストですよね？
情報ファイルはめんどいのじゃ
せめてWriterPがリンク使えればいいけど、リンク張るにはインデックスが必要だからどうしようもない
WriterPを軽い状態で常に開ける直結Obsidianリンクみたいの作れたら楽なんだけどな
これAutomateでいけるんじゃね
出来たけどファイル名が同じなのでどんどんファイルを作っていけるかというとそうでもない
File Heading Syncの出番か
あー、いけねぇ。
纏めファイル→AファイルからAAファイルがinfoファイルの情報をDataviewで集める場合、結局検索使うことになる。
Aファイルだってinfoファイルからしかリンク受けてないわけじゃないし、最低限のA、Iくらいのタグは必須だ。
タグページがいらないただの分類、もしくはそもそもの作品タイトルをタグとしてる
タグページはtagwranglerで作れるんだが、だって関連に追加してるページに関連からとタグからの両方で飛べるのってややこしくない？
ただでさえ大量にタグが付いてると、管理する気が失せるのに。
重複情報を付けてます、ってなるともうめんどくさすぎる。
セキュリティ観点だと両方から入れるのはありがたいが……情報の整理で考えるとだるんご……
でも関連ページにも上下ほしいのある。
breadcrumbsの時間か……
検索の速さを考えるとやっぱタグではあるが、必要になったことが無いので。
ブレクラ、マークダウンリンクに非対応の模様。
記事をマークダウンにして保存する試みは今までも何度かやったが、保存した記事は20KB程度になるほか、書こうとする記事よりも多く存在する。ウェブページを開けばいいだけなのに明らかな容量の無駄。
でも取り込まなきゃ、ページにしなきゃspaced repetitionが作動しない。これは見出しとURLだけ用意してSpaceにした方が軽いか。これやると完全に既定の動きになるわけだし自動化したい。
markdownloadをいじくればいける？
記事見出し、URL、分けるのは1::1などとして、読んだらEasy。
ところがこれだと１読み切ってないのに２が出たりしてしまう。カードを順番通りに出すようにすれば何とか。