RDFa 処理器 (RDFa 1.0)

[2] 適合conforming RDFa 処理器processorは、 RDFa 仕様書に従って RDF 三項組を取り出す処理器です。

仕様書

[1] RDFa in XHTML: Syntax and Processing (2008-10-14 00:17:32 +09:00 版) http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/#processorconf

要件

[3] 消費応用に対し、 RDFa 仕様書の処理モデルの章の規則によって生成した三項組すべてを含む単一の RDFグラフを提供しなければなりません
[5] >>4 の追加三項組を既定グラフにおいて提供してはなりません

許可

[4] RDFa 仕様書の規則に則らない三項組を提供して構いません

RDFa 処理器 (RDFa 1.1)

[17] RDFa が含まれる文書を処理してグラフを取り出すものを RDFa 処理器processorといいます。

[15] RDFa の処理は文書木に対する探索として定義されています。文書オブジェクトから順に子要素を文書順にたどって処理していきます。 >>16

仕様書

[14] RDFa Core 1.1 - Second Edition (2013-08-15 17:12:47 +09:00 版) http://www.w3.org/TR/rdfa-core/#h3_processorconf
[16] RDFa Core 1.1 - Second Edition (2013-08-15 17:12:47 +09:00 版) http://www.w3.org/TR/rdfa-core/#h2_s_model
[130] RDFa Core 1.1 - Second Edition (2013-08-15 17:12:47 +09:00 版) http://www.w3.org/TR/rdfa-core/#h2_s_initialcontexts

出力

[11] 適合RDFa処理器conforming RDFa Processorは処理の結果として出力グラグoutput graphと処理器グラグprocessor graphを応用に提供しなければなりません。 >>5

[12] 出力グラフは、 RDFa 1.1 の処理モデルにより得られたすべての三項組からなるRDFグラグです。 >>5

[13] 処理器グラフは、RDFa処理器が報告したエラー、警告、情報を集めたものです。 >>5

[127]

処理器グラフには接頭辞に関するエラーなどが含まれることになっています。そのようなエラーがあっても処理自体は継続されます。

[128] エラーといっても接頭辞以外はほとんどどんな記述であっても適当に解釈されてしまうので、誤ったマーク付けを検出する目的ではあまり使いものにならなそうです。

[129] RDFa処理器が Webアプリケーションとして実装されている場合には rdfagraph という query parameter でどのグラフを得たいかを指定することになっています >>16。

適合 XHTML+RDFa 1.0 利用者エージェント

仕様書

[166] RDFa in XHTML: Syntax and Processing (2008-10-14 00:17:32 +09:00 版) http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/#uaconf

要件

[167] 適合利用者エージェントconforming user agentには次の2要件が課されています。

[168] RDFa 1.0 仕様書で必須とされた機能すべてに対応しなければなりません。
[169] XHTML m12n 1.1 XHTML族利用者エージェントでなければなりません。

メモ

[171] あいかわらず「必須とされたすべての機能」などという曖昧な要件を課しています。

適合 XHTML+RDFa 1.1 利用者エージェント

仕様書

[172] XHTML+RDFa 1.1 (2012-06-05 02:29:56 +09:00 版) http://www.w3.org/TR/2012/REC-xhtml-rdfa-20120607/#user-agent-conformance

要件

[173] XHTML+RDFa 1.1 仕様書で必須とされた機能すべてに対応しなければなりません。
[174] XHTML m12n 1.1 2e 適合XHTML族利用者エージェントの要件に対応しなければなりません。

HTML+RDFa 処理器と利用者エージェント

仕様書

[176] HTML+RDFa 1.1 (2013-08-20 15:49:04 +09:00 版) http://www.w3.org/TR/2013/REC-html-rdfa-20130822/#rdfa-processor-conformance

要件

[177] RDFa処理器には次の要件が課されています >>176。

[178] RDFa Core 1.1 仕様書で必須とされた機能をすべて実装しなければなりません。
[179] HTML+RDFa 1.1 仕様書で必須とされた機能をすべて実装しなければなりません。

[180] 利用者エージェントには次の要件が課されています >>176。

[181] HTML 5.0 仕様書の適合性の項の要件すべてに適合しなければなりません。
[183] HTML+RDFa 1.1 仕様書で必須とされた機能をすべて実装しなければなりません。
[182] RDFa Core 1.1 仕様書で必須とされた機能をすべて実装しなければなりません。ただし HTML+RDFa 1.1 仕様書で上書きされた機能を除きます。

[184] 処理器と利用者エージェントで別になっているのは、ごくわずかなレンダリング機能しか備えないものなど、 RDFa処理器として妥当であっても HTML 5.0 処理器として妥当でないものがあり得るからとされています >>176。

[185] 実際には HTML5 はむしろそのようなツールの類であっても適合性を主張できるようにむしろ慎重に定義されており、 HTML5 に対する無理解に由来する誤った規定のように思えます。仮に >>184 の主張が正しいとしたところで、 RDFa に対する適合性の一部として HTML5 への適合性を要求する必要性は見当たらず、なぜ敢えて2つの適合水準を設けているのか不可解です。

[186] >>178 と >>182 は同じですが、 >>179 と >>183 は異なっています。この違いが意図的なものなのかどうかはわかりませんが、隣同士の章でそれほど離れておらず、違いの説明まで書かれている要件に誤って混入した規定とも思えません。 >>182 の通り HTML+RDFa と RDFa 本体の機能に一部矛盾があると解釈すると、 >>178 と >>179 が同時に満たせるのか (適合するRDFa処理器が存在できるのか) が気になります。

[187]

HTML+RDFa 1.1 と同時に RDFa Core 1.1 の第2版が出版されているので、なぜそのような衝突する規定が RDFa Core 1.1 側で改訂されずに猿パッチになっているのか謎ですが・・・。

RDFa 1.1 処理モデル

評価文脈

[18] RDFa 1.1 の処理は評価文脈evaluation contextを使って行われます。開始時には初期文脈initial contextが使われ、子要素の評価の際はそれぞれのために作られた評価文脈が使われます。 >>16

[19] 評価文脈には次の項目が含まれます >>16。

基底base
親主語parent subject
親目的語parent object
IRI 写像IRI mappingsのリスト
不完全三項組incomplete triplesのリスト
リスト写像list mapping
言語language
語写像term mappingsのリスト
既定語彙default vocabulary

[20] 初期文脈は次のように定義されています。

基底は処理する文書の基底URL >>16
親主語は基底と同じ >>16
親目的語は null >>16
IRI写像のリストは空 (RDFaホスト言語が定義することもできる) >>16
不完全三項組のリストは空 >>16
リスト写像は空 >>16
言語は null >>16
語写像のリストは定義しない (RDFaホスト言語が定義して構わない) >>16
既定語彙は定義しない (RDFaホスト言語が定義して構わない) >>16

[21] 仕様書の規定は曖昧かつ分散しています。この程度の単純な定義くらいはっきり書けてほしいのですが・・・。

[154] RDFa Core 1.1 本体仕様には明記されていませんが、初期文脈は複数あって順番に適用するということがあり得るようです。 (>>145, >>191)

[131] このホスト言語による初期文脈の定義については、構文解析器はそれをハードコードしても構いませんし、外部の文書として読み込む形にしても構いません。その外部の文書は、 RDFaホスト言語として承認されたものを使い、 RDFa 仕様書で規定された語彙により記述されなければならない >>130 とされています。いずれにせよよく知られた安定した初期文脈の定義は埋め込んでいるべきです >>130。

[132]

RDFaホスト言語の適合性の規定によると、そのような文書を用意すること自体は推奨でしかないようです。

[7] 歴史的事項は HTML の profile 属性の歴史の項も参照。

[22] 評価文脈に関連して、処理中は次の一時変数が使われます >>16。

IRI写像の局所リストlocal list of IRI mappings: 初期状態は空
不完全三項組の局所リストlocal list of incomplete triples: 初期状態は空
現在言語current language: 初期状態は空
要素を飛ばすskip elementフラグ
新主語new subject
現在特性値current property value
現在目的語資源current object resource
型付き資源typed resource
局所語写像local term mappings
局所リスト写像local list mapping
局所既定語彙local default vocabulary

処理

[23] RDFa の属性はホスト言語によっては省くことができますが、その場合当該属性に関する処理は行いません >>16。

[27] CURIE を含む属性の処理については、 CURIE の項をご覧ください。 CURIE 等が非妥当である場合その値が無視されると規定されており、その結果属性が空とみなされることもあります。空と属性が存在しないのは別の状態のようです。

[25] 現在要素current elementに対する RDFa の処理は次のように行われます >>16。

[24] 次の通り初期化します。
- 要素を飛ばすフラグは偽に
- 新主語、現在目的語資源、型付き資源、不完全三項組の局所リストは null に
- その他は評価文脈の値に
[26] 現在要素の vocab 属性の値があれば、それを解決して局所既定語彙とします。空なら、ホスト言語によって規定された既定値 (または null) とします。
- ここでいう既定値とは初期文脈の既定語彙と同じものでしょうか?
1. [28] 値があれば (基底, http://www.w3.org/ns/rdfa#usesVocabulary, 局所既定語彙) の三項組を生成します。
[29] 現在要素でIRI写像が定義されていれば、IRI写像の局所リストに追加します。既に同名のものがあれば上書きします。
1. [30] xmlns 宣言があれば、名前空間接頭辞を接頭辞、属性値を IRI とするべきです。
  - この手順はべきレベルであり、必須ではないようです。
2. [31] prefix 属性があれば、そこにある接頭辞と IRI の組を最初から最後の順で処理していきます。
- [32] ここで接頭辞は小文字に変換しなければなりません。
- [33] また IRI を解決してはなりません。
[34] 現在要素から言語を設定します。ホスト言語はこの方法を定義して構いません。
- 定義されていないときは好きにしていいのでしょうか...?
- XML+RDFa では xml:lang 属性を使っています。
[35] 現在要素が rel も rev を有していなければ、
1. [36] 現在要素が property 属性を有しており、 content も datatype も持っていなければ、
  1. [37] 新主語を次の値とします。
    1. [38] about 属性から値を得られれば、その資源
    2. [39] そうでなく現在要素が文書の根要素なら、空の about 属性があったとみなし、その資源
    3. [40] そうでなく親目的語があれば、それ
  2. [41] typeof があれば、型付き資源を次の値とします。
    1. [42] about 属性から値を得られれば、その資源
    2. [43] そうでなく現在要素が文書の根要素なら、空の about 属性があったとみなし、その資源
    3. [44] そうでなければ、
      1. [45] resource 属性から値を得られれば、その資源
      2. [46] そうでなく href 属性から値を得られれば、その IRI
      3. [47] そうでなく src 属性から値を得られれば、その IRI
      4. [48] そうでなければ新しい bnode
      5. [49] いずれにせよ、現在オブジェクト資源を型付き資源の値とします。
2. [50] そうでないなら、
  1. [51] about, href, src, resource のいずれかがあれば、新主語は次の値とします。
    1. [52] about 属性から値を得られれば、その資源
    2. [53] そうでなく resource 属性から値を得られれば、その資源
    3. [54] そうでなく href 属性から値を得られれば、その IRI
    4. [55] そうでなく src 属性から値を得られれば、その IRI
  2. [56] そうでなく resource 属性から資源を得られなければ、
    1. [57] そうでなく現在要素が文書の根要素なら、空の about 属性があったとみなし、その資源を新主語とします。
    2. [58] そうでなく typeof があれば、新主語をその bnode とします。
    3. [59] そうでなく親目的語があれば、新主語をその値とします。また property 属性がなければ、要素を飛ばすフラグを真とします。
  3. [60] typeof 属性があれば、型付き資源を新主語の値とします。
[61] 現在要素が rel か rev を有していれば、
1. [62] 新主語を次の値とします。
  1. [63] about 属性から値を得られれば、その資源
2. [64] typeof があれば、型付き資源の値を新主語とします。
3. [65] これで資源が決まらなければ次のようにします。
  1. [66] 現在要素が文書の根要素なら、空の about 属性があったとみなし、その資源を新主語とします。
  2. [67] そうでなく親目的語があれば、それを新主語とします。
4. [68] 現在目的語資源を次の値とします。
  1. [69] resource 属性から値を得られれば、その資源
  2. [70] そうでなく href 属性から値を得られれば、その IRI
  3. [71] そうでなく src 属性から値を得られれば、その IRI
  4. [72] そうでなく typeof があって about がなければ新しい bnode
5. [73] typeof があって about がなければ、型付き資源を現在目的語資源とします。
[74] >>35 か >>61 で型付き資源が null 以外に設定されたなら、
1. [75] typeof から得られた IRI それぞれについて、三項組 (型付き資源、 rdf:type、 IRI) を生成します。
[76] ここまでで新主語が null 以外かつ親目的語以外に設定されていれば、評価文脈のリスト写像を新しい空の写像に置き換えます。
[77] ここまでで現在目的語資源が null 以外に設定されていれば、
1. [78] inlist と rel の両方があれば、
  1. [79] rel から得られた IRI それぞれについて、
    1. [80] IRI に関連付けられたリストが局所リスト写像になければ、新しいリストを追加します。
    2. [81] そのリストに現在目的語資源を追加します。
2. [82] rel 属性があって inlist 属性がなければ、 rel 属性から得られた IRI それぞれについて、三項組 (新主語, IRI, 現在目的語資源) を追加します。
3. [84] rev 属性があれば、得られた IRI それぞれについて、三項組 (現在目的語資源, IRI, 新主語) を追加します。
[85] 現在目的語資源が null であれば、
1. [86] rel と inlist があれば、 rel から得られた IRI それぞれについて、
  1. [87] IRI に関連付けられたリストが局所リスト写像になければ、新しいリストを追加します。
  2. [88] 不完全三項組の局所リストに (リスト = 局所リスト写像から IRI へのリスト, 方向性 = なし) を追加します。
2. [89] そうでなければ、不完全三項組の局所リストに (述語 = IRI, 方向性 = 正) を追加します。
3. [90] rev があれば、得られた IRI それぞれについて、不完全三項組の局所リストに (述語 = IRI, 方向性 = 逆) を追加します。
4. [91] これらいずれかの場合には、現在目的語資源は新しい bnode とします。
[92] property があれば、
1. [93] 現在特性値は次の値です。
  1. [94] datatype があり、空以外の値を得られ、それが rdf:XMLLiteral 以外なら、型付きリテラルとします。そのリテラルの値は、 content があればその値、なければ子孫のテキスト節点の値を連結したものとします。型は datatype から得た値とします。
  2. [95] そうでなく datatype が空であれば、平リテラルとします。そのリテラルの値は、content があればその値、なければ子孫のテキスト節点の値を連結したものとします。
  3. [96] そうでなく、 datatype があり、得られた値が rdf:XMLLiteral なら、 XMLリテラルとします。 XMLリテラルの値は現在要素の子孫 (現在要素自体は含みません。) を排他的XML正準化1.0により直列化したものとします。型は rdf:XMLLiteral の IRI とします。
  4. [97] そうでなく content があれば、その値の平リテラルとします。
  5. [98] そうでなく rel、rev、content のいずれもないなら、
    1. [99] resource があればそこから得られる資源
    2. [100] そうでなく href があればそこから得られる IRI
    3. [101] そうでなく src があればそこから得られる IRI
  6. [102] そうでなく typeof があって about がなければ型付き資源
  7. [103] そうでなければ平リテラル
2. [104] 現在言語の値があれば、平リテラルの言語はその値とします。
3. [105] property から得られる IRI それぞれについて、
  1. [106] inlist があれば、
    1. [107] IRI に関連付けられたリストが局所リスト写像になければ、新しいリストを追加します。
    2. [108] そのリストに現在特性値を追加します。
  2. [109] そうでなければ、三項組 (新主語, IRI, 現在特性値) を生成します。
[110] 要素を飛ばすフラグが偽で新主語が null 以外なら、
1. [111] 評価文脈の不完全三項組のリストの不完全三項組それぞれについて、
  1. [112] 「方向」が無しなら、「リスト」に新主語を追加します。
  2. [113] 「方向」が正なら、三項組 (親主語, 「述語」, 新主語) を生成します。
  3. [114] 「方向」が逆なら、三項組 (新主語, 「述語」, 親主語) を生成します。
[115] 子要素それぞれについて、新しい評価文脈を使って再帰的に処理します。
1. [116] 要素を飛ばすフラグが真なら、現在の評価文脈を複写して、言語とIRI写像のリストを現在言語とIRI写像の局所リストに置き換えます。
2. [117] そうでないなら、次のようにします。
  - 基底は現在の評価文脈のもの
  - 親主語は新主語が null でないならそれ、そうでないなら現在の評価文脈の親主語
  - 親目的語は現在目的語資源が null でないならそれ、そうでなく新主語が null でないならそれ、そうでないなら現在の評価文脈の親主語
  - IRI写像のリストはIRI写像の局所リスト、不完全三項組のリストは不完全三項組の局所リスト、リスト写像は局所リスト写像、言語は現在言語、既定語彙は現在既定語彙
[118] 局所リスト写像の IRI それぞれについて、評価文脈の方に同じリストがなければ (つまり現在要素において作られたものなら)、
1. [119] その IRI に関連付けられたリストに何もなければ、三項組 (現在主語, IRI, rdf:nil) を生成します。
2. [120] そうでなければ、
  1. [121] リスト中のそれぞれについて bnode を生成します。
  2. [122] bnode とリスト中の IRI やリテラルの組それぞれについて、三項組 (bnode, rdf:first, IRI かリテラル) を生成します。
  3. [123] 各 bnode について三項組 (bnode, rdf:rest, 次の bnode (なければ rdf:nil)) を生成します。
  4. [124] 三項組 (現在主語, IRI, 最初の bnode) を生成します。

[125] XML+RDFa では xml:base も使われることになっていますが (>>137)、この処理ではなぜか使われていません。

[126]

RDFa は似たような機能を持つ属性が複数あったりして、本来 RDF を表現するために必要な以上に処理が複雑になっているように思えます。著者にとってもどの属性を使ったらいいのかわかりませんし、どのように表現するとどう解釈するのか理解するのが困難でしょう。 RDF/XML の処理と比べてもこれは相当に複雑です。

[149] 鬼畜なことに >>148 で XHTML+RDFa において、 >>197 で HTML+RDFa において一部の処理が猿パッチされています。

[150] 普通猿パッチは別の時期、別のグループの仕様書に対して変更を注入するものなのに、なぜ同時に同グループが出版した XHTML+RDFa 1.1 が RDFa Core 1.1 の規定を書き換える必要があるのですかね... HTML+RDFa も RDFa Core 1.1 の第2版と同時に出版されているのに...

[155] この処理では datatype 属性の値によって分岐するところがありますが、 XHTML+RDFa 1.1 の Metainformation Attributes Module では datatype の既定値が xs:string とされています。これらの規定の整合性がない気がしますがどうなっているのかは不明です。

XML+RDFa 文書

[10] RDFa処理器は XML+RDFa文書を次の初期文脈により処理します >>133。

[134] http://www.w3.org/2011/rdfa-context/rdfa-1.1 で定義されている既定の語termを用います。
[135] http://www.w3.org/2011/rdfa-context/rdfa-1.1 で定義されている既定のIRI写像を用います。
[136] 既定語彙 IRI はありません。
[137] xml:base 属性により基底を設定できます。
[138] xml:lang 属性により現在の言語を設定できます。

[133] RDFa Core 1.1 - Second Edition (2013-08-15 17:12:47 +09:00 版) http://www.w3.org/TR/rdfa-core/#h3_xmlrdfaconformance

[139] なぜか要件ではなく事実の文となっています。

[140] このように application/xml などと application/xhtml+xml などを区別するのは一般的な Webブラウザーの処理モデルと異なっています。また RDFa+XHTML などの処理とこの XML+RDFa の処理が衝突するおそれもあるはずですが、何も説明がありません。

[141]

>>137 と >>138 は初期文脈ではなく評価文脈に関する処理モデルの一部のような・・・。 (RDFa の仕様書はこのような若干のエスパーが必要な曖昧な記述が多いですね。)

XHTML+RDFa 1.1 文書

[151] RDFa処理器は html 要素の version 属性が使われている時にその値を調べなければなりません。 XHTML+RDFa の版として定義されているものであれば、その版の処理規則を用いなければなりません。そうでないか、 version 属性がない場合は、 XHTML+RDFa の最新版を使わなければなりません。 >>143

[152] これってつまり、 XHTML+RDFa 1.1 のRDFa処理器は XHTML+RDFa 1.0 も実装しないといけないってことですよね・・・。

[207]

XHTML+RDFa の最新版に XHTML5+RDFa が含まれるのかは不明です。 >>199 に従いかつ XHTML+RDFa 1.1 への適合性を主張したいのであれば、そう考えるしかありませんが・・・。

[142] XHTML+RDFa 1.1 文書は次のように処理されます >>143。

[144] 既定語彙IRIは未定義
[145] RDFa Core 1.1 の初期文脈 http://www.w3.org/2011/rdfa-context/rdfa-1.1 の後に XHTML+RDFa の初期文脈 http://www.w3.org/2011/rdfa-context/xhtml-rdfa-1.1 を適用する
[146] 基底は base 要素を使って設定できる
[147] 現在言語は lang または xml:lang を使って設定できる
[148] >>35 と >>61 において、 about, href, resource, src など資源属性によって IRI が指定されていない時で、 head 要素か body 要素であれば、新主語は親目的語に設定されているように動作する

[143] XHTML+RDFa 1.1 - Second Edition (2013-08-15 17:11:45 +09:00 版) http://www.w3.org/TR/2013/REC-xhtml-rdfa-20130822/#s_xhtmlRules

[153]

RDFa 本体の処理モデルの一部を書き換えるのがありなのですね・・・。びっくりです。普通プロファイル的なものって本体の仕様に従って特定の状況に適応させたもので、本体の仕様自体は変更しないものだと思うのですがね・・・。 (>>149)

HTML+RDFa

[188] HTML+RDFa 1.1 (2013-08-20 15:49:04 +09:00 版) http://www.w3.org/TR/2013/REC-html-rdfa-20130822/#extensions-to-rdfa-core-1.1
[242] HTML+RDFa 1.1 (2013-08-20 15:49:04 +09:00 版) http://www.w3.org/TR/2013/REC-html-rdfa-20130822/#preserving-namespaces-via-coercion-to-infoset

[224] HTML文書に要素の入れ子関係がおかしいものがあれば、 RDFa の処理の前に修正するべきです >>188。

[225] これはそもそも HTML の構文解析器が行うもので、 RDFa が規定するべきものではないと思いますが。 HTML文書の非妥当な要因はいくらでもあるうちでなぜ入れ子問題だけを明記したのかも謎ですし (例示というふいんきでもありません)、なぜ MUST でなく SHOULD なのかも不明です。

[189] HTML+RDFa 1.1 に適合する文書は RDFa Core 1.1 と次の例外に従い処理します >>188。

[190] 既定語彙 URI は未定義
[191] RDFa Core 1.1 の初期文脈 http://www.w3.org/2011/rdfa-context/rdfa-1.1 の後に HTML+RDFa の初期文脈 http://www.w3.org/2011/rdfa-context/html-rdfa-1.1 を適用する
[192] 基底は base 要素を使って設定でき、 XHTML5+RDFa 1.1文書では xlm:base でも設定できる。
[193] 現在言語は lang か xml:lang で設定でき、両方あると xml:lang が優先されます。両方ある場合同じ値でなければなりません。
[194] application/xhtml+xml の文書の場合は DOCTYPE を見なければなりません。
- [195] HTML+RDFa 1.1 仕様書には XHTML+RDFa 1.0 と XHTML+RDFa 1.1 の DOCTYPE が示されています。それ以外は XHTML5+RDFa 1.1 とされています。
- [196] DOCTYPE がなく version もなければ XHTML5+RDFa 1.1 と解釈しなければなりません。
[199] version 属性の値が RDFa の版として定義されたものなら、それにより処理しなければなりません。そうでないか version がないなら RDFa 1.1 の最新版により処理しなければなりません。
[197] RDFa Core 1.1 仕様書に対していくつか猿パッチを適用する (>>208)
[198] RDFa Core 1.1 の処理の後、特性複写操作を行う

[201] >>192 でなぜか XHTML の時だけ xml:base が適用されるとなっていますが、 HTML5 には (不適合ながら) HTML でも xml:base は有効とされているのに、なぜそれを参照せずに独自に定義するのか謎です。

[202] >>193 も HTML5 の定義を参照せずになぜ同じようなことを規定しているのか謎です。しかもなぜか処理の規定の中で lang と xml:lang の値が同じでなければならないと言及されていますが、本来は文書の適合性として規定されるべきものです。編集が雑すぎます。また HTML5 の同様の規定ではASCII大文字小文字不区別で同じとされていますが、こちらにはそのような記述がなく、意図的なのかどうかはわかりませんが RDFa の方がより制限が厳しくなっています。

[226] また HTML+RDFa 1.1 仕様書の別項には言語について HTML5 の仕様書に従わなければならないとの記述があり、 >>193 と矛盾しています。更に著者に対しては、 MIME型が事前にわからない時は lang と xml:lang の両方を同じ値にするべきとしています。 >>188

[227] そもそも MIME型が事前にわからない状況など普通はないですし (ほとんど text/html しか使われていない)、事前にわからないならその他にも考えなければならないことが沢山ありすぎるので、敢えて言語だけ言及する必要性があるのかどうか。

[228] >>226 の矛盾というのは、HTML5 の言語は Content-Language も考慮する点です。これについて注記では、 JavaScript ベースの (クライアント側の) RDFa の実装がこれにアクセスできないため不適合な実装となり、そのため著者ができるだけ lang 属性を使うのがよいurged >>188 とされています。

[203] >>195 の DOCTYPE の規定は実際仕様書に DOCTYPE の例示がありますが、それをどう解釈するべきかは不明です。一字一句そのままだと解釈するよりはスペースの違いなどは無視するべきと思いますが、システム識別子が相対URLの場合どう比較するべきなのかなどまったく言及がなく、曖昧すぎます。

[204]

>>189 は HTML+RDFa 文書の処理の規則として示されているのに >>194 や >>199 の規定は矛盾しているように思えますが、それは重箱の隅ということにしておきましょうか。

[205] >>196 では DOCTYPE も version もなければ HTML+RDFa 1.1 としており、 >>199 では version がなければ RDFa 1.1 の最新版としており、これが同じものなのかどうか不明です。そもそも RDFa 1.1 の最新版とは何を指すのか不明です。

[206] DOCTYPE と version が矛盾している時にどう処理するべきかは不明です。

[200] こちらもやはり猿パッチしまくっています (>>149)。 XHTML+RDFa (>>153) よりも悪化しています。

猿パッチ

[208] 猿パッチは次の通りです >>188。

[209] >>29 でIRI写像が上書きされるときには処理器グラフに警告 rdfa:PrefixRedefinition を生成しなければなりません。
[210] >>34 の直後で property 属性と rel 属性と rev 属性の一方または両方があれば、 CURIE でも URI でもない rel と rev の値は無視します。その結果 rel や rev が空になれば、その属性がなかったものとして扱わなければなりません。
[211] >>35 と >>61 で資源属性 (about, href, resource, src など) がなく、要素が head か body なら、新主語を親目的語に設定します。
[212] >>92 で現在特性値を生成するにあたり、 content 属性がなければ次のようにしなければなりません。
- [213] datetime があれば、リテラル値をその属性値とします。
- [214] datatype があれば、 RDFa の規定の通りに使います。
- [215] datatype がなく datetime が xsd:duration, xsd:dateTime, xsd:date, xsd:time, xsd:gYearMonth, xsd:gYear のいずれかに一致するなら、それをデータ型とします。
- [216] そうでなければ平リテラルとします。このとき現在言語を使います。
[217] >>92 で time 要素であって datetime も content もないなら、 datetime 属性が要素のテキスト値を含んでいるものとして扱わなければなりません。
[218] >>95 の直後で datatype が http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML に評価されるなら、 HTMLリテラルの値はすべての子供節点をテキストに直列化して作った文字列とします。

[219] >>209 は HTML+RDFa でのみ規定する必要性が感じられませんが、なぜ RDFa Core 1.1 でなく HTML+RDFa で追加されているのか謎です。

[220] >>210 は HTML の本来の rel 属性と衝突することを防ぐためでしょうが、 HTML で問題になるなら XHTML+RDFa でも問題だったはずで、なぜ XHTML+RDFa だけ追加されているのか謎です。

[221] >>212 や >>217 は time 要素を自然に利用する方法として有用でしょうが、なぜ time 要素でだけ特別な仕組みが追加され、 meter 要素や input 要素や img 要素で HTML の要素の意味に応じた特別な仕組みが追加されていないのか謎です。

[222] >>215 は RDF 側が XML Schema のデータ型を使っていることからこのような規定になっているのでしょうが、 time 要素の内容や datetime 属性の値の定義は厳密にはこれと一致しません。 HTML5 の処理モデルに従って解釈した値を XML Schema に適合する形で直列化したものをリテラル値として使うのではなく、このようなアドホックな HTML の解釈を求めるのは不適切でしょう。また「リテラル値」や「テキスト値」や「テキストに直列化」といった用語の意味は推測はできますが、正確さに欠けています。

[223] >>212、>>217、>>218 は W3C Process 上の理由により規定でなく参考とされています。 (HTML+RDFa 1.1 の項を参照。) ですからこの部分の規定には従わなくても適合することになりますが、本当にそれでいいのでしょうか。

[244] IRI写像の処理 (>>30) では、本来の名前空間属性を処理した後、null名前空間で局所名が xmlns: ではじまるものを名前空間属性であったものとみなして処理します >>242。

XML への変換

[229] HTML+RDFa 1.1 でデータ型が XMLLiteral のとき、次のようにして XML に変換しなければなりません >>188。

[231] 入力データがテキストのみならこれらの要件は適用しません。
[230] HTML5 の DOM からXML情報集合への変換規則に従って変換します。
- [243] ただしHTML文書の xmlns:* 属性 (本来名前空間属性ではなく未知の属性として扱われるもの) は XMLNS名前空間に属する名前空間属性とみなしてXML情報集合に変換します。 >>242
[234] 活性名前空間の情報を現在評価文脈のIRI写像から取り出し、最上位の要素に (既存の名前空間を上書きしないようにしつつ) 含めます。このとき接頭辞は小文字とします。
[232] 名前空間整形式の XML 1.0 とします。
[233] この変換過程で誤りや例外が発生したら、この XMLLiteral が含まれる三項組は生成しません。

[237] >>230 は HTML5 側で実装依存の項目がいくつかありますが、どのオプションを使うかは特に言及されていません。

[235] >>234 で大文字を小文字に変換するようですが、どの変換方法かは明記されていません。

[236] >>234 では元々 xmlns で宣言されていたものだけでなく、 prefix で宣言されていたものも xmlns として出力するようです。本当に大丈夫なのでしょうかね。

[238] 入力が構文解析直後の文書でなくスクリプトで変更された文書なら、大文字の名前空間接頭辞に依存した内容も含まれているかもしれませんが・・・。

[239] HTML要素では本来 xmlns 属性を指定しても無視されますが、 RDFa では HTML+RDFa の規定によりIRI写像に反映されます。それが >>234 により xmlns として出てくることになります。

XML 名前空間

[241] この他に HTML における xmlns の解釈に関するびっくりする規定があります。 xmlns の項を参照してください。

Role

[245] RDFa と同じく XHTML2 から独立した XHTMLモジュールの1つである Role Attribute 1.0 仕様書は、 role 属性に関する RDFa処理器が行う処理を定義しています。

[256]

RDFa Core 1.1 が参照されています。

[246] Role Attribute 1.0 (2013-03-29 00:13:26 +09:00 版) http://www.w3.org/TR/role-attribute/#using-role-in-conjunction-with-rdfa

[247] RDFa処理器は role 属性を組み込んだホスト言語の文書を処理する場合、 role 属性から三項組を生成して構いません。その場合次のようにしなければなりません。 >>246

[252] role に含まれる値それぞれを目的語とした三項組を生成する
- [253] 語彙 http://www.w3.org/1999/xhtml/vocab# の範囲内にあるものとみなす
[248] 主語は、
- [249] id があれば、文書の基底URLに # と id 属性値を連結したもの
- [250] そうでなければ新しい bnode
[251] 述語は、語彙 http://www.w3.org/1999/xhtml/vocab の語である role

[254]

xml:base は無視されるようです。また id が URL に使えない文字を含んでいても気にしないようです。

[255] こんな風にホスト言語依存で追加の三項組を生成しちゃうのはありなんでしょうか。 RDFa の実装にも Role の実装にもこの処理の追加を要求しておらず、あくまで認めているだけなので、ある文書がどんなグラフを生成するかまったく予測できないことになりますが・・・。

初期文脈

[158] RDFa Core 1.1 は初期文脈として http://www.w3.org/2011/rdfa-context/rdfa-1.1 を使っており、 XHTML+RDFa 1.1 は追加の初期文脈として http://www.w3.org/2011/rdfa-context/xhtml-rdfa-1.1 を使っています。これら URL は RDFa Core 1.1 と XHTML+RDFa 1.1 でそれぞれ URL のみ規定されていて、その内容は随時更新されているようです。

仕様書

[156] RDFa Core Initial Context (2013-11-28 00:07:18 +09:00 版) http://www.w3.org/2011/rdfa-context/rdfa-1.1
[157] XHTML+RDFa Initial Context (2011-12-10 18:34:41 +09:00 版) http://www.w3.org/2011/rdfa-context/xhtml-rdfa-1.1

内容

[159] >>156 には RDF 界隈でよく使われる接頭辞と名前空間URLの対応関係が定義されています。

[160] >>156 と >>157 では語termが定義されています。元々 rel 属性として使われていたものが選ばれているようです。

[161] 現時点で >>156 には describedby、 license、 role が、 >>157 には HTML4 のリンク型と meta, license, icon, p3pv1 が含まれています。

[163] なぜか license は両方に含まれています。 >>156 は XHTML Vocabulary と IANA登録簿の両方を参照しており、 >>157 は XHTML Vocabulary だけを参照しています。両者が同じものなのかどうか、重複していて問題ないのかどうかは不明です。

[162] どちらも W3C の文書で定義されているものという一応の基準はあるようですが、どのような手続きで追加されるのか、どういう基準で振り分けられているのかなどは不明です。ほとんどの値は出典が XHTML Vocabulary になっていますが、そこに含まれているすべてが >>156 と >>157 にも含まれているというわけでもありません。

GRDDL

[164] RDFa と GRDDL は直接関係ありませんが、 http://www.w3.org/2011/rdfa-context/xhtml-rdfa-1.1 を head 要素の profile 属性に指定することで、GRDDL 的に RDFa から RDF に変換できるようになるとされています。

HTMLメタ情報プロファイルの項も参照。

[165] XHTML+RDFa 1.1 - Second Edition (2013-08-15 17:11:45 +09:00 版) http://www.w3.org/TR/2013/REC-xhtml-rdfa-20130822/#a_deployment

[9] Some minor changes on the RDFa context document (Ivan Herman著, 2017-01-05 23:51:15 +09:00) https://lists.w3.org/Archives/Public/public-rdfa/2017Jan/0000.html