「TrackBackはもうなかったことにしてはどうか？」とは？

そんなにセンセーショナルなことを書き逃げしたつもりはなかったのだけど、ちゃんと書いておかないと誤解されると思ったので書いておく。

そうそう、TrackBackはもうなかったことにしてはどうか？
Ogawa::Buzz: Movable Type 4ベータテスト

5年前にはブログのキーフィーチャーのように語られていたTrackBackだが、end-to-endで特定のプロトコルで通知する仕組みは古臭い。直接的には送信者と受信者しか感知し得ないという意味でちっともWeb 2.0的でないし、単なる通知にしては受信側のリソースを食い過ぎる。一応Movable TypeのTrackBack実装にはエントリーに関連付けられたTrackBackをRSSフィードとして取り出す機能があるが、あまり知られているようでもない。

Web 2.0的な発想からより自然だと思えるのは、URL間のlinkageを提供する外部サービスを実現して、ブログからは適当なAPIを用いてそのlinkage情報を利用するようにする、というモデルである。このモデルが優れているのは、linkage情報の収集やそれに含まれるスパムをフィルタするための負荷が利用者の負担とならないということと、リソース・エフォートが集約できるということである。linkage graphを利用した新しいアプリに利用できるかもしれないし、そのgraph構造自体がスパムの発見に利用できるかもしれない。もちろん、任意のURLが(TrackBackに対応しているいないに関わらず)擬似的にTrackBack-enabledになるという利点も見過ごせない。

実はこうした外部サービス(の類似物)は、すでに存在している。

例えば、はてなブックマークの「このエントリーを含むほかのエントリー」機能は、エントリー間の言及関係に基づいてlinkage情報を生成・表示する。残念なことにこの情報のみを取り出すAPIは用意されていないようだし(あったらゴメン)、言及しているエントリーがブックマークされないとリストされない。

また、Googleなどのブログ検索もエントリー間の言及関係に基づいてlinkage情報を生成・表示することができる。例えば、このブログに言及しているブログは link:blog.as-is.net - Google ブログ検索で検索でき、そのフィード(RSS, Atom)URLを一種のWeb APIとして利用できる。Yahoo!ブログ検索でもほぼ同等の機能が提供されている(Yahoo!ブログ検索 - 「http://blog.as-is.net/」の検索結果)。Google AJAX Feed APIと組み合わせれば、フィードはサーバーサイドにキャッシュされ、便利なレンダリングライブラリも利用できるのでとても都合がよい。

ここに挙げたものは、いずれも「エントリー間の言及関係」を機械的に取得するインタフェースとして利用するのにすでに十分であるか、あるいはほんのわずかな拡張だけで十分利用可能なことが分かるだろう。

一方で、TrackBack protocolとそれを利用するレガシークライアントの普及度を考えると、もう少しstraightforwardなやり方もある。つまり、引数に対象URLを取るスタンドアロンなTrackBackサーバと、URLをキーにしてTrackBackフィードをRSSやJSONで返すサーバをペアで提供すればとりあえず事は足りる。ブログ側ではTrackBackフィードを定期的に取得してレンダリングするか、JavaScriptでオンデマンドにレンダリングするかすればよい。誰でもTrackBackフィードを利用できるようにしておけば再利用して新しいアプリも実現できる。なんて2.0!

もちろん欠点もないわけではない。最も重要な点を挙げるなら、サービス側に多大なリソースが必要となるために誰でも簡単にサービスを開始(あるいは維持)できるわけではないことだ。だからこそ競争相手が少ないとも言えるし、だからこそTrackBackフィードに広告リンクを混ぜればビジネスモデルとして成立するとも言える。

実はこのモデルはユーザの負荷を外部サーバにオフロードすることによって利便性を提供しているという点でFeedBurnerと似通っている。誰か立ち上げてGoogleに買われるまで頑張ってみては(嘘)!!

2007-06-12追記:
「Googleのブログ検索ではブログの代表URLに検索結果が集約されてしまう」と書いていたけど、それは誤りだったので本文を訂正(Thanks: はてなブックマーク - Fuktommyが後で読む / 2007年06月12日)。Google AJAX Feed APIへの言及も追加。

FeedBurnerは何も隠していないと思うよ

FeedBurnerは超重大な事実を隠してる - たねちゃんズ12

それは言いがかり…だけど、NASAばりに○○の存在をひた隠しにしなければならない団体に準えるセンスには脱帽。

自然に考えてこれはFeedBurnerが悪いのではなくて、Yahoo! Japanが悪いのだろう。ブログとフィードのURLの不一致があろうとも正しい形式でRSSを生成しているのであればそれを検索対象に含めるのが、「ブログ検索」のあるべき振る舞いだから。

むしろ問題は、

主に以下のような場合は、検索エンジン用ロボットの巡回対象とならないことがあります。 * RSSのアドレスが、ブログや各記事のドメインと異なる（例：外部サーバ上のRSSアドレスを直接参照している）

みたいに単純に技術的要請から生じた(であろうと想像される)留保条項をいつまで継続しなければならないのか、ということだ。

ブログ検索の中身がどうなっているのかは知らないが、基本的にはフィードに対する検索機能を実現するには、あるブログに(時間的・空間的に)複数のフィードが関連付けられているときにそれらのうちどのフィードを信用するかを決定する必要がある。それにはあるパラメータセットを取る評価関数が必要であって、そのパラメータセットには、フィードURL、ブログURL、フィードの更新頻度や最終更新日時、そのブログのlink要素へのフィードURLの記載の有無と時間的分布などが含まれ得る。で、評価関数はそれらのパラメータを使って各フィードのランク付けを行う。まあそんなとこだろう。

そういう前提があるものとして、ではなぜブログURLとフィードURLのドメインの一致・不一致が問題になるのか(≒「留保条項」が存在するのか)をちょっと考えてみると、まずあるブログに関連付けられるフィードは無限個存在するという事実がある。あなたがあるフィードを提供していたとすると、第三者がそのコピーフィードや若干加工したフィード、あるいはエントリーのURLのみをコピーした中身は出鱈目なフィード、を別のURLで公開することは際限なく実施できるから。で、その無限個存在するフィードのうち、ブログURLとドメインが一致するフィードの信用度はより高いとするだけの蓋然性がある。なぜなら両者のURLの所有者が同一であると考えられるから。これに対して、不一致の場合には、濫造されたフィードか、FeedBurnerのように本来は(暗黙的に)信用に値するフィードかを区別する手立てがなければ信用度は一律により低くするより他ない。

当然この基準に基づいて信用度が低くなったフィードであったとしても他のパラメータセットによって相対的に最も信用度の高いフィードとして選択されることはあり得る。だから、FeedBurnerを使っていてブログ検索に掲載されないサイトもあれば、問題なく掲載されるサイトもある、ということになる。

一方で、こういう疑問もある。「留保条項をいつまで継続しなければならないのか」という疑問に通底するのだが、このようなアルゴリズミックなエフォートと、プロトコル的なエフォート(単純に現時点でのブログのlink要素を信頼してフィードを確定する方法)の、いったいどちらがより優れた結果をもたらすのかという疑問である。現状では前者が後者を上回る結果をもたらすのだろうか。それとも実際にはlink要素を使っていないフィードがあまりに多くて検索対象となるフィードが少なくなり過ぎる(=coverageが下がり過ぎる)のだろうか。

門外漢なりにいろいろ技術的な困難さは想像してはいるのだけれど、日本のネット人口のブログユーザ率は他国に比べてかなり高いそうだから、この問題の解決は是非日本人の手で達成されるといいよねー。

追記:
Typoがあったので修正しました。

超シンプルなブログサービスTumblr

超シンプルなブログサービス、Tumblrを始めてみました。

tumbling pointers

ブックマークメモ用。Google Notebookでもいいのですが、もっさりしているので。

テンプレートをいじってみたのですが、自由度が低すぎますね。各エントリーのtitle要素を変更する程度の簡単な改造も今のところどうやったらいいか見当がつきません。わたしがやった改造は、↓くらい。

{block:Link}
    <div class="link">
        <a href="{URL}" class="link" {Target}>{Name}</a>
        {block:Description}
            <span class="description">{Description}</span>
        {/block:Description}
    </div>
    <ul>
        <li><a href="http://b.hatena.ne.jp/entry/{URL}">はてなブックマークで他の人の意見を読む</a></li>
        <li><a href="http://b.hatena.ne.jp/append?{Permalink}">このエントリーをはてなブックマークに追加する</a></li>
    </ul>
{/block:Link}

ブログバトラー、始めてみた。

流行っているみたいなので、ブログバトラーを始めてみた。

これだけだとなんなのでバトラーをリストするページを用意してみた。

BLOGBATTLERS COLOSSEUM

対戦相手を見つけるのが楽になるんじゃないか…っていう本当に本当の小ネタ。

Structured Bloggingについて思うこと

Structured Blogging的な話が盛り上がるのはとてもよいことだ。このエントリーではStructured Bloggingに関して私の思うところを述べる。ちなみに私はStructured Bloggingのコンテキストで述べられているような共通のデータ交換形式にはさほど興味がない。その試みは…多分またしても…思ったよりうまく行かない予感がする、XMLフィードに挿入するようなMicro Annotationを除けば。私が興味を持っているのは、Blogging SystemがStructured Dataを扱うことができるようになることでプラットフォームとしての機能を増すこと、である。

Structured Bloggingとは- at Syndicate - Speed Feed [ITmedia オルタナティブ・ブログ]

一年くらい前にSAKKに行ったときに平田さんとももっと構造のあるデータを扱いやすいようになれば(あるいはそのプラットフォームにMovable Typeがなれば)、ビジネス面でのBlogの利用価値がもっと向上するのではないか、とそういう話をしていたのを思い出した。いずれ向かう道としては非常に正しいと思う。

最近のMovable TypeのバージョンやWordPressではStructured Bloggingにあるプラグインが使えるし、宮川さんが紹介(RightFields - Turn your MT into Google Base!: blog.bulknews.net)しているようにRightFieldsというプラグインもある。CustomFieldsもあるけどね。また、Google Baseだってそのインプリメンテーションのひとつだという言い方ができる。

これらはいずれも、単にタグや位置情報やお天気情報をBlogの記事に付与するというだけのToyな「構造」だけでなく、本質的に「構造をもったデータ」として格納しておき、それらを加工して、Blogや他の形態での「ビュー」を与えられるということである。

さて、これらの共通の問題はスキーマの拡張性やデータベース機能がほとんど、あるいはまったくないということである。例えば、映画レビューBlogをStructured Dataとして格納したとして、後からスキーマに一個レビュー項目を追加したくなったらどうするのか。映画レビューBlogと俳優データBlogがあったとき、それらを連携したくなったらどうするのか。賃貸アパート・マンションBlogとレストランガイドBlogを連携したくなったらどうするのか。現状いずれにしてもその手段がない。

かなり構造データ指向であるはずのGoogle Baseだって事情はそんなに変わりがない。データベースを横断的にアクセスしようとしても、タグかラベルのような比較的ルーズな方法しか用意されていないように見える。また、スキーマに変更があれば再度バルクでアップロードし直してくれ、というアプローチのようだ。「タグやラベルで十分じゃん。アップロードし直しでいいじゃん。」という意見ももちろんあろう。しかし、従来のBlogやブックマークの場合にはたまたまタグ以外に構造データがなかったのでそれなりに使えるように見えていただけだとも言える。実際に特定のデータ型を持つ特定のフィールドをキーにexact matchを取れるのと比較すれば(あるいはspatialなデータのハンドリングなどを考えてもよい)、圧倒的に精度も信頼度も低いだろうことは想像に難くない。またFTPによるアップロードインタフェースはGoogleの産物とは思えないほどアナクロだ。

要するに私が言いたいのは、Structured Bloggingに現在本質的に不足しているのは結合演算や副問い合わせを含めたデータベース機能である、ということである。JOINすることができれば、別テーブルにスキーマの拡張分を定義すればよいだけだし(Alterしてもよいし)、複数の異なったStructured Blogを連携するのも実現できる。

もっとも外部からのアクセスメソッドをちゃんと定義してくれさえすれば、クライアントサイドで計算するという方法も選択肢としてはあり得るという意見もあろう。しかし、効率の点では圧倒的にサーバーサイドで計算する方が望ましい。また、Google Baseのようなリモートデータベースの場合には一般にクライアントサイドでの処理時間や消費メモリ量が予測できないので、できればやりたくないし、やるべきではない。

さらに言えば。「これからは『2.0』(括弧付き)の時代だぎゃ」「複数のサービスをMash-upするみゃ」とか言っている人たちともこの話は関わりがないこともない。まずサービスとは、入力メッセージに対して出力メッセージを返すプログラムであり、これは入力と出力のメッセージのペアの集合だと見なすことができる。このこと自体は別に新しい考え方でも何でもなく、プログラムの「関数」の数学的な意味を入出力のタプルの集合と考えるのは、Denotational Semanticsの伝統的な手法のひとつに過ぎない。

この抽象の下では、一つのサービスリクエストは一つの入出力データベースへの問い合わせを意味する。独立な二つのサービスを並行に利用する場合には実質的にJOIN演算を行っているのに等しいし、また連携させる場合にも実質的にやりたいことは、他データベースへの副問い合わせや複数の表の結合に帰着するだろう、と。

要は、Structured Bloggingと「2.0」(しつこく括弧付き)でやりたい、やろうとしていることは案外近い。そして両者がよりハッピーになる方法は単にアクセッサを公開することだけでなく、データ統合できるほどの粒度までインタフェースを公開して提供してしまうことなのだ、と思えるのだが…さて。

そこでグリッドの登場ですよ…(嘘つき!!)。

Google Blog Search

Google Blog Search (Find blogs on your favorite topics)

チョー有意義！Technoratiに対するdisadvantageは、今のところCoverageの低さとTag Searchくらい。前者は徐々に改善するだろうし、後者はTechnoratiくらいcoverageがあると使い物にならないという問題がある。

Keyword Searchはもちろん、Cosmos Search相当のことは当然できるし、AtomやRSSも利用できてしまうわけだね。

• Google Blog Search: ogawa
• Google Blog Search: link:as-is.net/blog
• Atom (10 items)
• RSS (10 items)

「後発の強み」の実例を絵に描いて額に入れて飾ったようなもの。

今こそnofollow属性を有効にしよう

今月になってGoogle経由でのアクセスが大幅に減少したブログが多数あるようです。PageRankに変更があったためですが、その原因をGoogleの特許出願^*1が実装されたせいだと(あまりその内容を吟味することもなく)早とちりしたり、トラックバック元の言及リンクがないせいだと誤解したりする人がまた非常に多いようです。

^*1 Googleの新しい順位決定方法のすべて。SEO関係者必読、グーグル特許出願文書全訳 [絵文録ことのは]2005/07/01

Googleが具体的にどの程度あるいはどのように出願内容を実装しているのかは一切不明ですが、トラックバックリンク(外部にトラックバックを送った時に生成されるリンク)に対応するバックリンクがないとトラックバック受信側のPageRankが下がるなどとは一言も書かれていません。書いてあるのは、トラックバックリンクの効果が、履歴情報や、送信側と受信側の内容の関連の有無などによって低減され得るということです。つまり、スパミング行為によって一時的に大量のトラックバックリンクを獲得したり、関連性のないページからのトラックバックリンクを獲得したりしても効果がないようにしようということです。

一方で今回のPageRankの低下は、単純に外部へ送ったトラックバックによってかさ上げされていたPageRankが出願方式およびnofollow属性によって無効化、あるいは適正な水準に是正された影響だと捉えると納得しやすいでしょう。

また、外部からのトラックバックによる受信側のPageRankへの影響は(そもそも出願内容に受信側への影響に関する言及はありませんが)、nofollow属性を付与していさえすれば排除できます。排除できるのであれば、トラックバック送信側のページに言及リンクがあるかどうかは一切関係ありません。

結局のところ私が言いたいのは、

• まずはnofollow属性を有効にしましょう。
• naoyaのはてなダイアリー - Movable Type で言及リンクのない TrackBack ping を弾くプラグイン、ゑBLOG: トラックバックSPAM防止プラグイン自身にPageRankを向上させる効果はありませんし、トラックバックの受信速度を低下させるだけです。言及リンクを含んだトラックバックしか受信できなくなることによって受信側への言及リンクが増え、よりPageRankが上がるような気がするかもしれませんがそうではありません。実際に観測される現象は、トラックバックの受信に失敗しやすくなってスパム・ハム(非スパム)の両方とも件数が減るというものでしょう。言及がないトラックバックをとにかく受け入れたくないという場合にはインストールするとよいでしょう。
  2005-07-14追記: 私自身はそういう意図ではありませんでしたが両プラグインに意味がないという誤解を招く表現になっていました。両プラグインの作者さまには謹んでお詫び申し上げるとともに、今後は誤解を招かないように心がけたいと思います。
• 役に立つエントリーを書いて外部から多く言及されるようにしましょう。そうすることが一旦落ちたPageRankの回復に繋がります。

ということです。

言及したら負けかなと思ってるトラックバックの話

言及したら負けかなと思ってる

のだが(参考)、トラックバックが言及リンクを含まなければならないという気分が醸造(情造)されてきているようだ。それはそれで面白いのだが、嘆かわしいことでもある。

↓の記事を書いた意図の一つは(というか書きかけだが)、トラックバックという機構とその役割を分離して考えられない人々への戒めでもあった。

• Gridable Type構想 (1)
• Gridable Type構想 (2)

繰り返すことになるが、トラックバックはショートメッセージを送受信して保存する機能であり、一義的な効果はNotificationであって、Back Linkの生成ではない。それをどのように利用するかは自明に受信側アプリケーション、受信者の裁量である。つまりは、自動的に自分のブログに表示しても、表示しなくても、寛容に受けれても、激怒しても、それは自由である。

ただ、激怒している人に問いたいのは、あなたは新聞の勧誘員や間違い電話やスパムメールに対しても全身全霊をもって怒りをぶつけるような、そんな「美味しんぼ」の登場人物のように熱い、そして暑苦しい人なのですか、ということなのである。私なら黙ってスルーするけど。激怒に加えて面罵した結果、ブログを止めてしまった人もちらほら見かけるわけで、むしろエゴを貫き通した結果周りに迷惑をかけているのではないかと自省しても損はないくらい。私の言葉とも思えないが、所詮実社会と同様他人に優しく自分に厳しくないと円滑な意思疎通は望めないし、みんなもっと眞鍋かをりから学ぶことがあるように思う。

---

さてここからが本文なのだが、言及リンク派の人々に聞きたいのは「言及リンク」が何で、それを求めることに意味があるかということだ。

ショートメッセージの中身に「言及リンク」を含むことはできないわけだから、ショートメッセージのurlフィールドが指し示すオブジェクトに含まれるa href要素を指していることくらいは容易に想像が付く。しかし、そもそもオブジェクトがHTML文書でない場合にはa href要素は定義されない場合の方が多い。また、仮にオブジェクトがHTML文書だったとしても、(URLとそのトラックバックインタフェースの関係がルーズなのと同程度には)urlフィールドの内容とそこに含まれるリンクの関係はinconsistentで、いつでも好きな時に好きな方法で関連付けを解消・削除できる。また、Basic認証などが施してあって受信側アプリはアクセスできないが人(ブラウザ)はアクセスできるとか、人によって異なる結果を与えるとか、時間の経過とともに異なる結果を与えるとか、非対称性は簡単に作り出せる。極端な言い方をすれば、ショートメッセージとしての用を成しさえすれば、urlフィールドはトラックバック受信側の実装次第では省略できるし、望ましくはないが意味のないものであってもよい。

つまりは、TrackBack Technical Specification自体に定義されていない言及リンクの普遍性は人々が信じるほど確実でない。ちょうど同仕様で定義されているurlからトラックバックインタフェースを自動的に検出する方法が確実であるのとは対照的に。

また、トラックバックの結果生じるリンクと言及リンクによって「相互に等価に」読者の誘導が行われるべきという観点で論じている例も見かけるが、この種の定性的な議論はあまり意味をなさない。なぜなら、Webのリーチのほとんどが検索エンジンやRSSリーダーなどの何らかのアグリゲータに依存していることに加え、トラックバックリンクに比べて直接言及されているリンクがクリックされる確率の方が十分高いと想像されるからである。個人的にはトラックバックをトラックするよりはコメント欄を読む方を好むし、コメント欄にURLがあればトラックバックよりは優先的にトラックする。無論コンテキストが明確だからである。

このように効果が現実には十分に小さいと予測される、あるいは計量可能でない以上、トラックバックはより直截的に著者本人へのメッセージングと同等な意味しか持たないか、それに漸近すると考えるべきである(もちろん過度な一般化は避けるべきだが)。

それでもPagerankが平等に配分されない(?)ことに疑問を呈する向きがあるかもしれないが、その点では言及派の旗色は一層悪いと言わざるを得ない。Nofollow属性によってトラックバックリンクはPagerankの算出に使われないようになる(なった?)以上、言及リンクを求めることは一方的に自分のPagerankを上げることだけを他者に求めていることに等しい、浅ましくも。まあそれを言うなら「トラックバック返し」とかいうのは本当に貧乏くさい発想である。また、「情報ハブ」のPagerankが上がらないからという主張も論理的におかしい、と真のモヒカン族としては指摘しておきたい。なぜなら、情報ハブのPagerankを上げる仕組みをトラックバックで担保しなければならない道理はないからである。

それでも言及リンクを求めることに何か意味があるのだろうか？

…意味がないと言いたい。断言したい。だいたい言及の有無とURLの指し示す情報の持つ価値の大小とは相関しないではないか。

私個人はどのようなトラックバックもウェルカムだし、広報目的も含めてありとあらゆる活用の可能性を否定しないつもりである。そもそもTrackBack Technical Specificationに明示的に言及リンクを含むことが記述されていない以上、それは含まなくてもよいこと、含む必要がないことを意味する。また、仕様書がどうあれ一旦道具が発明されればそれが目的外に使用されることは常にある。言及リンク派がなぜそのことを容認できないのかまったく理解できない。少なくとも私にとって、このトラックバックというゲームの本質は自分側の知りうる情報の量を最大化することにあり、「言及されたこと」を「知る」というのはそのほんの一部に過ぎないか、あるいはまったく情報として価値がない(そんなものはTechnoratiに行けば二束三文で売っている)。

ついでに、言及リンク派は「ディープリンク反対」反対派(ディープリンク擁護派?)を兼ねていることが多いようなのだが、そのことにも私は納得が行っていない。つまり、「ディープリンク反対」というごく情緒的なローカルルールは否定するのに、「言及リンクなしのトラックバック反対」というごく情緒的なローカルルールは肯定するという首尾一貫性のなさに。いやしくもモヒカンの一員を名乗るのならば、主張の一貫性を保つべきことは当然として、技術で克服できないものはないもないと放言して憚らないだけの気概が必要だろう。

最後に誤解を招かないように補足すると、規格準拠性という点ではQuasi-Spam Filter Pluginのようなツールも、言及リンクを必須とする方式もともに規格外である。ただ、前者は規格に準拠して受信したトラックバックをheuristicsに基づいて削除することを手助けするだけである。当然それがユーザーと合意されているからこそ、またその場合にのみ、意味を持つ。同様のことが後者にも言えるのだが、heuristicsとしての根拠と妥当性に疑問があり、本来の目的を損ねる危険性がごく高い。

2005-07-06: 不明確な表現が気になったので若干編集しました。

2006-01-06: ちょい加筆。

温故知新: Livedoor の「未来検索」と「Blogリーダー」

白ピクミンなので久し振りで調子が出ないので毒でも吐いてみます。

Livedoorと言えば、最近はブログを全面に出したポータルのプロモーションを行っているわけなのだが、鳴り物入りでスタートしたように記憶している未来検索は今現在機能しているのだろうか。

http://sf.livedoor.com/blog?blog_id=http://as-is.net/blog/てなURLを叩いてみれば分かるのだが、11月29日以降更新されている気配はない。

2005-06-16追記: 上記URLにアクセスしたら「指定されたブログは存在しませんでした。」と表示されるようになった。多分以前クロールしたデータをExpireさせたのだろう。「未来検索」はFeedburnerのフィードを正しくクロールしてくれないのではないかと思い、FeedburnerのソースになるURLを登録してみたところ、新規にクロールしてくれた。

ではというので未来検索のベースとなるコードを提供したと想像される宮川氏の分(http://sf.livedoor.com/blog?blog_id=http://blog.bulknews.net/mt/)も調べてみると12月21日以来更新されていない。一方ではちゃんと更新されているブログもあるので、平たく言えば仕様上の欠陥があるがそのまま放置されているということだ。サポートページでもサービス開始当初こそ「更新されへんがー」とクレームをつけている人もいたが、最近ではわざわざ指摘する人も稀だ。実用面で言えば、ブログ検索機能なら先発のTechnoratiの方が遥かに安定・充実しているし、検索結果をRSSとして表示する機能なら後発のMSN Search(RSS を使用して検索結果の更新内容を入手する)の方が意味がある。つまりは実用にはならないが、エチュードあるいはコンセプト作品としてわざわざ掲示されているのだろう。

ついでにLivedoorのWebベースのRSSリーダー(名前はなぜかBlogリーダー)にも言及しておきたいのだが、これを使っているというユーザーは現実問題としてどれくらい存在するのだろうか。こちらも未来検索ほどではないがあまり更新されない。私のブログの最新更新日時は4月25日だそうだが、26日(ブログの日)の直前に更新することになっているのだろうかと邪推したくもなるほどに、この遅延は容認しがたいものがある。尤も私はBloglinesの1～2時間の遅延すら容認できない狭量の持ち主である。

それよりも問題なのは画面のレイアウトなのだが。

1024×768の人々の視界:

...。

800×600の人々の視界:

...。なぜだか涙で視界が曇ってきてしまう次第。

私が言いたいことは、つまりは「もっとがんばりましょう」ということだ。

キムブログの全文引用に関して

完全に出遅れてますが、これも年末に書いたエントリーです。

木村剛の書くことが私にとって1 picoたりとも意味があった試しはないので、その内容に関して突っ込むことはしない。私が興味を持っているのは、以下のエントリーに寄せられたさまざまなトラックバックである。

週刊！木村剛 powered by ココログ: 「引用」は「リンク」に対する冒涜なのか？

個人的な意見を述べておくと、まず大方の予想通りではあろうが、標準的な引用規則(引用元を明示すべしとか、引用を必要最小限に留めるべしとか、引用に対して本文が主となるべしとか)を定めてそれを共通に運用することが望ましいという考え方に基本的には賛意を示したい。多く議論されている通り、これらの規則はすでに社会的に「スタンダード」としてのコンセンサスを得ており、運用されてもいる。

が、同時にそうした「Good Citizenshipを構成する」スタンダードはGoodなCitizenの間で共通に運用・通用するものであったとしても、そうしたCitizenshipを積極的にか無作為にか結びたがらないBad Citizenも容易に存在し得る、と考えるのが自然であろう。もう少し踏み込んで言うならば、(否定されるべき存在ではあるかもしれないが)そうしたBad Citizenの存在は、Good Citizenの存在と同程度に「当然」である。専ら全文引用したい人と全文引用されたい人「だけ」からなる奇妙な空間が構成できないわけでもないし(c.f. 専ら匿名投稿したい人「だけ」からなる奇妙な空間=2ちゃんねる)、そうした人々が「引用」に関して一般には通用しない論理を展開するのも自由である。彼らの払うべき犠牲は「信頼し得る情報源ではない」という烙印であるが、実世界では「信頼し得ない」出版物が日々出回っており、かつ(単に活字になっているというただそれだけの理由で)それを真に受ける人々も相当数いるという事実に目を背けることはできない。

むしろ、Winnyのように原著作者の権利の行使を困難ならしめる方法、あるいは不可能ならしめる方法を採っていないかどうかが問題である。木村某はそのような方法は採っておらず、無作為な全文引用を避ける方法(トラックバックしない、不本意に全文引用されたらクレームする)が原著作者には担保されているように見える。もっともその運用の信頼性はまた別の問題としてあるだろうし、トラックバックされた記事以外から全文引用したり、PDFファイルという形態の作品を無断で改変して掲載している例がないわけではない。

さて、こういう話の流れではGood Citizenの溜飲は一向に下がらないわけだが、原則論を繰り返すというのは決して美徳ではないのでここは是非とも抜本的な解決を提案したい。私が提案するのは、木村剛のブログを全文引用する「だけ」のブログをボランティアで運営するという甚だ「ネットワーク社会」らしい解決方法である。つまり、こういうことである。

1. 「原典を明示した上で『引用』されることは、『情報発信者としての名誉』」らしいので、木村ブログを粛々と引用するだけのブログがあってもよい。ゆめゆめ「情報発信者に対する権利侵害」とゴネられることもあるまい。逆に「感謝されるのではないかと推察」されるくらいである。
2. 引用ブログに対してトラックバックする分には原ブログの「引用規則」が適用される心配はなく、したがって無作為に全文引用される危惧もない。

問題はその手間だ。

“Edit This” Bookmarklet

唐突ですが、Editリンクを付けるのはちょっとどうかなー、ちょっとかっこ悪いかなー、と思います。わざわざexploit用の情報を公開しているようなものですから。

私はoobaさんのBookmarkletを「ちょこっと改造」したものを使っています。個別エントリーアーカイブをブラウザで開いている状態でこのBookmarkletをクリックするだけで編集画面を開くことができ、Editリンクがなくても非常に快適です。

bricklife.weblog."いま見ているエントリーを編集する Bookmarklet"

「ちょこっと改造」というのは、些細なことですが、oobaさんのバージョンのままだと「個別エントリーアーカイブ」以外を開いているときに実行するとエラーになる(エラー時のアクションは処理系依存なのでブラウザによっては気にならないかもしれない)のと、XHTML 1.0 Strict対応を考えてコメント用formのname属性を止めてid属性しか振っていない場合には動作しないからです。

このエントリでは「ちょこっと改造」バージョンを示します。それだけではナンですので「簡単”Edit This" Bookmarklet生成サービス」を提供することで、Editリンク撲滅を推進します。

結論から言うと、以下のようなBookmarkletにすればよいだけです(改行していますが一行です)。

javascript:d=document;f=d.comments_form||d.forms['comments_form'];if(f){id=f.entry_id.value;
location.href='http://www.example.com/mt/mt.cgi?__mode=view&_type=entry&id='+id+'&blog_id=BlogID';}

簡単に動作を説明すると、document.comments_formかdocument.forms['comments_form']があれば、formのhidden属性であるentry_idを見つけて編集画面を開きます。なければ何もしません。

上記から自力でBookmarkletを作れる方はそれでよいですが、下の「簡単”Edit This” Bookmarklet生成サービス」でも作れます。念のために申し上げておきますと、このサービス自体Javascriptを使って実現されていますので、このサービスを使ったからと言ってAdminScriptの場所が私に知れてしまうということは一切ありません。つまり、狭義には「サービス」ですらありません。

簡単”Edit This” Bookmarklet生成サービス (Movable Type 3.x用)

Admin Script URL:

Blog ID:

Edit This

使い方

1. Admin Script URL(mt.cgiあるいはmt.cgiをリネームしたCGIのURL)とBlog IDを入力してGenerateボタンをクリックします。
2. 「Edit This」リンクをブラウザのメニューバーなどにDrag&Dropするか、右クリックで「お気に入りに追加」するかしてBookmarkletを保存します。
3. できあがり！自分のブログの個別エントリーアーカイブをブラウザで開いて、Edit This Bookmarkletをクリックすれば編集画面が表示されるはずです。

注意点

• Internet ExplorerとFirefoxでしか動作確認していません。
• このBookmarkletは、Movable Type 3.xの標準個別エントリーアーカイブテンプレートのコメントフォームの存在を前提としています。標準テンプレートを大幅に変更して、例えばテンプレートからコメントフォームを除去した場合には動作しません。HINAGATAテンプレート、小粋空間テンプレートなど代表的な配布テンプレートでは問題ありません。

簡単”Edit This” Bookmarklet生成サービス (多分ココログ用、多分TypePad系)

Admin Script URL:

(ココログの場合、変更不要です)

Blog ID:

Edit This

おまけ! ”Edit This” Bookmarklet (多分JUGEM用)

Edit This (このままDrag&Drop)

もうひとつおまけ! ”Edit This” Bookmarklet (多分livedoor Blog用)

Edit This (このままDrag&Drop)