译言网 | 在语义网(Web 3.0)如何整合应用程序

来源:百度文库 编辑:神马文学网 时间:2024/04/29 01:56:06

在语义网(Web 3.0)如何整合应用程序

bean

于2007-12-01 20:23:31翻译 | 已有561人浏览

语义Web(语义网)是现有Web的扩展,信息被赋予定义良好的含义,更便于计算机和人的协同工作。语义网的基本思想是通过在网上提供定义好的、相互链接的数据,让网上的数据能被高效、自动地发掘利用、不同的数据能更好地集成,而且还能被各种不同的应用程序加以使用。为了充分发挥Web的潜能,为了能提供通用的Web入口平台,并且能通过一些自动处理的工具来共享和处理数据,取代现在需要手工干预操纵不同Web数据的局面,语义网势在必行。     语义网将提供一个基础架构,通过这个架构我们在互联网上不再只能处理Web页面,数据库、Web服务、程序,传感器、个人智能设备,甚至家用电器设备都能通过网页来传递并处理数据。各种软件代理将能够搜索并过滤这些数据,以一种全新的令人激动的方式把这些处理好的数据送到Web使用者面前。新的程序设计语言,将极大拓展We.....

语义Web(语义网)是现有Web的扩展,信息被赋予定义良好的含义,更便于计算机和人的协同工作。语义网的基本思想是通过在网上提供定义好的、相互链接的数据,让网上的数据能被高效、自动地发掘利用、不同的数据能更好地集成,而且还能被各种不同的应用程序加以使用。为了充分发挥Web的潜能,为了能提供通用的Web入口平台,并且能通过一些自动处理的工具来共享和处理数据,取代现在需要手工干预操纵不同Web数据的局面,语义网势在必行。

    语义网将提供一个基础架构,通过这个架构我们在互联网上不再只能处理Web页面,数据库、Web服务、程序,传感器、个人智能设备,甚至家用电器设备都能通过网页来传递并处理数据。各种软件代理将能够搜索并过滤这些数据,以一种全新的令人激动的方式把这些处理好的数据送到Web使用者面前。新的程序设计语言,将极大拓展Web数据的可读性,并且催生出一系列新一代的软件开发技术和工具包。

现在,语义网的部分技术已经研制成功,采用这些技术的商业模式也变得越来越清晰。本文中,我们将重点探讨语义网在近期待实现的关键目标,以及实现这些目标后能够Web用户们带来的潜在收益。

让我们回想一下在1989年时的文档处理系统,那时国际互联网还刚开始普及。在那个时候,检索并引用远程系统的信息还是专家们的游戏。虽然有了国际互联网,我们可以很容易登录到远程系统,然而,这些系统往往使用不同的信息提取协议,举例来说,你通过telnet(或者其它远程登录方式)登录到一个远程系统上后,在获取信息之前你还得首先学习该系统的信息提取协议,而且,找到了你需要的信息后,你还得把它们先拷贝到你自己的剪贴板,然后才能拷贝(或者重新输入到)到你自己的相关文档中。采用这样一种信息获取方式来处理那些关联性强、时效性和准确度要求极高的文档简直就是一场噩梦。

那就是Web技术普及前的情况。现在,有了Web技术,我们能轻松实现信息间的无缝链接。现在很多系统都有Web服务器,尽管它们可能运行在不同的机器上,仍然还在使用那些从1989年开始运行的老系统,但Web接口让它们看上去成为同样光滑、一致的信息世界的一部分。在我们生活中,Web让内容关联变得空前容易。

尽管有了这个信息世界的奇迹,在Web应用程序间传递内容仍然是非常困难的事情。一旦电脑能直接理解Web内容,将会衍生非常有价值的应用。如果我的个人日程管理程序能自动识别日期,它就能在约会来临前自动通知我;如果我的邮件地址地址管理程序能解析电话号码或者邮件地址,只要我一次点击就它可能帮我建立起和特定联系人的通讯;只要给我的数字电话到日本的具体位置,它就能帮我计算出应该乘哪趟火车及相应的差旅费用。

今天,我们在充分利用Web方面仍然受到很多的束缚。假设你在浏览互联网时偶然打开了一个会议召集通知,网页上有召开会议的时间和地点,并且还有很多超链接地址,分别链接到本次会议召集人及其它参与人员的个人主页。你决定报名参加本次会议,开始点击注册按钮,在这一刻,你期待着你的电子日历能自动记录会议的日期和时间,并能超链接到网页上详细的细节说明;你希望你的数字电话能下载会场地址并计算出在会议日期到达的最佳列车路线;你还希望你随身携带的商务通能自动把参会人员的联系方式下载并临时保存起来,直到会议结束。你,是多么地希望以上处理能够在网页上一次点击就自动完成!

不幸的是,你现在还做不到这一切。事实上你不得不非常辛苦地把会议详细情况逐条拷贝并粘贴到你的地址本,自己去查找会议日期和时间;你不得不手工从各个会议参加者的个人主页中寻找并拷贝他们的联系信息到你的地址本中,手动调整他们的地址及电话号码格式;你还不得不敲打这手机上的小按键,困难地录入会议的位置信息。这一切,和我们在拥有Web技术前处理文档系统是多么的相似,一言以敝之,我们还处于处理周围数据的前Web时代!

语义网已经提供了一些解决和改善以上状况的技术,接下来我们将着重描叙其中的三种:数据库间的链接、使用XML DTDs 或者schemas(数据视图)在应用程序间共享内容,以及发现并整合Web服务的关键应用程序。

 

超越HTMLWeb数据(The web of data - beyond HTML

上面遇到的麻烦还是发生在网络上处理个人数据的时侯,处理公司业务数据时的困难就可想而知了。如果你企图连接公司内部运行的不同数据处理系统,或者企图帮助客户从多种数据里面整合信息的时候,你就会遇到非常尴尬的前Web数据处理情形。在库存管理系统和财务系统里面存在很多重叠的数据,在整合这两个系统的数据时很容易发生主键冲突或者数据关联错误。今天,你不得不雇佣一个程序员编写“接口程序”从库存管理系统中筛选数据,格式化数据,然后才能导入到财务管理系统中。你还将发现到你的客户关系管理系统也应该和订单管理协调进行数据整合,否则将会严重影响你公司的业务开展。一次又一次,你不得不不断雇佣程序员来编写很多数据接口程序,如果你的公司存在很多不同的应用软件系统,将需要编写大量的代码来提供各种数据接口,这将给您带来昂贵的程序维护开销!

使用扩展标记语言(XML)( http://www.w3.org/XML/)对于改善以上情况会有些帮助,如果所有的应用程序都能采用XML格式,程序员就只要学会处理XML数据了,而不用像现在一样需要和各种离奇古怪的数据格式打交道。这意味着我们可以利用一些XML的工具例如XSLT(一种转换语言,参见:http://www.w3.org/TR/xslt )来粘合我们的应用程序。遗憾的是这种技术还不能帮助我们彻底改善数据接口的效率。因为每一对应用程序之间,甚至同一对应用程序的每一种接口之间,都需要定制相应的“XML到XML桥”,也就是说,当你在不同的应用程序间提取XML文件的时候,你不能仅仅简单地合并它们。为了执行一个针对XML文件的查询,你还得针对它的配对文件补充特定的限制条件,你不能仅仅简单地把两个查询合并到一块。这与在关系数据库中的处理是大不相同的,在那里,通用的数据元能被轻松地连接到一起。

问题是不同的数据库是由不同的schemas(数据视图)文件架构而成,而且这些schemas表达并不清晰。因此,一个如的XML 标记就很难直接和另一个数据库中的域关联起来。一种解决的思路是把这些schemas变得更明白易懂,并把它们映射为统一的术语。XML-Schema 语言(http://www.w3.org/XML/Scema )允许很多公益组织整理出一份统一的schema文件。一个公司,甚至是一个特定的商业部门,通过开发一个统一的XML映射集(例如:一个特定的schema文件),就能采用统一结构来表达他们的信息。不幸的是,这个事情有时实施起来会并不容易,而且通常针对不同用户开发一个大型词汇表都会遇到困难。

问题的关键是,正如我们上面提到的“在库存管理系统和财务系统之间存在一些重叠的数据”,一种特定的数据重叠,而且可能还不只一个。例如,库存系统会给每个商品一个唯一的编号-你的销售员会坚持这个要求。另一方面,财务系统必须给从不同供应商不同批次购进的同一个商品分配不同的号码以示区分,这样,库存中的商品编号就不能和映射到财务系统中的商品编号唯一对应。通常情况下,试图在一个大公司(或者是充满竞争的工业部门)定义单一schemas(视图文件)是非常复杂的,而且经常会无功而返,不同的用户会因为各自的岗位差别以及数据需要坚持用他们自己的方式来表达同样的数据。即使在一些实施比较容易的小公司或者合作部门,也同样会在供应链上混杂一些问题,有的用户不使用同样的schema或者不同意完全按照schema的要求表达数据。

不同结构的schemas(数据视图)文件、或者是基于不同商业词汇的不同用户的schemas(数据视图)文件之间的映射,都不是XML-schema所能解决的问题。现实生活中经常需要处理异种数据结构的映射问题,我们为此需要寻求更为有效的数据表达工具。例如用在关系数据库中的关系演算,数据表达能力远远胜过许多旧的数据库(文件数据库),因此它成了过去处理数据映射的标准。更为有效的表达方法,例如实体或关系或者对象模型,可以用来满足解决复杂的数据映射或者查询异构数据的需要。总之,采用更有表现力的语言能提升我们协同工作的层次。既然以前的老数据系统通过采用关系模型很好地解决了数据兼容问题,所以未结构化的web数据,或者XML-schema定义,也应该能通过采纳关系模型,有效解决数据模型问题。

因为这个原因,我们建立了一个名为资源描述框架(RDF; http://www.w3.org/RDF/ )的语义网的基础组件。如果两份来自于不同数据源的RDF格式文件需要合并,你只需要把它们合并成一个大文件就可以了,即把文件里面的关键字进行简单的连接,因为RDF文件格式里面的关键字都采用了相同的通用资源定位符(URIs)。如果你想在合并后的RDF文件中增加限制条件,修改原来的查询方式,你只要直接在新RDF文件中增加限制条件即可。XML文件是由元件和属性组成的,它只能告诉你文件里面记录了什么内容,而RDF数据则由一段段数据表达式组成,每一个表达式都描叙了一个特定的值,这个值相对于一个数据库表的单元。原有的关系数据库运算方法都能兼容,例如连接和视图,你可以使用常见的工具来执行它们。

现在我们就顺利地解决了企业级应用系统间的数据集成问题。我们只要把每个应用程序的数据输出或者转换为RDF格式文件,我们就可以针对这个RDF数据执行各种查询,我们能轻松地编写并修改查询条件,轻松导出我们需要的数据。反过来,这些数据也能轻松地导入到其它需要使用它们的应用程序中去。而且,这种问题和你的系统规模只是线性相关,就好像我们添加新Web服务器不会影响到其它人浏览网页一样,新的RDF应用也能被轻松地添加到先有的互联网上,而不会影响它的正常使用。大量需要编写的数据接口界面奇迹般地消失了,就像文档之间可以链接一样,数据也能通过Web连接到一起!

 

语义网的Web服务,把程序和数据整合到一起(Semantic Web Services - bringing programs and data together

正如如果没有RDF我们就难以在互联网上整合数据库一样,应用程序的跨互联网整合也遇到了同样的问题。表面上看,在互联网上整合应用程序是很容易的事情,毕竟,我们经常可以点击一下就从晚上下载java或者flash程序到本地运行。不幸的是,这种方法对于电子商务应用程序是无效的,特别是在B2B的应用程序间。把来自于某个地方的应用程序下载到本地运行和从某个程序提取信息到你的应用程序可是截然不同的两回事。

设想一个案例:有个企业想从一个供应商那边购置一批零部件,这批零件需要先联系大型船运公司安排船运,然后从本地几个生产商那边精心挑选一家在零件运到时具备最高生产能力的厂家生产。而且,他们希望能通过Web高效地解决这个问题,由一个销售员下订单,然后启动整个供应链高效协同工作!这看上去和前面提到的数据库间整合有几分相似,然后却要复杂很多,因为牵涉到的各家企业采用的内部管理软件可能会完全不同,而不仅仅是数据库不一致。更糟的是,这些应用程序可能运行在企业内部某台特定用途的电脑上或者隐身在内部防火墙和安全防护设备的后面。首要解决的问题就是规划如何才能通过互联网把这些不同的应用程序集成起来,也就是要为这些程序提供通讯协议和都能明白的服务描叙书。

很多IT界的大型企业一直在致力于解决这个难题,从而形成了一个正快速增长的“Web 服务”(Web services)市场,这也是现代Web商务中增长得最快的业务,例如,著名的B2C 电子商务组织Gartner声称,“采用Web服务将能降低成本,将IT项目的效率提高30%。”估计Web服务业已形成了十多亿美金的市场规模,并正在迅速成长。

所以,我们正加速开发新的协议和语言来标准化描叙Web服务。我们开发了一种基于XML的名为SOAP(http://www.w3.org/TR/SOAP)的协议来为Web服务间提供基于互联网的标准调用方法。除此之外,我们正在抓紧研发新的Web服务描述方法和Web服务架构语言。这也是我们W3C(World Wide Web Consortium’s)组织当前的主要任务。

语义网技术将在广泛分发Web服务的时候提升Web服务的作用。许多Web服务供应商希望通过互联网在更大的范围内为不同的用户公示他们的服务。提供中间代理服务-一种让Web服务用户间相互匹配的能力,是非常困难的。而且,这种周而复始的同类词汇间的映射会导致数据库的暴露。使用现在的实现方法,Web服务描述了输入、输出、端口和其它调用概要,但是服务的行为描述却以一个“content”(内容)字段保留了下来,等待着将来随意的描述(XML-parsable)。因此,这个问题就和前面的数据库间整合非常相似了,不同企业用户间未经商定的不同映射等待着被解析。在预先分派好的团体用户里面还有达成一致的可能,但和那些外来的Web服务提供商,由于他们使用了不同的内容schema(数据视图),要统一建立映射关系就非常困难了,这要求我们在整个供应链条上进行大量的预先约定,大大限制了Web服务的应用范围。

正如在前面数据库案例中提到的,强大的语义网表达语言,能够在这种时候给我们带来帮助。RDF的扩展-RDF-schema,以及一种新研发的Web本体语言OWL(http://www.w3.org/2001/sw/WebOnt/ ),能够用来建立层级和词库,从而帮助我们解释词汇词间是如何关联的。例如,我们可以在互联网上建立一个说明运送事件的schema(数据视图),邮寄是一种运输,加急邮件是一种邮政等等。通过合并不同的词汇表来描叙的我们服务项目,我们可以轻松整合出新的服务,而且被合并的文件仍然是合法的RDF。

此外,并不要求建立服务连接的描述信息采用自然语言中的公用词汇。外部服务来源,不管它来是自一个不同的用户还是开发者,是来自一个不同的词典还是随机在互联网上发现的某个网页,都能解释映射信息。因此,我能把我的一个叫做“lorry”的合作者和你的叫做“truck”的词汇间建立对应关系,日后,当我们合并图表的时候,我们就能发现lorry与truck的联系。甚至,这种新的语言还允许我们执行更为复杂的映射对应与合并、如果我把 a Nissan-Maxima 定义为汽车、类型是豪华,它的场地在日本,当我们连接到尼桑经销商的服务时,我们能一下就找到上面定义的属性。

当某些相对复杂的服务不能马上从互联网获得时,语义网将能提升现有Web服务的能力。例如,一家专门提供小糖果礼品盒的公司需要同时订购100个心形巧克力,100个棒棒糖,并需要把它们运送到名古屋进行包装。我们容易找到心形巧克力供应商,棒棒糖生产厂家,甚至很多的运输企业,但是这不是仅通过一个服务就能解决的问题。自然,我们希望能把以上服务打包在一起而不用去辛苦寻找三个以上的Web服务。语义Web服务允许我们把需要的服务信息轻松整合到一起,即使它们事先没有采用同样的词汇进行服务定义。甚至,语义网的应用程序还能分析实现我们目标的方法,提供高效、合理的Web服务集成(例如:运送巧克力需要冷藏,它能自动添加该项服务申请以保证巧克力不会在运输过程中融化)。尽管复杂的Web服务组合仍然是一个尚在研究中的课题,但许多基本的Web服务装配,例如各种不同服务的输入和输出匹配,已经可以通过现有的语义网工具成熟应用了。、

或许,曾有人担心建立语义网是在从事一项面向未来和火箭科学家们一样困难的研究工作,但正如您已经看到的,事实并不是这样。语义网,正如万维网一样,只要您有了明确的设想,就能把它在互联网上轻松实现。这一处理过程都已经被我们标准化,这也正是我们W3C存在的价值。我们并没有发明关系数据模型或者服务装配技术,我们只是把很多众所周知的成熟技术带到互联网上,让不同的数据和应用程序能通过Web自动集成,消除以前需要很多复杂的人为干预才能协调工作的麻烦。

总之,语义网已经提供了一些工具和语言来解决我们在本文中谈到的许多问题。不久的将来,你只要点击一次参会通知,你的计算机就能理解本次参会的表格,并挑选出正确的信息发送给其它程序,而且它会直接调用相关的程序(通过Web服务)执行必要操作处理而不再需要人工干预。数据和应用程序的集成市场是非常巨大的,我们相信那些选择深入挖掘并推动语义网技术的企业一定能取得巨大的成功!