microformats などの設計についていろいろ

» Permanent link | |

僕が提案した方法についておのひろきさんからツッコミが入り、 microformats を誤解している、マークアップする力の問題である、と批判されました。

まー実際、microformats を誤解しててマークアップする力もないかもしれないんだけど、 おのひろきさんの主張には賛成できないので、ここでまとめて反論しときます。

まず、「microformats についての誤解と，ぼくが理解している範囲」より。 前半の microformats の説明は特に異論はありません。 でもそれがなんでいきなり

それでさらに microformats であるなら，一度「意味付けと記述書式」を決め たら，それが他での使い回す事ができないと意味がありません．限定された問 題を解ければ良いとはいっても，特定の問題にしか対応できないほど限定して たら駄目なのです．

ってなっちゃんでしょう?(強調筆者) ここがまずわからない点。

rel 属性値は profile で定義してそこで意味付けをします．上の例では a 要素で rel 属性値 hatenab とある場合は href が指す URI ははてなブックマークであるってことになるのかな?

元記事では、主題が別だったので詳細なプロファイルまで書いてませんが、 リンク形式 rel="hatenab" は、リンク先が元ページの著者のはてなブックマークへのリンク、という意味です。 目的は「自分が使っているサービスを宣言」するため。

profile を定義するということを意識していないから rel 属性値をどうするかというところで間違えるのではないでしょうか．profile を定義することと，その profile が他で応用できるようにするということを考えないとダメだと思うのです．

最後のここもいまだにわからないんですよね。 rel を拡張するなら profile (microformats なら XMDP) が必用、というのはわかってるつもりです。 でもそれと、「他で応用できる」ってどう関係があるんでしょうか? たとえば XFN は友人関係を記述する以外にどう「他で応用できる」んでしょうか?

続けて「マークアップする力」より。

檜山さんの記事を引用して

「邪悪マークアップは先進的マークアップか？」から引用すると:

これがまずい理由は、<田中>元気で行ってこい。</田中>や<ミヨ子>おみやげ、忘れないでねぇ</ミヨ子>のあいだに共通性があるのに、その共通性がマークアップにより表現されてないことです。

これと同じ事が rel="hatenab" と rel="delicious" にも言えると思うのです．

と書いていますが、同じとは言えないと思いますよ。

おのひろきさんは Semantic Web に詳しいようなので釈迦に説法かもしれませんが、 rel 属性と class 属性の仕様上の違いをまず再確認してください。 rel は「リンク形式(のリスト)」、 class は「クラス名(のリスト)」です。 リンク形式(link type)がリンクの関係性を表現するのに対し、 クラス名は (X)HTML 要素の分類に用いるものです。

いわゆる microformats ではこの二つをちゃんと使い分けていて、 rel 属性は (X)HTML の仕様どおり、リンクの関係性を表現しています。 そのリンク先がライセンス文書であると指定したり、 リンク先のコンテンツがリンク元とは関係ない(follow してない)と指定する、などです。

一方で class 属性は XHTML に vCard の構造を埋め込んだり、 iCalendar の構造を埋め込んだりするのに使います。 クラス名が構造情報と対応しているわけです。

ここまでで明かだと思いますが、 檜山さんの記事に出てくる「多重マークアップ」は class 属性の応用の話です。 対して、ここで議論しているのは rel 属性の値(リンク形式)をどうするか、という話です。檜山さんの例を引けば、

<寄せ書き>
 <ひとこと 誰="田中">元気で行ってこい。</ひとこと>
 <ひとこと 誰="ミヨ子">おみやげ、忘れないでねぇ</ひとこと>
 ...
</寄せ書き>

ここで言う 「誰」属性の値は「田中」がいいのか「id:tanaka」がいいのか 「上司」がいいのか「社員」がいいのか「男」がいいのか「日本人」がいいの か「人間」がいいのか「哺乳類」がいいのか「動物」がいいのか「生物」がいいのか… って話と同じですよ。

だから、

つまり rel="hatenab" と rel="delicious" の間に共通性があるのに，その共通性が表現されていないのです．それは，書き手の頭の中だけにあります．

これは勘違いではないですか。 上記のとおり、リンク形式に指定する値の粒度をどれくらいにするかというのを議論してるんです。 その値の定義は、おのひろきさん自身が言っているとおり「profile によって定義するっていう手」を使います。

profile によって定義するっていう手もありますが，そうすると似たようなサービス全てについて profile で定義を用意しなければなりません．そうではなくて rel 属性では共通性の部分を表現するべきでしょう．

別に「似たようなサービス全て」を定義しなくてもいいんじゃないでしょうか。 プロファイル策定者がはてなだったら hatenab, hatenaa, hatenai, hatenad,... と自社のサービスを定義すればとりあえず十分でしょう。 これで、あとは API さえあれば、今閲覧している Web ページの作者のはてなブックマークを自分のお気に入りに入れるブックマークレットとか、 その人が使っているはてなのサービス一覧を小綺麗に表示する greasemonkey スクリプトとかが作れそうです。

ただ、一利用者の感覚とすれば、hatenab じゃなくて del.icio.us も使いたいんですよね。 でも del.icio.us には inbox はあっても「お気に入り」はない。 こんなかんじで hatenab と delicious を区別したいニーズはあります。

これについておのひろきさんは

rel="hatenab" とある場合とない場合で，メタデータの抽出の仕方がどう変わるかを考えたら，あまりrel="hatenab"ってのは有効ではないのでは? hatenabにマッチングするか b.hatena.ne.jp にマッチングするかの違いだか ら．

という見解のようですが、 僕はまったく逆ですね。 URI でマッチングしなきゃいけないような設計は悪い設計の代表例だと思います。 何で悪いかの理由のひとつは shckor さんがいうとおり URI がやむを得ず変わる場合ですね。 REST とか、疎結合の文脈で言えば、クライアントとサーバのお約束が増えてしまうという意味で悪い設計です。 せっかく rel 属性があるのに、関係ないところで URI のコンベンションを作るのは余計な制限を増やすだけだと思います。

ちなみに、はてなや del.icio.us のドメイン名は安定してそうなのでまだいいですが、 たとえば、サーバインストール型の Web アプリケーションだったり、 社内向けサーバで、どうしてもドメイン名を変更しなければならなかったりしたらどうするんでしょうか。 たとえば pukiwiki にソーシャルブックマークプラグインができたとしたらどうしますか。

<link rel="onlineBookmark delicious" href="http://del.icio.us/onohiroki"/>

ってのも良くないと思います．"delicious" ってのを profile で定義しなくちゃならないから．それなら "delicious" を与えるのは title 属性が良いと思うし，profile を定義しなくても良い class 属性のほうが rel 属性よりはまだ良いと思います．

上記のような理由から rel 属性の代わりに class 属性を安易に使うのは反対です。 rel には rel の意味があるのだから。

ここまで書いて、「class 属性を再発見」というエントリが追加されているのを発見したんで、 ついでにこちらにも若干コメントを。

最初に定義していなかったものを後から追加したくなったら，別 profile を作るのでしょうか? この問題をどう考えているのかはぜひ教えてほしいです．

同じプロファイルに新しいサービス名を追加してバージョンアップします。 もちろんこれは XML のスキーマのバージョンアップ問題と同じ話で、 いろいろと難しい問題を含んでいるのですが、 どこに追加される可能性があるのかはっきりさせる、 新しいものを追加しても問題が起きないようにクライアントを作る(知らないサービスは無視するか、知らないサービスとして扱う)、 追加するだけならバージョンを上げなくてもいい(プロファイルの URI を変更しない)、 といったような設計が 2005 年の現時点では理想的かつ現実的な設計でしょうね。

shckor さんや yohei さんが言っている事がちゃんと理解できたら title 属性とかぢゃなくて class 属性ってすぐに出てこないとおかしいですよね．いや，未だに shckor さんや yohei さんの主張でよく分からないところがあるけど．

僕は以前にも title 属性は助言情報なのだからコンテンツ作成者の自由にさせるべきという意見を書いたとおり、 title 属性の安易な濫用はお勧めしません。 上記のとおり rel から class への安易な鞍替えも同様です。

良い URI の設計

» Permanent link | |

URI は綺麗であるべき、と常々思っているんですが、よいページを発見しました。 Michael Eakes のこのエントリです。 Tanya Rabourn がリストアップしている文献一覧からエッセンスをまとめてくれています。 曰く、よく設計された URI とは

• 変らない(don't change)
• 人間が推測可能(are human guessable)
• 論理的(ファイルシステムを反映する必用がない) (are logical (no need to mirror a filesystem))
• サイト構造をビジュアライズするのに役立つ(help visualize the site structure)
• 短い(are short)
• 小文字を使う(use lowercase)
• 予期されない記号を使わない(don't use unexpected punctuation)
• 問合せパラメータなし(lack query parameters)
• 公開リンクを許す(allow public linking)
• ステートレス(are stateless)
• 技術を丸出しにしない(dont expose technology)

だそうです。 彼のエントリにはそのほかにも Flickr の URI が良い設計例として載っています。

典型的な悪い例はこんな感じかな。

http://test1.example.com/Test/getDocList.cgi?folder-name=abc&user_name=yohei&sessionId=123

直すとこうなる。

http://www.example.com/yohei/abc

最後の項目の悪い例は /home.pl とか /login.do とか /index.jsp とか /hitobito.nsf とかですかね。 とりあえずは mod_rewrite を使って解決するんでしょうけど、本質的にはフレームワークが解決した方がよさげ。