RDF/XML構文の簡単な説明

ノード要素の生成規則

RDFは主語となるリソースについての記述なので、（ルートのrdf:RDF要素の次のレベルは）主語を示すノード要素で始まります。単純化したノード要素の文法は、次のようなものです。

<nodeElt ((rdf:ID|rdf:about|rdf:nodeID)="S")? propertyAttr*>
 propertyEltList
</nodeElt>

つまり、nodeEltで表されるノード要素は、主語Sを示すrdf:IDもしくはrdf:about属性（nodeIDは空白ノードとなる特別なID）を0もしくは1つと、任意の数のpropertyAttr（プロパティ属性）を持ち、子要素にpropertyEltList（プロパティ要素リスト）を含む、というものです。抽象的でやや分かりにくいと思いますが、例を挙げながら、ここからモデルを導くルールを説明します。

プロパティ要素の生成規則

ノード要素の内容となるpropertyEltList（プロパティ要素リスト）は、アークを示すプロパティ要素の0回以上の繰り返しで構成されます。親ノードの主語に対する述語となるのは、これらプロパティ要素の要素型名（QName）です。目的語を含むモデルは、以下の生成規則によって与えられます（以下の例で、外側のrdf:Description要素は、プロパティの主語を与えるための親ノード要素です）。

[P1] リソースプロパティ要素

内容に前節のノード要素を含むものは、そのノードが目的語となります。基本的なストライピングの構文です。

（例）

<rdf:Description rdf:about="urn:pin:MK705">
 <ex:homePage>
  <rdf:Description rdf:about="http://kanzaki.com">
  </rdf:Description>
 </ex:homePage>
</rdf:Description>

この例では、ex:homePageが述語になっています。ここからは、親ノード要素のs.URIを主語とし、子ノード要素のs.URIを目的語とした、次のグラフが導かれます。

ノード要素にプロパティ属性があったり、子要素にプロパティ要素があれば、前節の規則に従い、さらにグラフは伸びていきます。

※ここでもしプロパティ要素ex:homePageにrdf:ID属性が与えられると、ノード要素のrdf:bagID属性（[N5]）と同様、文全体が具体化されます。とりあえず、詳細は略します。

[P2] リテラルプロパティ要素

要素内容がリテラル（文字列）であるプロパティ要素からは、その内容を目的語とし、[N3]と同様のリテラルノードが導かれます。

（例）

<rdf:Description rdf:about="urn:isbn:4-8399-0454-5">
 <dc:creator>KANZAKI, Masahide</dc:creator>
</rdf:Description>

[P3] リテラルパース型プロパティ要素

属性parseType="Literal"を持つプロパティ要素は、要素内容をリテラルとして扱い、RDFではそれ以上のパース対象としません。目的語に何らかの別のマークアップを含める場合などに使うことができます。

（例）

<rdf:Description rdf:about="urn:isbn:4-8399-0454-5">
 <dc:creator rdf:parseType="Literal">
  <h:ruby>
   <h:rb>神崎正英</h:rb><h:rt>かんざきまさひで</h:rt>
  </h:ruby>
 </dc:creator>
</rdf:Description>

dc:creator要素の内容は、タグも含めてそのまま文字列として扱われ、リテラルノードになります。アプリケーションは、このマークアップを利用した（ルビを振るなどの）独自の処理が可能です。

〔補足〕

ここで、parseType="Literal"属性を指定しなかった場合、内容はノード要素と解釈され、[N1]からこのノードはh:rubyという「型」を持ち、さらにその内容であるh:rt、h:rb要素は[P2]リテラルプロパティ要素として扱われ、結果的に次のような全く異なるモデルが生成されてしまいます。

〔以上補足〕

RDFではparseType属性の値としてはLiteral、Resource、Collectionの3つが定義されており、それ以外の値が出現した場合は、Literalと同じ扱いになります（OWLに合わせ、有限リストを表現するparseType="Collection"が追加されることになっています）。

[P4] リソースパース型プロパティ要素

属性parseType="Resource"を持つプロパティ要素は、要素内容をノード要素ではなくプロパティ要素として扱います。

（例）

<rdf:Description rdf:about="urn:isbn:4-8399-0454-5">
 <dc:creator rdf:parseType="Resource">
  <ex:name>KANZAKI, Masahide</ex:name>
  <ex:email>webmaster@kanzaki.com</ex:email>
 </dc:creator>
</rdf:Description>

プロパティ要素の中に“子プロパティ要素”が直接出現すると、（ノード要素がないため）アークが連続してしいます。そこで、ここに空白ノードを生成し、“子プロパティ要素”をそのプロパティとしてモデルがつくられます。

[P5] コレクションパース型プロパティ要素の目的語

通常、プロパティ要素の内容にはひとつのノード要素しか記述できません（アークの先にはひとつのノードしかない）が、属性parseType="Collection"を持つプロパティ要素は、内容に複数のノード要素を列挙できるようになります。rdf:Bagなどのコンテナモデルを使う場合と異なり、コレクションは列挙されるリストが有限であることを示します。

（例）

<rdf:Description rdf:about="urn:pin:MK705">
 <ex:homePage rdf:parseType="Collection">
  <ex:Site rdf:about="http://kanzaki.com"/>
  <ex:Site rdf:about="http://purl.org/net/kanzaki/"/>
 </ex:homePage>
</rdf:Description>

モデルはrdf:first、rdf:restというプロパティで、ひとつひとつのリストをつないでいくものです（2003-09-05の改訂で、少しシンプルになりました）。

このモデルは、OWLのクラス定義をowl:intersectionOf、owl:unionOfなど集合によって行う時などに使われます。

[P6] 空プロパティ要素の目的語

プロパティ要素に対応するノードは、要素内容ではなく属性としてまとめて記述することもできます。

rdf:resource属性でURIを指定すると、[P1]で子ノード要素のrdf:about属性で目的語を指定したのと同じモデルを得られます。

（例）

<rdf:Description rdf:about="urn:pin:MK705">
 <ex:homePage rdf:resource="http://kanzaki.com"/>
</rdf:Description>

[P7] 空プロパティ要素のプロパティ属性

さらに、空プロパティ要素で[N3]と同様のプロパティ属性を指定すると、この目的語についてのリテラル型プロパティまでを一度に記述することができます。

（例）

<rdf:Description rdf:about="urn:pin:MK705">
 <ex:homePage rdf:resource="http://kanzaki.com"
              dc:title="The Web KANZAKI"/>
</rdf:Description>

親要素（主語）ノードに別のプロパティを加えるのではなく、rdf:resource属性で示した目的語について、新たなモデルを追加することに注意してください。

rdf:resource属性がない場合は、空白ノードが生成され、[P4]と同様のモデルになります（P4の場合、rdf:resourceとrdf:parseType="Resource"を同時に指定できないので、必然的に空白ノードとなります）。ただし、P4ではリソースノードも生成できるのに対し、このプロパティ属性で生成できるのはリテラルノードのみです。