の作業記録

ブックカタリストな火曜日

8:00

おはようございます。今日は午後からブックカタリストの収録です。それまでは原稿とTextboxについて進めましょう。

Textbox:

状況を整理します。まず昨日は、from欄にIDが入っていたときの処理を書きました。

で、ここからの作業です。まず、histroy-boxでfromに値が入っていたときの表示をどうするのかがあります。IDを示して、リンクボタンにして、クリックしたらそれが表示されるか、そこにスクロールするというのがあるでしょう。あるいは、from欄にはidだけではなく、テキストも入れておき一緒に表示する、という手もありそうです。

通常の表示ではfromがあることだけを示し、詳細表示（今はありませんが）したときにfrom先の内容を引っ張ってくる、というのもあるでしょう。とりあえずいろいろできそうではあります。が、それはいったん後回しにしましょう。

今考えているのは、referrerの表示。特にbooksでの表示の仕方。ある本のjson項目に、referrerとして読書日記の項目のIDが入っている。で、本の詳細を表示すると、referrerを探しにいって、それを表示させる。そういうやり方です。で、この「探す」をどうするか。

当然ID名から探すわけですが、その検索先がどこになるのか。

読書メモであれば、historyが現状の保存地帯で、そこに読書日記.jsonのようなものも選択肢に加えるかどうか。

で、たとえば、ある本が別の本と関係している、というのはどうすればいいか。もしこれもreferrerで表現するならば、historyだけでなくlibrary.jsonも検索対象である必要があるでしょう。

しかしここで問題が出てきます。ある本の中で別の本が言及されていることと、倉下がある本と別の本が関係していると感じることはイコールではありません。前者はreferrer的ですが、後者は違うでしょう。

あるいは、読書メモの中で関連する本について言及する、という形をとる？

Scrapboxでは、本のページを作り、その頁の中に別の本のタイトルを書いてリンクにすることで「ノード」が生成されます。で、linksとreletedという二種類の「関係性」が保存されます。同じことを行う？

あるいは、そういうのとはぜんぜん別に関係性を扱うか。

＊　＊　＊

読み終えた本にタグ付けするような作業（たとえば、SFとかライトノベルとか）は、その本のメタ情報としてつけ加えればいいでしょう。では、関連している本はどうか？

「関連している本」（敷延して関連している項目）という欄を設ける？　それはreferrerとどう違う？

＊　＊　＊

たとえば『独学大全』という本がある。この本は、たとえば『アイデア大全』や『問題解決大全』とつながりがあると言えるだろう。また、『文章大全』のような「きたるべき」本ともつながりがある（あるいは潜在的つながりを持つ）とも言える。

一方で、たとえば『Learn Better』や『私たちはどう学んでいるのか』とのつながりもあるだろう。学習系というジャンル的なつながりだ。また『勉強の哲学』とのつながりは学習系というよりは「勉強」という言語的つながりといえる。

さらに『発想法』や『知的生産の技術』のように内容的かつ、倉下的視点とのつながりもある。

以上のように、一冊の本がもつ「つながり」はグラフ理論ではすべて単一の表現に収まるが、個人的認知としては実は十分ではない。しかし、その認知的差異をすべてデータ的に違いを持って保存するのは現実的ではないだろう。

では、どうするか。

一つは、linksとreletedの二種類くらいにわけておくこと。でもって、カテゴリやジャンルごとのつながりはaddressでなんとかすること。

次に。メタ情報としてでなく、文章としてその繋がりを示すこと。『独学大全』にrefを貼る読書メモの中で、「この本は勉強の視点で『勉強の哲学』と共通点がある」と表記する。それはそれでいいとして、じゃあそこからどうするかというと、やっぱり『勉強の哲学』をリンクにすることだろう。で、そのキーワードで検索して、本を見つけて、IDを付与する、という作業が必要となる。ふむ。

問題はこれをするとつながりが非常に複雑になることだ。『独学大全』という本の項目にリンクを張っているのではなく、そのrefの読書メモにリンクが貼られることになる。

なんかもうそういうことはすべてScrapboxでやった方がいいんじゃね、とは思う。思うけども、もうちょっとだけ頑張って考えてみる。

ようするに、上記のやり方で「関連する本」を一覧したければ、2hop先のリンクまで拾ってくる必要がある、ということだろう。

逆に言えば、このやり方をすれば「グラフに名前（タイトル）をつけられる」。これはScrapboxにはなかった道のりかもしれない。

＊　＊　＊

たとえば、タグに「勉強の本」とつけるとする。で、『勉強の哲学』にも「勉強の本」をつける。すると、タグで抽出したらこの二冊の本を拾い上げることは可能になる。で、そのグループは「勉強の本」と言えるだろう。この一般的なやり方と、自分が今考えているやり方は何か違うのだろうか。

『独学大全』という本の項目

『独学大全』のIDをfromに入れた、addressが読書日記（メモの方がいいか）の項目。その項目内の記述に『勉強の哲学』がある（この時点で『勉強の哲学』のIDをどのように保存しているのかは考えないとする）。

このとき、『独学大全』という本の詳細を開く。当然初期の想定では、読書日記の項目は表示される。『勉強の哲学』の本の詳細はここでは表示されていなくてもいいだろう。せいぜいクリックしたらその本の詳細にジャンプできる程度でいい。

逆に『勉強の哲学』の詳細を表示したらどうなる。先ほどの読書メモは表示されていて欲しい。つまり、refに先ほどの読書メモのIDが入っていて欲しい。

つまり、先ほどの読書メモは記述ないに本のタイトル＋リンクを含むことで、その本の項目にピンを送っている（トラックバックを送っている）と考えられる。そのピンを処理したら、二つの項目間でエッジが成立する。

別の言い方をすれば、読書日記の項目が二つの本をブリッジしている。

ここまではいいだろう。

＊　＊　＊

Mapについて。

ぜんぜん実装はしていないが、リンク関係があるならば、それを「一つ上の視点」から眺めてみたいと思う。ある本に関係する本を一覧したい、という場合どうするか。

その本へのrefは自分の項目が持っている。まずそれを表示させる（それは基本的には読書メモだけであるはず）。でもって、読書メモが持っているidがある。それは別の本へのリンクだ。それも拾い上げる。2hop。さらにその本も、という感じでいくらでも拾い上げられる。

この場合、『独学大全』と『勉強の哲学』はエッジ（線）で結ばれるわけだが、その線はただの線ではなく「読書メモ」という内容＝テキストをもっている。普段は線の形で表示しておけばいいが、ホバーすればそのテキストが表示される、といったことができる。

ふむ。

面白そうではある。やっていることも、やや手間ではあるが、プログラミング的に高度という印象はうけない（あくまで印象）。

＊　＊　＊

一応の検討課題は、本文内に埋め込んだ書名リンクの処理である。その項目のfrom欄はすでに埋まっている。となるとfor欄を新設するか、という話しになるのだが、それは結局addressのことになるだろう。

ここで機能の衝突が生じている。addressに加えるか、それとも何か別の欄を設けるか、それとも作成時に単にピンを送るだけで、それ以外の情報は持たないようにするか、だ。

役割を考えるならば、今やろうとしていることがアドレスにして、もともとの機能はタグにリネームするのが良さそうにも思う。

本当にそうだろうか？

そもそもaddressという機能はそこまで必要だろうか。「メモは送り先がある」という認識からスタートしているわけだが、いまのところは単なるタグ機能にしかなっていない。これも結局、historyに保存しつつ、別の場所（たとえばpegeやjson）に送る、ということが念頭にあったわけだ。が、現状なくても特に困っていない。だから簡易のタグ付け装置として機能しているし、それはそれで悪くない。

むしろこの「address」は、住所の都道府県のような位置づけになっている。国はhistoryで決まっていて、その中の送り先、という形。別の国に送信する機能があってもいい。

＊　＊　＊

たとえば、その読書メモ項目だけを表示したときにどうなるか。それは『独学大全』についての読書メモであり、本文に『勉強の哲学』が言及されている。このとき、『勉強の哲学』の情報が表示されると嬉しいかどうかが関わっている？　本文内に対象のページを限定する情報が残っているならば、わざわざメタ情報にする必要はあまりない？

『勉強の哲学』に関する別の読書メモを並べて表示したいならば、メタ情報として持っておいた方が処理しやすい気はする。しかし、それこそScrapboxと同じ処理だ。

＊　＊　＊

ここで関係性の議論に戻ってくる。たとえば「読書日記」というのは一つの情報の関係性の提示であろう。でもってそれは時系列で閲覧したいときなどに役立つ。絞り込みとしてのカテゴリ。

一方で、それ単体で表示したときに表示されて欲しい「つながり」だろうかと考えるといささか怪しくなってくる。山田さんの隣に鈴木さんが住んでいるとして、山田さんの家を訪問したら鈴木さんも一緒にいた、というのはちょっと違うだろう。むしろ山田さんの友達がいてくれた方がいい。

この二つは異なるのだ、ということ。これは結局、Scrapboxでも「プロジェクト」の切り分けで実現されている。一つのプロジェクトは地区の住所みたいなもので、時系列の並びならば山田さんの隣には鈴木さんが並んでいる。しかし、山田さんページが開いたら、その関連性にはページの性質に応じたものが選ばれ、単に時系列での前後のページは出てこない。逆に言えば、くっていくページ、という概念はそこにはない。

このように一つの情報に対する関係性はたくさんのタイプがありうる。

ある本があるとして、その本に関係している本というセマンティックなつながりもあるし、その本の前に読み終えた本というクロノロジカルなつながりもある。それを一応区別していこう、という感じがよいだろうか。

＊　＊　＊

まあ、本文中にIDがつかめる情報が残されているならば、そこから属性を事後的に生成することもできるので、今はこれを考えないようにしよう。

あるページに書名リンクを埋め込んだら、そこからpinが送られる。そういう形でいこう。

書名リンクは『hoge』と大胆にしてしまってもいいが、普通に[『hoge』]とブラケットで囲んでもいいだろう。保存ボタンが押されたら処理が走って、それがパースされる、という寸法。ダブルブラケットはページが開いてしまうので、そこは一応変えておく（最終的に統合することもありえるかもしれない）。というか、これはもうTextboxとは別のツールを作っているのかもしれない（なんだかそんな気がしてきた）。

基本的にすべてjsonでデータを扱っているので、mdで情報を扱うTextboxとは路線が異なっている。一応そのことは念頭に置いておいこう。

＊　＊　＊

好ましい動作としては、本文中に項目リンク（と呼ぶことにする）があったら、それがクリックできて、それをクリックしたら該当項目の詳細が表示される、というもの。「戻る」の動作などをどうするのかは考えないといけないが、そのような表示の移動が求めている機能。

つまり、指定されたIDに応じてページの詳細を開く、という機能が必要。でもってこれはbooksで本をクリックしたときに詳細を開く、というのと同じ機能と考えていいだろう。

あとはその機能（関数）をトリガーするためのクリックイベントをその項目リンクに付与すればいい。

ただ、ブラケットがシングルとダブルである場合、置換に気をつける必要がある。まず、二重を先に処理して、残ったものに一重の処理をする、という形にしないと、二重の方が無視されてしまう。そもそもこのやり方がバットノウハウという気もするので、ちょっと考えたいが、マークダウンだって#の数で重みを変えているのだからそれはそれでいいのかもしれない。

[『書名』]のような情報が入力されたら、pinを送るのはいいとして、本文データもこのまま保存するのか、それとも『書名』(ここにID名)のような本文に変換し、表示の際にその記法を利用して項目リンクにするのか、はちょっと考えておきたい。まあ、本文にID名を埋め込むのはちょっと違う気がするな。

＊　＊　＊

とりあえずは、項目のIDを受け取ったら、その中身を表示する関数ですね。historyにあるのかbooksにあるのかでもちょっと変わってきそうですが、まずはどこか限定してその機能を書いてみましょう。

12:00

Textbox:

詳細の表示について。

表示はモーダル表示がよいだろう。で、現状inputboxはモーダルを使っているが、それを使い回すか、新しく作るか。

たぶん、UIが大きく変わるだろうから新しく作ったほうがいいかもしれない。tempaleteタグなどを使って。

モーダルの下地（黒色の固定背景）だけを作っておき、それはdislpay:noneにしておく。何かアクションがあったら、そのテンプレートから中身をコピーして、下地をblockに変更する。で下地にappendする、的な。