• なんと！サイドパネルに水槽がついた(魚付き)アルミケースが登場!! - http://akiba.ascii24.com/akiba/news/2003/03/14/642480-000.html

小さい魚の1、2匹くらいは飼うことが出来そうだけど、藻とか苔が壁面にへばりついたりするのを掃除するのが大変だろうなー。本当に魚を入れてみて、あとでひどい目に遭う人が世の中には1人くらいいるかも。っつーか、どこかのショップがやりそうだな。緑のどろどろ状態になった筐体が捨てられていたり。

tDiaryにTrackBackが実装されて（http://sheepman.parfait.ne.jp/20030315.html#p01）しまったことだし、やっぱりHNS用TrackBackコードも書いておこうかなーと思って漠然と設計を考えてみたんだけど、記事（NEW）単位でいちいちRDFを埋め込むコストを払うのが、とってもいやな気分になった。

HNSの場合は過去ログは、一ヶ月を三期（約10日）でまとめたHTMLのアンカーとして扱うから、そのすべてのNEWにRDFを埋め込むと、過去ログHTMLのサイズがそれだけで倍になってしまいそう。かといって、記事単位をあきらめて日付単位にするのもいやなんだよなー。

というところで、「TrackBackを実装する」のときに考えた、

>システムのTrackBack関連のメタ情報（インターフェースの仕様など）を得るためのAPIも欲しい

ってのを真面目に考えてみたくなった。PingBackみたいにlinkタグ（とheaderの拡張）で表現するのが一番無難かな。たとえば、

X-MetaInfo: http://ishinao.net/WikiLike/metainfo.php

とか

<link rel="metainfo" href="http://ishinao.net/WikiLike/metainfo.php">

とかでメタ情報取得インターフェースを得て、あとはそのインターフェースに対して規定のリクエストを渡すことで、

• サイトがどのようなインターフェース（TrackBack、PingBack……）に対応しているか
• ある記事のRSSアイテムとしての情報
• ある記事に対するTrackBack Ping URL
  • あるいは統合インターフェースに対して直接TrackBackを送信する
• ある記事にTrackBackしている記事のRSS（TrackBack Ping URL?__mode=rssへのエイリアス）

みたいなことが可能になるイメージ。

この手の考えを大げさ方向に推し進めると、Webサーバーレベルでディレクトリ（Webアプリケーション）単位の情報取得APIをサポートしてもらうのが一番だろうな。でもまあひとまずはCMS、特にWeb日記およびblog系ツールを中心に考えてみよう。

• Amazon、Web サービスプログラムをイギリスでも実施 - http://japan.internet.com/wmnews/20030317/12.html

もしかしたら、米国で実施してみたはいいが負担（コスト）がかかる割には利益に貢献しないんで、機会を見てやめてしまおうとか思っているんじゃないかと、ちょっと不安になっていたんだけど、イギリスでも始めたってことは日本でも始まる可能性があるってことだよな。日本でも始まると、書評リンク関連でいろいろ遊ぶネタが出来そうだなー。

• グーグル、インテル、MSが注目するベイズ理論 - http://japan.cnet.com/news/special/story/0,2000047679,20052855,00.htm

最近あちこちで見かけるキーワード「ベイズ（ベイジアン）理論」の解説記事。なるほど基本となるのは、過去の統計から今後の予測を行おうというごくごく当たり前な考え方なんだけど、最近になってそれをコンピュータ上でうまく実現するためのモデルが確立されつつあるという話なのね。

その背景には、コンピュータパワーの増大によって未来の予測に使えるほどのデータ量を扱うことが簡単になり、また、ネットワークインフラが整ってきたことによって大量の情報を収集することが可能になっている、ということがあるわけね。

• tDiary: TrackBack - http://sho.tdiary.net/20030317.html#p01

>「いかにPingBackする側が楽できるか」という視点からなので、やっぱりこの「手動TrackBachフォーム」が出てくるだけだと面白みがないなぁ。手動でツッコミ欄に書いても一緒だし。これって、他のBlogツールからだと自動でできたりするんでしょか?

TrackBack送信側の手間としては、自分のサイトで記事をPOST（作成・更新）する際に、TrackBackする先のTrackBack Ping URLを専用のinput欄にコピーしておくだけです。

記事URLからTrackBack Ping URLを自動的に取得（埋め込みRDFをparse）することも可能なんで（MovableTypeではそれをbookmarklet（JavaScript小物アプリ）で実装しているらしいけど、もちろんWebアプリ側で処理を行うことも可能）、最小の手間としては相手の記事のURL（普通は本文中でリンクに使っているはず）を専用の欄にコピーしてから更新すればいいことになります。

確かに、PingBackの方がTrackBackよりも更新側の手間はかからないかもしれませんけど、私は「TrackBack先URLを専用の欄にコピーする」＝「TrackBackしたいという意志を表明する」というところが結構重要なのではないかと思っています。全自動処理のPingBackと違って、TrackBackの場合は言及行為を筆者が意識して行っていることになるので。

• TrackBackとRefererとツッコミと - http://sho.tdiary.net/20030317.html#p02

>残念ながらTrackBackにはこのエンターテイメント性が欠けていて、どのような序列のサイトからでもTrackBack可能だし、TrackBackされたサイトから見ればどのサイトも平等である

確かに「本日のリンク元」における逆人気投票的なエンターテインメント性はないけれども、ある意見に関する議論をツリー構造的に見渡せる（反響が多い記事が一目で分かる）ことから、どの意見（ツリーの枝）が反響が多いか（子ノードが多いか）という複数サイト（コミュニティ）を俯瞰した人気投票的エンターテインメント性が出てきます。TrackBack Tracerの画面みたいに、どの枝が長く広く続いているのかが一目で見渡せるんで。

>結局、ishinaoさんが考えるTrackback情報を使って、サイト横断的に議論を閲覧できる未来のようなツールが出てきて初めて、TrackBackの有効性が出てくるのではないかと思う

「鶏が先か、卵が先か」みたいな話ですね。ツールが出てこないとTrackBackは有用じゃないけれども、TrackBackが普及していないとツールが出てこない（作る気になれない）。

>日記もblogも刹那的なメディアなんだから

ってスタンスがやっぱり基本でしょうね。P2Pで分散ってのは、ある意味「誰も保証しない」ってことですし。私は、ひとまず目先が楽しければそれで十分です。でも、複数のサイトがスレッド的につながるようになると、リンクの永続性がある程度保証されているサイトに人気が集まったりしそうな気もします。

>zoeさんのリンク先を読むのが億劫という感覚、おれは間違ってないと思う

というのは確かにそうなんですけど、その億劫だという思いを乗り越えて（笑）「いざリンクをたどるときにかかる労力を減らそう」という場合に、TrackBackは役に立つと思います。

• ［WSJ］ 上級ユーザー取り込みを目指すAOL Communicator - http://www.zdnet.co.jp/news/0303/17/xedj_aol.html

GoogleがBlogger買収あたりと絡めて、Google Clientを作ったら、それこそ上級ユーザー御用達クライアントツールになるだろうなー。とふと思った。AOLって日本ではまだドコモとくっついているのかな？

• Opinion新型ノートブックは買い時か - http://www.zdnet.co.jp/enterprise/0303/17/epn04.html

俺がもしも純粋に趣味で一台新しいノートPCを買っていいと言われたら、新しいPowerBookを買うだろうなー。Mac OS Xマシンはとてもいじり甲斐がありそうだ。でも実用で買うんだったら、新しいVAIOノートZかThinkPad T40かどっちかを買うんだろうな。いや、まだSRX7＋大容量バッテリーで十分満足しているから買わないけど。

• もしNetscapeが勝っていたら……？ - http://www.zdnet.co.jp/news/0303/17/cead_cooper.html

>Windowsの意義が薄れていた

確かにNetscape（Webアプリクライアント）＋Java（Webアプリ実装＋Webクライアント実装）って感じになっていたら、マイクロソフトの存在意義はかなり薄れていただろうな。と考えると、マイクロソフトがNetscapeをIE無料配布大作戦でつぶしたのは（企業戦略として）正しかったってことだよな。

>ブラウザのインタフェースはもっと良くなっていた

ブラウザのインターフェースに関しては、IEコンポーネントを使った各種ブラウザとかOperaのジェスチャー機能みたいに、結構革新的な進歩を遂げていると思うんだけど。もしかして、海外ではIEコンポーネントを使った各種ブラウザとかってあんまり栄えていない？　でも確か俺が最初に使ったタブブラウザは洋ものだったはずだけど。ちなみに現在はSleipnir。

>「ハイテクの権威」が変わっていた

現在ビル・ゲイツの言葉なんて誰か真面目に聞いているの？　大局を見る目は相変わらず優れていると思うけれども、でも最近細かい技術の話をちゃんとしてくれなくなった気がする。もうそういうものに対するオタク的興味が薄れちゃったのかな？　.NET Frameworkのクラスライブラリとか、もうちゃんと見ていなさそうだもんな。

>デバイス／アプリケーションが多様化していた

それはNetscapeがどうこういうよりは、SUNがクライアントJavaの普及に失敗したことが一番のポイントなんじゃないか。もしもJavaプロセッサとかがばしばし作られていて、現在のTRONのポジション以上PC未満を埋め尽くしていたら、デバイス／アプリケーションは多様化していただろうな。

やっぱり仕様概略を語って、プリミティブなサンプルを作っただけだと、あんまり分かってもらえないんだろうなー。というわけでちょっと詳しく書いておこう。

キーワードで複数サイトを結ぶ言葉交差点という実験は、関心空間のように「ある言葉（話題）にリンクしている記事を抽出する」という意味とか、あるいは「あるISBN（書籍）にリンクしている記事を抽出する（＝書評リンク集）」とか、あるいは「ページ作者が検索インデックスをメンテする検索エンジン」とか、いろいろな意味（使い道）があるわけですけど、この仕組みを「TrackBack（あるいはPingBack）ルートサーバー」的に使うことも可能です。

言葉交差点で言うところのキーワードには、URL文字列なんかも含みます。だから、単にキーワードとしてTrackBack/PingBack先のURLを登録すれば、ある記事を参照（TrackBack/PingBack）しているURL一覧を抽出することが出来るし、さらにそれらURLを参照しているURL一覧をたどっていくことで、リンク関係を解析表示（ツリー構造化）することが可能になります。

言葉交差点で試している、まったく型付けしないキーワード報告型リンク集ってのは結局、関心空間とかはてなダイアリーとかTrackBack/PingBackとか書評リンク集とか、その手の可能性をすべて同時に成立させるための実験なわけです。ある特定の意味を持つ情報を収集するのではなく、型付けしない雑多な情報（キーワード）を収集し、それをサーバー側で適切に解釈して、意味のある結果としてみせようというアプローチ。

ただし、そのようなアプローチでは、インターフェース設計や情報解析にコストがかかる（型付けされた情報を収集解析するよりも）し、そのアプローチではノイズが除去しきれないであろうというデメリットもあります。

でもまあ、わざわざいろいろな用途ごとにそれぞれのインターフェースを用意する（PingBackとTrackBackと○○と××と……に対応しなきゃ、みたいな）のがあまりにもバカらしい気がするので、型付けされない情報を後から意味のある情報に解釈してみせるアプローチを試してみているわけです。現在のところは、書評リンク系のインターフェースしかまともに作っていないけど。

---

一応言葉交差点に自動POSTするPHPのコードサンプルを載せておこう。Curlライブラリを使っているけど、Queryの形式さえあわせてもらえばどうやってPOSTしてもいい。$urlと$titleは自分のサイト（記事）のもの、$keywordsは\n区切りで複数登録可能。

function DoWordsLinks($url, $title, $keywords) {
$posturl = "http://ishinao.net/wordslinks/regist.php";
$url = urlencode($url);
$title = urlencode($title);
$keywords = urlencode($keywords);
$query = "url=$url&title=$title&text=$keywords&btn_regist=true";
$curl = curl_init ($posturl);
curl_setopt ($curl, CURLOPT_POST, 1);
curl_setopt ($curl, CURLOPT_POSTFIELDS, $query);
curl_exec ($curl);
curl_close ($curl);
}