materials_5-语义web_RDF 入门推荐标准 TransWiki - W3CHINA.ORG 开放翻译计划（OTP）.doc_P26-P30

有些资源可能没有URI,空节点也同样提供了一种更准确的发表关于这些资源的陈述的方法,但这是通过和那些有URI的资源的关系来描述的。例如:当发表个关于某人(比如 Jane Smith)的陈述的时候,可能会很自然的想到要用基于这人的emai1地址的URI作为她的URI( mailto:jane@ example,org),但是, 这种方法可能会导致一些问题。如果需要同时记录关于Jane(比如她目前的实际住址)和她的邮箱(比如,它所在的服务器)两者的信息,那么,还用基于她邮箱地址的URI作为她的 URIref的话,就会很难区分表述的到底是Jane还是她的邮箱。同样的问题也会出现在下面这种情况:当一个公司用它公司的网页URL (比如:http://www.example.com/)作为自己的URI的时候。同样地,当需要同时记录关于网页(比如:是谁于何时创建的)和这个公司两者的信息时,如果还用"http://www.examplecom 两者的标识符,就会导致很难区分谁是真正意义上的主体这些问题出现的根本原因就是:用Jane的邮箱来代表Jane是不正确的,因为 Jane和她的邮箱根本就是两码事,因此她和它应该区别对待。当Jane自己没有时,空节点提供了一条为这种情形更正确的建模方法:Jane可以由一个空节点表示,并且用这个以“ exterms: mailbox”为属性的空节点作为陈述的主体且用 URIref“ mailto:iane@ example. org”作为它的这个属性的值。这个空节点也可以用以“ exterms: Person”为值的一个“rdf:type”属性来表述(类型 (type)将在以后章节做更详细的讨论),或者是其他有用的描述性信息,正如下列三元组所示的: jane exterms: mai l box <mai lto: jane @example. or g&gt jane rdf: type exterms: Person exterms: name Jane Smith exterms: emp ID 23748" ane exterms: age (注意在第一个三元组中“ mailto: iane@example.org”写在两个尖括号里面, 这是因为“ mail to: iane@example.org”在 mail to uri模式中是个完整的 URIref,而不是一个 QName缩写,在三元组表示法里一个完整的 URIref必需写在一对尖括号内。) 这些三元组准确地说明了:“有一个资源,其类型为 exterms: Person,其电子邮箱是由“ mailto:iane@ example.org”来标识的,其名字是 Jane Smith,等等”。就是说,空节点可以读作“有一个资源”。以这个空节点作主体的陈述就提供关于这个资源特性方面的信息

有些资源可能没有 URI，空节点也同样提供了一种更准确的发表关于这些资源的陈述的方法，但这是通过和那些有 URI 的资源的关系来描述的。例如：当发表一个关于某人（比如 Jane Smith）的陈述的时候，可能会很自然的想到要用基于这人的 email 地址的 URI 作为她的 URI（mailto:jane@example.org ），但是，这种方法可能会导致一些问题。如果需要同时记录关于 Jane（比如她目前的实际住址）和她的邮箱（比如，它所在的服务器）两者的信息，那么，还用基于她邮箱地址的 URI 作为她的 URIref 的话，就会很难区分表述的到底是 Jane 还是她的邮箱。同样的问题也会出现在下面这种情况：当一个公司用它公司的网页 URL （比如：http://www.example.com/）作为自己的 URI 的时候。同样地，当需要同时记录关于网页（比如：是谁于何时创建的）和这个公司两者的信息时，如果还用“http://www.example.com/”作为两者的标识符，就会导致很难区分谁是真正意义上的主体。这些问题出现的根本原因就是：用 Jane 的邮箱来代表 Jane 是不正确的，因为 Jane 和她的邮箱根本就是两码事，因此她和它应该区别对待。当 Jane 自己没有 URI 时，空节点提供了一条为这种情形更正确的建模方法：Jane 可以由一个空节点表示，并且用这个以“exterms:mailbox”为属性的空节点作为陈述的主体，且用 URIref“mailto:jane@example.org” 作为它的这个属性的值。这个空节点也可以用以“exterms:Person”为值的一个“rdf:type”属性来表述（类型（type）将在以后章节做更详细的讨论），或者是其他有用的描述性信息，正如下列三元组所示的： _:jane exterms:mailbox <mailto:jane@example.org> . _:jane rdf:type exterms:Person . _:jane exterms:name "Jane Smith" . _:jane exterms:empID "23748" . _:jane exterms:age "26" . （注意在第一个三元组中“ mailto:jane@example.org”写在两个尖括号里面，这是因为“mailto:jane@example.org” 在 mailto URI 模式中是个完整的 URIref，而不是一个 QName 缩写，在三元组表示法里一个完整的 URIref 必需写在一对尖括号内。）这些三元组准确地说明了：“有一个资源，其类型为 exterms:Person，其电子邮箱是由“mailto:jane@example.org” 来标识的，其名字是 Jane Smith，等等”。就是说，空节点可以读作“有一个资源”。以这个空节点作主体的陈述就提供关于这个资源特性方面的信息

实际上,在这些情况下用空节点替代 URIref并不会在信息处理方面带来太多改变。例如:人们知道一个 email地址唯一确定在 example.org里的某人(特别地, 如果这个地址不能被重用的话),那么,这个 email地址会被用来聚集来自多个数据源的关于这个人的信息。尽管这个 email地址不是这人的URI。在这种情况下,如果在Web上找到了一些描述一本书的RDF,并且给出了作者的联系资料如 mail to: jane example,org,那么把这条新信息和先前的一套三元组结合起然后推断作者的名字是 Jane smith,这样做就可能是合理的。这种说法的关键有点像"这书的作者是 mail to; jane@example,org"是“这书的作者是邮箱是 mailto;jane@ example,org的某人"的一种典型的缩写一样。用一个空节点来表示这个“某人”是一种更准确地来表示真实世界的方法。(顺便说一下,一些基于RDF的模式语言特别指出允许某些属性可以作为它们描述的资源的”唯一标识符“。这些将在5.5节 (http://www.w3.org/tr/2004/reC-rDf-primer-20040210/#ricHersChEmas)fth 更深入的探讨。) 这种使用空节点的方法也可以帮助人们避免文字( literals)在可能不适当情况下的使用.例如:当描述Jane的书而又缺少一个识别作者的 URIref时,出版商就可能这样写(使用出版商自己的 externs:词汇表 ex2terms: book78354 rdf: type ex2terms: Book ex2terms: book78354 ex2terms author "Jane Smith 但是,书的作者却不是字符串“ Jane Smith”,而是一个名叫 Jane Smith的人。于是,当出版商用一个空节点时相同的信息就可能会被更准确的表达出来: ex2terms: book78354 rdf: type ex2terms: Book ex2terms: book78354 ex2terms author author 78354 author 78354 rdf: type exterme: Per son author 78354 ex2terms: name Jane Smith 这实质上说,“ex2 terms:book78354”的类型是“ex2 terms:book”,并且它的作者是类型为“ex2 terms: Person”的一个资源,作者的名字是“ Jane Smith 当然,在这个特例中,出版者为了要鼓励对作者的外部引用,可能对作者指派他自己的 URIrefs而不是使用空节点识别他们最后,上面的例子给出了Jane的年龄是26说明了这么一件事实就是:有时一个属性的值可能表面上看来很简单,但实际上可能会更复杂。在这种情况,Jane

实际上，在这些情况下用空节点替代 URIref 并不会在信息处理方面带来太多改变。例如：人们知道一个 email 地址唯一确定在 example.org 里的某人（特别地，如果这个地址不能被重用的话），那么，这个 email 地址会被用来聚集来自多个数据源的关于这个人的信息。尽管这个 email 地址不是这人的 URI。在这种情况下，如果在 Web 上找到了一些描述一本书的 RDF，并且给出了作者的联系资料如 mailto:jane@example.org，那么把这条新信息和先前的一套三元组结合起来，然后推断作者的名字是 Jane Smith，这样做就可能是合理的。这种说法的关键有点像"这书的作者是 mailto:jane@example.org"是“这书的作者是邮箱是 mailto:jane@example.org 的某人"的一种典型的缩写一样。用一个空节点来表示这个“某人”是一种更准确地来表示真实世界的方法。（顺便说一下，一些基于 RDF 的模式语言特别指出允许某些属性可以作为它们描述的资源的”唯一标识符“。这些将在 5.5 节 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#richerschemas)做更深入的探讨。）这种使用空节点的方法也可以帮助人们避免文字（literals）在可能不适当情况下的使用.例如：当描述 Jane 的书而又缺少一个识别作者的 URIref 时，出版商就可能这样写（使用出版商自己的 ex2terms:词汇表）： ex2terms:book78354 rdf:type ex2terms:Book . ex2terms:book78354 ex2terms:author "Jane Smith" . 但是，书的作者却不是字符串“Jane Smith”，而是一个名叫 Jane Smith 的人。于是，当出版商用一个空节点时相同的信息就可能会被更准确的表达出来： ex2terms:book78354 rdf:type ex2terms:Book . ex2terms:book78354 ex2terms:author _:author78354 . _:author78354 rdf:type ex2terms:Person . _:author78354 ex2terms:name "Jane Smith" . 这实质上说，“ex2terms:book78354”的类型是“ex2terms:book”，并且它的作者是类型为“ex2terms:Person”的一个资源，作者的名字是“Jane Smith”。当然，在这个特例中，出版者为了要鼓励对作者的外部引用，可能对作者指派他自己的 URIrefs 而不是使用空节点识别他们。最后，上面的例子给出了 Jane 的年龄是 26 说明了这么一件事实就是：有时一个属性的值可能表面上看来很简单，但实际上可能会更复杂。在这种情况，Jane

的年龄实际上是 26 岁，但是单位量（岁）没有明确给出。当确信某个访问文本中属性值的人由此能推定所使用的单位量时类似的单位量经常被省略。但是，在 Web 上无际的文本海洋里，这样的“确信”通常是不可靠的，例如：一个美国地址也许给定一个重量单位－－磅，但是某个从外部访问这个数据的人可能会推想给定的单位是千克。总的来说，对于单位或是类似的信息应该经过缜密的考虑然后进行明确的表述。这个问题将会在 4.4 节 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue)做更深入的探讨，在这节中将会讲述能把这样的信息表述成构造值（structured values）是 RDF 特色之一，同时也会涉及到另外一些用于表述这类信息的技术。 [编辑] 2.4 类型文字上一节讲述了怎样处理如下这种情况：用平凡文字表示的属性值分解为能表示那些文字每个单独部分的构造值。例如：如果要记录一个网页的创建日期的话，这种方法用一个专门的平凡文字作为它的值，这个值会以一个由年，月，日组成的结构体作为资料的各个部分，并分别用平凡文字来表示相应的值，就取代了通过创建一个单独 exterms:creation-date 属性来记录一个网页创建日期的方法。但是，到目前为止，所有可以在 RDF 中作为客体的常量值都用这些平凡（非类型）文字表示，甚至当意图是用数字（例如一个年份属性或是年龄属性的值）或者其他更特殊的值当作属性值时。例如，如图 4 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure4) 所示的一个记录关于 John Smith 资料的 RDF 图，这个图中记录的 John Smith 的属性 “exterms:age”值为平凡文字“27”，正如图 7 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#figure7)所示的那样：图 7：表示 John Smith 的年龄

在这个例子中,假设的组织 example.org可能想要用一个数字来表示“27”,而不是用由“2”和后面的“7”组成的字符串来表示(因为文字表示了一个属性 “age”的值)。但是,图7并没有明确指出“27”应当被解释成一个数字。同样地, example.org可能也想把“27”表示成一个十进制数(比如,一个值为二十七的十进制数),而不是表示成一个八进制数(比如,一个值为二十三的八进制数)。然而,同样地,图7也没有明确指出这些信息。一些特殊的应用程序可能会在编码时把属性 exterms:age的值解释成十进制数,但这意味着对这个RDF 的正确解释会依赖RDF图中没有明确提供的信息,因而还依赖一些其他需要解释这个RDF的应用程序不一定能获取的信息。在程序设计语言和数据库系统里通常都会提供一个关于如何解释文字的附加信息:即给文字关联一个数据类型,比如在这个例子里,数据类型是小数或者是整数。一个能理解数据类型的应用程序就会知道,比如,把文字“10”表示成数字十,还是数字二,还是由字符“1”和后面的字符“0”组成的一个字符串,取决于指定的数据类型是整数,二进制数,还是字符串。(虽然这本入门文档不会详细说明关于数据类型的概念,但在2.3节 (http://www.w3.org/tr/2004/reC-Rdf-primer-20040210/#stRucTurEdpropert ies)的结尾处已经提到过更多可以用来包含单位信息的专门的数据类型,比如个为 intergerYears数据类型。)在RDF中,类型文字 (http://www.w3.org/tr/rdf-concEpTs/#dfn-typed-literal)是用来提供这类信息的。一个RDF类型文字是通过把一个字符串与一个能确定一个特殊数据类型的 URIref配对形成的。结果在RDF图中的一个文字节点就是这个配对。类型文字表示的值就是把指定的字符串赋值给指定的数据类型的值。例如,使用一个类型文字, John Smith的年龄将会被表述成在三元组中使用的整数27: <http://www.exampleorg/staffid/85740&gt:<http://www.exampleorg/terms/age&gt 27"<http://www.w3.org/2001/xmlschema#integer&Gt: 或者,使用 QName来简化URI则可写成: exstaff: 85740 exterms: age27 xsd: integer 或者,如图8所示的:

在这个例子中，假设的组织 example.org 可能想要用一个数字来表示“27”，而不是用由“2”和后面的“7”组成的字符串来表示（因为文字表示了一个属性 “age”的值）。但是，图 7 并没有明确指出“27”应当被解释成一个数字。同样地，example.org 可能也想把“27”表示成一个十进制数（比如，一个值为二十七的十进制数），而不是表示成一个八进制数（比如，一个值为二十三的八进制数）。然而，同样地，图 7 也没有明确指出这些信息。一些特殊的应用程序可能会在编码时把属性 exterms:age 的值解释成十进制数，但这意味着对这个 RDF 的正确解释会依赖 RDF 图中没有明确提供的信息，因而还依赖一些其他需要解释这个 RDF 的应用程序不一定能获取的信息。在程序设计语言和数据库系统里通常都会提供一个关于如何解释文字的附加信息：即给文字关联一个数据类型，比如在这个例子里，数据类型是小数或者是整数。一个能理解数据类型的应用程序就会知道，比如，把文字“10”表示成数字十，还是数字二，还是由字符“1”和后面的字符“0”组成的一个字符串，取决于指定的数据类型是整数，二进制数，还是字符串。（虽然这本入门文档不会详细说明关于数据类型的概念，但在 2.3 节 (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#structuredpropert ies)的结尾处已经提到过更多可以用来包含单位信息的专门的数据类型，比如：一个为 intergerYears 数据类型。）在 RDF 中，类型文字 (http://www.w3.org/TR/rdf-concepts/#dfn-typed-literal) 是用来提供这类信息的。一个 RDF 类型文字是通过把一个字符串与一个能确定一个特殊数据类型的 URIref 配对形成的。结果在 RDF 图中的一个文字节点就是这个配对。类型文字表示的值就是把指定的字符串赋值给指定的数据类型的值。例如，使用一个类型文字，John Smith 的年龄将会被表述成在三元组中使用的整数 27： <http://www.example.org/staffid/85740> <http://www.example.org/terms/age> "27"^^<http://www.w3.org/2001/XMLSchema#integer> . 或者，使用 QName 来简化 URI 则可写成： exstaff:85740 exterms:age "27"^^xsd:integer . 或者，如图 8 所示的：

materials_5-语义web_RDF 入门 推荐标准 TransWiki - W3CHINA.ORG 开放翻译计划（OTP）

materials_5-语义web_RDF 入门推荐标准 TransWiki - W3CHINA.ORG 开放翻译计划（OTP）