ちょっとしたメモ

『セマンティックHTML/XHTML』が発刊されたので、書籍に掲載している例コードのテキストデータを用意しました。書籍ホームページの関連情報セクションをご覧ください。また、巻末参照文献リストをリンク集の形にして掲載しました。

本書の例の多くはRDFaを用いていますが、RDFaによるデータの記述は、慣れないとどんなグラフが抽出されるのか分かりにくいかもしれません。また自分で記述してみるにしても、正しいグラフが得られるかどうかの確認が必要です。

書籍第14章ではRDFaからのグラフ抽出ツールやプログラムを紹介していますが、手軽に確認できるよう、グラフ視覚化ツールも用意しました。RDFaによるHTML文書全体を記述しなくても、HTML断片からの抽出も可能なので、書籍の例を少し書き換えながら試してみると、理解しやすいのではないかと思います。

書籍の立ち読み用PDFを出版社に用意してもらいましたので、『セマンティックHTML/XHTML』目次ページにおいて公開、配布します。例セクションのデータなども追って公開する予定です。

立ち読みページには、ある程度本書の雰囲気がつかめるように、次の箇所を選びました。

• 「1.1 メタデータの誕生」および「1.2 文書のメタデータ」（10頁）
• 「8.3 FOAFと人のネットワーク」（8頁）
• 「11.1 基本的なコンテンツメタデータ」（7頁）
• 「12.4 タグと集合知」の一部（3頁）

例として記載しているHTMLやRDFのコードは、後日準備して公開します。

新刊『セマンティックHTML/XHTML』の案内がマイコミの書籍セクションで公開され、アマゾンでも予約が始まりました。奥付の発行日は5月30日で、書店に並ぶのもほぼその頃になる見込みです。

なんとも絶妙のタイミグで、HTML5に「マイクロデータ」という提案が登場して議論になっていますが、さすがにもう間に合わないので、これについては今後メモなどでフォローしていきます。もっとも、マーク付けの構文は本書の内容の一部分であって、基本的な考え方はHTML5でも同様に適用できるはずなんですが。

現在、最後の念校を行なっているところで、これが完了したらあとは下版して印刷所に送り、刷り上がりを待つばかり。当サイトの書籍情報ページは、近く公開する予定です。

さて、昨年夏から格闘していたセマンティック・マーク付けに関する本の原稿をようやく書き上げ、出版社に送りました。仮タイトルは『セマンティックHTML/XHTML』で、毎日コミュニケーションズから5月下旬に刊行予定です。5年ほど前から本の企画はありながら、なかなかまとめられずにいたのですが、昨年とあるプロジェクトが没になったのを機に、集中してこの本に取り組み、何とか脱稿にこぎつけました。

セマンティック・マーク付けとは、普通のウェブ文書の中に含まれるイベントや人物などの情報を、ソフトウェア・エージェントでも扱えるように明示することで、人間が読むための文書（文書のウェブ）を、同時にコンピュータにも処理できる情報（データのウェブ）にしようという試みです。何度か取り上げたGRDDLやマイクロフォーマットもその一種ですし、最近ではRDFaという仕様がW3C勧告になり、注目を集めています。この本は、そうしたマーク付けの方法を、背景から構文、具体的な語彙、利用ツールまで紹介しようというものです。

全体は3つのパート分かれており、最初に少々理論的な話とマーク付けのための構文説明、次に具体的な語彙を用いたさまざまな記述例、最後にデータの名前付けと共有、そして利用のツール紹介という構成です。

• Part 1. 名前と関係のモデル
  • 第1章 メタデータと名前
  • 第2章 ページ構成要素の役割と名前
  • 第3章 名前の拡張とマイクロフォーマット
  • 第4章 RDF：グローバルな名前とモデル
  • 第5章 GRDDL：メタデータ抽出の標準
  • 第6章 RDFa：文書にRDFを組み込む
• Part 2. さまざまな語彙による記述
  • 第7章 文書メタデータの記述
  • 第8章 人や組織に関する情報
  • 第9章 時間と場所の記述
  • 第10章 評価と信頼
  • 第11章 ユースケースと応用
• Part 3. リンクするデータ
  • 第12章 タグという名前付け
  • 第13章 グローバルなデータ名
  • 第14章 メタデータの抽出、確認と検索
• Appendix

やや馴染みのない分野も含まれているかも知れませんが、図版140点、例は400以上用意して、できるだけ分かりやすく説明したつもりです。ご期待ください。

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

タグの共有

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

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

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

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

これに対して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:topicsやdc:creatorなどのプロパティを与えている点。タグとオントロジーの「リソースとタグと作者」でも検討したように、これは、ブックマーク付与者が対象ページの作者であることを意味してしまう。さらに複数のRSSをマージしたときに、だれがどのタグを付与したか分からなくなってしまうという問題もある。単なるフィードとしては機能するのだが、これではRDFが生きてこない、というよりも誤った情報を提供してしまうのだ。これはFavikiに限った話ではなく、del.icio.us型RSSを提供するブックマークサービスに共通する問題。