yohei-y:weblog

XML と REST/Web サービス関連の話題が中心の weblog です

2005-07-31

Web らしく URI で連携する方向

前のエントリで触れた ID だけのディスカバリの問題点ですが、 他にもこんなのもあります。

僕が自分のブログにはてな ID を埋め込んだとして期待するのは、 ブログを訪れた人が自分のブックマークやアンテナを見に来てくれたり、投げ銭してくれたりすることです。 でも僕がはてなで何を使っているかは僕にしかわかりません。 僕の場合はてブはてアは使ってるけど、 はてダは更新を止めちゃった、はてフは知らん、という状況です。 もしかしたらアサマシは嫌いだから投げ銭してほしくない、という人もいるかもしれない。

これって「はてなID」の埋め込みだけでは実現できません。 自分ははてなのこのサービスを使っているよ、という主張をできないからです。

ではどうするか。 自分ははてなのこのサービスを使っているから見に行ってね、という宣言をしたらどうでしょう。 head 内で宣言するんだったらこんな感じ。

<link rel="hatenab" href="http://b.hatena.ne.jp/yohei" />
<link rel="hatenaa" href="http://a.hatena.ne.jp/yohei" />

body 内部で a タグに書くのであればこんな感じ。

<a rel="hatenab" href="http://b.hatena.ne.jp/yohei" >はてぶ</a>
<a rel="hatenaa" href="http://a.hatena.ne.jp/yohei" >はてあ</a>

ここまでくると、別にはてなに限らないでもいいのではないかという気がしてきます。 たとえば僕の場合、使っていると宣言したいサービスは

  • hatenab
  • hatenaa
  • flickr
  • bloglines
  • delicious
  • mixi
  • blogger

なので、head はこうなります。

<head>
  <link rel="hatenab" href="http://b.hatena.ne.jp/yohei" />
  <link rel="hatenaa" href="http://a.hatena.ne.jp/yohei" />
  <link rel="bloglines" href="http://www.bloglines.com/public/yamamotoyohei" />
  <link rel="flickr" href="http://www.flickr.com/photos/60043209@N00/" />
  <link rel="delicious" href="http://del.icio.us/yohei" />
  <link rel="mixi" href="http://mixi.jp/show_friend.pl?id=173690" />
  <link rel="blogger" href="http://yohei-y.blogspot.com" />
</head>

a タグだったらこうなります。

<a rel="hatenab" href="http://b.hatena.ne.jp/yohei">僕のブックマーク</a>です。
<a rel="mixi" href="http://mixi.jp/view_profile.pl?">mixi</a>も使ってるよ。
<a rel="payment hatenagesen" href="http://nagesen.hatena.ne.jp/yohei">投げ銭</a>よろしく。

この rel= はいわゆる microformats ですね。 link タグなら Atom feed にも同じように入れられます。

rel 属性の値が各サービスごとに違うのがいいのか、 もっと別の値がいいのか、そもそもこんなことがやりたいのか、やっていいのか、という話はありますが (^^; URI で繋がるという方向性もある、ということを認知してもらえたらと思います。

ラベル: , , ,

そもそも ID を見つけるだけで十分なのだろうか

なんか複雑な方向になってきたなーと思っていたところで風邪を引いてしまって寝込んでいたので、なんだか浦島太郎状態ですが、思うところを。

今の暫定仕様は僕にとってはちょっと違う方向のように感じるんですね。アカウントの ID だけを渡すというのは、関数のパラメータの一引数を渡すというのに繋がる気がするからです。

そもそも naoya さんがやりたかったこと

まずそもそも僕が考えた仕様は...という前にまず何をしたいかを明確にしないとですね。僕がしたいのは、はてなダイアリーを含めたインターネット上のウェブページ (Permalink) から、そのページを作った人の「はてなのID」を探し出したい、ということです。

ですが、では ID を探し出して具体的に何をするんでしょうか。 もちろん、はてなのサービスの中の人はいいと思います。 HTML や RSS/Atom を取ってきて、その中にはてなIDがあれば、その ID からユーザを特定していろいろできる。 でも Web 2.0 的に考えるなら、はてな外の Remix する人の事も考えてほしい。

そんな Web 2.0 的な Hatena ID Auto Dicovery の応用に、 吉松さんが触れていました

僕は「投げ銭」に特化しないほうがいいなあ、と思ってます。例えばツールバーに「この人のはてダに移動」とか「このひとのはてブお気にを一覧」とかいうボタン作るのに役立ちそうだな、と思うもので。

なるほど。確かに便利そう。 とある Web の記事や RSS/Atom フィードを表示すると、 はてなツールバーや Greasemonkey スクリプトでその人のはてなブックマークへのリンクがポップアップしたら楽しい。 実際のコード(の断片)は例えばこんな感じかな。

var hatenaid = getIdFromRdfFoaf("http://www.hatena.ne.jp/");
document.write("<a href='http://b.hatena.ne.jp/" + hatenaid + "'>?B</a>");

うーん、嫌だ。

嫌な点の一つ目は "http://b.hatena.ne.jp/" という文字列をクライアント側で持っていて、ユーザ名と組み合わせている点。 これをやってしまうと、b.hatena.ne.jp を変えたり、URL の構造を変えたとたんに 途方もない数の全クライアントを一斉に変更しなければならなくなってしまう。 いわゆる密結合の一番悪いパターンですね。

もちろんはてなのドメイン名や URI の構造がそんなに簡単に変化するとは思いませんが、 一般的にはやらない方がいいことです。

それからもうひとつ嫌なのは JavaScript で getIdFromRdfFoaf() を作るのが大変そうなところ。 コメントアウトされた RDF/FOAF の文字列を「わざわざ」探し出して、さらにそれをパースして、RDF のトリプルにして…、 とやるのは想像するだけで鳥肌が立つ(のは僕だけかな)。

HTML に ID を埋め込む、というのは一見するとすごく汎用的で何にでも使えそうなんだけど、 汎用的であるが故に何をやるにも中途半端になってしまう危険性があります。 もう少し実用的な使い方をいくつか模索したり組み合わせたりして、 その中で汎用的に使える部分を探すという方がいいのではないかと思います。

では具体的には何なのだ、という話は次のエントリで。

ラベル: ,

2005-07-23

Hatena ID Auto-Discovery について

昨日は SIGMOD-J の大会に行った後にアルファギークなお二人と食事をしてきました。

大会ではやはり naoya さんの Web 2.0 についての話が一番面白かったです。 周りにいた人の反応も一緒でした。

ちなみに僕は naoya さんは初対面。 食事に途中参加の高林君とはちょうど4年ぶりだったことが今判明。オリンピックみたいだ:-)。

naoya さんは普段から blog やブックマークを見ているので、ぜんぜん初対面な気がしなかったんですが、 僕としては REST だの Folksonomy だの microformats だのといった単語をガンガン喋ったり聞いたりするのが新鮮かつエキサイティングでした。 やっぱり直接会って話すのは大切だと実感です。

以下本題です。僕は話題に出遅れてしまったんですが Hatena ID Auto-Discovery について。 naoya さんには直接喋ったんだけど、 酔っ払っててよくわからなかったと思うので、 もう一回ここに書いておきます。

まず、現状の仕様はこうですね。

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="DC.creator" title="id:naoya"
  href="http://www.hatena.ne.jp/user?userid=naoya" />

で、僕が提案するのはこれ。

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="DC.creator" href="http://www.hatena.ne.jp/user/naoya" />

二点提案があります。

最初は title 属性について。 例では title="id:naoya" となっていますが、 別にこれはなくてもいいのではないでしょうか。 DC の creator は href 属性で指定される URI で識別されるのであって、title 属性はあくまでも便宜上の助言的情報。 ならば、title 属性の内容はコンテンツ作成者に委ねた方が自由度が上がる、と考えられます。 もちろん id 記法が好きな人は title="id:yohei" としていいし、 そうじゃなくて title="YAMAMOTO Yohei" としてもいいし、 title="このページの作者のはてなIDです" とかしてもいいわけです。

次に href でリンクする先の URI についてです。 ひとつは ?userid=naoya というように、query string を使うのはどうだろう、という話。 もうひとつはこの URI が適切なのか、という話です。

こういう ID としての URI に query string が入っているとちょっとクールじゃないですね。 文字列長も長くなっちゃうし、何より query string はクライアント側でいじれる所がいかにも密結合的です。 ま、このケースはそんなに気にすることはないんですが、 僕のこれまでの感覚だと、はてなは URI がいつも綺麗だという印象があります。 はてならしさを維持するためにも、ここは query string を使わないほうがいいのではないでしょうか。

あとはリンク先の妥当性です。 はてなダイアリーの id 記法でリンクする先はそのユーザのダイアリーですよね。 その観点から id 記法との整合を考えると、ダイアリーを持っているユーザの場合は、 ダイアリーにリンクするのが最も適切ではないでしょうか。 ダイアリーを使っていないユーザはどうするのかという問題が残りますが、 それも id 記法でのリンク先にあわせるのがいいのではないでしょうか。

ということで、最終的には以下のような形になりました。

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="DC.creator" href="http://d.hatena.ne.jp/naoya" />

ラベル: ,

2005-07-17

Atom 1.0

Atom Syndication Format 1.0 が Tim Bray からアナウンスされましたね。

いろいろなところで言及されていますが、 XML cover pages がいつもながら一番まとまっています。 ちなみに RSS/Atom のこれまでの流れは Robert Sayre の記事によくまとまっています。

これで syndication format の本命は RSS 2.0 と Atom 1.0 に絞られたわけですが、 これからどうなるか注目です。 両者の比較は Tim Bray のもの(日本語版)がありますが、 はっきりいって機能的にはそんなに違いませんね。 Atom 1.0 の方が後出しジャンケンなので全体的にすっきりしていますが、 普及状態から言うと圧倒的に RSS 2.0 が勝っています。

Atom の方はもちろん syndication format 単体で使えるのですが、 APP(って書くと「アプリ」を想像されそうなので AtomPP) がそろって初めて本領を発揮でしょうから、 AtomPP の標準化までにどれだけ syndication format が普及しているかも重要です。

ちなみに Atom 1.0 フィードの実例を見たい人はここからどうぞ。 blogger は Atom 1.0 に対応してくれるのかなあ…

ラベル: ,

2005-07-15

今後10年

この weblog のアクセス数がいつもの10倍になっていて、 なんだなんだと思ったら naoya さんとこで言及されてました。

Remix や Folksonomy という考え方はすばらしいのだけど、 それらを実現する手段としてよりシームレスなものっていうのは一体何なんだろう。 使い手がそれらを意識することなしに、その恩恵を得られるもの。 自分の両親が blog を使いはじめて整えられたアーキテクチャでウェブサイトを構築し、 RSS や Atom でシンジケーションするということはもしかしたらありえるかもしれないけど、 Greasemonkey で Remix して tagging で情報をうまく整理するなんてことはどう考えてもあり得ない。

Remix とか Folksonomy ってそんなに難しい話なんですかね。 tagging だの microformats だの api だのといった言葉や概念は 10年後にないかもしれないけれど、 たとえば自分が撮影した写真を rel="license" で CC ライセンスにして広く共有するとか、 逆に CC ライセンスの写真や演奏を検索してそれを基にした二次配布物を公開とか、 あるいは Web 2.0 ベースのツールで wikipedia を編纂するとか、 10年後(5年後?)に教育テレビで「ホームページ入門」の一環としてやってるんじゃないかなあ。

と、考えると、これらの世界が実現していくためには今とは違った手段が必要になってくるだろうし、 そういった手段が出てこなかった概念はいずれ廃れる、 あるいはいわゆるデジタル・デバイド(なんか死語っぽいけど)の象徴になるのかもしれない、なんて風にも思う。 手段自体がメジャーシーンに拡大しなくても、 API によって開発された成果物を使う人、 Folksonomy で分類された後の結果だけを見てその恩恵を授かるフォロワーがいたりする、 ということもあるので、かならずしも手段のコモディティ化が必須というわけではないのだろうけど。

コンテンツ作成者とフォロワーの間に高速道路が敷かれるんでしょう。 つまり、例えばはてなはフォロワーがすぐにコンテンツ作成者になれる道を現在建設中と捉えることができます。 これまでは geek の専売特許だったコンテンツ作成とか remix といった行為を 普通の人たち(そういう人たちのコンテンツも魅力的)にまで拡大する、 それが世界政府御用達システム製造・運用会社や、例の変な会社のミッションなのでは。

2005-07-02

Google Maps で世界のサーキット

自分で見つけられた分

こちらが詳しい