本体演化管理的方法和关键技术研究进展

[摘要]本体演化管理是本体开发和应用过程中的重要环节，介绍本体演化管理的原因和流程。本体演化管理涉及本体演化需求、本体变化表示、变化传播、协作式本体编辑工作流、本体版本机制等一系列关键技术，针对以上关键技术进行分析，并对国外相关研究给予介绍，以期为本体演化管理工作提供一定参考。

[关键词]本体演化　本体变化表示　本体版本　本体变化传播

[分类号]TP393　TP31

1.引言

近年来，本体在诸多领域内得到了广泛的应用，既包括各领域本体的建设，也包括对各种现有本体的重用。实践证明本体建设是一个动态持续的过程，随着时间的推移，本体自身也需要不断进化和修改。然而随着本体数量的增多，本体各种应用的关联增加，复用本体源本体之间的关系也日渐复杂，这对本体维护和管理提出了挑战。

本体演化是在保证本体一致性的前提下，对本体所作的一系列修改过程，它可以被看作为本体发展过程中一系列操作的结果。也就是随着时间的推移，本体为了不断适应领域的发展变化和各种新的需求而做出相应变化，并保证这些变化可以传播到之相关的其他应用之中。本体演化也可被称为本体进化。

目前关于本体演化管理的研究多分散在各个研究领域，国外已在关键技术环节提出了基于用户日志、文本分析、工作流、变化本体等一系列经典方法和理论；国内期刊论文尚缺乏一定深度，深入分析多见于博硕士论文。本文将从宏观演化管理流程和微观国外先进技术两方面进行介绍，为本体演化管理的进一步研究打下一定基础。

2.本体演化的动因

2.1领域概念发生变化

由于事物总是处于不断变化之中，各个学科领域也不可能静止不变，经常出现的情况包括：某一新概念成为领域的一部分；某个现有概念成为过时概念而被摒弃；或者概念本身的定义发生重大改变。由于本体是对领域内共享概念正式、明确的说明，领域内的变化应当正确反映到本体之中。

2.2用户需求发生变化

在本体自身发展过程中，用户需求也在不断进行更新。领域专家和用户可能要求增加、删除或修改某些领域知识。这类需求变化往往发生在本体主体建设之后，数量和紧迫度不足以支撑开发一个全新的本体，这时就需要直接在现有本体的基础上进行相应修改，以满足用户的新需求。

2.3本体描述规范的变化

本体的描述规范也会随着时间的变化而发生改变，较为常见的情况包括：使用其他本体语言代替现有本体语言，或者新版本的本体语言取代了旧有的版本。这些变化有可能会导致相应的技术需求更新。在变更描述规范的同时，本体自身的结构和内容也可能受到影响，需要从整体的角度思考本体演化。

2.4开发新本体的成本过高

本体演化之所以存在，另一个重要因素是开发新小体成本过高。开发一个全新的本体往往需要领域专家的深入介入，广泛进行概念的提取和梳理，最终达到领域内共识。新本体的开发周期长，成本高，需要付出大量的人力、物力和时间，因此，在现有改变不足以当前本体的情况下，以原本体为基础，加以改造和重用是本体更新的一条合适道路。

3.本体演化管理的流程

本体演化管理往往发生在本体建设生命周期的末端，通常是在本体的主体部分完成之后，其自身也包含一定的流程。Ljiljana Stojanovic认为本体演化管理涉及6个阶段：①变化捕捉。变化捕捉是支持本体持续改进的动力。②变化表示。用来表达一个或多个本体正式的、明确的变更请求。③语义变化。以系统化的方法保证整个本体的一致。对变化进行语义控制，预防出现因变化而导致的语义不一致。④变化传播。将源本体的变化传播到所有依赖该本体的应用之中，例如分布式的本体实例、依赖于该本体的其他本体和相关应用等。⑤变化实施。告知本体工程师变化请求发生后所有可能的影响，便于交互的实施变化请求和派生的各类请求，并追踪这些变化。⑥变化验证。允许验证已实施的变化，可根据用户需求取消变化。帮助本体工程师确认本体建设是否正确，是否符合需求。

Pieter De Leenheer和Tom Mens则提出了另一种本体演化流程。该流程建立在Keith Bennett等人设想的基础之上，分为4个阶段：①提出变化请求。包括变化的表示，确定多次变化的优先次序，发现变化有关的操作等。②做出变化方案。确定为什么需要进行本体演化以及在哪些地方进行改变。核心工作是进行变化影响性分析，确定由于本体变化而导致的所有潜在后果。需向本体工程师提交预算费用分析，综合决定是否实施变化。③实施变化方案。包括传播变化，并在实施变化和一致性检验前对本体的结构进行相应重组。④验证和生效。核实本体变化后是否仍然符合一致性要求，是否以正确的方式进行建设，确保当前本体满足既定的需求。

综合以上两种本体演化流程，笔者认为本体演化的过程如图1表示：

4.本体演化管理的关键技术

4.1本体演化需求的收集

本体变化的需求分析居于本体演化管理的初始阶段，是进行本体演化的依据和评判演化结果的标准。本体演化需求的收集分为两种：自顶向下、自底向上。

自顶向下的需求通常由领域专家或用户根据使用目的直接提出，是显性的需求。领域专家和用户可以直接向系统管理员提出修改建议；由本体系统管理人员定期或不定期向指定用户收集反馈意见；或由系统管理人员根据系统的实际运行情况，做出必要判断。例如某一本休的用户要求本体新增“专利”概念，并将这一概念“科研人员”、“科研产品”概念建立关系等。

自底向上的需求则是通过一定手段挖掘出领域专家或用户隐性的需求或潜在不足。在本体的使用过程中，用户不断进行浏览、检索等操作，这些操作间接反映着用户的使用目的和真实意图。通过对用户行为的抓取、识别、分类，利用机器学习的方法，可以区分出频繁使用或很少使用的概念、属性、实例，或可增删；挖掘出概念、属性、实例之间存在潜在关系，或可调整。自底向上的需求收集多自然语言处理、数据挖掘、机器自动化等领域密切关联，利用日志挖掘、加权词频算法、挖掘频繁模式的Apriori算法、贝叶斯分类等经典方法或改进方法，将能够在一定程度上为本体演化需求的发现提供依据。

4.2本体变化的表示

本体变化表示是将本体演化需求通过形式化的方法表现出来。随着研究的深入，国外已提出若干正式、精确的本体变化表示方法，目前大多数的研究都是围绕如何将这些方法更加完善。

Ljiljana Stojanovic认为可以使用一种“元本体”来表达本体演化中的变化。这一元本体建立在KAON本体模型基础之上，将记录曾经发生哪些变化，变化产生的原因、时间、操作者，以及具体的变化过程。根据复杂程度将本体变化分为：元素层、复合层和混合

层。元素层变化指的是只发生在一个实体上的修改，而当一组元素层的变化共同发生时则构成复合层的变化。本体变化表示还应记录其他决策方面的信息，如成本、相关性、优先度等。此外，变化变化之间的关系也需要通过一定属性来表达，如表示变化发生的先后顺序、变化的类型等。

Raul Palma等人则提出了用“通用本体”来表示本体的变化，它独立于任何现有的本体模型，可支持任何本体语言。作者将本体变化分类的颗粒度划分得更加精细，包括原子级、实体级和复合级三个等级。作者认为其所提出的“原子级”操作是真正最小的、不可再分的操作级别。该级别内不包含“修改”操作，因为“修改”操作实际上可以进一步细化为删除和新增。而第二层实体级的变化则允许将本体变化本体元素相关联。复合级的变化则表示一组原子级变化，作用于逻辑实体，例如移动类树，合并同级。

除利用“元本体”、“通用本体”来表示变化外，Michel Klein提出了一个建立在OWL本体模型之上用来表示本体变化的本体，Yaozhong Liang等人利用Log Ontology也可以很好地表示本体变化。

早期的本体演化方法多偏向于单用户或若干本体工程师针对存储于单一节点的本体进行修改。随着本体开发规模和应用规模的扩大，分布式的网络本体逐步出现。本体被存储于多个节点，本体工程师队伍涵盖多种角色。在这种共同协作开发和维护本体的情况下，需要一个统一的流程来协调各项工作的开展。

协作式本体编辑工作流是专门用于设计网络化本体以及协调本体设计者、本体元素、任务关系的流程。需要满足以下需求：①能够识别不同本体编辑者角色；②根据不同用户角色分配权限，允许本体编辑者商讨、修改、确认和撤销操作；③能够自动转换作元素的状态，协调并发操作；④能够让操作人员获知由于操作而带来的潜在影响。

在Raul Palma等人提出的协作式本体编辑工作流中，按照操作人员的知识储备和技能水平，将用户角色分为两类：①领域专家负责修改本体；②管理员负责审核修改操作。

本体的状态可从“元素层”和“本体层”两个角度出发，每个层次分别分配了4种状态，不同条件导致不同状态，不同状态下可以进行相应权限的操作。元素层的“草稿”状态可以被分配给任一待编辑元素；一旦领域专家确认了某个“草稿”的变化，则进入“待审核”阶段，直到管理员接受或拒绝；当管理员接受了某一处于“待审核”的元素，即“审核通过”；如果领域专家认为某一元素有必要被删除时，该元素将被赋予“待移除”状态，管理员可真正删除它。在本体层，只要本体发生了任何变化，系统自动将该本体设定为“草稿”状态；当本体中的某一元素都处于“待审核”状态时，则本体转变为“待审核”；当本体的所有变化都处于“审核通过”时，该本体转变为“审核通过”；只有处于“审核通过”时，才能由管理员标记为“”。除“”状态外，本体的其他状态均由系统自动分配。

除了以上方法外，具体的本体开发组织根据不同的需求也设计‘了其他流程方案。例如基于Protege系统扩展而出的Collaborative Protege；用于分散环境下知识共享的本体工程流程DILIGENT等。

4.4本体变化的传播

关于变化的传播也曾是数据库系统、分布式系统等领域关注的问题之一。对于本体而言，专门研究本体变化传播的并不多见。然而随着本体重用情况的增多和应用的推广，源本体的每一次变化，也需要传播到其他相关的本体和应用中去，在跨越多节点的分布式存储的本体系统中尤为关键。

按照本体间不同的重用方式，Ljiljana Stojanovic将本体变化的传播划分为两个层面：①多个相关本体在同一节点(服务器)上的变化传播，即从属式的本体演化；②多个复用本体在多个节点(服务器)上的变化传播，即分布式的本体演化。

从属式的本体演化对应的是在单一节点(服务器)中重用整个本体模型，而非本体的子集。重用后，本体内的信息只能被增加，而很难进行缩减。针对这类本体重用关系里的演化传播，可在各个相关本体间使用相互推送的同步方式，也就是当某一本体发生变化时，即将这一变化传播到其他本体中。由于各个相关本体需要时刻保持一致，故这种变化传播应在变化发生时立即传播。

更常见的情况则是对本体进行有针对性的复用，各个复用本体存储在多个服务器中。这种情况的本体演化传播根据传播方向再细分为：①由源本体向复用本体的变化传播，采用源本体推送的传播方式；②由复用本体向源本体的变化传播，将复用本体的变化发送给某一专门节点后，再由该节点负责传播。通过复合策略，保证多个节点上的若干复用本体间的一致。

如果源本体和相关本体或应用之间的变化传播过于频繁，系统的交互性和易用性将会受到影响。变化传播的频率应根据系统的实际情况、用户需求加以权衡。如本体编辑团队成员在地理上是分散的，编辑者在不同时区工作，无需稳定、快速的网络连接的情况下，则可以将系统设定为定时传播本体变化。

4.5本体版本机制

一个理想的本体开发者既要保证完成本体不同版本的更新，也要掌握各版本之间的差别，确保版本之间能够平稳过渡。本体版本可以看作为本体演化的一种特殊形式，对本体版本机制的研究可以为本体进化管理提供借鉴。

Pieter De Leenheer和Tom Mens认为本体版本应允许用户就给定的系统对变化进行跟踪，并可选择撤销变化，恢复到之前的版本。他们定义了两类版本变化：①基于状态的版本变换，即无论系统发生了何种变化，只要符合既定模式，系统将进入一新的特定的状态，每一个新的状态都将被赋予唯一的版本号；②基于变化的版本变换，即将变化本身作为首要衡量因素，存储变化有关的所有精确的信息，无论发生什么样的变化，都将记录在案。

Damyan Ognyanov和Atanas Kilyakov提出了一个用于RDF(S)知识库的模型。该模型可追踪本体的变化、本体版本以及各类相关信息。这一方法建立在RDF陈述的基础上，针对的是最小的、可直接管理的知识，这些知识自身不可被改变，仅可新增或移除。因此，该模型实际上只包含两种操作：陈述新增和移除。知识库的每一次更新实际上都是一系列陈述被明确断言的过程。其中有一些更新可以被认作是版本的变换。

此外，还有基于网络的知识表示语言SHOE，可用于支持本体的多版本；基于网络的本体变化管理系统OntoView，其透明界面可用于比较本体版本之间的差异。

4.6其他关键技术

除以上本体演化管理最为密切和直接相关的技术外，还包括其他贯穿本体建设方面的关键技术，如：本体冲突的解决，判别本体间的相互影响和依赖关系，解决语义冲突、语法冲突的难题；本体一致性检验，贯穿本体演化实施前后，保证本体的结构一敛性、逻辑一致性和用户自定义一致性的标准；本体比较技术，利用算法自动判别不同本体版本之间的语义和语法差异，也可为本体进化实施后的需求检验提供依据等。

5.结语

随着本体开发的深入和应用推广，本体演化管理是解决本体更新问题的途径和方法。然而本体演化从来不是单纯的技术问题，它是领域专家、用户和本体开发团队共同协作的过程。也由于本体系统自身的复杂性，对本体所做的修改需要从全盘考虑，在实施之前进行全面的影响性分析，充分权衡利弊，最终做出合适的实施方案，或可取消本体演化计划。