Hyperstrataには引用ネットワークが必須なのではないかもしれない
Hyperstrata について提唱する記事[1]を書いて 1 週間が経った。
この 1 週間の間、記事をいくつか更新し運用を続けてみて感じたのだが、Hyperstrata に必須の要素として先の記事で挙げていた引用ネットワークについて、必須ではないと考え直すに至った。 引用に限らず、もっといろんな方法でネットワークを定義できて良いし、Hyperstrata に必要なのは層の中にネットワークを貼ることであって、ネットワークの貼り方が引用である必要性はないと考え直した。
その考え直した話について以下に書いていく。
Hyperstrataの真の要件
考え直した上での Hyperstrata の真の要件についてまずは書いてみる。
Hyperstrata のコアは、イミュータブル（不変）の記事を積み重ねて、未完成の記事でも良いから公開して、どんどん記事を継ぎ足して層を重ねて執筆していくこと、そしてそうやって執筆した記事の層に何らかのネットワーク構造を張ることである、と定義をし直した方が良さそうだ。
そしてこのネットワークを作るためにどのように記事を接続するか、というのは人によってやり方が違って良いとも思う。 ネットワークをどう実装するかは自由だし、どのように記事同士をつなげたいかによって色々な方法が考えられる。 この方法を引用のネットワークのみに限定する必要はない。
次に、今回私が自分のサイトに取り入れた引用ではない記事同士の接続方法について記載する。
「シリーズ」という引用以外のネットワーク
この Web サイトに記事同士のつながりを作る新しい方法としてシリーズという概念を追加してみた。 記事がシリーズに属していれば下のほうにシリーズのページネーションが追加される。
1 つの記事は複数のシリーズに所属することもできる。 その場合はページネーションのカードが複数表示されることになる。
それぞれのシリーズのページでは、シリーズの記事が時系列順にリストアップされている。
シリーズの前後の記事はつながりがあり、グラフビューにもそのシリーズの前後関係でのつながりは線として描画される。
ひとまずグラフビューでは引用によるリンクと区別はしていないので、グラフビューには引用によって作られる記事同士のつながりとシリーズによって作られる記事同士のつながりの両方で作られたネットワークが表示されている。
この Hyperstrata に引用ネットワーク以外に一連の記事のまとまりを作るというのは、私だけが考えたアイデアというわけではなく先行事例がある。 shivaduke さん[2]のサイト[3]も見ると「Reference」と「Referenced by」のほかに「Continue」「Continued by」という一連の続きの記事のようなまとまりがあるようだ。
（それはそれとして shivaduke さんのサイトはめちゃカッコいい）
「引用」というのは学術論文に引っ張られすぎていたように思う。 Hyperstrata は学術論文ではない。
学術論文であれば過去の関連する論文にはちゃんと言及して、自身の論文の位置づけを明らかにする必要がある。
しかし、Hyperstrata ではより気軽に未完成の記事でも次々と層を重ねていく、というかたちで執筆のコストを下げることを意識したものである。 丁寧に過去の記事を全部さらって関係するものを引用して位置づけをするというのを真面目にやる必要があるとなると、執筆のコストが重くなってしまう。 学術論文を書くときの過去の関連研究を集めてそれらを見ながら自分の研究の立ち位置を定めていくという作業は重要な作業で、ということはつまり引用を正しく行うのは重たい大変な作業でもあるということである。 引用を本当に学術論文などのように運用するのは、Hyperstrata の目的の重たい大変な作業を減らして記事を気軽に書いていくというのには向いていないと言えると思う。
学術論文とは違い、Hyperstrata では書きかけの記事や議論が出そろっていない状態の記事であっても公開していくことが可能である。 そして、それらに対する続きや補足は別の記事として積み重ねて行き、読む人はそのつながりを追いかけて記事を読むということになっている。 この未完成の記事を続きをどんどん追記していくという用途においては引用というよりシリーズ記事という形のほうが適切なように思った。
もちろんシリーズとは別に別の記事を引用したくなることは依然として存在するので引用が必要なくなるわけではない。 引用の形でネットワークを作る仕組みも残しておいて問題ないが、それだけでなくシリーズ記事をまとめるような仕組みがあっても良いのではという感じである。
記事のタグはどうなるか
ネットワークの話とはちょっとずれるが、記事の整理という話では近い話なので、こちらもついでにメモしておく。
タグなどの整理がブログなどでは一般的だが、これもどうするべきかというのを以前に shivaduke さん[2]や hacha さん[4]と話してたので、それも合わせてメモっておく。
そのときは、タグも時間発展するべきだったりするのではないか、という話が出てきた。 ある時点で A と分類していたものが、あとから B だとわかったときに全部を分類し直すかどうかという話があり。 また、自分の分類の仕方が変わった時以外にも、タグにしていたものの名前が変わる（Twitter→X）などでタグの名前が変わりうる流れをみたい場合があるのではないか。
以下の猿人から新人に進化していく、以下の系譜図のようにタグの名前が「猿人」から「原人」「旧人」「新人」と変化しながら全体としては流れがあっても良いのではないかという話など。
https://www.aip.nagoya-u.ac.jp/public/nu_research_ja/highlights/detail/0002919.html
あるいは、もはやタグ検索も諦めてすべての記事をベクトル検索に入れて、検索キーワードを入れたら抽出されるようにしても良いかもしれない。 自分の手で整理しようとするのが大変さの根源であり AI に整理を任せてしまうのも、今の時代なら 1 つの手かもしれない、など。
ネットワークにしろ分類の与え方にしろ、まだまだ考えられる余地は色々ありそうだ。 これが正解というものもないと思うので、その人その人で独自の思想で色々アレンジを加えてほしい。 「これが俺の Hyperstrata や！」というのを各自作っていってほしいという気持ちは変わらないままである。
実はネットワークをメンテするのは嫌いではない？
Hyperstrata の出自が「デジタルガーデンの記事をメンテし続けるのが大変だから」という話から始まっていたはずなのに、私はここ数日は記事のネットワークについて整理をしてばかりである。 これは記事それ自体の内容はいじりたくないが、ネットワークはいじりたいのかもしれない。 記事の配置を整理するのは好きだけど、記事自体をメンテし続けるのはしたくない、というところだったのかもしれない。
Hyperstrata の命名の記事[5]でも述べたが、命名をした当初は、歴史のようにあとから解釈をして編纂するのではなく少しずつ自分で記事を伸ばしていくのだ、という思想があって歴史書的な命名を避けたという話があった。 しかし、こうやって少し Hyperstrata の更新をしてみると、後から記事のつながり自体を編纂することもありえるかもしれないなあと思っている。
記事自体を変化させる必要はないが、そこにどのようにネットワークを張るかは個別の記事とは別のレイヤーの話であり、そちらの整理が苦痛ではないなら整理をしてもよいのかもしれない。 ネットワークは地層をどのように読み解くかというガイドである。 地層自体は変化していないが、どこからどのようにイベントを追いかけて解釈すればよいかという部分のガイドを専門家があとから付け足すような感じなのかもしれない。