可能不被用作主体或者谓词。在画RDF图时,节点为 URIrefs的用椭圆来表示, 而节点为文字的则用方框来表示(这个例子中的简单字符串文字叫做平凡文字 (http://www.w3.org/tr/rdf-conCepTs/#dfn-plain-literal)它与将会在2 pi(http://www.w3.org/tr/2004/reC-Rdf-primer-20040210/#tYpedLiTerals) 做介绍的类型文字 (http://www.w3.org/tr/rdf-conCepTs/#dfn-typed-literan)(typed literals)是不同的。在[IRDF= concepts (http://www.w3.org/tr/2004/reC-rDf-primer-20040210/#ref-rdf-cOncepts)] 中详细说明了各种不同的可用于RDF陈述中的文字。平凡文字和类型文字都能容 许采统一字符编码[ INICODE (http://www.w3.org/tr/2004/reC-Rdf-primer-20040210/#rEf-uNicOde)]bl 符,即允许信息用多种语言描述。) 有时在讨论它们的时候画图不太方便,因此也会用到一个替代的书写陈述的方 法,称为三元组(http://www.w3.org/tr/rdf-conCepTs/件dfn-rdf-triple在 三元组表示法中,图中的每个陈述都可以写成一个依次为主体,谓词,客体的三 元组。如图3 (httD:/Ww.n3.org/2004EC-rdf- prImer-20040210/ure3所表示的 陈述用三元组表示法来写就是: <http://www.example.org/index.html>:<http://puri.org/dc/elements/1.1/creator> <http://www.exampleorg/staffid/85740> <http://ww.exampleorg/index.html> <http://www.exampleorg/terms/creation-date>:auguSt16.1999 w example. org/index. html> <http://purl.org/dc/elements/1.1/language>:en 每一个三元组均对应于图中的一条弧,且这个弧的起始节点和终止节点分别是陈 述中的主体和客体。和图形表示法不同(倒像是原先的陈述),三元组表示法要 求一个节点在它出现的每个陈述中都要有标识。因此,例如, http://www.exampleorg/index.htm1在三元组表示法中共出现了三次(在 每个三元组中均出现一次),而在图形表示法中只出现了一次。但是,三元组表 示法和图示法描述了完全相同的信息,这揭示了一个要点:RDF的基础是陈述的 图模型,而用于表示或描述这个图的表示法则是次要的 完全的三元组表示法要求写出完整的 URIref(括在尖刮号中),正如上面例子 那样,所以导致了在一页中有很多长句。为方便起见,本文档用一种简写法(也 在其他的RDF规范里使用)来书写三元组。在这种简写法中,一个不用尖刮号 的MM限定名( QName)作为一个完整的 URIref的缩写形式( QName会在附录 B(http://www.w3.org/tr/2004/reC-rDf-primer-20040210/docuMenTs)It 步讨论)。一个 QName包括一个被赋为命名空间URI的前缀,其后是一个冒号
可能不被用作主体或者谓词。在画 RDF 图时，节点为 URIrefs 的用椭圆来表示， 而节点为文字的则用方框来表示（这个例子中的简单字符串文字叫做平凡文字 (http://www.w3.org/TR/rdf-concepts/#dfn-plain-literal)，它与将会在 2.4 节 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#typedliterals) 做介绍的类型文字 (http://www.w3.org/TR/rdf-concepts/#dfn-typed-literal)（typed literals）是不同的。在[[RDF-CONCEPTS (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#ref-rdf-concepts)] 中详细说明了各种不同的可用于 RDF 陈述中的文字。平凡文字和类型文字都能容 许采统一字符编码[UNICODE (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#ref-unicode)]的字 符，即允许信息用多种语言描述。） 有时在讨论它们的时候画图不太方便，因此也会用到一个替代的书写陈述的方 法，称为三元组 (http://www.w3.org/TR/rdf-concepts/#dfn-rdf-triple)。在 三元组表示法中，图中的每个陈述都可以写成一个依次为主体，谓词，客体的三 元组。如图 3 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure3)所表示的 陈述用三元组表示法来写就是： <http://www.example.org/index.html> <http://purl.org/dc/elements/1.1/creator> <http://www.example.org/staffid/85740> . <http://www.example.org/index.html> <http://www.example.org/terms/creation-date> "August 16, 1999" . <http://www.example.org/index.html> <http://purl.org/dc/elements/1.1/language> "en" . 每一个三元组均对应于图中的一条弧，且这个弧的起始节点和终止节点分别是陈 述中的主体和客体。和图形表示法不同（倒像是原先的陈述），三元组表示法要 求一个节点在它出现的每个陈述中都要有标识。因此，例如， “http://www.example.org/index.html” 在三元组表示法中共出现了三次（在 每个三元组中均出现一次），而在图形表示法中只出现了一次。但是，三元组表 示法和图示法描述了完全相同的信息，这揭示了一个要点：RDF 的基础是陈述的 图模型，而用于表示或描述这个图的表示法则是次要的。 完全的三元组表示法要求写出完整的 URIref（括在尖刮号中），正如上面例子 那样，所以导致了在一页中有很多长句。为方便起见，本文档用一种简写法（也 在其他的 RDF 规范里使用）来书写三元组。在这种简写法中， 一个不用尖刮号 的 XML 限定名（QName）作为一个完整的 URIref 的缩写形式 （QName 会在附录 B (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#documents)进一 步讨论）。一个 QName 包括一个被赋为命名空间 URI 的前缀，其后是一个冒号
然后是个”局部名称”( local name)。由 QName可以生成完整的 URIref,即将 局部名称添加到已经赋了命名空间URI的前缀。因此,例如,如果将命名空间 Uri "htTp: //example. org/somewhere/"赋值给 QName前缀foo,那么 QName foo:bar就是UriRef"http://example.org/somewhere/bar"的缩写。在本 文档的例子中也会用一些“公认的” QName前缀(这些前缀无需说明就可使用) 定义如下 前缀rdf:命名空间Uri:http://www.w3.org/1999/02/22-rdf-syntaxns 前缀rdfs:命名空间Uri:http://www.w3.org/2000/01/rdf-schema#t 前缀dc:,命名空间Uri:http://puri.org/dc/elements/1.1. 前缀owI:命名空间Uri:http://www.w3.org/2002/07/owl 前缀ex:,命名空间Uri:http://www.exampleorg/(orhttp://www.example.com 前缀xsd:命名空间Uri:http://www.w3.org/2001/xmlschema 显然,“ example”的前缀“ex:”的变形在需要时也会用在示例中,例如 前缀exterms:命名空间Uri:http://www.example.org/terms/(作为示例的组织中的词汇) 前缀exstaff命名空间Uri:http://www.example.org/staffid/(作为示例的组织中的雇 员标识) 前缀ex2:命名空间Uri:http://www.domain2.exampleorg/(作为示例的第二个组织中的 词汇), and so or 用这种简写法,先前的三元组可以写成: ex: index. html dc creator exstaff: 85740 ex:index. html exterms: creation-date August 16. 199 ex: index. html dc: l anguage 因为RDF用 URIref替代词语来命名陈述中的事物,RDF称一个 URIref的集合(特 别是为了某个目的集合)为词汇表( vocabulary)。通常,这些词汇表中的 URIrefs 被组织为一个有相同前缀的 QName的集合。也就是说,一个词汇表中的所有术语 都有一个相同的命名空间 URIref,通常这个 URIref(无论是谁控制)定义了这
然后是个"局部名称"（local name）。由 QName 可以生成完整的 URIref，即将 局部名称添加到已经赋了命名空间 URI 的前缀。因此，例如，如果将命名空间 URI“http://example.org/somewhere/”赋值给 QName 前缀 foo，那么 QName “foo:bar”就是 URIref“http://example.org/somewhere/bar”的缩写。在本 文档的例子中也会用一些“公认的”QName 前缀（这些前缀无需说明就可使用）， 定义如下： 前缀 rdf:, 命名空间 URI: http://www.w3.org/1999/02/22-rdf-syntax-ns# 前缀 rdfs:, 命名空间 URI: http://www.w3.org/2000/01/rdf-schema# 前缀 dc:, 命名空间 URI: http://purl.org/dc/elements/1.1/ 前缀 owl:, 命名空间 URI: http://www.w3.org/2002/07/owl# 前缀 ex:, 命名空间 URI: http://www.example.org/ (or http://www.example.com/) 前缀 xsd:, 命名空间 URI: http://www.w3.org/2001/XMLSchema# 显然，“example”的前缀 “ex:”的变形在需要时也会用在示例中，例如: 前缀 exterms:, 命名空间 URI: http://www.example.org/terms/ (作为示例的组织中的词汇), 前缀 exstaff:, 命名空间 URI: http://www.example.org/staffid/ (作为示例的组织中的雇 员标识), 前缀 ex2:, 命名空间 URI: http://www.domain2.example.org/ (作为示例的第二个组织中的 词汇), and so on. 用这种简写法，先前的三元组可以写成： ex:index.html dc:creator exstaff:85740 . ex:index.html exterms:creation-date "August 16, 1999" . ex:index.html dc:language "en" . 因为 RDF 用 URIref 替代词语来命名陈述中的事物，RDF 称一个 URIref 的集合（特 别是为了某个目的集合）为词汇表（vocabulary）。通常，这些词汇表中的 URIrefs 被组织为一个有相同前缀的 QName 的集合。也就是说，一个词汇表中的所有术语 都有一个相同的命名空间 URIref，通常这个 URIref（无论是谁控制）定义了这
个词汇表。包含在词汇表里的 URIrefs是通过在公用的 URIref的末端加上局部 名称形成的,这样就构成了一套有着公用前缀的 URIrefs。譬如:正像前面的例 子展示的那样,一个组织,比方说是 example.org,可能定义一个由前缀全部为 http://www.example.org/terms/的URIrefs构成的词汇表,用来表示这个组织 在业务中用到的术语(例如:“创建日期”,“产品”等),同时也会定义一个 全部由http://www.exampleorg/staffid/开头的URIrefs词汇表来标识这个 组织的雇员。RDF用相同的方法来定义它自己的术语的词汇表,这些术语在在RDF 中有着特定的含义。RDF词汇表中的 URIrefs都以 http://www.w3.org/1999/02/22-rdf-svntax-ns#开头,通常情况下,其 QName用前缀“rdf:”来表示。RDF词汇描述语言(将会在第五节 (http://www.w3.org/tr/2004/reC-Rdf-primer-20040210/#rdFscHemA)fhe) 定义了另一套都以http://www.w3.org/2000/01/rdf-schema#开头的URIrefs 的术语集合,其 QName用前缀“rdfs:”来表示。(当一个特定的 QName前缀以 这种方式与一个已给定的术语集相关联的时候,那么这个 QName前缀有时会用以 作为这个词汇表的名称,比如,有人可能说“rdfs:词汇”) 使用公用的URI前缀提供了一种便捷的方法来组织一套相关的术语集 URIrefs, 然而,这仅仅只是一种约定。RDF模型只认可完整的 URIrefs;它不会去看 URIrefs 的具体内容或使用任何关于它们结构的知识。特别地,RDF不会仅仅因为 URIrefs 有一个公用的前缀而认定这些 URIrefs之间有联系(更深入的探讨请看跗录A (http://www.w3.org/tr/2004/rEc-Rdf-primer-20040210/#IDenTifIers)) 当 URIrefs带有不同的前缀时,并没有规定说,这些 URIrefs就不能被认为属 于同一个词汇表。某个特定的组织、过程( process)或者工具等可以根据自己 的需要,来定义词汇。这些词汇的 URIrefs可以来自于任何其它的词汇,数目 不受限制 另外,有时一个组织将使用词汇表的 URIref命名空间用作是提供关于该词汇表 的详细资料这种Web资源所在地的URL。例如:像著名的 QName前缀dc:将会在 本文档的例子中用到,它是和命名空间 URIref http://pourl.org/dc/elements/1.1/相关联的。事实上,这指在6.1节 (http://www.w3.org/tr/2004/reC-rDf-primer-20040210件dublincore阐述的 都柏林核心词汇表。通过在网页浏览器中访问这个 URIref命名空间就能获得关 于都柏林核心词汇表(明确地说,是一个 RDF Schema)的其他一些信息。然而, 这也仅仅只是一种约定。RDF不会认为每个URI命名空间都能确定一个可获取的 Web资源(更深入的探讨请看跗录B (http://www.w3.org/tr/2004/rEc-Rdf-primer-20040210/dOcumEntS)) 在这个入门文档的其余部分里,当涉及到一些为特殊目而定义的一套 URIref, 比如供RDF自身的使用而定义的各种 URIref,或者是 example.org定义的用来 标识它雇员的一套 URIref,时都将会用到术语“词汇表”。术语“命名空间” 只是在特指ⅫML命名空间这个语法概念的时候才会使用(或者用来描述 QName 中的URI前缀)。 在RDF图中可以自由混合来自不同词汇表的 URIrefs。譬如:在图3 (httD:/wm.w3.og/R2004 REC-rdf- prImer-20040210件 figure3)中用到了
个词汇表。包含在词汇表里的 URIrefs 是通过在公用的 URIref 的末端加上局部 名称形成的，这样就构成了一套有着公用前缀的 URIrefs。譬如：正像前面的例 子展示的那样，一个组织，比方说是 example.org，可能定义一个由前缀全部为 http://www.example.org/terms/ 的 URIrefs 构成的词汇表，用来表示这个组织 在业务中用到的术语（例如：“创建日期”，“产品”等），同时也会定义一个 全部由 http://www.example.org/staffid/ 开头的 URIrefs 词汇表来标识这个 组织的雇员。RDF 用相同的方法来定义它自己的术语的词汇表，这些术语在在 RDF 中有着特定的含义。RDF 词汇表中的 URIrefs 都以 “http://www.w3.org/1999/02/22-rdf-syntax-ns# ”开头，通常情况下，其 QName 用前缀“rdf:”来表示。RDF 词汇描述语言（将会在 第五节 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfschema)做阐述） 定义了另一套都以 http://www.w3.org/2000/01/rdf-schema# 开头的 URIrefs 的术语集合，其 QName 用前缀“rdfs:”来表示。（当一个特定的 QName 前缀以 这种方式与一个已给定的术语集相关联的时候，那么这个 QName 前缀有时会用以 作为这个词汇表的名称，比如，有人可能说“rdfs: 词汇”）。 使用公用的 URI 前缀提供了一种便捷的方法来组织一套相关的术语集 URIrefs， 然而，这仅仅只是一种约定。RDF 模型只认可完整的 URIrefs；它不会去看 URIrefs 的具体内容或使用任何关于它们结构的知识。特别地，RDF 不会仅仅因为 URIrefs 有一个公用的前缀而认定这些 URIrefs 之间有联系（更深入的探讨请看附录 A (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#identifiers) ）。 当 URIrefs 带有不同的前缀时，并没有规定说，这些 URIrefs 就不能被认为属 于同一个词汇表。 某个特定的组织、过程（process）或者工具等可以根据自己 的需要，来定义词汇。这些词汇的 URIrefs 可以来自于任何其它的词汇，数目 不受限制。 另外，有时一个组织将使用词汇表的 URIref 命名空间用作是提供关于该词汇表 的详细资料这种 Web 资源所在地的 URL。例如：像著名的 QName 前缀 dc: 将会在 本文档的例子中用到，它是和命名空间 URIref http://purl.org/dc/elements/1.1/ 相关联的。事实上，这指在 6.1 节 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#dublincore)阐述的 都柏林核心词汇表。通过在网页浏览器中访问这个 URIref 命名空间就能获得关 于都柏林核心词汇表（明确地说，是一个 RDF Schema）的其他一些信息。然而， 这也仅仅只是一种约定。RDF 不会认为每个 URI 命名空间都能确定一个可获取的 Web 资源（更深入的探讨请看附录 B (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#documents) ）。 在这个入门文档的其余部分里，当涉及到一些为特殊目而定义的一套 URIref， 比如供 RDF 自身的使用而定义的各种 URIref ，或者是 example.org 定义的用来 标识它雇员的一套 URIref，时都将会用到术语“词汇表”。术语“命名空间” 只是在特指 XML 命名空间这个语法概念的时候才会使用（或者用来描述 QName 中的 URI 前缀）。 在 RDF 图中可以自由混合来自不同词汇表的 URIrefs。譬如：在图 3 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure3) 中用到了
分别采用了 exterms:, exstaff:;,dc:词汇表的 URIref。在RDF图中,RDF也没有 限制能用多少个具有同一谓词 URIref的陈述描述同一个资源。例如:如果资源 ex: index.htm1是由约翰·史密斯和其他几名工作人员努力合作创造的话,那么 example.org可能写以下陈述 ex: index. html dc: creator exstaff: 85740 ex:index. html dc: creator exstaff: 27354 ex index. html dc creator exstaff: 00816 这些RDF陈述的例子开始展现一些使用 URIref作为RDF标识事物的基本方式的 优势所在。譬如:在第一个陈述中,不用字符串“ John Smith”来作为网页的制 作者,而是把一个 URIref(使用基于他的雇员号码的 URIref) http://www.example.org/staffid/85740赋予给他。这样使用URIref的一个优 点就是陈述主体可以被更加精确的标识出来。就是说,这个网页的制作者不是宰 符串“ John Smith”,也不是数以千计的名叫 John Smith的人中的一个,而是 与那个 URIref(且不管是谁创建了定义了这种关系的 URIref)相关的那个特殊 的 John Smith。而且,因为一个指向 John Smith的 URIref,他就成为一个成熟 的资源,并且仅仅通过增加其他主体为John的 URIref的RDF陈述,就可以记 录他的一些其他信息。例如:图4 (http://www.w3.org/tr/2004/reC-Rdf-primer-20040210/#fIGurE展示了可 给出关于John的姓名和年龄的一些陈述 http://www.example.org/index.html http://purl.org/dc/elements/1.1/creator http://www.example.org/staffid/85740 http:/nWw.example.org/terms/name http:/nWw.example.org/terms/age John Smith 27 图4:更多关于 John Smith的信息 这些例子也说明了RDF在RDF陈述中用 URIref作为谓词。就是说,RDF使用 URIrefs标识属性,而不是使用像“ creator”或者“name”那样的字符串(或词 组)。用 URIref来标识属性的重要性是基于很多原因的。第一,它可以把一个人 用的属性和其他人用的属性区别开来,尽管他们可能用相同的字符串来表示属 性。例如:在图4
分别采用了 exterms:,exstaff:,dc:词汇表的 URIref。在 RDF 图中，RDF 也没有 限制能用多少个具有同一谓词 URIref 的陈述描述同一个资源。例如：如果资源 ex:index.html 是由约翰·史密斯和其他几名工作人员努力合作创造的话，那么 example.org 可能写以下陈述： ex:index.html dc:creator exstaff:85740 . ex:index.html dc:creator exstaff:27354 . ex:index.html dc:creator exstaff:00816 . 这些 RDF 陈述的例子开始展现一些使用 URIref 作为 RDF 标识事物的基本方式的 优势所在。譬如：在第一个陈述中，不用字符串“John Smith”来作为网页的制 作者，而是把一个 URIref（使用基于他的雇员号码的 URIref） http://www.example.org/staffid/85740 赋予给他。这样使用 URIref 的一个优 点就是陈述主体可以被更加精确的标识出来。就是说，这个网页的制作者不是字 符串“John Smith”，也不是数以千计的名叫 John Smith 的人中的一个，而是 与那个 URIref（且不管是谁创建了定义了这种关系的 URIref）相关的那个特殊 的 John Smith。而且，因为一个指向 John Smith 的 URIref，他就成为一个成熟 的资源，并且仅仅通过增加其他主体为 John 的 URIref 的 RDF 陈述，就可以记 录他的一些其他信息。例如：图 4 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure4)展示了可 给出关于 John 的姓名和年龄的一些陈述。 图 4：更多关于 John Smith 的信息 这些例子也说明了 RDF 在 RDF 陈述中用 URIref 作为谓词。就是说，RDF 使用 URIrefs 标识属性，而不是使用像“creator”或者“name”那样的字符串(或词 组)。用 URIref 来标识属性的重要性是基于很多原因的。第一，它可以把一个人 用的属性和其他人用的属性区别开来，尽管他们可能用相同的字符串来表示属 性。例如：在图 4
(htp:/ww.w3.org/T7R2004 REC-rdt- Drier-20040210 #figure4中的例子, example.org使用"name"想要使写出的某人的全名作为一个字符串文字(譬如: “ John Smith”),但是其他人可能想要使"name"代表某些不同的事物(譬如: 在一个程序段中的变量名)。当一段程序遇到“name”作为一个Web上的属性标 识符(或者当合并来自多个数据源的数据)时将不一定能区分这些使用方法。但 是,如果 example.org用“htp://w, example.org/ terms/name”当作它定义 的“nane”的值,并目其他人用 "http://www.domain2.exampleorg/genealogy/terms/name"当作他们定义的 name”的值,那么显然不同的“name”包含着不同的值(即使一个程序不能自 动确定它们的具体含义)。此外,使用 URIrefs来区分属性能使属性被看成是资 源本身。因为属性也是资源,仅仅通过増加主体为属性的 URIref的RDF陈述 就能记录关于属性的信息(譬如: example. org所用的“name”属性的含义的英 文描述) 用 URIref作为RDF陈述的主体,谓词,客体支持了Web上的共享词汇表的使用 和发展,因为人们可以发现并开始使用已经在用的词汇表来描述事物,这反映了 人们对那些概念的共享理解。例如:在三元组“ex: index. html dc: creator exstaff:85740”中 ex: index. html dc: creator exstaff: 85740 当谓词“dc: crearot”完全展开为一个 URIref时,就明确的指向了 Dublin core 元数据属性集(一个广泛使用的描述各种各样信息的一套属性集,将在6.1节 (httD:/w.n3.org/R/2004REC-rdf- primer-2000210/ lublincore)中做深 入的讨论)中的“ creator”的属性。这个三元组的作者有效地说明了网页(由 http://www.exampleorg/index.htm所标识)和网页的作者(一个独一无二的 人,由http://www.example.org/staffid/85740所标识)之间的关系正是一个 由http://purl.org/dc/elements/1.1/creator标识的概念。另一个熟悉 Dublin core词汇的人,或是查明了“dc: creator”确切含义(通过在Web上查 找的它的定义)的人,将会明白这个关系的含义。另外,在这种理解的基础上 在处理含有谓词“dc: creator”的三元组时,人们就能编写出行为与这个含义 致的程序来。 当然,这有赖于越来越普遍地使用 URIref而不是用文字来指代事物;譬如:用 URIref像“ exstaff:85740”和“dc: creator”来代替字符串文字像“John Smith”和“ creator”。即使是那样,RDF对 URIne的使用仍不能解决所有的标 识问题,因为例如:人们仍然能够用不同的 URIref来指代同一个事物。由于这 个原因,尽量使用现有的词汇表(比如 Dublin core)的术语,而不发明可能与 其他词汇表中术语重复的术语,这是个不错的想法。正如在第6节 (http://www.w3.org/tr/2004/reC-rDf-primer-20040210/#appLicaTiOns)aie 的应用展示的那样,在特定领域里适用的词汇表一直都在完善中。然而,即使同 义词被建立了,在普遍可访问的“Web空间”中使用不同的 URIref,即提供了 在这些 URIref中识别等价关系的机遇,也提供了转向使用通用词汇表的机遇
(http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure4)中的例子， example.org 使用"name"想要使写出的某人的全名作为一个字符串文字（譬如： “John Smith”），但是其他人可能想要使"name"代表某些不同的事物（譬如： 在一个程序段中的变量名）。当一段程序遇到“name”作为一个 Web 上的属性标 识符（或者当合并来自多个数据源的数据）时将不一定能区分这些使用方法。但 是，如果 example.org 用“http://www.example.org/terms/name”当作它定义 的“name”的值，并且其他人用 “http://www.domain2.example.org/genealogy/terms/name”当作他们定义的 “name”的值，那么显然不同的“name”包含着不同的值（即使一个程序不能自 动确定它们的具体含义）。此外，使用 URIrefs 来区分属性能使属性被看成是资 源本身。因为属性也是资源，仅仅通过增加主体为属性的 URIref 的 RDF 陈述， 就能记录关于属性的信息（譬如：example.org 所用的“name”属性的含义的英 文描述）。 用 URIref 作为 RDF 陈述的主体，谓词，客体支持了 Web 上的共享词汇表的使用 和发展，因为人们可以发现并开始使用已经在用的词汇表来描述事物，这反映了 人们对那些概念的共享理解。例如：在三元组“ex:index.html dc:creator exstaff:85740 ”中： ex:index.html dc:creator exstaff:85740 . 当谓词“dc:crearot”完全展开为一个 URIref 时，就明确的指向了 Dublin Core 元数据属性集（一个广泛使用的描述各种各样信息的一套属性集，将在 6.1 节 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#dublincore)中做深 入的讨论）中的“creator”的属性。这个三元组的作者有效地说明了网页（由 http://www.example.org/index.html 所标识）和网页的作者（一个独一无二的 人，由 http://www.example.org/staffid/85740 所标识）之间的关系正是一个 由 http://purl.org/dc/elements/1.1/creator 标识的概念。另一个熟悉 Dublin Core 词汇的人，或是查明了“dc:creator”确切含义（通过在 Web 上查 找的它的定义）的人，将会明白这个关系的含义。另外，在这种理解的基础上， 在处理含有谓词“dc:creator”的三元组时，人们就能编写出行为与这个含义一 致的程序来。 当然，这有赖于越来越普遍地使用 URIref 而不是用文字来指代事物；譬如：用 URIref 像“exstaff:85740”和“dc:creator”来代替字符串文字像“John Smith”和“creator”。即使是那样，RDF 对 URIre 的使用仍不能解决所有的标 识问题，因为例如：人们仍然能够用不同的 URIref 来指代同一个事物。由于这 个原因，尽量使用现有的词汇表（比如 Dublin Core）的术语，而不发明可能与 其他词汇表中术语重复的术语，这是个不错的想法。 正如在第 6 节 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#applications)描述 的应用展示的那样，在特定领域里适用的词汇表一直都在完善中。然而，即使同 义词被建立了，在普遍可访问的“Web 空间”中使用不同的 URIref，即提供了 在这些 URIref 中识别等价关系的机遇，也提供了转向使用通用词汇表的机遇