欢迎光临112期刊网！
- 期刊查询
日期：2023-01-24 阅读量：0次 所属栏目：软件技术
基于软件工程开发的领域本体构建研究
目前流行的领域本体构建方法有：英国edinbunrgh大学ai应用研究所的enterprise项目组开发的“骨架法”，该方法使用middle—out开发方式提供与商业和企业有关的术语及其定义的集合；加拿大toronto大学企业集成实验室开发了tove项目本体，通过该本体来建立指定知识的逻辑模型；bernaras等人开发的欧洲eaprit kactus项目中由应用来控制本体的开发，每个应用都有相应的知识本体，这些本体即能复用其他的本体，又能集成到项目以后的本体应用中；西班牙madrid理工大学ai实验室开发的，methontology法构建知识级本体；美国southern california大学信息科学研究所开发的sensus法，主要通过自然语言处理，提取和合并不同电子知识源的信息而得到该领域本体的内容。
本文借鉴了上述传统领域本体构建方法中的基本思想，并在构建框架中融合了软件工程开发方法中的结构化开发方法和原型化开发方法。
1 传统领域本体构建方法分析
1.1 共同点分析
纵观上述“骨架法”、“评估法”、“bernaras”、“methonotology”及“sensus”方法构建领域本体过程中的思路，它们之间存在以下共同点：
（1）许多本体构建方法都以一个具体任务为起点，这样易于知识的获取和本体功能的描述。
（2）本体构建大致可划分为阶段法（如骨架法）和演化法（如methontology法）。
（3）在构建过程中可分为“非形式化描述本体”和用正规描述语言“形式化描述本体”前后两个阶段。
（4）希望通过累积的方法构建本体，即先构建一个基础本体，然后做进一步开发。
（5）对于由同一个基础本体构建出的领域本体，由于高层概念的共享，本体系统之间具有互操作能力。
1.2 缺陷分析
ieee 1074—1995标准是软件开发生命周期过程的标准，其中包括模型阶段、项目管理阶段、软件开发阶段与集成阶段4个开发阶段，其中软件开发阶段的具体步骤如下：
（1）开发前期：主要进行可行性研究等活动；
（2）开发阶段：主要进行需求分析、设计和实现等活动；
（3）开发后期：主要进行软件的安装、试运行、操作和维护等活动。
与ieee 1074—1995标准对比而言，目前领域本体构建还远远没有成为一种工程性活动，还具有如下缺陷：
（1）没有一种方法是完全成熟的，不论是bemaras法、sensus法、骨架法、评估法，还是methontology法。
（2）缺乏工程化的本体本文由论文联盟http://收集整理通用构造方法和标准。由于每个研发团队处于不同的学科领域，虽然总结出各个领域不同的开发方法和体系结构，但是各个本体开发方法都不尽统一，缺乏通用的标准。
本文在领域本体构建过程中扬弃上述5种领域本体构建方法中的优缺点，而且借鉴了软件工程开发的基本标准。
2 基于软件工程开发的领域本体构建
2.1 构建框架
本文在领域本体框架构建的形式上采用结构化方法中分段式模式，将整个领域本体构建过程分为领域本体规划阶段、领域本体分析阶段、领域本体设计阶段、领域本体实施阶段及领域本体运行阶段，每个阶段都有自己独立的目标及主要任务，前一阶段任务的完成是后一阶段任务开始的前提和基础，后一阶段任务通常是对前一阶段提出的解决问题方法的进一步具体化，即该过程是按照软件工程开发的生命周期流程来逐步解决问题的。在领域本体分析阶段，根据领域本体规划阶段提出的具体要求和目标，采用原型化方法不断地对分析结果进行修改和完善。其构建框架如图1所示。
2.2 构建框架分析
2.2.1 领域本体规划阶段
（1）确定领域本体的用途和范围
确定领域本体范围的方式之一是设计并填写本体的性能调查表，以下从需求的角度对本体支持的性能调查表进行简单的分类：
①需求细化。需求细化过程必须满足何种标准？会产生多余的需求吗？需求是客户的清晰表述吗？
②需求追溯能力。需求还能分解吗？需求的来源是什么？谁记录需求？需求在特定的设计团队中适用吗？
③需求满足。需求能够满足吗？两个或多个需求间相互冲突吗？更高抽象级别的需求怎样满足评估？
④文档生成。需求属于哪类文档？哪些是与需求文档中的段落相符的需求？不属于客户报告的需求有哪些（商业机密）？
⑤升级。这是需求的最新版本吗？需求的旧版本有哪些？为什么还要改变需求？变化对需求文档的一致性和完整性有影响吗？
（2）考虑复用现有领域本体
一些本体已经初具规模，可以在网上找到相应的本体库及相关资料，在具体开发之前，有必要在这些本体中寻找系统可以重用的本体，这样可以省去元本体和顶层本体的建立，而把本体建立的目标重点放在领域本体的建立上。
2.2.2领域本体分析阶段
（1）定义类和类层次
类描述了领域的概念而非单词。在类和类层次的定义过程中，需要依据以下8个原则：
①确保类层次的正确性
恰当使用is—a和kind-of等类间关系，is-a关系指类a是类b的子类，前提是b的每个实例也是a的实例。类的子类表示概念是kind-of父类表示的概念；层次关系间具有传递性，并应区分直接子类和间接子类的关系；避免类层次的循环，确保类层次随着领域发展而进化。
②分析类层次中的兄弟关系
元素。形式化定义为f：c1×c2×……×cn-1→cn。
④公理（axioms）
代表永真断言，如概念乙属于概念甲的范围。
⑤实例（instances）
代表元素，从语义上讲实例表示的就是对象。
另外，从语义上讲基本的关系有4种：整体与部分关系（part—whole）、分类关系（is—a）、实例与概念关系（instance—concept）和属性关系（attribute-of）。但在实际建模过程中，概念之间的关系不限于上述4类关系，可以根据领域的具体情况定义相应的关系。
（2）领域本体的形式化描述语言
领域本体可用自然语言、框架、语义网络或逻辑语言等来描述。但对计算机来说，形式化描述语言做为一种可供计算机处理的概念模型，应具备以下条件：
①应该具有较强的表示能力，同时也应兼顾推理能力，以满足智能检索中进一步实现推理的需求。
②应该具有较强的内在逻辑系统支持。
③应该具备一致的描述概念和表示数据的能力。
④应该尽可能与w3c已有标准兼容，从而保证其持续发展需求。
⑤应该具备xml语法特性，最好是基于语义web。
⑥所表示的领域知识是形式化的，即机器可读和可理解的。
目前已经开发了6种本体语言，有些是直接基于xml语言的语法，如简单html本体扩展（simple html ontologyextension，shoe）、本体标记语言（ontology markup language，oml）和基于xml的本体交换语言（xml—based ontology exchange language，xol）；另外有2种本体语言是建立于rdf（s）之上，以便改善rdf（s）的特征：本体交互语言（ontology interchange language，oil）和darpa主体标记语言+本体推理层（darap agent markup language with ontology inference layer，daml+oil）。最近，以oil和daml+oil语言为起点，已开发出语义网所用的web本体语言（web ontology language，owl）。各个本体语言之间的层次化关系如图2所示：
（3）领域本体的文档化构建和存储
构建领域本体文档，可对后续领域本体修改和进化奠定基础。1个owl文档由以下4个部分组成：
①本体首部：包含了文档的元数据，如导入数据、版本数据及与其他owl文档的兼容数据。
②类的定义：通过（owl：class）标签定义类，使用（rdfs：subclassof）来继承1个或多个类，由此建立类的层次关系。类的语义用类的描述来表达。owl区分了6种类的描述：1个类标识，1个详细的列举，1个属性的限定，2个或多个类描述的交，2个或多个类描述的并，1个类描述的补。
③属性的定义：owl存在2种类型的属性，即对象属性（object property）和数据类型属性（datatype property）。对象属性是用来表述2个类实例之间的关系，而数据类型属性则描述类的实例、rdf literals，以及xml schema数据类型之间的关系。属性之间还能够定义子属性关系以及为属性声明额外的特征（传递属性和逆属性）。如能够定义father是parent的子属性，定义anceator为传递属性，定义child为parent的逆属性。
④个体（实例）的定义：一个个体是一个特定类的实例，并与其属性相联系。
2.2.4 领域本体实施和运行阶段
（1）领域本体评价
这里采用gruber在1995年提出的5条准则：
①清晰性。所定义的术语应尽量客观，避免受社会背景和客观环境的影响；给出的定义应尽可能完整。
②一致性。即本体中定义的公理应该是逻辑一致的，概念和概念间关系在逻辑上也应该是一致的。
③可扩展性。本体应该能够保证添加新的通用或专用术语，而不需要修改原有的定义，即能支持在已有的概念基础上定义新术语。
④编码偏好程度最小。概念应该在知识层次上说明，而不应该依赖于特定的符号层次的编码，因为不同的系统可能采用不同的表示风格。
⑤最小本体承诺。一般地，本体承诺只要满足特定的知识共享需求即可，这可以通过定义约束最弱的公理及只定义交流所需的基本词汇来保证。
（2）领域本体试运行
可针对某一应用目标，可利用初始生成的领域本体在特定的应用范围内进行试运行，来验证初始领域本体是否能够满足领域范围应用的需求，特别是要检验其一致性、完整性和可扩展性。经过试运行，若符合要求则转向（4）；若不符合要求则要重新经过本体分析阶段，然后转向（3）与（4）。
（3）领域本体文档的修改
针对试运行的结果，可在owl文档的基础上做一些标注性的修改。
（4）领域本体应用
对于修改后的领域本体，可正式投入实际运行应用过程。
3 总结和展望
本文在总结与分析传统领域本体构建方法中的基本思想及缺陷的基础上，提出了基于软件工程开发角度来构建领域本体的思路。其中利用结构化开发方法构建领域本体整体开发流程，充分借鉴了结构化开发方法中的用户至上原则，结构化、模块化、自顶向下地对系统进行分析和设计等优点，但由于结构化开发方法中存在开发周期过长、不易满足用户需求并难易修改等缺陷，因此在领域本体构建的重要环节，即在领域本体分析阶段采用原型化开发方法，使用户与开发者通过不断地沟通尽快确定领域本体初始模型，并通过结构化开发方法所划分的层次结构过程不断地优化和修改初始模型，使其能够尽快满足用户的需求。
