ちょっとしたメモ

思いつき、マイナーな追加更新、実験文書などについてのちょっとしたメモです。RSS /RDFもあります。

メモの最新から数えて6~10番目の記事を表示します。

FavikiとタグとDBpedia

先日登場した新しいブックマークサービス Faviki は、ユーザがタグを与えるときに、英語版Wikipediaに登録された語句を候補として提供することで、語彙のゆれ(同義語の問題)を解消しようという特徴を持つ。さらに、タグとWikipediaの連動により、多義語の問題(Operaは歌劇かブラウザか)をも解決する可能性を示す。UIも工夫されており、タグを巡る困難へのひとつの答えともいえる。

タグの共有

以前「タグとオントロジー」で検討したように、タグを広く共有するためには、同義語、多義語の問題を処理する必要がある。アプローチとしては、

  • 従来のタグシステムを前提として、ユーザが自由に与えたタグから、統計的な手法を利用して共通項を見出していく方法と、
  • ユーザがタグを与える時点で、そのタグを共有可能なもの(統制されたもの)にする方法

が考えられた。Favikiの場合は、後者の立場で、与えられるタグをWikipediaの登録語彙に限定してしまおうというものだ。

タグをあらかじめ統制する方法としては、TwineCalaisなどのように、サービス側がコンテンツを解析して自動的にタグを与える手もある。これは利用者にとっては非常に手軽で、特に深く考えなくても共有可能なタグが加わっていくという利点がある一方、コンテンツによっては解析がうまく行かず、適当とはいえないタグがついてしまうこともある(もちろん、利用者がタグを追加したり修正することは可能)。

これに対してFavikiの場合は、タグはあくまでユーザが考えて与える。このとき、タグの最初の数文字をフォームにタイプすると、Ajaxを用いてWikipediaからの語彙が候補として表示されるので、そのリストから選択することにより、タグを統一するというわけだ。たとえば、「Opera」の場合は、別候補として「Opera (web browser)」も示され、よく見て選べば“歌劇かブラウザか”もうまく区別できる。また、同じコンテンツに別のユーザがすでにタグを与えていたら、それはクリックだけで選択できるようにあらかじめ表示されるから、人気コンテンツのタグ付けはそれほど面倒ではない。

DBpedia

Favikiの特徴のひとつが、Wikipedia登録語をタグ候補として示すために、DBpediaを利用しているところだ。DBpediaは、英語版を中心にWikipediaから構造化されたデータを抽出し、RDFの形で提供しているもの。抽出した語彙には、リンクするデータとして利用可能なURIが与えられている。たとえば、WikipediaのRoger Norringtonに対応するデータは、次のURIで表現される。

http://dbpedia.org/resource/Roger_Norrington

このURIは、(Wikipediaのようなウェブページではなく)「人物(リソース)としての」ロジャー・ノリントンを表現しているため、さまざなRDFの記述で直接用いることができる。こうした固有名詞や概念を表すURIが、Wikipediaの膨大な語彙から取られているので、利用価値が高い。さらに、WikipediaのカテゴリやInfoboxのデータもRDFによって関連付けられており、様々なデータを「リンク」して辿っていくことが可能だ。

FavikiはタグにこのDBpediaを用いているので、タグに対応するURIから、さらに関連する情報につながる「リンクするデータ」が実現するという点でも期待が高まる。FavikiのRSSを見ると、次のような「タグURI」が含まれているのが分かるだろう。

(例)

<taxo:topics>
 <rdf:Bag>
  <rdf:li resource="http://dbpedia.org/resource/Roger_Norrington" />
  ...
 </rdf:Bag>
</taxo:topics>

タグを表現するモデルとしては、上記のRDFはベストとは言い難いが、タグ自身のURIにDBpediaを導入したことは大きな一歩だ。サービスがやや凝りすぎていて、ブラウザ(の設定)によっては一部動作が不完全なところがあったり、利用が殺到すると動作が重くなってしまう(ように思われる)問題はまだ見られるものの、タグの可能性を広げるサービスとして、注目しておきたい。

〔追記〕「ベストとは言い難い」というのは、FavikiのRSS 1.0は、del.icio.usの場合と同様、itemの主語(rdf:aboutの値)をブックマーク対象ページのURIとし、そこにブックマークとしてのtaxo:topicsdc:creatorなどのプロパティを与えている点。タグとオントロジーの「リソースとタグと作者」でも検討したように、これは、ブックマーク付与者が対象ページの作者であることを意味してしまう。さらに複数のRSSをマージしたときに、だれがどのタグを付与したか分からなくなってしまうという問題もある。単なるフィードとしては機能するのだが、これではRDFが生きてこない、というよりも誤った情報を提供してしまうのだ。これはFavikiに限った話ではなく、del.icio.us型RSSを提供するブックマークサービスに共通する問題。

関連メモ:

alt要素?

alt要素なんて、もちろん今の仕様には存在しないわけだけれど、それらしきものが検討された様子がある…という話を、何かのページの一部に書いたような気がするのだが、消してしまったみたいなので、思い出しながら書き記しておこう。検討の痕跡が残っているのは、XHTMLモジュール化仕様のDTD実装ページだ。

このページのF.2.5. XHTML Qualified NamesのセクションBは、「XHTMLの全要素型の名前空間修飾名を提供するためのパラメータ実体を宣言する」とされている。つまり、このセクションでxxx.qnameという形の定義があれば、xxxはXHTMLの要素型名として用いられる(と想定されている)ことをあらわす。このセクションの最後には、次のような記述がある。

<!-- Provisional XHTML 2.0 Qualified Names  ...................... -->
<!-- module:  xhtml-image-2.mod -->
<!ENTITY % alt.qname     "%XHTML.pfx;alt" >
<!-- end of xhtml-qname-1.mod -->

XHTML 2.0の暫定的な修飾名として宣言されているのがalt.qname。すなわち、XHTMLモジュール化仕様が検討されていた当時は、XHTML 2.0で「alt要素」を導入する考え(可能性)があったということだ。もっとも、XHTML2の最初の草案がでたときには、この幻の「alt要素」は含まれていなかったのだが。

これがどんな使い方を想定したものなのかは、想像するしかないが、OASISのDITA言語にはalt要素が定義されていて、次のような用例が示されている。

(DITAのimage要素とalt要素の例)

<image href="tip-ing.jpg">
  <alt>Here's a Tip!</alt>
</image> 

DITAのimage要素にはalt「属性」も定義されているが、こちらは非推奨(deprecated)で、代替テキストはalt要素で示すこととされている。おそらく、XHTMLでもこのような使い方が念頭にあったのだろう。

HTML5でのalt属性についてはいろいろな議論があるようだけれど、実は2007年8月に「alt要素」の提案も行われていた。このアイデアは、上記のXHTML2のものとは別の話で、ESW WikiのHTML/ABetterAltページにまとめられている。採用されるには至らなかった模様だが、なかなか興味深い内容になっている。alt属性の問題点や、本来はそれに取って代わるはずのobject要素もうまく行かない点など、もう一度考えてみる価値はあるだろう。

実際に、HTML文書に含まれるオブジェクトは、画像だけでなく多様化しており、代替テキストをきちんと提供することは以前にも増して重要になってきている。「alt要素だって? 寝ぼけてんじゃないの?」と言っている場合じゃないかもしれない。

metaprofのブロックレベル要素処理を強化

metaprofをプロファイルに指定してGRDDLで処理するとき、ブロックレベル要素に接頭辞付@class属性値を用いると型付ノード要素を生成しますが、文書自身とこのノードをfoaf:topic以外のプロパティで結び付けたいという要望を見かけたので、対応してみました。@classに、プロパティをあらわす値を付け加えるだけで、任意のプロパティを利用できます。

要望であげられていた例を使うと、

(例)

<dl class="prism.isTranslationOf foaf.Document">
 <dt>Original Page</dt>
  <dd><a href="http://www.alistapart.com/articles/previewofhtml5"
         class="about">A List Apart:  Articles: A Preview of HTML 5</a></dd>
 <dt>Author</dt>
  <dd><a rel="creator" href="http://lachy.id.au/">Lachlan Hunt</a></dd>
 <dt>Copyright</dt>
  <dd><a rel="rights" href="http://www.alistapart.com/copyright/">Copyright &copy;</a>
  1998-2008 A List Apart Magazine and the authors.</dd>
</dl>

上記のように記述すれば、以下のRDFグラフが得られます(最初のfoaf:DocumentはXHTML文書自身です)。〔追記〕型付ノード要素の主語(rdf:about)にするa要素は、class="about"としてください。慌ててrel="about"と書いていたのを修正しました)。

(例)

<foaf:Document rdf:about="">
 ...
 <prism:isTranslationOf>
  <foaf:Document rdf:about="http://www.alistapart.com/articles/previewofhtml5">
   <rdfs:label>A List Apart: A Preview of HTML 5</rdfs:label>
   <dc:creator>
    <foaf:Agent>
     <rdfs:label>Lachlan Hunt</rdfs:label>
     <foaf:homepage rdf:resource="http://lachy.id.au/"/>
    </foaf:Agent>
   </dc:creator>
   <dc:rights>
    <rdf:Description rdf:about="http://www.alistapart.com/copyright/">
     <rdfs:label>Copyright</rdfs:label>
    </rdf:Description>
   </dc:rights>
  </foaf:Document>
 </prism:isTranslationOf>
</foaf:Document>

(ここで、foaf:dc:はあらかじめmetaprofで定義しているので直接foaf.dc.としてXHTMLの@class属性値で使えますが、prism.は未定義なので、XHTMLのlink要素で rel="schema.prism" href="..." という形で指定しておく必要があります)

ブロックレベル要素の@class属性の扱いは、ピリオドを含む(以下、接頭辞付き)名前かどうかで次のようになっていました。

  1. 属性値が大文字で始まる(Bookなど)か、接頭辞+大文字で始まる値(foaf.Documentなど)なら、型付ノード要素とする
  2. 属性値が接頭辞+小文字で始まる値(prism:isTranslationOf!など)ならプロパティ要素として、内容をリテラル値にする
  3. それ以外の@class値は無視する(abstractなどの予約値は別)

今回、1.と2.を合わせる形で、新しい規則を追加します。

  • 属性値が接頭辞付き名を含むとき、1つ目が接頭辞+小文字開始名、2つ目が接頭辞+大文字開始名ならば、それぞれをプロパティ要素型付ノード要素とする

接頭辞付き名前の順序を逆にする(1番目を接頭辞+大文字開始名とする)ことはできませんが、この順序さえ正しければ、それ以外の名前(クラス属性値トークン)が含まれても構いません。なお、2つめのトークンとして、接頭辞のない大文字で始まる値(Bookなど)を用いても、型付ノード要素は生成されないので注意してください。

また、例で強調しているのは、要望のオリジナルから書き換えている部分ですが、@rel属性をうまく使うことで、型付ノード要素の中の情報を、リテラルではなくリンク可能なデータとして表現できます。

関連メモ:

SKOSの新草案

SWBPのプロジェクトという位置づけで草案が公開されていたSKOSが、W3Cの標準化トラックに乗って、改めて最初の草案 SKOS Simple Knowledge Organization System Reference が公開された。シソーラスや分類表などの図書館系の知識体系を、できるだけそのままRDFで表現できるようにする語彙+モデルで、個人的なカテゴリや分類方法を体系化するのにも使える。さまざまな領域において、すでに多くのシソーラスや用語集が構築されているわけだが、これらは必ずしもOWLなどでそのままクラス体系として記述できるとは限らない。こうした知識や情報を、無理なく「セマンティック・ウェブ」に組み込むモデルとして、SKOSの果たす役割はかなり大きいのではないかと期待される。

SKOSでは、シソーラスや分類で扱う「術語」を、OWLのクラスではなく、概念リソース(Conceptual Resource)として扱う(skos:Conceptクラスのインスタンスになる)。概念リソース同士の関係は、上下関係ならskos:broaderskos:narrower、参考関係ならskos:relatedとして表現される(シソーラスのBT、NT、RTと同じ)。前者はOWLクラスのサブクラス関係と似ているが、クラス階層は属関係(継承の関係、is_a関係)しか扱えないのに対し、skos:broaderskos:narrowerは全体部分関係やインスタンス関係も扱えるという柔軟さがある。

たとえば、カテゴリとして「日本」と「東京」を考え、前者を後者の上位カテゴリにするというのはごく普通だろう。しかし、これらをowl:Classとして扱い、ex:東京 rdfs:subClassOf ex:日本 .としてしまうのはおかしい。東京は日本の一部(全体部分関係)であって、日本の一種(is_a関係)ではないからだ(さらに、「日本」をクラスというよりも、「国家」クラスのインスタンスと考えるほうがよさそうだ)。SKOSならこれらを

(例)

ex:東京 skos:broader ex:日本 .

とそのまま記述できる。多くの既存のシソーラスは、クラス体系にするためには大工事が必要になるが、SKOSならほぼ機械的にRDFに移し変えることができるわけだ。

新草案では、SWBP時代には別の仕様に分けられていた、異なるシソーラス(SKOSでは概念スキームと呼ぶ)の術語をマッピングする語彙も組み込まれた。国会図書館件名標目の「セマンティックウェブ」とWikipediaの「セマンティック・ウェブ」が同じ概念を表しているなら、

(例)

ndlsh:セマンティックウェブ skos:exactMatch wikipedia:セマンティック・ウェブ .

という記述で両者を関連付ければよい。これをowl:sameAsで結びつけると、両者は全く同一のリソースということになり、いろいろと問題が生じてしまう。SKOSはOWLで火傷をしないための回避策を随所に盛り込んで、その点でも既存知識体系を活用しやすくしている。

OWLのクラス体系と、インスタンス間の関連付けの違いは、それなりにRDFを使っている人も混乱しやすいところなのだが、このSKOS仕様書はその部分を的確に説明しており、特に第1章は入門学習素材としても使えそうな感じだ。RDFの予備知識が全くないと少々辛いかもしれないけれど、最初に記したように、実用的な知識システム構築用の語彙としても期待が持てるので、読む価値ありだと思う。

(※SWBPの旧SKOSを使っていた人は、語彙の削除追加を含むかなり大きな変更が加えられているので、要注意。ちなみに名前空間はそのまま)

HTML5はモジュール化しないの?

HML5の最初の草案が公開されたが、まともに印刷すると400ページ以上になる分量を読むのはなかなか大変。それなのに仕様は、First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections ...なんてことを要求している。まぁそれはともかく、こんな巨大な仕様は、モジュール化するのが吉というのが、HTML4実装の教訓だったんじゃないのかな。適切に設計すれば、「HTML5の○○が気に入らない」という相反する意見も、モジュールの組み合わせでうまく行くかもしれないのに。

さまざまな機器でウェブにアクセスするようになり、またその利用目的もオンライン取引からソーシャルネットワーク、小説の発表など多岐にわたる。これら全てをひとつの仕様で完全にまかなおうとすると、どうしても内容は膨大になり、また異なる要件が相反したりして、簡単にはいかない。小さなデバイスで実装するのも難しくなってくる。だからXHTMLの仕様をいくつかのグループに分割して、そこから必要なものを選んで目的に合った言語を構成しようというのがモジュール化の狙いだった。

HTML5で新たに追加するとしている要素や機能は、HTML4を丸ごと再定義しなくても、こうしたモジュールの設計によって可能になるものが多いように見える。XではないHTMLのモジュール化はやりにくいかもしれないが、XHTML版V5をモジュールベースで定義した上で、そこからHTML版V5をつくることはできるだろう。

こんなことぐらい普通なら思いつくだろうに、新HTML部会で検討されたことはないのかと調べてみたら、2007年3月22日のIRCログに次のようなやり取りがあった。

[17:42] <schnitz> XHTML Modularization is the answer to the statement
   that HTML5 is heavily intertwined and cannot be modularized,
   not true, we did it in M12N
[17:42] <schnitz> and XHTML M12N is very close to HTML 4.01
[17:43] <schnitz> so no magic XHTML2 stuff here
...
[17:55] <anne> WHATWG has been thinking about HTML for over two years now...
[17:55] <bewest> except that future vision is much worse than hindsight
[17:55] <anne> (and many on the WHATWG for a longer period)
[17:56] <anne> why do we need modularization anyway?
[17:56] <anne> on the web you don't want profiles etc.

<schnitz>ことSebastian SchnitzenbaumerはXHTMLモジュール化仕様(1.0)のエディタでもあったから、その方法論やメリットを踏まえて発言しているわけだが、他のメンバーは、もうここまで進んでいるのに何で今頃そんなこというの?という雰囲気のようだ。最後の発言に見られるように、モジュール化やプロファイルはむしろウェブを分断するから、仕様は一体化する方がいいのだという考えもあるらしい。そうかなぁ。

確かに部会憲章でThis will be a complete specification, not a delta specification.と宣言しているので、追加モジュールだけの定義というわけには行かないだろう。しかし全体をモジュール化して、articleasideheaderfooternavあたりをFunctional Elements Moduleなどとすれば、使いたい作者はフルの(X)HTML5で書けばいいし、これがHTMLの本質に反すると思うなら、納得できるモジュールだけのサブHTML5を定義して用いればいい。新機能は役立ちそうだけれど既存要素のセマンティクスを変えて欲しくなかったり、削除される要素や属性で必要なものがあるなら、XHTML1.1と新モジュールを組み合わせることもできるだろう。もしかしたら、XHTML2とだって相乗りができるかもしれない。

あー、しかし、Ian Hicksonはメーリングリストでこんなこと言ってるよ。

The "Modularization of XHTML" basis is a specification-level concern and doesn't affect authors or implementors, so I don't really understand its relevance.

モジュール化したければXHTML2を使えという反応が返ってきそうだけれど、何かもう少し賢い方法を取れないものか。

関連メモ:

and more...

→ さらに5件さかのぼってみる