[转]规划语义 Web 站点

来源：http://www.ibm.com/developerworks/cn/xml/x-plansemantic/

规划语义 Web 站点 规划站点以实现结构化数据

级别： 初级

Rob Crowther ([e-mail]), Web 开发人员, 自由职业

2008 年 3 月 31 日

当用户查找他们真正感兴趣的内容时，语义 Web 可以产生更智能的搜索结果，并使站点所有者获得更多有针对性的通信。但这些优势并非唾手可得。要利用这种新兴技术，您需要在信息架构和一般性基础架构方面做好准备，本文将向您介绍这些方面。

<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --><!--END RESERVED FOR FUTURE USE INCLUDE FILES-->

本文介绍如何使您的站点成为语义 Web 的一部分。本文首先从语义 Web 尝试解决的问题入手，然后进一步介绍所涉及的技术，如资源描述框架（Resource Description Framework，RDF）、Web Ontology Language (OWL) 以及 SPARQL 协议和 RDF 查询语言 (SPARQL)。您将了解到语义 Web 如何在现有 Web 之上分层。然后介绍规划一个新 Web 站点时需要了解的一些问题，同时提供一些具体示例，演示如何使用这些技术（如 RDFa 和 Microformats）使您的现有 Web 站点成为语义 Web 的一部分。

语义 Web 简介

万维网是人类迄今为止所提供的一个最大的信息资源。不幸的是，尽管它依赖计算机执行全部的操作，但是大部分信息只有人类能够理解，而不是计算机。尽管计算机可以使用 HTML 文档的语法在浏览器中向您显示它们，但是 Web 计算机无法理解这些内容 — 即语义。

常用的缩写词 API：应用程序编程接口 HTML：超文本标记语言 URI：统一资源标识符 W3C：万维网联盟 XML：可扩展标记语言

语义 Web 是 Tim Berners-Lee 对未来 Web 的憧憬。尽管这个梦想目前还没有实现，但是现在有足够的构建块使您能够在 Web 站点中利用多种语义 Web 技术，包括 RDF、OWL 和 SPARQL。语义 Web 的目标是将大量 Web 的信息资源公开为计算机可以自动解释的数据。

Web 最初全部关于文档。只需单击 Web 浏览器中的链接，即可触发浏览器请求 Web 服务器向您发送文档，之后向您显示该文档。文档可以是下周的日程表， 也可以是来自朋友的一封电子邮件。实际上 Web 浏览器并不关心这些；它只是按照它的内部规则显示页面而已。由您来理解页面上的信息。

实现结构化数据提升了数据的价值。如果拥有了一致的结构，就可以通过多种方式使用数据。如今，在围绕 Web 站点涌现的众多 API 中，实现结构化数据的要求可以看作是 Web 2.0 发展趋势之一 — API 属于结构化数据，并且，来自各种来源的结构化数据推动着 Mashup。Mashup 背后的思想就是将数据从各种来源拉到 Web 上，并且当以一致的方式组合和显示时，将元素组合在一起实现了增值，并超过了单一信息源的价值。

语义 Web 的目标就是解决所有人构建各种 API 要解决的相同问题：将 Web 的内容公开为数据，然后采用不同的方法组合不同的数据源来实现新的价值。您不需要构建和维护您自己的 API，相反，您可以构建自己的 Web 站点以充分利用已有的语义 Web 基础结构。如果您的 Web 站点就是您的 API，则可以减少总的开发和维护。同样，不需要针对希望从中获取数据的所有 Web 站点构建自定义解决方案，您可以基于语义 Web 技术实现一个解决方案，并让其跨多个 Web 站点工作 — 包括在开始开发之前没有注意到的站点。

回页首

语义 Web 技术概述

可以从多个层次考虑语义 Web 技术，每一层都依赖和扩展其下面层次的功能。尽管经常作为一个单独的实体谈论语义 Web，但是它是现有 Web 的扩展和增强而不是一个替代品。

图 1. 语义 Web 技术堆栈

如图 1 所示，语义 Web 的底层是 HTTP 和 URI。这些通常被认为是 “Web” 而不是 “语义 Web”，但是每个被提议的语义 Web 技术都依赖于这些 Web 基础。URI 是语义 Web 的名词。HTTP 是动词：GET、PUT 和 POST 以及很多在身份验证和加密领域经过仔细测试的解决方案。

资源描述框架 (RDF) 是语义 Web 的主要组成。它是一种对关系进行编码的语法。RDF 三元组具有三个组件：主题、谓词（或动词）和目标。每个组件都可以表达为 Web 上的一个资源，即一个 URI。这比对随机 XML 文档中的数据进行编码更明确。可以将清单 1 中表达简单 XML 关系的各种方法与 清单 2 中的 RDF 三元组进行比较。

清单 1. XML 中的关系不明确

                
<author>
    <uri>page</uri>
    <name>Rob</name>
</author>

<person name="Rob">
    <work>page</work>
</person>

<document href="http://www.example.org/test/page" author="Rob" />

清单 2 显示 RDF 三元组。

清单 2. 使用 RDF 表达关系

                
<page> <author> <Rob> .

清单 1 中所有示例表达的关系都是 “Rob is the author of page”— 相当简单的语句 — 但在 XML 中采用多种方式表达。构建可以从所有可能的 XML 表达方式中得出这种关系的软件是非常困难的。但是 RDF 只采用一种方法表达这种关系，因此它可以用来构建常规分析程序。

在语义 Web 早期，人们希望内容制作者能够对其所有内容使用 RDF，并随后应用到更多数据。不幸的是，可能因为大部分 RDF 的 XML 表达似乎存在不必要的复杂性，因此很难理解。更简练的 RDF 表示方法，比如 Notation3 (N3) 和 Terse RDF Triple Language (Turtle)，虽然现在可用，但是一直没有解决这个问题（有关 N3 和 Turtle 的详细信息，请参阅 参考资料）。这个问题的解决方案是受到了 Microformats 方法的启发。借助 Microformats，通过对标准 HTML 元素和属性使用一致模式，向现有 HTML 内容中添加了语义价值。Microformats 的存在是为了服务有限但常见的数据项（如联系人信息和日历项）。W3C 等价物是 RDFa，即嵌入到 XHTML 中的 RDF 数据。该实现比 Microformats 稍微复杂一些，但它更普遍 — 对于可以采用 RDF 表达的任何内容， 都可以使用 RDFa 添加到 XHTML 文档。使用这种技术，就可以通过现有 Web 内容实现语义 Web。

当然，作为 RDFa 嵌入到 XHTML 文档中的 RDF 并不适用于需要 RDF 作为输入的所有语义 Web 工具。此处需要能够自动识别 RDFa 内容是否存在并从中提取 RDF。这个问题的 W3C 解决方案就是从语言的方言中采撷资源描述（Gleaning Resource Descriptions from Dialects of Languages，GRDDL）。其思想就是通过一个 XSL 转换运行一个现有的 XHTML 文档来生成 RDF。然后可以通过直接包含引用或间接通过配置文件和名称空间文档链接 GRDDL 转换。

尽管可以使用 RDF 明确地表达语义，但即使每个人都这样做，如果不知道如何将各个站点的 RDF 联系起来，那么也没有什么用处。 清单 2 中的 RDF 三元组用谓词表达了 author 关系，虽然对您来说含义可能非常明显，但是计算机理解起来仍然困难。如果您在站点的 RDF 文件中表达了 author 关系，那么计算机会认为它们是相同的内容吗？如果您在 RDF 三元组中表达的是 writer 关系又会怎样呢？您需要的是一种表达常用词汇的方法，以便能够说明我的 author 和您的 author 指的是同一内容，或者表明 “author” 和 “writer” 是类似的。在语义 Web 中，这个问题由本体（ontology）解决的，并且用于表达本体的 W3C 标准就是 Web 本体语言 (OWL)。OWL 本身就是一个较大的主题，但因为您仅对它在本文中的应用感兴趣，因此有关它的详细信息，请参阅 参考资料。

一旦您拥有了采用 RDF 的一些数据源，并且拥有可以确定它们之间关系的本体，那么您需要一种从中获得有用信息的方法。简单协议和 RDF 查询语言（Simple Protocol and RDF Query Language，SPARQL，发音为 “sparkle”）是一个与 SQL 类似的语法，用于针对 RDF 数据表示查询，并且查询本身外观和行为都与 RDF 数据类似。SPARQL 的基本范例就是模式匹配，其设计原理为跨 Web 工作，处理来自不同来源的数据组合，并且具有灵活性。例如，可以将匹配描述为可选，这使它在查询粗糙的数据时比 SQL 更合适。粗糙数据（Ragged data）的结构不可预测且不可靠，如果您的数据是从 Web 上的各种来源组合的，而不是来自于一个良好包含的 SQL 数据库，那么您的数据结构就是这样。

回页首

规划语义 Web 站点的注意事项

或许您已经了解到，在构建下一个重要的 Web 2.0 站点时，如果从一开始就是要语义 Web 技术并将 Web 站点转变为 API， 而不是为 Web 站点创建单独的 API，那么这样做可以节省大量时间。语义 Web 方法为您提供了免费的类似于 API 的功能。通常，API 是一种从其他非结构化的 Web 站点中获取采用 XML 或 JSON 格式的结构化数据的方法。这样导致一种双重方法：您拥有供人类使用的网页，并且拥有一个计算机可以获取结构化信息以便进行自动处理的 API。但是，这会产生额外的工作；如果您希望人们使用您的 API，则您必须将其文档化、支持它并且使其与您 Web 站点上的新功能保持同步。借助语义 Web 方法，您的 Web 站点拥有了结构化数据。您不需要单独实现。您和您的用户可以利用其他语义 Web 工具来进行自动处理。

这要求在规划时考虑一些问题。使用 API，您可以为要提交的每个信息项随意定义您自己的数据格式，在语义 Web 中，这类似于定义您自己的本体。如果缺乏经验，那么本体设计将非常困难，因此，您应该考虑现有的主要本体是否适合您计划使用的数据类型，下一节 将进一步讨论这些内容。当您设计一个 API 时，您通常还需要考虑一个用于概念结构的对象模型，以便开发人员可以理解何时获得数据项集合或只获得一些数据项，以及他们的数据项属于哪些集合。在语义 Web 站点中，这不仅仅由您选择的本体决定，而且还取决于您的 URI 方案。接下来，将查看一种方法，它可以使您的 URI 用作 API 的一部分。

最后，在现有 Web 站点上，如果您更新内容以利用 GRDDL、RDFa 和 Microformats，则您和您的用户仍然可以从语义 Web 中获益。

回页首

在现有本体上下文中评估数据

语义 Web 中比较复杂的部分就是设计一个与您的数据相匹配的本体。通常，实现正确的本体是成功实现语义 Web 项目的关键元素。幸运的是，有很多现成的本体。表 1 列出了其中的一些。

表 1. 当前 Web 使用的一些本体

Dublin Core	这种元数据元素标准用于跨域信息资源描述，提供了一组简单的标准约定，使用易于查找的方式描述联网信息。
SIOC	Semantically-Interlinked Online Communities Project 是一个本体，它采用 Internet 讨论方法表达显式和隐式包含的信息，如博客或论坛邮件列表。
FOAF	Friend of a Friend 本体描述各人及其活动，以及与其他人员和对象之间的关系。 FOAF 允许以分布式方式描述社会网络。
DOAP	Description Of A Project 是一个描述开放源码项目的本体。
ResumeRDF	该本体表达简历或履历表或 (CV)，包括诸如工作和教育经历或技能之类的信息。

此外，很多本体都是特定于诸如技术、环境科学、化学和语言学之类的领域。与上面列出的 Web 站点相比，这些本体适用的站点范围更窄。很多数据可能适合 表 1 中本体所涵盖的至少一个领域，这种情况下，您可以将它们都合并到您的规划当中。

回页首

选择语义 URI 方案

如果您的 Web 站点就是您的 API，则您的 URI 便是程序员访问以获取数据的方法。因此，合理、简洁和一致的结构非常重要，并且需要提前考虑到，因为任何项目启动之后频繁更改会损害目标受众的期望。还应该记住，RDF 三元组的组件通常是 URI。若要更改它们，将会使引用 Web 站点的大多数现有 RDF 失效。

在早期的 Web 中，URI 的结构通常反映 Web 服务器中的文件结构。如果您销售产品集合中某一特定类型的部件，它的 URI 可能类似于：http://www.mysite.com/products/gadgets/widget.html。

这种方法的优势在于它在语义上相对比较清晰；如果您还售出了一个新的装置，则您希望查找产品详细信息的一个较为清晰的 URI 为：http://www.anothersite.com/products/gadgets/doodad.html。

部件和新装置之间的关系非常清楚。主要问题就是这种方法不太灵活；类别层次结构是固定的。

随着 Web 不断发展，动态生成的站点逐渐成为规范。但是，虽然站点变得更加灵活，结构也不再绑定到特定的文件布局，但是 URI 中的语义信息量也减少了。向您显示的页面由查询字符串中某些非常机密的信息决定。例如，小部件的 URI 可能为：http://www.mysite.com/inventory.cgi?pid=12345，新装置的 URI 可能为：http://www.mysite.com/inventory.cgi?pid=67890。

URI 突然变得只提供很少的语义价值。当然无法确定这两个产品是否属于同一类别。最近，内容管理系统和 Web 开发框架已经着手解决这个问题。现在，让具有语义结构的 URI 仍然保留动态页面的灵活性非常容易。这可以通过一种特殊 URI 来实现，这种 URI 不引用服务器上的物理文件，而是引用从不同位置中的脚本或页面提供的内容。在引领业界趋势的 Ruby on Rails 框架中，这是通过路由（将匹配的 URI 映射到特定控制器和操作的规则）来实现的。在 CMS 包中，通常该功能取决于 Apache 的 mod_rewrite（或其他 Web 服务器中对应的内容），并且通常称为 “Search Engine Friendly URI” 或类似内容。当您为站点选择 CMS 或开发框架时，请务必研究一下它是否符合这方面的要求。

最后注意：如果可能的话，请考虑删除 URI 中的文件扩展名。文件扩展名（.html 和 .cgi）没有提供与用户相关的任何语义信息，长远来看，实际上会导致出现问题。如果您将 Web 站点更改为使用 PHP 而不是 CGI 脚本，则您会拥有不同的 URI，但它们服务的内容却完全相同。这不利于 URI 的语义价值以及您的 Google 排名！更好的语义方法是利用 HTTP 报头进行内容协商。考虑以下 URI：http://www.mysite.com/products/gadgets/widget。

通常，Web 浏览器将使用 Accept HTTP 报头表明它的首选内容类型。当请求该资源时，Web 服务器可以检查该头，请注意 text/html 是其中的一个选项，并且服务一个 HTML 页面。如果您拥有一个希望使用 RDF 的 mashup 应用程序，则 HTTP 请求中的 Accept 报头应该包含 application/rdf+xml，并且来自同一 URI 的 Web 服务器可以服务此页面的 RDF 版本。

目前，这种内容协商功能还不能用于很多现成的 CMS 解决方案，但从短期来看，很多解决方案应该都可以使用没有文件扩展名的 URI，这意味着您将来可以添加这个功能，同时不会干扰您的 URI 方案。

回页首

利用现有语义添加工具

不管您是在 Web 站点基础结构中完整地应用语义 Web，还是只是想让您的现有内容更加有用，都可以利用很多机会向 Web 站点中的现有内容添加结构。这是 Microformats、RDFa 和 GRDDL 的领域。表 2 列出了您可以轻松标记为结构化数据的较为常见的信息类型。

表 2. 可以标记为结构化标记并进行自动转换的信息类型
信息类型 结构化标记

人员和组织	hCard、RDF vCard
日历和事件	hCalendar、RDF Calendar
选项、等级和检查	VoteLinks、hReview
社会网络	XFN、FOAF
许可证	rel-license
标记、关键字、类别	rel-tag
列表和概述	XOXO

向页面中添加结构化标记非常简单。下面的清单 3 和 4 显示了包含联系人信息的 HTML 片段，清单 3 不具有 RDF vCard 所需的附加标记，而清单 4 提供了 RDF vCard 所需的附加标记。

清单 3. 非结构化的联系人信息

                
<div class="contactinfo">
  Rob Crowther. Web hacker
  at
  <a href="http://example.org">
    Example.org
  </a>.
  You can contact me
  <a href="mailto:[e-mail]">
    via e-mail
  </a> or on my work phone at 0123 456789.
</div>

清单 4 显示了带有 RDF vCard 所需的附加标记的联系人信息。

清单 4. 使用 vCard 的联系人信息

                
<div xmlns:contact="http://www.w3.org/2001/vcard-rdf/3.0#" class="contactinfo"  
                                     about="http://example.org/staff/robertc">
  <span property="contact:fn">Jo Smith</span>.
  <span property="contact:title">Web hacker</span>
  at
  <a rel="contact:org" href="http://example.org">
    Example.org
  </a>.
  You can contact me
  <a rel="contact:email" href="mailto:[e-mail]">
    via e-mail
  </a>
  or on my 
  <span property="contact:tel">
    <span property="contact:type">work</span>
    phone at
    <span property="contact:value">0123 456789</span>
  </span>.
</p>

在 清单 4 中，您可以看到添加了 Span 元素以区分文本中重要的语义部分以及表示其含义的属性。您添加了链接到 RDF VCard 词汇表的名称空间 “contact”。接下来，您指出该元素是关于 URI http://example.org/staff/robertc 所表示的资源。之后，您使用用于链接关系的 rel 属性以及非链接中的 property 属性添加了元数据。惟一有点复杂的部分就是电话，因为您需要指定类型和号码。为此，需要将类型和值元素嵌入到 tel 元素中。添加此结构允许用户只通过单击鼠标即可向其地址簿中添加联系人详细信息。

其他自动处理可能采用其他结构化形式；例如，Technorati 使用 rel-tag 微格式对其大量的博客文章进行分类。清单 5 中显示了一个 rel-tag，正如您所见，它只是利用 rel 属性的一个简单链接。重要的部分是 URI 的结束部分，在最后一个 / 之后。这就是标记（使用标准的 URI 编码惯例，其中空格由加号表示）。

清单 5. Technorati 用于标记 ‘semantic web’ 的 rel-tag

                
<a href="http://technorati.com/tag/semantic+web" rel="tag">
  Semantic Web
</a>

如果您编写一个有关语义 Web 的博客文章，该文章包括 清单 5 中的代码，然后对 Technorati 执行 ping 操作以通知它们您发布了一篇新闻纸（很多博客软件都可以配置为自动执行此操作），之后他们的爬行程序将索引您的文章并将其摘要添加到您的标记元素链接到的页面，以及具有相同标记（参见图 2）的任何其他文章。

图 2. 从 rel-tag 生成的 Technorati 上的 “语义 Web” 页面

回页首

结束语

分享这篇文章……

	提交到 Digg
	发布到 del.icio.us
	Slashdot 一下！

在本文中，您了解了语义 Web 技术如何采用标准、一致的方式解决 Web 的结构化数据需求，同时比较了当前流行的方法 —— 即每个 Web 站点定义自己的 API。您看到了语义 Web 技术如何在现有 Web 的 HTTP 和 URI 之上的结构中实现价值，首先允许使用 RDF 明确地表达关系，然后允许与基于 OWL 的本体共享含义，最后使用 SPARQL 查询分布式的 Web 知识。本文还介绍了如何利用现有的本体定义数据以及使用语义 URI 方案使您的 Web 站点成为您的 API。最后本文介绍了如何使用 RDFa 和 Microformats 升级现有 Web 站点的内容，以便 GRDDL 服务可以从页面中自动提取 RDF。

尽管 Tim Berners-Lee 对语义 Web 的承诺尚未完全实现，但是多年的思考和研究已经在解决实际问题方面有所收获。Web 2.0 中强烈的协作趋势只会要求 Web 具有更多可用的结构化、语义编码的数据。通过进行规划，您可以适当地利用语义 Web 工具，从而满足这种需求。