4.1 RDFaプロセッサの適合性

この仕様では、出力グラフという用語を、処理モデルの項に従ってドキュメントが言明するすべてのトリプルを意味するために用います。適合するRDFaプロセッサは、処理モデルの項の規則を用いて生成されたすべての可能なトリプルを含む一つのRDFグラフを、それを利用するアプリケーションに提供しなければなりません(MUST)。プロセッサ・グラフという用語は、RDFaプロセッサがそのステータスを報告するために生成しえる(MAY)すべての参考情報、警告、エラーのトリプルのコレクションを示すために用いられます。出力グラフとプロセッサ・グラフは別々のグラフであり、RDFaプロセッサによって同じグラフに格納されてはなりません(MUST NOT)。しかし、プロセッサは、2つのグラフが一緒に取得されることを許すことができます。詳細は7.6.1項を参照してください。

適合するRDFaプロセッサは、ここで記載していない規則を用いて生成された追加のトリプルを提供できますが(MAY)、そのトリプルを出力グラフで提供してはなりません(MUST NOT)。(この追加のトリプルが1つ以上の追加のRDFグラフで提供されるかどうかは、実装固有であるため、ここでは定義していません。)

適合するRDFaプロセッサは、プレーン・リテラルとXMLリテラルの両方で空白を保持しなければなりません(MUST)。しかし、プロセッサが動作するアーキテクチャが、ドキュメントがRDFaプロセッサに到達する前にドキュメント内の空白を変更したというケースもありえます(例えば、[XMLSCHEMA11-1]プロセッサは属性値の空白を「正規化する」ことが許されています - 3.1.4項を参照してください)。処理環境間の整合性が最大限に確保されるように、著者はプレーン・テキストやXMLリテラル内の不要な空白を削除すべきです(SHOULD)。

適合するRDFaプロセッサは、ドキュメントのホスト言語を決定するために、処理中のドキュメントのメディア・タイプを検証しなければなりません(MUST)。RDFaプロセッサがメディア・タイプを決定できない場合や、そのメディア・タイプをサポートしていない場合は、RDFaプロセッサは、そのドキュメントを、application/xmlというメディア・タイプであるかのように処理しなければなりません(MUST)。XML+RDFaドキュメントの適合性を参照してください。ホスト言語は、追加の通知メカニズムを指定できます(MAY)。

4.2 RDFaホスト言語の適合性

RDFaを組み込んだホスト言語は、下記に準拠しなければなりません。

• この仕様で要求されるすべての機能がホスト言語に含まれていなければならない(MUST)。
• この仕様で定義されている必須属性がホスト言語のコンテンツ・モデルに含まれていなければならない(MUST)。
  注

  疑義を避けるために、@hrefや@srcなどの属性を、適合するホスト言語で用るという要件はありません。すべての必須属性がすべての要素のコンテンツ・モデルに組み込まれているという要件もありません。ワーキンググループは、ホスト言語の設計者が、ホスト言語のコンテンツ・モデル全体で一般的に用いられている要素のコンテンツ・モデルに必須属性が確実に組み込まれているようにすることを推奨しています。

• ホスト言語がXML名前空間[XML-NAMES]を用いる場合、この仕様の属性は「名前空間なし」で定義される(例えば、ホスト言語の名前空間内の要素で属性を用いる場合、修飾接頭辞: <myml:myElement property="license">なしに使用できる)べきである(SHOULD)。ホスト言語が属性を「名前空間なし」で用いない場合、XHTML名前空間(http://www.w3.org/1999/xhtml)を介して属性を参照しなければならない(MUST)。
• ホスト言語がこの仕様で定義されている属性に対して独自の定義を持っている場合、その定義は、この仕様の要件と整合性がある方法で属性が用いられる場合に、この仕様で要求される処理を継続できるようなものでなければならない(MUST)。
• ホスト言語は、初期コンテキスト(例えば、IRIマッピングおよび/または用語の定義またはデフォルトの語彙IRI)を指定できる(MAY)。そのような初期コンテキストは、RDFa初期コンテキストで定義されている規定を用いて定義されるべきである(SHOULD)。

4.3 XML+RDFaドキュメントの適合性

この仕様では、単独の文書型は定義していません。ここの属性は、他のホスト言語(例えば、HTML+RDFaやXHTML+RDFa)に統合されることを意図しています。ただし、この仕様では、汎用的なXMLドキュメント - つまり、text/xmlまたはapplication/xmlのメディア・タイプとして配信されるドキュメント - の処理規則を定義しています。そのようなドキュメントは、次のすべての基準を満たさなければなりません。

1. ドキュメントは、[XML10-4e]で定義されている整形式でなければならない(MUST)。
2. ドキュメントでは、この仕様で定義されている属性を「名前空間なし」で用いる(例えば、要素で属性を用いる場合、修飾接頭辞: <myml:myElement property="license">なしに用いる)べきである(SHOULD)。
   注

   XML文法は、この仕様の属性と衝突するネイティブな属性を持つことができます。その結果、RDFaプロセッサにより、予期しないトリプルが生成される可能性があります。

RDFaプロセッサがXML+RDFaドキュメントを処理する場合は、次の初期コンテキストを用いてそれを行います。

1. デフォルトの用語(例えば、describedby、license、role)があり、http://www.w3.org/2011/rdfa-context/rdfa-1.1で定義されている。
2. デフォルトの接頭辞マッピング(例えば、dc)があり、http://www.w3.org/2011/rdfa-context/rdfa-1.1で定義されている。
3. デフォルトの語彙IRIがない。
4. 基底は、[XML10-4e]で定義されている@xml:base属性を用いて設定できる。
5. 現在の言語は、@xml:lang属性を用いて設定できる。

5.1 属性の役割

RDFa属性は、セマンティックがリッチなドキュメントでは異なる役割を果たします。その役割とは、簡単に言えば次のとおりです。

• 構文属性: @prefix、@vocab
• 主語属性: @about
• 述語属性: @property、@rel、@rev
• 資源属性: @resource、@href、@src
• リテラル属性: @datatype、@content、@xml:langまたは@lang
• マクロ属性: @typeof、@inlist

5.2 属性値内の空白

多くの属性は、空白区切りのトークンのリストを受け入れます。この仕様では、空白を次のように定義しています。

whitespace      ::=  (#x20 | #x9 | #xD | #xA)+ 

属性が空白区切りのトークンのリストを受け入れる場合、RDFaプロセッサは先頭または末尾の空白を無視しなければなりません(MUST)。

7.1 概要

RDFaトリプルのドキュメントの評価は、ドキュメントの目的語から始まり、次に、ドキュメント順に個々の子要素を訪問し、処理規則を適用することで実行します。処理は、子要素ごとに、プロセッサがその子要素をそれぞれ訪問し、同じ処理規則を適用するという点で再帰的です。

処理が続行されると、トリプルを生成する規則が適用され、その後に子孫要素を処理するときに用いられる評価コンテキストの情報も変わる可能性があります。

7.2 評価のコンテキスト

処理中に、評価のコンテキストによって提供される情報を用いて各規則が適用されます。初期コンテキストは、処理の開始時に作成されます。そのコンテキストには次のメンバーが含まれています。

• 基底(base)。これは通常、処理中のドキュメントのIRIだが、(X)HTMLのbase要素などの他のメカニズムによって設定された他のIRIでもかまわない。重要なのは、それが相対パスを解決できるIRIを確立するという点である。
• 親の主語(parent subject)。初期値は基底の初期値と同じですが、通常は処理の過程で変更される。
• 親の目的語(parent object)。状況によっては、ステートメントの目的語が入れ子のステートメントの主語になり、このメンバーが、この値を伝えるために用いられる。この値は、状況によっては多くの入れ子のステートメントが1つのbノードにまとめられるため、bノードでありえることに注意。これは、bノードが、包含しているステートメントで設定され、下に受け渡されなければならないことを意味する。
• 現在の、対象とするIRIマッピング(IRI mappings)のリスト。
• 不完全なトリプル(incomplete triples)のリスト。トリプルは、資源を必要とする述語(すなわち、@relまたは@rev)とともに目的語資源が提供されていない場合、不完全になりえる。トリプルは、資源が利用可能となったときに完全になりえ、その時に、次の主語が指定されるだろう(連鎖と呼ばれるプロセスの一部)。
• IRIをリストに関連付けるリスト・マッピング(list mapping)。
• 言語(language)。デフォルトの言語はないことに注意。
• 用語マッピング(term mappings)。用語リストとその関連するIRI。この仕様では初期リストは定義していない。ホスト言語は、初期リストを定義できる(MAY)。
• デフォルトの語彙(default vocabulary)。RDFaプロセッサにとって未知の用語が用いられている場合に接頭辞IRIとして用いる値。この仕様では、デフォルトの語彙に対する初期設定を定義していない。ホスト言語は初期設定を定義できる(MAY)。

処理の過程で、各子要素に渡される新しい評価のコンテキストが作成されます。下記で記述している最初の規則は、そのコンテキストにおける項目の値を決定します。次に、このコアな規則により、要素によって提供される情報と、評価のコンテキストの情報を組み合わせて新しいトリプルが作成されます。

処理の過程で、次のような、多くのローカルな範囲の値が必要になります。

• IRIマッピングのローカルなリスト(local list of IRI mappings)と呼ばれる、最初は空のIRIマッピングのリスト。
• 不完全なトリプルのローカルなリスト(local list of incomplete triples)と呼ばれる、最初は空の不完全なトリプルのリスト(list of incomplete triples)。
• 最初は空の言語の値。
• スキップ要素(skip element)フラグ。関連するRDFa属性がないため、現在の要素を安全に無視できるかどうかを示す。子孫要素は引き続き処理されることに注意。
• 新しい主語(new subject)の値。次の項で説明しているとおり、これは計算されると、評価のコンテキスト内に親の主語を設定し、不完全なトリプルを完全にするために用いられる。
• 現在のプロパティー値(current property value)に対する値。リテラルの目的語を持つトリプルを作成するときに用いるリテラル、または、@relまたは@revがない場合のIRI。
• 現在の目的語資源(current object resource)に対する値。資源の目的語を持つトリプルを作成するときに用いる資源。
• 型付き資源(typed resource)に対する値。@typeofで指定されている型に対するrdf:typeの関係を作成するための資源。
• ローカルな用語マッピング(local term mappings)。用語のリストとその関連するIRI。
• ローカルなリスト・マッピング(local list mapping)。IRIをリストにマッピングする。
• ローカルなデフォルトの語彙(local default vocabulary)。用語が用いられているときに接頭辞マッピングとして用いるIRI。

7.3 連鎖

ステートメント連鎖は、著者が、不要なマークアップの反復を避けながら、RDFステートメントどうしをリンクさせることができるRDFaの機能です。例えば、著者が、資源であった目的語の子としてステートメントを追加する場合、これらのステートメントはその資源に関するものと解釈されるべきです。

<div about="http://dbpedia.org/resource/Albert_Einstein">
  <span property="foaf:name">Albert Einstein</span>
  <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
  <div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire">
    <span property="dbp:conventionalLongName">the German Empire</span>
  </div>
</div>

この例では、目的語資源(「German_Empire」)が、入れ子のステートメントの主語になっていることがわかります。このマークアップは、「AはCを持つBを持つ」という基本的な連鎖パターンも示しています(つまり、Einsteinはドイツ帝国という出生地を持ち、それは「the German Empire」という長い名前を持っている)。

入れ子のステートメントの主語は、含んでいるステートメントに目的語を提供することもできます — 実質的に、先ほど見た例の逆です。説明のために、今述べた種類の連鎖の例を取り上げ、より効率的にマークアップする方法を示します。まず、Albert Einsteinは、彼の人生のある時点において、ドイツ帝国とスイスの両方に住居を持っていたという事実をマークアップします。

<div about="http://dbpedia.org/resource/Albert_Einstein">
  <div rel="dbp-owl:residence" resource="http://dbpedia.org/resource/German_Empire"></div>
  <div rel="dbp-owl:residence" resource="http://dbpedia.org/resource/Switzerland"></div>
</div>

ここで、同じ情報を示しますが、今度は住居の部分から不完全なトリプルを作成し、その後に、トリプルを「完全にする」するために、さらに任意の数の主語を用います。

<div about="http://dbpedia.org/resource/Albert_Einstein" rel="dbp-owl:residence">
  <span about="http://dbpedia.org/resource/German_Empire"></span>
  <span about="http://dbpedia.org/resource/Switzerland"></span>
</div>

この例では、不完全なトリプルは、実際に2回完全になり(1度はドイツ帝国に関して、1度はスイスに関して)、これは先の例とまったく同じ情報を示します。

<http://dbpedia.org/resource/Albert_Einstein>
  dbp-owl:residence <http://dbpedia.org/resource/German_Empire> .
<http://dbpedia.org/resource/Albert_Einstein>
  dbp-owl:residence <http://dbpedia.org/resource/Switzerland> .

連鎖には、比較的小さなマークアップが含まれている要素が伴うことがありえます(例えば、1つの資源のみ、または1つの述語のみ示しているものなど)。ここでは、Einsteinの写真を掲載するためにimg要素を用いています。

<div about="http://dbpedia.org/resource/Albert_Einstein">
  <div rel="foaf:depiction">
    <img src="http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg" />
  </div>
</div>

このような小さなマークアップが用いられると、資源に関連する属性のいずれかが、連鎖において主語または目的語として機能する可能性があります。

<div about="http://dbpedia.org/resource/Albert_Einstein">
  <div rel="dbp-owl:residence">
    <span about="http://dbpedia.org/resource/German_Empire"></span>
    <span about="http://dbpedia.org/resource/Switzerland"></span>
  </div>
</div>

上記のように、@propertyと@relは交換可能である場合が多いことに注意してください。これは連鎖には当てはまりません。最初の例で考えてみると、その例を次のように用いた場合、

<div about="http://dbpedia.org/resource/Albert_Einstein">
  <span property="foaf:name">Albert Einstein</span>
  <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
  <div property="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire">
    <span property="dbp:conventionalLongName">the German Empire</span>
  </div>
</div>

「the German Empire」の主語は、Albert Einsteinのままとなるでしょう(そして、それはもちろん間違いでしょう)。これが@propertyと@relの主な違いで、後者は連鎖を導きますが、前者は通常は導きません。

7.4 CURIEとIRIの処理

RDFaは究極的にはRDFを転送する手段であるため、重要な概念は資源と、IRIとしてのその明示(manifestation)です。RDFは完全なIRI(相対パスではない)を処理します。RDFaをトリプルに変換する場合、任意の相対IRIは、RFC 3987[RFC3987]の6.5項、リファレンス解決で定義されているアルゴリズムを用いて、基底IRIに応じて解決されなければなりません(MUST)。IRIを参照するRDFa属性の値は、IRI、SafeCURIEorCURIEorIRI、またはTERMorCURIEorAbsIRIという3つの異なるデータ型を用います。これらの属性はすべて、処理後にIRIにマッピングされます。これらの属性の処理は次のとおりです。

IRI

コンテンツはIRIであり、そのまま用いられる。

SafeCURIEorCURIEorIRI

• 値が角括弧で囲まれていれば、角括弧内のコンテンツは、CURIE構文定義に従ってCURIEとして評価される。有効なCURIEでない場合は、値を無視しなれけばならない(MUST)。
• そうでない場合、値はCURIEとして評価される。それが有効なCURIEであれば、その結果のIRIが用いられる。そうでない場合、値はIRIとして処理される。

注

この結果、このデータ型の属性の値が空の文字列(例えば、@about="")であれば、その値がIRIに解決されることになります。""というIRIは、基底と同じであると解釈される相対IRIです。言い換えれば、 ""の値は通常、現在のドキュメントのIRIに解決されます。

注

これに関連する結果は、このデータ型の属性の値が空のSafeCURIE(例えば、@about="[]")であれば、その値はIRIにならず、したがって、その値は無視されることになります。

TERMorCURIEorAbsIRI

• 値が用語であれば、それは属性における用語の一般的な使用に従って用語として評価される。このステップは、値が無視されることを意味することに注意。
• 値が有効なCURIEであれば、その結果のIRIが用いられる。
• 値が絶対IRIであれば、その値が用いられる。
• そうでない場合、値は無視される。

属性のすべての値が無視される可能性があることに注意してください。そうなった場合には、属性は、空であるかのように扱わなければなりません(MUST)。

例えば、DBPedia上のAlbert Einsteinの完全なIRIは次のとおりです。

http://dbpedia.org/resource/Albert_Einstein

著者は、情報を扱いやすくするためにCURIEを用いてこれを短縮できます。最初のステップは、著者がIRIの先頭セグメントに接頭辞をリンクさせた接頭辞マッピングを作成することです。RDFaでは、このマッピングは@prefixを用いて表されます。

<div prefix="db: http://dbpedia.org/">
  ...
</div>

接頭辞が確立されると、著者はそれを用いて次のようにIRIを短縮できます。

<div prefix="db: http://dbpedia.org/">
  <div about="db:resource/Albert_Einstein">
    ...
  </div>
</div>

著者はIRIをいつでも自由に分割できます。しかし、CURIEの一般的な使用方法は用語と値の利用可能なライブラリを作ることであるため、接頭辞は通常、最も再利用されるものを提供する共通セグメントにマッピングされ、用語のライブラリの管理人によって提供されることが多いです。例えば、DBPediaには膨大な資源のリストが含まれているため、資源の基底位置を用いた接頭辞マッピングを作成する方が効率的です。

<div prefix="dbr: http://dbpedia.org/resource/">
  <div about="dbr:Albert_Einstein">
    ...
  </div>
  <div about="dbr:Baruch_Spinoza">
    ...
  </div>
</div>

<div prefix="dbr: http://dbpedia.org/resource/">
  <div about="dbr:Albert_Einstein">
    ...
  </div>
</div>
<div prefix="dbr: http://someotherdb.org/resource/">
  <div about="dbr:Albert_Einstein">
    ...
  </div>
</div>

<div about="http://dbpedia.org/resource/Albert_Einstein">
  ...
</div>

<div about="dbr:Albert_Einstein">
  ...
</div>

<div about="[dbr:Albert_Einstein]">
  ...
</div>

<div about="[Albert_Einstein]">
  ...
</div>

<div about="Albert_Einstein">
  ...
</div>

term     ::=  NCNameStartChar termChar*
termChar ::=  ( NameChar - ':' ) | '/'

<link rel="license" href="http://example.org/license.html" />
<link rel="xhv:license" href="http://example.org/license.html" />

<> <http://www.w3.org/1999/xhtml/vocab#license> <http://example.org/license.html> .

<link about="_:john" rel="foaf:mbox"
  href="mailto:john@example.org" />
<link about="_:sue" rel="foaf:mbox"
  href="mailto:sue@example.org" />
<link about="_:john" rel="foaf:knows"
  resource="_:sue" />

_:john foaf:mbox <mailto:john@example.org> .
_:sue foaf:mbox <mailto:sue@example.org> .
_:john foaf:knows _:sue .

7.5 順序

処理は通常、解析対象のドキュメントが完全にロードされた後に開始されます。しかし、そうである必要はなく、SAX[SSAX]などのストリーム・ベースのアプローチを用いてRDFa情報を抽出することも確かに可能です。しかし、ここで定義しているDOMトラバーサルの技術以外のアプローチを用いる場合は、ホスト言語固有の処理規則を確実に適用することが重要です(例えば、XHTML+RDFa[XHTML-RDFA]では、base要素を使用できることが示されており、baseは、たとえmetaやlinkの要素がストリームのbase要素の前にあっても、それらの要素内のIRIの解釈に影響を与えるでしょう)。

処理の開始時に初期評価コンテキストが次のように作成されます。

• 基底はドキュメントのIRI(または、HTMLのbase要素などの言語固有の方法で指定されている別の値)に設定される。
• 親の主語は基底の値に設定される。
• 親の目的語はヌル(null)に設定される。
• 不完全なトリプルのリストは空である。
• リスト・マッピングは空である。
• 言語はヌルに設定される。
• IRIマッピングのリストは空(または、ホスト言語の初期コンテキストで定義されているリスト)である。
• 用語マッピングはヌル(または、ホスト言語の初期コンテキストで定義されているリスト)に設定される。
• デフォルトの語彙はヌル(またはホスト言語の初期コンテキストで定義されているIRI)に設定される。

処理は、この初期評価コンテキストのコンテキストにおいて、以下の処理規則をドキュメントの目的語に適用することによって開始されます。各規則集合に用いられている評価コンテキストは、適用されている可能性のある以前の規則に基づいていますが、ツリーのすべての要素は、深さ優先(depth-first)で、下記で説明する規則に従っても処理されます。

処理規則は次のとおりです。

1. まず、ローカルな値が次のように初期化される。
   • スキップ要素フラグは「偽」(false)に設定される。
   • 新しい主語はヌルに設定される。
   • 現在の目的語資源はヌルに設定される。
   • 型付き資源はヌルに設定される。
   • IRIマッピングのローカルなリストは評価コンテキストからのIRIマッピングのリストに設定される。
   • 不完全なトリプルのローカルなリストはヌルに設定される。
   • リスト・マッピングは評価コンテキストからのリスト・マッピング(の参照)に設定される。
   • 現在の言語の値は評価コンテキストからの言語の値に設定される。
   • ローカルな用語マッピングは評価コンテキストからの用語マッピングに設定される。
   • ローカルなデフォルトの語彙は評価コンテキストからのデフォルトの語彙に設定される。
   一部のローカルな変数は、評価コンテキストを介して子孫要素に渡される値の一時的なコンテナであることに注意してください。コンテナの名前が同じである場合もあるため、次の手順でどちらが処理されているかを明確にするため、項目のローカルなバージョンは一般的にそのような名前で呼ばれます。
   ローカルな用語マッピングは、初期コンテキストによって提供され、常にグローバルな値にリセットされることに注意してください。この仕様の将来のバージョンでは、ローカルな用語マッピングを動的に設定できるメカニズムが導入されるかもしれません。その場合、ローカルな用語マッピングは親の値から継承されるでしょう。
2. 次に、@vocabによりデフォルトの語彙への変更に対して現在の要素が検証される。@vocabが存在し、値を含んでいれば、ローカルなデフォルトの語彙は、CURIEとIRIの処理の項に従って更新される。値が空であれば、ローカルなデフォルトの語彙は、デフォルトに定義されている(存在する場合)ホスト言語にリセットされなければならない(MUST)。
   @vocabの値は、次のようにトリプルを生成するために用いられます。

   主語

   基底

   述語

   http://www.w3.org/ns/rdfa#usesVocabulary

   目的語

   @vocabの値

   ホスト言語ではデフォルトの語彙を定義する必要はありません。そのような場合には、@vocabを空の値に設定すると、ローカルなデフォルトの語彙をヌルに設定する効果があります。
3. 次に、現在の要素がIRIマッピングに対して検証され、これらがIRIマッピングのローカルなリストに追加される。IRIマッピングは、同じ名前を持つリスト内の現在のマッピングを単純に上書きすることに注意。
   マッピングは@prefixで定義されます。この属性の値は、最初から最後まで評価されます(例えば、通常のドキュメントでは左から右へと)。下位互換性のため、RDFaプロセッサは@xmlnsによるマッピングの定義も認めるべきです(SHOULD)。この場合、マッピングされる値は、XML名前空間接頭辞で設定され、マッピングする値は属性の値 — IRI — です。(@xmlnsによる接頭辞マッピングは非推奨であり、この仕様の将来のバージョンでは削除されるかもしれないことに注意してください。)xmlnsがサポートされていれば、そのマッピングは、同じ要素の@prefixのマッピングを処理する前に処理しなければなりません(MUST)。マッピングの宣言方法に関わらず、マッピングする値は、小文字に変換しなければならず(MUST)、そのIRIは決して処理されません。特にそれが相対パスであれば、現在の基底に対して解決してはなりません(MUST NOT)。著者は、相対パスをIRIとして用いるべきではありません(SHOULD NOT)。
4. 現在の要素は、任意の言語情報に対しても解析が行われ、存在していれば、それに応じて現在の言語が設定される。
   RDFaを組み込んだホスト言語は、要素とそのコンテンツの自然言語を指定するメカニズムを提供できます(MAY)(例えば、XMLは汎用のXML属性である@xml:langを提供している)。
5. 現在の要素に@rel属性または@rev属性が含まれていなければ、次のステップは新しい主語の値を確立することである。このステップには2つの選択肢がある。
   1. 現在の要素に@property属性が含まれているけれども、@contentと@datatypeの属性のいずれも含まれていなければ、
      新しい主語は、次の規則の最初の一致から得られた資源に設定されます。

      • CURIEとIRIの処理の項に従って得られた@aboutの資源(存在していれば)を用いることによる。
      • そうでない場合、その要素がドキュメントのルート要素であれば、空の@aboutが存在しているかのように動作し、上記の@aboutの規則に従って処理する。
      • そうでない場合、親の目的語が存在していれば、新しい主語は、親の目的語の値に設定される。

      @typeofが存在していれば、型付き資源は、次の規則の最初の一致から得られた資源に設定されます。

      • CURIEとIRIの処理の項に従って得られた@aboutの資源(存在していれば)を用いることによる。
      • そうでない場合、その要素がドキュメントのルート要素であれば、空の@aboutが存在しているかのように動作し、前の規則に従って処理する。
      • そうでない場合、
        • CURIEとIRIの処理の項に従って得られた@resourceの資源(存在していれば)を用いることによる。
        • そうでない場合、CURIEとIRIの処理の項に従って得られた@hrefのIRI(存在していれば)を用いることによる。
        • そうでない場合、CURIEとIRIの処理の項に従って得られた@srcのIRI(存在していれば)を用いることによる。
        • そうでない場合、型付き資源の値は新しく作成されたbノードに設定される。
        • その後、現在の目的語資源の値は、型付き資源の値に設定される。
   2. そうでない場合:
      • 要素に@about、@href、@src、または@resource属性が含まれていれば、新しい主語は、次のようにして得られた資源に設定される。
        • CURIEとIRIの処理の項に従って得られた@aboutの資源(存在していれば)を用いることによる。
        • そうでない場合、CURIEとIRIの処理の項で得られた@resourceの資源(存在していれば)を用いることによる。
        • そうでない場合、CURIEとIRIの処理の項に従って得られた@hrefのIRI(存在していれば)を用いることによる。
        • そうでない場合、CURIEとIRIの処理の項に従って得られた@srcのIRI(存在していれば)を用いることによる。
      • そうでない場合、資源属性で資源が提供されていなければ、次の規則の最初の一致が適用される。
        • その要素がドキュメントのルート要素であれば、空の@aboutが存在しているかのように動作し、上記の@aboutの規則に従って処理する。
        • そうでない場合、@typeofが存在していれば、新しい主語は、新しく作成されたbノードになるように設定される。
        • そうでない場合、親の目的語が存在していれば、新しい主語は親の目的語の値に設定される。さらに、@propertyが存在していなければ、スキップ要素フラグが「真」(true)に設定される。

      • 最後に、@typeofが存在していれば、型付き資源を新しい主語の値に設定する。

6. 現在の要素に@relまたは@revの属性が含まれていれば、次のステップは、新しい主語の値と現在の目的語資源の値の両方を確立することである。
   新しい主語は、下記の規則の最初の一致から得られた資源に設定されます。

   • CURIEとIRIの処理の項に従って得られた@aboutからの資源(存在していれば)を用いることによる。

   @typeof属性が存在していれば、型付き資源を新しい主語に設定します。

   資源が提供されていなければ、次の規則の最初の一致が適用されます。

   • 要素がドキュメントのルート要素であれば、空の@aboutがあるかのように動作し、上記の@aboutの規則に従って処理する。
   • そうでない場合、親の目的語が存在していれば、新しい主語がそれに設定される。

   次に、現在の目的語資源は、次の規則の最初の一致から得られた資源に設定されます。

   • CURIEとIRIの処理の項に従って得られた@resourceの資源(存在していれば)を用いることによる。
   • そうでない場合、CURIEとIRIの処理の項に従って得られた@hrefのIRI(存在していれば)を用いることによる。
   • そうでない場合、CURIEとIRIの処理の項に従って得られた@srcのIRI(存在していれば)を用いることによる。
   • そうでない場合、@typeofが存在しており、@aboutが存在していなければ、新しく作成されたbノードを用いる。

   @typeofが存在しており、@about存在していなければ、型付き資源を現在の目的語資源に設定します。

   現在の目的語資源の最終的な値は、ヌル(初期化からの)か完全なIRIかbノードのいずれかになることに注意してください。

7. 前のいずれかのステップにおいて、型付き資源が、ヌルでない値に設定されていれば、それは今度は主語を型の値に提供するために用いられる。
   型付き資源に対する1つ以上の「型」は、@typeofを用いて設定できます。存在していれば、属性は、CURIEとIRIの処理の項に従って得られた1つ以上のIRIを含むことができ、それぞれは次のようにトリプルを生成するために用いられます。

   主語

   型付き資源

   述語

   http://www.w3.org/1999/02/22-rdf-syntax-ns#type

   目的語

   型付き資源の「型」の現在の完全なIRI

8. 前のいずれかのステップにおいて、新しい主語が親の目的語とは異なるヌルでない値に設定されていれば、
   評価コンテキストから得られたリスト・マッピングは、新しい空のマッピングに設定されます。
9. 前のいずれかの手順において、現在の目的語資源がヌルではない値に設定されていれば、それは今度はトリプルを生成してローカルなリスト・マッピングにエントリを追加するために用いられます。
   要素に@inlistと@relの属性の両方が含まれていれば、@relには、CURIEとIRIの処理の項に従って得られた1つ以上の資源を含むことができ、それぞれは次のようにリスト・マッピングにエントリを追加するために用いられます。

   • ローカルなリスト・マッピングにIRIに関連付けられたリストが含まれていなければ、新しいリストをインスタンス化してローカルなリストのマッピングに追加する。
   • ローカルなリスト・マッピングの資源に関連付けられたリストに現在の目的語資源を追加する。
   現在の目的語資源に対する述語は、@relと@revの属性の一方または両方を用いて設定できますが、@rel属性の場合は@inlistが存在しない場合に限られます。

   • 存在していれば、@relには、CURIEとIRIの処理の項に従って得られた1つ以上の資源を含むことができ、それぞれは次のようにトリプルを生成するために用いられる。

     主語

     新しい主語

     述語

     完全なIRI

     目的語

     現在の目的語資源

   • 存在していれば、@revには、CURIEとIRIの処理の項に従って得られた1つ以上の資源を含むことができ、それぞれは次のようにトリプルを生成するために用いられる。

     主語

     現在の目的語資源

     述語

     完全なIRI

     目的語

     新しい主語

10. 現在の目的語資源はヌルに設定されたけれども、述語が存在している場合は、目的語として使用できる主語が発見されるまでそれを不完全なトリプルとして格納しなければならない。また、現在の目的語資源は、新しく作成されたbノードに設定すべきである(不完全なトリプルが最終的にトリプルになった場合に接続する主語が存在しているように)。
    不完全なトリプルに対する述語は、@relと@revの属性の一方または両方を用いて設定できます。

    • 存在していれば、@relには、CURIEとIRIの処理の項に従って得られた1つ以上の資源が含まれていなければならず、それぞれは次のように不完全なトリプルのローカルなリストに追加される。
      • 要素に@inlist属性が含まれていれば、
        • ローカルなリスト・マッピングにIRIに関連付けられているリストが含まれていなければ、新しいリストをインスタンス化してローカルなリスト・マッピングに追加する。
        • 追加:

          リスト

          このIRIに対するローカルなリスト・マッピングのリスト

          方向

          なし

      • そうでない場合に追加:

        • 述語

          完全なIRI

          方向

          正方向

    • 存在していれば、@revには、CURIEとIRIの処理の項に従って得られた1つ以上の資源が含まれていなければならず、それぞれは次のように不完全なトリプルのローカルなリストに追加される。

      述語

      完全なIRI

      方向

      逆方向

11. 繰り返しの次のステップは、現在のプロパティー値を確立することである。
    現在のプロパティー値に対する述語は@propertyを用いて設定できます。存在していれば、CURIEとIRIの処理の項に従って1つ以上の資源が得られ、実際のリテラル値は次のように得られます。

    • @datatypeが存在していれば、型付きリテラルとして、CURIEとIRIの処理の項に従った空の値はなく、http://www.w3.org/1999/02/22-rdf-syntax-ns#という語彙のXMLLiteralには設定されない。

      実際のリテラルは、現在の要素のうち、順に、@contentの値(存在していれば)、またはすべての子孫テキスト・ノードの値を連結して作成された文字列のいずれかである。最後の文字列には、[RDF-SYNTAX-GRAMMAR]で記述されているデータ型IRIが含まれており、それはCURIEとIRIの処理の項に従って得られる。

    • そうでない場合、@datatypeは存在しているがCURIEとIRIの処理の項に従った空の値があれば、プレーン・リテラルとして。

      実際のリテラルは、現在の要素のうち、順に、@contentの値(存在していれば)、またはすべての子孫テキスト・ノードの値を連結して作成された文字列のいずれかである。

    • そうでない場合、@datatypeが存在しており、http://www.w3.org/1999/02/22-rdf-syntax-ns#という語彙のXMLLiteralに設定されていれば、XMLリテラルとして。

      XMLリテラルの値は、テキストへのシリアル化を行い、すべてのノードが現在の要素の子孫である、つまり要素自体を含まず、http://www.w3.org/1999/02/22-rdf-syntax-ns#という語彙でXMLLiteralのデータ型を付与して作成される文字列である。その結果のシリアル化されたコンテンツの形式は、排他的XML正規化バージョン1.0[XML-EXC-C14N]で定義されているとおり。

      注

      このリテラルのポータビリティを最大限に維持するために、要素である現在のノードの子要素には、シリアル化された要素で宣言されている現在のXML名前空間宣言(存在していれば)がなければなりません(MUST)。子要素ノードは、新しいXML名前空間も宣言できるため、RDFaプロセッサは、シリアル化された要素の定義を生成する際にそれを注意深く統合しなければなりません(MUST)。誤解を避けるために、現在のノードでアクティブだった宣言よりも子ノードの再宣言を優先させなければなりません(MUST)。

    • そうでない場合、@contentが存在していれば、@contentの値を用いてプレーン・リテラルとして。
    • そうでない場合、@rel、@rev、および@contentの属性が存在していなければ、次の資源のうちの1つから得られた資源として。
      • CURIEとIRIの処理の項に従って得られた@resourceからの資源(存在していれば)を用いて。
      • そうでない場合、CURIEとIRIの処理の項に従って得られた@hrefからのIRI(存在していれば)を用いて。
      • そうでない場合、CURIEとIRIの処理の項に従って得られた@srcからのIRI(存在していれば)を用いて。
    • そうでない場合、@typeofが存在していて@aboutが存在していなければ、型付き資源の値。
    • そうでない場合、プレーン・リテラルとして。

    さらに、現在の言語に値があれば、[RDF-SYNTAX-GRAMMAR]で記述しているとおり、プレーン・リテラルの値にこの言語情報を含めるべきです。実際のリテラルは、@contentの値(存在していれば)または現在の要素の各子孫要素のテキストのコンテンツをドキュメント順に連結して作成された文字列です。

    次に、現在のプロパティー値は、次のように各述語とともに用いられます。

    • 要素に@inlist属性も含まれていれば、現在のプロパティー値は、次のようにローカルなリスト・マッピングに追加される。
      • ローカルなリスト・マッピングに、述語IRIに関連付けられているリストが含まれていなければ、新しいリストをインスタンス化してローカルなリスト・マッピングに追加する。
      • 現在のプロパティー値を、ローカルなリスト・マッピングの述語IRIに関連付けられているリストに追加する。
    • そうでない場合、次のようにトリプルを生成するために現在のプロパティー値が用いられる。

      主語

      新しい主語

      述語

      完全なIRI

      目的語

      現在のプロパティー値

12. スキップ要素フラグが「偽」であり、かつ、新しい主語がヌルでない値に設定されていれば、現在のコンテキスト内の不完全なトリプルを完全にすべきである。
    現在の評価コンテキストの不完全なトリプルのリスト(不完全なトリプルのローカルなリストではなく)には、0以上の述語IRIが含まれるでしょう。このリストは繰り返され、各述語は親の主語および新しい主語とともに用いられ、トリプルを生成するか、ローカルなリスト・マッピングに新しい要素を追加します。各レベルに不完全なトリプルのリストが2つあることに注意してください。1つは現在の処理レベル(前のステップでは各子要素に渡されるもの)で、もう1つは評価コンテキストの一部として受け取られたものです。このステップの処理で用いられるのは後者です。
    不完全なトリプルにはそれぞれ、生成される各トリプルのうち、何が主語になるのか、何が目的語になるのかを決定するために用いられる方向の値があることに注意してください。

    • 方向が「なし」の場合、繰り返される不完全なトリプルから新しい主語がリストに追加される。
    • 方向が「正方向」の場合、次のトリプルが生成される。

      主語

      親の主語

      述語

      繰り返される不完全なトリプルの述語

      目的語

      新しい主語

    • 方向が「逆方向」の場合、これは生成されたトリプルである。

      主語

      新しい主語

      述語

      繰り返される不完全なトリプルの述語

      目的語

      親の主語

13. 次に、現在の要素の子であるすべての要素が、ここで記述している規則を用いて処理され、新しい評価コンテキストを用いて、次のように初期化される。
    • スキップ要素フラグが「真」であれば、新しい評価コンテキストは、このレベルの処理に渡された現在のコンテキストのコピーであり、言語とIRIマッピング値のリストがローカルな値で置き換えられる。
    • そうでない場合、値は次のとおりである。
      • 基底は現在の評価コンテキストの基底の値に設定される。
      • 親の主語は新しい主語の値(ヌルでない場合)か、現在の評価コンテキストの親の主語の値に設定される。
      • 親の目的語は現在の目的語資源の値(ヌルでない場合)か、新しい主語の値(ヌルでない場合)か、現在の評価コンテキストの親の主語の値に設定される。
      • IRIマッピングのリストはIRIマッピングのローカルなリストに設定される。
      • 不完全なトリプルのリストは不完全なトリプルのローカルなリストに設定される。
      • リスト・マッピングはローカルなリスト・マッピングに設定される。
      • 言語は現在の言語の値に設定される。
      • デフォルトの語彙はローカルなデフォルトの語彙の値に設定される。
14. 最後に、ローカルなリスト・マッピングに1つ以上のマッピングがあれば、リストのトリプルは下記のように生成される。
    ローカルなリスト・マッピングのIRIごとに、同等のリストが評価コンテキストに存在していなければ、それはそのリストが元々現在の要素でインスタンス化されたことを示し、次のようにリストを用います。

    • IRIに関連付けられているリストに項目がなければ、次のトリプルを生成する。

      主語

      現在の主語

      述語

      このリストに関連付けられているローカルなリスト・マッピングの完全なIRI

      目的語

      http://www.w3.org/1999/02/22-rdf-syntax-ns#nil

    • そうでない場合、
      • 新しく作成されたbノードを含んでいる新しい「bノード」配列を作成する(リストの項目ごとに1つ)。
      • リストのbノード-(IRIまたはリテラル)の対ごとに、次のトリプルが生成される。

        主語

        bノード

        述語

        http://www.w3.org/1999/02/22-rdf-syntax-ns#first

        目的語

        完全なIRIまたはリテラル

      • 「bノード」配列の項目ごとに、次のトリプルが生成される。

        主語

        bノード

        述語

        http://www.w3.org/1999/02/22-rdf-syntax-ns#rest

        目的語

        「bノード」配列の次の項目、またはそれが存在していなければ、http://www.w3.org/1999/02/22-rdf-syntax-ns#nil

      • 1つの追加のトリプルが生成される。

        主語

        現在の主語

        述語

        このリストに関連付けられているローカルなリスト・マッピングの完全なIRI

        目的語

        「bノード」配列の最初の項目

7.6 プロセッサのステータス

前項でカバーした処理規則は、ドキュメントからできる限り多くのトリプルを抽出するように設計されています。RDFaプロセッサは、エラーが発生した場合にも処理を続行するように設計されています。例えば、接頭辞マッピングや用語の解決に失敗すると、RDFaプロセッサはトリプルの生成をスキップし、ドキュメントの処理を続行します。個々のRDFaプロセッサの警告やエラーを知ることは、著者にとって有益な場合があります。プロセッサ・グラフは、すべての参考情報、警告、およびエラー・メッセージをRDFaプロセッサからのトリプルとして捕捉するメカニズムとして設計されています。これらのステータスのトリプルは、RDFaのオーサリングや自動エラー検出を助けるために取得され、使用できます。

RDFaプロセッサがプロセッサ・グラフの生成をサポートしている場合、次の処理の問題が発生したときは、トリプルの集合を生成しなければなりません(MUST)。

• 適合しないホスト言語のマークアップの結果としてドキュメントを完全に処理できなかった場合、rdfa:Errorが生成されなければならない(MUST)。
• CURIE接頭辞の解決に失敗した場合、rdfa:Warningが生成されなければならない(MUST)。
• 用語の解決に失敗した場合、rdfa:Warningが生成されなければならない(MUST)。

RDFaによって、その他の実装固有のrdfa:Info、rdfa:Warning、またはrdfa:Errorのトリプルが生成されることがあります(MAY)。

@prefix rdfa:    <http://www.w3.org/ns/rdfa#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix dc:      <http://purl.org/dc/terms/> .
[] a rdfa:DocumentError ;
   dc:description "The document could not be parsed due to parsing errors." ;
   dc:date "2010-06-30T13:40:23"^^xsd:dateTime .

@prefix rdfa:    <http://www.w3.org/ns/rdfa#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix dc:      <http://purl.org/dc/terms/> .
@prefix ptr:     <http://www.w3.org/2009/pointers#> .
@prefix ht:      <http://www.w3.org/2006/http#> .
 
[] a rdfa:DocumentError ;
   dc:description "The document could not be parsed due to parsing errors." ;
   dc:date "2010-06-30T13:40:23"^^xsd:dateTime ;
   rdfa:context <http://www.example.org/doc> ;
   rdfa:context [
      a ptr:Pointer ;
      # Detailed xpointer/xpath information provided here to locate the error.
   ] ;
   rdfa:context [
      a ht:Response ;
      ht:responseCode <http://www.w3.org/2006/http#404>
      # The HTTP response headers on the request for the source file.
   ].

7.7 語彙拡張

プロセッサは、RDFa語彙拡張で記述しているとおり、制限されたRDFSとOWLの含意規則を利用して語彙拡張を行うことができます(MAY)。