RDF/XML シンタックス仕様書 (改訂版)

W3Cワーキングドラフト2002年3月25日

この版:

http://www.w3.org/TR/2002/WD-rdf-syntax-grammar-20020325

最新版:

http://www.w3.org/TR/rdf-syntax-grammar

旧版:

http://www.w3.org/TR/2001/WD-rdf-syntax-grammar-20011218

編集者:

Dave Beckett (University of Bristol)

Copyright ©2002 W3C^® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

要旨

本仕様書は、リソースディスクリプションフレームワーク(RDF)用のXML構文を定義するものである。本構文は、RDFモデルとシンタックス仕様書に記述されていたものをRDFコアワーキンググループが不足部分を補足し、曖昧な部分を明確にして作成したものである。XML Baseの新しいサポートでXML情報セットに関して指定するためにこのシンタックスを更新した。RDFモデル理論で定義されているように、シンタックスの各部分ではRDFグラフを作成するためのマッピング規則を記述している。これは、N-トリプルグラフシリアライズ化テストを使用することによって定義できる。N-トリプルグラフシリアライズ化テストを使用すると、機械が処理しテストできる形式でより正確にマッピングの記録を行うことができる。こういったテストを収集し、RDFテスト事例で公開している。

本文書の位置付け

本書は、W3C のセマンティックWebアクティビティ (アクティビティステートメント)の一環として作成された RDFコアワーキンググループのワーキングドラフトのひとつである。 本文書は、本ドラフトにあるXML Base [XML-BASE]の新しいサポートを含み、最初RDFモデルとシンタックス文書にXML情報セット [INFOSET]を重ね合わせるべきと言う、当該ワーキンググループの決定に基づいたものである。

本書は、特に変更を行うと現行の実装やコンテンツにどのように影響するかということに関してフィードバックやコメントを推奨するため、W3Cワーキンググループとその他関連機関のレビュー用にリリースされたものである。現在の状況として、オリジナルの文書のgrammar section（文法の節）で記述しているように、本書は、オリジナルの文書からいくつかの部分を削除した（rdfms-abouteachを参照のこと）ものの、シンタックスの大部分を記述していることと、RDFグラフへのマッピングが完成したと考えられる点があげられる。旧版である2001年12月のドラフトからの変更の詳細は、変更点の節に記載しているが、主な変更点は次のようになっている。rdf:bagIDのグラフ作成のための規則の完成、リテラルでのxml:langの処理、XML リテラルの処理 (完成はしていない)、 XML Baseサポートの追加、前ドラフト以降にRDFコアワーキンググループが行った決定 の後の新しい例やその他変更を加えての序論部分の更新。

本書は、公開のW3Cワーキンググループのドラフトであり、 他の仕様書によりいつでも改版・置換・陳腐化の可能性がある。 W3Cワーキングドラフトを標準文書として使用したり"作業中"以上のものとして引用することは不適切である。現在のW3C勧告とその他の技術ドキュメントのリストは http://www.w3.org/TR/を参照されたい。

本書のコメントは公的メーリングリストwww-rdf-comments@w3.orgへお願いしたい。コメントの記録はhttp://lists.w3.org/Archives/Public/www-rdf-comments/で参照できる。

1 序論

本書は、RDFモデルとシンタックス [RDF-MS] W3C勧告で本来、定義されていたRDFのXML [XML]シンタックスについて記述している。 この構文の今後の実装とその結果のRDFグラフを比較すると次の様に言うことができる。 以前のものは曖昧さが有った、この為、異なるグラフに基づいた色々な実装がされていた為、固定的な構文形式で広く実装されることが無かった。 これらの問題は、www-rdf-comments@w3.org (アーカイブで指摘され、RDF Interest Groupで議論されて来た。 RDF関連グループリストの議論の履歴は、www-rdf-interest@w3.org (アーカイブを参照されたい。

RDFコアワーキンググループは、RDFの抽象グラフとXML構文の仕様書の問題を修正し、曖昧なものを明確にし、改善する必要性に答える事とチャータに定められている。

文法への修正や削除を含む決定の一部は、以下で参照できる。 最終的な決定は、RDFコアワーキンググループの問題のリストに記録されている。

本書では、空白の要素の特定な形式などのより低いレベルの内容から移行したXML情報セット [INFOSET]に関するオリジナルのEBNF文法について再記述している。そうすることによって、文法はより正確に記録でき、XMLシンタックスからのRDFグラフへのマッピングをよりわかりやすく示すことができる。RDFグラフへのマッピングは、RDFテスト事例 [RDF-TESTS] ワーキングドラフトのN-トリプル節に定義されている形式からステートメントを削除することで可能である。N-トリプルとは、RDFモデル理論 [RDF-MODEL]ワーキングドラフトで定義しているセマンティックを持つRDFグラフを作成するものである。

本書はXMLからN-トリプルを作成する一つの方法を述べている。つまり、結果として同じN-トリプル(RDFグラフ)となる別の方法が使用できるということである。

特に、以下のことが言える：

• N-トリプルはどんな順番ででも作成することができる。
• どの時点でも、複製を削除できる。
• どの方法においても、N-トリプルに対応するための必要条件はない。

2 RDFのXMLシンタックス

RDFモデル理論 [RDF-MODEL] では、正式にRDFを記述している。 これは、ノード、および、 アークで構成されるグラフとして考えることができる。ノードは、URLやリテラルで標示付けできるか、または、空白にしたり、リソースを示したりできる。アークはノードを接続し、すべて、URIで標示付けされる。このグラフは正確には、端に方向付けられた標示付きのグラフとばれている。端は各々、二つのノードを接続している有向アーク（矢印）である。これらの端は、矢印/アークの終わりの鈍い部分では、サブジェクトノードのトリプルとして記述することができ、鋭い部分では、プロパティアークおよび、オブジェクトノードとして記述することができる。また、プロパティアークは、二つのリソース間の関係、または、いくつかのリソースのサブジェクトノードに対する属性の値（オブジェクトノード）の定義としても解釈できる。

グラフをXMLで符号化するためには、ノードとアークがXMLの要素、属性要素コンテンツ、属性値に変換される。プロパティやオブジェクトノードのURLラベルはXMLネーム空間 [XML-NS]を使用してXMLに書きこまれる。XMLネーム空間[XML-NS]は、ローカル名というネーム空間で認められた要素名と属性名を伴った短い接頭語のネーム空間URIを提供する。 ネーム空間とローカル名を連結させてオリジナルのノードURIを形成できるように、（ネーム空間とローカル名の）この一組が選択される。サブジェクトノードとオブジェクトノードを標示付けしているURIは、XML属性値に格納される。文字列リテラルで標示付けされているノードは（通常、オブジェクトノードである）要素テキストコンテンツ、または、属性値に変わる。

この変換によって、”ノード、アーク、ノード、アーク、ノード、アーク”の形式のグラフのパスを、要素の中にある要素順に変換する。そうすることによって、要素が書き込まれる際、ストライプ状になる。つまり、ノード要素とプロパティ要素が交互になのである。その並びの始めにあるノードは通常、サブジェクトノードであり、RDF/XMLの一番上で、XML文書の要素(この場合、rdf:RDF)の下に書き込まれるrdf:Descriptionという包含要素に変わる。そのため、ストライプ状の連鎖はRDF/XMLの一番上から開始し、ノードで始まる。

例えば、ASCIIで記述された図1では、"RDF/XMLシンタックス仕様書（改訂版）"というタイトルの文書（本文書のこと）があり、その文書には編集者がおり、その編集者の名前は"Dave Beckett"で、ホームページはhttp://purl.org/net/dajobe/である、ということを示している。

図1:RDF/XMLのグラフの例 (SVG版)

ノードが楕円で書かれ、URLがわかっている場合にそのURLが記述されている場合、”編集者がいる”などのプロパティは、URLで示され、相当するアークを標示付けするのに使用される。そして、文字列は 長方形の中に書き込まれる。

図2図2のグラフのパスの場合:

図2: グラフのパス (SVG版)

これは、以下のノード/アークのストライプ状に相当する：

1. ノード [http://www.w3.org/TR/rdf-syntax-grammar]
2. アーク -[http://example.org/stuff/1.0/editor]->
3. アーク []
4. アーク -[http://example.org/stuff/1.0/homePage]->
5. ノード [http://purl.org/net/dajobe/]

RDF/XMLでは、このノードとアークの五つの並びは、例1で示している5 XML要素に相当する：

URIがわかっていて、記入することができるノードと空白のままにするノードで構成する場合は例2の様になる:

<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
  <ex:editor>
    <rdf:Description>
      <ex:homePage>
        <rdf:Description rdf:about="http://purl.org/net/dajobe/">
        </rdf:Description>
      </ex:homePage>
    </rdf:Description>
  </ex:editor>
</rdf:Description>

より簡単に記入することのできる省略形がいくつかある。複数のプロパティと値で同じリソースを同時に記述することは、標準的なことなので、複数のプロパティと値を持つ複数の子要素をrdf:Descriptionに入れることができる。 これらすべては、例3で示しているように、ノードのプロパティである。 (ここでは、上記のグラフにはないdc:formatを追加している）:

<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
  <dc:title>RDF/XML Syntax Specification (Revised)<dc:title>
  <dc:format>text/html<dc:format>
    ...
</rdf:Description>

プロパティ値が文字列の場合、XML属性やXNL値、ノード要素の属性としてより簡単に符号化できる。これをプロパティ属性といい、例4で示している:

<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
                 dc:title="RDF/XML Syntax Specification (Revised)"
                 dc:format="text/html">
  ...
</rdf:Description>

一般的な使用をもう一つあげると、ノードがrdf:type関係を持つクラスのインスタンスの場合の typedノードがある。 例5 (上記とは異なるグラフを使用している）のように、rdf:typeプロパティと値を削除し、rdf:Description要素名をtype関係の値のURIに相当するネーム空間の要素に置き換えることでこの省略表現を作成することができる:

<rdf:Description rdf:about="http://example.org/thing">
  <rdf:type rdf:resource="http://example.org/stuff/1.0/document"/ >
  ...
</rdf:Description>

<ex:document rdf:about="http://example.org/thing">
  ...
</ex:document>

上記では、RDF/XMLシンタックスの基礎を形成しているが、RDFリストプロパティの作成や空白の要素ノードの書き込みの省略などを含む省略形など、ここで述べていないものもある。後者はストライプ状を壊してしまうが、ユーザにとっては、複数の値を持つプロパティを符号化するのに便利である。

上記の例は、例6の省略形をいくつか使用して、記入/完成する:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://example.org/stuff/1.0/">
  <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
    <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
    <ex:editor rdf:parseType="Resource">
      <ex:fullName>Dave Beckett</ex:fullName>
      <ex:homePage rdf:resource="http://purl.org/net/dajobe/" />
    </ex:editor>
  </rdf:Description>
</rdf:RDF>

履歴的な観点における、より長いRDF/XML ストライプ状のシンタックスについては、RDF: Understanding the Striped RDF/XML Syntax [STRIPEDRDF]を参照のこと。

3 データモデル

本シンタックスは、ノードの順番として、3.2節情報セットマッピングで定義している文書順という順序に並べてある[XPATH]  情報セットマッピングの形で文書順にXML文書で機能する。結果としてできたノードを[SAX2] XML APIで作成したイベントに似たようにするつもりである。このモデルは単なる概念上のものであり、実装方法を押し付けるものではない。特に、 [XPATH] や、[SAX2]は必須ではない。

シンタックスは不完全なXML文書には対応していないし、XML情報セットのない文書にも対応していない。例えば、XMLネーム空間 [XML-NS]に準拠していない文書には対応していない。

Infosetには、下記の情報項目プロパティ[base URI]を発生するXML Base [XML-BASE]のサポートが必要である。 このプロパティをRDF/XMLで使用することに関しては、 3.6節で述べている。

本仕様書には、[INFOSET]で定義しているような情報セットが必要である。この[INFOSET]は、RDF/XML用の最低以下の情報項目とプロパティに対応している。

Document Information Item(文書情報項目) >

[document element], [children], [base URI]

Element Information Item(要素情報項目)

[local name], [namespace name], [children], [attributes], [parent], [base URI]

Attribute Information Item（属性情報項目）

[local name], [namespace name], [normalized value], [owner element]

Character Information Item（文字情報項目）

[character code]

Processing Instruction Information Item（処理指示情報項目）

未使用

Unexpanded Entity Reference Information Item（未展開のエンティティ参照情報項目）

未使用

Comment Information Item（コメント情報項目）

未使用

Document Type Declaration Information Item（文書タイプ宣言情報項目）

未使用

Unparsed Entity Information Item（未解析エンティティの情報項目）

未使用

Notation Information Item（表記法情報項目）

未使用

Namespace Information Item（ネーム空間情報項目）

未使用

3.1 ノード

以下の小節では、6つの種類のノードを定義している。（識別子以外の）ほとんどのノードがInfoset情報項目で構成されている。 ノードの構成での効果として、一意の一致で新しいノードを作成し、ノードを識別することがあげられる。ノードにはプロパティがあり、すべてにノードの一部であるか、または、含まれているノードのstring-valueから計算されたstring-valueプロパティがある。

3.1.1 ルートノード

ルートノードは、Document Information Item（文書情報項目）から作成され、その要素情報項目から以下のプロパティと値をとる。それは、document-element, childrenそして、base-uri。プロパティ言語は、空の文字列に設定される。

3.1.2 要素ノード

要素ノードは、Element Information Item（要素情報項目）から作成され、 その要素情報項目から以下のプロパティと値をとる。それは、local-name, namespace-name, children, attributes, parent そしてbase-uri。このノードが前述の値から作成されると、URIプロパティは、 namespace-nameの値とlocal-nameプロパティの値が連結した文字列の値で定義される。作成時にli-counterプロパティとbag-li-counterプロパティは、初期整数1で追加される。

要素ノード作成時に、 ‐attributes‐プロパティに属性ノード xml:lang (つまり、その属性のlocal-nameプロパティには、値"lang"があり、namespace-nameプロパティには、値"http://www.w3.org/XML/1998/namespace"がある)が含まれていると、その属性は属性のリストから削除され、その要素ノードのプロパティ ‐language‐ はその属性の文字列値に設定される。このような属性が存在しない場合、要素ノードのlanguageプロパティは親ノードの languageプロパティの値に設定される。
xmlで始まるノードはすべて削除される（つまり、"http://www.w3.org/XML/1998/namespace"で始まるnamespace-nameプロパティ値）注: base-uriプロパティのようにInfosetにすでに存在するxml:baseはこのノードには含まれない。

subjectプロパティは追加することができるし、識別子ノードの値をとることもできる。また、通常ステートメントのサブジェクトであり、RDFグラフの一つのノードに対応する要素で使用される。

3.1.3 End要素ノード

プロパティを全くとらないが、順序の中の包含要素の最後を示す。

3.1.4 属性ノード

属性のノードは、Attribute Information Item（属性情報項目）から作成され、local-nameプロパティ、namespace-nameプロパティ、所有者要素およびそれぞれの要素情報項目プロパティからのそれぞれの値をとる。前述の値からこのノードが作成されると、プロパティと値が二つずつ定義される。 [XML]で定義しているように、最初に string-valueプロパティが、規格化した値で定義される。規格化された値の長さがゼロの文字列である属性は、特別な扱いを受けない。つまり、結果として、長さがゼロの文字列値を持つ属性ノードになる。次に、namespace-nameプロパティの値とlocal-nameプロパティの値が連結した文字列値で、‐URI‐プロパティが定義される。

3.1.5 テキストノード

テキストノードは、一つ以上の連続したCharacter Information Items（文字情報項目）から作成され、各文字情報項目のcharacter code（文字コード）を連結させることによって作成された文字列の値を持つ単一のプロパティ ‐string-value‐を持つ。 [注意: XPathと同一である。]

3.1.6 識別子ノード

識別子ノードとは、以下の三つのプロパティを持つことのできるtyped識別子のことである。そのプロパティとは、‐identifier‐、‐identifier-type‐、そして、‐string-value‐である。これらのノードは、‐identifier‐ プロパティと ‐identifier-type‐プロパティに値を入力することによって作成される。 identifierプロパティは、文字列値をとり、identifier-typeプロパティは値、 "URI"または、"bnodeID"をとる。

‐string-value‐プロパティは、次のように、他のプロパティから定義される。： ‐identifier-type‐が "URI" の場合、値は、"<"と‐identifier‐プロパティの値と、 ">"の連続となる。 ‐identifier-type‐が "bnodeID" の場合、値は "_:"と ‐identifier‐プロパティの値の連続となる。

RDFグラフの識別に関しての詳細は、3.5節を参照のこと

3.1.7 リテラルノード

リテラルノードとは、以下の三つのプロパティを持つことのできるリテラルのノードのことである。そのプロパティとは、literal-value、literal-language、そして、‐string-value‐である。これらのノードは、どちらも文字列値をとる ‐literal-value‐プロパティと‐literal-language‐プロパティに二つの値を入力することによって作成される。

‐string-value‐プロパティは、次のように他のプロパティから定義される。‐literal-language‐が空白の場合、値は "" (二重引用符が一つ)と‐literal-value‐プロパティの値と、"" (二重引用符が一つ)の連続となる。 そうでない場合、値は、""" (二重引用符が一つ)と‐literal-value‐プロパティの値と、""-" (二重引用符が一つと'-'が一つ)と‐literal-language‐プロパティの値の連結となる。 二重引用符がついたliteral-valueの文字列は、 "などのような特定の文字を拡張するためのN-トリプルstring escapes（拡張文字） を使用する必要があることに注意。

3.1.8 XMLリテラルノード

XMLリテラルノードとは、次の三つのプロパティを持つことのできるXMLリテラルのノードである。そのプロパティとは、 ‐literal-value‐、‐literal-language‐、そして、‐string-value‐である。これらのノードは、どちらも文字列値をとる‐literal-value‐プロパティと‐literal-language‐ プロパティ に二つの値を入力することによって作成される。

‐string-value‐プロパティは次のように、他のプロパティから定義される。： ‐literal-language‐が空白の場合、値は、"xml"" ('x'、'm'、'l'、そして、二重引用符が一つ)と ‐literal-value‐プロパティの値と""" (二重引用符が一つ)の連結となる。それ以外の場合、値は、"xml"" ('x'、'm'、'l'、そして、二重引用符が一つ)、と‐literal-value‐プロパティの値と""-" (二重引用符が一つと'-'が一つ）と‐literal-language‐プロパティの値の連結となる。 二重引用符がついたliteral-value文字列は、"などのような特定の文字を拡張するためのN-トリプルstring escapes（拡張文字）を 使用する必要があることに注意。

3.2 情報セットマッピング

Infosetを文書順でノードの順序に変換するには、各情報項目を上記の様に変換してプロパティと値でノードのツリーを作成する。そして各要素ノードを下記のように置き換えてノードのツリーを文書順の順番に変換する。

1. オリジナルの 要素ノード
2. childrenプロパティの値、おそらく順番に並べられてノードの空のリスト。
3. end要素ノード

3.3 RDF MIMEタイプ、ファイルの拡張子、および、Macintoshのファイルタイプ

RDFのインターネットメディアタイプ/ MIMEタイプは、"application/rdf+xml" である。-RFC 3032 (RFC-3023) 8.18節を参照のこと。W3Cは、本ワーキングドラフトがより安定したら、このタイプを登録する予定である。

すべてのプラットフォームにおいて、RDFファイルには拡張子 ".rdf"（すべて小文字）をつけるこをお勧めする。

Macintosh HFSファイルシステムに保存されているRDFファイルには、 "rdf " (すべて小文字で、スペース文字を4番目にいれる)を使用することをお勧めする。

3.4 RDFネーム空間

RDFネーム空間のURIは、http://www.w3.org/1999/02/22-rdf-syntax-ns"#であり、他の接頭語が使用される場合もあるが、一般的には接頭語 rdfを使用してXMLで使用される。ネーム空間には以下の名前のみが含まれている。

RDF Description
ID about bagID parseType resource
li

上記の用語はシンタックスにのみ使用され、グラフの概念では使用されない。

Seq Bag Alt Statement Property
subject predicate object
type value
_n

n が、負の整数ではない場合、グラフには、RDFクラス(最初の5つ) または、プロパティ(残り) のどちらかがある。

その他の名前は定義されてなく、アプリケーションに障害が発生した場合は警告されるべきであるが、それ以外は普通に動作し、その使用に適したプロパティやクラスとして扱う必要がある。

本書にある用語 rdf:nameは、nameがRDFネーム空間からのものであり、RDFネーム空間URIとnameの連続のURIがあることを示すために使用される。例えば、rdf:typeには、URI、http://www.w3.org/1999/02/22-rdf-syntax-ns"#typeがある。

3.5 識別子

RDFグラフは、ノードとアークに対し以下の三つのタイプの識別子（または、ラベル）を使用する。

URI参照(ラベリングノードとアーク)

URI参照は、XMLネーム空間が認めた要素と属性名(QNames) 、または、rdf:ID属性値とrdf:bagIDreferences属性値から構成され、3.6節で述べているように、範囲内のベースURIに解決する必要のある絶対的なURI、または、相対的なURIのどちらかとして与えることができる

XML QNameは、ネーム空間URIとXMLローカル名を連結させることによって、URIを与える。例えば、XMLネーム空間の接頭語fooには、 URI　http://example.org/somewhere/ がある場合、QName foo:barは、URI　http://example.org/somewhere/barに相当する。これは、どのURIが作成され、作成されたそのURIをさまざまな方法で与えることができる、ということを制限することに注意。

rdf:ID値とrdf:bagID 値は、属性値と連結された相対的なURI""#"と一致しているとみなすことによって、URIを作成する。3.6節で述べているように、このことは範囲内のベースURIと相対したものに解決することができる。

リテラル(ラベリングオブジェクトのアーク)

ユニコード文字列、または、XMLコンテンツがある。

警告:RDFコアワーキンググループは、文字列のリテラルの処理方法の概略を決定したが、現時点では、すべての事例が解決しているわけではない。特に以下の問題について参照のこと。rdf-charmod-literals, rdfms-xml-literal-namespaces

空白のノード識別子(ラベリングノード)

これらの識別子は、N-トリプルの nameプロダクションと一致しなければならないN-トリプルシリアライゼーションのローカル識別子に与えられる。

注意:以前、RDFアプリケーションの中には、任意のURIを作成することによって空白のノード（そのため、匿名ノードといわれている）を処理するものもあった。そういうことはしてはいけない。つまり、アプリケーションは空白のノードからURI参照を区別できなければならないのである。

3.6 ベースURI

RDF/XMLは、 XML情報セット [INFOSET]に従って、XML Base [XML-BASE]をサポートし、 ‐ルートノード‐、および、‐要素ノード‐に‐base-uri‐プロパティを定義する。

RDF/XMLはURI-参照を使用し、範囲内のベースURIを適用し、"#frag"形式のURI文書参照と""形式の自己文書参照の両方を解決する。

同じ文書の空のドキュメント参照""は、ベースURIのURI部分に対して解決し、フラグメント部分は無視される。Uniform Resource Identifiers (URI) [URIS] 4.2節を参照のこと。

4 表記

4.1 用語

本書の"しなければならない"、"してはいけない"、"必須である"、"するものとする"、"しないものとする"、"すべきである"、"すべきでない"、"推奨する"、"してもよい"、そして、"任意で" は、RFC 2119 [KEYWORDS]で定義されているように解釈される。

4.2 文法の表記

ノードと文法EBNFを記述するために、以下の表記が使用される。RDF/XML文法は、情報セットノードに関して以下の形式のステートメントを使用して定義される。:

number node-type node-content

action...

N-triples

（3.1節で述べているように)下記の表に記載している形式の構造を使用してnode-content が他のnode-types を参照する表現の場合、番号は参照をするために使用される。action にモデルへのN-トリプルの作成を含んでもよい。

5 RDF/XML文法

5.0 文法の概要

5.1 文法の開始

RDF/XMLがスタンドアローンのXMLコンテンツの場合、文法はルートノード  docで開始する。

RDF/XMLが他のXMLコンテンツの中に組み込まれている場合などのように、文脈がコンテンツをRDF/XMLだと認識している場合、文法は、要素ノード  RDF(XMLにおいてその時点で要素が正当である場合にのみ）、または、 nodeElementList(これは要素のリストなので、要素コンテンツが正当である場合のみ）で始まる。このような組み込まれたRDF/XMLの場合、ルートノードが使用できなため、一番外側の要素の ‐base-uri‐の値は包含XMLから初期化されなければならない。そういった組み込みが発生した場合、文法は何回か入力できるが、状態は維持されないかもしれないということに注意。

5.2 プロダクションdoc

5.3 プロダクションRDF

5.4 プロダクションnodeElementList

5.5 プロダクションnodeElement

要素e の場合、子ノードやその他の属性の処理など他の作業の前に、属性のうちのいくつかの処理が行われなければならない。 その処理は以下のうちどの順番でも行うことができる。

• a.URI = rdf:ID属性を持つa がある場合、e subject := identifier(identifier=concat(e. base-uri, ""#", a. string-value), identifier-type="URI")
• a.URI = rdf:about a を持つa がある場合、e.subject := identifier(identifier=a. string-value, identifier-type="URI").
• e. subject が空の場合、ローカルの空白のノード識別子 i と n := identifier(identifier=i, identifier-type="bnodeID"). e subject := n を作成する。

以下はどの順番でも実行できる。

• S1 e.URI != rdf:Descriptionの場合、次のステートメントがモデルに追加される。

  e.subject.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns"#type> <e.URI> .

• S2 a.URI = rdf:typeを持つpropertyAttr に属性a が存在する場合、次のステートメントがモデルに追加される。

  e.subject.string-value <a.URI> <a.string-value> .

• S3属性a が(rdf:typeではなく) propertyAttrと一致する場合、 o := literal(literal-value=a.string-value, literal-language=e.language) および、次のステートメントがモデルに追加される。

  e.subject.string-value <a.URI> o.string-value .

• S4 文書順でpropertyEltList 子ノードを処理する。

a.URI = rdf:bagIDをもつ 属性a が存在する場合、n := identifier(identifier=concat(e.base-uri, ""#", a.string-value), identifier-type="URI") でありどの順番でもよい。

• S5次のステートメントをモデルに追加する。

  n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns"#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns"#Bag> .

• 上記で作成された(S5を除く)ステートメントは以下の順番となる。

  1. S1
  2. S2 およびS3 からの任意の順番のステートメント
  3. propertyEltList の子とS4 で作成した任意の順番の文書順のステートメント

  propertyElt からS4 でステートメントが作成され、既存の識別子e.subjectを持つ場合、 s := e.subjectとなる。 それ以外の場合は、ローカルな空白ノード識別子 i と s := identifier(identifier=i, identifier-type="bnodeID")を作成する。

  その後、 5.26節の具体化規則を使用してノードsでステートメントを具体化し、 5.28節のbag拡張の規則をノード n に適用してURI u を入力する。次のステートメントがモデルに追加される。

  n.string-value <u.string-value> s.string-value .

5.6 プロダクションws

5.7 プロダクションpropertyEltList

5.8 プロダクションpropertyElt

要素 e に e. URI = rdf:li がある場合、5.27節の要素e.parentにリスト拡張の規則 を適用して、新しいURI u とe.URI := u.を入力する。

5.9 プロダクションresourcePropertyElt

要素 e で、組み込まれた単一のnodeElement n の場合、 次のステートメントがモデルに追加される。

rdf:ID属性 a が与えられている場合、上記のステートメントは、i := identifier(identifier=concat(e.base-uri, ""#", a.string-value), identifier-type="URI")で 5.26節の具体化規則とe.subject :=i　を使用して具体化される

5.10プロダクションliteralPropertyElt

e とテキストノード t の場合、o := literal(literal-value=t.string-value, literal-language=e.language) と次のステートメントがモデルに追加される。

rdf:ID属性 a が与えられている場合、上記のステートメントは、i := identifier(identifier=concat(e.base-uri, ""#", a.string-value), identifier-type="URI") で、5.26節の具体化規則と e subject := i を使用して具体化される。

5.11 プロダクションparseTypeLiteralPropertyElt

要素 e とリテラル l の場合、o := xml(literal-value=l.string-value, literal-language=e.language) と次のステートメントがモデルに追加される。

rdf:ID属性 a が与えられている場合、上記のステートメントは、 i := identifier(identifier=concat(e.base-uri, ""#", a.string-value), identifier-type="URI") で、 5.26節の具体化規則と e.subject := i　を使用して具体化される。

5.12 プロダクション parseTypeResourcePropertyElt

空である可能性のある要素 e の場合、コンテンツ c になる。

ローカルな空白ノード識別子 i と n := identifier(identifier=i, identifier-type="bnodeID")を作成する。

次のステートメントをモデルに追加する。

rdf:ID属性 a が与えられている場合、上記のステートメントは、i := identifier(identifier=concat(e.base-uri, ""#", a.string-value), identifier-type="URI") で、5.26節の具体化規則と e.subject := i を使用して具体化される。

要素コンテンツ c が空でない場合、ノード n を使用して以下のようにノードの新しい順序を作成する。

その後、プロダクションnodeElementを使用して結果としてできた順序を処理する。

5.13 プロダクションparseTypeOtherPropertyElt

文字列"Resource"や"Literal"以外のrdf:parseType属性値はすべて、"Literal"のように扱われる。処理はプロダクションparseTypeLiteralPropertyEltで続けなければならない。 その他のrdf:parseType値に対して余分なトリプルは作成されない。

5.14 プロダクションemptyPropertyElt

• 属性が存在しない場合または、任意のrdf:ID属性 i のみが存在する場合、 o := literal(literal-value=", literal-language=e.language) と次のステートメントがモデルに追加される。

  e.parent.subject.string-value <e.URI> o.string-value .

  そして、i が与えられている場合、上記のステートメントは、識別子(identifier=concat(e.base-uri, ""#", i.string-value), identifier-type="URI") で、 5.26節の具体化規則を使用して具体化される

  テスト: test002.rdf および test002.ntで記載している。

  テスト: test005.rdf およびtest005.ntで記載している。

• その他の場合

  • rdf:resource属性 i が存在する場合、r := identifier(identifier=i.string-value, identifier-type="URI")
  • それ以外の場合、ローカルな空白ノード識別子 i と r := identifier(identifier=i, identifier-type="bnodeID") を作成する。

  任意のrdf:bagID属性 b が与えられている場合、n := identifier(identifier=concat(e.base-uri, ""#", b.string-value), identifier-type="URI")

  以下はどの順番でも行うことができる。

  • 次のステートメントをモデルに追加する。

    e.parent.subject.string-value <e.URI> r.string-value .

    そして、rdf:ID属性 i が与えられている場合、上記のステートメントは、 識別子(identifier=concat(e.base-uri, ""#", i.string-value), identifier-type="URI") で5.26節の具体化規則を使用して具体化される。

  • propertyAttr a (任意の順番)の場合

    • a.URI = rdf:typeの場合、以下のステートメントがモデルに追加される。

      r.string-value <a.URI> <a.string-value> .

    • それ以外の場合、o := literal(literal-value= a.string-value, literal-language= e.language) と以下のステートメントがモデルに追加される。

      r.string-value <a.URI> o.string-value .

    ノード n が与えられている場合、ローカルな空白ノード識別子 i と s := identifier(identifier=i, identifier-type="bnodeID")を作成する。 その後、上記の各ステートメントをノード s で、5.26節の具体化規則を使用して具体化し、5.28節のbag拡張規則はURI u を与えるためにノード n に適用される。 その後、次のステートメントがモデルに追加される。

    n.string-value <u.string-value> s.string-value; .

    テスト:test013.rdf およびtest013.ntで記述している。

    テスト:test014.rdf and test014.ntで記述している。

  • ノード n が作成される場合、次のステートメントをモデルに追加する。

    n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns"#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns"#Bag> .

5.15 プロダクションidAttr

5.16 プロダクションaboutAttr

5.17 プロダクションbagIdAttr

5.18 プロダクションpropertyAttr

5.19 プロダクションresourceAttr

5.20 プロダクションparseLiteral

5.21 プロダクション parseResource

5.22 プロダクションparseOther

5.23 プロダクション URI-reference

5.24 プロダクションliteral

5.25 プロダクションrdf-id

5.26 具体化規則

N-トリプルに相当する、用語s、p　とo を持つステートメントの場合、以下となる。

与えられた識別子ノード r を使用して、次のステートメントをモデルに追加する。

5.27 リスト拡張規則

与えられた要素 e に対して、新しい　URI u := concat("http://www.w3.org/1999/02/22-rdf-syntax-ns"#_", e.li-counter)を作成し、 e.li-counterプロパティを1増やし、u を返す。

5.28 Bag拡張規則

与えられた要素 e に対して、 新しい　URI u := concat("http://www.w3.org/1999/02/22-rdf-syntax-ns"#_", e.bag-li-counter)を作成し、 e.bag-li-counterプロパティを1増やし、u を返す。

6 RDF/XMLへのRDFグラフのシリアライズ化

RDFモデル理論 [RDF-MODEL]で表現できるグラフがすべて、このシンタックスに符号化できるわけではない。RDF/XML から RDF グラフを行き来した後、RDF/XMLへ戻る場合、その意味は同じ（グラフ）であるが、現れたRDF/XMLは厳密には同じではない。

RDFのシリアライズ化には二つの方法がある。

基本の方法では、[RDF-MS]からの基本のRDFシンタックスを使用する。その場合、

• 空白のノードはすべて割り当てられた任意のURIである。
• 各リソースは、rdf:about属性を使用してトップレベルのrdf:Description要素のサブジェクトとして順にリストされる。
  各トリプルに対して、サブジェクトがリソースの場合、該当するプロパティ要素プロダクションが使用され、文字列コンテンツ（空の可能性のある）または、rdf:resource属性の場合、トリプルのオブジェクトを指定する。

出力されたRDF/XMLがさらに進んだ処理でのみ使用されるアプリケーション用に、基本のシリアライゼーションを使用することをお勧めする。出力したRDF/XMLファイルを人が読むことを目的とする場合、基本のシリアライゼーションが不十分であるとわかる。基本のシリアライゼーションは、[RSS] や [CC/PP]などのような、より制限されたRDFのサブダイアレクトには準拠しない。そのため、そういったアプリケーションには、ダイアレクト専用のシリアライザーが必要である。

人間が読むことのできる出力が必要な場合、以下の要素を考慮するべきである。

• 同一のRDFグラフに対応するRDF/XML文書がたくさんあるため、選択肢はたくさんある。個々のトリプルはさまざまな方法で表現できる。 高品質の　RDF シリアライゼーションには、これらの選択肢がシリアライズ化コードで判断されなけなければならない。その中には、アプリケーション依存型よりも適切なものがある。
• グラフのトリプルは、適切な順序で判断されなければならない。順番に選択肢がたくさんあり、その中にもアプリケーション依存型よりも適切なものがある。

RDF/XMLシリアライゼーションを使用して、XML ネーム空間で許可された名前(QName)として表現できないプロパティレベルを持つトリプルでRDFグラフをシリアライズ化することはできない。 RDFシリアライザーの実装者は、URI をネーム空間名とローカル名に崩し、XMLではない最後のName の文字の後にそれを分割することをお勧めする。URI がNameでない文字で終わった場合、"this graph cannot be serialized in RDF 1.0（本グラフはRDF1.0ではシリアライズ化できない）" という例外、または、エラーを発生する。

トップダウンの反復的降順方法で完全な文法を使用してRDF/XMLをシリアライズ化する方法については、[UNPARSING]で述べている。

7 謝辞（報知）

以下の方々の本書への貴重な貢献に感謝する。

• Dan Brickley, W3C/ILRT
• Jeremy Carroll, HP Labs Bristol

8 参考文献

規範的な参考文献

[RDF-MS]

Resource Description Framework (RDF) Model and Syntax Specification, O. Lassila and R. Swick, Editors. World Wide Web Consortium. 22 February 1999.
本版は、http://www.w3.org/TR/1999/REC-rdf-syntax-19990222である。
RDF M&Sの最新の版は http://www.w3.org/TR/REC-rdf-syntaxで参照できる。

[XML]

Extensible Markup Language (XML) 1.0, Second Edition, T. Bray, J. Paoli, C.M. Sperberg-McQueen and E. Maler, Editors. World Wide Web Consortium. 6 October 2000.
本版は、 http://www.w3.org/TR/2000/REC-xml-20001006である。
XMLの最新版はhttp://www.w3.org/TR/REC-xmlで参照できる。

[XML-NS]

Namespaces in XML, T. Bray, D. Hollander and A. Layman, Editors. World Wide Web Consortium. 14 January 1999.
本版は、 http://www.w3.org/TR/1999/REC-xml-names-19990114である。
Namespaces in XMLの最新版 はhttp://www.w3.org/TR/REC-xml-namesで参照できる。

[INFOSET]

XML Information Set, J. Cowan and R. Tobin, Editors. World Wide Web Consortium. 24 October 2001.
本版は、 http://www.w3.org/TR/2001/REC-xml-infoset-20011024 である。
XML Information setの最新版 は http://www.w3.org/TR/xml-infosetで参照できる。

[URIS]

RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding and L. Masinter, IETF, August 1998.
本書は http://www.isi.edu/in-notes/rfc2396.txtである。

[RDF-TESTS]"

RDF Test Cases, A. Barstow and D. Beckett, Editors. 作業中である。 World Wide Web Consortium, 15 November 2001.
RDF Test Casesの本版は、 http://www.w3.org/TR/2001/WD-rdf-testcases-20011115/である。
RDF Test Casesの最新版 は http://www.w3.org/TR/rdf-testcasesで参照できる。

[KEYWORDS]

RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF. March 1997. 本書は、 http://www.ietf.org/rfc/rfc2119.txtである。

[RFC-3023]

RFC 3032 - XML Media Types, M. Murata, S. St.Laurent, D.Kohn, IETF. January 2001.
本書は http://www.ietf.org/rfc/rfc3023.txtである。

[XML-BASE]

XML Base, J. Marsh, Editor, W3C Recommendation. World Wide Web Consortium, 27 June 2001. XML Baseの本版は、http://www.w3.org/TR/2001/REC-xmlbase-20010627/である。XML Baseの最新版 はhttp://www.w3.org/TR/xmlbase/で参照できる。

情報提供となる参考文献

[CHARMOD]

Character Model for the World Wide Web 1.0, M. D・st, F. Yergeau, R. Ishida, M. Wolf, A. Freytag, T Texin, Editors, World Wide Web Consortium Working Draft, work in progress, 20 February 2002.
Character Modelの本版は http://www.w3.org/TR/2002/WD-charmod-20020220/で参照できる。Character Modelの最新版はhttp://www.w3.org/TR/charmod/で参照できる。

[RDF-MODEL]

RDF Model Theory, P. Hayes, Editor. 作業中である。World Wide Web Consortium, 14 February 2002.
RDF Model Theoryの本版は http://www.w3.org/TR/2002/WD-rdf-mt-20020214である。
RDF Model Theoryの最新版 は http://www.w3.org/TR/rdf-mt/である。

[RDF-PRIMER]

RDF Primer, F. Manola, E. Miller, Editors, World Wide Web Consortium W3C Working Draft, work in progress, 19 March 2002. RDF Primer の本版は http://www.w3.org/TR/2002/WD-rdf-primer-20020319/である。
RDF Primerの最新版は http://www.w3.org/TR/rdf-primer/である。

STRIPEDRDF

RDF: Understanding the Striped RDF/XML Syntax, D. Brickley, W3C, 2001. 本書は http://www.w3.org/2001/10/stripes/である。

XPATH

XML Path Language (XPath) Version 1.0, J. Clark and S. DeRose, Editors. World Wide Web Consortium, 16 November 1999．
XPathの本版は http://www.w3.org/TR/1999/REC-xpath-19991116である。
XPathの最新版は http://www.w3.org/TR/xpathある。

SAX2

SAX Simple API for XML, version 2, D. Megginson, SourceForge, 5 May 2000.
本書は http://sax.sourceforge.net/である。

RSS

RDF Site Summary (RSS) 1.0, G. Beged-Dov, D. Brickley, R. Dornfest, I. Davis, L. Dodds, J. Eisenzopf, D. Galbraith, R.V. Guha, K. MacLeod, E. Miller, A. Swartz, E. van der Vlist, 2000. 本書は http://purl.org/rss/1.0/specである。

CC/PP

Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies, G. Klyne, F. Reynolds, C. Woodrow, H. Ohto, World Wide Web Consortium Working Draft, work in progress, 15 March 2001. 本版は http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/である。CC/PP structure and Vocabulariesの最新版は http://www.w3.org/TR/CCPP-struct-vocabで参照できる。

UNPARSING

Unparsing RDF/XML, J. J. Carroll, HP Labs Technical Report, HPL-2001-294, 2001.
本書は http://www.hpl.hp.com/techreports/2001/HPL-2001-294.htmlで参照できる。

RELAXNG

RELAX NG Specification, James Clark and MURATA Makoto, editors, OASIS, 3 December 2001. RELAX NGの本版はhttp://www.oasis-open.org/committees/relax-ng/spec-20011203.htmlである。 最新版は http://relaxng.org/で参照できる。

RELAXNG-NX

RELAX" NG Non-XML Syntax, James Clark, 3 December 2001.
本書は http://www.thaiopensource.com/relaxng/nonxml/である。

XML Schema Part 0: Primer

XML Schema Part 0: Primer - W3C Recommendation, World Wide Web Consortium, 2 May 2001.

XML Schema Part 1: Structures

XML Schema Part 1: Structures - W3C Recommendation, World Wide Web Consortium, 2 May 2001.

XML Schema Part 2: Datatypes

XML Schema Part 2: Datatypes - W3C Recommendation, World Wide Web Consortium, 2 May 2001.

Schematron

Schematron, Rick Jelliffe, Academia Sinica Computing Centre, Taibei.

付録 A: RDF/XML シンタックスに影響する問題(標準非準拠)

本節では、解決すべきローカルな問題と、XMLシンタックスとその処理に関してRDFコアワーキンググループに寄せられた問題について述べている。本節は最終的なリストでもないし、後者の記述の最終版でもない。 RDFコアワーキンググループの問題のリストを参照のこと。また、決定した問題には、関連したテスト事例があり、そのテスト事例はRDFテスト事例の W3C ワーキングドラフトで参照できる。

A.1: 文書の問題 / 課題(標準非準拠)

task-infoset

(2001年12月18日のドラフトのフィードバック):　SAX　よりも　Infoset　を元に検討する。

task-renaming

(2001年12月18日のドラフトのフィードバック): 例えば、RDFグラフノードとの混乱をさけるためのイベントなど、nodesetの用語の変更を検討する。

task-intro

(2001年12月18日のドラフトのフィードバック): RDF モデル、グラフ、モデル論理、N-トリプルに関するよりよい指示テキスト。

A.2: RDFコアワーキンググループで未解決のRDF/XMLシンタックスに影響する問題（標準非準拠)

rdf-charmod-literals

literal の処理は charmod に準拠している？[CHARMOD]

アクション: ?

rdf-charmod-uris

uri-references　の処理は　charmodに準拠している? [CHARMOD]

アクション: ?

A.3: RDFコアワーキンググループが決定したRDF/XMLシンタックスに影響する問題 (標準非準拠)

rdf-ns-prefix-confusion

2001年5月25日、ワーキンググループは、属性すべてがネーム空間で許可されなければならないということを決定した。
関連する文法プロダクションと テスト事例の収集についての詳細を含む決定の詳細 を記録している。

アクション: 元の文法プロダクション、6.6、6.7、6.8、6.9、6.11、6.18、6.32、6.33を削除。

rdfms-abouteachprefix

2001年6月1日、ワーキンググループは、実装経験が不足しているため、RDFモデルとシンタックスの勧告からaboutEachPrefixを削除することを決定した。そのため、勧告には記載されるべきではない。
RDFの将来の版には、この機能のサポートを検討している。

アクション: 元の文法プロダクション6.8を削除。

rdf-containers-syntax-ambiguity
rdf-containers-syntax-vs-schema

2001年6月29日、ワーキンググループは、コンテナと文法（プロダクション 6.13) のtypedノードプロダクションが一致することと、コンテナ専用のプロダクション（プロダクション6.25から6.31まで）とそれへの参照を文法から削除することを 決めた 。 trdf:li 要素は、propertyElt (プロダクション 6.12)、または、typedNode (プロダクション 6.13)のどちらかと一致する場合、rdf:_nnn 要素に変換される。この決定には、 テスト事例の集合も含まれる。

アクション: 元の文法プロダクション、 6.25、6.26、6.27、6.28、6.29、6.30、 6.31を削除。

rdfms-empty-property-elements

2001年6月8日、ワーキンググループは、空のプロパティ要素が解釈される方法を決定した。この決定はすべて、テスト事例に記載している。

アクション: テスト事例へのポインタを空のプロパティが認識される場所で文法に挿入した。

rdfms-aboutEach-on-object

2001年6月29日、ワーキンググループは、ステートメントのオブジェクトであるrdf:Description (または、typedノード)でrdf:aboutEach属性が許可されないということを決定した。

アクション: 必要なし。-2001年12月7日、languageから、rdf:aboutEachを削除した 。

rdfms-syntax-desc-clarity

シンタックスを記述する言語があいまいである。 [6節]

2001年10月26日、ワーキンググループは、本書のシンタックスを定義する新しい方法でこの問題をクローズすることを決定した。

アクション: 本書の主な目的は、シンタックスをより明確で正確にすることである。 特に、文法の節とXML妥当検査のスキーマへのポインタがこの件に対処するのに役立つ。

rdfms-formal-grammar

RDFの正式な文法

2001念10月26日、ワーキンググループは、本書のシンタックスを定義する新しい方法でこの問題をクローズすることを決定した。

アクション: 本書の主な目的は、シンタックスをより明確で正確にすることである。特に、文法の節とXML妥当検査のスキーマへのポインタがこの件に対処するのに役立つ。

rdfms-validating-embedded-rdf

2001年11月9日、RDFコアワーキンググループは、”現行のRDF/XMLシンタックスを現在の憲章の範囲外の問題に対処するのに必要な範囲までに変更するため、その範囲外の領域に関して後に検討を行う”ための課題を保留にすることを決議した。

アクション: 必要なし。

rdfms-rdf-names-use

2001年11月30日、ワーキンググループは、以下のことを決議することでこの問題をクローズすると決定した。

文法で指定されている様に確保された名前として使用する以外でのrdf:RDF、rdf:ID、 rdf:about、rdf:resource、rdf:bagID、rdf:parseType、rdf:aboutEach、rdf:li except　の使用はエラーである。 [その後、2001年12月7日に、rdf:aboutEach をlanguageから削除した。]

2002年2月25日、ワーキンググループは、以下のことを決議した。

ワーキンググループは、シンタックス的ではないRDFネーム空間の名前を制限しないという決定を再確認し、 RDFネーム空間に定義されていない名前がある場合、EDFプロセッサは警告を発すべきであり、それ以外の場合は正常に機能することを決定した。

アクション: 3.4節 RDFネーム空間に注意書きを追加した。

rdfms-abouteach

rdf:aboutEach を処理するにはサブプロパティ関係の処理が必要である。

2001年12月7日、ワーキンググループは、language から　rdf:aboutEach　を削除することを決議した。

アクション: 文法から削除した。

rdfms-propElt-id-with-dr

2001年12月7日、ワーキンググループは、language から　rdf:aboutEach　を削除することを決定し、この問題はクローズされた。

アクション: なし。

rdfms-difference-between-ID-and-about

新しいリソースを’作成’するためのID属性とそれを参照するための　about 属性の使用の違いは何か？

2001年12月14日、ワーキンググループは、この問題について本書で解決することを決定した。

アクション: 詳細については識別子の節を参照のこと。

rdfms-qname-uri-mapping

2002年1月11日、ワーキンググループは、qnameをuriにマッピングするためのアルゴリズムを変更しないということを決議し ( 改定した)、この件に関する問題をクローズした。

1. このような変更を行うと、RDF/XMLシンタックスのモデルへのマッピングを大幅に変更することになり、私達の権利の範囲外である。
2. 同じRDF/XMLが、現行の変更された実装から異なるグラフを作成することになる。
3. 現行のコードは、 RDF/XMLの一部にとっては間違った（不正な）グラフを作成することがある。

アクション: なし

rdfms-reification-required

2002年1月11日、ワーキンググループは、propertyEltのrdf:ID onを使用するか、rdf:Descriptionのrdf:bagIDによって明示的に具体化されたもの以外は、rdf:Description　要素すべてに具体化したステートメントの　bag　を作成するのにパーサは必要ないということを決議した ( 改定した)。

rdf-ns-prefix-confusion test0001 ( test0001.rdf、test0001.nt) などのような、現行のテスト事例では、この解決策を説明している。

アクション: 必要なし。- 現行のシンタックス表記と一致する。

rdfms-replace-value

2002年1月11日、以下の理由で、ワーキンググループはこの時点でこのプロパティの名前を変更しないということを決議し ( 改定した)、

• 変更を行う十分な理由がない
• M&Sの例のように、変更を行うと現行の使用が不正なものとなる

rdf:valueのセマンティックを明確にする必要があるとして問題を書き直すことを決議した。

アクション: なし

mime-types-for-rdf-docs

2002年1月18日、ワーキンググループは、現在RDF MIMEタイプの節に記載している提案された 表現で新しい節を追加することによって本書からこの問題を削除することを認めた。

ワーキンググループの準備ができたら（文書が安定したら）、アプリケーション/rdf+xmlのためのMIMEコンテンツタイプの登録を続行する。

アクション: RDF MIME タイプの節を追加した。

rdfms-xml-base

2002年1月18日、ワーキンググループは、RDF文書の随所でxml:baseが許可・尊重されることを決定した。

2002年2月25日、ワーキンググループは、
(1) xml:base はRDFの文書参照（部分）の使用に適用する
(2) パスコンポーネントのないxml:base の階層的URIは/.を設定するために、これを有するものとする
(3) rdf:IDの値の複製があるかどうかを確認する際、xml:base属性の範囲を考慮するべきである
ことを決定した。

アクション: 3 節 データモデル のInfosetの序論近くに詳細を追加し、3.6 節 ベースURIを新しく追加した。

rdfms-nested-bagIDs

bagIDでネストされた要素のためにどのようなトリプルが作成されるのか?

2002年2月25日、ワーキンググループは、この問題は以下の解決策でクローズしたことを決定した。

bagIDは同じ要素のプロパティ属性を、bagIdを含む要素の直下の子であるプロパティ要素から出てくるtypeノード、ステートメント、bagidとして具体化する。特に、プロパティ要素のステートメントがbagの一部であり、プロパティ属性を持つ場合、そのステートメントはbagの一部ではない。

アクション: bagIDのアルゴリズムをnodeElement emptyPropertyEltに追加した。

rdfms-not-id-and-resource-attr

文法のpropertyEltプロダクション6.12では、ID属性とリソース属性を指定できない。

2002年2月25日、ワーキンググループは、rdf:IDに常に具体化したステート�