ちょっとしたメモ

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属性をうまく使うことで、型付ノード要素の中の情報を、リテラルではなくリンク可能なデータとして表現できます。

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

SKOSでは、シソーラスや分類で扱う「術語」を、OWLのクラスではなく、概念リソース（Conceptual Resource）として扱う（skos:Conceptクラスのインスタンスになる）。概念リソース同士の関係は、上下関係ならskos:broader、skos:narrower、参考関係ならskos:relatedとして表現される（シソーラスのBT、NT、RTと同じ）。前者はOWLクラスのサブクラス関係と似ているが、クラス階層は属関係（継承の関係、is_a関係）しか扱えないのに対し、skos:broader、skos: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を使っていた人は、語彙の削除追加を含むかなり大きな変更が加えられているので、要注意。ちなみに名前空間はそのまま）

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.と宣言しているので、追加モジュールだけの定義というわけには行かないだろう。しかし全体をモジュール化して、article、aside、header、footer、navあたりを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を使えという反応が返ってきそうだけれど、何かもう少し賢い方法を取れないものか。

ウェブ上でRDFデータの照会を行うSPARQLが15日付でW3C勧告となった。仕様は、問い合わせ言語SPARQL Query Language for RDF、プロトコルSPARQL Protocol for RDF、クエリ結果のXMLフォーマットSPARQL Query Results XML Formatの3つ。バーナーズ＝リーのことばを借りれば、ようやくデータベースとしてのウェブのためのSQLが標準化されたわけで、分散する多様なデータへの一貫したアクセスが可能になる。

SPARQLはすでに多くの言語で実装されていて、JavaのJenaライブラリ、PerlのRDF::Query、PHPのARC、PythonのRDFLib、さらにいろんな言語から使えるRasqal RDF Query Libraryなどが揃っている（サポート具合は差があるので、実装状況調査を参照）。

SPARQLクエリをオンラインで試してみるなら、SPARQLer - An RDF Query Serverがほぼ全機能を備えている。クエリを簡単に書くために、JavaScriptによるSPARQL Editorも公開されている。単独のアプリケーションTwinkleは、実際に自分でSPARQLを利用してデータを処理するのにも使えるだろう。

SPARQLクエリ言語の詳しい説明は、また別途。

Dublin Core語彙の定義が、これまで検討されてきた内容を踏まえてかなり改訂され、新DCMI Metadata Termsとして勧告された。定義域、値域は別途Domains and Ranges for DCMI Propertiesという文書にもまとめられ、さらに改訂の概要を説明するRevisions to DCMI Metadata Termsも公開されている。

改訂概要では定義域、値域を「提案している」となっているが、語彙定義に含まれているので、正式なものと考えてよいのだろう。見やすいように「DCプロパティと定義域、値域一覧」としてまとめておく。

今回の改訂では、過去から引きずっていたいろんな経緯を振り切って、できるだけDCMI抽象モデルに忠実になるような整理が行われた。スキーム要素と呼ばれていたものが「語彙符号化スキーム」と「構文符号化スキーム」に分けて定義しなおされたり、プロパティの定義文も近年の議論を反映して書き直されている。

旧基本15要素（dc:名前空間）は同じ名前のプロパティとして拡張語彙（dcterms:名前空間）で改めて定義された。creatorはcontributorの、sourceはrelationのサブプロパティとされたのは興味深い。当分の間は旧15要素も互換性のために用いられるだろうが、今後はdcterms:が主流になっていくはず（少なくともDCMIの思惑としては）。