無印吉澤（※新エントリはhatenablogに掲載中）

■[年表][SBM]繋がりの多様性を特徴とする「ソーシャル年表サービス」の提案

以前の日記（2005/04/26）で、僕は「ソーシャルブックマークサービス（SBM）はWWWのオーバレイネットワークを形成する技術だ」という話を書きました。

今回はその考えを更に発展させて、WWWのオーバレイネットワークを形成する道具として「年表」を使うことを提案します。

つまり、個々人がネット上で簡単に年表を作れて、更に、それらの年表を集めて自由に再構成できるサービスがあれば、年表はブックマークよりも効果的にウェブサイト同士を繋ぐことができるのではないでしょうか？　それをここでは仮に「ソーシャル年表サービス」（ダサイですけど他に思い付かないので）と呼ぶことにし、その基本的なコンセプトを公開してみます。

■ 年表の定義

ねんぴょう【年表】
歴史上の出来事を年代順に記した表。

三省堂提供「大辞林 第二版」より抜粋

一般的には、歴史に限らず、特定の事柄に関連した出来事を時間の流れに沿って並べたものが年表と呼ばれています。出来事については、その日付と短い記述が付いているのがお約束でしょう。

しかし、今回はネット上で公開する年表なので、その定義を少し拡張します（以下の定義がこの構造がホントに良いかは全然分かりません。あくまで仮ということで）。

• 年表は2つの構成要素（タイトル、出来事）から構成される。1個のタイトルと、1個以上の出来事を含む。
• 出来事は4つの構成要素（日付、記述、タグ、関連サイト）から構成される。1個の日付、1個の記述、0個以上のタグ、そして0個以上の関連サイトを含む。

（クリックして拡大）

そのデータ構造を簡単に図式化したのが下の図になります。このように年表も出来事も、作った人に関連付けられます。

（クリックして拡大）

年表が扱うものとしては、個人や、集団（国とか会社とか）、文化、科学技術に関する歴史などが考えられます。それらを簡単に作れるようにするだけでも十分に需要がありそうですけど、それらを組み合わせることで、思わぬ繋がりを生んだら楽しいのでは……というのが今回のアイディアのポイントです。

■ 年表のmixから生まれる繋がりの多様性

年表の組み合わせ方と、それによって生まれる繋がりの図を見ながら、ソーシャル年表サービスにおける繋がりの多様性を見ていきます。図中のアルファベットは、それぞれ以下の構成要素に対応しています。

• P : Person（人）
• C : Chronology（年表）
• E : Event（出来事）
• T : Tag（タグ）
• W : Website（関連サイト）
• D : Date（日付）

1. 年表（C）の継承関係による、人（P）同士の繋がり
誰かが作った年表を組み合わせて、新しい年表を作れるようにします（これを「継承」と呼ぶことにする）。例えば、Aさんが作ったKaZaAの年表と、Bさんが作ったSkypeの年表を継承して、CさんがSkypeのCEOの年表を作ったケースでは、以下のような繋がりができあがります。

（クリックして拡大）

2. 出来事（E）の二次利用による、年表（C）同士の繋がり
誰かが作った出来事を、自分の年表で二次利用できるようにします。例えば、Bさんが作ったSkypeの年表からSkype for Pocket PCに関する出来事を取り出して、Cさんが自分のPDA年表に組み入れたケースでは、以下のような繋がりができあがります。

（クリックして拡大）

3. 関連サイト（W）の共有による、出来事（E）同士の繋がり
先の定義から、出来事にはその関連サイトを含めることができます。そのため、関連サイトを介することで、異なる年表に含まれる出来事の間でも、以下のような繋がりができあがります。

（クリックして拡大）

4. タグ（T）の共有による、出来事（E）同士の繋がり
先の定義から、出来事にはタグも含めることができる*1ため、出来事の間にはソーシャルブックマーク（ソーシャルタギング）と同じような繋がりができあがります。

（クリックして拡大）

5. 日付（D）の近接による、出来事（E）同士の繋がり
年表とブックマークの最大の違いは、多分これです。同じ日付、または同じ時期（前後1週間など）に発生した、という日付の近接によって、出来事の間の繋がりを見ることができます。

（クリックして拡大）

■ その他のポイント

Wikiとの違い。
当初、ソーシャル年表サービスの元の案を考えている時点では、「大勢の共通作業で年表を作る」ことを目的として「Wikiのように1つの年表をみんなで編集する」というアプローチも考えてみました。ただ、Wikiの場合はカテゴリ分け――Wiki単位でのテーマ分け、またはその中でのフォルダ分け――がどうしても固定的になってしまうので却下しました。それよりは、1つ1つの出来事の作成者を明確にして、その組み合わせを誰でも自由に出来るようにしたほうが、多分柔軟で楽しいと思います。

メタ情報の手動入力を促す。
結局、今回の話は「年表というフォーマットは意味情報を手動入力させるのに適しているのではないか」という提案です。これはソーシャルブックマーク（ソーシャルタギング）も同じ視点だと思いますが、意味情報をいかに自動抽出するかを考えるのではなく、意味情報をいかに手動入力させるかを考えるのはいろいろ面白そうです。

時間経過に強い。
ソーシャル年表サービスは、扱うデータ（出来事）に日付の情報を組み込んでいるため、時間経過の影響を受けにくいというメリットがあります。SBMでは「注目された時期」を利用してランク付けせざるを得ない一方、ソーシャル年表サービスでは「出来事の発生した時期」を利用したランク付けが可能になります。まあ、これはどちらが良いという類の問題ではなくて、両者は性質の違うもの、と考えた方がよさそうですけれど。

■ 課題、というより改善の余地

最後に、今回この日記を書いていて気付いたソーシャル年表サービスの課題を並べておきます。

まず、入力が面倒です。
他の人が作った年表、出来事を二次利用して年表を作るだけならともかく、自分でゼロから年表を作ろうとすると編集の手間がかなりかかりそうです。下手をすると、二次利用する出来事を探すだけでも、要素間の繋がりが多すぎるせいで手間になる可能性もあるかも（後述に関連）。対策としては、ブログから年表を自動作成できるようにするとか、年表形式のブログツールを作る（「年表モード」みたいな）といった案が思い付きます。

更に、閲覧も面倒です。
繋がりが多くなることで、どこまでもダラダラと眺めていく分には楽しくなりそうですけど、目的を持って何かを探したいときには適切なインタフェイスが無いと辛そうです。上で書いたようなグラフを可視化するという案は思い付きますけど、その手のサーチエンジンが全然流行ってないのを考えると……うーん。

最後に、ライセンスの問題があります。
このサービスは、年表や出来事といったコンテンツが単体で存在しているだけではあまり意味が無くて……それらがmixされることを前提として成り立っているため、コンテンツの二次利用に関するライセンスをどうするかが重要になりそうです（ブックマークよりは創作性がありそうですし）。この手の話ならCreative Commonsを採用すればうまく行きそうなイメージがありますけど、専門家に聞いてみないとよく分からないですね。

----

僕にはこういうWebアプリを作るスキルは無いので、コンセプトだけ紹介してみました。一応自分でも調べてみたのですが、既に似たようなものがありましたら是非教えてください。割と切実に欲しいです、こういうの。

----

（2005/06/08追記）
もう少し実装寄りの話をまとめた2005/06/07の日記（年表ウェブの構成要素）へ続きます（「ソーシャル年表サービス」から「年表ウェブ」に改名しました）。