の作業記録
PTを書く金曜日
- 作業記録の共有
- PT+2-3の執筆
- PT+原稿送信
- 21:00~ブックカタリスト収録
8:00
おはようございます。本日はPT原稿の送信日です。夜からは、ブックカタリストの臨時収録があります。
＊ ＊ ＊
上のように書けば、最上位にあるタスクリストに項目を追加してくれる、という機能があったら便利だろう。でもって、chatGTPを使えば可能だろう。
Textbox:
inputboxを改良というか、拡張します。
＊ ＊ ＊
入力欄を、まずlineモードとCardモードで変化させる、というところまでは検討しました。
で、まずCardモードでは「タイトル欄」があった方がいいなと思います。もちろん、一行目を自動的にタイトルにする手もありますが、あえて「これは違うモードなのですよ」と明示した方が効果がありそうな気がします。
で、問題はタグです。あるいはaddress。これをどう扱うか。
たとえば、「読書日記」はaddressで構わないでしょう。では「漫画」というメディアタイプや「SF」というジャンルはどうするか。これもアドレスにしてしまうか。
addressにすれば、SFだけで抽出ということも可能になりますが、そういう使い方をするものでしょうか。
言い換えれば、SFという抽出は、全体に対して行われることはほぼなく「読書日記」や「買った本」についてだけで機能するものです。つまり、前者をグローバルタグと呼ぶならば後者はローカルタグといえるでしょう。タグにスコープの概念を持ち込んでみる？
仮にそうするなら、データの扱いはどうなるか？
＊ ＊ ＊
book空間、という名前空間を仮定する？
自分の着想に「SF」というタグを付けることはあるか？ アイデアメモ、特にショートショートのネタを思いついたときに、それを分類するために使われることはあるだろう。では、その二つを混ぜて抽出を行うことはあるか？ あまり為さそう。
addressは、名前空間の一番上(root)を指定すると考える。で、それに対応するタグ空間を考える、という流れ。タグの階層構造。
どうやって実装するのかはぜんぜんわかりませんが、面白そうです。で、タグの方は、本文中でもハッシュタグの形で記述できるようにする？
＊ ＊ ＊
情報的には間違いが含まれていなくても、この三つがフラットに並んでいるのはどうにも違和感がある。
では、どのような表記なら違和感がないか。ある意味、違和感がないならばデータ上はフラットに保存されていてもいいかもしれない。名前空間のように異なるドメインを作りスコープを切り分けるのではなく、「この二つはよく一緒に使われている」（あるいは片方があるときは、ほぼもう片方がある）という共起性で関係をマッピングする（自分のコーディング技術では無理だが）。
この考え方は、lineの方にも適用できるだろうか？ そのaddressでよく使われているタグをサジェストする？
＊ ＊ ＊
むしろまったく使われていなかったfromをここで使うか。
たとえば、『あかね噺 4』をfrom欄に入れる。そのとき、まだ『あかね噺 4』なる大本は生まれていない。その場合は、そのデータが生成される。すでに存在しているなら、その書誌情報データに紐付けられる。これならば同じ本について複数回言及することができる。
あるいは、fromは『あかね噺』としてもいい。その場合はそのシリーズを一つの項目として扱うことになる。4という数字はどこかで付与することになるだろう。
自分の感想・日記と書誌データを区別するのかどうか。
＊ ＊ ＊
最初fromは「〜〜についての言及」という意味で、Twitterのリプライのような機能を想定していた。でもって、上記のような使い方も一つの範囲内であろう。ポイントは「いまだ存在しないページをfromに指定できる」ということくらいか。
＊ ＊ ＊
仮にfromをtitle代わりにつかうと起こりうる問題（おそらくは衝突）はあるだろうか。
読書日記については構わない。どれもこれも「〜〜について」の記録だからだ。では、別のものはどうだろうか。たとえば一週間の振り返りは？あるいはそれはcardではなく、残されたpageに相当するのか。
＊ ＊ ＊
「読書日記」と「books（買った本）」は、タグを共有するだろう。そこはある種特別な情報空間が広がっている。自分の中では、ということだが。解像度の高い情報空間と、そうでない空間がある。その空間に沿ったデザインすればいい。
＊ ＊ ＊
「読書日記」と「漫画」と「笑い」が区別されるのはよいとして、「漫画」と「笑い」も厳密に考えれば片方が上層で、もう片方が下層になる。ただし、この「笑い」は他にも「恋愛」や「ギャグ」といったものがあり、それは漫画以外のメディアにも当てはめられる。で、SFの「笑い」と漫画の「笑い」は共に使われる可能性がある。その意味で越境的であり、名前空間をはみ出る。これはむりに階層化しなくてもいいのではないか。
「漫画」を選んで、その中から「笑い」を選んで、というのはあまりにもカテゴリー主義的すぎる。
＊ ＊ ＊
読書日記が形式であるとすれば、メモとは状態である。ある形式に至る前の状態。
＊ ＊ ＊
addressとタグを分離するとして、でもってタグそれ自身は階層化しないとして、そのタグはどのように設定するか。
一つは、タグの入力欄を設けること。これは一番作りやすい。が、面倒さも感じないではない。
Scrapboxのように文中に埋め込む手がある。これは入力者としては非常に助かる。
＊ ＊ ＊
一つひらめきが。タグもアドレス欄に入力するが、そのときに特別な記法を使うのはどうか。それならばinputboxを増やさなくてもいい。
t:漫画 とか #漫画 とする。これは悪くない。
本文中から拾うか、この方式にするか、あるいはその両方か。とりあえず、この方式の実装をちょっと考えてみよう。
＊ ＊ ＊
タグを作成する、という関数を弄る。
＊ ＊ ＊
アドレスとタグを分ける、ということは、jsonにもaddress以外にtagを作る？それかアドレスの中に#tagとして保存しておく？
＊ ＊ ＊
たとえば、『あかね噺 4』という読書日記の中に#漫画や#笑いのタグ入力は必要だろうか。一冊だけの本ならば必要だろうが、これはシリーズであろう。でもって、このタグはシリーズに向けてつけられるものではないか。
となると、読書日記では別に必要ない、ということになる。
読書日記の中で、漫画を読んだものを抽出する、というのはあるだろう。ふむ。ややこしくなってきた。
＊ ＊ ＊
イメージとして漫画やライトノベルは「シリーズ」を単位に持ちたい。ジャンルなどはそこに付与すればいい。あるいは、それを親エレメントとして、それぞれの巻はそれらを"継承"した要素と考えても言い。ともかくメタ情報はそこで管理すればいい。
読書日記はこの二つの情報処理、つまり「まず書誌情報を記録し」、ついで「その本の感想を書く」ということを行っている。普通の本ならばそれで問題になることはあまりない（上下巻の本ですこし問題が出てくる）が、漫画の場合連続が前提なので問題が露見する、ということだろう。
＊ ＊ ＊
あるいは、「書き足していく」という方法もあるか。
つまり「シリーズ」という原本を作るのではなく、まず一巻の記録をつけ、その記録に付け足す形で二巻の記録も付ける。
ではどうやって付け足すか。つまりfromだろう。リプライ（あるいはリプライチェーン）。
「シリーズ的管理」の抜本的な問題は、どれだけそれが情報理念として整合していても、あきらかに面倒だ、という点にある。
しかしこの場合、タグはどうなるのか。「漫画」や「笑い」という情報は、どこか受け持つのか。
＊ ＊ ＊
今年一年で読んだ「漫画」の冊数を知りたいとする（知りたいかどうかは不明）。そのとき、読書日記の個別の項目が「漫画」を持っているのは有用だろう。が、はたしてそんなことを知りたいのだろうか。
買った本リストと読書日記はおなじ表現でよいのか、それとも違うほうがいいのか。あるいはそれぞれが表現のスタイルを変更できる方がいいのか（カードタイプ、データベースタイプなど）。
＊ ＊ ＊
やく2時間考えて、ほぼコードの実装はできず。でも、ロジックはすこし整理できました。というか、どういう問題があるのかが見えてきました。
11:00
Textbox:
漫画本の書誌情報の中に感想を書くのか、二つを別物としてそれらを関連付けるのか。
13:00
Textbox:
方向性が見えてきました。とりあえず、library.jsonかcomic.jsonに漫画の書誌情報を集めていく。で、その感想を書くときには、addressを「読書日記」にして、fromにその漫画の書誌情報が記録されている項目のIDを入力する。
もし、そのIDがimageを持っているならば、その日記のimageもそれに揃えておく、という流れ。これはなかなか難しそう。
そうすると、別にこれはcardではなくlineでも処理できそう。書誌情報から書籍名を持ってくればタイトルが割になりそうです。問題は、inputboxから、その書誌情報の項目のタイトルを探す方法です。
まず、日本語を入力し、対象のjsonから項目をサーチする。で、その項目の情報を持ってくる。imageはこのときにでもピックアップできるでしょう。問題はその「対象のjson」をどう絞り込むか。
fronの当初の想定だと、アイデア台帳などからもリプライ先が探せるようにしたかったのですが、あまりに数が多くなりすぎる。
二重鍵括弧ではじまっていたら本のデータ、とする手もありますが、さて。
＊ ＊ ＊
速度を気にしないなら、対象のjsonは一番手広く持つ、という手があります。次にそうやって探す用のjsonを特別に作る。最後に、addressが「読書日記」なら書誌情報を探す、というようなロジックにしてしまう。この場合、汎用性は落ちますが、そもそも読書日記を書こうとしているのだから、他の場所からfromになることはあまりなさそう。もちろん、映画や音楽の情報はその書誌情報群に含まれているのが望ましいとは思いますが。
あとで、何をどういう方向で実装するのかまとめておきましょう。
＊ ＊ ＊
cardを選んだ場合の保存形式を整える。タイトルとbodyを分ける。
jsonにfromの項目を加える。
fromに入力したら、既存のjsonからインクリメントサーチしてくれるようにする。
だいたいこれができたらOKでしょう。
14:00
断片:タスク管理と仕事:
タスクがうまく整理できないことで仕事の達成率が悪い、という状況はたしかにあるだろう。ノウハウによってそれが改善されることも期待できる。だからといって、タスク管理ができるようになればそれで仕事ができるようになるとは言えない。さらに言えば、タスク管理を追求しすぎることによってむしろ仕事が少しできなくなってしまう可能性すらある。銀の弾丸を求めるのは危険。
15:00
PT:
送信用の原稿を書きましょう。
＊ ＊ ＊
書いて送信しておきました。こうして毎週金曜日に2000字前後の文章を送っていきます。
メルマガ:
原稿を一つ書きましょう。
＊ ＊ ＊
3600文字ほど書きました。