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

■[SBM][SNS]「同質的」という単語の意味 / SBMはロングテールの敵か？

前回の日記には個人的にいろいろ気になる点があったので、主に2つの点についてセルフつっこみしておきます。
（突っ込まれると思っていたら誰も反応してくれなかったので。SNS関係のサイトにもことごとくスルーされるし……）

----

1つ目は「同質的」という単語の意味について。

自分で言うのもなんですけど、前回の日記は途中までは論理的に書いてあるものの、最後の章（「■ SBMのネットワークとSNSのネットワーク」以下）で「SBMのネットワークは情報交換に適している」という印象を理由付けするために

• (1) SNS（ソーシャルネットワークサービス）のネットワークは同質的
• (2) 逆に、SBM（ソーシャルブックマーク）のネットワークは分散的
• (3) 情報交換のネットワークには分散的で多様性のあるネットワークが適している
• (2)と(3)により、SBMのネットワークは情報収集に適している
• (1)と(3)により、SBMのネットワーク形成にSNSの特性（同質的）を利用するのは逆効果

という、かなり乱暴な論理を展開していて、個人的にはその気持ち悪さがずっと気になっていました。

前回の日記を読んで僕と同じ気持ち悪さを感じた人がいるとしたら、それは多分僕が「同質的（homogeneous）」という単語を曖昧に使ってしまったせいだと思います。そもそも「同質」という単語自体、辞書にはこんな風に書いてあるくらい曖昧です。

どうしつ 【同質】
質が同じであること。
⇔異質

現在のSBMは主に先進的なユーザ（early adapter）によって使われている、と言われていますが、もしそれが本当だとしたら「人種：日本人」「性別：男性」「年齢：20〜30歳」「嗜好：IT関係に興味がある」という多くの要素で同質な人達によって作られているのが現在のSBMのネットワークなはずです。それが何故面白いのか？

その理由を論理的に説明するためには「情報収集に適したネットワークを形成するためには、ユーザ同士がどの要素で異質ならば良いのか？」という細かい話を出来ないとダメそうですけど、今のところ僕にはよく分かりません……このあたりについては今後も考えてみます。

----

2つ目はSBMのランキング機能について。

del.icio.usやはてなブックマークのような代表的なSBMでは、クリップされたサイトに付随して、そのサイトをクリップした人数を表示する機能があります。

これがある種のランキング機能として働いていて、ユーザから重宝されているのですが……これはSBMのユーザ数が少ない今でこそ有効に機能しているものの、今後ユーザ数が増えるに従って

• 「注目されているサイトがますます注目される」

というベキ乗の法則に従うようになって、一度注目されたサイトはひたすらクリップされるけど、注目されないサイトは内容に関わらずいつまでも衆目に触れないということになってしまうのではないでしょうか？　前回の日記ではランキング機能に触れず、SBMのメリットを「情報収集に適した形でWWWのオーバレイネットワークを形成する」ことと結論づけたのは、そう考えてのことでした。

ロングテール萌えのお兄ちゃん達は、ソーシャルブックマークのことをどう捉えているんでしょうか。気になります。

参考：ロングテールのリンク集
http://harryblog.exblog.jp/1871306

■[書評]コミュニティ・オブ・プラクティス―ナレッジ社会の新たな知識形態の実践

コミュニティ・オブ・プラクティス―ナレッジ社会の新たな知識形態の実践(野中 郁次郎/エティエンヌ・ウェンガー/リチャード・マクダーモット/ウィリアム・M・スナイダー/野村 恭彦)

「自分の知識や見識を深めるために、職場や仕事外でいろいろな人と情報を共有したい」という個人的な問題意識から、最近ではナレッジマネジメント関係の本にも手を出し始めていたのですが、本書はその問題への答えそのもののような内容でした。

僕に限らず、ブログを運営しているような人は多少の知識欲を持っていると思いますが、本書で述べられている「実践コミュニティ」という枠組みは、そのような曖昧な知識欲から具体的な行動を生み出すためのヒントになりそうです。

----

■ 実践コミュニティと、本書のアプローチ

タイトルにある実践コミュニティ（コミュニティ・オブ・プラクティス）*1とは、「あるテーマに関する関心や問題、熱意などを共有し、その分野の知識や技能を、持続的な相互交流を通じて深めていく人々の集団」を表す、ナレッジマネジメント用語です。

実践コミュニティの具体例としては、「特定の技術に興味を持つ人達が、企業内の業務チームの枠を超えて行う勉強会」などが挙げられます。また、仕事に必要なスキル以外のテーマでも、例えば「サッカー教室での試合時間を利用して、子育てのコツや洞察をやりとりする保護者たちのお喋り」のように一般的な知識をテーマとしたものも、実践コミュニティです。

つまり、実践コミュニティとは新しく生まれた特別なものではなく、今までも自然発生的に存在してきた、どこにでもあるものを定義付けしたものと言えます。

しかし、それにも関わらず、何故最近になってナレッジマネジメントの分野で実践コミュニティに対する関心が高まっているのか？　それは、実践コミュニティはそこに所属するメンバだけではなく、その実践コミュニティを抱える組織にとってもメリットがある、と考えられ始めたからです。

• メンバにとってのメリット
  コミュニティ内での継続的な相互交流を通して、あるテーマに関する知識や考え方など（＝実践）を共有することで、メンバは自らの知識や技能を高められるだけでなく、最先端の話題についても活発に議論できるようになる。
• 組織にとってのメリット
  実践コミュニティは実践という形で形式知と暗黙知の両方を蓄積し、それらを他者に伝えるという能力を持つ。そのため、組織（主に企業）にとって必要なテーマ毎に実践コミュニティを育成できれば、それらは組織内の効果的なナレッジ・システムになる。

そこで、今まではボトムアップで自然に発生し発展してきた実践コミュニティを、組織全体のナレッジマネジメントの中核に据えるためにトップダウンでサポートする。つまり、今後は

「組織はメンバーやコミュニティだけでなく、組織自身のためにも、実践コミュニティを積極的かつ体系的に育成しなければならない」(p.44)

というのが本書のアプローチです。

■ 実践コミュニティの構造モデル

実践コミュニティの基本的な構造は「領域」、「コミュニティ」、「実践」という3つの基本要素の組み合わせになっています。

実践コミュニティはそれが所属する組織（企業）によって名称や形態が異なる*2のですが、著者らはそれらのコミュニティに共通した3要素から成る構造モデルを定義することで、実践コミュニティとその他のコミュニティの違いを明確なものにしています。

実際のところ、これらの要素について細かく見ていかないと、実践コミュニティが何なのかはなかなか理解しにくいように感じたので……それぞれの要素についてここで簡単にまとめておきます。

▽ 領域（domain）

領域とは、そのコミュニティで扱うべきテーマの定義のことです。

• 領域は明確に定義される

  • 領域を明確に定義することで、コミュニティの目的と価値をメンバやその他の関係者に確約し、コミュニティを正当化することができる。
  • 領域は抽象的な関心の対象ではなく、メンバが現実に直面する重要な課題や問題から成る。
  • ただし、メンバは領域に対する見解を明確に表現できる場合も、できない場合もある。世界やコミュニティの変化に応じて、領域もまた徐々に発展していく。

• メンバ間で領域を共有する

  • メンバは領域の境界や最前線を理解することで、何が共有するに値するか、どのように自分の考えを提示すべきか、どの活動を遂行すべきかといったことについて、的確な判断を下すことができる。
  • 領域に対するコミットメントのないコミュニティは、友人同士のグループに過ぎない。

▽ コミュニティ（community）

「コミュニティ」とは、特定の領域に関心を持つ人々の集まりのことです。

• 定期的な情報交換の場

  • 実践コミュニティを築くためには、メンバが領域の重要な問題について定期的に情報交換する必要がある。
  • メンバは定期的な相互交流を通して、領域に関する共通の理解や実践への取り組み方法を生み出す。

• 信頼感を醸成する場

  • コミュニティが重要な要素である理由は、学習が理知的なプロセスというだけではなく、帰属意識にかかわる問題でもあるため、
  • 強く結びついたコミュニティでは、メンバが互いを尊重し信頼しているために、自発的にアイデアを共有し、無知を露呈し、厄介な質問をし、注意深く耳を傾けようという気になる。また、意見の不一致があっても結びつきが損なわれず、逆に対立を利用して学習を深めることができるようになる。

• 自由な雰囲気を持つ場

  • 実践コミュニティの成功は個人の情熱に負うところが大きい。そのため、参加を強制しても効果はない。
  • コミュニティへの加入は自発的でも強制的でもよいが、実際に関与する度合いを決めるのは個々人でなければならない。

▽実践（practice）

実践とは、コミュニティのメンバが共有する一連の枠組やアイデア、ツール、情報、様式、専門用語、物語、文書などのことです。つまり、実践にはコミュニティの暗黙知と形式知の両方が含まれます。

• 共通の基礎知識の確立

  • 共有された実践が果たす役割の一つは、ある特定の領域で物事を行うために正規のメンバ全員が習得すべき共通の基礎知識を確立する、というものである。
  • 共通の基盤を確立し、既によく知られていることを標準化することによって、実践コミュニティのメンバは創造的なエネルギーをより高度な問題に傾けることができるようになる。

• 実践はコミュニティに蓄積される

  • 文書やツールとして体系化できる知識（形式知）を共有しても、それを自分の環境に合わせて適用するには、同じような状況に直面する人々との交流から得られる暗黙知が必要（1990年代に、IT主導のナレッジマネジメントが失敗した理由）。
  • 実践コミュニティは知識を単なる物体に貶めるのではなく、メンバの活動や相互交流を通して、実践という形でコミュニティの中に蓄積する。

また、上記の3要素は実践コミュニティを定義する要素であるだけでなく、メンバが実践コミュニティに参加する動機を表す要素にもなっています。

• 「領域」に関心があって、その発展を見守りたいがために参加する人
• 「コミュニティ」に属すること自体に意義を感じて参加する人
• 「実践」について学びたい人

■ 感想

本書（全10章）の構成は、大まかに分けると下記のようになっています。

• 実践コミュニティとは何か（1〜2章）
• 実践コミュニティの育成方法（3〜7章）
• 実践コミュニティを事業戦略に組み込む方法（8〜9章）
• 市民社会における実践コミュニティ（10章）

著者達の主な狙いは後半部分に書かれているのですが、上記のように、僕はむしろ前半の「実践コミュニティとは何か」という辺りに興味を引かれました。まぁ、後半の内容はかなり話が大きくなってしまうので、マネジメント層からほど遠い下っ端の僕には全然ピンと来なくなってしまったというのもあるんですけど……。

これは個人的な話になりますが、技術者として仕事をしたりサイトを運営したりしていると、よく

「自分の知識や見識を深めるために、職場や仕事外でいろいろな人と交流を持ちたいなあ」

と思うことがあるのですが、実際そのためにどういうことをすればいいのかはよく分からなかったりします（最近あちこちで勉強会が開かれているのを見る限り、同じような悩みを持っている人は結構多い？）。そういう時にこの「実践コミュニティ」という枠組みを使うことで、上記のようなアバウトな欲求を

• 知識や見識を深めるには、どのコミュニティに参加すべきか（どれが実践コミュニティか）
• 現在所属しているコミュニティを実践コミュニティに近づけるには、何をすべきか（どうして実践コミュニティになっていないのか）

という問題に落とし込めれば、その問題を解決するために具体的な行動を起こせるようになるのでは？という気がします。もちろん、全てのコミュニティが実践コミュニティである必要はないので……この枠組みをどう使うべきかは、それこそ実践を重ねる中で考える必要がありそうです。

また、その他の部分では、実践コミュニティの形態に関する記述の中で共通性と多様性に触れた部分に、特に興味を惹かれました。

コミュニティという概念には、共通性という意味合いが含まれることも多い。だが、理想的な実践コミュニティが均一的な特質を持つと考えるのは誤りだ。確かに長期にわたる相互交流は、共通の歴史やコミュニティとしてのアイデンティティを生み出すが、それは同時にメンバー間の差別化をも促すのである。それぞれのメンバーが相互交流の中で公式非公式に、違った役割を引き受ける。各人が独自の専門分野や様式を発展させる。（中略）長期に及ぶ相互交流は、共通性と多様性を生み出すのだ。(p.72)

このような実践コミュニティの特徴が、ネットワーク分析の観点からはどう捉えることができるのかを考えてみると面白そうです。

■[P2P]P2Pのキモ

最近仕事場で、ふとしたきっかけから「P2Pとクライアントサーバ（C/S）の違いは何か」、「その違いがサービス、プログラム、今のインターネットにもたらすものは何か」と聞かれることがありました。

で、その時には適切な答えが思い付かなかったんですけど、今後のために現時点の意見を簡単にまとめてみました。

---- ここから ----

P2PとC/Sの違いは何か
→エンドユーザがサービス提供者になることがある

その違いがサービス、プログラム、今のインターネットにもたらすものは何か
→サービス提供にかかる資源（ストレージ、帯域、処理能力など）を削減する

以上から、「エンドユーザにどうやって資源を提供してもらうか」がP2Pのキモになる。これに対するアプローチは以下の4通りに分かれる。

• エンドユーザ1つあたりの提供する資源を増やす

  • PCの高性能化、通信回線のブロードバンド化が既に影響

• エンドユーザの総数を増やす

  • 他のソフトウェアでは出来ないことを出来るようにする
  • ユーザに好印象を与える、ブランド

• サービスに必要な資源を減らす

  • 各種P2Pプロトコル（DHTも含む）はこれが目標
  • オーバレイネットワークの形成・維持に必要な資源を減らす、とも言える

• ただ乗りするエンドユーザを減らす

  • ソフトウェアの内部動作を隠す
  • ソフトウェアによる評判システム（reputation system）
  • ユーザ同士の信頼関係による評判システム

---- ここまで ----

そういうわけで、最近個人的にはP2Pネットワーク上での評判システムに興味を持っていて、EigenTrustの論文*1でも読んでみよう……と思っている内に連休は終わってしまいました……。でもそのうち読みます。

正直、僕自身は「P2P」という単語の厳密な定義なんてどうでもいいと思ってて今までこういう話題には触れなかったんですけど、今回は良い機会なので書いてみました。上の定義はあくまで自分が興味を持っている範囲をうまく括れるものを選んだだけで、他の人の定義を否定するものではありません。こういう目線もある、という程度に捉えてもらえると助かります。

参考：
P2Pを定義する(Fuktommyの倉庫)
http://fuktommy.s64.xrea.com/p2p/definition.html

P2P 技術：オーバーレイネットワーク（2）（Japan.internet.com）
http://japan.internet.com/column/webtech/20050325/8.html

■[英語学習]ITをトピックにした英語学習サイトListen-IT !

Listen-IT !
http://www.listen-it.com/

最近新しく開設された、ネット上で公開されているIT関係の音声ファイルを元ネタにして、英語学習の教材を提供してくれるサイトです。Listen-IT!って何？によると、

語学習得の鍵は継続。誰もがわかっていることですが、なかなか定期的に勉強を続けるのは大変です。Listen it!では、ITに特化し、興味深い最新情報が語られるものを厳選、さらにコンテンツの内容についての解説や、関連するインターネット上の英文記事へのリンクもあるという、「内容そのものも興味深い」ものになっています。これにより、飽きずに練習を続けることができます。

とのこと。IT系の音声コンテンツがネット上に山ほどあると分かっていても、「どれを聞いて良いか分からないしなあ」と手が出なかった人間にはかなりありがたいサービスです。有料でも使いたいくらいかも。

で、早速僕も、利用のてびきと、練習方法についてもう少し詳しく知りたい方へを読んで、早速第1回の教材を試してみました。今回は「ラジオ番組の内容を今後はポッドキャストで募集する」という話です*1。

第1回教材：オープンソース・ラジオ(Listen-IT !)
http://www.listen-it.com/archives/200505102000.php

教材を使った学習は

• 穴埋め問題でリスニング
• 解答の文章をリーディング
• 音声ファイルを聴きながらシャドーイング(shadowing)

という感じで、ここまでは1時間もかからずに一通り終わるくらいの量になってます。ただ、shadowingはなかなかうまくできないので

shadowingがスラスラとつかえずにでき、また、shadowingをしながら、文章の意味が自然と頭に思い浮かぶようになるのが目標です。できれば、一回ずつでもよいので毎日繰り返し、目標が達成できるまで繰り返してください。

というアドバイス通り、次の教材が出るくらいまで毎日繰り返す、という流れで使うのが良さそうです。

これをきっかけに、僕もそろそろ真面目に英語の勉強しようかなぁ……。

■[tDiary]highlightプラグイン（微妙に改造）

この日記のタイトルが、日付リンク時とアンカーリンク時で形式が変わってしまうのが気になったので、以下のサイトを参考に対策してみました。なんだか、ブックマークされた時の見栄えが統一されてないのがイヤで……今更なんですけどね。すみません。

tDiaryのアンカーリンク時にドキュメントタイトルを表示する(tdiary.ishinao.net)
http://tdiary.ishinao.net/20050419.html#p01

highlightプラグインの最新版（version 1.3）をSourceForgeから拾ってきて、

if (highlightElem.tagName == 'H3') {
  var diary_title = "#{@conf.html_title.gsub(/"/, '\\"')} (#{@date.strftime('%Y-%m-%d')})";
  var sanchor_length = #{@conf.section_anchor.gsub(/<[^>]+?>/, '').length};
  var section_title = highlightElem.innerHTML.replace(/<[^>]+?>/g, '').substr(sanchor_length);
  document.title = section_title + ' - ' + diary_title;
}

となっている部分を、

if (highlightElem.tagName == 'H3') {
  var diary_title = "#{@conf.html_title.gsub(/"/, '\\"')}";
  var section_title = highlightElem.innerHTML.replace(/<[^>]+?>/g, '').substr(1);
  section_title = section_title.replace(/^(\\[[^\\]]+\\])+/, '');
  document.title = diary_title + ' - ' + section_title;
}

と修正して適用してみました。substr(1)としてしまっているのは、アンカー文字の「■」をうまく取り除けなかったからです……。あと、Hatenaスタイル限定で汎用性の無い方法なのですが、カテゴリ表示を取り除く処理も追加しました。

というわけで。今後、ここの日記にリンクを張る or ブックマークする際はなるべくアンカーリンクでお願いします。

----

（2005/05/18追記）
カテゴリの記述方法はスタイルの種類に関係なかったですね……。勘違い部分に取消線を引きました。

■[セキュリティ][NAT]WindowsのIPsec NAT Traversalに関する文書

セキュリティホール memo(2005.05.17)経由。

WindowsのIPsec NAT Traversalに関する2つの文書が新たに公開されました（と言っても2ヶ月前の話みたいですけど）。そういえば、はてなから新しいサイト（ここ）に移ってからはあまりIPsecネタを扱ってなかったので、せっかくだからと読んでみました。

（自動翻訳された日本語文がワケ分かんない代物だったので、英語の方にリンクしてあります）

■ IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators
http://support.microsoft.com/kb/885348/en-us

これは「NAT内部で運用しているサーバ（Windows Server 2003）へのアクセスにIPsec NAT Traversalを利用するのは非推奨とする」という内容の文書です。その理由を理解するには、一番下のセクション「Windows XP SP2 does not support establishing IPSec NAT-T security associations to servers」に書かれている事例を見るのが分かりやすいです。以下はその部分の要約。

1. NATの内部にサーバ（以下、サーバ1）が設置され、そのNATは「ポート500(IKE)と4500(IPsec NAT-T)へ向かうトラフィックをサーバ1に転送する」と設定されている環境を考える。
2. まず、NATの外部にあるクライアント（以下、クライアント1）が、IPsec NAT-Tを使ってサーバ1との双方向接続を確立する。
3. 次に、NATの内部にあるクライアント（以下、クライアント2）が、IPsec NAT-Tを使ってクライアント1との双方向接続を確立する。
4. このとき、クライアント1がクライアント2とのを再確立しようとすると、そのためのIKEとIPsec NAT-Tのトラフィックは、NATの設定に従ってサーバ1へ転送されてしまう。つまり、本来クライアント2へ向かうべきトラフィックが誤送されてしまう。

結局、簡単に言うと

client(private IP address) → NAT → Internet → server(global IP address)
って状況以外ではIPsec NAT Traversalなんて絶対使うなよ！　話がややこしくなるから！

というのがこの文書の主張です。

■ The default behavior of IPsec NAT traversal (NAT-T) is changed in Windows XP Service Pack 2
http://support.microsoft.com/kb/885407/en-us

一方、こちらは「デフォルト設定のWindows XP SP2では、NATの外部から内部へ向かう通信ではIPsec NAT Traversalを使えないようにした（レジストラで変更可）」という内容の文書です。上記の文章の意図した内容を実装面でも強制するようにした、という話ですね。

ただし、ここで誤解してほしくないのは、Windows XP SP2でデフォルト無効にされたのはNATの背後に配置されたレスポンダへのIPsec NAT-Tだけで、IPsec NAT-TのイニシエータとしてはNAT内でも従来通り使えるということです。

セキュリティホール memoで紹介された際には「SP2 ではデフォルト無効に変更されたそうです。」というコメントが添えられていたため、正直「マイクロソフトはとうとうIPsecを見捨てたのか？！」とビックリしてしまったのですが、そういうわけではなかったみたいです。早とちりには気を付けましょう。

----

（2005/05/20追記）
デフォルト設定に関する記述が分かりにくかったので、表現を修正しました。

■[年表][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の日記（年表ウェブの構成要素）へ続きます（「ソーシャル年表サービス」から「年表ウェブ」に改名しました）。

■[P2P]Skype勉強会で講演します（8月〜9月頃）

skype conference 2005 JAPANの講師陣について(Tomo’s HotLine)
http://toremoro.tea-nifty.com/tomos_hotline/2005/05/skypeskype_conf_b422.html

skype conference 2005 JAPAN（skype勉強会）の講師陣ですが、大方調整がついたのでご報告します。なお、諸事情等により講師や講演内容が変更となる可能性があります。 いずれの講演者もskypeに関して日本有数の有識者ばかりで、とても貴重な講演が聴けると思います。是非ご期待下さい。

Tomo's Hotlineにて数日前に告知されましたが、8月か9月頃に開催される予定のSkype conference 2005 JAPAN（タイトル言ったもん勝ちみたいな感じで、実体はSkype勉強会）にて僕もちらっと講演することになりました。なんか、他の講演者の顔ぶれが凄いんですけど、いいんでしょうか。

で、Tomoさんからは「P2P-SIPでひとつよろしく」とお願いされましたので、僕の講演では、そもそもSIPとは何かという話から始めて、SIPとP2P-SIPの違い、そしてSkypeに勝てるP2P VoIPを実現するには、といった感じで話せれば……面白いですか？（すいません考え中です）

まだ大分先の話ですけど、これから頑張りますので当日はよろしくお願いします。

■[IPv6]IPv6へ移行しつつあるアメリカの連邦政府機関

Federal Agencies Need to Plan for Transition(The IPv6 Portal)
http://www.ipv6tf.org/news/newsroom.php?id=1175

アメリカの連邦政府機関では新しいプランを契約する際の重要な検討事項として、IPv6への移行プランを要求しているという記事です。連邦政府機関のネットワークにはIPv6対応のソフトウェアや装置が既に存在しており、このような要求が今後IPv6へ移行する際のコストと複雑さを減らす、と述べています。

個人的には、当分の間IPv6は機器制御とか映像配信とか内線電話とか……つまり閉じたネットワークの中でしか使われないのではないかと思っていたのですが、アメリカでは政府が積極的にIPv6への移行を促しているようです。日本の政府機関でも、こういうIPv6への移行を推進する活動が行われるようになるんでしょうかね。