ある物事に関する情報を表現するために用いる有向グラフを XML で記述する場合、XML
ドキュメントの各要素、（RDF ノードなどの）DLG の各要素、そしてもちろん記述されるオブジェクトについても、文法を作ることができなければならない。
ほとんどの場合、人間の読み手にとっては自明だろう。"jam jar label text" は（一般には）"jam jar label text" や "jam jar label"、"jam jar" とは続けて読むが "jam" 単独では読まない。
架空の文法を用いたある人物に関する記述の例を挙げる。
<z:person id="foo">
<head>
<play:author>Zoe</play:author>
</head>
<play:name>Albert</play:name>
<play:mailbox resource="mailto:adoe@bar.com"/>
<play:son-name>Bill</play:son-name>
<play:daughter-name>Claire</play:daughter-name>
<play:father>
<z:name value="Joe"/>
<z:wrote href="#foo">
<z:friend resource="#foo"/>
</play:father>
</z:person>
ここで、XML要素には１つの属性と４つの子要素があり、RDF ノードには（ここで明記された）３つのプロパティがある。例えば Albert という人には２人の子供がいる。では我々が参照するというのは "#foo" を参照することなのか？当然ながら我々はその要素を参照するのだが、RDF ステートメントを作る際には通常 RDF ノードを参照するか、むしろそのノードで表されたオブジェクト、RDF の用語ではリソースを参照したいところだ。
もちろん、典型的な UNIX プログラミング言語では、単に文法上使える文字を付加して参照形式を区別するだろう： #foo がノードなら、@#foo（またはそのようなもの）が参照するオブジェクトになるように。しかしここでは全てを RDF で、そして XML でできる限りのことをやろうとしているので、代わりに全く新しいシンタックスを加えてしまうと、幾つか重要なポイントを失うことになるだろう。我々にできることは、異なる参照形式に対して異なる属性名を用いる程度だ。上の例で用いた属性名は次のようなものである：
| value | リテラル文字列 |
| href | フラグメント識別子を含むまたは含まない URI 文字列を使用し、それが参照するテキスト（または XML フラグメントや何らかのメディア） |
| resource | フラグメント識別子を含む URI 文字列を使用し、特定の XML ドキュメントのフラグメントに対応する抽象的 RDF オブジェクト（rdf:resource） |
ここでは "href" を用いて、RDF で XML モデルへの参照ができるようにした。これは、例えばある人が電子的に署名したものが XML 表記であって（署名付き XML 内の）RDF 表記ではないという点で重要である。また、RDF が XML 要素について話せるというのも便利だ。このことは、RDF のフラグメント識別子が何を意味するのかという問題に関わってくる。
次のような URI でなにが特定されるかについて考えてみる。
<rdf:description rdf:id="bar"> <rdf:type resource="...#person"> <y:common-name>Ora Lassila</y:common-name> <y:mailbox>ora.lassila@research.nokia.com</y:mailbox> </rdf:description>フラグメント識別子の意味は、その MIME タイプに関連付けられた仕様から得られる。すなわち、これを application/rdf タイプのドキュメントとして取得したならば、フラグメント識別子は RDF ノードを記述したもの（ここでは Ora という人物）を特定する。これが RDF における参照の使い方である。
しかしながら、MIME タイプが text/html だった場合を考えると、フラグメント識別子は XML の仕様によって定義され、参照先は値 "bar" を持つプロパティ XML:ID を含む要素となる。すなわち rdf:id は xml:id として定義されるのではなく、何を意味するにせよ、RDF の仕様によって "何らかのアクト" として定義されることになる。この参照は（rdf:description 要素とその内容からなる） XML 部分木を指すのか、未定義または恐らく id="bar" を持つというだけの他の何らかの要素を指すのか、明確になっていない。
ドキュメントの概念的なタイプを表す機能としての URI の解釈が異なれば、「RDF に XML 文法を適用すれば、RDF ドキュメントは XML ドキュメントである」とは言えなくなる。言うまでも無く、我々は RDF を正規の XML ドキュメントに適合させる。従ってこれらを区別することはナンセンスである。
もちろん、RDF の仕様上は、単純に XML の定義を間接的に用いて RDF ノードへの参照を XML 要素で記述することが可能だ。しかし、これでは RDF の能力を十分に活かせない。なぜなら、RDF は XML ドキュメントや XML 要素についてのステートメントを生成できる必要があるからだ。そこで例えば、私が上記の小文を書いた事実を示したかったとする。私は自分が foo.rdf#bar の著者だととても書きたくなるだろう。だが、私は Ora Lassila の著者ではない。RDF ではこの問題を解決するために parseType を用い、インラインで data: parseType=Resource と書くことで、参照対象が RDF オブジェクトであることを示す。さらに parseType=Literal と書くことで XML への参照であることを示す。これにより、XML 部分木と RDF オブジェクトの間の関係を表すプロパティの解釈を用いて解決することができる。そのようなプロパティを定義することは良いだろうが、一方で RDF 文法にはショートカットが必要である。私なら、リソースを指定するために使っている "resource=" をリソースのフラグメント識別子にも使用し、さらに実際の RDF ノードを参照するために新たな文法の導入を提案するだろう。ここで実際の RDF ノードとは、その（主語、述語、目的語の）意味 -- 同様にある "もの" の意味 -- に相当する "object=" になるだろう。（前者が "object=" を選んだ理由だ - 一般にその属性は参照されるもののクラスではなく関係を表現できなければならないからだ！）
RDF M&S 1.0 では、ある名前空間で定義されたプロパティ名が、その名前空間の URI に XML 要素のローカルなタグ名を直接繋げることで作られる。
このようなネーミング規則を適用する１つの自然な方法は、ローカルなタグ名がフラグメント識別子になるように、名前空間の URI を "#" で終わることである。スキーマが XML で書かれていれば、これはタグ名（単純な英数字）が XML ID を用いてドキュメント内の何かを特定することを意味する。これはスキーマ言語の制約、ある要素の XML ID は定義されたものへの参照として必ず使用できるという制約である。
RDF プロパティと XML 要素タイプとの間で１対１の対応が存在する場合、次のような選択肢がある。
（ちなみに、XML には現在やや混乱した幾つかの識別子の取扱いが入り混じっているようだ。
要素と属性の名前空間は、語の省略の点では非常にうまく扱われており、URI 空間をベースとし、XML 名前空間の仕様を用いている。
URI 空間はもちろん同じ空間なのだが、値が URI としてタイプ付けされる場合は要素の名前空間の省略形式を用いることができない。）
他の人々もこの問題には気付いており、しかも URI 接頭辞と名前空間接頭辞とを混乱させる提案でさえある。実際、この問題は幾つかのポイントを回避することにより解決できる [ Eric のホワイトボードを参照]。１つの可能性としては、空の URI スキーマ名をコロン接頭辞を用いて待つ方法がある（Eric Prud'hommeauxの提案）。
href=":rdf:description"
上記は、定義された rdf: 名前空間を用いた rdf:description URI を参照する（XML のコンテクストにおいて）全く正しい URI だろう。この方法は、他の URI のように XML 特有の方法で拡張する場合とは異なる扱いをしなければならない点で、私としては無理があるように思える。
他に必要なものは、１度だけしか現れない要素名を使用する場合、且つデフォルトの名前空間を変更しない場合、次のように記述できる明白な論理性だけである。
<http://foo.com/schemas/memo6.2#priority>a</[...]>
次の例では一般論から始めることに全力をかけるため、本稿が終わる前に最初に使った例を見ておく必要があるかもしれない。XML に対する変更を２度も見られるわけではないが。）
［参照されるオブジェクトが特定の要素によって参照されることを示すために、便宜的にリソースを持ち出すことができるかもしれない。明らかに強引だが、
<z:person id=foo> <head> <z:author>Zoe</z:author> </head> <z:name>Albert</z:name> <z:mailbox>mailto:adoe@bar.com</z:mailbox> <z:son-name>Bill</z:son-name> <z:daughter-name>Claire</z:daughter-name> <z:father> <z:name value="Joe"/> <z:wrote href="#foo"> <z:friend> <rdf:node href="#foo"> </z:friend> </z:father> </z:person>このような記述は、形式的にはありそうだが面倒だ：全ての rdf アークが２倍必要になってしまう！事実、Rref の方が RDF にとって本来的かつ基本的であり、href はレベルを分けるために追加したレベル・ブレーカーである。]
私の考えでは、この分析からすれば、RDF の抽象オブジェクトがリソースだとは分かっているが、URI の "R" に相当する "Resource" とは異なるものだ、これは非常に紛らわしい。
RDF M&S は、これと同じ様な問題をオブジェクトに対する ID 、ステートメントであればコンテナに対する BAGID を用いて解決している。
RDF では、"resource" を RDF グラフのノードで表されたオブジェクトを指すものとして用いる。上記の例では、XML 言語として "#foo" が <z:person ... の要素を指しているが、RDF としては #foo は（私の理解によると）その人（person）そのものを指している。これが意味するところは、
@@@ - オブジェクトと URI との対応関係は、抽象リソースを除けば不完全なものだということだ... 例を挙げれば（ホームページ、メールボックス、一般の名前）.... 識別子が無くプロパティのみを使う SQL と比べれば @@@
次の例を考えてみる。
<rdf:description> <rdf:type>http://www.people.org/types#person</a> <play:name>Ora Yrj? Uolevi Lassila</play:name> <play:mailbox resource="mailto:ora.lassila@research.nokia.com"/> <play:homePage resource="http://www.w3.org/People/Lassila"/> </rdf:description>この例は、RDF グラフでは５つのノードで表される： Ora 自身（彼は Web アドレスを持っていない）を示す無名ノードと４つのアーク（これらは "人" タイプ、氏名、email アドレス、ホームページをそれぞれ指している）
これらのプロパティの一部は、幾つかの点で曖昧である（unambiguous → ambiguous の間違い？）：同じメールボックスを持つ２人の人は同一人物と見なされるかもしれない。（私は、どの ID にどういう識別プロパティを与えるべきかというような些細な問題に首を突っ込むつもりはない - それはこの議論の中心ではない。）
私は、多くのプロセッサが、そのようなプロパティを一意に特定するための（プログラムされた、またはスキーマから得た）知識を駆使して結果を得ようとするところを想像している。例えば、play:mailbox というノードをどの２人でも共有できないように定義する場合、次のような情報
<rdf:description> <rdf:type resource="[...]book"/> <play:author parseType="Resource"> <play:mailbox resource="mailto:ora.lassila@research.nokia.com"/> </play:author> </rdf:description> <rdf:description> <play:name>Ora Lassila</play:name> <play:mailbox resource="mailto:ora.lassila@research.nokia.com"/> <play:homePage resource="http://www.w3.org/People/Lassila/"/> </rdf:description>によってシステムは「その本の著者名が Ora Lassila である」と結論づけることができる。
これは、我々が "その著者は ora.lassia@research.nokia.com だ" と省略して言うときに実際起こっていることを如実に語っている。ここで我々が言ったことが意味しているのは、その著者がそういうインターネットのメールボックスを持った誰かであるということだけだ。このような２ステップのプロセスを明らかにすることは、その識別関係の実情をさらすことであり、またその限界をさらすことでもある。これは、私の意見では、データをモデル化するための非常に分かり易い方法であるが、時には次のようなショートカットが必要になる：
<rdf:description rdf:type="[...]book"> <rdf:type>[...]book<rdf:type/> <play:author-mailbox resource="mailto:ora.lassila@research.nokia.com"/> </rdf:description>RDF は人を "リソース" として扱い、通常トートロジー的に "URI を伴うもの" を意味するこの用語（＝リソース）を用いる上では、Ora が彼の Web ページやメールボックスと同義になる。これはもちろん良いデザインとは言えない。「著者−メールボックス」といったショートカットが作られると何が起きるのかを明らかにすることが重要である。このモデルでは、著者自身を表す RDF ノードは存在しない。その本を書きメールボックスを持つ人物が存在することが、他のどこかで表現されなければならない。RDF スキーマは、実際のところ（ボキャブラリーさえあれば）ショートカットの拡張を何らかの機械的な処理に置き換えるのに適しているだろう。
play:mailbox が持つ曖昧さの無い性質は、何かを特定する方法として利用可能なことを示していた。mailto:ora.lassila@research.nokia.com のような URI それだけでは、email を送受信できる抽象的なメールボックスを特定するだけだ。しかし、play:mailbox プロパティは人を特定することができる。その明確さによって、"email が ora@w3.org のとある人物によって書かれた" というリテラルから、"メールボックスが ora@w3.org である特定の人物によって書かれた" という、より有用なステップへと進むことができるのだ。