另外,重要的是,要区分RDF本身赋予RDF陈述中的词汇(比如在先前例子里的 dc: creator)的含义与人们(或人编写的程序)可能赋予这些词汇的其他外部定 义的含义。作为一门语言,RDF直接定义的只有主体,谓词,客体三元组的图示 语法,在rdf:词汇表中的 URIrefs的某些含义,和稍后会做介绍的某些其他概 念。这些事物在[RDF= CONCEPTS (http://www.w3.org/tr/2004/rEc-rdf-primer-20040210/#Ref-Rdf-concepts)] 和[ RDF-SEMANTICS (http://www.w3,org/tr/2004/reC-Rdf-primer-20040210/#rEF-rDf-Semantics )]有规范的定义。不过,RDF没有定义在RDF陈述中使用的其他词汇表中的术语 的含义,比如:dc: creator。特定的词汇表会被创建且其中的 URIref会被赋予 特定的含义,但这是在RDF之外的。使用了这些词汇表中的 URIref的RDF陈述 可能会把那些术语的特定含义传达给熟悉这些词汇表的人,或是处理这些词汇表 的RDF应用程序,而不会把这些含义传达给不是特意处理这些词汇表的通用RDF 应用程序 例如,人们可以给一个三元组如 ex: index. html dc: creator exstaff: 85740 赋予一定的含义,这是基于单词“ creator”作为 URIref“dc: creator”的一部 分出现所表示的含义,或者基于在他们理解了“dc: creator”在 Dublin core 词汇表中的确切定义。不过,就通用的RDF应用程序而言,这个三元组和下面 的三元组在内在的含义上是一样的 fy: joefy. iunm ed: dsfbups fytubgg: 85740 与此类似,任何可能在Web上找到的描述“dc: creator”含义的自然语言文本都 无法为一个通用的RDF应用程序提供其直接可用的额外的含义信息。 当然,来自一个特定词汇表的 URIrefs可以在RDF陈述中被使用,尽管给定的应 用程序可能不能把任何特定的含义赋予他们。例如,通用的RDF软件会识别出上 述表达式是一个RDF陈述,其中“ed: dsfbups”是一个谓词,等等。它不会把词 汇表开发人员赋予给一个 URIref(比如ed: dsfbups)的任何特定含义赋给这个 三元组。此外,基于他们对一个给定的词汇表的理解,人们仍可以编写出一个与 这个词汇表中的 URIref的特定含义一致的RDF应用程序,尽管这个含义对不是 以这种方式编写的RDF应用程序是无法理解的。 结果是:RDF提供了一种发表更易被应用程序处理的陈述的方法。一个应用不能 真正理解这些陈述,就如当一个数据库系统处理一个查询语句如: SELECT NAME FROM EMPLOYEE WHERE SLALRY>35000的时候,数据库系统对像“ employee 或“ salary”这类的词汇的理解一样。但是,如果一个应用程序编写的很合理, 那么它处理RDF陈述时就好像它确实理解它们一样,这正像是一个数据库系统和 它的程序并没有理解什么是“ employee”和“ payroll”却能在处理雇员和薪水
另外，重要的是，要区分 RDF 本身赋予 RDF 陈述中的词汇（比如在先前例子里的 dc:creator）的含义与人们（或人编写的程序）可能赋予这些词汇的其他外部定 义的含义。作为一门语言，RDF 直接定义的只有主体，谓词，客体三元组的图示 语法，在 rdf:词汇表中的 URIrefs 的某些含义，和稍后会做介绍的某些其他概 念。这些事物在[RDF-CONCEPTS (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#ref-rdf-concepts)] 和[RDF-SEMANTICS (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#ref-rdf-semantics )]有规范的定义。不过，RDF 没有定义在 RDF 陈述中使用的其他词汇表中的术语 的含义，比如：dc:creator。特定的词汇表会被创建且其中的 URIref 会被赋予 特定的含义，但这是在 RDF 之外的。使用了这些词汇表中的 URIref 的 RDF 陈述 可能会把那些术语的特定含义传达给熟悉这些词汇表的人，或是处理这些词汇表 的 RDF 应用程序，而不会把这些含义传达给不是特意处理这些词汇表的通用 RDF 应用程序。 例如，人们可以给一个三元组如： ex:index.html dc:creator exstaff:85740 . 赋予一定的含义，这是基于单词“creator”作为 URIref“dc:creator”的一部 分出现所表示的含义，或者基于在他们理解了“dc:creator”在 Dublin Core 词汇表中的确切定义。 不过，就通用的 RDF 应用程序而言，这个三元组和下面 的三元组在内在的含义上是一样的： fy:joefy.iunm ed:dsfbups fytubgg:85740 . 与此类似，任何可能在 Web 上找到的描述“dc:creator”含义的自然语言文本都 无法为一个通用的 RDF 应用程序提供其直接可用的额外的含义信息。 当然，来自一个特定词汇表的 URIrefs 可以在 RDF 陈述中被使用，尽管给定的应 用程序可能不能把任何特定的含义赋予他们。例如，通用的 RDF 软件会识别出上 述表达式是一个 RDF 陈述，其中“ed:dsfbups”是一个谓词，等等。它不会把词 汇表开发人员赋予给一个 URIref（比如 ed:dsfbups）的任何特定含义赋给这个 三元组。此外，基于他们对一个给定的词汇表的理解，人们仍可以编写出一个与 这个词汇表中的 URIref 的特定含义一致的 RDF 应用程序，尽管这个含义对不是 以这种方式编写的 RDF 应用程序是无法理解的。 结果是：RDF 提供了一种发表更易被应用程序处理的陈述的方法。一个应用不能 真正理解这些陈述，就如当一个数据库系统处理一个查询语句如：SELECT NAME FROM EMPLOYEE WHERE SLALRY > 35000 的时候，数据库系统对像“employee” 或“salary”这类的词汇的理解一样。但是， 如果一个应用程序编写的很合理， 那么它处理 RDF 陈述时就好像它确实理解它们一样，这正像是一个数据库系统和 它的程序并没有理解什么是“employee”和“payroll”却能在处理雇员和薪水
的数据信息时做有用的工作一样。例如:一个人能搜寻Web找到全部书评并且为 每本书创建一个平均等级。然后,这个人就可以把这些关于书的信息放到Web 上。而另一网站能获取这些书平均等级的列表并且创造一个"评价最高的十本书 面。这里,一个关于书等级的共享词汇表的可用性和及其使用,以及用于标 识那些书的一组共享的 URIref,允许个人建造一个在Web上可相互理解和用处 日益广泛(或说是做了其他贡献那样)的关于书的“信息库”。相同的原则适用 于人们每天在Web上创建的关于数以千计的主题的大量信息 RDF陈述和很多其他信息记录格式类似,像 在一个数据处理系统里,一个简单的记录或是目录清单中的实体, 个简单的关系数据库的行 形式逻辑的简单断言 并且,这些格式的信息都能看成RDF陈述,这使得RDF能用于集成来自多个数据 源的数据。 2.3结构化的属性值与空节点 需要记录的信息,如果用简单的RDF语句的形式来描述就足够了,那么,一切都 将变得很简单,但是,大多数现实世界中的数据,至少表面看起来,要比简单的 RDF语句所能描述的形式复杂得多。例如,在最初的那个例子中,用来记录创建 网页的是一个简单的数据: creation-date属性,这个属性的值是简单的字符型, 但是,假设这个 creation-date属性的值需要分别记录年、月、日,或者,在描 述 John Smith的个人信息的情况下,我们来考虑John的地址,整个的地址可以 被写作一个简单的字符串,或者一个三元组"1501 Grant Avenue, Bedford, Massachusetts 01730 exstaff 85740 exterms address 1501 Grant Avenue, Bedford, Massachusetts 01730 然而,设想一下约翰的地址需要记录为由一个街道,城市,州和邮政编码组成的 结构,这些在RDF中是如何做到的? 像这样的结构化的数据信息在RDF中是通过以下方式描述的:把被描述的事物聚 集体(比如: John Smith的住址)看成一个资源,然后发表关于这个新资源的 陈述。所以,在RDF图中,为了将 John Smith住址分解成它的各个组成部分 个用来描述 John Smith住址这一概念的新节点就随之产生了,并用一个新的 URIref来标识,如http://www.example.org/addressid/85740(可缩写为
的数据信息时做有用的工作一样。例如：一个人能搜寻 Web 找到全部书评并且为 每本书创建一个平均等级。 然后，这个人就可以把这些关于书的信息放到 Web 上。而另一网站能获取这些书平均等级的列表并且创造一个"评价最高的十本书 "页面。 这里，一个关于书等级的共享词汇表的可用性和及其使用，以及用于标 识那些书的一组共享的 URIref，允许个人建造一个在 Web 上可相互理解和用处 日益广泛（或说是做了其他贡献那样）的关于书的“信息库”。相同的原则适用 于人们每天在 Web 上创建的关于数以千计的主题的大量信息。 RDF 陈述和很多其他信息记录格式类似，像： • 在一个数据处理系统里，一个简单的记录或是目录清单中的实体， • 一个简单的关系数据库的行， • 形式逻辑的简单断言， 并且，这些格式的信息都能看成 RDF 陈述，这使得 RDF 能用于集成来自多个数据 源的数据。 [编辑] 2.3 结构化的属性值与空节点 需要记录的信息，如果用简单的 RDF 语句的形式来描述就足够了，那么，一切都 将变得很简单，但是，大多数现实世界中的数据，至少表面看起来，要比简单的 RDF 语句所能描述的形式复杂得多。例如，在最初的那个例子中，用来记录创建 网页的是一个简单的数据：creation-date 属性，这个属性的值是简单的字符型， 但是，假设这个 creation-date 属性的值需要分别记录年、月、日，或者，在描 述 John Smith 的个人信息的情况下，我们来考虑 John 的地址，整个的地址可以 被写作一个简单的字符串，或者一个三元组"1501 Grant Avenue, Bedford, Massachusetts 01730"。 exstaff:85740 exterms:address "1501 Grant Avenue, Bedford, Massachusetts 01730" . 然而,设想一下约翰的地址需要记录为由一个街道，城市，州和邮政编码组成的 结构，这些在 RDF 中是如何做到的？ 像这样的结构化的数据信息在 RDF 中是通过以下方式描述的：把被描述的事物聚 集体（比如：John Smith 的住址）看成一个资源，然后发表关于这个新资源的 陈述。所以，在 RDF 图中，为了将 John Smith 住址分解成它的各个组成部分， 一个用来描述 John Smith 住址这一概念的新节点就随之产生了，并用一个新的 URIref 来标识，如 http://www.example.org/addressid/85740 （可缩写为
exaddressid:85740)。把这个节点作为主体,RDF陈述(附加的弧和节点)可 用来描述附加的信息,如图5 (http://www.w3.org/tr/2004/rEc-Rdf-primer-20040210/fIgurE5)Ft: http:/nWww.example,org/staffid/85740 http:/mWww.example.org/terms/address http://ww.example.org/addressid/85740 http://www.example.org/terms/city http://www.example.org/terms/postalcode Bedford 01730 http:/mWww.example.org/terms/street http:/nWw.example.org/terms/state 1501 Grant Avenue Massachusetts 图5:分解John的住址: 相应的三元组表示如下: exstaff: 85740 exterms address exaddressid: 85740 exaddress id: 85740 exterms street 1501 Grant Avenue exaddress id: 85740 exterms: city Bedford exaddress id: 85740 exterms state exaddress id: 85740 exterms: posta l Code01730 这中描述RDF结构化数据的方法会产生很多的“中间的” URIrefs,比如像描述 聚集体概念(如John'’ s address)的 URIref exaddressid:85740。这些概念可 能从来不会被从RDF图的外部引用,因此可能不需要“通用的”标识符。另外, 在用于描述一组陈述的图图5 (http://www.w3.org/tr/2004/reC-rDf-primer-20040210/#figUre5)中,用来标 识“ John Smith' s address”的 URIref并不是真正需要的,因为这个图可以简 单地标识为如图6 (httD:/Ww.n3.org/2004EC-rdf- primer-20040210/件ureb所示:
exaddressid:85740）。把这个节点作为主体，RDF 陈述（附加的弧和节点）可 用来描述附加的信息，如图 5 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure5)所示： 图 5：分解 John 的住址： 相应的三元组表示如下： exstaff:85740 exterms:address exaddressid:85740 . exaddressid:85740 exterms:street "1501 Grant Avenue" . exaddressid:85740 exterms:city "Bedford" . exaddressid:85740 exterms:state "Massachusetts" . exaddressid:85740 exterms:postalCode "01730" . 这中描述 RDF 结构化数据的方法会产生很多的“中间的”URIrefs，比如像描述 聚集体概念（如 John's address）的 URIref exaddressid:85740。这些概念可 能从来不会被从 RDF 图的外部引用，因此可能不需要“通用的”标识符。另外， 在用于描述一组陈述的图 图 5 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure5)中，用来标 识“John Smith's address”的 URIref 并不是真正需要的，因为这个图可以简 单地标识为如图 6 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure6)所示：
http://www.example.org/staffid/85740 http:/mWww.example.org/terms/address http:/nWw.example.org/terms/city http:/mWww.example.org/terms/postalcod Bedford 01730 http:/mWww.example.org/terms/street Ahttp://www.example.org/terms/state 1501 Grant Avenue Massachusetts 图6:使用一个空节点 k6(http://www.w3.org/tr/2004/rEc-Rdf-primer-20040210/#fIguRe6E 个近乎完美的RDF图,它使用了一个没有 URIref的节点来表示“ John Smith's address ”这一概念。这个空节点 (httD:/iw.w3.ore/ R/rdf-concepts/mdn- blank-node)虽然没有 URIref,但 表达了它应该表达的含义,因为这个空节点本身提供了图中各个部分之间必需的 连通作用(空节点在[RDF-MS (http://www.w3.org/tr/2004/rEc-Rdf-primer-20040210/#Ref-RdfMs)]中被称 作匿名资源( anonymous resources))。然而,为了把这个图表示为三元组的 形式,就需要一个某种形式的能清楚表示那个空节点的标识符。这里试着写出了 5k6(http://www.w3.org/tr/2004/reC-Rdf-primer-20040210/#FiguRe6ar 示的内容相应的三元组: exstaff: 85740 exterms: address ??? exterms: street 1501 Grant Avenue exterms: cit Bedford exterms: state Massachusetts exterms: posta I Code 01730 ???”出现的地方正是出空节点出现过的地方。因为一个复杂的图包含的空节 点可能会不只一个,所以需要一种区分在图的三元组表示法中出现的不同空节点 的办法。因此,三元组使用空节点标识符
图 6：使用一个空节点 图 6 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure6)是一 个近乎完美的 RDF 图，它使用了一个没有 URIref 的节点来表示“John Smith's address”这一概念。这个空节点 (http://www.w3.org/TR/rdf-concepts/#dfn-blank-node)虽然没有 URIref，但 表达了它应该表达的含义，因为这个空节点本身提供了图中各个部分之间必需的 连通作用（空节点在[RDF-MS (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#ref-rdfms)]中被称 作匿名资源（anonymous resources））。然而，为了把这个图表示为三元组的 形式，就需要一个某种形式的能清楚表示那个空节点的标识符。这里试着写出了 与图 6 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure6) 所 示的内容相应的三元组： exstaff:85740 exterms:address ??? . ??? exterms:street "1501 Grant Avenue" . ??? exterms:city "Bedford" . ??? exterms:state "Massachuset ts" . ??? exterms:postalCode "01730" . “???”出现的地方正是出空节点出现过的地方。因为一个复杂的图包含的空节 点可能会不只一个，所以需要一种区分在图的三元组表示法中出现的不同空节点 的办法。因此，三元组使用空节点标识符
(http://www.w3.org/tr/rdf-concEpTs/#dfn-blank-node-id),以name的 形式来表示空节点。例如:在这个例子中,空节点标识符“: johnaddress”可 以用来表示空节点,那么相应的三元组可以写成如下的形式: exstaff: 85740 exterms address johnaddress headdress exterms street 1501 Grant Avenue johnaddress exterms: city Bedford johnaddress exterms: state Massachusetts johnaddress exterms: posta I Code 01730 在表示一个图的三元组中,图中每个不同的空节点都被赋予一个不同的空节点标 识符。与 URIref和文字不一样,空节点标识符并不被认为是RDF图的一个实际 组成部分(这从图6 (httD:/w.w3.og/R2004 REC-rdf- prImer-20040210件 figure6)所示的就 可以看出来,并且注意在图中空节点并没有空节点标识符)。空节点标识符仅仅 是在把RDF图表示成三元组形式的时候,用来表示图中的空节点的(并且区分不 同的空节点)。空节点标识符只是在用三元组表示单一的图的时候才有意义(两 个有相同空节点数目的RDF图可能会独自地使用相同的空节点标识符来区别那 些空节点,但是如果假设不同RDF图中具有相同标识符的空节点是相同的就不对 了)。如果希望图中的一个节点需要从图的外部来引用,那么就应该赋予一个 URIref值来标识它。最后,因为空节点标识符表示的是(空)节点而非弧,所 以在一个图的三元组表达式中:空节点标识符只能出现在三元组主体和客体的位 置上;不能出现在谓词的位置上。 这一节的开头部分记录了聚集体结构(比如 John Smith' s address)可以通过 如下的方式来描述:聚集体被作为一种资源描述,然后发表关于这个新资源的陈 述。这个例子阐明了RDF的一个重要方面:RDF只能直接表示二元关系,例如: John Smith和描述他住址的文字( literal)之间的关系。要描述John和由这 个地址的每个单独部分组成的组的关系的时候,就要涉及到处理一个N元 (n-ary)关系(在这里N=5),其中这五元分别是John,街区( street),城 市(city),州( state),和邮政编码( postal code)。为了要在RDF中直接 的描述这种结构(例如:把地址看作是由街区( street),城市(city),州( state), 和邮政编码( postal code)这四个部分构成的一个组),就必须把这个N元关 系分解为一组二元关系。空节点提供了一种完成这个任务的方法:对于每一个N 元关系,选择其中的一元( participant)作为这个关系的主体(比如John) 创建一个空节点来描述其余的关系(比如John' s address),这个N元关系的 其他元(比如city)则被描述成由空节点标识的新资源的各个单独的属性
(http://www.w3.org/TR/rdf-concepts/#dfn-blank-node-id)，以“_:name”的 形式来表示空节点。例如：在这个例子中，空节点标识符“_:johnaddress”可 以用来表示空节点，那么相应的三元组可以写成如下的形式： exstaff:85740 exterms:address _:johnaddress . _:johnaddress exterms:street "1501 Grant Avenue" . _:johnaddress exterms:city "Bedford" . _:johnaddress exterms:state "Massachusetts" . _:johnaddress exterms:postalCode "01730" . 在表示一个图的三元组中，图中每个不同的空节点都被赋予一个不同的空节点标 识符。与 URIref 和文字不一样，空节点标识符并不被认为是 RDF 图的一个实际 组成部分（这从图 6 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure6)所示的就 可以看出来，并且注意在图中空节点并没有空节点标识符）。空节点标识符仅仅 是在把 RDF 图表示成三元组形式的时候，用来表示图中的空节点的（并且区分不 同的空节点）。空节点标识符只是在用三元组表示单一的图的时候才有意义（两 个有相同空节点数目的 RDF 图可能会独自地使用相同的空节点标识符来区别那 些空节点，但是如果假设不同 RDF 图中具有相同标识符的空节点是相同的就不对 了）。如果希望图中的一个节点需要从图的外部来引用，那么就应该赋予一个 URIref 值来标识它。最后，因为空节点标识符表示的是（空）节点而非弧，所 以在一个图的三元组表达式中：空节点标识符只能出现在三元组主体和客体的位 置上；不能出现在谓词的位置上。 这一节的开头部分记录了聚集体结构（比如 John Smith's address）可以通过 如下的方式来描述：聚集体被作为一种资源描述，然后发表关于这个新资源的陈 述。这个例子阐明了 RDF 的一个重要方面：RDF 只能直接表示二元关系，例如： John Smith 和描述他住址的文字（literal）之间的关系。要描述 John 和由这 个地址的每个单独部分组成的组的关系的时候，就要涉及到处理一个 N 元 （n-ary）关系（在这里 N＝5），其中这五元分别是 John，街区（street），城 市（city），州（state），和邮政编码（postal code）。为了要在 RDF 中直接 的描述这种结构（例如：把地址看作是由街区（street），城市（city），州（state）， 和邮政编码（postal code）这四个部分构成的一个组），就必须把这个 N 元关 系分解为一组二元关系。空节点提供了一种完成这个任务的方法：对于每一个 N 元关系，选择其中的一元（ participant）作为这个关系的主体（比如 John）， 创建一个空节点来描述其余的关系（比如 John's address），这个 N 元关系的 其他元（比如 city）则被描述成由空节点标识的新资源的各个单独的属性