はてなブックマークのタグ編集に Atom PP を用いる件について

» Permanent link | |

楽しそうなので、考えてみることにする

なにはともあれはリソースのことを考えよう。 タグをリソースとするならまずはそれに URI を割り当てなければならない。 僕(yohei) の "atompp" というタグの URI は以下のような形式とする。

http://b.hatena.ne.jp/atom/yohei/tag/atompp

次に考えるのはタグリソースの 表現に何を使うか。 構造を持った情報なので XML になるのはすんなり確定。 問題はその形式。候補は以下のとおり。

最新 AtomPP のメンバー要素(member)

長所: 軽い、簡単

短所: member/@href で参照する先の URL はどの XML 形式にする? あるいはタグ名のテキスト(plain/text)か?

Atom の entry 要素(entry)

長所: 標準。使える子要素がいろいろ定義されている

短所: (他に比べて)重い。ブックマークの dc:subject との違いがわかりにくい

独自要素(hatena:tag or dc:subject?)

長所: 自由。簡単

短所: クライアントにとって扱いが難しい。独自すぎる

ここでは entry がいいのではと思うので、それで進めてみる。 entry を選んだのはそのバランスによる。 たとえば entry の子要素にはもちろんタグの更新時刻や利用回数も入れられる。 タグ名は title に入れるのが素直そうだ。

次はこのリソースに対してどんな操作を行うか。 REST 的に考えると必要そうな操作は取得(GET)、削除(DELETE)、更新(PUT)、新規作成(POST)の四つ。 ま、GET と DELETE は必要だろう。 POST で新規作成はいらなさそうだ(タグはブックマーク時に自動的に新規作成されるので)。 PUT で更新できるのはタグ名くらいかな。 タグにコメントなんてつけられなくてもいいよね。

さて、これでタグリソースは固まった。 今度はタグの一覧を考える。 AtomPP 最新最新版ならコレクションという便利なものがあって、 上記どの種類の XML 形式でもひとつのコレクションとして扱える。 でもここではタグリソースをあえて Atom entry にしたので、feed 要素を使ってみよう。

一覧取得のときに、オフセットや取得数、タグ名をワイルドカードや正規表現で検索などをしたい気もするけど、 そういうのはコレクションリソースの URI の query string でやればよさそうなので、 ここでは単純に全タグ取得を考える。

ちなみにコレクションリソースの URI に適用できるのは GET だけ。

以下に例を書いておく。名前空間宣言や X-WSSE ヘッダとか xml:lang とかは省略してるけど許してね。

タグ一覧取得

GET /atom/yohei/taglist HTTP/1.1
Host: b.hatena.ne.jp

HTTP/1.1 200 OK
Content-Type: application/x.atom+xml

<feed>
  ...
  <entry>
    <id>タグの ID</id>
    <!-- Edit URI へのリンク -->
    <link rel="service.edit" type="application/x.atom+xml"
      href="/yohei/atom/tag/atompp" title="atompp"/>
    <!-- title はタグになる -->
    <title>atompp</title>
  </entry>
  ...
</feed>

タグの一括置換というのは要するにタグ名の変更(=リソース title の変更)と考えて、 EditURI に新しいタグ名を PUT する。

PUT /atom/yohei/tag/atompp HTTP/1.1
Host: b.hatena.ne.jp
Content-Type: application/x.atom+xml

<entry>
  <id>タグの ID</id> <!-- いらんか -->
  <title>新しいタグ名</title>
</entry>

タグの一括削除はタグリソースの URI を DELETE する。

あとはタグリソースが URI を持つようになったので、ブックマークリソースのタグ要素(dc:subject or category)からリンクするのがよさそうだ。

Google Maps でみつけたもの

» Permanent link | |

着陸寸前の飛行機とか走行中の新幹線とか

Microformats の夢

» Permanent link | |

Microformats の嬉しさについて。

Technorati が推進していることからもわかるとおり、一番わかりやすいのは blog 検索の精度向上だろう。 たとえば hReview でブックレビューを書いておけば、 たとえば hCalendar でカンファレンスのスケジュールを登録しておけば、 たとえば rel="license" で自分の記事や写真を CC ライセンスにしておけば、 あなたが提供しているその情報を必要としている人に届きやすくなる。

あるいは今流行の Musical Baton で他の blog にリンクするときに XFN で友人・知人関係を記述しておいたらどうだろう。 こんなアイデアを自動化しつつ さらに参加者間のリンクを関連で色分けして表示するアプリが作れそうだ。

そんなの前からできたって?
そう、メタデータを駆使したセマンティックウェブを使えば前からできた。 Microformats の価値はそこではない。

そんなの面倒くさそうだって?
そう、これまでは面倒だった。でもこれからは面倒ではなくなりそうな予兆がある。 Microformats が素晴らしいのは、メタデータが簡単につくれることと、 メタデータが簡単に利用できることだ。簡単にできる、と言い切ってしまうのは時期尚早だけれども、その希望はある。

たとえばこの Greasemonkey アプリを見てほしい。 Movable Type(だけじゃないけど) の textarea で hCalendar を入力しやすくするための hack である。 もうちょっとこのインターフェースがこなれれば Blog サービスに十分標準搭載できそうだ。

あるいはこれはどうだろう。 可能性を感じませんか?

Microformats とは何か

» Permanent link | |

Web 2.0 の図の中でたぶん一番なじみがないのが microformats だと思う。

現時点で microformats の日本語の解説で一番詳しいのは NII の武田先生の このポストだ。

そもそもMicroなのかというと，既存の大量な詳細なドキュメントで規定される人間が読むことができないようなフォーマット("megaformat!")に対して，format自身も小さいし，簡単に理解できるようなフォーマットだから，ということでしょう．

セマンティックウェブの先端研究者の方による解説なので、Web 2.0 に興味のある方はぜひ読んでください。

REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy)

» Permanent link | |

少し前の話だが、Blog Hackers Conference 2005 に行った。 miyagawa さんのキーノートも、naoya さんの講演も、キーワードは Web 2.0 (的なもの)だなという印象だった。

中でも特に気になったのはこのスライドで blog が missing piece を埋めた、という話だ。 こちらのコメントにも書いたのだけれど、 ここでいう blog というのはいわゆる weblog system/service だけを指すのではなくて、 blog 周辺の技術 (RSS, Atom, AtomPP, REST, Permalink) が方法論として、プラットフォームとなる、というのがまっとうな解釈であろう。

僕自身もこのような Web 2.0 的なものが現在の主要な関心事になっていて、それをまとめたのがこの図である。

まず REST。 REST の詳細は REST 入門を見ていただきたいが、 ここでいいたいのは REST アーキテクチャスタイルの Web がすべての基本となる、ということである。 どんなサービスやアプリケーションを作るにしても REST は避けて通れない。

次に Atom Publishing Protocol (AtomPP; いわゆる AtomAPI) である。 AtomPP は REST で足りないところをきれいに補完するものだ。 RESTful Web で URI 経由でリソースに CRUD を適用できるようになっただけでは、まだ難しい。 AtomPP は REST の URI+CRUD でコンテンツをどう編集するかを具体的に規定した(する)プロトコルとして価値がある。 また AtomPP はその汎用性と拡張性から、 80/20 の法則で、ほとんどの Web サービスのベースとなるのではないかと予想する。

次に blog system/cms である。Wiki も含む。 これは REST ベースの AtomPP 上に実現された、まさにプラットフォームである。 blog/cms がもたらした効能はたくさんある。 まず第一に Web 上のコンテンツ作成の敷居を大幅に下げた点。 次に、(X)HTML の長年の夢である文書構造とスタイルの分離を推進した点。 さらにその進化版として、構造化文書+メタデータの作成を簡単にすることも期待される。 そして最も大きいのは各種最新技術のテストベッドとして、 アルファギークの格好のおもちゃとなっている点である。

Permalink は REST の思想のひとつだ。 すべてのリソースはそれぞれ URI を持つ。 もちろんこのときに "Cool URIs don't Change" であるべきだ。 この永続的な URI を手作業で作成・管理していくのは難しい。 昔ながらの Web サイト作りではどうしてもリンク切れが発生する。 しかしそれも blog システムや CMS の普及でツールに任せる時代がやってきた。 また、AtomPP はもちろん Permalink をベースとしている。

みなさんご存知の各種 RSS および Atom Syndication Format はコンテンツ配信、特に syndication が目的だ。 Permalink, blog, AtomPP と組み合わせることで、浮動的なコンテンツを実現する。 (TODO もうちょっと RSS/Atom の本当の価値を検討する必要があるな)

少し毛色が変わって Folksonomy は tagging やはてなブックマークのようなゆるいソーシャルサービスも含む。 こいつがすごいところは、コンテンツ作成者以外にコンテンツとメタデータ作成の門戸を開いたところである。 それまで、ブロガーが独占してきたコンテンツ作成という特権を、 blog を書かない大多数の人々に tagging やコメントという形で開放したところである。 もちろん大勢の人々によるメタデータの補完という価値もある。 ちなみに、ソーシャルブックマークで tagging するためには、もちろん Permalink が必要である。

Microformats が実現するのはコンテンツの更なる細分化である。 Permalink で記事単位になったコンテンツを semantics で分解してプログラムからアクセスできるようになる。 現状では microformat なコンテンツを作成するハードルは高いが、 これは blog/cms がじきに解決する問題だろう。

Ajax、ここはいわゆる Ajax だけじゃなくて greasemonkey とか動的言語とか、そういう気持ちも入っている。 simple で practical な hack 環境。

そして、最後に行き着くところは Remixing Culture である。 REST/AtomPP/Permalink でコンテンツ編集のためのアーキテクチャが整い、 その実装としての blog システムが整備され、 RSS/Atom でコンテンツが再編集しやすい形で配信し、 Folksonomy/Microformats でセマンティクスが補完され、 Ajax で Remix する。

若干酔っ払ってるのでまとまりないですが、最近考えてるのはこんなことです。

CDF を…覚えていますか?

» Permanent link | |

CDF を覚えている人はいるだろうか。

たとえば このファイル をダウンロードして、デスクトップに保存してみてほしい。 Windows を使っている人なら、アンテナのアイコンが現われるはずだ。

ためしにダブルクリックしてみよう。 あやしげなダイアログボックスが表示されるだろう(キャンセルしといてね)。

右クリックしてみよう。 いっぱいメニューが出てくるはずだ。

エディタで開いてみよう(「右クリック→編集」でもよい)。 タグ名が大文字の見なれない XML ファイルである。

これは XML の創世記に話題となった Channel Definition Format (CDF) だ。

覚えていない人、あるいはそもそも知らない人のために解説すると、 CDF は XML の最初のアプリケーションとして 1997-1998年当時に大変注目されていた技術である。 タグ名が大文字なのも、当時としては普通のことだった(あのころ僕たちは HTML のタグを大文字で書いていた)。 村田さんの「XML 入門」(この本が書かれたのは'97年で XML の勧告化前)でも、 XML の応用例として最初に CDF が登場している。

この CDF はプッシュ型 Web キャスティングのために開発された規格である。 プッシュ型 Web キャスティングというのは、 ユーザが Web ページをいちいちチェックしなくても、 CDF 対応クライアントが CDF ファイルを定期的にチェックして、 更新があったときだけ通知してくれる機能のことだ。

鋭い人ならもう気付いている思うが、 この機能は現在我々が RSS でやっていることと、基本的には全く同じなのである。

当時、現在の RSS リーダーはまだ一つもなかった。 ではいったい何で CDF を受信していたのか。 それは PointCast (あー懐しい)や Windows の ActiveDesktop あるいは IE 4.0 などだ。 PointCast はもうとっくに廃れているけれど、 Windows や IE はまだ現役なので、 我々のデスクトップにアンテナアイコンを表示してくれるのだ。

---

(hr タグを使うのも久しぶりだなあ…)

さて、なんで今さら CDF の話をしたのかというと、 naoya さんのこの記事を読んだからだ。 いわく、一度はキャズムを越えられなかった RSS が、 blog という最良の伴侶を見つけてキャズムを越え爆発的に普及した、ということである。

技術的にはそんなに違わないのに CDF はキャズムを越えられなかった。 当時でも CDF を理解して PointCast を使っていたのはギークだけだろう。 それ以外の何万(もっとかな)のユーザは CDF なんて知らずに PointCast で天気予報と朝日新聞を見ていたのだ。 でも CDF は死んだ。

RSS も粘って粘ってやっとキャズム越えた。 blog ツールによりすべての人々が RSS を提供できる仕組みができたからだろうか。僕にはわからない。

コンセプト/アイデアはいいのに死んでいった技術の中にも、 復活するものがあるのかもしれない。 ただし、復活させるには駄目になったときとは違うグループがやる必用がある。 たぶん。

冒頭の CDF は Sam Ruby さんのものです。