基于测试用例的应用本体需求验证方法研究

2019-09-04 版权声明 举报文章

摘 要:文章从判定语义正确性的基本准则、需求验证方法两方面分析当前研究的不足。在此基础上,针对应用本体特点,提出一个基于测试用例的需求验证模型,并深入分析测试用例的具体内涵,探讨现有的本体测试工具的特点及不足,最后总结需求验证方法与其他评价方法的区别。

关键词:应用本体 需求验证 测试用例

中图分类号: G254.29 文献标识码: A 文章编号: 1003-6938(2013)01-0030-06

本体是领域概念的明确规范化说明。作为知识组织、表示、共享及互操作的基础,已广泛应用于自然语言处理、知识管理、信息抽取、智能搜索中。语义网的发展强化了用户对能力本体的需求。所谓能力本体,就是能够满足应用需求的应用本体[1-2]。本体需求的主要表现是能力问题和推理任务。本体的详细程度不同,刻画其需求的能力问题也是有差异的。应用本体旨在描述特定应用或具体业务相关的概念、关系及约束,因而其能力问题或推理任务往往是详尽的、具体的,代表实际要解决的问题。在这种情况下,验证需求是否得到满足就非常重要,且验证的目的在于发现错误的数据并进行更改。只有能够准确,在结构上严谨(一致性、简洁、完整)、在逻辑上完备(包含所有必备的知识)、在语义上正确(所定义概念、关系及公理或约束与领域知识相符)的应用本体,才是真正有用的本体。然而,到目前为止,还没有自动化需求验证方法,也没有成熟的、识别并诊断与需求不符的错误数据的方法。

本体开发是个复杂的过程。一方面,受人员素质、需求识别方法、开发技术等因素影响,所得本体在结构、功能、可用性等方面都可能存在问题,质量难以保证。应用本体也不例外;另一方面,现有本体开发方法普遍缺乏对需求验证的支持,这严重阻碍后续的应用。因此,本文以开发场景下的需求验证为重点,分析现有需求验证方法的不足,并结合单元测试技术对现有方法进行改进,以保证本体与需求的一致性。

1 研究现状

需求验证需要通用的判定准则和自动化的验证方法,因此本节将分别从判定准则、需求验证方法两方面来阐述当前研究的不足。

1.1 缺乏判定语义正确性的基本准则

从需求描述看,现有各种本体开发方法多通过需求说明文档来描述需求,包括开发本体的目的、范围、本体应具备的功能和非功能属性等,旨在为本体开发和后期的验证提供参考。从这个意义上讲,需求说明文档越详细越好。但现有本体开发方法中的需求文档大多都是指南性的,内容宽泛,缺乏基本的严格性和规范性,很难满足本体开发和本体验证的需要。

在设计企业本体(Toronto Virtual Enterprise Ontology,TOVE Ontology)时,Gruninger and Fox等通过能力问题来刻画本体需求[3]。能力问题是一系列在构建本体之前就确定的、用自然语言描述的、本体必须回答的问题及参考答案,用于为定义本体中概念、关系和公理提供指南。这种需求说明方法的局限在于:用户并不能列出所有能力问题,因而能力问题是不完备的。满足CQ的本体并非就一定满足其他潜在的需求[4]。

METHONTOLOGY则进一步从实践操作上探讨如何通过能力问题来刻画本体需求并推进本体开发,但并没有解决能力问题的不完备的问题[5]。

为更加系统、全面、准确的获取需求,NeOn项目提出一个通过模板(本体需求说明文档的模板ORSD)和样表为需求分析和描述提供指导的需求开发指南。需求说明文档必须明确说明开发本体的动机、目标、范围、语言、使用场景、适用对象和具体需求(包括功能需求和非功能需求)等。功能需求用能力问题来刻画,可以为本体开发和评价提供多方面支持。实践证明,该指南虽然能发挥一定的指导作用,但部分步骤还是过于粗略,也不能实现自动化。需求都是自然语言描述的,无法直接利用模型论在自动推理上的优势,后续的开发与验证需要大量的人工干预,效率较低[6]。

从判定本体语义正确性的基本准则看,现有需求研究普遍缺乏对应用本体的关注。应用本体的特点是描述特定场景(使用场景下的期望模型都是具体的、详细的)的概念、约束及业务规则,相对于轻量级本体更容易出现深层的语义错误,其语义要求相应的就应该是更具体、更深层。现有针对轻量级本体的、判定分类体系正确性的约束准则(如OntoClean)并不能充分代表对富语义、重量级应用本体的要求。没有充分刻画的语义要求,就很难得到高质量的应用本体。因此,如何形式化描述应用本体必须满足的、语义要求就成为亟待解决的关键问题,这也是实现自动化验证的基本前提[7-8]。

1.2 缺乏自动化的需求验证方法

理想的需求验证方法是自动化的、能从语义上验证本体内容的方法,但现有的本体验证方法,如基于推理机的一致性检测、基于OntoClean的分类关系评价和基于能力问题的词汇覆盖率评价等,还远没有达到这样的要求,也不满足应用本体需求验证的需要,下文将深入阐述其原因。

从理论上讲,一致性检测只是考察本体中是否存在相互矛盾的知识,并不能检测内容的正确性。通过一致性检测的本体并非一定就满足应用需求。这是因为,证明本体的一致性很容易,只需找到一个本体模型便可。但存在一个模型只能说明本体理论在该模型所代表的特定场景下一致,并不能保证本体在所有情况下都一致。假定某几何本体中存在句子:边是面与面的交集,在立体几何中该句子是可满足的,也就是说,该本体至少存在一个立体几何模型,因此是一致的;但在平面几何中,边只属于一个面,该句子是不满足的,对于需要平面几何的应用而言,该本体显然是不符合需求的。综上所述,就应用本体而言,仅用一致性检测方法是不够的,还要利用形式化表达的应用需求对本体内容进行测试才能保证内容正确性(若添加平面几何所特有的假定:边只能属于一个面,那么该本体就变得不一致、边是面与面的交集的错误便可识别了)[9]。

OntoClean是基于哲学概念及原则来验证分类关系的正确性,其局限在于:首先,所谓正确性是狭义的、针对特定哲学规则而言;其次,实施困难,需要领域专家手工操作,不能保证完备性,很容易变成随机测试;再次,OntoClean只能验证分类关系正确性。这对弱语义本体、简单本体而言是充分的,但对于富语义、应用本体而言却是远远不够。应用本体的特点在于具有丰富的非分类关系(公理),这些关系间往往存在复杂的约束和规则,更易于出现深层语义错误,因此,非分类关系才是要验证的重点;OntoClean只关注本体逻辑结构的正确性,不考虑本体的具体需求。此外,本体也可以描述抽象事物或者隐含在现实世界中的经验知识,如何为这类术语添加元属性目前尚不明确,OntoClean无法为抽象术语或概念添加元属性,也无法处理具体领域关系。总而言之,OntoClean方法对本文研究内容是不适用的[10]。

能力问题是对建模需求的部分刻画,是在本体开发前就确定的一系列本体必须回答的问题,用于说明或限定本体的功能,也是本体必须通过的测试。现有能力问题验证法的基本过程是:将能力问题转化为SPARQL检索式检索本体知识库,将实际答案与参考答案对比。若相符,则表明本体满足该需求;若不符,则表明本体不满足该需求。

就应用本体而言,能力问题评价法的局限在于:在有些情况下,确定能力问题后,其答案是无法穷举的(如鸟有哪些子类?无法详尽列出所有答案),或者不可能存在的(谁既是a的父亲又是a的母亲),简单的SPARQL检索不能恰当的处理这些情况;只关注实际检索结果是否与预期相符,并不关心检索结果的生成方式(是明确声明的断言,还是基于特定公理、通过已有事实推理出来的),不能检测特定公理、约束或规则的正确性;自身的不完备性。受各种因素影响,需求分析过程并不一定能穷举所有需求,因此能回答所有问题,并不意味着被测本体就是完备的。

综上所述,就应用本体而言,前两种都属于结构评价,不考虑功能及具体应用需求。后者虽然考虑功能,但只关注词汇覆盖率,并没有深入到语义,都不能达到自动化需求验证目的。要验证本体是否满足应用需求,还需对上述进一步深化或者用其他方法做补充。

2 基于测试用例的需求验证

为解决上述问题,本文借鉴软件测试及不一致诊断领域的研究成果,用形式化的需求来定义测试用例,用测试用例作为蕴含推理的后件来约束本体的语义,通过一致性检测或蕴含推理来验证本体内容的正确性。任何不能通过测试的本体都不是合格的本体,不管采用何种开发(如自上而下对引入本体进行具体化、或者自下而上在实例中应用学习推理算法)。若本体与需求不符,本文通过不一致诊断技术来识别与需求冲突的最小公理集合,以便对其进行修正,最终找到一个与需求相符的最大一致子本体。

2.1 理论基础

Megan Katsumi等人认为应用需求来源于期望模型。若本体在语义上正确,那么其实际模型与期望模型就应该等价,但模型之间的等价关系无法直接证明。为达到自动化验证的目的,作者利用数学理论,引入表示定理、解释、转换公式、相对解释等概念,从理论上阐明如何把本体模型与期望模型之间等价关系的证明转化为本体schema与数学理论(用数学结构来完备刻画期望模型)之间等价关系的证明。根据模型论语义,理论之间的等价关系可以转化为蕴含推理问题,而蕴含推理问题可通过推理机来实现,那么自动化需求验证成为可能[11] 。

表示定理只有在完全理解期望模型的条件下才能定义。但在实际应用中,这种完全的理解通常很难达到,尤其当本体还不太成熟时。这就需要适当的变通,允许对期望模型进行部分刻画。也就是说,除完备刻画方法外,还需要其他部分刻画方法来说明需求。其理论依据是:本体模型中关系的外延所具有的属性应该等价于期望模型中关系的外延都能满足的属性。也就是说,从本体推出的任何结论都应该蕴含在期望模型中;反过来,从期望模型中提炼出来的任何能力问题都应该被本体模型所蕴含。更进一步,若不考虑本体的成熟度,用本体schema中的术语来形式化描述这些句子,对于所有期望模型蕴含的句子a,若能够证明本体Tonto也蕴涵a,那么就可以说本体满足了该句子所代表的需求[12]。

2.2 需求验证模型

由上述分析可知,若把应用需求用本体中术语来形式化描述、并定义为测试用例,那么需求验证问题便可转化为基于测试用例的蕴含推理问题。根据测试用例与本体之间的关系,可以将测试用例划分为4个不相交子集:TC+代表一致的公理集合;TC-代表不一致的公理结合;TI-代表必须被本体蕴含的公理集合;TI+代表不能被本体蕴含的公理集合[13]。

(1)KB∪e+ consistent,?e+∈TC+

(2)KB∪e-inconsistent,?e-∈TC-

(3)KB|=ne-,?ne-∈TI-

(4)KB不蕴含ne+,?ne+∈TI+

利用否定符,可以把蕴含推理问题归约为本体合并及一致性检测问题。若要求本体蕴含着某公理,那么并上该公理的否定就一定是不一致的;若要求本体不蕴含某公理,那么蕴含该公理的否定、或者不存在任何与该公理相关的信念都是可以的,因此并上该公理的否定一定是一致的。也就是说,第三种情境就可以归约为第二种情境,检测KB∪e-是否unsatisfiable;第四种情境也可以归约为第一种情境,检测KB∪e+是否satisfiable。不失一般性,本文将只考虑前两种情境。

开发知识库的目的是为了推理。在经典逻辑系统中,推理服务必须以可满足的知识库为基础。若本体与需求相符,那么给定测试用例,其关系一定是符合上述要求的。若推理结果与预期不符,则表明本体有错,存在非合法蕴含式或者与需求冲突的句子,需要对其进行诊断与修正,也就是根据本体、需求及测试用例来识别与需求不符的、必须修改或删除的最小公理集合,或者添加特定的公理,以获取一个与需求相符的、能通过所有测试的最大一致(或连贯)子本体Ot的过程,其本质就是不一致诊断。为形式化描述该过程,本文提出一个基于测试用例的不一致诊断模型,包括诊断问题、目标本体、诊断等基本要素[14] 。

一个诊断问题是一个由不一致本体O、一系列背景公理B、一系列必须被Ot蕴含的逻辑句子集合P、一系列一定不能被Ot蕴含的逻辑句子集合N共同构成的四元组。引入背景理论B的原因在于:诊断过程中,开发者可能会预定义一些肯定正确的、原则性的逻辑句子,这些句子不应该出现在任何诊断中[15]。

一个目标本体Ot是由一系列背景公理B、一系列必须被Ot蕴含的逻辑句子集合P、一系列一定不能被Ot蕴含的逻辑句子集合N共同刻画的逻辑句子集合。可以为识别目标本体Ot提供充足的信息。给定,不满足下述任何约束条件的Oi都不是符合要求的Ot。

(1)Ot 必须是可满足的或者连贯的;

(2)B?Ot;

(3)Ot|=p,?p∈P;

(4)Ot不蕴含n,?n∈N;

假设是诊断问题的一个具体实例, EX是为满足需求而必须添加到知识库中的逻辑句子集合,那么该诊断问题的诊断D就是满足以下约束条件的公理集合:

(1)(O\D)∪B∪EX是一致的或者连贯的;

(2)(O\D)∪B∪EX|= p,?p∈P;

(3)(O\D)∪B∪EX不蕴含n,?n∈N;

一个诊断为本体O定义了一个划分,也就是将O划分为两部分:D中的每个公理都是错误的;D之外的其他公理都是正确的。若Dt是要修正的目标诊断,那么目标本体Ot=(O\Dt) ∪B∪EX。

诊断描述了要修正的公理集合。修正公理不是随意的,仅在有证据表明其错误的条件下才进行修正。诊断概念的定义并没有对错误本身做出任何假定,因此公理具体属于哪类错误无关紧要。在某些情况下,如缺公理时,最小诊断D便是空集,因为没有必须要改变的公理集合。EX用于描述必须添加到本体中的公理集合,只根据需求或测试用例对当前本体进行修正,并不关注如何学习新公理。若用必须被Ot所蕴含的句子P来替代EX,那么不用真正扩展EX也可以形式化描述目标本体Ot[15]。也就是说,对于一个诊断问题的具体实例,若满足以下条件,则公理集合D是诊断:

(1)(O\D)∪B∪p∈P P是一致的或者可满足的;

(2)对于?n∈N,(O\D)∪B∪p∈P P不蕴含n;

根据描述逻辑的单调性,对于一个诊断问题的具体实例,若B∪∪p∈P P是一致或连贯的;并且对于?n∈N,B∪∪p∈P P不蕴含n,那么一定存在一个诊断D。

3 测试用例的类型

测试用例可以是T Box公理,也可以是A Box断言。

3.1 用实例断言定义的测试用例

用SPARQL检索式形式化描述能力问题、用XML或JSON形式化描述相应的参考答案。

添加实例断言并调用推理机进行分类计算和实例关系推理。

选择要测试的问题,检索本体知识库:若答案明确,则用SELECT语句获取答案;若答案不明确,则用CONSTRUCT描述约束条件、并与O合并,检测结果一致性;

若实际答案与预期不符(不考虑答案的先后次序),则表明本体有误,需求没有满足。

需要注意的是,能力问题用于定义本体的边界和核心功能,仅在测试明确表达的需求、构建初始本体时有效,下文的推理任务则更适用于测试其他补充的需求、适宜在维护阶段创建并不断完善[16]。

3.2 用术语公理定义的测试用例

能力问题只关注是否能得到预期的检索结果,并不关心检索结果的生成方式,如究竟是明确声明的断言,还是基于特定公理、通过已有事实推理出来的。利用测试用例(也就是用本体中术语来形式化描述的推理任务)便可弥补这方面的不足,将需求验证转化为蕴含推理问题(特定公理是否被本体所蕴含),达到约束本体语义的目的。[17]

正测试用例:本体应该蕴涵的公理集合P,若被测本体没有蕴涵其中某个公理,则该本体是不满足需求的,需要扩充相应的公理。

负测试用例:本体不该蕴涵的公理集合N,若被测本体蕴涵其中任何公理,则该本体是不满足需求的,需要诊断其原因并进行修正。

需要注意的是,测试并不需要罗列所有可能的公理,只是列出描述用户所关注的关键性公理即可。例如,当本体不一致时,验证正测试用例P是没有意义的,因为不一致本体可以蕴涵任何可能的公理;当测试对象是空本体时,验证负测试用例N是没有意义的,因为空本体不蕴含任何公理。

与软件工程的单元测试相似,测试用例多是在本体维护过程中创建并不断完善。实际上,也可以先由经验丰富、技术水平高、相对稳定的开发人员给出,然后在本体演化及维护过程中,再由技术水平一般、变动较频繁的维护人员根据使用情况对其进行更新和完善。一旦发现潜在错误或者任何用户要求的、可以用OWL公理描述的需求,维护人员便可将其形式化并加入相应的测试用例中,以避免重复出现该错误,降低测试和维护成本。

需要注意的是,测试用例需单独维护,不能直接将正测试用例中的公理或负测试用例中公理的否定合并到被测本体,这是因为:并非所有的公理都有否定形式,如角色公理或断言,在OWL DL中是无法否定的;基于开放世界假设,不蕴含N所表达的语义并不等同于蕴含着非N,也可能是。也就是说,不知道并不意味着否定,否定后合并会曲解用户的原意;所使用语言构件也可能超出被测本体的表达能力;增加推理复杂性;若某个测试用例与O从其他O中引入的公理相似,合并会造成本体冗余,增加维护负担;负测试用例中允许存在相互冲突的公理,如为避免泄露个人隐私,要求既不能推出肯定事实SameIndividual(P NP),也不能推出否定事实DifferentIndividuals(P NP),这种相互冲突的公理用于描述本体对特定事实的不可知性,也就是说,任何通过测试的本体在这件事上都是无知的。在这种情况下,负测试用例就不能公布于众,否则就泄露线索,难以保护原本要保密的真实信息。

SPARQL与正测试用例有时可相互转化,大多情况下是互补关系。相对于SPARQL,测试用例从一定程度上深化了需求的内容,具体到特定OWL公理,以判断其是否明确存在于本体中。该方法的局限在于:虽然节省了时间和成本,但测试用例不可能覆盖所有关键性公理,需不断更新。

3.3 用约束定义的测试用例

要检测本体中是否存在特定约束或约束表达是否正确,可通过变异测试来实现,也就是特意输入不正确的、或者错误的数据、或边界值数据,看本体是否能检测该异常。理想情况下,输入正确的测试数据后,本体会返回预期的推理结果,不出现任何其他不相关或错误的推理结果;与此同时,若输入与约束不符的、错误的数据后,本体也应该很快检测该冲突。也就是说,本体实际执行的推理过程与期望的完全相符。这便是错误预防类单元测试的核心思想。为实现该过程,Denny Vrandecic等建议将本体分解为两个版本:一种是带约束的复杂本体,一种是不带约束的简单本体。简单版本主要定义相关的术语集及术语间的分类关系,复杂性低,推理效率高;复杂版本则包含更多的领域公理和约束。后者用于测试,而前者用于提供推理服务[17]。

大多数情况下,引入某些复杂约束(如不相交关系、基数约束等)并不能推出新的知识,仅是为了描述本体应满足的约束、以检测与约束冲突的实例或概念。例如,引入最小基数约束是为了限制与特定概念实例存在特定关系的实例的个数,引入不相交公理是为了检测本体一致性,二者都只是用于检测冲突,以便向用户提供有价值的反馈信息,并不能推出新的知识。

将冲突数据作为实例与本体合并,若确实出现不一致,则表明相关约束是存在的且能够正确发挥预期作用(尤其在本体映射、本体对齐或合并不同信息源的场景下)。这种检测仅在本体投入应用前进行,且只需一次,无需在每次推理前都测试。

4 相关本体测试工具

本体测试最早由Denny Vrandecic等提出。受软件工程中测试框架的启发,他们尝试用多种不同的方法进行本体测试,但并没有结合本体开发过程提出系统的、详尽的本体测试方法论和指南[17]。为解决该问题,Blomqvist进一步扩展本体测试的类型,构建测试用例元模型、给出测试过程的基本要素及具体内涵,并从操作层面上探讨具体的实现方法[18]。与Blomqvist研究成果最相关的工具是Garcla等提出的OntologyTest,但局限在于:首先,它并没有应用“尽量将任务细分”的设计原则,并没有把测试用例和测试执行过程分开、以实现一次测试一个需求,也没有把测试数据和被测本体分开;其次,它所关注的问题是测试的类型(如各类推理任务)而不是如何执行测试;再次,该方法目前还不能在现有任何本体工程环境中运行[19]。Horridge等提出的OWL测试框架(The OWL Unit Test Framework)是少有的本体测试工具之一,主要基于启发式规则、OWL-DL建模过程中的常见错误模式来检测错误,可构建正测试用例,检测本体是否蕴涵了应该蕴涵的知识。该工具利用注释属性将测试用例附加到相应的、特定的命名类之上,但测试内容仅限于本体语法及逻辑结构的正确性,与具体任务或功能无关[20-21]。

与测试问题相关的、其他的研究成果是一系列诊断工具中的测试方法、以及内嵌在XD工具集中的XD Analyzer,它们大多都采用与OWL测试框架类似的启发式规则,关注的焦点也是结构特性而不是功能特性,不考虑特定应用需求的[22]。

5 结论

从本体评价的视角看,本文研究的需求验证的特点在于:关注本体内容与应用需求的一致性,因此属于功能视角的语义评价,优于结构视角的语义评价方法OntoClean;关注本体是否以正确的方式实现形式化需求,因此属于功能视角的本体验证,优于结构视角的一致性验证和OntoClean;以面向特定任务的应用本体为研究对象、关注其功能需求,因此属于功能视角的任务评价法,自动化程度高,不同于面向覆盖率的文本语料评价法;验证过程需要预先确定测试用例以及测试用例与本体之间的关系,根据实际结果与期望结果是否相符来判断需求是否得以满足。若本体与需求不符,则通过不一致诊断方法来识别必须进行修改最小公理子集或扩充的蕴含式,以得到符合要求的最大一致子本体。这与软件测试的目标及过程极为相似,因此本文主要借鉴软件测试的相关理论和方法分析应用本体的需求验证方法。

参考文献:

[1]Annamalai, M.Formative evaluation of ontologies for information agents[C].Conference in Computer Science, Technology and Networking. Shah Alam,Malaysia. 2005.

[2]Annamalai, M. & Teo, N. I. Tool support for competency evaluation of web-ontologies[C].International Conference on Informatics. Petaling Jaya, Malaysia.2007:110-117.

[3]Gruninger, M., Fox, M.S.The role of competency questions in enterprise engineering[C].Proc. of the IFIP WG

5.7 Workshop on Benchmarking - Theory and Practice,1994:1-17.

[4]Gruninger, M., Fox, M.: Methodology for the Design and Evaluation of Ontologies[C]. Proc. of IJCAI 1995, Ws. on Basic Ontological Issues in Knowledge Sharing,1995.

[5]Fern'andez, M., G'omez-P'erez, A., Juristo, N.METHONTOLOGY: from Ontological Art towards Ontological Engineering[C]. Proceedings of the AAAI 1997, Spring Symposium Series on Ontological Engineering,1997:33-40.

[6]Suarez-Figueroa, M.C., G'omez-P'erez, A., Fern'andez-L'opez, M. The NeOn Methodology for Ontology Engineering[A]. Ontology Engineering in a Networked World[M].Springer, 2012:9-34.

[7]Guarino,N.,Welty,C.,Evaluating ontological decisions with OntoClean[J].Communications of the ACM, 2002,45(2):61-65.

[8]Michael Gruninger, Torsten Hahmann, Ali Hashemi,Darren Ong. Ontology verification with repositories[C]. In FOIS, 2010:317-330.

[9] Michael Gruninger, Torsten Hahmann,,Megan Katsumi. Exploiting Modularity for ontology verification[C].Proceedings of the 5th International Workshop on Modular Ontologies, 2011.

[10]Nicola Guarino,Christopher Welty. An overview of ontoclean[A].Ste_an Staab and Rudi Studer,editors,Han

dbook on Ontologies[M].Berlin:Springer,2004:151-159.

[11]Megan Katsumi,Michael Gruninger.Theorem proving in the ontology lifecycle.[C]Proceedings of the International Conference on Knowledge Engineering and Ontology Development(KEOD2010), 2010:37-49.

[12]GrüningerM., HahmannT., HashemiA., et al.Modular first-orderontologies via repositories[J].Applied Ontology,2010,(7):169-210.

[13]Friedrich, G., Shchekotykhin, K.: A General Diagnosis Method for Ontologies[C].Proceedings of 4th International Semantic Web Conference,2005:232-246.

[14]Kalyanpur, A., Parsia, B., Horridge, M., Sirin, E.Finding all Justifications of OWL DL Entailments[C]. Proceedings of 6th International Semantic Web Conference,2007:267-280.

[15]Shchekotykhin, K., Friedrich, G., Fleiss, P., Rodler, P.Interactive ontology debugging : two query strategies for efficient fault localization[J].Web Semantics: Science, Services and Agents on the World Wide Web,2012(12-13):88-103.

[16]Prud’hommeaux, E., Seaborne, A.: SPARQL Query Language for RDF. W3C Recommendation(2008)[EB/OL].[2012-10-23].http:///TR/rdf-sparql-query/.

[17]Vrandeˇci'c, D., Gangemi, A.: Unit Tests for Ontologies[A]Meersman,R.,Tari Z.,Herrero,P.(eds.) OTM 2006Workshops[M].Berlin:Springer,2006:1012-1020.

[18]Blomqvist, E., Presutti, V., Daga, E., Gangemi, A.: Experimenting with eXtreme Design[A].Cimiano,P., Pinto,H.S.(eds.) EKAW 2010[M].Berlin:Springer,2010:120-134.

[19]Garc'a-Ramos, S., Otero, A., Fern'andez-L'opez, M. OntologyTest: A Tool to Evaluate Ontologies through Tests Defined by the User[A].Omatu, S., Rocha, M.P.,Bravo, J., Fern'andez, F., Corchado, E., Bustillo, A.,Corchado,J.M.(eds.)IWANN2009,Springer,2009:91-98.

[20]Horridge, M.: The OWL Unit Test Framework[EB/OL].[2012-10-23].http:///downloads/owlunittest/.

[21]Wang, H., Horridge, M., Rector, A.L., Drummond, N., Seidenberg,J.: Debugging OWL-DL Ontologies:A Heuristic Approach[A].Gil,Y.,Motta,E.,Benjamins,V.R., Musen,M.A.(eds.)ISWC 2005[M].Berlin:Springer,2005:745-757.

[22]Presutti, V., Daga, E., Gangemi, A., Blomqvist, E.: eXtreme Design with Content Ontology Design Patterns[C].Proc. of WOP 2009, Collocated with ISWC 2009. CEUR Workshop Proceedings,2009:90-100.

作者简介:宋丹辉(1983-),女,中科院国家科学图书馆博士研究生。

注:本文为网友上传,不代表本站观点,与本站立场无关。举报文章

0

好文章需要你的鼓励

上一篇:论诚实信用条款在民事诉讼法中的具体化适用 下一篇:在生活中学习作文让作文充满着活力

你需要文秘咨询服务吗?

客服团队跟踪服务,时刻为您答疑解惑

了解详情
期刊推荐咨询,轻松见刊

期刊咨询定制化服务,1~3月见刊

了解详情

被举报文档标题:基于测试用例的应用本体需求验证方法研究

被举报文档地址:

https://wenmi.com/article/pxb3280320zg.html
我确定以上信息无误

举报类型:

非法(文档涉及政治、宗教、色情或其他违反国家法律法规的内容)

侵权

其他

验证码:

点击换图

举报理由:
   (必填)

发表评论  快捷匿名评论,或 登录 后评论
评论