基于国共合作领域本体的知识推理模块实现

6.4.4　基于国共合作领域本体的知识推理模块实现

国共合作领域本体推理模块是基于TABLEAU^［27］和RETE算法的推理机制实现的。其主要功能有:

●本体推理引擎:根据本体库即存事实由规则推理出新的知识。

●本体逻辑检测分析器:检测推理后的新的本体库是否有逻辑错误，如图6-12系统推理功能框架图所示。

图6-12　系统推理功能框架图

●本体推理路径回溯分析器:对于由检索模块检索出的结果，分析它的推理过程，如图6-13本体推理路径回溯分析器所示。

图6-13　本体推理路径回溯分析器图

本体推理引擎和本体逻辑检测分析器实质上是属于建库模块的推理功能扩展;而本体推理过程分析器应用于检索模块的结果分析。

1.本体推理引擎

(1)推理规则的选用与优化

推理引擎的工作是利用规则推理来发现本体库大量事实中蕴涵的知识，表现本体库知识中可推论的部分。要实现这一工作目标，首要任务是建立一个符合应用需求的规则库。规则库由大量规则和少量事实组成。首先建立基于自然语言描述的规则，再将这些规则转换成规则语言描述的规则。

根据推理知识的不同，规则库中规则可分为两种:本体类推理规则和本体属性推理规则。在自然语言描述的规则库中，我们设定了3个本体类推理规则和95个本体属性推理规则。转换成规则语言描述的规则后，规则库中包含了3个本体类推理规则和120个本体属性推理规则。

但是我们在做本体库推理时，并没有把所有的规则全部放入规则库。因为经过测试，我们发现，在所有规则正确无误的情况下，引入整个规则库将长时间占用极大的服务器资源，长达15分钟的等待时间是任何一个用户都无法忍受的。所以我们需要对规则库进行优化。

优化的标准有两个:推理出的蕴涵知识的意义和运行效率。作为历史领域的两个活跃元素，事件和人物是人们重点关注的对象。所以事件和人物相关知识的推理对整个项目是具有重大意义的。因此，我们保留了人物和事件本体的大多数推理规则。而那些推理意义不大，又需要占有大量计算资源，影响运行效率的规则，则被我们从规则库中剔除。而对那些具有一定推理意义，又需要占有大量计算资源，影响运行效率的规则我们将其提取出作为动态规则。所谓动态规则，即规则是在系统运行时根据用户提出检索要求动态组装而成。如，事件发生先后顺序的知识对于用户来说是非常有意义的，但是如果将其推理规则写成规则库中的静态规则，那么生成本体推理库的时候，Jena推理机将把所有的事件时间点两两比较，这种推理运算量是巨大的，但是任何两个事件的前后顺序知识是没有太多意义的。而利用动态规则推理，我们可以极大缩小推理范围，提高运行效率，从而也较好地响应了用户的检索需求。最终我们确立下来的规则库只包含了本体属性推理规则。其中静态规则102条，动态规则5条。

(2)推理引擎功能的实现

实现推理引擎功能，Jena2推理引擎其结构如图6-14所示。在系统实现中，我们使用ModelFactory类把推理机与数据模型关联起来，以达到推理的目的。当用户提交查询以从RDF数据模型获取数据时，不仅能得到数据模型本身所含有的数据，而且可以得到由推理机制所产生的蕴涵知识数据。

图6-14　Jena 2推理引擎结构图

Jena中包含的推理机有:传递推理机、RDFS规则推理机、OWLLite推理机、DAML micro推理机以及通用规则推理机(Generic rule reasoner)，其中通用规则推理机基于用户指定的规则来进行推理。在Jena中获得一个推理机方法有工厂方法、推理机注册器方法、本体模型规范方法、模型工厂方法四种方法^［28］。

在实现国共合作领域本体库推理机制中，主要是采用工厂方法中的GenericRuhReasonerFactory来获得通用规则推理机，从而引入事先测试好的形式化的规则库文件对本体库进行推理。基于推理出的蕴涵知识的意义和推理效率的原则，我们完全摒弃了Jena中的RDFS规则推理机(RDFS Role Reasoner)，OWL-Lite推理机(OWL FB Reasoner)等内置推理机。原因是对于国共两党合作这样的历史领域本体库，基于描述逻辑的推理结果意义并不大。比如OWL推理中，有这样一个类推理规则:［rdfs7:(?a rdf:type rdfs:Class)→(?a rdfs:subClassOf?a)］。它的意思是如果?a的类型是rdfs:Class，那么推理出?a是它自己的子类。事实上这样推理出来的新三元组或者说是新知识意义并不大，在本体系统的其他模块中(比如检索和建库)并不会用到这样的三元组，用户也并不关心这样的新知识。但是如果规则库中有这样的规则，推理机会自动按照这个规则应用RETE算法进行推理匹配，最后的结果只能是让推理之后的新本体库包含大量的无意义的垃圾信息。所以我们只是针对自定义的107条含有历史意义规则进行推理，用通用规则推理机来实现。

具体实现步骤如下:

首先使用Jena从OWL文件中读取本体库数据，创建OntModel对象，在这个对象里，将库中所有的数据以三元组形式保存，这个过程实际上一般会省略，因为OntModel对象只需要在系统启动时建立一次即可，其后将缓存在内存当中，需要访问时，直接调用方法得到该对象的引用就可以了。接下来读取规则文件，解析并创建Rule对象，再通过Jena创建Reasoner对象。通过前面得到的OntModel对象和Reasoner对象就可以调用Jena的ModelFactory工厂类，创建InfModel对象了。代码如下:

Model m=ModelFactory.createDefauhModel();

Resource configuration=m.createResource();

configuration.addProperty(ReasonerVocabulary.PROPruleMode，″hybrid″);

configuration.addProperty(ReasonerVocabulary.PROPruleSet，″ontorules.

roles″);

Reasoner reasoner=

GenericRuleReasonerFactory.theInstance().create(configuration);

reasoner.setDerivationLogging(true);

InfModel infModel=ModelFactory.createInfModel(reasoner，ontMode1);

infMode1.prepare();

在创建InfModel对象后，推理还并没有进行，需要调用InfMode1.prepare()方法来启动推理，如果没有调用这个方法，则推理将在第一次访问推理得到新数据的时候启动。推理完成后，就可以在程序中访问推理后的数据了。对于InfModel有两个用来访问不同部分的数据的方法InfMode1.getDeductionsModel()和InfMode1.get RawModel()，分别返回推理得到的数据和原库中的所有数据。

2.本体逻辑检测分析器

逻辑检测即利用基于描述逻辑的TABLEAU算法对知识库中的概念及其逻辑结构进行推理，以判断概念定义和逻辑结构是否合理，知识库中是否存在逻辑冲突。通过利用基于TABLEAu算法的Racer推理机对我们的本体库进行一致性检测、包含检测和本体实例检测，我们及时发现了一些本体库中人工检错难以发现的错误，同时也减轻了我们管理和维护本体库的工作量。

(1)本体逻辑检测分析器的实现

Jena内建的基于规则的推理机，可以提供对OWL-Lite和部分OWL-DL、OWL-full结构的本体语义推理。不过，对于大型而复杂的本体库，规则推理是十分耗费计算资源的。于是，Jena在本体模型和实现了DIG接口(描述逻辑推理接口)的外置推理机间提供一个透明网关，通过这样一种机制，就可以添加外置推理机了^［29］。DIG接口是一个逐渐发展形成的标准，它通过基于HTYP协议的接口来提供对描述逻辑推理机的访问，从而完成一个分布式的推理过程。现在已经支持的DIG接口推理机有Racer，FaCT和Pellet。DIG接口机制的模型图如图6-15所示。

图6-15　DIG接口模型图

我们使用DIG来调用外部的Racer进行逻辑检错的代码如下:

Model cModel=ModelFactory.createDefaultModel();

Resource conf=cMode1.createResource();

conf.addProperty(ReasonerVocabulary.EXT.REASONER_URL，

cMode1.createResource(″http://localhost:2004″));

DIGReasonerFactory drf=(DIGReasonerFactory)ReasonerRegistry.the

Registry().getFactory(DIGReasonerFactory.URI);

DIGReasoner r=(DIGReasoner)drf.create(conf);

OntModelSpec spec=new OntModelSpec(OntModelSpec.OW L_DL_

MEM);

spec.setReasoner(r);(www.xing528.com)

OntModel m=ModelFactory.createOntologyModel(spec，null);

使用ReasonerRegistry.theRegistry().getFactory(DIGReasonerFactory.

URI)方法创建DIGReasonerFactory对象，再用DIGReasonerFactory的create(conf)方法创建DIGReasoner对象。这里的conf对象是一个预定义的Resource对象，用来设置DIGReasonerFactory对象的参数，比如代码中的ReasonerVocabular.EXT_REASONER_URL参数，用来设置外置推理机的访问地址。得到DIGReasoner对象后，就可以进一步创建OntModel对象了，创建完后就可以进行下面的检测步骤了。

ValidityReport validity=infmode1.validate();

if(validity.isValid()){

System.out.println(″\nOK″);

}else{

System.out.println(″\nConflicts″);

for(Iterator i=validity.getReports();i.hasNext();){

ValidityReport.Report report:(ValidityReport.Report)i.next();

System.out.println(″—″+report);

}

}

在调用ValidityReport对象的isValid()方法，将得到检测结果。如果有冲突，则再调用ValidityReport对象的getReports()方法，这里将返回一个迭代集合，迭代遍历这个集合后，就可以得到完整的检测结果信息了。

(2)国共两党合作本体逻辑检测的局限性

因为目前的本体库逻辑检测完全是通过DIG接口由Racer推理机完成，所以Racer性能的好坏对本体库逻辑检测影响很大。而目前Racer虽然是推理能力较为强大的商业化推理工具，但是其局限性也是显而易见的。由于Racer是基于描述逻辑的TABLEAU算法实现，所以对T-Box，即术语(概念)层次的推理有较好的支持。而对A-Box，即实例推理支持不太好。而且对于OWL的一些属性，如sameAs、基数约束集等也支持不太好。这就意味着使用Racer进行本体库逻辑检测并不能完全检测出库中的逻辑冲突。而且Racer是个商业化推理工具，不提供开源服务。所以我们无法进行二次开发和算法优化，而不能为系统提供更好的个性化推理逻辑检测支持。

3.本体推理路径回溯分析器

(1)推理过程的意义

在用户检索过程中，查询得到的结果可能并不是在本体库中直接断言的知识。而用户很可能对推理的过程感兴趣，以进一步全面获取知识。因此，有必要在用户得到推理结果后，再向用户提供查询推理过程的机制。比如，用户通过查询“在中国发生的事件”，查询得到了“西安事变”，这时在用户界面上将提示这一知识由推理得来，用户这时可能不仅需要这一知识点，还需要知道“中国”与“西安事变”这两个本体实例之间的关系推理来源，从而可以得到更详细的有关“西安事变”的知识。更典型的是用户在查询“毛泽东的家人”时，发现其家人有文七妹与毛新宇这样两个人物，可能就会感觉奇怪，想进一步知道文七妹与毛新宇到底是什么关系，是通过什么中间人建立的这种关系。这就涉及推理路径回溯的问题。在用户对推理过程感兴趣，并提交推理回溯请求后，将提供完整的推理路径。如图6-16所示。

图6-16　推理结果显示图

(2)推理路径回溯的实现

在Jena中针对推理路径的查询提供了比较好的API。Jena得到推理路径实际上是在推理后得到新的本体库的时候完成的。也就是说在引入规则和原库进行推理时，Jena将所有推理过程保存下来，在完成推理后，再使用相关的方法来获取这些推理过程。由于保存推理路径是相当耗费空间的，因此默认情况下，生成推理库时，Jena是不保存推理路径的，需要在进行推理前调用Reasoner对象的一个方法来打开:

reasoner.setDerivafionLogging(tree);

保存了推理路径并完成推理后，就可以通过调用推理库的这个方法来获取推理路径对象了:

InfMode1.getDerivation(Statement)

调用这个方法返回的是一个Derivation对象的迭代集合，通过迭代访问可以得到每一步推理的Derivation对象，调用Derivation.PrintTrace()方法则得到推理路径的描述文本。

Derivation接口只定义了比较简单的几个抽象方法，如果要得到推理路径中的本体实例等，需要用到Derivation接口的一个实现类RuleDerivation。通过调用这个实现类的getMateh()，getConclusion()，getRules()等方法，可以得到推理过程中涉及的所有本体实例，以及它们之间的用于推理的关系等，接下来就可以进行后续的各种处理了。示例代码如下:

Iterator derivItr=getlnfModel().getDerivation(stmt);

while(derivItr.hasNext()){

RuleDerivation deriv=(RuleDerivation)derivltr.next();

if(deriv.getConclusion().matches(

new Triple(A.getNode()，property.getNode()，

B.getNode()))){

for(herator matehItr=deriv.getMatehes().

iterator();

matehItr.hasNext();){

Triple tpl=(Triple)matehhr.next();

if(!tp1.getObject().isLiteral()){

com.hp.hp1.jena.graph.Node s=tp1.getSubject();

com.hp.hp1.jena.graph.Node P=tp1.getPredicate();

com.hp.hp1.jena.graph.Node o=tp1.getObject();

Resource SS=getOntModel().getResource(s.getURI());

Property PP=getInfModel().getProperty(P.getURI());

Resource oo=getOntModel().getResource(o.getURI());

}

}

}

}

推理结果的展现运用可视化的图形方式显示。在普通的检索结果中，图中的结点与结点之间由实线的蓝色有向边连接，表示结点所代表的本体实例之间的关系。在基于推理的检索中，推理结果将以橙黄色有向边表示，从而与普通检索获得属性关系的有向边相区分。如图6-17(彩图)所示。

图6-17中“文七妹”实例与“毛新宇”实例之间由橙黄色有向边连接，这说明这一关系由推理得到，如果用户需要进一步了解推理过程，则可以直接点击橙黄色有向边，点击后，橙黄色有向边展开，并显示该推理结果完整的推理路径，推理路径以粉红色有向边表示。如图6-17所示，点击橙黄有向边代表的“曾孙”关系后，得到展开的“文七妹”到“毛泽东”，“毛泽东”到“毛岸青”，“毛岸青”到“毛新宇”的详细推理结点路径。另外，在显示界面详细处，推理路径所用到的推理规则也会完整显示。