履歴もしくは日誌

hatenab の意味 / rel 属性と class 属性について

microformats であるなら，一度「意味付けと記述書式」を決め たら，それが他での使い回す事ができないと意味がありません．限定された問題を解ければ良いとはいっても，特定の問題にしか対応できないほど限定してたら駄目なのですって書きましたが，これは撤回しましょう．microformats としての仕様を考える時にぼくならどうしたいかという事であって，使い回す事ができなくて特定の問題にしか対応できないからと言ってまったくの無価値な訳ではないしね．

でも目的が「自分が使っているサービスを宣言」するためであれば，yohei さんが使っているサービスも，ぼくが使っているサービスも同じように記述できる程度の汎用性がある記述方法を期待してしまいます．オレ専用 profile を書くよりは皆で使い回せるほうが良いですよね．

XFN では youhei さんの友達もぼくの友達も同じように rel="friend" と記述できます．ぼくの友達である susumu さんや maki さんを友達だって記述するために rel="susumu" とか rel="maki" って記述するのは良くないと思うし，それと同様に はてなブックマークを rel="hatenab" と記述するのも良くないと思うのです．XFN で rel="friend met" って書くのと同様に rel="onlinebookmark" で良いぢゃないかと．

でもいろいろ説明していただいたように rel="hatenab" って書く事でメリットがあるという主張は受け入れましょう．rel="hatenab" はダメだ間違いだというのも取り消しましょう．

でも，もっと他の方法も考えられます．

rel="hatenab" のデメリットは，新たなサービスを追加するためには profile の更新が必要だということです．ぼくは rel="onlinebookmark" といった感じでリンクの関係性を表現したうえで，hatenab のような個々のサービスを表す値は class 属性で扱うのが良いのではないかと思います．

「hatenab」は「はてなブックマーク」の事で，rel="hatenab" は「リンク先が元ページの著者のはてなブックマークへのリンク」という表現という事で話をすすめます．

rel 属性と class 属性は XHTML での定義からしたらこうですよね:

rel 属性

リンクの関係性を表現．リンクタイプを記述する．

class 属性

要素識別子としてクラス名を与える．

まず最初に yohei さんは，自分が使っているサービスを宣言したいということで rel="hatenab" という記述形式を提案しました．

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

これは hatenab がリンクの関連性であり，リンク先が元ページの著者のはてなブックマークへのリンクという意味ですね．

hatenab よりは，オンラインブックマークを示すような表現が良いのではないかという話で次ぎに rel="onlinebookmark hatenab" のような記述はどうかという話になりました．

<link rel="onlinebookmark hatenab" href="http://b.hatena.ne.jp/onohiroki/"/>

上のようにするのであれば onlinebookmark も hatenab もリンクの関連性を示すということですね．

たしかに a 要素や link 要素で指し示す URI に対して意味付けするなら rel 要素でリンクタイプを記述するのが自然なんです．でもリンクタイプとしてなら，オンラインブックマークというリンクタイプのほうが自然に感じます．onlinebookmark というのがリンクタイプであるというのは良いとして，hatenab は本当にリンクタイプが一番良いのでしょうか．

onlinebookmark も hatenab もリンクタイプでありリンクの関連性を示すとするのに対して onlinebookmark はリンクの関連性で hatenab は識別子だという考えからしたら下の例のほうが自然でしょう．

<link rel="onlinebookmark" class="hatenab" href="http://b.hatena.ne.jp/onohiroki/"/>

この場合は「リンク先は元ページの著者のオンラインブックマークで，そのオンラインブックマークは はてなブックマーク」という意味になると思います．

hatenab や delicious がソーシャルブックマークという概念に含まれる概念であり，クラス名という識別子であるという考えを受け入れることができるのであれば，hatenab や delicious などは識別子として class 属性に記述して rel 属性ではオンラインブックマークへのリンクという事を表現するという方法が考えられます．yohei さんの主張でも URI からオンラインサービスを識別するよりは hatenab という文字列マッチで識別したいという話でしたから，hatenab を識別子として取られることにはことさら異議がないのではないでしょうか．

yohei さんは「リンク先が元ページの著者のはてなブックマークへのリンク」と表現したかったということですが，それを「リンク先は元ページの著者のオンラインブックマークで，そのオンラインブックマークは はてなブックマーク」という表現にしてもおかしくはありません．そう考えれば hatenab は，オンラインブックマークの中のサービスの識別子であると考えられます．shckor さんはhatenab という“属性”は onlineBookmark という“属性の属性”とも言えるという表現で同様の事を書いていますね．

「リンク先は元ページの著者のオンラインブックマークで，そのオンラインブックマークは はてなブックマーク」という表現なら hatenab は class 属性に記述しても良いでしょう．他のサービスである del.icio.us が profile に定義してなかったとして class="delicious" と書いても XHTML の文法違反になりません．これはメリットだと思います．後になってから profile にそれを定義して，意味付けをすることもできます．

yohei さんは microformats では,クラス名が構造情報と対応していると説明していますが，元の規格でのメタデータの構造をクラス名に対応づけて構造化しているだけではないでしょうか．hatenab の場合は「リンク先は元ページの著者のオンラインブックマークで，そのオンラインブックマークは はてなブックマーク」と表現する時に class 属性を使って class="hatenab" という記述は妥当だと思います．

では hatenab を rel 属性にするのと，class 属性にするのとでは，どっちが良いでしょうか．

• ありとあらゆるサービスについてもどんどん profile を更新して定義を足して行くというのが実現できていて，class 属性を使う事に異議があれば，rel 属性で hatenab と書く事になります．

• ありとあらゆるサービスについてもどんどん profile を更新して定義を足して行くというのが実現できていて，class 属性を使う事に異議が無ければ，rel 属性でも class 属性でもどちらでも良いでしょう．

• ありとあらゆるサービスについても，どんどん profile を更新して定義を足して行くというのが実現するのが疑わしいという立場なら，rel 属性よりは class 属性のほうが望ましいですね．

それで，実は yohei さんの話では，ありとあらゆるサービスについてどんどん　profile を更新して追加するってわけでないのですよね．もちろん新しいサービスについても記述したくなったら profile に追記して更新するわけです．rel 属性を使った場合は，「自分が使っているサービスを宣言」するためには，そのサービスが profile で定義済みではなかったら記述できない訳です．ある会社がが自社のサービスの為だけに profile を作るのなら rel="hatenab" かもしれないけど，それなら del.icio.us などの他者のサービスは同じ profile の中では定義されないでしょう．第三者が profile を作るとして，はてなと del.icio.su は定義済みとして，それ以外のサービスを使っている人は，同じようなことを表現したいのに表現できないことになってしまいませんか．

だからいずれにしても rel 属性ではオンラインブックマークへのリンクであるという事を示す rel="onlinebookmark" というような表現を用意しておくのが良いと思います．これについては異論がないと思います．さらに hatenab を rel 属性の中に加えるか，それとも class 属性にするかです．

hatenab のようなのを class 属性にすることにしておくと，profile で特に定義しておきたいのは定義しておいて，それ以外は未定義でも XHTML の文法違反にはならないから，書き手が好きに書けて良いと思います．profile に未定義のサービスに対して profile に追加したくなった時に，追加すれば良いし．

でも yohei さんの話では hatenab がどうして必要なのかについては，なにかの実装で情報を抽出するために hatenab という識別子が URI とは別に必要だという事だったので，rel="onlinebookmark" としてリンクタイプが記述できていれば hatenab はどこかに記述する必要はあっても意味付けする必要は無いのではないでしょうか．

「自分が使っているサービスの宣言」を XHTML で表現し microformats で利用することまで考えた時にどのような表現にすべきかについて，ぼくの考えをまとめると:

• rel="onlinebookmark" というような表現は必須と考えます．
• hatenab は rel 属性でしか扱えないような内容ではないと考えます．
• hatenab はリンクタイプというよりは，識別子(クラス名)ではないかと考えます．
• hatenab は識別だから class 属性に属性値として記述するのが良いと考えます．
• hatenab に識別子であるという以上の意味付けする必要は無いのかもしれないですが，必要なら profile で意味付けすることができると考えます．
• profile に定義されていない class 属性値は，単に意味付けを profile でされていないという扱いにするのが妥当と考えます．
• profile に定義されていない rel 属性値は，単に HTML/XHTML の仕様に反します．

profile に定義されていない rel 属性値が HTML/XHTML の仕様に反するという事については，そんなに厳密に考えなくてもいいのかもしれないけど，避ける方法があれば避けた方がより良いですよね．

ぼくなら hatenab は削除してオンラインブックマークサービスというリンクタイプだけにするでしょう．

<link rel="onlinebookmark" href="http://b.hatena.ne.jp/onohiroki/"/>

なんかの実装の都合で hatenab がやっぱり必要ってことなら，リンクタイプでなく識別子で hatenab を記述します．

<link rel="onlinebookmark" class="hatenab" href="http://b.hatena.ne.jp/onohiroki/"/>

rel="onlinebookmark hatenab" という記述がより良いという場合は，hatenab は識別子としては扱えなくて，あくまでもリンクタイプであると言う事が説明され，「リンク先は元ページの著者のオンラインブックマークで，そのオンラインブックマークは はてなブックマーク」というのは不適切で「リンク先が元ページの著者のはてなブックマークへのリンク」が適切だという説明が必要だと思います．

関連リンク

• yohei-y:weblog: microformats などの設計についていろいろ
  http://yohei-y.blogspot.com/2005/08/microformats.html
• rel="hatenab"に関する議論 - 徒委記
  http://www.akatsukinishisu.net/wiki.cgi

でも，まぁGRDDL でメタデータが RDF として抽出できるのであれば，他の人が同じ profile を利用する事を一切考慮しない「オレ専用 profile」を書いてオレだけの microformats って事でも良いかもしれない．

Permalink Trackback URI http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050823n2 TrackBack

class 属性を再発見

rel 属性を利用すればリンクの関連性を豊かに表現できるという rel 属性の価値の再発見があって XFN では rel 属性を利用しました．識別子を付加したいのであれば class 属性が適切なので，class 属性を使えばよいのではないかと思います．
「SYNの日記 - Re: マークアップする力」を読みました．確かに shckor さんの個体識別子を定義する属性もあるべきだと思うという主張をぼくはよく分かっていないと思います．

個体識別子が何を意図するのかが良くわかっていません．これは URI が指し示すものが何なのかを URI とは別の方法で識別子を付加したいということですよね? URI から識別するのではなぜだめなのかもぼくにはよくわかりません．その rel 属性での識別子付けのルールは profile で定義し，その profile ではあらかじめ想定されたものだけを定義しておく訳ですね．
最初に定義していなかったものを後から追加したくなったら，別 profile を作るのでしょうか? この問題をどう考えているのかはぜひ教えてほしいです．

もし profile を定義するのでは無いなら，rel 属性に勝手に属性値を定義するのは XHTML の規則に違反するから適切ではないです．独自の属性 relto とかを定義するのも XHTML の規則に反するから適切ではないです．任意の文字列を属性値として持ちたいのであれば title 属性が適切だと思いますが，title 属性に記述するような人間が読んで意味が分かるような文字列を使いたい訳ではなくて，識別子としての文字列を定義したいのであれば class 属性が良いでしょうね．

<a class="hatenab"
      href="http://b.hatena.ne.jp/onohiroki" 
      title="おのひろきのはてなブックマーク" >bookmark</a>

class 属性値であれば，好き勝手に定義しても XHTML の規則違反にならないので良いと思います．link 要素の場合も id 属性や class 属性を与えることができます．

識別子である URI にさらに識別子を定義したいというのが目的だから，リンクの関連性を示す rel 属性を利用するよりは，識別子を定義するための属性である class 属性を利用するのが適切だと思います．

次に microformats を考えると class 属性値に意味を持たせる為に profile を書くことになるのかな．xoxo とか hCard などは class 属性を使って意味付けして profile で意味付けについて定義していますよね．

class 属性を使って class="hatenab" とか書いてそれを microformats 的に利用するのであれば，なにも問題ないと思います．特にこだわらなければ profile で意味付けしなくても良いと思います．

と，いうわけでもし識別子を付加したいのであれば rel 属性でなく class 属性が良いと思います．これは提案．
それで，識別子を hatenab なんて形で付加するのにどういう意味があるのかはぼくには良くわかりませんが．

ぼくは rel 属性値を定義するのが，そのまま microformats ではないだろうと書きました．XFN で rel 属性を使ったのは rel 属性を利用すればリンクの関連性を豊かに表現できるという rel 属性の価値の再発見があったからでしょう．XFN ではリンクの関連性を表現したくて，適切な属性である rel を利用したのです．もしリンク先の識別子を表現したければ rel 属性を利用しなかったでしょう．

microformats の面白いところは XHTML として適切なマークアップが先にあり，さらに決まった書式であれば，そこからメタデータを抽出できるってところだとぼくは感じています．

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

はてなの Account Auto-Discovery の話も，この microformats に付いての話も，ぼくはそれなりに楽しんでます．いろいろ勉強になります．自分でもいろいろ調べないと書けないですね．

Permalink Trackback URI http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050820n1 TrackBack

マークアップする力

「yohei-y:weblog: Web らしく URI で連携する方向」での提案は良くないと思うのですが，どう良くないのかをうまく伝えられませんでした．もう microformats の話ぢゃなくて，どうマークアップするか，どう表現するかっていう話題になるかと思いました．

問題の表現はこんなんです:

<link rel="hatenab" href="http://b.hatena.ne.jp/yohei" />
<link rel="delicious" href="http://del.icio.us/yohei" />

このマークアップがどう問題なのかをどう説明するか．かなり考えましたが，この問題をうまく説明する文書がありました!

• 檜山正幸のキマイラ飼育記 - 邪悪マークアップは先進的マークアップか？
  http://d.hatena.ne.jp/m-hiyama/20050725/1122277983
• 檜山正幸のキマイラ飼育記 - Microformatsと多重マークアップ
  http://d.hatena.ne.jp/m-hiyama/20050722/1122023064

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

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

これと同じ事が rel="hatenab" と rel="delicious" にも言えると思うのです．
つまり rel="hatenab" と rel="delicious" の間に共通性があるのに，その共通性が表現されていないのです．それは，書き手の頭の中だけにあります．profile によって定義するっていう手もありますが，そうすると似たようなサービス全てについて profile で定義を用意しなければなりません．そうではなくて rel 属性では共通性の部分を表現するべきでしょう．

<link rel="onlineBookmark" href="http://b.hatena.ne.jp/onohiroki" title="はてなブックマーク"/>
<link rel="onlineBookmark" href="http://del.icio.us/onohiroki" title="del.icio.us"/>

microformats の話以前に，rel 属性の特性を考えたらこうなるのが自然だとぼくは思います．
rel 属性の値を拡張するには profile が必要なので，その profile では rel 属性値が onlineBookmark である場合，href 属性値はオンラインブックマークサービスでの URI を指し，title 属性値にそのオンラインブックマークサービスの名称が定義すれば良いでしょう．

ちなみに「邪悪マークアップは先進的マークアップか？」では，例にあげているようなトンデモ・マークアップでも許容すべきではないかという文脈のなかで，先に挙げた例がでてきます．「Microformatsと多重マークアップ」の中で出てくる多重マークアップってのは，今回の問題をちゃんと整理するのにとても役に立ちました．

SYNの日記 - microformatsの誤解での話は，やっぱり外していると思う．microformats の話ぢゃなくて HTML 4.01 の話として考えてみたって，同じ事だと思います．

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

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

Permalink Trackback URI http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050817n2 TrackBack

rel="Bookmark" のなぞ

HTML+ では REL=BOOKMARK ってのがあったみたい．その時の定義は今の HTML 4.0.1 や XHTML とはちょっと違っていたように見えます．最終的には破棄された規格 HTML 3.0 の検討では HTML 4.01 とほぼ同じ定義がされていました．それは HTML 3.2 の Proposed Recommendation 05-Nov-1996 にもありましたが，HTML 3.2 の勧告では REL=Bookmark が無くなっているみたい．ぼくが HTML の仕様を気にするようになったのは HTML 4.0 以降ですから HTML 3.2 とか HTML+ なんてのは良く知りません．でも HTML 4.0 以降は rel="Bookmark" については，本当に簡単にしか書いてないので良くわからないのですよ．だから古い規格についての文書を見てみたのです．

HTML 3.0 の The Head Element and Related Elements から引用するとこうでした:

REL=Bookmark

Bookmarks are used to provide direct links to key entry points into an extended document. The TITLE attribute may be used to label the bookmark. Several bookmarks may be defined in each document, and provide a means for orienting users in extended documents.

An example of toolbar LINK elements:

    <LINK REL=Previous HREF=doc31.html>
    <LINK REL=Next HREF=doc33.html>
    <LINK REL=Bookmark TITLE="Order Form" HREF=doc56.html>

ここでは用例があるんですね．これを見ると，REL="Bookmark" は，もとの文書と関連のある外部のドキュメントへの URL になっていて，リンク集の URL を指しているわけではないようです．この例では，商品紹介のページから REL=Bookmark で注文フォームのページの URL を指し示めしているようです．

XHTML では次のように定義されています:

Bookmark

Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The title attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.

rel="Bookmark" でリンク集のページを指すのが適当なのは，Web サイトという一連の文書があって，その一連の文書の中の文書の一つとしてリンク集を指す場合でしょう．だから rel="Bookmark" でリンク集も指すのは間違いではないかもしれないけど，リンク集以外をさす事もあります．例えば Weblog の各記事へのリンクは rel="Bookmark" になるという考えがあるようです．一連の文書の中に「しおり/Bookmark」をつけておくということですね．HTML の head 要素の中の link 要素で使う場合，rel="Bookmark" で指すべき URI が複数ある場合は，rel="Bookmark" の link 要素を列記することになります．

• Dealing with Large Documents
  http://www.w3.org/MarkUp/HTMLPlus/htmlplus_55.html
• HTML 3.2 Reference Specification
  W3C Proposed Recommendation 05-Nov-1996
  http://www.w3.org/TR/PR-html32-961105
• HTML 3.2 Reference Specification
  http://www.w3.org/TR/REC-html32
• Modularization of XHTML - Defining Abstract Modules
  http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_LinkTypes
• Putting rel="bookmark" to work - Anne’s Weblog about Markup & Style
  http://annevankesteren.nl/2003/08/putting-relbookmark-to-work
  Weblog での個々の記事(エントリー)の恒久的な URI (permalink) へのリンクは rel="bookmark" になるという考え．

だから del.icio.us などのオンラインブックマークを rel="Bookmark" で指すのは，普通にオンラインブックマークを利用しているのであれば，間違いということになりますね．

Permalink Trackback URI http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050817n1 TrackBack

microformats についての誤解と，ぼくが理解している範囲

microformats って一体なんだ? という問いに対して，XFN などの具体的なものを例にしてこんなものだよって説明するのは簡単だし分かりやすそうです．でもその結果として，
<a href="example.com/">example</a>
って書いていたのを
<a rel="example" href="example.com/">example</a>
って書くようにしたのを microformats だよっていうような，誤解がひろがっているんぢゃないかなって不安になりました．ぼくも良くわかっていないので人に説明するレベルではないと思っているのですが，とりあえずぼくが理解している範囲を整理しておこうかなって思います．つっこみ大歓迎です．

まず RDF を使った Semantic Web っていうものがあります．RDF はとても応用範囲が広く，統一的な方法でいろいろなものを意味付けしていくことができます．HTML 文書は画像ファイルをデータとしたら，そのデータのデータつまりメタデータを RDF で表現して既存の HTML 文書や画像ファイルにメタデータとして意味を付加して行きます．このメタデータは意味をコンピュータが処理できる形で記述するので，例えば検索エンジンでメタデータを利用したら検索は単純な文字列マッチングではなくて，意味を処理した検索ができるようになると...

でも，RDF はいいとして，もっと特定の問題について簡単にできないかなっていう話が出て来ました．HTML 文書と別に RDF を用意するのではなくて HTML でマークアップする時に，文書構造だけでなくちょっとした意味もマークアップできなかなっていう話．順番がどうなっているのか良くわかっていませんが XFN っていうのが出て来ました．はじめは RDF を使った Semantic Web に対して小文字の semantic web と紹介されていた XFN などのアプローチは，後に microformats と呼ばれるようになったようです．

例えば XHTML 文書の中で，友達について話題にする時にその人の名前の部分をハイパーリンクにして
<a href="http://sususmu.cup.com/">すーさん</a>
と記述するのは，今まで普通に行われて来たと思います．友達についてのメタデータとして Semantic Web なら FOAF を使って記述するなどの方法がありますが，もっと簡単にってことで XFN では
<a href="http://sususmu.cup.com/" rel="friend met">すーさん</a>
のように記述します．この方法の利点は以下のようなものがあります:

• RDF/XML で FOAF を記述のように，HTML 文書とは別の独立した記述をしなくてよい
• RDF での記述と比べると，非常に簡単に記述できて，記述する量も少ない
• 記述形式と意味付けをきちんと定義しておけば，メタデータの抽出を自動化できる
• 従来の HTML の決まりの範囲で記述できる

HTML/XHTML では rel 属性の値はあらかじめ決められたもの以外を使う場合は，profile を用意する事になっています．XFN は人間関係を表現するのが目的で，その profile は http://www.gmpg.org/xfn/11 にあります．そして profile は <head profile="http://www.gmpg.org/xfn/11"> のように head 要素の profile 属性で指定します．XFN の profile は XMDP という profile の記述の規格があって，それにそった記述がされています．

• rel 属性値の拡張には profile が必要である
• profile は head 要素の profile 属性で定義する
• profile で microformats の意味付けを定義する
• 記述形式を定義する

参考:

• ちょっとしたメモ - 小文字のsemantic web
  http://www.kanzaki.com/memo/2004/03/05-1
• 武田の近況報告: Microformats (とSemantic Web）
  http://www-kasm.nii.ac.jp/mt/archives/000063.html
• naoyaのはてなダイアリー - microformats って一体何だ?
  http://d.hatena.ne.jp/naoya/20050715/1121411871
• hail2u.net - Weblog - XHTML Meta Data Profiles
  http://hail2u.net/blog/internet/xmdp.html

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

で，誤解の例としてはこんなのがあります:

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

<a rel="hatenab" href="http://b.hatena.ne.jp/onohiroki">僕のブックマーク</a>です

rel 属性値は profile で定義してそこで意味付けをします．上の例では a 要素で rel 属性値 hatenab とある場合は href が指す URI ははてなブックマークであるってことになるのかな? こういう形なら，profile であらゆるオンラインブックマークサービスなどに対応した rel 属性値をあらかじめ決めなくちゃ駄目ですよね．そうではなくてオンラインブックマークサービースだという属性値を定義しないと．だから hatenab でなく bookmark とかね．

ちなみに標準で rel 属性値に Bookmark って定義されていますよね．

[削除 2005-08-17:これは microformats でもなんでもないけど，ふつうに rel="Bookmark" 使ってこれでいいぢゃん:

<link rel="Bookmark" href="http://b.hatena.ne.jp/onohiroki" title="はてなブックマーク" />

]

• yohei-y:weblog: Web らしく URI で連携する方向
  http://yohei-y.blogspot.com/2005/07/web-uri.html

上の「Web らしく URI で連携する方向」での話題で「<a rel="mixi" href="http://mixi.jp/view_profile.pl?">mixi</a>も使ってるよ。」なんてのは，microformats としての条件を満たしていないと思うっていうのは，つまりそういうことです．profile を定義するということを意識していないから rel 属性値をどうするかというところで間違えるのではないでしょうか．profile を定義することと，その profile が他で応用できるようにするということを考えないとダメだと思うのです．

Permalink Trackback URI http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050815n1 TrackBack

一つの RDF/XML で Tracback URI と Account 情報を示す

8 月 11 日に Tracback URI を示す RDF と Account 情報を foaf:holdsAccount を用いて示す RDF を一つの RDF/XML として表現する例を示したけど，間違ってました．早速訂正しました．

• 他の人のAccount Auto-Discovery用RDF - 徒書
  http://www.akatsukinishisu.net/itazuragaki/xml/another_AAD.html

rdf:Description要素が空要素になっており、それと別にfoaf:maker要素が独立して書かれているので、リソースのURIと作者との関連が外れた状態になっています。rdf:Description要素でfoaf:maker要素を囲うようにした方がよいように思います。

そうそう，ご指摘のとおりです．書く前はそう書こうと思っていたはずなのに，どうしてかあのように書き間違えました．やっぱり W3C RDF Validation Service でグラフを書いて確認するのが基本ですね．

ご指摘ありがとうございました．

で，間違えたところを修正すればこうなります:

<!--
<rdf:RDF
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:dc="http://purl.org/dc/elements/1.1/"
 xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
 xmlns:foaf="http://xmlns.com/foaf/0.1/">
<rdf:Description rdf:about="http://onohiroki.cycling.jp/"
 trackback:ping="http://onohiroki.cycling.jp/tb/tb.cgi/top_page"
 dc:title="おのひろきおんらいん"
 dc:identifier="http://onohiroki.cycling.jp/">
 <foaf:maker rdf:parseType="Resource">
  <foaf:holdsAccount>
   <foaf:OnlineAccount foaf:accountName="onohiroki">
    <foaf:accountServiceHomepage rdf:resource="http://www.hatena.ne.jp/" />
   </foaf:OnlineAccount>
  </foaf:holdsAccount>
 </foaf:maker>
</rdf:Description>
</rdf:RDF>
-->

Permalink Trackback URI http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050814n1 TrackBack

xsltproc を使って XHTML からメタデータを抽出してみる

XML.com の記事を見ていたら，面白い事が書いてありました．Libxlst を紹介する記事だったんですが，xsltproc で，直接 Web ページや XSLT のスタイルシートをダウンロードしつつ，変換するっていう事．そんな事ができるって知りませんでした．記事の例では Google News のページを得て，それに XSLT を使ってブロックレベルの HTML 要素に固有の id を挿入するっていうデモでした．

xsltproc -html -o gnews.xml http://www.snee.com/xml/xslt/addids.xsl http://news.google.com/news?ned=tus

Windows ではどうだか知らないけど，Mac OS X とか Linux では xsltproc というコマンドが使えるようになっていると思います．さっそく試してみました．これ自分の環境でやってみたら，Google の URI はダブルクォーテーションで囲む必要がありました．

xsltproc -html -o gnews.xml http://www.snee.com/xml/xslt/addids.xsl "http://news.google.com/news?ned=tus"

したら，gnews.xml っていうファイルが生成されました．これは元と比べると id 属性が挿入されて，そこに固有 ID が与えられてました．まぁ変換の内容は XSLT が分かる人はスタイルシートを見れば数行なのですぐに分かると思います．

これ，-html っていうオプションを与えると，入力が整形式 XML でない HTML でも受け入れるってのが面白いですね．それに HTML をいったんダウンロードしなくても，直接 xsltproc で取って来れるって知らなかったですよ．

これを使って XHTML に埋め込まれているメタデータを RDF/XML として抽出するのを試してみました．GRDDL だと，XHTML にメタデータを埋め込み，その XHTML の profile の情報から利用できる XSLT スタイルシートが得られるようになっています．ここでは profile を見て XSLT スタイルシートを見つけるのでは無くて，神崎さんの xh2rdf.xsl を利用します．

xsltproc -o metadata.rdf xh2rdf.xsl http://onohiroki.cycling.jp/2005-08-05-1

これで metadata.rdf というファイル名で RDF/XML が得られます．もっとあちこちで GRDDL が利用されたらおもしろいかな．

参照先:

• XML.com: Appreciating Libxslt
  http://www.xml.com/pub/a/2005/08/03/libxslt.html
• XSLT スタイルシート xh2rdf.xsl
  http://www.kanzaki.com/parts/xh2rdf.xsl
• Embedding metadata in XHTML and extracting them as RDF
  http://www.kanzaki.com/docs/sw/xh2rdf.html
• XHTMLからメタデータを自動抽出する
  http://www.kanzaki.com/docs/sw/xh2meta.html

Permalink Trackback URI http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050805n1 TrackBack

2005 年 7 月のアクセス統計発表

今月のアクセス解析では，6 月よりややアクセスが増えているような傾向でした．一方でトップの welcome ページへのアクセスは減っていました．紫陽花の季節だからか麻綿原高原についての検索が多かったようです．

• おのひろきおんらいん全体で 337,791 ページビューで，先月の 306,422 ページビューより増加
• 1 日あたりの訪問数は平均 2,834 で，先月の 2,722 より増加
• Web サイトのトップの welcome ページは 59,378 ヒットで，先月の 61,721 ヒットより減少
• 履歴もしくは日誌の RSS は 43,413 ヒットで，先月の 39,763 ヒットより増加

従来は，「履歴もしくは日誌」の特定記事の URI は http://onohiroki.cycling.jp/weblog200508.html?d20050801n1_ という感じでした．長いし .html に ? がついてクエリーが続くという形式．Google でもインデックス化はされていたのですが，あまり良い感じではありませんでした．それで http://onohiroki.cycling.jp/2005-08-01-1 っていう形の URI も有効になるように設定しました．古い形式も生きていますが，今後はより簡素な新しい形式を使って行く事にしたいと思います．Google でもきちんとインデックス化されていて，各記事が個別の HTML として扱われるようになりました．

Weblog 用のツールなどのコンテンツマネジメントシステム (CMS) は使っていなくて，HTML をずらずら書いたファイルを，月ごとに一つのファイルに区切ってアップロードしています．それに SSI を使って各記事を表示させるのを実現していたので，月ごとの HTML ファイルにクエリー文字列を付加した URI になっていたのですが，URI の書き換え設定をして新しい URI の形式が使えるようになりました．

後から思うと http://onohiroki.cycling.jp/2005/08/01/1 っていう形式にすれば良かったなぁって思うのですが，まぁいいや．

新しい形式の URI を採用したのは 7 月 28 日からです．でも Webalizer のアクセスログに載ってないみたい．拡張子が無いからかなぁ．設定間違っている?

Permalink Trackback URI http://onohiroki.cycling.jp/tb/tb.cgi/weblog_d20050801n1 TrackBack