Hatena::Groupweb

vantguarde

1.8

MicrodataがHTML5より分離

| 23:38

だいぶ前ですが、Microdataについて書いた事がありました。

Microdataをひとことで言うと「セマンティックなやつ」になります。取りあげてから仕様がかなり変更されてるので、参考にならなかったりしますが…

さて、セマンティックなやつ+HTMLといえばRDFaがあるわけで、それに似たような仕様ができると、まあ面倒な事になります。というわけでメタ議論も含め数え切れないほどのメールが流れ、不毛な時期がけっこう続きました。

で、最終的に「MicrodataをHTML5から分離する」というChange Proposalが受理されて、分離する事が決定されました。Chairのひとたちがまとめた文書には、決定に至るまでの経緯なんかもまとめられています。

で、今日の朝あたりに早速分離する作業が行われました。

W3CのCVSサーバになんか問題があるらしくHTML5 EDの方にはまだ反映されてませんが、MicrodataのEDはすでに公開され、FPWDとして公開するためのCfCもMaciejより投げられました。

MicrodataはDOMインターフェースを備えてるのと、DnDと組み合わせて構造化されたデータを移動できるなんて提案もされてますし、面白い規格ではあります。

Mozillaは実装を検討しているようです。

I approve of publishing this. We're planning on implementing this in Firefox, though don't have a specific timeline yet. Hopefully there will be some support in Firefox 3.7, definitely in the release after that.

Re: CfC: Publish HTML5 Microdata as First Public Working Draft and a new HTML5 Working Draft

頑張れば3.7にちょっと入るかもとか言ってますね(注:Mozilla時間)

また、Operaのvideo実装をやってるらしいPhilip JägenstedtさんがMicrodataにコミットしていたりします。個人的な興味だと確か言っていましたが、ちょっと期待したいかなと。

5.14

GoogleのRich Snippets

| 00:42

触れておきますよ。

Today, we're announcing Rich Snippets, a new presentation of snippets that applies Google's algorithms to highlight structured data embedded in web pages.

Rich Snippets give users convenient summary information about their search results at a glance. We are currently supporting data about reviews and people. When searching for a product or service, users can easily see reviews and ratings, and when searching for a person, they'll get help distinguishing between people with the same name.

Official Google Webmaster Central Blog: Introducing Rich Snippets

検索結果にレビューや人の名前があったら、ちょっと違う見た目になるようです。

で、レビューや人についての情報をどうやって判断するかというと、microformatsやRDFaを使うと。書いたら何もしないでも結果に表れるってのは、Yahoo!のSearchMonkeyと違って良いところかなと。

ただ、現在の実装はmicroformats, RDFaともに良くない感じです。結構厳しいマークアップを課すmicroformatsは、それが定義されていないように使われる可能性があります。まあ、コンベンションなのでそこは崩れても良いのかもしれませんが。

RDFaは、自分で好きな語彙を使う事ができず、data-vocabulary.orgで定義されているプロパティのみが対象となるようです。そして公開されているRDFスキーマが良くない感じ。ここは報告しておかないと。

じゃあ、Googleは何も知らないアホ集団か(そしてGoogle叩きへ)みたいな流れになるかというとそうではないです。指揮をとってるのはAppleでMCFをつくって、後にNetscapeでRSSへと発展させたRamanathan V. Guhaですし、ちゃんとしてます。

インタビューも結構面白いですし、今後の向上に期待したいところ。

mCard ― vCard×microdata

| 00:11

HTMLでメタ情報な界隈はよく分からない盛り上がり方をしてますね。

  • HTML5にmicrodataが追加
  • 「セマンティックHTML/XHTML」予約開始
  • microformatsのvalue-class-pattern
  • GoogleのRich Snippets

なんなんでしょうね一体。

さて、microdataですが、“predefined vocabulary”というセクションが追加されました。

数日前にHixieがvCardがどうのこうの言ってたので、なにかやってるんだとは思ったんですが、そうきましたか。

例はないですが、だいたいhCardと同じです。Implied "n" Optimizationも導入されてるので、参考にしたんでしょう。

<section>
  <h2>profile</h2>
  <dl item=vcard>
    <dt>name:
    <dd itemprop="fn nickname">vantguarde
    <dt>weblog:
    <dd><a href="http://web.g.hatena.ne.jp/vantguarde/" itemprop=url>web:g vantguarde</a>
  </dl>
</section>

たぶんこんな感じ。subtypeの書き方とかは、microformatsよりかなり自由に書けそうな感じです(良く読んでないので例は書いてない)。

昨日「reversed DNS labels無しのプロパティは概念の衝突が起こる」って書きましたが、アイテムの型がvcardの場合は特別な処理をさせるようにするんでしょうね。

発展すれば、「itemcom.example.***って書けば、それ以下のラベル無しアイテムはcom.exampleに属する」とかそんな定義も生まれそうな気がします。良いのか悪いのかは解りませんが。

FOAFとDublin Coreあたりが入ってくれると面白いなあ。

5.13

microdata雑感

| 02:38

(うわわわ、セクションのやつよりずっとブックマークがついている。なぜ。)

それはそうとですよ。

I've renamed property="" to itemprop="".

[whatwg

はやいよ!

というわけでpropertyitempropに改名しました。前のエントリも書き換えました。ふー。

というわけでまだまだ落ち着いた感じのしないmicrodataですが、前の奴についたコメントとかを読んでみたので、雑感などを。

microformatsとの関連

microとあるせいかつながりがあるように思ってる人がいらっしゃるようですが、ほとんど無いと言ってよいでしょう。かたや語彙(プロファイル)の集合で、かたやフレームワーク。かたやhuman readable優先、かたやそういう目的じゃない。いろいろ違います。

仕組みの設計やHixieの発言を見るに、RDFaにかなり近い仕組みです。microformatsって一概にまとめるのも結構危ないですね。一貫した仕組みがないのに、そう見えてしまうし。

RDF

RDFとの違いをちょっと書きましたが、もうちょっと。

現在のproposalでは、RDFとしても出力可能なんですが、カスタム語彙を書く時に問題がでてきます。ただ単itemprop=titleとか書いちゃうと、それがhttp://www.w3.org/1999/xhtml/custom#titleというURIにマップされてしまうので、概念の衝突が起こってしまう可能性があるんですね。

共有を目的としない文書であればcom.example.***みたいに書く必要がないわけなんですが、RDFに変換した時にあまりよくないわけです。

あとは、全てのアイテムの主語が文書のURIになってしまうのもRDF的には残念なのかなと。subjectがIDREFじゃなくてURIも取れるように変更されれば、それを利用して回避する事はできそうですが。

めんどう?

「面倒」とか「手書きは」的な意見を目にしたのですが、ちょっとよくわからないんですよね。

  • com.example.***」みたいなのがめんどくさいのか
  • それともこういう行為自体が面倒なのか

前者であれば、手書きであっても例えば--titleとでもまずタイプして、あとでcom.example.に置換しておくとか、そういう工夫をすればclass書くのと大差がないように思います。あと、一番手間がかかるのは、語彙を設計したり、正しくマークアップしたりする事だと思うので、そこまで問題にならないかなあと。

で、後者であれば本末転倒というかなんというか。文章中から機械可読なデータをある程度楽にするためには、spanなりでマークアップする必要があるわけで。それはRDFaだってmicroformatsだって同じです。そういう面倒をかけないといけないし、かけてもいい人のために用意されてるものでもあるわけで。

それともあれですかね、インライン要素が本文中にいっぱいあるのは「美しくない」てきな感覚なんでしょうかね。うーん。まあいいや。

DOM APIが用意されている強み

しかし、DOMのAPIが用意されているのはいいですね。RDFaはたぶん定義してないでしょうし、microformatsはDOM以前にプロファイル毎に実装を作らないといけないですし。

インターフェースを全然見ていないので解らないんですが、スクリプトからアイテムやプロパティのコレクションをいじる事が出来ると楽しそうかなって思いました。itempropとか書かずとも、データテーブルの情報だったりをアイテムとしてマッピングできたりなんかすると、面倒ってことにはならなさそうですし。

5.11

HTML5のmicrodata

| 02:04

おおおっ。きましたよーー

microdata in HTML5の最初のドラフトが上がってきました。ちょっと前にユースケースが集められてたので、追加する気なんだとちょっとびっくりしたのですが、すごいですねー

さて、ざっとですが読んだので紹介を。試しにここの簡単な概要を書くと、こんな感じになるようです。

<section item="com.example.weblog">
  <h2>このサイトについて</h2>
  <p><span itemprop="com.example.title">vantguarde</span>っていうweblogです。
  <p><span itemprop="com.example.author">id:vantguarde</span>がやってます。
</section>

itemは新しい「アイテム」を、itempropはハッシュでいうnameを表します。valueは要素のtextContentになるんでしょうか。

itemがネストされると、構造化されたデータを値に取る事が可能です。最新のエントリーについての情報を追加してみます。

<section item="com.example.weblog">
  <h2>このサイトについて</h2>
  <p><span itemprop="com.example.title">vantguarde</span>っていうweblogです。
  <p><span itemprop="com.example.author">id:vantguarde</span>がやってます。
  <p itemprop="com.example.latest" item>最新の記事は
    <a itemprop="com.example.permalink" href="/html5_microdata">
<span itemprop="com.example.title">HTML5のmicrodata</span></a>です。<br>
    <time itemprop="com.example.pubdate" datetime=2009-05-11>2009/05/11</time>に公開されました。
</section>

その他、idの付いた要素を参照し、アイテムの主語とするsubjectなんて属性も定義されています。RDFaからの影響がよく解る属性ですね。

itempropの語彙ですが、基本は例に挙げたようなJavaっぽいNamespaceを使うようです。ただドメイン持ってない人のためなのか、URLも使えるようです。URLといいつつHTML5の「URL」にはURIも含まれるはずなので、tag URIとかも使えるのかなとは思います(解決されるのかどうかはさておき)。

さて、microdataはmicroformatsよりも“human readable”に狂ってはおらず、機械に都合の良いデータも簡単に埋め込む事が出来るようです*1

使うのはproperty付きのmeta要素です。microdataの追加にあわせ「itempropがあるものはflow content」という定義が追加されました。これでbody内に書く事が可能です。

<section item>
  <h2 itemprop="com.example.label">コロッセオ</h2>
  <meta itemprop="com.example.lat" content="41.890278">
  <meta itemprop="com.example.long" content="12.492222">
  <p itemprop="com.exmaple.desc">ローマにある円形闘技場跡です。</p>
</section>

データの利用ですが、DOM APIが提供され、またJSONやRDFへの変換アルゴリズムも用意されてます。

面白いですね。RDFとの違いをざっと考えてみましたが、リテラルやURIを持つリソース(ObjectProperty)、データ型などの概念がないこと、同じプロパティを複数持てない事でしょうか。まあでも、語彙を工夫すればそこまで問題ない気がしています。

propertyなど属性名のコンフリクトは気になるところですが、RDFaの処理モデルを考えると問題ないのかなと。書く側に紛らわしいっていう問題は残りますが。

実装の段階でどうなるのかも含めていろいろ楽しみです。

*1:目的が機械のためのデータを表現することなので、出来ないと困るわけですが

4.14

rel-canonicalとかrevとか

| 22:46

一つ気になるのが、URLの正規化*1としてただ使われていそうなこと。あまり適切な使われ方だとは思えない。

というのは、rel, revはHTML文書とリンク先(元?)のURLが表すリソースとの関係を表すものなので、URLとURLというわけではありません。URLはただの識別子なので、同じリソースに別のURLとかURIを割り当てる事が可能なわけです。なのでまあ、なんかもやもやします。

ただ、「正規化されたURLが表すリソース」として別のリソースに一本化できるよう使えるなら、なかなか面白いですね。alternativeと何が違うんだって少し思いますが、alternativeはなんとなくsymmetricなプロパティとしてのイメージを持ってます。canonicalは一方向というか。

Anneも同じこと書いてますね。って、canonicalってsame-originなんだ。じゃあダメじゃん。

*1:この言い方はあまり適切じゃない気もするけど

Contact: @vant / lepetitcroissant@gmail.com.