current element

Edit New

current element

[8] 本項は RDFa を解釈する側の処理方法について、仕様書をできるだけ好意的に解釈しようと試みるものです。 RDFa の仕様書は 00年代 W3C レベルの品質でしか無いので、 相互運用可能なレベルで実装できる程度に理解するのは難しいです。

目次

  1. RDFa 処理器 (RDFa 1.0)
    1. 仕様書
    2. 要件
    3. 許可
    4. 関連
  2. RDFa 処理器 (RDFa 1.1)
    1. 仕様書
    2. 出力
  3. 適合 XHTML+RDFa 1.0 利用者エージェント
    1. 仕様書
    2. 要件
    3. 関連
    4. メモ
  4. 適合 XHTML+RDFa 1.1 利用者エージェント
    1. 仕様書
    2. 要件
    3. 関連
  5. HTML+RDFa 処理器と利用者エージェント
    1. 仕様書
    2. 要件
  6. RDFa 1.1 処理モデル
    1. 評価文脈
    2. 処理
  7. XML+RDFa 文書
  8. XHTML+RDFa 1.1 文書
  9. HTML+RDFa
    1. 猿パッチ
    2. XML への変換
    3. XML 名前空間
  10. Role
  11. 初期文脈
    1. 仕様書
    2. 内容
    3. GRDDL

RDFa 処理器 (RDFa 1.0)#✎

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

仕様書#✎

要件#✎

許可#✎

関連#✎

[6] 適合RDFa利用者エージェントとの関係は明示されていません。

[240] HTML+RDFa 仕様書は、 XHTML+RDFa 1.0 が text/html で提供されることがあるとして、 text/html であるにも関わらず xmlns 属性を処理する方法と適合性をなぜか規定しています。

RDFa 処理器 (RDFa 1.1)#✎

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

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

仕様書#✎

出力#✎

[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 利用者エージェント#✎

仕様書#✎

要件#✎

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

関連#✎

[170] 適合RDFa処理器というクラスが別途定義されています。その関係は明示されていません。

メモ#✎

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

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

仕様書#✎

要件#✎

関連#✎

[175] RDFa処理器との関係はやはり不明確です。 RDFa Core 1.1 の実装が RDFa処理器、 XHTML+RDFa 1.1 の実装が利用者エージェントと呼ばれているようですが・・・。

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

仕様書#✎

要件#✎

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

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

[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] 初期文脈は次のように定義されています。

[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。

  1. [24] 次の通り初期化します。
  2. [26] 現在要素の vocab 属性の値があれば、それを解決して局所既定語彙とします。空なら、ホスト言語によって規定された既定値 (または null) とします。
    1. [28] 値があれば (基底, http://www.w3.org/ns/rdfa#usesVocabulary, 局所既定語彙) の三項組を生成します。
  3. [29] 現在要素でIRI写像が定義されていれば、IRI写像の局所リストに追加します。既に同名のものがあれば上書きします。
    1. [30] xmlns 宣言があれば、名前空間接頭辞を接頭辞、属性値を IRI とするべきです。
      • この手順はべきレベルであり、必須ではないようです。
    2. [31] prefix 属性があれば、そこにある接頭辞と IRI の組を最初から最後の順で処理していきます。
  4. [34] 現在要素から言語を設定します。ホスト言語はこの方法を定義して構いません。
    • 定義されていないときは好きにしていいのでしょうか...?
    • XML+RDFa では xml:lang 属性を使っています。
  5. [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 属性があれば、型付き資源を新主語の値とします。
  6. [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 がなければ、型付き資源を現在目的語資源とします。
  7. [74] >>35 か >>61 で型付き資源が null 以外に設定されたなら、
    1. [75] typeof から得られた IRI それぞれについて、三項組 (型付き資源、 rdf:type、 IRI) を生成します。
  8. [76] ここまでで新主語が null 以外かつ親目的語以外に設定されていれば、 評価文脈のリスト写像を新しい空の写像に置き換えます。
  9. [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, 新主語) を追加します。
  10. [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 とします。
  11. [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, 現在特性値) を生成します。
  12. [110] 要素を飛ばすフラグが偽で新主語が null 以外なら、
    1. [111] 評価文脈の不完全三項組のリストの不完全三項組それぞれについて、
      1. [112] 「方向」が無しなら、「リスト」に新主語を追加します。
      2. [113] 「方向」が正なら、三項組 (親主語, 「述語」, 新主語) を生成します。
      3. [114] 「方向」が逆なら、三項組 (新主語, 「述語」, 親主語) を生成します。
  13. [115] 子要素それぞれについて、新しい評価文脈を使って再帰的に処理します。
    1. [116] 要素を飛ばすフラグが真なら、現在の評価文脈を複写して、言語とIRI写像のリストを現在言語とIRI写像の局所リストに置き換えます。
    2. [117] そうでないなら、次のようにします。
  14. [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。

[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。

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

HTML+RDFa#✎

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

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

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

[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。

[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。

[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 が参照されています。

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

[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 のみ規定されていて、 その内容は随時更新されているようです。

仕様書#✎

内容#✎

[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メタ情報プロファイルの項も参照。

[9] Some minor changes on the RDFa context document (Ivan Herman著, ) <https://lists.w3.org/Archives/Public/public-rdfa/2017Jan/0000.html>

Updated:

Google search: current element

三