当前主要本体推理工具的比较分析与研究，本文主要内容关键词为：本体论文,工具论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
【分类号】TP391
1 引言
Berners-Lee为未来的Web发展提出了基于语义的体系结构[1]，本体(Ontology)位于语义Web体系结构中的第四层，它是解决语义层次上Web信息共享和交换的基础。
由于本体推理机是本体创建和使用过程中必不可少的基础性支撑工具之一，因此国内外许多研究机构研发了一大批本体推理机，其中比较典型的有W3C用来对本体进行测试的本体推理机[2]，DIG推荐的基于描述逻辑实现的本体推理机[3]、一些集成在语义网开发平台(如HP实验室的Jena2、德国Karlsruhe大学的KAON2)和本体管理系统(如IBM的SNOBASE系统)中的推理机引擎。面对如此众多的本体推理机，有着不同需求的用户该如何选择适合自己的本体推理机，为了解决这个问题，就需要对当前的本体推理机系统进行详细的分析研究和对比测试，文献[4] 提出了一种使用现实本体来测试对比推理机系统的方法，但是它仅仅是从系统功能这一个角度来进行的。文献[5] 重点对一些本体表示和查询语言进行了详细的测试对比，可并没有牵涉到具体的本体推理机系统之间的测试对比。为了使用户更好地了解、使用和开发本体推理机，本文从系统功能，用户和开发者三个不同的角度设计了一套比较不同本体推理机的测试方案，并对三个典型推理机系统进行了实验对比分析。下面先介绍本体推理机的一般系统结构。
2 本体推理机的系统结构
在对收集到的本体推理机进行详细的分析研究后，归纳出了本体推理机的一般系统结构，见图1。
图1 本体推理机的系统结构图
系统结构由本体解析器、查询解析器、推理引擎、结果输出模块和API五大模块组成。
2.1 本体解析器
负责读取和解析本体文件，它决定了推理机系统能够支持的本体文件格式，如RDF，OWL，SWRL等。解析性能的好坏直接决定了推理机能否支持对大本体文件的解析。
2.2 查询解析器
负责解析用户的查询命令，虽然SPARQL已经成为了RDF的候选标准查询语言，但目前还没有一种公认的针对OWL的标准查询语言，目前使用较多的有RDQL、nRQL、OWL-QL等。
2.3 推理引擎
负责接受解析后的本体文件和查询命令，并执行推理流程，它是本体推理机的核心部件，因为它直接决定本体推理机系统的推理能力。目前大部分推理引擎是基于描述逻辑表算法实现的。
2.4 结果输出模块
完成对推理引擎所推导出来的结果进行包装，以满足用户的不同需求。它决定了本体推理机能够支持的文件输出格式，一般常用的有XML、RDF、OWL等。
2.5 API模块
主要面向开发用户，一般包含三大部分，OWL-API、DIG接口以及编程语言开发接口。OWL-API为用户操作OWL本体文件提供了一种标准接口，目前还没有一个公认的推荐标准，只有两种应用比较广泛的OWL-API(WonderWeb OWL-API和Protégé OWL-API)。DIG接口为描述逻辑推理机系统向外提供服务提供了一组标准的接口，作用类似于数据库中的ODBC，它允许前端(如本体编辑器)挂接到后台不同的推理引擎上，目前最新的版本为2.0。另外本体推理机提供的常见编程语言接口主要有Lisp和Java两种，因为大部分本体推理机系统是采用这两种编程语言实现的。
3 三个典型的本体推理机
本文基于最新、应用最为广泛和最具有代表性三个原则挑选了三个典型的推理机系统Racer,Pellet,FaCT++进行介绍以及对比分析。
3.1 Racer
Racer[6](Renamed ABox and Concept Expression Reasoner)是德国Franz Inc.公司开发的一个采用描述逻辑作为理论基础的本体推理机，最新的版本为RacerPro 1.9，它是一个功能强大的商用本体推理机，不仅可以当作描述逻辑系统使用，还可以用作语义知识库系统。它支持单机和客户端/服务器两种使用模式。
3.2 Pellet
Pellet[7] 是美国马里兰大学MINDSWAP项目组专门针对OWL-DL开发的一个本体推理机，基于描述逻辑表算法实现，最新的版本为Pellet-1.3，能够支持OWL-DL的所有特性，包括支持对枚举类和XML数据类型的推理，它是一个开源项目。
3.3 FaCT++
FaCT++[8] 是FaCT(Fast Classification of Terminologies)的新一代产品，FaCT是英国曼彻斯特大学开发的一个描述逻辑分类器，提供对模型逻辑(Modal Logic)的可满足性测试，采用了基于CORBA的客户端/服务器模式。FaCT++为了提高效率和获得更好的平台移植性，采用了C++而非FaCT的Lisp语言来实现，并开放源代码。
4 本体推理工具实验测试方案设计及实现
对于本体推理机的测试方案目前为止还没有一个公认的标准，本体推理工具的对比分析主要集中在系统功能方面，简单地说就是看哪一个推理机系统功能最为强大，执行速度最快。由于测试者一般都是被测试系统的开发者，这样从测试数据的选取到测试方案的设计都很难保证全面客观，也不能为应用和开发用户提供全面的参考方案。本文在综合考虑了本体推理机基本功能和一般系统结构的基础上，结合传统描述逻辑推理机系统对比测试方案[9]，提出了一套如图2的综合测试方案。
图2 测试方案总体设计
在本测试方案中，将从系统功能角度，用户角度以及开发者角度进行全面的对比分析，其中功能测试主要对本体推理机的两个基本推理功能[10](本体一致性检查和获取隐含知识能力)进行性能测试。应用用户角度分析主要从用户界面是否友好等角度来进行。开发用户角度分析则从本体推理机系统是否为开发者提供了丰富的程序开发接口等方面考察，最后综合考虑上述三个方面的对比测试结果，给出测试系统的最终评价。下面将详细介绍这套测试方案。
4.1 系统功能测试
系统功能测试采用装载解析本体时间、检验本体一致性时间和推理查询时间三个指标对测试系统进行比较分析，主要用来比较本体推理机实现的两大基本推理功能，如果要对系统进行更为全面的性能测试，还应该加入更多的如概念分类、实例归类，本体包含检验等其他功能测试。
(1)本体测试文件选择方案
为了使本体测试数据不失一般性，在本测试方案选择测试本体数据时主要考虑了文件格式、本体类别、本体是否一致、文件大小、本体中定义的类、属性以及个体数量和数据来源等几个方面的因素。其中文件格式涵盖了XML、RDF、OWL、DAML和SWRL，本体类别涵盖了Lite、DL、Full三个级别，测试数据包含了一致和不一致两种类型的本体。具体的本体测试数据采用了来自4个不同地方的本体文件，一部分是由Lehigh大学SWAT项目[11] 的数据产生器产生；一部分从Pellet系统测试文件中挑选；还有一部分是从Protege Ontology Library本体库中选取；最后一部分是通过本体搜索引擎swoogle(http://swoogle.umbc.edu/)从网上随机选取。这样就基本上就可以达到本体测试数据的一般性，广泛性和代表性。
(2)查询语句设计方案
为了使测试的查询语句具有代表性，在本测试方案中查询语句的设计主要考虑到了以下三个因素：
①查询的类型
即测试的查询语句集是否涵盖了本体查询的所有类型，即是否涵盖了布尔查询、检索查询和组合查询三大类型[2]，其中布尔查询是最简单的一种查询，它一般可以转化为一个本体的一致性检查问题，而检索查询和组合查询则可能需要对本体进行推理。
②查询结果的大小
即查询结果中的类或者实例的数量在本体文件中所占的比例应该大于一个阈值，阈值一般是根据具体的本体测试文件而定。
③查询牵涉到推理的复杂度
即推理牵涉到类层次以及属性层次的深度和是否需要进行逆关系推理等复杂推理操作，一般推理牵涉到的类或属性层次越深，推理复杂程度就越高。
下面给出三个典型的简单查询，查询语句采用OWL-QL语法格式来表达，测试查询语句的详细信息见表1。
其中Q1判断Tom是否是一名学生；Q2查询出所有研究生的名字；Q3查询所有信息科学学院的学生名字。有关查询时间的详细测试数据结果请见实验结果分析。
4.2 应用用户角度对比分析
用户角度分析主要考察推理机系统是否为应用用户提供了一个友好的用户界面，是否提供了方便用户使用的文档和演示以及是否方便用户连接当前一些主流的本体编辑器等。表2给出了对比分析的相关详细结果。
从上表可以看出，尽管Racer，Pellet和FaCT++对一些主流的本体编辑器能够提供良好的推理支持，但没有一个能为应用用户提供一个全面友好的使用环境，或者因为没有图形交互界面，或者交互界面太过于复杂。并且Pellet和FaCT++支持的本体查询语言太少，另外FaCT++不支持当前的主流本体表示语言，如OWL等。
4.3 开发用户角度对比分析
开发用户角度分析主要考察推理机系统是否为用户进行二次开发提供了详细的参考文档和编程接口，是否开放源代码和提供开发示例代码等。表3给出了Racer，Pellet和FaCT++的详细测试结果。
从测试结果中可以看出，Racer与Pellet都为开发用户提供了丰富的二次开发接口、开发文档和一些示例代码，因此作为Lisp编程用户可以选择Racer进行二次开发，Java编程用户则可以考虑选择使用Pellet。
5 实验结果分析与展望
实验平台：Pentium 4 CPU 2.60GHz，256M内存，80G硬盘，Windows XP SP2，Java JDK1.5。参与测试的推理机：Racer1.9.0，Pellet1.3，FaCT++1.3.1。编辑器为Protege3.2 Beta。
说明：由于FaCT++没有提供OWL接口也不支持对实例的查询(即A-Box查询)，因此在装载本体和查询的对比测试中只对Racer与Pellet进行了比较。另外限于篇幅，本文没有列举出本体测试数据的相关详细信息。
本体装载时间测试结果如图3所示：
图3 本体装载时间折线图
从上图可以看出，本体装载时间随着本体文件中元组数目的增加而增加，当元组数量很少时，Racer和Pellet的装载时间差不多，但当元组数量超过万个以上时，Racer的上升速度要低于Pellet，这说明Racer能够对大本体文件提供一个良好的支持，这与Racer是一个商业系统的定位是一致的。
本体一致性检查时间的详细测试结果如表4所示(时间单位为s)。
从上表可以看出Racer能够很好地对所有测试本体进行一致性检查，Racer和Pellet所耗时间差不多，FaCT++所耗时间最少。在测试中发现一致性检查时间主要由不一致概念数量和造成本体不一致的原因而不是文件大小决定，如本体O2要比本体O3小，但由于它包含更多不一致概念，因此所耗费的时间要比O3长。另外不难发现采取DIG外挂方式要比单独使用本体推理机系统进行本体一致性检验耗费更多的时间，这是因为编辑器和推理机系统之间通信消耗了大量的时间。表5给出了查询时间测试结果(时间单位ms)。
从测试结果来看，Racer与Pellet在Q1(布尔查询)上花费的时间差不多，这是因为执行布尔查询的过程就是一个检验本体一致性的过程，这个结果符合本体一致性时间测试结果。Racer执行Q2(检索查询)的时间要比Pellet耗得多，主要是因为Racer在对本体执行查询前需要对本体文件做一些索引等准备工作以加速其后查询的速度。但Pellet执行Q3(组合查询)的时间超过了Racer，这是因为Q3查询牵涉到了对T-Box的推理，可以看出Racer在T-Box推理能力方面要优于Pellet。由此可见，一般情况下如果只是进行A-Box推理查询，则考虑使用Pellet，而查询如果牵涉到T-Box推理则推荐使用Racer。
对于上述的各项测试结果，必须考虑到不同的软硬件平台，使用不同的本体测试文件和不同的查询语句均可以对实验数据产生很大的影响，这里只能够得出一个相对的比较结果，综合以上测试结果可以发现，Racer和Pellet都能够实现检查本体一致性和挖掘本体隐含知识两个基本功能，但综合起来评价Racer要优于Pellet。虽然FaCT++在本体一致性检查中占优，但由于它不支持OWL和本体查询语言，因此综合评价最低。这个结果与大多数评测结果是相符合的，这就说明本测试方案是可行和有效的。
6 结语及展望
通过对当前本体推理机的分析和三个典型推理机的测试对比，发现尽管大部分本体推理机都能够实现两大基本推理功能，但是还是存在着一些不足，如Racer不支持对枚举类和用户自定义数据类型的推理，Pellet缺乏对本体规则语言SWRL的支持并且支持的本体查询语言不够全面等。另外它们还缺乏对多个本体、不一致本体以及大规模本体服务器的推理支持，还有用户界面不够友好等缺陷。由此可见，未来本体推理机的发展趋势应该是在系统功能方面开发更为强大和完善的推理算法，如在描述逻辑中支持量词约束、用户自定义数据类型和逆关系属性类型等。并能允许用户自定义推理规则以及支持多个、多版本和不一致本体的推理。向用户提供更加友好的GUI和更为丰富的程序开发接口也将是未来本体推理机的一大发展趋势。本文下一步的工作将是进一步完善本体推理机的测试方案，并实现一个测试平台。
标签：推理论文;