sites/21055287
１　Daily notes
２　Link
３　Metadata（Properties）
４　Folder
５　Title（ノートタイトル）
DiMFiTはいわば、雑然とした情報を管理するためのフィルターです。そしてこれに「Search（検索）」を加えると、必要なメモにたどり着くための「手がかり」となります。 情報はDiMFiTというフィルターを通すことによって、ある程度分類・整理された状態で保存され、手がかりによって取り出される。メモの山からメモそのものではなく、手がかりをつまんで引っ張り上げるイメージが近いかもしれません。

・・・そうではないのです。リンクのみに頼った整理では、必ず後でしっぺ返しを食らいます。Obsidianは整理不要のアプリではなく、日々増え続ける情報をゆるく分類するためのフィルターの種類・・・適切なルールに従って保存された情報ならば、その数がいくら増えようとも、検索やリンク、またはその他の手がかりによって適切にフィルタリングされ、ノイズの少ない状態で取り出せるはず・・・

セカンドブレインを成長させるには、「記憶する」「結びつける」「つくり出す」という３つの段階があると３章で説明しました。

ほかの整理術も試してきましたが、「目を通してはブックマークをして、やがて忘れる」のくり返しだったと言います。

Inazuma SearchのSvrのクロールに、36時間かかった。

データ量は合計1TBぐらい。ツクモ黒PCでそれだから、ハチPCだと倍かかるだろう。

Cltだと24時間。Cltは外付HDDにしている。Clt×1.5=Svr がビルネットワークのスピード差だ。

クロール中のPCは苦しそう。だからクロール中は作業できない。データが大きすぎてソフトの許容量を超えるのでないかという懸念があった。探三郎は許容を超えたが、Inazuma Searchは問題ない。十分だ。ということは、おそらくFessやエラクレも大丈夫だろう。

最新を求めるものではない。だから常駐クロールははずしておく。更新クロールは連休しかやれない。素材が安定したらSvrのみになるかも、Cltはいらないかも。否、ガンガンぶん回しするほうがいいからCltのみがいい。更新クロールよりHDD-K交換のほうがシンプルだ。

￥1,550/月で３個使っている。

近接検索を夢見ている。

が半分諦めている。しかし、完全とはいわないまでもある程度は勝手になるとは思っている。手の届かないことを考えるのはやめよう。執着しないことにして別の道を模索する。それは「ただの検索」である。Inazumaを使いこなすことが先です。おそらくAI検索が追い越してくるだろう。

近似検索を諦めるなら、範囲を小さくする作業をすることになる。近似検索とAI検索が手に入ってもこの分割作業は無駄ではないはずだ。おそらく強力になる。

入れ物（乗り物）にEverNoteを加える。ノートブックとタグの2軸がよさそう。タグがなんとかしてくれそうな気がした。タグだけでの検索・というか絞り込み。タグは階層的となり世の中のモノコトに応じてどんどん増える。100はある。

EverNote はタグ検索に向いていないのではないのか、というよりタグで整理するのはそもそも無理ではないのか。またEvernote は入れ物として適当ではないのではないか、という気がしてきている。

やめるかもしれない。

prologue：表と裏／前者と後者／A・B・串刺し／0・1・2／3階層が認知の限界／ 内部秘密たるminos／外部公開たるmskura／ミノスと倉。

前者は、つねに堅固にしておく必要があるからつねにシンプルにしておく。外部公開という（湧いた）需要は複雑さの種になるから、この段階で切り離したほうがいい。だから二つ目を加える。
mskuraの出現によって、フル権限の私がクライアント側にになるという新たな視点が生まれた。まずこのことを歓迎して、この発想の足場を固めることからはじめよう。 minosの根のセキュリティ設定がフル（強固）になったことによりシンプルになって嬉しい。

#0：minosメールは外部ユ―ザ一の一人。yama#もしかり。そうしてtokudメールなどの元々外部ユーザーと同一部類となる。
#1：フル権限たるminosなどの少数限定。
#2：閲覧のみたるteraoなどの不特定多数。
#3：guestまたはvisit。シンプルというか単純化してmskura@msoffice.biz gestもといmskuraの乱数表。mikeメール・hatiメールがgest／縦軸は、kuro・hati・mukeの三つ。実際はgest-kuro@msoffice.bizの一点物

visitたるmskura@msoffice.bizの乱数表。足し算ができる程度で予測可能なシステムにしておく。非公開・機密秘密ではなく拡散や乱用を防止する措置。
1234 2345 3456 4567 5678 6789
機密情報ではないがゲー卜を設けています。入室にID・Passが必要です。 電話・メール・主要文書の補足情報であるので、利用者にフィルターをかけています。
Passwordは乱数表Aのとおりです。 1234 3456 5678 ====— 1234 3456 6789：これだな

自炊書籍を分離したいのです。
★
わかりやすい本として「Ｑ＆Ａ300問」という本があります。これは約700頁あります。自炊目次は、次のように章立てとなって2階層となっています。

　第1章　　総則
　　1問　＊＊＊　　…〇〇頁
　　2問　＊＊＊　　…〇〇頁

　第2章　　各論1
　　3問　＊＊＊　　…〇〇頁
　　4問　＊＊＊　　…〇〇頁
　300問　＊＊＊　　…〇〇頁

この＊＊＊タイトル毎に分割し、且つこのタイトルをファイル名にしたい。

（分割後のファイル名を「しおり」にする方法がわかりません）

★

★

私が推測するには、1「既存の目次からしおりを生成する」が頼りになると考えました。2だから、この既存の目次が正確でなければならない。そこで、既存の目次をＯＣＲしたものをワードに落として丁寧にチェックして差し替えるほうがいい。3その際頁番号は無関係。と考えました。

★

しかし、うまくいきません

★その他
スキャンしてOCR化しているので、テキスト化は完全ではありません。

バラバラにして検索が目的であるから、はしがき・索引・あとがきは削除しています。また、N章の末紙の白紙には頁数が書かれているが邪魔だから削除しています。頁番号は、ほとんど100％フッター中央にあります。

目次に頁番号が振られ、本文にもその連続した頁番号が振られている書籍がある。
　例　目次1・2・2、本文4・5・5…
いっぽう、本文に独立した頁番号振られることもあり、これが多い。

自炊目次を置き換え・はしがき等を削除すると、1ワード目次と、2自炊本文の2つになる。
1ワード目次には頁番号を無視しているし、自炊本文は連続していない場合がある。

次らしい。

ON しおりを自動生成する
ON 既存の目次からしおりを生成する
OFF 目次のページ番号でリンクを設定する とした場合の対応方法になります
対処方法ですが、下準備2で次のようにしてから自動生成ウィザードを使用してみてください

1問 ＊＊＊ — 1 2問 ＊＊＊ — 1 3問 ＊＊＊ — 1 4問 ＊＊＊ — 1 300問 ＊＊＊＊ — 1

とするとよいとのこと。つまり、ぺ―ジ数は関係ない。よくわからん。

千頁ある自炊書籍を分割したい。
高度なAＩならそのようなことが自動化できるかもしれない。ABBYY FineReaderがそうかもしれない。しかし、いまのところは手作業でないとできないだろうと思われる。

AＩではないが標記のソフトがある。