情報大工のひとりごと

情報デザイン業務の周辺で思ったこと、そして考えたこと

分散を前提とした知識ネットワークの可能性

2003年09月20日

内容的に前回の続きになりますが、何かについての情報や知識をネットワーク経由で入手するためには、「散逸した関連情報をどうやって結びつけるのか」「それらの情報の関係を巨視的に把握できる仕組みをどのように用意するか」ということが、今後は(それだけでなくこの瞬間も)主要な問題となってくるはずです。検索エンジンの能力も上がってきているとはいえ、「検索結果にもっと精度が欲しい」「複数の検索結果の関連性を事前に確認できれば」と思うようなケースが実感として増えてきています。

つまり、ネットワークを知識ネットワークとして捉えると、まだまだ力不足な面が大きいのです。現状のシステム・考えかたは前述のような点がもともと弱い上に、対象となる情報量は増加する一方なのですから、これはある意味当然のことです。情報アーキテクチャの課題ではWebサイト単体(とそのサイトが関わるコミュニケーション全体)で完結する話が多いのですが、知識ネットワークを構築しようとするのであれば、ネットワーク内のリソース全体を見渡して考える必要が出てきます。この辺の課題に関してはセマンティックWebというアプローチがあることは重々承知していますが、コンセプト自体をいまいち信用できないこともあり、別の方向から少し考えてみることにします。

TrackBackがうまく機能すれば、個人による情報発信が分散ベースの巨大メディアとして浮かび上がる可能性が大きくなる」と前回書きましたが、これは別にすべてのコンテンツがblogツールベースに移行するべきであるとか、このような世界はblogツールベースでしか実現できないということとは異なります。現在利用されている通常コンテンツでTrackBackのようなシステムをサポートする方法でも、それなりの効果を期待できるからです(その意味で、blogツールとTrackBackというシステムは分けて考えるべきであり、blogというツール/システムそのものに過剰な期待はしていません)。

ただし、これではTrackBackの使われかたがある一定の流儀に沿っていないと、あとから適切な形で関連性を切り取ることが困難になります。例えば「特定記事そのものに関する言及」をTrackBackと捉えるのか、それとも「特定記事が対象としている領域についての言及」をTrackBackと捉えるのかでは、対象となる情報の範囲がまったく変わってしまいます。他にもディープリンクですら紛糾する(苦笑)こともある以上、TrackBackを中心に置いて情報(知識)のネットワークを生成することは難しい面もありそうです。そうなると、コンテンツを置いている個別サーバー側で関連情報をやり取り・管理するTrackBackよりも、コンテンツ内のアンカー要素を抽出したメタ情報を集約して利用するようなアプリケーションの方が、情報の関連性を示す目的には効果的なのかもしれません。

とは言うものの、それじゃあ今までの検索エンジンと同じで、情報を集中管理していることに変わりがないのでは?とも思えます。確かにこのような方式では、優れた知識を分散系で持ちつつ、一体の知識として利用するというメリットが薄れてしまうケースが出てくる可能性もありそうです。そうすると、閲覧したWebページのキャッシュデータからメタ情報を生成して、その情報をP2Pで共有→何らかのアプリケーションからそのデータを利用する、というような方向が本命になるのでしょうか?(う〜ん)

まあこの話はそんなに簡単に結論の出るようなものではありませんので、これからも機会をみて取り上げていきたいと考えています。

関連記事(TrackBack)

この記事に言及する(Trackback URL)
http://www.laplace-lab.org/cgi-bin/mt/mt-tb.cgi/9

皆様からのコメント

この記事についてのコメントをお寄せください










名前、アドレスを登録しますか?






トップ | 新着情報 | 研究発表 | ひとりごと | 業務案内 | ご意見箱 | リンク集
このサイトについて | ご意見・ご感想はinfo@laplace-lab.orgまでお寄せください
©1996-2006 ラプラス取説研究所
ラプラス取説研究所のトップページに移動
#
新着情報のページに移動
#
研究発表の一覧ページに移動
#
情報大工のひとりごとに移動
#
ラプラス取説研究所の業務紹介ページに移動
#
ご意見箱に移動
#
リンク集に移動

新着記事(最新5件)

記事のジャンル

過去記事

アンテナ・ブックマーク

RSSフィード RSSフィード
Powered by MovableType 3.2