要約

この仕様は、RDFaコア1.1とRDFa Lite 1.1の仕様をHTML5とXHTML5に適合させて用いるための規則とガイドラインを定義しています。この仕様で定義している規則は、非XMLやXMLモードのHTML5ドキュメントのみでなく、HTML5の解析規則により解釈されるHTML4とXHTMLドキュメントにも適用されます。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。

これは、2013年8月22日に公開された勧告の編集改訂版です。変更点については別の項を参照してください。

この仕様は、HTML5言語の拡張です。この仕様で特に上書きしていない限り、HTML5仕様の規範的な内容はすべて、この仕様の基礎となることを意図しています。

この仕様では、rdf:HTMLデータ型を利用しています。この機能は、リテラル値の同等性がW3C勧告のステータスにまだ達していないDOM4[dom4]の仕様に依存しているため、非規範です。詳細については、関連するRDF 1.1仕様[rdf11-concepts]を参照してください。

テスト・ハーネスのサンプルがソフトウェア開発者に提供されています。この一連のテストは網羅的なものではありません。コミュニティが管理しているウェブ・サイトには、ウェブ・ドキュメントからRDFaデータを抽出して処理するために使用できる、さらなる読み物、開発者向けツール、およびソフトウェア・ライブラリに関する詳細情報が含まれています。

このドキュメントは、RDFaワーキンググループによって勧告として公開されました。このドキュメントに関してコメントを行いたい場合には、public-rdfa-wg@w3.org(購読、アーカイブ)にお送りください。どのようなコメントでも歓迎します。

ワーキンググループの実装報告書を参照してください。

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

このドキュメントは、2005年10月14日のW3Cプロセス・ドキュメントによって管理されています。

目次

1. はじめに

この項は非規範的です。

今日のウェブは、主に人間の読者向けに構築されています。機械可読データがウェブに浸透し始めても、それは一般的に、別のファイル、別の形式で配布され、人間と機械のバージョン間の対応は非常に限られている状況にあります。その結果、ウェブ・ページを解析し処理する際に、ウェブ・ブラウザは最小限にしか人間を支援できません。つまり、ブラウザでは表示用の情報しか見られません。RDFaは、HTMLドキュメントにおける機械可読データのマークアップに関する問題を解決することを目的としています。RDFaは、機械可読のヒントを用いて表示用データを補強するためのHTML属性を提供します。RDFaを用いることで、著者は人間が見ることのできる既存のテキストやリンクを、コンテンツを繰り返すことなく機械可読データに変換できます。

2. 適合性

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的ですこの仕様のその他の部分はすべて規範的です。

「することができる／してもよい(MAY)」、「しなければならない(MUST)」、「してはならない(MUST NOT)」、「推奨される(RECOMMENDED)」、「すべきである／する必要がある(SHOULD)」、「すべきでない／する必要がない(SHOULD NOT)」というキーワードは、[RFC2119]で記述されているように解釈されるべきです。

2.1 ドキュメントの適合性

RDFaのセマンティクスが含まれているHTMLドキュメントには、HTML+RDFaとHTML+RDFa Liteという2種類のドキュメント適合性基準があります。

RDFaのマークアップを含んでいるHTMLドキュメントには次の適合性基準が適用されます。

適合するHTML+RDFaドキュメントの例です。RDFaの部分を緑色で強調表示しています。

例1: HTML+RDFa 1.1ドキュメントの例
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Example Document</title>
  </head>
  <body vocab="http://schema.org/">
    <p typeof="Blog">
      Welcome to my <a property="url" href="http://example.org/">blog</a>.
    </p>
  </body>
</html>
適合するRDFaプロセッサによって次のデータが抽出されます。Turtle形式[turtle]で示しています。
例2: ドキュメントの例のTurtle出力
[] a <http://schema.org/Blog>;
   <http://schema.org/url> <http://example.org/> .

非XMLモードのHTML+RDFa 1.1ドキュメントは、HTML5仕様[html5]の12.1項で定義されているtext/htmlというインターネット・メディア・タイプでラベル付けを行うべきです(SHOULD)。

XMLモードのXHTML5+RDFa 1.1ドキュメントは、HTML5仕様[html5]の12.3項で定義されているapplication/xhtml+xmlというインターネット・メディア・タイプでラベル付けすべきで(SHOULD)、XHTML+RDFa 1.0またはXHTML+RDFa 1.1のDOCTYPE宣言を用いてはならず(MUST NOT)、@version属性を用いるべきではありません(SHOULD NOT)。

2.2 RDFaプロセッサの適合性

RDFaプロセッサの適合性基準を下記に示します。これらはすべて必須です。

2.3 ユーザ・エージェントの適合性

ユーザ・エージェントは、そのユーザ・エージェントがRDFaの属性とその値を格納または処理する場合にRDFaプロセッサの一種であるとみなされます。RDFaプロセッサの適合性の項とユーザ・エージェントの適合性の項が別々に存在している理由は、有効なHTML5 RDFaプロセッサではあるけれども、(例えば、ごくわずかな表示機能のサブセットしか提供しないなど)有効なHTML5ユーザ・エージェントではない場合がありえるためです。

ユーザ・エージェントの適合性基準を下記に示します。これらはすべて必須です。

3. RDFaコア1.1の拡張

RDFaコア1.1[rdfa-core]の仕様は、この仕様を構築する際の基礎となっているドキュメントです。RDFaコア1.1では、ウェブ・ドキュメントからのRDFの抽出に関し、5項: 属性と構文で属性と構文を、7項: 処理モデルで処理モデルを規定しています。この項では、HTMLドキュメントからのRDFの抽出をサポートするための、RDFaコア1.1で定義されている属性と処理モデルに対する変更点を規定します。

RDFaコアで規定されており、さらにこのドキュメントで拡張している要件と規則は、すべてのHTML5ドキュメントに適用されます。HTMLとXHTMLの両ドキュメントで(特にその結果として得られるDOMやinfosetで)動作するRDFaプロセッサは、これらの処理規則をHTML4、HTML5、XHTML5のシリアル化、DOM、および/またはinfosetに適用しなければなりません(MUST)。

3.1 追加のRDFa処理規則

この仕様の規則に適合するドキュメントは、[rdfa-core]に従い、次のような拡張を行って処理されます。

  1. デフォルトの語彙URIは未定義である。
  2. HTML+RDFaはデフォルトで追加の初期コンテキスト(http://www.w3.org/2011/rdfa-context/html-rdfa-1.1)を用いる。これは[rdfa-core](http://www.w3.org/2011/rdfa-context/rdfa-1.1)に対する初期コンテキストの後で適用されなければならない。
  3. 基底はbase要素で設定できる。XHTML5+RDFa 1.1ドキュメントの場合、基底は@xml:base属性でも設定できる。
  4. 現在の言語は、@lang属性または@xml:lang属性のいずれかで設定できる。@lang属性と@xml:lang属性が同じ要素で指定されている場合、@xml:lang属性が優先される。@langと@xml:langの両方が同じ要素で指定されている場合、それらの値は同じでなければならない(MUST)。現在の言語の設定に関する詳細は、3.3 リテラルの言語指定の項を参照。
  5. application/xhtml+xmlというメディア・タイプで提供されているドキュメントにどのRDFa処理規則を用いるかを判断する際には、適合するRDFaプロセッサは、ドキュメントのDOCTYPE宣言の値を調べなければならない(MUST)。DOCTYPE宣言が存在していれば、処理規則は次のとおり。
    • <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">というDOCTYPEの場合はXHTML1+RDFa 1.0、または、
    • <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">というDOCTYPEの場合はXHTML1+RDFa 1.1、または、
    • その他のすべてのDOCTYPEの値の場合はXHTML5+RDFa 1.1。
    application/xhtml+xmlとして提供され、DOCTYPE宣言を含まず、@version属性を指定していないドキュメントは、XHTML5+RDFa 1.1ドキュメントとして解釈しなければならない(MUST)。
  6. 7.5項: 順序の処理ステップ3では、プロセッサ・グラフ機能がサポートされていて、IRIマッピングによってIRIマッピングのローカルなリスト内の既存のマッピングが事前に異なる値で上書きされている場合、プロセッサは適切なrdfa:PrefixRedefinitionの警告を生成し、関連するトリプルをプロセッサ・グラフに置かなければならない(MUST)。
  7. 7.5項: 順序の処理ステップ4の直後では、@property属性と@relおよび/または@revの属性が同じ要素に存在していれば、CURIEではなくURIではない@relと@revの値は無視される。その後で、@relおよび/または@revの値が空になると、プロセッサはそれぞれの属性が存在していないかのように動作しなければならない(MUST)。
  8. 7.5項の処理ステップ5と処理ステップ6では、資源属性(例えば、@about、@href、@resource、または@src)でIRIが提供されていなければ、その要素がheadかbodyの要素なのかを最初にチェックして確認する。そうであった場合は、新しい主語を親の目的語に設定する。
  9. 7.5項: 順序の処理ステップ11では、@contentが同じ要素にも存在していなければ、現在のプロパティー値を生成する際に、HTML5の@datetime属性を用いなければならない(MUST)。そうでない場合、@datetimeが存在していれば、次のように現在のプロパティー値を生成しなければならない。リテラル値は、@datetime属性に含まれている値である。@datatypeが存在していれば、それはRDFaコア[rdfa-core]の処理規則で定義されているとおりに用いられる。そうでない場合、@datetimeの値が有効なxsd:date、xsd:time、xsd:dateTime、xsd:duration、xsd:gYear、またはxsd:gYearMonthと字句が一致すれば、データ型をその一致するxsdデータ型に設定して、型付きリテラルが生成されなければならない。そうでない場合、現在の言語を考慮してプレーン・リテラルが生成されなければならない(MUST)。実装者は、xsd:duration、xsd:dateTime、xsd:date、xsd:time、xsd:gYearMonth、xsd:gYearという順序の一致テストを用いてもよい。
  10. 7.5項: 順序の処理ステップ11では、要素がtimeであり、その要素に@datetimeまたは@contentの属性がなければ、プロセッサはその要素のテキストの値を正確に含んでいる@datetime属性が存在しているかのように動作しなければならない(MUST)。
  11. 7.5項: 順序のステップ11のサブステップ2の直後では、@datatype属性が存在していて、http://www.w3.org/1999/02/22-rdf-syntax-ns#HTMLと評価される場合、HTMLリテラルの値は、すべての子ノードをテキストにシリアル化することにより作成される文字列である。これは、要素自体を除く、現在の要素の子孫であるすべてのノードに適用される。HTMLリテラルには、 [rdf11-concepts]の5.2項:rdf:HTMLデータ型で定義されているhttp://www.w3.org/1999/02/22-rdf-syntax-ns#HTMLというデータ型が付与される。この機能は、リテラル値の同等性がW3C勧告のステータスにまだ達していないDOM4[dom4]の仕様に依存するため、非規範的である。詳細は、[rdf11-concepts]を参照。
  12. RDFaコア1.1仕様[rdfa-core]の7.5項: 順序で定義されている処理ステップおよびこの項のステップに従って出力グラフが生成されれば、プロパティー複製の実装で定義されている操作を実行する。

@version属性は、HTML5ではサポートされておらず、非適合です。しかし、HTML+RDFaドキュメントのhtml要素に@version属性が含まれていれば、適合するRDFaプロセッサはこの属性の値を調べなければなりません(MUST)。その値がRDFaの定義済みバージョンの値と一致する場合には、そのバージョンの処理規則を用いなければなりません(MUST)。値が定義済みバージョンと一致しない場合や@version属性がない場合は、RDFa 1.1の最新バージョンの処理規則を用いなければなりません(MUST)。

3.2 入力ドキュメントの変更

RDFaコア1.1仕様[rdfa-core]の7.5項: 順序で概説しているRDFaのツリー・ベースの処理規則により、処理前にホスト言語に承認されている方法で入力ドキュメントを自動的に訂正、クリーンアップ、再配置、または変更することができます。RDFa処理規則が動作する有効なツリー・ベースのモデルであるDOMに入力ドキュメントが変換される前に、HTMLドキュメントの入れ子の要素の課題を訂正すべきです(SHOULD)。

html5libライブラリなどの、HTML5やXHTML5のDOMと同等のデータ構造を生成するメカニズムは、RDFa処理規則に対する入力として提供されるツリー・ベースのモデルを構築するメカニズムとして使用できます(MAY)。

3.3 リテラルの言語指定

現在の言語は、RDFaコア1.1に従ってホスト言語で指定できます(MAY)。この仕様に準拠するためには、RDFaプロセッサは、[html5]仕様のlang属性およびxml:lang属性の項で記述されているメカニズムを用いてノードの言語を決定しなければなりません(MUST)。

HTMLフラグメントの最終的なカプセル化されたMIMEタイプが編集中に決定されなければ、著者は、両方の属性の値がまったく同じである@langと@xml:langを両方とも指定することをお勧めします(RECOMMENDED)。

注

HTML5仕様は、要素の言語を決定する際にContent-Language HTTPヘッダーを考慮に入れます。RDFaプロセッサの実装の中には、JavaScriptで書かれたものなど、このヘッダーにアクセスできないものがあり、その言語がContent-Language HTTPヘッダーでしか指定されていないような極端なケース(edge case)においては適合しないものがあります。このような場合、RDFaドキュメントの著者は、ドキュメントがすべてのRDFaプロセッサで正しく解釈されるように、html要素の@lang属性でドキュメントの言語を設定することが求められます。

3.4 無効なXMLLiteral値

XMLLiteral型のリテラルを生成する場合、プロセッサは、出力されるXMLLiteralが名前空間整形式XMLフラグメント(namespace well-formed XML fragment)であることを保証しなければなりません(MUST)。名前空間整形式XMLフラグメントには次のプロパティーがあります。

XMLフラグメントを変換するRDFaプロセッサは、HTML5仕様で指定されているとおり、HTML5仕様のXHTMLフラグメントのシリアル化の項で定義されているアルゴリズムに従って、HTML DOMからinfosetへの強制変換アルゴリズムを用いなければなりません(MUST)。変換中のある時点でエラーや例外が発生した場合は、XMLLiteralが含まれるトリプルを生成してはなりません(MUST NOT)。

XMLLiteralデータを利用するアプリケーションは、データが名前空間整形式XMLフラグメントであると予期するため、名前空間整形式XMLフラグメントへの変換が必要です。

変換要件は、値が空("")の@datatype属性が含まれているリテラルや、テキストのノードのみが含まれている入力データなど、テキストのみのプレーン・テキストの入力データには適用されません。

名前空間値の保持を示す変換の例を下記に示します。→という記号は、その行が前行の続きであることを示すため用いており、読みやすさのために含んでいるだけです。

例3: 名前空間保持のマークアップ
<p xmlns:ex="http://example.org/vocab#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 Two rectangles (the example markup for them are stored in a triple):
 <svg xmlns="http://www.w3.org/2000/svg"
      property="ex:markup" datatype="rdf:XMLLiteral">
 →<rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:1; stroke:rgb(0,0,0)"/>
 →<rect width="50" height="50" style="fill:rgb(255,0,0);stroke-width:2;stroke:rgb(0,0,0)"/></svg>
</p>

上記のマークアップは、次のトリプルを生成すべきで(SHOULD)、これは、rect要素に@xmlns属性を挿入することにより、xmlns宣言をマークアップ内に保持します。

例4: 名前空間保持のトリプル
<>
   <http://example.org/vocab#markup>
      """<rect xmlns="http://www.w3.org/2000/svg" width="300"
→height="100" style="fill:rgb(0,0,255);stroke-width:1; stroke:rgb(0,0,0)"/>
→<rect xmlns="http://www.w3.org/2000/svg" width="50"
→height="50" style="fill:rgb(255,0,0);stroke-width:2;
→stroke:rgb(0,0,0)"/>"""^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .

exとrdfの名前空間は、いずれのrect要素でも用いられていないため、XMLLiteralでは保持されません。

同様に、異なる名前空間に存在する複合的なドキュメントの要素は、その名前空間宣言を保持しなければなりません。

例5: 複合的なドキュメント要素の名前空間の保持
<p xmlns:ex="http://example.org/vocab#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:fb="http://www.facebook.com/2008/fbml">
 This is how you markup a user in FBML:
 <span property="ex:markup" datatype="rdf:XMLLiteral">
→<span><fb:user uid="12345">The User</fb:user></span>
→</span>
</p>

上記のマークアップは、次のトリプルを生成すべきで(SHOULD)、これは対応するトリプル内でfb名前空間を保持します。

例6: 名前空間要素を保持したトリプル
<>
   <http://example.org/vocab#markup>
      """<span xmlns:fb="http://www.facebook.com/2008/fbml">
→<fb:user uid="12345"></fb:user>
→</span>"""^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .

3.5 プロパティー複製

著者が、あるページの多くの資源に共通するプロパティーの集合があることに気づく場合があります。例えば、いくつかの音楽イベントは、演奏時間は異なるけれども、場所、バンド、チケット価格が同じである可能性があります。この特定のケースでは、データを表すすべてのマークアップを繰り返す必要なしに、場所、バンド、チケット価格の情報を含めるようにRDFaプロセッサに指示する省略表記法があると便利です。

HTML+RDFaは、資源に関連付けられているプロパティーを別の資源に複製できるプロパティー複製のメカニズムを定義しています。このメカニズムは、rdfa:copyという述語を用いて有効化できます。この機能を、次の2つの例で示します。

例7: プロパティーが重複するイベント
<div vocab="http://schema.org/">
  <p typeof="MusicEvent">
   <link property="image" href="Muse1.jpg"/>
   <link property="image" href="Muse2.jpg"/>
   <link property="image" href="Muse3.jpg"/>
   <span property="name">Muse</span> at the United Center.
   <time property="startDate" datetime="2013-03-03">March 3rd 2013</time>, 
   <a property="location" href="#united">United Center, Chicago, Illinois</a>
   ...
  </p>

  <p typeof="MusicEvent">
   <link property="image" href="Muse1.jpg"/>
   <link property="image" href="Muse2.jpg"/>
   <link property="image" href="Muse3.jpg"/>
   <span property="name">Muse</span> at the Target Center.
   <time property="startDate" datetime="2013-03-07">March 7th 2013</time>, 
   <a property="location" href="#target">Target Center, Minneapolis, Minnesota</a>
   ...
  </p>
</div>

この場合、2つの音楽イベントが、image、name、startDate、およびlocationのプロパティーで定義されています。imageとnameの値は、2つのイベントで同じであり、マークアップに不必要な重複があります。RDFaのプロパティー複製機能を用いると、共通プロパティーを表現するパターンを宣言できます。その後、このパターンは、ドキュメント内の他の資源に複製できます。

例8: 共通プロパティーの複製
<div vocab="http://schema.org/">
  <div resource="#muse" typeof="rdfa:Pattern">
    <link property="image" href="Muse1.jpg"/>
    <link property="image" href="Muse2.jpg"/>
    <link property="image" href="Muse3.jpg"/>
    <span property="name">Muse</span>
  </div>

  <p typeof="MusicEvent">
    <link property="rdfa:copy" href="#muse"/>
    Muse at the United Center.
    <time property="startDate" datetime="2013-03-03">March 3rd 2013</time>, 
    <a property="location" href="#united">United Center, Chicago, Illinois</a>
    ...
  </p>

  <p typeof="MusicEvent">
    <link property="rdfa:copy" href="#muse"/>
    Muse at the Target Center.
    <time property="startDate" datetime="2013-03-07">March 7th 2013</time>, 
    <a property="location" href="#target">Target Center, Minneapolis, Minnesota</a>
    ...
  </p>
</div>

この場合、すべてのイベントに対する共通プロパティーが最初のdivで表されています。共通プロパティーは、rdfa:copyという述語によって各イベント資源に複製されます。前の2つの例の出力は同じです。

例9: プロパティー複製のTurtle出力の例
@prefix schema: <http://schema.org/> .
@prefix xsd: http://www.w3.org/2001/XMLSchema#> .

[] a schema:MusicEvent;
   schema:image <Muse1.jpg>, <Muse2.jpg>, <Muse3.jpg>;
   schema:name "Muse";
   schema:startDate "2013-03-03"^^xsd:date;
   schema:location <#united> .

[] a schema:MusicEvent;
   schema:image <Muse1.jpg>, <Muse2.jpg>, <Muse3.jpg>;
   schema:name "Muse";
   schema:startDate "2013-03-07"^^xsd:date;
   schema:location <#target> .

複製のプロセスは繰り返しであるため、その資源は他の資源を複製する他の資源を複製する可能性があります。例えば、次のとおりです。

例10: 資源は、他の資源を複製する他の資源を複製しえる
<div vocab="http://schema.org/">
  <div typeof="Person">
    <link property="rdfa:copy" href="#lennon"/>
    <link property="rdfa:copy" href="#band"/>
  </div>
  <p resource="#lennon" typeof="rdfa:Pattern"> 
    Name: <span property="name">John Lennon</span>
  <p>
  <div resource="#band" typeof="rdfa:Pattern">
    <div property="band" typeof="MusicGroup">
      <link property="rdfa:copy" href="#beatles"/>
    </div>
  </div>
  <div resource="#beatles" typeof="rdfa:Pattern">
    <p>Band: <span property="name">The Beatles</span></p>
    <p>Size: <span property="size">4</span> players</p>
  </div>
</div>

上記の例では、#lennonと#bandのプロパティーが最初の資源へと複製されます。その後、#beatlesのプロパティーが#bandに複製されます。その結果、これらのプロパティーは最初の資源に再度複製され、次の出力が生成されます。

例11: ITurtleによる繰り返し複製の出力例
@prefix schema: <http://schema.org/> .

[ a schema:Person;
  schema:name "John Lennon" ;
  schema:band [
    a schema:MusicGroup;
    schema:name "The Beatles";
    schema:size "4"
  ]
] .

[rdfa-core]で定義されている語彙拡張と同様に、RDFaのプロパティー複製は、ドキュメント処理の完了後に出力グラフ上で動作します。

3.5.1 プロパティー複製の実装

出力グラフが、RDFaコア1.1仕様[rdfa-core]の7.5項: 順序で定義されている処理ステップと、この仕様で定義しているHTML5構文の拡張に従って生成されると、プロセッサは次の規則を用いて出力グラフを更新しなければなりません(MUST)。

  1. 出力グラフのrdfa:copyステートメントごとに、また、新しいトリプルが出力グラフに追加されなくなるまでプロパティー複製を行った結果として追加された新しいrdfa:copyステートメントごとに、次の規則を実行する。
    規則名 出力グラフに含まれていれば 追加
    pattern-copy ?subject rdfa:copy ?target
    ?target rdf:type rdfa:Pattern
    ?target ?predicate ?object    		 ?subject ?predicate ?object
  2. 最後に、利用したrdfa:copyステートメントとrdfa:Pattern資源を出力グラフから削除するためにこの規則を実行する。
    規則名 出力グラフに含まれていれば 削除
    pattern-clean ?subject rdfa:copy ?target
    ?target rdf:type rdfa:Pattern
    ?target ?predicate ?object    		 ?subject rdfa:copy ?target
    ?subject rdf:type rdfa:Pattern
    ?target ?predicate ?object
注

パターン複製規則をあまりに単純に実装すると、循環依存を処理する際に無限ループが発生する可能性があることに実装者は注意すべきです。固有のトリプルが生成されなければ、プロセッサはパターン複製規則を停止すべきです。

注

最終結果が同じである限り、別の規則を用いて出力グラフを更新することができます。

4. HTML5構文の拡張

RDFaを完全にサポートするために、HTML5構文の拡張として追加している属性がいくつかあります。

5. 下位互換性

RDFaコア1.1では、RDFa 1.1ドキュメントでの@xmlns:の使用を非推奨としています。ウェブ・ページの著者は、RDFa 1.1ドキュメントで@xmlns:を用いて接頭辞マッピングを表すべきではありません(SHOULD NOT)。ウェブ・ページの著者は、@prefix属性で接頭辞マッピングを指定すべきです(SHOULD)。

しかし、text/htmlのMIMEタイプを用いたXHTML+RDFa 1.0ドキュメントがウェブ・サーバーで提供されていることがあります。このような場合、HTML5仕様では、ドキュメントが非XMLモードのHTML5処理規則に従って処理されることを言明します。この特定のケースでは、RDFa 1.0ドキュメントとの下位互換性を保証するために、@xmlns:で宣言されている接頭辞をRDFaプロセッサ用に保持することが重要です。以下の項では、RDFaプロセッサ実装の下位互換性要件について詳しく説明します。

5.1 @xmlns:接頭辞付き属性

RDFaコア1.1[rdfa-core]仕様では、CURIE接頭辞マッピングを宣言するための@xmlns:のメカニズムの使用を非推奨としており、@prefix属性を選択しています。しかし、その使用が避けられない場合があります。例えば、レガシー・ドキュメントをHTML5として公開したり、@xmlns:属性に依存した古いXHTML+RDFa 1.0ドキュメントをサポートしたりする場合です。

先頭に@xmlns:が付いた属性を用いて指定されたCURIE接頭辞マッピングは、infosetベースのプロセッサの場合は4.4.1項: infosetからのURIマッピングの抽出で、またはDOMレベル2ベースのプロセッサの場合は4.5.1項: DOMからのURIマッピングの抽出で定義されているアルゴリズムを用いて処理しなければなりません(MUST)。@prefix属性を用いたCURIE接頭辞マッピングの場合、7.5項: 順序のステップ3を用いて名前空間値を処理しなければなりません(MUST)。

CURIEの接頭辞マッピングが@xmlns:で指定されていたため、また、HTMLの属性名は大文字と小文字を区別しないため、@xmlns:の属性-名前のパターンxmlns:<PREFIX>="<URI>"を用いて宣言されるCURIE接頭辞名は、小文字のみで指定すべきです(SHOULD)。例えば、「@xmlns:」というテキストと"<PREFIX>"内のテキストは小文字のみであるべきです(SHOULD)。これは、接頭辞マッピングが、HTML(大文字と小文字を区別しない属性名)とXHTML(大文字と小文字を区別する属性名)の文書型で同じように解釈されるようにするためです。

5.2 @xmlns:接頭辞付き属性の適合性基準

RDFa 1.0ドキュメントには、CURIE接頭辞を指定するために@xmlns:で始まる属性が含まれている可能性があるため、「@xmlns:」というテキストの文字列と大文字と小文字を区別せずに一致したもので始まる属性は、RDFaプロセッサに渡されるDOMやその他のツリー状のモデルで保持されなければなりません(MUST)。この仕様に適合するドキュメントの場合、「@xmlns:」と一致する大文字と小文字を区別しない接頭辞を持つ名前の属性は、適合しているとみなされなければなりません(MUST)。適合性チェッカーは、「@xmlns:」と一致する大文字と小文字を区別しない接頭辞を持つ属性名を適合しているものとして受け入れるべきです(SHOULD)。適合性チェッカーは、@xmlns:の使用が非推奨であることを知らせる警告を生成すべきです(SHOULD)。適合性チェッカーは、xmlns:の使用をエラーとして報告することができます(MAY)。

大文字と小文字を区別せずに「@xmlns:」と一致する接頭辞で始まるすべての属性は、XMLの名前空間[xml-names11]の3項: 名前空間の宣言で概説されている生成規則に準拠しなければなりません(MUST)。XMLの名前空間に適合しない@xmlns:の属性が含まれているドキュメントを適合しているものとして受け入れてはなりません(MUST NOT)。

5.3 強制による名前空間のinfosetへの保存

RDFa 1.0ドキュメントには、接頭辞マッピングを宣言するために@xmlns:のパターンが含まれている可能性があるため、非XMLモードのHTML5ドキュメントで宣言されている名前空間情報が正しくinfosetにマッピングされていることが重要です。このマッピングが確実に正しく実行されるようにするために、[html5]で定義されている「HTML DOMからinfosetへの強制変換」の規則を拡張した、次の規則を含めなければなりません。

XML APIが名前空間に対応している場合、ツールは、非XMLモードのDOMをinfosetに変換する際に、([namespace name](名前空間名)、[local name](ローカル名)、[normalized value](正規化済みの値)の)名前空間タプルが作成されていることを確認しなければなりません。xmlns:foo="http://example.org/bar#"という標準的な@xmlns:の定義の場合、[namespace name]はhttp://www.w3.org/2000/xmlns/、[local name]はfoo、[normalized value]はhttp://example.org/bar#であるため、名前空間タプルは(http://www.w3.org/2000/xmlns/, foo, http://example.org/bar#)になるでしょう。

例えば、次のテキストが入力されているとします。

例12
<div xmlns:com="https://w3id.org/commerce#">

HTML DOMからinfosetに強制変換すると、上記のdiv要素には、「http://www.w3.org/2000/xmlns/」に設定された[namespace name]、comに設定された[local name]、および「https://w3id.org/commerce#」の[normalized value]が含まれている[namespace attributes](名前空間属性)のリストに属性が含まれるはずです。

5.4 infosetベースのプロセッサ

このRDFa処理命令の目的は、言語とツールチェーンができる限り独立している規則の集合を提供することですが、明確にするために、XML情報セット上で動作するプロセッサからRDFaコンテンツを抽出する詳細な方法を以下に示します。

5.4.1 infosetからのURIマッピングの抽出

動作中のinfosetベースのRDFaプロセッサ内からの、@xmlns:で宣言されているURIマッピングの抽出は、次のアルゴリズムで行うことができます。

[rdfa-core]の7.5項: 順序のステップ#2で記述されているとおりに要素を処理している間に、

  1. [prefix](接頭辞)の値が含まれている[namespace attributes]リスト内の属性ごとに、マッピングされる値として[prefix]を、マッピングする値としてnormalized value]を格納することにより[IRI mapping](IRIマッピング)を作成する。
  2. 値のない[prefix]と@xmlns:で始まる[local name]が含まれている[attributes]リスト内の属性ごとに、@xmlns:の文字を削除してマッピングされる値として[local name]部分を、マッピングする値として[normalized value]を格納することにより[IRI mapping]を作成する。
    注

    infosetの強制規則が非XMLモードで指定された名前空間を保持していれば、このステップは不要です。

例えば、次のマークアップがinfosetベースのRDFaプロセッサによって処理されたとします。

例13
<div xmlns:ps="https://w3id.org/payswarm#" ...

マークアップの処理後に、psからhttps://w3id.org/payswarm#へのマッピングを含む[local list of URI mappings](URLマッピングのローカルなリスト)に[URI mapping](URIマッピング)が存在しているはずです。

5.4.2 RDFa属性の処理

HTML5のRDFa処理に関連する接頭辞のない属性がいくつかあります。XML情報セット・ベースのRDFaプロセッサでこれらの属性を処理する場合は、次のアルゴリズムで属性の値を検出し抽出すべきです。

[rdfa-core]の7.5項: 順序のステップ＃4からステップ＃9で記述されているとおりに要素情報項目のinfoset属性情報項目を処理している間に、

  1. 値のない[prefix]が含まれているinfoset[attributes]リスト内のRDFaに特化した属性情報項目ごとに、[normalized value]を抽出して用いる。

5.5 DOMレベル1およびレベル2ベースのプロセッサ

DOMに対応しているRDFaプロセッサのほとんどは、DOMレベル1[dom-level-1]メソッドにアクセスして要素の属性を処理できます。@xmlns:を指定したCURIE接頭辞マッピングをすべて発見するために、Node.attributes NamedNodeMapを繰り返すことができます。@xmlns:というテキストの文字列で始まる各Attr.nameは、CURIE接頭辞マッピングを指定します。マッピングされる値はAttr.name変数の@xmlns:部分文字列の後の文字列で、マッピングされる値はAttr.value変数の値です。

RDFa処理命令の目的は、言語とツールチェーンができる限り独立している規則の集合を提供することです。開発者が前の段落で概説したDOM1の環境メカニズムを用いないことを選択した場合には、次のDOM2[dom-level-2-core]の環境メカニズムを使用できます。

5.5.1 DOMレベル2によるURIマッピングの抽出

動作中のDOMレベル2ベースのRDFaプロセッサ内からの、@xmlns:で宣言されているURIマッピングの抽出は、次のアルゴリズムで行うことができます。

[rdfa-core]の7.5項: 順序のステップ＃2で記述されているとおりに各DOM2[Element]を処理している間に、

  1. @xmlnsという[namespace prefix]の値が含まれている[Node.attributes]リスト内の[Attr]ごとに、マッピングされる値として[local name]を、マッピングする値として[Node.nodeValue]を格納することにより[IRI mapping]を作成する。
  2. ヌル(null)である[namespace prefix]の値と@xmlns:で始まる[local name]が含まれている[Node.attributes]のリストの[Attr]ごとに、@xmlns:の文字を削除してマッピングされる値として[local name]部分を、マッピングする値として[Node.nodeValue]を格納することにより[IRI mapping]を作成する。
    注

    XMLと非XMLモードのDOMの名前空間に整合性があれば、このステップは不要です。

例えば、次のマークアップがDOM2ベースのRDFaプロセッサで処理されたとします。

例14
<div xmlns:com="https://w3id.org/commerce#" ...

マークアップの処理後に、comからhttps://w3id.org/commerce#へのマッピングを含む[local list of URI mappings]に[URI mapping]が存在しているはずです。

5.5.2 RDFa属性の処理

HTML5のRDFa処理に関連する接頭辞のない属性がいくつかあります。DOM2ベースのRDFaプロセッサでこれらの属性を処理する場合は、次のアルゴリズムで属性の値を検出し抽出すべきです。

[rdfa-core]の5.5項: 順序のステップ＃3からステップ＃9で記述されているとおりに要素を処理している間に、

  1. ヌルである[namespace prefix]が含まれている[Node.attributes]リスト内のRDFa属性ごとに、[Node.nodeValue]を値として抽出して用いる。
注

@hrefと@srcから値を抽出する場合、ウェブの著者と開発者は、DOMではないプロセッサによる場合と比べて、DOMプロセッサによりアクセスする場合は、特定の値が変換される可能性がある(MAY)ことに注意すべきです。URL値の変更の規則は、主要なHTML5仕様の2.5項: URLに記載されています。

A. このドキュメントについて

A.1 履歴

この項は非規範的です。

2004年の初めに、Mark BirbeckがXHTML2ワーキンググループを通じて「RDF in XHTML」と題したドキュメントを公開し、最終的にRDFa(AttributesのResource Description Framework)となる基礎を築きました。

2006年に、セマンティック・ウェブ展開ワーキンググループの協賛を得て、XHTMLでセマンティック・データを表現するための技術に関する取り組みを正式に発動しました。この技術は、開発に成功してW3Cで合意に達し、後に公式のW3C勧告として公開されました。HTMLはドキュメントの構造(タイトル、段落、リンク)を表現するメカニズムを提供しますが、RDFaはドキュメントの意味(人、場所、イベント)を表現するメカニズムを提供します。

「XHTMLにおけるRDF: 構文と処理」[xhtml-rdfa]と題したドキュメントは、属性を処理するための一連の属性と規則を定義し、その結果、機械可読セマンティック・データの出力が得られるようになりました。このドキュメントはXHTMLに適用されましたが、属性と規則は、ツリー・ノードに属性を含んだ(HTML4、SVG、ODFなど)ツリー・ベース構造全体で動作することを常に目的としていました。

RDFaは当初、XHTMLでの使用に向けて既定されましたが、ウェブ上の多数の大規模機関による採用により、XHTML以外の言語でのRDFaの使用が促進されました。しかし、これらの言語の公式な仕様が開発される前にHTML4で用いることで、ドキュメントの適合性に懸念が生じました。

RDFaコミュニティのメンバーは、長年にわたり、XHTML+RDFa仕様で概説されているものと同じ属性と処理規則をすべてのHTMLファミリー・ドキュメントに適用する可能性について議論しました。設計上、すべてのHTMLドキュメントとXHTMLファミリー・ドキュメントとの統合的なセマンティック・データ表現メカニズムの可能性は、率直に言って、有り得る状況でした。

RDFaの多言語実装に関する課題に対処するために、2010年にRDFaワーキンググループが作成されました。XHTML+RDFaドキュメントは、RDFaコア1.1[rdfa-core]と呼ばれる基本仕様と、RDFaコア1.1の上位に位置する複数の薄い仕様に分割されました。XHTML+RDFa 1.1仕様[xhtml-rdfa]は、そのような薄い仕様の一例です。このドキュメントも薄い仕様であり、HTML4、HTML5、XHTML5を対象としています。

このドキュメントは、RDFaをすべてのHTMLファミリー・ドキュメントで使用できるようにするRDFaコア1.1仕様の拡張について記述しています。RDFaコア1.1仕様に記述されている属性と処理規則を用い、このドキュメントの軽微な変更点に注意を払うことにより、著者はHTML4、HTML5、XHTML5と同じセマンティック・データ出力を生成するマークアップを生成することができます。

A.2 最終公開勧告以後の変更履歴

この項は非規範的です。

2014年12月16日: [html5]の勧告としての公開により、@datetimeの使用が規範的になった。対応する処理ステップの注記が削除された。

2014年12月16日: [rdf11-concepts]の勧告としての公開により、rdf:HTMLの使用は非規範的のままとなった。対応する処理ステップにおける可能な規範的ステータスに関する注記が削除された。[dom4]に対する依存に言及しつつ、データ型の使用に明確化の注記を追加した。

2014年12月16日: @datetimeとrdf:HTMLの非規範的な性質に関するステータスの項の注記を削除したが、rdf:HTMLの非規範的な性質に関する段落と明確化を追加した。

2014年12月16日: [html5]と[rdf11-concepts]に加え、その他のRDFaドキュメントへの参照を最新の(PER)バージョンに更新した。

2014年12月16日: 参考文献のスタイルを最新のrespecスタイルに更新した。

A.3 謝辞

この項は非規範的です。

公開時点のRDFaワーキンググループのメンバーは次のとおりです。

Ivan Herman (staff contact)、Shane McCarron、Gregg Kellogg、Niklas Lindstrom、Steven Pemberton、Manu Sporny (chair)、Ted Thibodeau、およびStephane Corlosquet。

仕様に関するフィードバックをいただいた皆様に大変感謝しています(そのほとんどは以下に記載しています)。

Adam Powell、Alex Milowski、Andy Seaborne、Arto Bendiken、Austin William、BAI Xi、Benjamin Adrian、Benjamin Nowack、Bjoern Hoehrmann、Christian Langanke、Christoph Lange、Cindy Lewis、Corey Mwamba、Crisfer Inmobiliaria、Dan Brickley、Daniel Friesen、Dave Beckett、David Wood、D. Grant、Dominik Tomaszuk、Dominique Hazael-Massieux、Doug Schepers、Dr. Olaf、Theresa O'Connor、Faye Harris、Felix Sasaki、Gavin Carothers、Grant Robertson、Guus Schreiber、Harry Halpin、Michael Hausenblas、Henri Bergius、Henri Sivonen、Henry Story、Holger Knublauch、Ian Hickson、Irene Celino、Alexander Kroener、Knud Moller、Philip Jagenstedt、Reto Bachmann-Gmur、Ivan Mikhailov、James Leigh、Jeff Sonstein、Jeni Tennison、Jens Haupert、Jochen Rau、John Breslin、John Cowan、John O'Donovan、Jonathan Rees、Julian Reschke、KANZAKI Masahide、Kingsley Idehen、Knud Hinnerk、Landong Zuo、Leif Halvard Silli、Liam R.、Lin Clark、Maciej Stachowiak、Mark Nottingham、Markus Gylling、Martin Hepp、Martin McEvoy、Matthias Tylkowski、Darin McBeath、Melvin Carvalho、Michael Chan、Michael Hausenblas、Michael Steidl、Michael? Smith、Mischa Tuffield、Misha Wolf、Nathan Rixham、Nathan Yergler、Nicholas Stimpson、Noah Mendelsohn、Paul Cotton、Paul Sparrow、Pete Cordell、Peter Frederick、Peter Mika、Peter Occil、Phil Archer、Reece Dunn、Richard Cyganiak、Robert Leif、Robert Weir、Ramanathan V. Guha、Sami Korhonen、Sam Ruby、Sandro Hawke、Sebastian Germesin、Sebastian Heath、Shelley Powers、Simon Grant、Simon Reinhardt、Stefan Schumacher、Tab Atkins Jr.、Thomas Adamich、Thomas Baker、Thomas Roessler、Thomas Steiner、Tim Berners-Lee、Toby Inkster、Tom Adamich、Tantek Celik、Ville Skytta、Wayne Smith、およびWill Clark。

B. 参考文献

B.1 規範的な参考文献

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[dom-level-1]
Scott Isaacson; Steven B Byrne; Mike Champion; Ian Jacobs; Arnaud Le Hors; Gavin Nicol; Jonathan Robie; Robert S Sutor; Chris Wilson; Lauren Wood et al. Document Object Model (DOM) Level 1. 29 September 2000. W3C Working Draft. URL: http://www.w3.org/TR/DOM-Level-1/
[dom-level-2-core]
Arnaud Le Hors; Philippe Le Hegaret; Lauren Wood; Gavin Nicol; Jonathan Robie; Mike Champion; Steven B Byrne et al. Document Object Model (DOM) Level 2 Core Specification. 13 November 2000. W3C Recommendation. URL: http://www.w3.org/TR/DOM-Level-2-Core/
[html5]
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. HTML5. 28 October 2014. W3C Recommendation. URL: http://www.w3.org/TR/html5/
[rdfa-core]
Ben Adida; Mark Birbeck; Shane McCarron; Ivan Herman et al. RDFa Core 1.1 - Third Edition: Syntax and processing rules for embedding RDF through attributes. 17 March 2015. W3C Recommendation. URL: http://www.w3.org/TR/rdfa-core/
[rdfa-lite]
Manu Sporny. RDFa Lite 1.1 - Second Edition. 17 March 2015. W3C Recommendation. URL: http://www.w3.org/TR/rdfa-lite/
[xml-names11]
Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin et al. Namespaces in XML 1.1 (Second Edition). 16 August 2006. W3C Recommendation. URL: http://www.w3.org/TR/xml-names11/

B.2 参考情報の参考文献

[dom4]
Anne van Kesteren; Aryeh Gregor; Ms2ger; Alex Russell; Robin Berjon. W3C DOM4. 10 July 2014. W3C Last Call Working Draft. URL: http://www.w3.org/TR/dom/
[rdf11-concepts]
Richard Cyganiak; David Wood; Markus Lanthaler. RDF 1.1 Concepts and Abstract Syntax. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/rdf11-concepts/
[turtle]
Eric Prud'hommeaux; Gavin Carothers. RDF 1.1 Turtle. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/turtle/
[xhtml-rdfa]
Shane McCarron. XHTML+RDFa 1.1 - Third Edition. 17 March 2015. W3C Recommendation. URL: http://www.w3.org/TR/xhtml-rdfa/