面向资源的架构:信息,而非容器

万维网因其主要的使用体验集中于文档而被认为是文档网络。就文档本身而言,数千年来,我们一直使用其代表的组织原则进行信息管理。该系列文章主要关
注构建数据网络,在此过程中,我们一定不要忽视文档作为数据源的观点。在早期的HTML文档中,我们通过百般努力方能从页面上提取内容,但这一个过程如此
苦痛和脆弱,以至于我们中的多数人认为这只是西西弗斯式的徒劳而将其放弃了。[译者注:西西弗斯,希腊神话中科林斯的国王,因其绑架死神而闻名,后
被众神惩罚,神祇们处罚薛西弗斯,叫他不停地把一块巨石推上山顶去,由于它本身的重量,巨石又从山顶上滚下来。他们认为没有更可怕的处罚比得过从事徒劳无
功和毫无希望的工作。后被阿尔贝·加缪塑造为一个悲剧式的英雄。]
。尤其是如何在页面中展现信息,根本就无标准可言,这使得在该领域的努力更加徒
劳。随着新技术的不断涌现,在网络上为可提取内容进行编码变得越来越容易了。在以后的文章中,我们会着眼于那些可以从无结构的信息中提取出结构化信息的技
术。目前,我们将重点关注制作者如何提高文档的机器可处理性。

微格式

虽然大多数人在屏幕抓取上灰头土脸、败下阵来,但是一个意志坚定的社区却脱颖而出,她对于在文档中编码语义内容的前景被忽视甚为不满。因而,微格式
得以作为一种小规模、目标明确、特定领域的命名规则而创立,它可以将特定类型的数据织入HTML中。日历、评论、人员、组织和提纲,这些都是使用它描述实
际的,有用的信息的例子。提倡者很清楚这些努力首先是面向人的,其次才是机器。他们并不想要任何专用工具,或者新的语言,亦或是任何对大型语义网络显而易
见的修饰。这其实是一个语义化网络的努力。

这里我们看看hReview,它是一种围绕电影评论进行表述的微格式。hReview特有的部分加粗表示。请注意,它并不遵从某种命名规则,看起来它与标签设计师和Web开发者已经习惯的用法极为相像。

<div class="hreview">
<span class="reviewer vcard">
<span class="fn">O. Dinn</span>,
<abbr class="dtreviewed" title="20100412">April 12th, 2010</abbr>

</span>
<div class="item">
<a lang="en" class="url fn" href="http://www.imdb.com/title/tt0800369/">Thor</a>
</div>

<div>Rating: <span class="rating">5</span> out of 5</div>
<div class="description">

<p>Better than "Iron Man"!.</p>
</div>
</div>

小目标往往更易于实现,但其带来的收益通常也不大。因此,微格式一直在特定领域里收获有限的成功。然而,它们的限制使其无法满足那些有着更多需求的
大社区。就各种微格式而言,并不存在统一的数据模型。虽然每种单独的格式都有各自的软件库来解析和提取信息,但却无法将不同的格式联系在一起。同时,对构
建实体和关系的全局引用也无能为力,所有事情都聚焦于文档域的内容。而且也没有命名空间来防止偶然的命名冲突。

多数微格式的开发者对这些大问题的解决毫无兴趣,也不关心微格式立刻应用在更大的场景中。好在群组一直保持活跃,并且在这一主题上有一本非常受欢迎
的新书刚刚出版。不过,这些成功刺激了人们去寻求可以受益于这种数据编码方法的更宽泛的解决方案。好消息是,支持更大的场景变得更容易了,同时,我们能将
微格式社区已经贡献的财富收归己用。

GRDDL

需要解决的首要问题之一是:如何从使用微格式编码的页面中一致地获取语义内容。一种办法是使用称之为“从方言中采撷资源描述(GRDDL)”的技术。这个方法对不同的文档格式有更广泛的适用性,就(X)HTML而言,其工作方式如下:为了向客户端指示某个页面中包含可提取的内容,文档要使用GRDDL的元数据概要(profile)信息进行自我标识:

<head profile="http://www.w3.org/2003/g/data-view">

元数据概要由HTML 4
入,其目的是为了让作者向客户端提供一种或多种文档查看或分类的方法。在这里,它指的是,当客户端发现该概要时,它会预期在<head>元素
内发现一个或多个<link>元素,每个<link>元素都有一个transformation类型的rel属性。这些链接指向
了将用来从文档中提取特定元数据的XSLT样式单的位置。

<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokFOAF.xsl" />
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokCC.xsl" />
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokGeoURL.xsl" />

我们这里看到的是可用来提取Dubin Core的出版元数据、Creative Commons的许可信息、以及地理位置信息等的链接。客户端可以自由地决定他们将采用哪个转换(transformation):查找已知的样式单还是简单地全部都用。为了解其实际工作情况,让我们看一个规范的GRDDL页面,Joe Lambda’s Homepage。这里看到的是人类可阅读的版本:

但我们也可以注意到隐藏其背后的元数据:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head profile="http://www.w3.org/2003/g/data-view">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Joe Lambda's Home page [an example of RDF in XHTML]</title>

<link rel="schema.DC" href="http://purl.org/dc" />
<link rel="meta" type="application/rdf+xml" title="FOAF"
href="http://www.w3.org/2000/06/webdata/xslt?xslfile=
http%3A%2F%2Fwww.w3.org%2F2003%2F11%2Frdf-in-xhtml-processor;xml
file=http%3A%2F%2Fwww.w3.org%2F2003%2F12%2Frdf-in-xhtml-xslts%2Fcomplete-example.html"
/>
<meta name="DC.Title" xml:lang="en" lang="en"
content="Joe Lambda Home page as example of RDF in XHTML" />
<meta name="DC.Creator" content="Joe Lambda" />
<meta name="DC.Description" xml:lang="en" lang="en"
content="home page for the infamous Joe Lambda, with the purpose of demonstrating how to mix
several RDF vocabularies in XHTML"


/>
<meta name="DC.Publisher"
content="W3C - World Wide Web Consortium - http://www.w3.org" />
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokFOAF.xsl" />
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokCC.xsl" />
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokGeoURL.xsl" />
<link rel="transformation" href="/2000/06/dc-extract/dc-extract.xsl" />
<link rel="transformation" href="/2000/08/w3c-synd/home2rss.xsl" />


<link rel="stylesheet" href="/StyleSheets/base" />
<link rel="stylesheet" type="text/css" href="/QA/2002/12/qa4.css" />
<meta name="ICBM" content="39.2975, -94.71388888888889" />
</head>

<body>

<div class="foaf-person">

<h1>Joe Lambda's homepage</h1>
.
.
.

这里
示了从这个页面提取的信息。这个链接指向的服务会获取一个连接上述文档的引用,并将它发现的XSLT样式单应用其上。注意:一些浏览器(我告诉你,就是
Safari)在处理这些内容时表现的不佳。如果结果看上去不像正确的RDF/XML,那就试试Firefox或者其它浏览器。

这个方法要求文档制作者遵循XSLT样式单所期望的命名规范。一旦完成,无论何种客户端,在获取页面时都可以发现链接并进行转换。GRDDL即可以
与RDF编码的数据协同工作,也可以与微格式数据亲密合作,这些微格式数据能够动态转换成RDF数据。我们可以使用RDF的开放扩展数据模型将来自不同编
码的信息汇聚成相同的输出模型。HTML
5已经舍弃了profile属性。取而代之的是一种新机制,以用来表明存在可用于GRDDL的内容。GRDDL的其余机制仍将继续发挥作用。

然而,问题依旧存在,每种样式单都定义了各自的规范来表述其信息。由于这样和那样的原因,语义网社区为在文档中编码丰富的元数据寻找了一种通用的解决方案,RDFa应运而生。

HTML 5包含的微数据(microdata)是一种比微格式更通用的语义标签方法。由于它与RDFa的范围并不一致,而且它仍在开发之中,所以我们目前不打算关注它。

RDFa

RDFa是将资源描述框架(RDF)模型编码到结构化文档中的标准方法。虽然我们在这篇文章中仅关注XHTML,但对于HTML 5SVG、甚至是开放文档格式(ODF)都有大量的建议规范和指导作用。

RDFa最初是作为W3C的注释由Mark Birbeck提出的,自诞生以来它已经成为了W3C的正式建议,得到快速发展。当然,并非没有批评的声音,但规范的新版本在保持向后兼容性的基础上正在努力尝试解决这些问题。

RDFa指定了下述属性类型来编码RDF内容:

属性 描述
@rel 资源之间的关系
@rev 反向关系
@content 机器可读的内容(文字)
@href URI (资源对象)
@src URI (嵌入式兑现)
@about 主题定义
@property 主题—值的关系
@resource 不可点击的资源的关系
@datatype 数据类型的关系
@typeof RDF类型/实例的关系

让我们看看如何着手将一些信息编码到一个XHTML示例文件中。在这个例子中,通过一个页面记录了某个会议的信息。它的信息即包含了会议什么时候举办、在哪里举办、也有谁将参加、以及为什么我们要关注它等信息。

这个人类可读的页面(以及它简朴的风格)使我们可以直观的得到我们需要的信息,但如果打算用软件来提取这些信息,我们就需要用某种方式来对它进行编
码。作为开始,我们需要定义文档类型以及将在整个文档中使用的所有XML命名空间前缀。接下来我们将会看到,其它作用于文档某些部分的命名空间可本地化到
文档的某个特定部分。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dc="http://purl.org/dc/terms/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:cal="http://www.w3.org/2002/12/cal/icaltzd#">

<head>
<title>QCon Tokyo 2010</title>
</head>
.
.
.

我们已经介绍了一系列标准的前缀映射(XHTML、RDF和RDFS),也介绍了用来描述机器可处理的方法中事件的词汇。除了已定义的词汇(如,都柏林核心),我们也为朋友之友(Friend-of-a-Friend)日历信息定义了词汇。之所以定义前缀,是因为URI和URL非常难用。我们不想将又长又累赘的数据返回给客户端,或者强制开发者和设计人员一遍又一遍的输入这些数据。因此,初始的RDFa规范选择使用称为CURIE的紧凑符号系统来表示URI。

下一步是指定一个讨论主题。由于文档中可能会描述很多主题,所以对于这些主题的引入位置必须小心谨慎。它们是分级的,而且如果不注意的话,你很可能会干涉某个已存在的主题。为了声明一个新主题,我们将使用about属性。

<body>
<div about="http://qcontokyo.com#qcontokyo2010" typeof="cal:Vevent">
<p>Please join us at
<a property="cal:summary" href="http://qcontokyo.com">QCon Tokyo 2010</a> to be held at
<span property="cal:location">Tokyo Midtown Conference Center</span>

from <span property="cal:dstart" datatype="xsd:date">2010-04-19</span> to
<span property="cal:dtend" datatype="xsd:date">2010-04-20</span>.
</p>
</div>

.
.
.

最终,我们获得了一个标准XHTML和RDF元数据的混合物。我们首先就是把主题的URL——
http://qcontokyo.com#qcontokyo2010——标识为一个主题。接下来,我们通过使用属性
typeof="cal:Vevent"来表明主题的类型。这等价于下列RDF:

<http://qcontokyo.com#qcontokyo2010> rdf:type cal:Vevent . 

换句话说,(该文档的)URL指向某个Vevent
事物。至此,我们已经描述了一个RDF事实(fact)——这到底是在做什么呢?我们已经用片段标识符来表示“Qcon东京2010这一概念”。也许来年
仍会使用同样的URL,但用于表述QCon东京2011的事实(fact)将会与现在的不同。另外,网页本身并不是一个事实,它只是被人们用来描述事件而
已。就主题而言,文档的URL可能不是一个合适的选择。我们在以后的文章里将会介绍其他处理这种差异的方法。现在,我们将继续使用片段标识符

接下来的事实使用property属性来表示已定义的主题标识与值之间的关系。如果我们不得不为了人和机器而复制重复,那将是一个既浪费又愚蠢的办
法,因此,我们尽力为这两个消费者仅表示一次数据。RDFa解析器会从property属性所附属的元素的文本节点(text
node)中将值取出来。现在,我们得到了第二个事实。

<http://qcontokyo.com#qcontokyo2010> cal:summary "QCon Tokyo 2010" .

谓词cal:location使用了基本相同的方式来表示事实。现在我们来做点有趣的事——发布包含数据类型的事实。在这个例子里,我们打算表示事
件的开始和结束日期。我们不仅要使用关系cal:dstart和cal:dtend,还要指明对象的文本值应该解释为“xsd:date”类型。解析
后,RDFa解析器将产生像这样的结果:

<http://qcontokyo.com#qcontokyo2010> <http://www.w3.org/2002/12/cal/icaltzd#dstart> 
"2010-04-19"^^<http://www.w3.org/2001/XMLSchema#date> .
<http://qcontokyo.com#qcontokyo2010> <http://www.w3.org/2002/12/cal/icaltzd#dtend>
"2010-04-20"^^<http://www.w3.org/2001/XMLSchema#date> .

我们当然期望能够更多地表示与事件本身相关的信息,但估计我们顶多只能变着花样使用我们所学的知识。如果想要增加其它词汇,你只需简单地设置适当的
前缀映射就可以了。再让我们介绍一些新的主题和结构。为了吸引人们参加会议,我们需要激起他们对演讲者的兴趣。假如演讲者有一些吸引人的著作,我们应该突
显这些事实。

<div>
<p>You will hear from:
<ul>
<li resource="urn:ISBN:0596517742">
<span rel="dc:creator">
<a href="http://qcontokyo.com/speaker_DouglasCrockford.html#doug"

typeof="foaf:Person" property="foaf:name">Douglas Crockford</a>

</span>, author of <span property="dc:title">"JavaScript: The Good
Parts"

</span>
</li>
<li resource="urn:ISBN:0201633612">

<span rel="dc:creator">
<a href="http://qcontokyo.com/speaker_ErichGamma.html#erich"

typeof="foaf:Person" property="foaf:name">Erich Gamma</a>
</span>, author of <span property="dc:title">"Design Patterns :
Elements of Reusable Object-Oriented Software"


</span>
</li>
<li resource="urn:ISBN:0978739213">
<span rel="dc:creator">
<a href="http://qcontokyo.com/speaker_MichaelNygard.html#mike"

typeof="foaf:Person" property="foaf:name">Mike Nygard</a>

</span>, author of <span property="dc:title">"Release It!"
</span>
</li>
</ul>
</p>

</div>

我们使用resource属性介绍了三个新主题。因为我们选择了它们的URN来进行标识,所以对于每一本书都有一个有效的URI来唯一地标识它,但
又不会被人点击到。另一方法是链接到一个在线图书经销商或者出版商的页面。应该注意到,每个<li>元素仅使用一个东西界定其范围。这里,我
们选择使用书籍,而不是作者来作为主题的目的是让主题应用于它下面的整个层次范围。而后续定义的任何属性将应用新引入的主题,而不是上面的事件。在表示著
作权时,我们使用了dc:creator关系。

我们也使用作者的个人会议页面来标识他们。每个演讲者都有一个页面,并且彼此不同。处于相同的原因,即一个页面并不是一个演讲者。所以,对于演讲者,我们仍旧使用片段标识。

我们最后要讨论的是如何标识文档自身的创作共用许可。我们不再谈论事件或者其声名斐然的作者,而是关注实际的文档问题。这里,我们使用如下的代码块来标识版权由谁维护,与页面关联的许可权,以及当人们要使用页面的某些章节时,需要如何声明其出处。

    <div id="foot">
<a rel="license" href="http://creativecommons.org/licenses/by-nc/3.0/us/">
<img alt="Creative Commons License" style="border-width:0"
src="http://i.creativecommons.org/l/by-nc/3.0/us/88x31.png" />
</a>
<br/>

This document, <span xmlns:dc="http://purl.org/dc/elements/1.1/"
property="dc:title">QCon Tokyo 2010</span>, by <a
xmlns:cc="http://creativecommons.org/ns#" href="http://bosatsu.net"
property="cc:attributionName" rel="cc:attributionURL">Brian Sletten</a
>
is licensed under a <a rel="license"
href="http://creativecommons.org/licenses/by-nc/3.0/us/"
>Creative Commons
Attribution-Noncommercial 3.0 United States License</a>.
</div>

</body>
</html>

注意,可以在任意块中引入新的命名空间前缀,例如这里就是页脚。如果文档的其它地方没有创作共用方面的内容,就没有必要为整个文档添加相应的前缀。
RDFa的目的之一就是让文档的各个部分从元数据的角度看是自包含的。未来的工具将能为拷贝和粘贴的文档部分提取出相应的元数据。

提取

我们已经为整个文档做了标记,那么要怎么提取它呢?需要使用RDFa解析器。虽然不同语言都有若干可用的解析器,但我们将使用Damian Steer的Java RDFa解析器,因为它非常简单。首先,把该文件保存到本地。然后下载解析器,并使用如下的命令来运行它:

java -jar java-rdfa-0.4-SNAPSHOT.jar qcon.html

请使用你实际下载的版本,并将其指向你所命名的文件。在运行之后,你应该看到所有RDF事实都打印出来了(每个相关主题也被显示地召集起来了)。

<http://qcontokyo.com/> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.w3.org/2002/12/cal/icaltzd#Vevent> .
<http://qcontokyo.com> <http://www.w3.org/2002/12/cal/icaltzd#summary>
"QCon Tokyo 2010" .
<http://qcontokyo.com/> <http://www.w3.org/2002/12/cal/icaltzd#location>
"Tokyo Midtown Conference Center" .

<http://qcontokyo.com/> <http://www.w3.org/2002/12/cal/icaltzd#dstart>
"2010-04-19"^^<http://www.w3.org/2001/XMLSchema#date> .
<http://qcontokyo.com/> <http://www.w3.org/2002/12/cal/icaltzd#dtend>
"2010-04-20"^^<http://www.w3.org/2001/XMLSchema#date> .
<http://qcontokyo.com/speaker_DouglasCrockford.html#doug> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>

<http://xmlns.com/foaf/0.1/Person> .
<urn:ISBN:0596517742> <http://purl.org/dc/terms/creator>
<http://qcontokyo.com/speaker_DouglasCrockford.html#doug> .
<http://qcontokyo.com/speaker_DouglasCrockford.html#doug> <http://xmlns.com/foaf/0.1/name>
"Douglas Crockford" .
<urn:ISBN:0596517742> <http://purl.org/dc/terms/title>
""JavaScript: The Good Parts"" .

<http://qcontokyo.com/speaker_ErichGamma.html#erich> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://xmlns.com/foaf/0.1/Person> .
<urn:ISBN:0201633612> <http://purl.org/dc/terms/creator>
<http://qcontokyo.com/speaker_ErichGamma.html#erich> .
<http://qcontokyo.com/speaker_ErichGamma.html#erich> <http://xmlns.com/foaf/0.1/name>
"Erich Gamma" .

<urn:ISBN:0201633612> <http://purl.org/dc/terms/title>
""Design Patterns : Elements of Reusable Object-Oriented Software"" .
<http://qcontokyo.com/speaker_MichaelNygard.html#mike> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://xmlns.com/foaf/0.1/Person> .
<urn:ISBN:0978739213> <http://purl.org/dc/terms/creator>
<http://qcontokyo.com/speaker_MichaelNygard.html#mike> .

<http://qcontokyo.com/speaker_MichaelNygard.html#mike> <http://xmlns.com/foaf/0.1/name>
"Mike Nygard" .
<urn:ISBN:0978739213> <http://purl.org/dc/terms/title>
""Release It!"" .
<file:///Users/brian/Dropbox/Documents/Writing/InfoQ/ROA-3/qcon.html> <http://www.w3.org/1999/xhtml/vocab#license>
<http://creativecommons.org/licenses/by-nc/3.0/us/> .

<file:///Users/brian/Documents/Writing/InfoQ/ROA-3/qcon.html> <http://purl.org/dc/elements/1.1/title>
"QCon Tokyo 2010" .
<file:///Users/brian/Documents/Writing/InfoQ/ROA-3/qcon.html> <http://creativecommons.org/ns#attributionURL>
<http://bosatsu.net> .
<file:///Users/brian/Documents/Writing/InfoQ/ROA-3/qcon.html> <http://creativecommons.org/ns#attributionName>
"Brian Sletten" .

<file:///Users/brian/Documents/Writing/InfoQ/ROA-3/qcon.html> <http://www.w3.org/1999/xhtml/vocab#license>
<http://creativecommons.org/licenses/by-nc/3.0/us/> .

我们已经很容易地从这个页面得到了许多有用信息。这种事情对于浏览器、代理服务器(proxy)或者其它理解HTTP协议的代理(agent)都是
相当简单的。然而,我们无需等到这样的支持被加入后才开始设想使用这些信息。我们可以将RDFa的扩展代码包装成一个服务。W3C使用了RDFa蒸馏器,它是由Python实现的,如果你经常使用,可以把它下载到本地执行。目前,我们用该文档的网络版来调用这个服务:

http://www.w3.org/2007/08/pyRdfa/extract?uri=http%3A%2F%2Fbosatsu.net%2Fqcon.html&format=pretty-xml&warnings=false&parser=lax&space-preserve=true

这个URL指向一个服务,该服务以一个URL为数据源,并将提取到的信息以RDF文档的形式返回。因此,可以通过上面的URL对这个生成的RDF文档进行网络寻址。

为了理解其重要性,我们必须回想一下从该系列文章所学的知识。在第一篇文章中,我们了解到REST的URL命名规范和内容协商如何让我们以统一的方式来访问文档、数据和服务。在第二篇文章里,
我们学习了RDF的术语和概念以及如何查寻RDF数据源。将这些合到一起(包括我们用指向服务的URL来从文档中提取内容),我们便可以使用SPARQL
查寻作为数据库的文档,现在就能够将文档纳入我们的工作流了。设想我们要查找页面中提到的每个作者的名字和对他们著作的索引。当使用复合URL,下面的
SPARQL将完成这个工作:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/terms/>

select ?name ?title where {
?book dc:creator ?author ;
dc:title ?title .
?author foaf:name ?name .
}

通过Leigh Dodd的SPARQL工具Twinkle,可以看到这个问题的答案:

要完全理解这个新能力意味着什么可能需要一些时间,但我们鼓励你为此深思熟虑一番。

多年来,批评者一直嘲笑愿意按这一方式标注内容的人们,但在接下来的部分,我们将会看到,他们完全错了。另外,如果通过程序来生成页面,你会充满希望的发现,发布织入这些属性的XHTML来促进机器的可处理能力是多么得简单。

试想一下,如果一个报告中的科学或财务数据是可以直接提取的。“就这个报告中显示的本季度市场上的顶级制造企业,对于每个公司,你可以在我们的数据
库中进行查询,看看他们在过去的表现”。你的组织越是致力于使用REST, RDF和RDFa,这样的查寻就越强大,也会越简单。

网上

如果这仅仅是语义网工具箱里的一个花哨的新工具,那么即便它颇具威力,它也不是人们急切需要的。如果看一下RDFa是如何被采纳的,以及早期对其好处的分析,我们就会明白这为什么如此重要。

  • 首先,主流的开源软件,如DrupalMediaWiki,都已开始对RDFa提供直接的支持。
  • 美国英国的政府均采用这种方式发布大量数据。(这方面,英国是赢家)
  • O’Reilly已经开始用RDFa标注其所有的目录以及良好关系词汇。
  • 大型零售商,如TescoBestBuy,也将良好关系和RDFa用于其产品和商铺的页面上。特别是BestBuy,他们已经看到采用这些技术后所产生的流量骤然增加。当然,将其仅仅归因于RDFa元数据是草率的,但至少RDFa元数据是一个贡献因素,而且其他人也开始观察到类似的上升。
  • Google已开始用微格式和RDFa为涉及大众、评论以及视频内容的词汇建立索引
  • Yahoo在Search Monkey上的工作正在为如何扩展对其它元数据类型的支持添砖加瓦。
  • 网络上的歌曲和其它内容正在使用创作共用来标识其版本信息。

要想理解创作共用在这方面是如何创新的,我们可以回顾一下会议页面,来看看我们是如何在页脚标识版本信息的。如果直接点击当前页面上的版本链接,你会得到一个有关版本定义的通用描述。

然而,如果你是通过会议页面的网络访问版来点击该链接,那边你会看到一些独特的东西:

发生了什么?!?

当你点击链接时,创作共用服务器会得到一个到HTTP
Referrer的引用。接着,它会从该访问来源(referrer)获取内容、解析、然后提取与版本信息有关的任何东西。如果发现了有关信息,它就会基
于这些信息生成特定的响应。在我们的例子里,是我们提供的属性名和URL。

事实上,我们在链接里提供元数据,然后其他服务器据此给出响应。这样,链接就不再仅仅是链接了。你获得的响应依赖于你是通过那个“门”过来的。查询
参数曾经在某些方面给予了我们这样的能力,但是从基于拉动的观点来看,我们应当可以响应任何输入,而不仅仅是那些我们所要求他们输入的。我们正在接受任意
的、可全局解析的元数据。

展望

RDFa
1.0赢得了很多人的热捧,但仍有一些批评意见。一些人非常担心命名空间的分级作用域以及CURIE的使用。在一个命名空间中得以解析的元素,由于自身的
移动或者其它命名空间的抢先,它可能会被解析(或者是无法解析)。虽然更好地使用工具对此有所帮助,但RDFa
1.1也希望借助在属性中使用全限定的术语引用来解决一些问题。

RDFa工作组正将RDFa 1.1拆分成几个部分,包括了Core、API和使用文档。他们为来年制定了一份大胆的进度表,好在是,进展迅速。2010年4月15日,工作组同意发布RDFa Core 1.1和XHTML+RDFa 1.1修改。这其中包含了多种方法以用来表示前缀映射、xmlns前缀的过期提示、关于RDFa概括(RDFa Profiles)的想法和其它更多东西。一些新的属性被用来支持这些功能:

属性 描述
@vocab 建立缺省的词汇表
@prefix 建立前缀映射
@profile 制定RDFa概要(profiles)

 无论作为生产者还是消费者,这样的技术都是非常令人兴奋的。链接标识相关性,当你赋予内容更多的关联,它就获得了更多的相关性。我们由搜索排名入手来了解它的好处,但现在,我们也可以着手跨站点聚合信息了。排名信息不再需要由一个站点来维护(这会导致向不当影响收费),而是可以由多个位置收集得出。

尽管,这里主要的进步不过是文档成为了又一种数据源。但是,网络让我们忘掉了计算机,转而关注文档。而语义网络又使我们关注于信息,而不是信息的容
器。同样的SPARQL查询所能包含的内容可以来自于关系数据库、REST服务、本地RDF三元组仓库(triplestores)、以及如今的文档。我
们共享给他人的编码信息对于软件来说也不再是不可以访问的了。虽然我们需要更好的工具和支持才能充分利用这些新兴技术,但这已经成为一个何时发生的问题,
而不是是否会发生的问题了。

结语

就在我刚刚把这篇文章提交InfoQ发布后不久,F8会议举办,Facebook在会议上放出消息,他们正在“基于RDFa”将类似语义网的元数据编入HTML。很明显,他们正打算拥有所有这些关系,但总的来说,这将作为这些概念的很好证明。就分布式创新为什么如此牛逼,Ben Adida给出了一个富有思想的回答。

另外,W3C发布了XHTML模块化RDFa 1.1 并正在收集反馈。Ivan Herman发起了一个有价值的讨论,来探讨哪些是新的,以及有哪些不同。

以上这些都强调了本文的主题的流行,并且映衬了我原文中最后一句话所表达的必然性:“这已经成为一个何时发生的问题,而不是是否会发生的问题了。”

查看英文原文:Resource-Oriented Architecture: Information, Not Containers


感谢马国耀对本文的审校。

This entry was posted in Achitecture. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s