本体的检索建立在它的存储机制上,目前RDF本体存储机制主要有数据库、内存、磁盘等载体。通过相关研究与实验可知,这三种存储方式具有以下特点:

(1)采用关系数据库来存储本体三元组数据源是一种比较常见的存储方式。优点是数据库管理系统提供了标准的查询接口,使用方便,但存在高成本和对本体推理支持不足的问题。文献[15]具体描述了目前使用数据库存储本体三元组的几种可能的形式,分别是:水平数据库,模型简单,但浪费存储空间,使数据库成为一张稀疏表;垂直数据库,由Jena等众多RDF引擎采用,缺点是每一次检索都需要遍历整个表,处理联合查询时,查询引擎很难获得高效率;按属性来建表的存储方式,造成表多而不易维护,且查询效率不高。

(2)基于内存的RDF存储与数据库相比,安装和配置较为简单,而且在内存中,处理OntoThesaurus三元组的插入、查询和推理操作的速度很快。但该机制的缺点也很明显,由于内存容量的限制,只适合小规模的数据量,而且存储是非持久性的^{[ 15]},内存还需处理很多其他的进程,易造成工作效率低下等。

(3)如果将OntoThesaurus的信息以OWL文件的形式直接存储在磁盘里,这样虽然可以存储海量数据,但是对查询引擎提出了很高的要求,需要具备解析和处理OWL大文件的能力,与其他方式相比,既缺乏查询支持,又不具备效率的优势^{[ 15]}。

因此,考虑到既要存储大量数据,又要实现高效查询,本文选择为超大型OntoThesaurus建立存储在磁盘的Lucene倒排索引来实现本体检索与推理。

本文提出了基于RDF三元组思想的Lucene索引存储结构。

简单而言,需要索引的信息来自一个RDF/XML本体文件的ABOX部分,它包含多个资源描述,而一个资源描述是由多个语句(声明)构成,每一个语句是由资源(主体)、属性(谓词)、属性值(客体)构成的三元组,即表示资源具有的一个属性。

Lucene的数据结构是虚拟文档,即Document,OWL本体大文件是Lucene需要索引的数据源。RDF的三元组思想为将这些数据源定制成Lucene的虚拟文档Document提供了参考,即本体文件中的一个三元组对应Lucene的一个虚拟文档Document,然后将所有的虚拟文档交给Lucene做索引,通过倒排索引的形式存储在磁盘。

中文叙词表本体OWL文件是RDF/XML格式的文件,其ABOX部分由许多个XML节点组成,其中每个节点表示一个完整的中文叙词款目。也就是说,一个概念(叙词)表示一个资源,它由多个语句组成。例如,从CCT1_OntoThesaurus文件中抽取出来的一个叙词概念“焙烤食品”由两个语句表示:概念的中图法分类号是“TS219”,它的族首词是“食品”,如图1所示:

图1

	Figure Option ViewDownloadNew Window
	图1 OWL本体大文件中的一个完整叙词款目

从这些信息可以知道,叙词“焙烤食品”有两个属性,一个为CLCCode,另一个为TopConcept,其值分别为“TS219”和“食品”,用RDF三元组的有向图来表示,如图2所示:

图2

	Figure Option ViewDownloadNew Window
	图2 RDF三元组有向图表示的叙词款目信息

根据RDF三元组的有向图,该叙词的相关信息在做索引的时候,可以构建两个Lucene虚拟文档,其表示方法如图3所示:

图3

	Figure Option ViewDownloadNew Window
	图3 Lucene虚拟文档表示的叙词款目信息

叙词的每个Lucene虚拟文档都包含两个数据字段(Field),即代表一个三元组,其中概念名称如“焙烤食品”为主体,属性名称如CLCCode或TopConcept为谓词,属性值如“TS219”或“食品”为客体。该叙词款目的存储结构设计成以RDF三元组思想为基础的Lucene虚拟文档后,生成Lucene索引的过程如图4所示:

图4

	Figure Option ViewDownloadNew Window
	图4 OntoThesaurus的Lucene索引过程

OntoThesaurus的查询机制与它的语法和存储关系密切。在OTCSS中可以使用Lucene来定制各种查询,如构造基于定义域和属性域的词条查询和三元组的查询、布尔或、布尔与和布尔否查询等各种组合查询。倒排索引赋予Lucene高效的检索速度,功能强大且使用方便,这样OntoThesaurus的检索问题将迎刃而解。本文对现有的中文叙词表本体大文件进行了实验,用Lucene做索引后构造各种查询,其检索时间都保持在几百毫秒之内。

将OntoThesaurus以RDF三元组的逻辑结构构造成Lucene虚拟文档后,中文叙词表本体转换成索引数据,它可以看作是若干个Lucene虚拟文档Document,即三元组构成的一个集合,根据RDF(S)推理规则,OntoThesaurus的推理可以在已有的三元组上推出新的三元组,也可以在已有的三元组上推出某些矛盾的三元组,甚至在已有的三元组上推出多余的三元组等信息。

OntoThesaurus中的每一个三元组由两个节点和连接两个节点的有向边组成,边的起始点为OntoThesaurus中的概念实例,边的终节点为该概念实例的某个属性值,有向边由该属性标记。因此OntoThesaurus为一个大型的三元组有向图,它由若干个推理子图组成,如图5所示。设节点为OntoThesaurus的叙词(C),边为OntoThesaurus的谓词(Narrower),可以从三元组T(1, N, 4)、T(4, N, 3)和T(1, N, 3)以及T(8, B, 9)、T(9, B, 10)、T(10, B, 6)和T(8, B, 6)推出下位词传递关系T(1, N, 3)和上位词传递关系T(8, B, 6)越界。

图5

	Figure Option ViewDownloadNew Window
	图5 OntoThesaurus中的推理有向图

OntoThesaurus的推理在相应的每个推理子图中进行,这样可以节省大量的时间开销,避免每次推理都在整个OntoThesaurus中进行。对于每个推理图G = (C, {T}),其中每条有向边对应一个三元组t(S, P, O)∈T,推理图中的三元组为推理条件,对于每种推理结果,推理后对推理图进行更新,因此更新后的图还是一个推理图。

根据构造的Lucene索引及其逻辑结构,可以分析Lucene版的本体推理机在时间和空间上的复杂度,确定该本体推理机是否能够解决网络化的在线推理难题。设超大型的OntoThesaurus的三元组个数为n(n = n_p + n_c + n_h + n_t + n_n + n_b + n_r,下标为OntoThesaurus中相应属性名称的首字母^{[ 1]}),OntoThesaurus中关系属性种类数目为p,结合文献[6]的中文叙词表本体定义的一致性检测机制,构造了相应的推理算法来实现,并且估算出其中一些推理的复杂度,如表1所示:

表1

表1

表1 Lucene版本体推理机部分推理复杂度分析表 复杂度 全局检查 时间复杂度 空间复杂度 值域不一致 O(nh) O(nh) 二元关系冲突 O(n*p) O(n/p) 入口词多次出现 O(nh) O(nh) 传递关系越级 O({Invalid MML})或O({Invalid MML}) O(nb)或O(nn) 未成对指引 O(nn)或O(nb) O(nn)或O(nb) 非法对称 O(n) O(n/p) 非法自反 O(n) O(n/p)

表1 Lucene版本体推理机部分推理复杂度分析表

从表1可以看出,Lucene版的本体推理机的在时间复杂度上基本上都是线性的。由于目前一般的服务器内存空间都足够大,所以借助Lucene这个高效的检索引擎,实现OntoThesaurus的网络化在线推理完全是可行的。

OntoThesaurus的检索实现是建立在05CTQ001项目的成果OTCSS基础之上的,功能和界面基本不变,详见文献[5]。将超大型本体的检索转化成为对超大型本体的索引文件的检索,对于精确检索、前方一致检索以及任意一致检索,一般通过不同的查询子类(Query)辅以通配符来实现。

下面主要介绍通过主题词(入口词)途径进行任意一致检索的解决思路,其他途径的检索实现可以参照此解决方案。使用Lucene实现任意一致检索的步骤如下:

(1)初始化存放Lucene索引文件目录的路径;

(2)定义指向Lucene索引文件目录的搜索器;

(3)构建与任意一致检索相关的查询,此时使用通配符搜索(WildcardQuery),如果为精确搜索则使用TermQuery,前方一致搜索使用PrefixQuery;

(4)定义存放检索结果的Hits类;

(5)执行相应的查询;

(6)将查询结果进行归并,即调整成若干个完整叙词款目的形式;

(7)对叙词款目按拼音(Lucene默认为按相关度排序)进行排序后输出;

(8)计算本次检索所花费的时间。

需要注意的是,从构建Lucene虚拟文档的方法来看,如果检索条件是英译名、中图法分类号,则需要通过两次检索才能搜索出用户所想要的检索结果。搜索效果如图6所示:

图6

	Figure Option ViewDownloadNew Window
	图6 以“中国”作为关键字的Lucene搜索效果[ 16]

OntoThesaurus在语义Web界、图书馆界都有着很强的应用背景。本文提供的超大型OntoThesaurus的网络术语服务包括供人使用的OntoThesaurus-TS和供应用程序使用的Web Service API,其中OntoThesaurus-API目前可提供18个服务函数。功能和界面与原OTCSS系统^{[ 5]}保持一致,但实现方法有所改变,保证了服务的时效性。

网络用户利用OntoThesaurus-TS^{[ 16]}的服务,可以检索和获取所需的概念术语及其相关信息(分类号、英译名、同义词、上/下位词或其指定子关系词、相关词或其指定子关系词等),应用于OPAC检索、搜索引擎、数据库检索等应用程序,进行扩展查询、分类标引、翻译等工作。在此过程中,还可以随时提交对现有词表的修订意见。

OntoThesaurus-API^{[ 17]}可以帮助应用程序突破机械式字面(关键字)匹配局限于表面形式的缺陷,从词所表达的概念意义层次上来认识和处理用户的检索请求^{[ 18]},即实现概念检索(或智能检索)。例如,在深圳大学图书馆的OPAC检索系统中,可以通过调用OntoThesaurus-API,实现各种概念检索。以检索“电脑”为例,将此入口词转换为正式主题词“电子计算机”,实现规范化检索,效果如图7所示:

图7

	Figure Option ViewDownloadNew Window
	图7 以“电脑”作为关键字的智能搜索效果

OntoThesaurus-API还可以广泛应用于其他应用程序中。例如:在众多支持Tag的应用程序中,可以使用OntoThesaurus-API为用户输入的标签进行规范化的提示,使用户输入的标签更为规范化;在面向主题词的数据挖掘中,运用OntoThesaurus-API可以基于主题词及其款目信息对数据进行挖掘、统计;在机器学习中,OntoThesaurus-API可以提供同义词辨析机制和主题词分析机制,进行与主题词相关的信息抽取等。

上述所有的应用都可以通过Web Service调用的标准方法,在不同的应用平台上进行实现^{[ 19]}。

超大型OntoThesaurus的推理主要运用于一致性检测机制的实现,OTCSS系统的知识采集、词表管理以及全局检查功能中都用到了一致性检测机制,以保证OntoThesaurus在整个生命周期中的正常运行。

文献[6]结合中文叙词表和本体的特点、编制规范和描述逻辑,建立了OntoThesaurus的一致性检测机制,即10条自定义规则。该文中采用的Jena/SPARQL推理方案可以满足一般大型OntoThesaurus(约2万叙词款目以上)的实时推理要求,但无法满足超大型OntoThesaurus的推理时效性要求。

本文采用Lucene和Jena对OntoThesaurus进行基于自定义规则的推理,可检测出值域不一致、入口词多次出现、非法自反关系、非法对称关系、未成对指引关系、二元关系冲突和传递关系越级等矛盾问题,以及拼音缺失和叙词未定义等信息缺失问题,并可自动生成族关系。在全局检查阶段,这些问题可以通过网络界面呈现在修订专家面前,根据推理结果的问题信息提示,修订专家可进行相应的处理,达到不断完善的目的。

在知识采集和词表管理的各个阶段,根据需要不同程度地应用了一致性检测机制。知识采集的过程包括两个部分:知识发送和知识提取,它是OntoThesaurus进行充实和完善的有效途径。普通网络用户、领域专家和标引员可以发送修订意见给修订专家参考,其发送信息包括:为原叙词增加入口词(同义词)、新增补叙词(正式主题词/概念)、修改原叙词款目信息、原叙词款目整条删除,以及新增相关关系子关系种类等。修订专家通过提取统计后的修订信息进行处理,决定修订意见的去留。词表管理是供修订专家使用的网络维护界面,对完善OntoThesaurus起着非常重要的作用。它通过维护Lucene索引来实现,主要包括以下三个部分:新增叙词、修改叙词和删除叙词。

OTCSS的知识采集和词表管理都是为应对OntoThesaurus的动态发展而制定的一套维护机制。知识采集中新增补叙词款目、修改原叙词款目信息和原叙词款目整条删除的处理方式,分别与词表管理的新增叙词、修改叙词和删除叙词一致;为原叙词增加入口词(同义词)需要检验在OntoThesaurus中新增的该入口词是否作为概念的实例以及概念的实例的入口词存在,如果合法就只需向索引文件中加入一个三元组虚拟文档即可;新增相关关系的子关系种类则需要通过Jena修改OWL本体文件的TBOX部分,向其中添加该关系种类的基本信息。因此,OTCSS应具备完善的推理能力,以保证在更新的过程中不至于破坏OntoThesaurus的一致性而引起矛盾,其具体的检测效果详见文献[16]。

根据OntoThesaurus一致性检测问题的形式化描述^{[ 6]},构造了相应的推理算法来判定这些一致性检测问题。以“传递关系越级”为例,算法如下:

(1)用Jena API解析OntoThesaurus的TBOX(OWL文件),从中搜索出Narrower、Broader关系以及它们的扩展子关系集合R;

(2)定义存储传递关系越级矛盾信息的空集合ErrorMsg;

(3) 依次取出集合R中的任意元素r,从OntoThesaurus中以r域搜索出r关系中的所有三元组,其中c₁和c₂分别为三元组的主体和客体,即∀r(r∈R∧1,c₂>∈r∧c₁,c₂∈C),若∀r(r∈R∧1,c₃>,3,c₂>∈r)成立,且1,c₃>∈r,3,c₂>∈r,无论是直接的还是间接的,将矛盾信息加入集合ErrorMsg,否则继续检查该r关系中未检查的三元组,直到r关系中的所有三元组检查完毕,转步骤(4);

(4) 集合R中的所有元素都处理完毕,则转步骤(5),否则转步骤(3);

(5)若ErrorMsg不为空,输出OntoThesaurus中所有传递关系越级的矛盾信息,即print(ErrorMsg),否则提示OntoThesaurus中不存在传递关系越级的矛盾信息。

用Java编程实现了这些算法。本方案与原方案均采用Java语言进行实现,且没有改变系统的架构,不同之处在于原方案对于本体模型的读取、检索、推理和写入都采用Jena提供的API实现,而本方案则基于Lucene提供的API对这些功能进行实现。