下载掌阅APP，畅读海量书库
立即打开
1.2.1.1 本体演化的原因
文献[11]认同的本体发生变化的原因有以下几个。（1）一个本体就像任意一个包含领域关注点的信息结构体一样，相关信息可能会简单地由于关注点发生变化而改变。即使不现实地假设存在一个一成不变的领域，有时也需要改变观察领域的视角，视角变了，本体内容自然不同。（2）另外一个可能性是发现忽视了用户的某个隐性需要，原始领域概念模型中包含了一个设计错误，需要根据用户的需求综合更多的功能，于是需要改正本体错误，扩充本体内容。（3）类似地，像不相容或语义不连贯这样的矛盾可能暴露出来，这种情况下也会采用行动应对这个矛盾。（4）更进一步，以前是未知的、未分类的新信息，现在变成可用的了，或者是该领域的不同特性变得已知和重要了。此外，本体变化的原因还与本体开发和语义网的特性有关。
本体开发是一个复杂的系统工程，过程上需要本体工程师分工协作，多个部分本体组合在一起而形成最终的本体。这个过程中需要对子本体进行修改以达到一个相容的正确的结果状态。即便如此，所谓的“最终”状态也很少是最终结果，因为本体开发通常是一个持续演进的过程。
语义网的特性也决定了本体动态变化的特点。语义网上的本体通常依赖于其他本体，但本体工程师可能对它们根本无法完全控制。如果由于某些原因，这些“远程”本体被修改了，依存本体也就需要修改，以便体现术语和表达方面的变化。其他变化的情形还包括：某个智能体、服务或应用可能需要使用一个本体，它的术语或表示与它所理解的不同，这时就需要对引入本体进行某种转换（变化）才能使用；再就是也许需要从两个或更多本体中综合信息以便生成一个更适用于某个应用的本体。
1.2.1.2 本体演化的定义
本体演化 [12,25] 是为适应变化而对一个本体做出的及时修正，要求是保持结构上的相容性、用户自定义的相容性和逻辑一致性。一个变化可能导致本体其他部分的不一致，还会影响到相关的智能体、服务和应用。所以说，本体演化是一系列一致性传播过程，它包含技术上和管理上的多种活动 [26] ，这些活动的目的是有效地保证修改后的本体依旧能够满足结构上一致性和用户的需求。
1.2.1.3 本体演化与数据库模式演化
数据库中的模式演化一直是热点的研究课题 [27～30] ，本体演化和数据库的模式演化有密切的联系 [27] ，尤其是面向对象的数据库 [31,32] 。表1-1对比了数据库模式和本体在实例、查询上的不同特点，二者的演化条件有所不同，但在变化传播方面，数据库模式变化影响的控制要么是通过维持相容性规则完成，要么是通过基于公理的推理机制完成 [33] ，而本体变化要将这两种方法结合起来使用。
表1-1 数据库模式演化与本体演化
（续表）
相对于关系数据库，本体演化更接近面向对象数据库的模式演化，表1-2对比了两者的不同之处，需要指出的是有几个本体演化改编自面向对象数据库模式演化的方法，但两者模型之间的区别使本体演化方法不仅是对已有方法的改写，而且是一种扩充 [36] 。
表1-2 面向对象的数据库模式演化与本体演化
1.2.1.4 本体演化过程
文献[10,12,37]将本体演化划分为变化表示（Change Representaion） [38] 、变化语义（Semantics of Change）、变化实现（Change Implementation） [39] 和变化传播（Change Propagation） [10,27,40] 这4个过程。在此基础上，文献[12,41]将本体演化分成如图1-2所示的6个阶段。第一个是需求获取（Requirement Capturing）阶段，目的是获取系统意欲发生的行为 [9,10,12,14,23,42,43] ；第二个是变化表示阶段，把这些行为用适当的形式（原子变化表示简单的、细粒度的变化，复合变化表示复杂的、粗粒度的变化）表示出来 [7,10,26,44] ；第三个是变化语义阶段，这一阶段的任务是确认和解决由变更引起的连锁反应 [45,46] ，保证本体的一致性；第四个是变化实现阶段，将前两个阶段确认的变更操作作用于本体 [6] ；本体变更对本体实例和相关应用（如智能体、本体等）的影响体现在第五阶段，也就是变化传播阶段 [47,48] ；最后一个阶段是变化验证（Change Validation）阶段，允许本体工程师重新审查变化，如果需要，可能会撤销不合理的变化操作 [49] 。
图1-2 本体演化过程
国外研究者针对本体演化的不同阶段提出了不同的解决办法。
（1）本体变化的发现和表示
对于本体变化的发现国外主要有三种研究方法：①变化驱动的方法 [23] ；②Stojanovic [50] 、Castano [42] 、Plessers [9] 等提出基于用户需求驱动的本体变化发现方法；③数据驱动 [10,43] 的本体变化发现主要是根据本体实例来反向推导，这种本体变化发现方式与基于逻辑的变化发现方式的不同在于，这种方式通常假设环境是封闭的，可以利用数据挖掘等技术实现。
本体变化表示主要分为基本变化和复合变化。研究人员在基本变化的基础上提出了复合变化 [10,50] 。Sassi [51] 给出动态环境中基于Z语言的本体变化类型和变化操作的形式化表示。
国内对本体变化发现和语义表示研究也有初步尝试。例如，吉林大学的鲁宁 [52,53] 等提出一种基于语义的本体变化表示方法，并利用变化语义来保证变化本体的一致性，解决变化导致额外变化的问题；南京航空航天大学的蔡丽宏 [54] 针对OWL本体设计出一种本体变化获取算法，并验证了领域本体半自动化方案的可行性。
（2）本体变化的实施和变化传播
变化实施的研究也有多种方法。①基于用户驱动的本体变更策略 [55] 根据用户使用过程中发现的问题来修改本体，这种方法的缺点在于整个本体变更过程的每一步都需要提交给领域专家，由领域专家对多种变更策略进行理解和判断，决定是否采纳变更，这样的演化方式过分依赖领域专家，而不同的领域专家也可能因为知识结构等的不同，对修改做出截然不同的判断。②Stojanovic 在文献[37]中将本体演化问题看成是一个重配置问题，文章给出了本体变更的描述并利用图搜索的方法来获得一条能够满足变更需求，并且能够保证变更后本体一致的变更路径，该文章图中的约束也是由用户提供的，也就是说由用户来定义本体需要遵守的一致性规则。③Plessers [8] 提出一种结合了自顶向下和自底向上的本体演化方法，通过保留本体版本的变化轨迹，比较多个本体版本，得到版本之间的差异，用自动变化检测机制来辅助本体工程师完成本体变更。另外，在信念修正 [56～59] 中已经提出多个与知识更新相关的概念，也已经用于本体的知识表示 [60,61] 中。对本体变更之后的影响也有很多研究 [62～67] 。
国内学者对于本体演化也提出了自己的方法。例如，复旦大学的杨明华等 [68] 提出的方法需要抽取本体中的关系，这是目前尚未解决的问题；中国科学院的刘晨 [69] 利用图的启发式搜索算法来获取本体演化的变更路径；吉林大学的罗景文 [70] 从演化代价的角度出发，根据演化代价是否最小来决定演化路径的选择；周栩等 [71,72] 又将演化代价加入图搜索算法中，提出基于演化代价的本体演化方法。
国内学者对于本体演化影响也做了研究 [44,73,74] 。例如，金龙飞等 [75] 利用邻接矩阵和可达矩阵来分析本体演化的影响范围，量化计算在已知依赖和未知依赖两种情况下的本体演化波及效应；刘晨等 [69] 重点研究本体变更的影响范围，文中根据本体之间的依赖关系量化计算不同本体变更的影响范围，并利用启发式搜索算法找到一条影响范围最小的变更执行路径。
（3）本体演化工具
随着本体演化方法研究的深入，为实现本体演化的自动化进程，近年来本体演化工具 [76,77] 也不断进步。本体编辑器调查中针对几十种不同本体工具的各种方面进行了比较。但是大部分工具不支持本体的协同开发。例如，Protégé [78] 是一个 Java 开源工具，提供多种本体语言的编辑接口，它本身没有推理功能；OntoEdit [21,22] 工具注重本体开发的过程，提供简单的本体评价机制，不支持开放环境中的本体管理、本体集成等操作。这些本体工具有的（如Protégé）支持部分本体演化操作，只是这种能力都比较有限，支持的本体变更策略比较简单，并且也是根据开发工具预先定义的策略来执行的。例如，要删除一个概念，这些工具采取的策略通常是同时删除它所有的子概念，用户无法控制变化的方式。更进一步，工具使用过程中并不会考虑本体演化，尤其是开放式环境下本体演化的复杂性，这使这些自动本体构建和演化工具并不能满足开放环境下的本体演化需求。
本体在开发和维护的过程中不可避免地出现不一致问题或者含有不希望蕴含的结论，因此本体的一致性维护与诊断成为本体应用中不可缺少的推理服务之一，在开放环境下这一问题尤为突出。
（1）演化过程中的一致性
本体演化的变化语义是指本体变化对本体自身的影响，本体变化之后需要检查本体的一致性。文献[12]中认为一致的本体是无法从本体定义中推导出矛盾结论的。这里的一致性 [12,79] 包括逻辑一致性、语义一致性和用户自定义的一致性。不一致本体若不被发现和纠正，所要付出的代价是沉重的，因此保证演化本体的一致性是尤为重要的。
作为本体主要描述语言的描述逻辑 [80] ，最基本的推理问题包括概念满足性检查、本体一致性检查、判断本体是否蕴含某条结论以及回答提问。目前语义 Web 的推理方法 [81] 中主要的经典推理方法包括归结方法、表推演方法、基于公理的系统、自然演绎法以及重写系统等。归结方法 [82] 和表推演方法 [83,84] 是自动推理领域著名的广泛应用的推理方法，逻辑系统的不同也要求对推理技术进行扩展，对于某些非经典逻辑的推理需要探讨扩展的，甚至是混合的推理技术。随着语义Web研究的兴起，描述逻辑系统中的表推演方法以及各种优化技术得到了深入研究，基于表推演的描述逻辑推理工具主要有FaCT++（FaCT,Fast Classification of Terminologies） [85] 、RACER （The Renamed Abox and Concept Expression Reasoner） [86] 、Pellet [87] ，分别实现了完备的公式可满足性的判定过程。
2003 年，Schlobach [88] 等提出了调试描述逻辑术语集的非经典推理的概念，非经典推理又称非标准推理。例如，已知本体蕴含的一个结论，推理的任务就是求解它的一个或全部的最小解释，即由本体中的某些公理所构成的蕴含该结论的最小集合。对本体进行修改会破坏原有本体的一致性，本体由此会蕴含若干不期望的结论，如果能找到其成立的原因，对其进行修正可以使该结论不再成立。因此本体演化客观上需要对一致性进行检测、定位和修复。另外，经典推理中对于有些问题，如循环定义，尚没有得到合理解决，主要是针对一些很小的不带否定构造算子的描述逻辑 [89～94,95] ，因此在目前已实现的描述逻辑推理系统（如Pellet [87] 、FaCT [96] 、FaCT++ [85] 和RACER [86] ）中都给出强制规定：描述逻辑知识库的Tbox中不允许出现循环定义 [97] ，但循环定义可大大扩充描述逻辑的表达能力，而且在许多实际应用中（如医学本体、语义数据模型），循环定义是不可避免的。
本体一致性是本体存在的基础，现有的不一致本体推理研究主要是如何发现不一致和如何为依赖本体的应用提供一致的服务。国外对于本体不一致的推理研究工作主要有三种方式。第一种是预先定义一致性约束规则，如文献[56]中提出在分布式环境下本体演化中的时序行为检测。根据检测不等式是否有解来确定行为序列是否是分布式环境下本体演化的时序序列。文献[8]利用定义好的一致性模型（Consistency Model）来约束变化后的本体，但是这种一致性模型是根据不同的语言进行设置的，不同的语言有不同的一致性模型，OWL不同的语言部分（如OWL Lite和OWL DL）也有不同的一致性模型。文献[12]认为一致性本体应该是遵守所有预定义的一致性规则，包括常量约束、软约束和用户自定义约束。这种一致性推理的局限性在于不能用于本体开发过程中，因为其中的叶子节点概念可能被认为是接下来的一个扩展点。这种方法虽然能够根据语言的语法定制本体变更的策略，按照用户偏好进行演化排序，但对于语义方面可能带来的影响无法估计，也就难以定制相应的应对方法，难以满足语义一致的要求。第二种是利用软件测试的方法对本体进行不一致性诊断。Kalyanpur [98] 和Parsia [99] 利用白盒测试和黑盒测试对本体进行测试，查找是否存在不可满足的概念，还有文献[88,100,101]等。最后一种利用非标准推理进行本体不一致推理 [88,102] 。文献[103]利用OWL中三种本体不一致来源提出一种启发式的调试方法，目的是找到本体不一致的根源。Grau等 [104] 对于OWL本体重用的情况，探讨如何将引用的本体整合到同一本体中，再进行OWL一致性推理。文献[105]将本体重用的情况通过模块划分进行处理，这样做的目的在于能够将本体不一致的检测控制在一定的模块范围内，更有利于本体不一致的定位。另外，还有可辩驳推理 [106～108] 、非单调推理 [109] 、缺省推理 [110] 等非标准推理方法。
国内学者对于本体演化一致性的关注也越来越多 [111～113] 。鲍爱华 [114] 认为，导致本体演化中不一致的根源主要有用户需求变化和环境变化两个方面。他认为针对不同原因导致的本体不一致需要用不同的解决办法。吉林大学的鲁宁 [53] 提出的本体演化一致性模型中包含变化本体本身的一致性约束和用户自定义的一致性约束，并且定义不一致发生时的处理策略。这种方法需要很多的人为参与，模型中的用户自定义一致性的部分处于不断变化中，随时可能增减，而且定制的策略有严重的主观性，没有足够的逻辑依据，并不能保证解决策略的逻辑正确性。复旦大学的杨明华 [68] 提出用一阶谓词进行本体的语义一致性检测，但并没有给出具体的方法。中国科学院的刘晨 [69] 对于保证本体一致性的做法是描述本体所有可能的约束集合，检测本体是否一致是通过验证本体是否符合约束集合中的每一条约束。
（2）开放环境下的本体演化
当前支持 Web 本体演化的方式主要是知识工程师和一小部分领域专家对静态本体的集中开发 [115] ，这种方式复杂、耗时 [116] 。因此，开放环境下基于协作或自动/半自动的演化方法逐渐出现。开放环境下将本体演化视为多人（如知识工程师、领域专家和最终用户等）共同参与完成的一个社交的过程 [117～120] ，这些参与人员可以分布在不同的地点，根据各自的经验和观点参与演化 [37,119,121～124] 。这种本体演化方法既有较高的覆盖度和代表性，又具有较低的成本，且适应于开放环境下通过不断的知识积累进行增量本体变更的情况。但开放式环境下的本体演化是还存在尚未解决的问题 [20,23,123,125～129] 。现有的研究工作总结为以下三点。
（1）开放环境下的本体演化框架研究。Xexéo [130] 、Martin [131] 认为少数参与者集中式的本体开发不能满足语义 Web 的要求， Xexéo在文献[130]中提出一种P2P框架，用于本体协同操作，开发出一个可以更多人共同参与的本体构建管理平台OntoWiki。文献[124]将本体演化根据属性和特点分为不同的场景，提出用 Protégé 插件CHAO（Change and Annotation Ontology）来记录本体版本之间的差异，并将这种差异展现给本体演化的管理者，由管理者最终决定变更操作的取舍。
（2）开放环境下协同演化的方法研究。Haase [17] 和 Clyde [132] 等提出一种由大量具备不同经验和知识的学者和工程师参与的协作式本体开发方法。该方法从初始的本体开始进行多次迭代演化，每次迭代各个参与者都将对当前的本体进行评论，并将迭代结果作为下一次迭代的基础。一直进行到全体参与者对于所得到的本体达成一致意见为止。Benjamin等 [133] 报告了他们在一个人类健康会议上进行的本体协作开发的经历。会议期间有 68 位志愿者参加了这个实验性的知识获取过程，最终得到了一个包含几百个术语和同义关系的共享本体。针对DL下的本体，Haase等 [79] 的本体演化框架整合了他们以前的相关工作：首先假定本体不含矛盾，进行相容本体的演化；若变更引入不相容，就要修复它；若无法修复就采用不相容推理；最后多版本推理综合考虑旧版本的本体和新版本的本体。Klein [20] 记录本体变化日志，进而提出一种支持分布式的本体演化框架，但这种方式不适合开放的语义 Web [134] ，因为变化日志不能记录多用户同时对本体进行修改的情况。Klein [33] 还研究了OKBC本体在开放环境下的变更管理方法，思想是：对于给定的前后两个不同版本的本体，借助本体编辑时所产生的日志，分析得到两本体间的转换信息，用明确定义的操作算子表示前后两本体在概念上的映射关系。
（3）开放环境下本体演化冲突问题研究。Leenheer [135] 在DOGMA [136] 的基础上进行扩充，提出 DOGMA-MESS 方法来支持协同本体演化过程。他利用图变换中的关键对分析方法 [137] 来分析本体演化中的冲突。文献[104]针对开放环境下多本体重用的情况，提出一种合并的思想并对整合后的 OWL 本体进行推理。Alexander [10] 认为在开放环境下不同的本体工程师可能会出现不同的本体变化意见，为了解决这些问题，Alexander 为本体演化引入验证阶段。Stojanovic [138] 认为用户应该能够分解本体变化操作，预见可能存在的冲突并给出满足需求的变化序列，要求用户能够了解每个本体变化操作的语义，而实际上这种要求是耗时且极易出错的，尤其是当本体规模很大并且复杂性很高时，人为完成这样的要求几乎不可能。
国内对于开放环境下的本体演化研究也刚刚起步。中国科学院计算技术研究所智能科学实验室提出的KMSphere —— 知识管理平台 [139] ，其目标是在大规模的、分布的Web资源上建立动态的、跨平台的、多机构的虚拟组织，协调Web资源共享，但也没有对多用户的本体演化意见冲突进行讨论。中国人民大学的李曼等 [140] 指出由于语义Web规模和复杂性的增长，大规模的本体需要多个参与者参与构建和管理，并提出一种基于角色的协同构建方法RCDM。复旦大学的章少雷 [141] 提出开放环境下本体演化的冲突检测和冲突解决方法，他利用本体的URI构建冲突表，并针对用户是否相同或重叠的URI作为冲突判断的依据，再针对不同的冲突进行冲突解决。文献[142]虽然提出协同的概念，但是并没有充分考虑开放环境下的本体演化问题，主要研究集中在企业内部和企业之间的协同。王进等 [143] 通过对本体信息的抽取来支持本体演化，提出一种网络环境中的本体演化和本体管理模型。复旦大学的陈叶旺 [144] 根据本体变化影响的范围将本体协同构建中的冲突分为硬冲突（Hard Conflict）、软冲突（Soft Conflict）和潜在冲突（Latent Conflict），并针对不同的冲突根据影响范围给出检测算法。天津大学的饶国政在文献[74]中对于开放环境下的本体提出一种基于语义WIKI的本体库管理方法。