Stu Charlton谈语义网

个人简介 Stuart Charlton是云计算软件基础设施提供商Elastra公司的首席软件架构师。Stuart的专攻领域包括系统架构、REST式Web架构、数据仓库等，他还热衷于将精益与敏捷（lean & agile）的方法用于业务流程与产品开发。

QCon全球企业开发大会（QCon Enterprise Software Development Conference）是由C4Media媒体集团InfoQ网站主办的全球顶级技术盛会，每年在伦敦、旧金山、北京、东京召开。自2007年3月份在伦敦召开首次举办以来，已经有包括金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 大家好，我是Ryan Slobojan，现在跟我在一起的是Stu Charlton。语义网（Semantic Web）也是您感兴趣的领域，那么能否请您谈谈什么是语义网呢？

嗯，我正在Elastra做的工作是关于语义网的。我常说，语义网的运用就跟使用辣椒酱一样——除非你非常爱吃辣，否则一点点就足够了——你要是愿意的话，也可以大量运用，但未必人人都能理解[你那些语义]。语义网的想法很简单，现在的万维网是“文档之网（web of document）”，也就是说，我们可以与朋友和同事们分享很多信息，我们可以进行电子商务，等等等等。

而语义网的思想是“万物之网（web of things）”。我们可以在Web上表达任何事物，无论是汽车还是房子，或者是数据中心。它实际上成了一个分布式的对象系统。其实，我和Mark Baker在去年OOPSLA（国际面向对象编程）大会的导课上就讲过这个“将Web视为一个分布式对象系统”的思想。我们认为的“文档网（document web）”实际上是一个抽象接口，而REST架构风格确实地描述了该抽象接口，并说明了它为什么奏效、以及施加于Web的架构约束为什么能带来如此的成功。因此，实际上语义网是这样的，“我想在这个Web上叠加一层逻辑。我希望Web可以成为一个事实上的开放世界关系数据库。”这一点都不夸张。

我的真实意思是，我希望拥有可读的数据。我希望可以采用一定的标记语言（比如RDFa，也就是W3C的微格式）对网页进行标注；另外，我还希望可以这样，即假如我有一个数据模型，我希望网页能忠实于此数据模型。要是按当前技术（多半是Struts、Spring MVC或Rails等）来构建Web应用的话，那么我们首先拥有这个关系数据模型，然后利用它来生成网页，但由此得到的网页并不能忠实于原始的数据模型。

而语义网是这样的，“好，我们会在网页里保持原有的数据模型，所以你日后依然可以获得它”。因此，我可以把网页交给RDFa处理器，由它得到原始形式的数据。语义网最大的一点不同在于，它是开放世界的（open-world），这意味着“任何人可以就任何事情发表任何观点”——这里不存在参照完整性（referential integrity）。当然，你仍然可以保持完整参照性，但这需要通过另外的技术。你知道，人们总是担心语义网要求有一个硕大的本体，或者是统一的秩序。但这种想法其实是错误的。

语义网的真正思想是：不同的人有不同的术语体系。比如，当我说到“tank”一词时，我指的可能是“水槽（water tank）”，也可能是军事武器中的“坦克（tank）”；再如，当我提到“storm”一词时，我的意思可能是“我在抢滩（I'm storming the beachfront）”，也可能指的是“暴风雨（storm）”。计算机是不擅于区分这些含义的，所以它需要借助于某种逻辑框架。关于如何有效地利用逻辑框架，这项研究已经进行30多年了。此后你可以在Web上分享这个逻辑框架，于是我们便拥有了一个非常好的获取机器可读信息（machine readable information）的方式——这种方式较目前的做法具有更好的可集成性。我们现在的做法相当于神经外科手术，做的都是接合、转换、运送这些事。

我并不是说那些可以完全不要，语法差异你还是得靠转换（transformation）来解决的。但在其上铺设一个语义层的话，你就可以采用“以往被认为不可能的”灵活方式来把数据连接起来了。并且由于开放世界的缘故，你可以创建相对立的数据。当你在阅读某样东西时，你将面对“嗯，这里采用哪个解释呢？”的问题。人们需要一定时间来理解这些，但是我确实认为，关系数据库的能力在于为信息提供逻辑结构，我觉得在接下来的十年里，它将随着语义网而复苏。

   

2. 您认为当前阻碍语义网大规模应用的原因是什么？

我觉得挑战在于，语义网实践者们往往需要关注于很多问题，他们更关心知识表示、经典人工智能之类的东西，而不是企业信息技术或集成等现实问题。但情况正在转变。在过去的几年里，人们较多地关注了“语义网”里的“语义（semantic）”部分，而逐渐地，你会看到“语义网”里的“Web”部分将被再次重视起来。这个“Web”部分并不是新创造出来的，它已经存在有一段时间了，尽管还有不少理论问题有待解决，但我认为，对于Web部分，应该更强调实际。

我相信REST的下一步就是语义网。当人们开始采用REST式Web架构来开发系统时，他们会开始思考“我该如何用这个模型来组织我的数据？”对此，目前有各种各样的专用手段（ad-hoc ways）。诸如Atom feeds和微格式（microformats）之类的，它们很有用。语义网为此提供了一个考虑周全且具有相当稳固的逻辑基础的框架。关系数据库在过去遭到过反对，而现在的语义网也是。在七十年代，当时网状数据库（network databases）和层次数据库（hierarchical databases）非常流行，对它们应用逻辑的提议遭到了很多反对。不过，关系数据库的业务效益最终还是得到了理解，并迅速发展和流行起来。

我觉得类似的情况又将发生了，当你完全关注命令式开发（imperative-style development）时，你试图能够控制事物；而逻辑则是声明式开发（declarative-style development），我试图声明事物却不必实现各个部分。因此，使用逻辑是非常高效的，但是许多开发人员可能不这么认为。不过最终你会意识到，“这会节省很多时间与精力”，接着你会说，“好吧，就将它作为一个新工具吧”。没错，它是一个不错的工具，但我觉得这类工具还需要改进，目前这类高质量的开源工具还相当少。

我认为，由Tim Berners-Lee和W3C提出的链接数据运动（linked data movement）是一个实用版或现实版的RDF和语义网。它很有前途，一两年后你将看到大量关于人们如何使用它的案例；另外，还有被称为SPARQL的语义网查询语言。因此我觉得，你会开始看到一些非常实际的应用，尽管它们可能是比较初级的。

   

3. 对于那些想在Web应用中运用语义网技术的开发者而言，您推荐他们看些什么？

首先，其实好的指南还比较少。YouTube上有个不错的关于语义网和RDFa的介绍。可以将RDFa作为起点。RDFa是一种非常简单的“为网页标注语义”的方式。 它使得你能够表达“哪个是对象（object）哪个是属性（properties）”、表格中的域、表单中的域等等。通过微格式来涉足语义网也是一个不错的选择，你可以把它理解为一种“小写S的”语义网（semantic Web），它的思想与目的跟语义网相同，只不过作为一种专门方式的（ad-hoc）实现，它在HTML之上使用了iCalendar等现有格式。所以我的建议是，首先着眼于RDFa，并用它来标注你的网页。

其次，请关注SPARQL——语义网的查询语言。试着用用看SPARQL吧！目前有些库允许你对数据库进行SPARQL查询，你也可以用它来查询Web，或者你可以给它一个链接，它将抓取该链接之下的所有链接，并根据你的查询返回结果集。虽然RDFa和SPARQL还处在初级阶段，但我认为它们都是很有价值且令人振奋的。

   

4. 您提到SPARQL时，我想起一个事，您说SPARQL会抓取内容。那么一般来说，语义网查询是在后台执行并建立索引，还是实时完成，比方说就像在使用Google时，输入一段文本就可以进行搜索了？

嗯，这跟事物演化的历史有关。我来自工业界，其实并不算作语义网社区中的一员。我只是偶然知道了语义网，然后对它感兴趣。但当我回顾语义网技术的历史时，我发现，它起初是关注于Web技术的使用的，但这里它却没有采用Web，而是采用了一种被称为三元组存储库（triple stores）的数据库。三元组存储库跟关系数据库一样，只不过它存储的是语义网的基本单元——三元组（triple）：主语（subject）、谓语（predicate）、宾语（object）。

就像“玛丽有一只羊羔”一样，不管什么都可以归结为三元关系。三元关系被存储在数据库中（可以采用常规的关系数据库，也可以采用私有的对象数据库），这种存放三元关系的数据库就叫三元组存储库（triple store）。在过去，这些三元组是通过API来查询的，我记得SPARQL是2008年1月才成为W3C标准的。事实上，现在已经有许多支持SPARQL的三元组存储库了，因此你可以用SPARQL来查询这些数据库。

再次强调，URI只是起标识符作用，它未必意味着一定要上网。这就是说，链接数据可以在缓存或数据库中，也可以在公共Web上。因此我觉得，如果你需要非常快的响应时间，那么你得采用数据库；但假如你的确想从Web上实时获取信息，而且愿意为此等几秒钟的话，也是可以的，就好比我们今天的mashup一样。语义网技术确实可以令mashup做得更好。总之，神经外科手术更少而且更容易做了。

这实际上和我们今天的mashup没有什么分别，只不过效用更大、表达能力更强了，因为我们不用进行手工解析了——借助于SPARQL，我们不需要写任何代码便可进行跨页面的查询。这是非常强大的，而且我们将看到一些实现，至少Adobe Flex平台不久将支持用Javascript之类的东西进行SPARQL查询。