本体不一致的诊断方法

本体不一致的诊断方法

（上海海事大学信息工程学院，上海 200135）

摘要：近年来，语义Web技术不断发展，本体作为一种清晰表达语义和知识共享的方式，成为了语义Web的核心，其相关研究也得到了很大的进步。然而，在实际应用中，很难构建没有错误的本体，引起本体不一致的原因有很多。本文研究的是不一致本体的诊断方法，提出了模型诊断方法和局部诊断方法两部分，并给出了相应的方法描述。

关键字：本体；本体不一致；诊断

Abstract:In recent years, the Semantic Web technology development, the body as a clear expression of semantics and knowledge-sharing manner, became the core of the Semantic Web,

the research has also been a lot of progress. However, in practice, it is difficult to build there is no wrong body, causing the body inconsistent for many reasons. This study is inconsistent with the body of diagnostic methods, diagnostic methods and models proposed local diagnostic methods in two parts, and the corresponding method descriptions

Keywords: Ontology;Inconsistency；Diagnosis

1.引言

不一致本体的诊断修复方法作为解决不一致本体问题的主要方法，受到了研究者的广泛关注。因为目前的推理机只能检查出不一致本体中不可满足的概念，而无法检查出产生不一致的原因，更无法分析或修复本体中的错误。因此，研究不一致本体的诊断修复方法是非常重要和必要的，诊断修复法就是研究当本体出现不一致时，如何利用有效的方法来帮助用户分析不一致产生的原因，诊断出导致不一致出现的公理集合，进一步给出有效的解决方案修复不一致。

2.模型诊断方法

2.1基于模型诊断的本体不一致问题描述

Reiter给出了诊断(diagnosis)问题的基本定义:当观察到一个异常行为时，从本体中找出可能引起该行为的部位。“诊断”这个概念来自医疗领域，指医生根据病人的主诉信息，诊断出发病原因的过程，例如，病人的“异常行为”表现为头部发烧，经医生诊断后确定“发病部位”是扁桃体炎症。Reiter采用一阶命题逻辑来描述问题域。

Hamscher等人在Reiter的基础上，提出了模型诊断(Model-based Diagnosis)方法，即已知一个本体，给定若干新成分(components )，将这些新成分添加到该本体中，一旦新成分的添加动作引起该本体发生不一致现象，则使用诊断方法,陈复本体的一致性。它采用与Reiter相同的形式语言来描述待诊断问题的领域模型。

基于模型诊断的本体不一致问题描述如下:

（a）对于待诊断的本体:用一个命题公式集合来表示;

（b）对于本体的每个成分X:用命题变量。okX表示该成分是否处于正常工作

状态。如果没有证据证明本体不正常工作，那么假设所有变量。okX全为真。

2.2系统描述

定义1.1(基于诊断的本体)本体表示为一个序偶(SD,ASS)，其中:

（a）SD:本体描述(System Description)，是一个有限命题公式集合;

（b）ASS:疑似元素(assumables )集合，是一个由命题变量。akX组成的有限命题变量集。

用观察OBS（observation）表示待添加的新成分，它是一条命题公式。

这样，就可以用(SD,ASS,OBS)表示诊断问题，称OBS是本体(SD,ASS)的一个观察。当观察到异常行为，即(SD,ASS)∪{OBS}出现不一致时，就需要诊断了。定义1.2(诊断)定义在(SD,ASS,OBS)上的诊断是一个最小集△∈ASS，使得SD∪{OBS}∪(ASS\△)∪{?okX|okX∈△}是一致的。

在模型诊断中，诊断是为了恢复本体的一致性而必须删去的疑似元素集合ASS的最小子集。

一个本体的“诊断”并非总是存在的。

推论1.1(SD,ASS,OBS)的诊断存在当且仅当SD∪{OBS}是一致的。

根据推论1.1和定义1.2可得如下推论1.2：

推论1.2△∈ASS是“(SD,ASS,OBS)的诊断”，当且仅当SD∪{OBS}∪(ASS\△)是一致的。

2.3诊断计算

在Reiter提出的寻找“诊断”的方法中，用到了冲突集(Conflict Set)和目标集(Hitting Set)这两个概念。

定义1.3（冲突集）（SD,ASS,OBS）的冲突集是一个集合Conf={okX

1,okX

2

,...,okX

n

}

∈ASS,使得SD∪{OBS}∪Conf不一致。

根据推论1.2和定义1.3可得：△∈ASS是“(SD,ASS,OBS)的诊断”，当且仅当△是最小集，并且(ASS\△)不是“(SD,ASS,OBS)的冲突集”。

给定一个由一组集合作为元素构成的集合，C的目标集与每个集合元素的交集不为空，可得定义1.4。

定义1.4(目标集)设C是一个由一组集合作为元素构成的集合，C的目标

集是一个集合H∈∪S，S∈C，使得对于全部S∈C，H∧S非空。

C的目标集最小，当且仅当其任何真子集都不是C的目标集。

下面的定理1.1给出了一种寻找“诊断”的方法。

定理1.1△∈ASS是“(SD,ASS,OBS)的诊断”，当且仅当△是由“(SD,ASS,OBS) 的所有最小冲突集”构成的集合的最小目标集。

根据定理1.1可知找目标集首先应该找冲突集。

3.局部诊断方法

3.1核心收缩

定义1.5(核心操作⊥)对于给定公式集B和公式a，X∈B⊥a，当且仅当: （a）X∈B；

（b）a∈Cn（X）；

（c）对于所有Y，若Y∈X，则a?Cn（Y）。

B⊥a的元素称为a-核心，其中，Cn(X)表示所有能够由X蕴含的公式。

X是蕴含a的、B的极小子集，但不唯一。

定义1.6（B的切割函数σ对于任意一条公式a:

（a）σ（B⊥a) ∈∪(B⊥a);

（b）如果?≠X∈B⊥a，那么X∧σ(B⊥a)≠?。

由这个定义可推出结论，即去掉σ之后得到的B'不再蕴含a。

3.2核心半修复诊断

定义1.7（ B的核心半修复？σ)对于所有公式a， B? σa =（B∪{a})\σ((B ∪{a})⊥)。

给定本体(SD,ASS,OBS)} SD∪ASS表示待半修复的本体，OBS表示待添加的本体，那么诊断问题与核心半修复操作具有如下对应关系:

（a)冲突集:指SD∪ASS∪{OBS}的不一致核心操作中的疑似元素，表示为{X∧ASS|X∈((SD∪ASS)+OBS) ⊥}。

（b)切割函数:切割函数几乎与目标集对应，最小目标集是只返回疑似元素的最小切割函数值。

半修复操作的两个步骤是:

第1步，将待添加的本体连同疑似元素一起添入原本体中，得到一个新的本体;

第2步，当新本体满足一致性时，则无须删除任何本体成分，否则找出不一致核，并且使用切割函数挑选出需要放弃的本体成分。

所谓最小诊断，就是最小切割，即切割函数的一种特殊变种。

定义1.8(最小切割函数)给定集合A，A-最小切割函数σ

A

是从“公式集

的集合”到“公式的集合”的函数，即对于公式集中的任何集合S，满足:

（a)σ

A

(S) ∈∪S；

（b)如果?≠X∈S，那么X∧σ

A

(S)≠?；

（c)如果对于所有X∈S}，X∧A≠?,那么σ

A (S) ∈A，并且σ

A

(S)是满足

(a),（b),（c)的最小集。

在诊断问题((SD,ASS,OBS)中，因为SD中公式的状态与ASS中公式的状态有所不同， ASS表示一种疑似状态，与SD相比，ASS具有更大的修正价值，所以不希望放弃SD或OBS中的任何句子，而宁愿放弃ASS中的谓词变量okX。因此设A是疑似元素集，则切割函数优先选择okX，即对于(SD,ASS,OBS)，一旦诊断存在，那么ASS-最小切割函数只选择ASS中的元素，据此可得推论1.3。

推论1.3在(SD,ASS,OBS)中，σ

ASS

是一个ASS-最小切割函数。如果诊断存在，

那么σ

ASS

((SD∪ASS∪OBS) ⊥⊥ASS。

引理1.1出现于((SD∪ASS∪OBS)的不一致核中的疑似元素构成

"(SD,ASS,OBS)的冲突集”，并且所有最小冲突集都可以用下列方式得到: （a)对于所有XE(SD∪ASS∪OBS)⊥⊥，X∧ASS都是冲突集，并且，

（b)对于每个最小冲突集Y，都存在着X∈(SD∪ASS∪OBS)⊥⊥,使得X∧ASS =Y。

注意并非每个不一致核都能确定一个最小冲突集。

给定切割函数。，集合B关于公式。的半修复是:B ?σa.=(B+a)\σ((B+a,⊥），而“诊断”是ASS的元素，它将根据观察通过核心半修复操作删除。

推论1.4假设S=(SD,ASS,OBS)是一个本体，σ

ASS

是一个ASS-最小切割函数，

那么，(SD∪ASS)\((SD∪ASS)?σ

ASS OBS)= σ

ASS

((SD∪ASS∪OBS)}1)是诊断。

3.3局部诊断算法

根据公式间的关系，用DAG图来表示SD，并给出了一个基于DAG的“诊断”寻找算法:首先从SD∪ASS∪{OBS}中找出与OBS关联的成分(用Comp表示)，然后只对这一部分调用诊断算法。

分割算法Compartment包括两个步骤:先调用邻接点计算算法Retrieve从ASS中找出关联疑似元素(用Relevant表示)，然后根据这部分疑似元素从SD∪

ASS∪{OBS}中找出与OBS关联的成分Comp。Compartment算法描述如下：输入:SD，ASS，OBS

输出:关联成分Comp

Compartment()

{Retrieve()

Comp=OBS

For all p∈Relevant，

Comp:=Comp∪{a∈SD∪ASS|p∈Var(a)}

}

Retrieve算法使用Adjacent函数计算邻接于某给定结点的所有结点来收集关联于某给定结点的所有结点，即给定关联关系R，adjacent(x)={y∈Var(SD)∪ASS|R(x,y)}，其中Var（X）是出现于集合X的所有公式的命题变量的集合。对于命题变量集合Y，adjacent(Y)=∪{adjacent(y)|y∈Y}。

4.总结

本体作为共享概念模型的明确的规范说明，其数据的组织方式还蕴含着数据间的逻辑关系，具有丰富的语义关系。将本体引入海量、异构、分布的Web信息资源整合中，为计算机系统具备语义理解的能力提供了基础条件。但由于这些Web知识具有分布性和异构性，经常会出现这些对知识的理解不一致、语义不明确等问题，即本体是不一致的，从而导致知识无法共享，无法提供有效的知识协同服务。因此，如何处理本体不一致问题成为基于本体的知识管理与服务工作中的关键问题。当本体知识库出现不一致时，它可以平凡地演绎出任何结论，针对这样的本体知识库的推理查询是没有实际意义的，因此研究如何处理本体的不一致问题是非常必要的。

本文提出了基于模型诊断和局部诊断的证据验证诊断方法。我们利用模型诊断方法中的(SD,ASS,OBS)表示诊断问题，称OBS是本体((SD,ASS)的一个观察。模型诊断方法提出了基于模型诊断的本体不一致问题描述，并通过诊断进行描述和计算。局部诊断方法提出了核心收缩、核心半修复诊断，最后通过局部诊断算法来对本体不一致问题进行了分析。

参考文献：

[1] 崔运鹏.基于本体论的农业知识管理关键技术研究[博士论文]，中国农业科学院，2007.

[2] 马跃.语义万维网中的不协调知识处理[博士论文].北京大学，2008.

[3] Paul Buitelaar , Philipp Cimiano _ and Bernardo Magnini _ DFKI, Language Technology Lab_ AIFB, University of Karlsruhe_ ITC-irst, Centro per la Ricerca Scientifica e TecnologicaOntology Learning from Text:An Overview.

[4] Eugenijus Kurilovas, Anita Juskeviciene ,Computers in Human Behavior, In Press, Corrected Proof, Available online 6 November 2014 .Eugenijus Kurilovas, Anita Juskeviciene

本体构建方法

本文通过借鉴其他领域本体的构建方法，尤其是苏格兰爱丁堡大学的企业本体的建立过程，首先尝试着一步步建立起自己的本体模型，并且经过反复迭代的过程，不断的进行排错和修改，直至本体模型初具雏形。 然后在遵循本体建立准则的基础上，通过抽象总结出一套领域本体的知识工程构建方法。 领域本体构建过程 3.1确定本体的领域与范围 本体是否包含了足够的信息来回答这些问题？问题的答案是否需要特定的细化程度或需要一个特定领域的表示。 3.2列举领域中重要的术语、概念。 在领域本体创建的初始阶段，尽可能列举出系统想要陈述的或要向用户解释的所有概念。这上面的概念和术语是需要声明或解释的。而不必在意所要表达的概念之间的意思是否重叠，也不要考虑这些概念到底用何种方式（类、属性还是实例）来表达。 3.3建立本体框架。 上一步骤中已经产生了领域中大量的概念，但却是一张毫无组织结构的词汇表，这时需要按照一定的逻辑规则把它们进行分组，形成不同的工作领域，在同一工作领域的概念，其相关性应该比较强。另外，对其中的每一个概念的重要性要进行评估，选出关键性术语，摒弃那些不必要或者超出领域范围的概念，尽可能准确而精简的表达出领域的知识。从而形成一个领域知识的框架体系，得到领域本体的框架结构。 上述Step 2和Step 3并非是绝对的顺序，这两个步骤往往也可以颠倒过来进行，有时会先列举出领域中的术语和概念，然后从概念中抽象出本体框架；也可以先产生本体框架，再按照框架列举出领域的术语。至于如何具体进行，应该根据开发人员对领域的认识程度，如果领域内已经存在非常清晰的框架或

者认识已经很深刻，则可以直接产生框架。当然，这两个步骤也可以交叉进行。 3. 4设计元本体，重用已有的本体，定义领域中概念及概念之间的关系。 为了描述各个概念，利用术语对概念进行标识，并对其含义进行定义，在这一步定义时先采用自然语言进行定义。为了定义一个概念，设计了元本体。一个概念可以采用元本体中定义的元概念进行定义，或采用在本体中已经被定义的概念进行定义，或重用已有的本体。 元本体是指本体的本体，其术语用于定义本体中的概念，如实体、关系、角色等。它可以说是更高层次的本体，是领域内概念的抽象。在设计元本体时，尽量做到领域无关性，并且包含的元概念数目尽可能的少。 UNSPS C、DMOZ、Ontolingua 的本体文库和DAML 的本体文库等，可以导入倒本体开发系统中。本体被表达的形式通常并不重要，因为许多知识表示系统能够导入和导出本体。即使某个知识表示系统不能直接使用某种形式的本体，将本体从一种形式到另一种形式通常也不难实现。 除了概念，还要定义概念之间的关系。这些关系不仅仅涉及同工作领域的概念，不同工作领域的概念也可以相关，只是这些关系总是属于某一个工作领域。 定义类（class）及类的层次体系。创建的概念中，很大一部分属于类，而对类的层次的定义有以下3种方法： (1)自上向下法（top-down）： 先定义领域中综合的、概括性的概念，然后逐步细化、说明。 (2)自下向上法（bottom-up）： 先定义具体的、特殊的概念，最底层、最细小的类的定义开始，然后对这些概念泛化成综合性的概念。

设计流程及方法

UED设计流程及方法 “用户体验设计”无疑是这两年互联网行业最炙手可热的话题，而从我们成都UCD书友会火爆的现场来看，也的确如此。那么“用户体验设计”为什么会如此火爆呢?这需要从互联网的Web2.0革命说起。 这场革命，代表了互联网应用关注焦点的变迁，从以内容为王的门户型网站时代，转变为以用户为中心的互联网服务时代。以用户为中心的互联网服务，自然就需要以用户为中心的设计。但是要做到真正的以用户为中心的设计却并不简单。 这是什么意思呢?我想用彩程的实际经历对这个问题做出解释。和很多其它软件企业一样，彩程也是从一些中小型的企业网站、电子商务网站开发业务启程的。当时我们开发一个电子商务类网站的流程是什么样的呢? 首先会由超级打杂老妖出马，跟客户沟通，套出用户的需求，然后由费西或是老妖自己，三下五除二的搞一个首页出来，拿去给用户确认，用户如果点头，那么ok，开始做首页的html切图，然后丢给程序员开始开发，同时，美工继续孤军深入，出各种特征内页，切html，交给程序员开发，如此循环往复。而一旦整个项目开始进行，客户就很少再参与其中了。 于是，这个项目持续运行，直到某一天，程序员说：“好了”，这样，老妖满怀希望的冲到客户那里，很想听到客户对网站认可，但实际的场景往往是： 客户抱怨说，这里我明明是想要个Flash广告，但是却只有一张图片;这个订单系统怎么不好用，为什么不参考淘宝来做呢?我还想要个会员系统，每个会员有自己的个人页面。 这个时候，可怜的老妖只能作出两种选择，要么照单全收，ok，哪里有问题我给你改哪里，要么就是耍死皮，但是后面一种情况一般不会出现，因为老妖不愿因为得罪客户而丢掉奶粉钱。所以，这个原本大家都认为很简单的网站项目就这样被delay下去了。 这样的情况出现的次数多了，让公司首脑小s同学很不满意，于是他开始召集大家思考，这是为什么呢?让我们来看看之前我们的流程:

OWL本体知识库的面向对象表示

Software Engineering and Applications 软件工程与应用, 2018, 7(3), 132-141 Published Online June 2018 in Hans. https://www.sodocs.net/doc/2412627729.html,/journal/sea https://https://www.sodocs.net/doc/2412627729.html,/10.12677/sea.2018.73015 Object-Oriented Representation for OWL Ontology Knowledge Base Shaohua Zhang, Yingzhong Zhang School of Mechanical Engineering, Dalian University of Technology, Dalian Liaoning Received: Apr. 26th, 2018; accepted: May 8th, 2018; published: May 15th, 2018 Abstract Ontology technologies can better represent the knowledge implied in various terms and concepts in a structured, computable and shared form. The ontology based knowledge representation me-thod has been widely used in many fields. In view of the lack of efficient OWL (Web Ontology Lan-guage, OWL) ontology knowledge processing and integration tools in the engineering information processing, based on the study of the knowledge representation framework, language syntax and document structure based on the OWL ontology, an object-oriented OWL ontology knowledge base representation model is proposed and designed. A method based on XML document parsing plat-form to parse the OWL documents in a RDF/XML format is implemented, which can convert the OWL ontology knowledge base into an object oriented ontology knowledge base. The presented work lays a foundation for the subsequent engineering semantic information reasoning and knowledge retrieval service. Keywords Ontology, OWL, Knowledge Representation, Knowledge Base, Object-Oriented OWL本体知识库的面向对象表示 张少华，张应中 大连理工大学，机械工程学院，辽宁大连 收稿日期：2018年4月26日；录用日期：2018年5月8日；发布日期：2018年5月15日 摘要 本体技术能更好地以一种结构化的、可计算和可共享的形式表示各种术语、概念所隐含的知识，基于本

基于Wiki的本体构建方法

第30卷第8期通化师范学院学报Vol.30№8 2009年8月JOURNAL OF T ONGHUA TEACHERS COLLEGE Aug.2009 基于W iki的本体构建方法 于江涛,毛慧珍 (通化师范学院计算机科学系,吉林通化134002) 摘　要:该文提出一种本体构造环境方案,在W iki pedia的基础上加入本体构造用户接口,降低用户构造本体的门槛,使用户在建立概念的同时创建本体.系统以OWL本体形式存储、管理和共享知识,还可以以系统已有概念为字典,对相关本体领域相关文本进行本体学习,自动建立本体. 关键词:本体构建;W iki;用户驱动;本体学习 中图分类号:TP311　文献标志码:A　文章编号:1008-7974(2009)08-0019-02 收稿日期:2009-06-01 作者简介:于江涛(1969-),男,硕士,通化师范学院计算机科学系副教授. 1　引言 本体(Ont ol ogy)是当前人工智能研究领域的热点,是解决知识工程中一些问题的有效方法.它的优势体现在可以用于不同领域内的人之间的交流和知识共享,可用于语义网进行语义判断,还可对知识进行管理.本体的构建是本体应用的前提,一直是个烦琐的过程.传统上为了保证本体的正确性,领域本体的构建都需要领域专家的参与.然而仅靠少数领域专家的参与难以实现领域本体构建的繁重任务[1],更不用说实现本体工程. 仅有少部分人来构建本体,主要存在两个问题:①本体的创建过程不在其用户的完全控制之内,一旦被发现有错误,发现者往往不能自已修改,而要求助于少部分人的本体建造者;②本体使用者不能抓住本体的重要性质,本体不能更好的满足用户的需要.因此,在允许少量误差前提下,我们需要更快捷的方法得到大范围的领域本体.这便需要降低本体产生和维护工具的使用门槛,使更多人的参与进来. 本文提出了基于W iki技术的本体构建方法,用户可以通过模仿自然语言中词汇的出现过程来完成本体的建立,就像任何人都能发明一个自然语言中的词汇,任何人都可以依靠W iki技术建立自己的本体.经过一次次的修改最终成为最完善和满足用户需要的本体.该方法以OWL本体来存储概念,在W iki pedia的基础上加入本体构件的用户接口,用户在建立概念的同时就建立了本体. 2　基于W iki的本体构造方法 设计界面类似于Platypus W iki(Platypus W iki 是一个Sem antic W iki W iki W eb工程[2]),但提供更丰富的OWL Full抽象语法,需要用自然语言的名称,以期不需要高的应用门槛.当使用W iki 建立一个新的概念(C lass)时,会提示记录父类(subC lass O f),当然也可以新建父类.如果其父类已经存在就取其父类的属性(Property)来指导该类属性的建立.继而对属性建立dom ain,range等等.同时对概念给出解释性自然语言描述,最终产生OWL交换语法描述和解析树.OWL本体可供修改和共享. 虽然任何人都可以对概念或者本体进行修改甚至删除,但W iki引入版本控制概念,所以任何版本的信息都会被保存下来.引入用户投票机制,让相关概念的使用者以自己的评价权重对已有本体进行评价,得到评价最高的本体作为相关概念的系统推荐本体.本体的评价高低又反过来决定其作者的评价权重. 当系统的本体规模足够大时,可以依托这些本体作为基本概念的字典,对欲建立的某新概念,指定相关领域网站,利用网络爬虫抽取与之链接网站中的文本,从相关文本中抽取对概念的描述语句,不断进行本体学习,自动建立相关概念的本体.该本体的准确性虽然略低,但可以作为用户建立相关本体时的参考,有指导作用,至少可以减少欲建立该本体的用户的工作量.当前在本体自动构建方面做的比较好的是Ont o W are Pr oject的text2ont o,它以WordNet 为字典,利用text m ining从大量文本资源中得到相关概念的描述信息,自动建立出该领域的本体[3,4]. ? 9 1 ?

Jena_中文教程_本体API(经典)

Jena 简介 一般来说，我们在Protege这样的编辑器里构建了本体，就会想在应用程序里使用它，这就需要一些开发接口。用程序操作本体是很必要的，因为在很多情况下，我们要自动生成本体，靠人手通过Protege创建所有本体是不现实的。Jena 是HP公司开发的这样一套API，似乎HP公司在本体这方面走得很靠前，其他大公司还在观望吗？ 可以这样说，Jena对应用程序就像Protege对我们，我们使用Protege操作本体，应用程序则是使用Jena来做同样的工作，当然这些应用程序还是得由我们来编写。其实Protege本身也是在Jena的基础上开发的，你看如果Protege 的console里报异常的话，多半会和Jena有关。最近出了一个Protege OWL API，相当于对Jena的包装，据说使用起来更方便，这个API就是Protege 的OWL Plugin所使用的，相信作者经过OWL Plugin的开发以后，说这些话是有一定依据的。 题目是说用Jena处理OWL，其实Jena当然不只能处理OWL，就像Protege 除了能处理OWL外还能处理RDF(S)一样。Jena最基本的使用是处理RDF(S)，但毕竟OWL已经成为W3C的推荐标准，所以对它的支持也是大势所趋。 好了，现在来点实际的，怎样用Jena读我们用Protege创建的OWL本体呢，假设你有一个OWL本体文件（.owl），里面定义了动物类 （https://www.sodocs.net/doc/2412627729.html,/ont/Animal，注意这并不是一个实际存在的URL，不要试图去访问它），并且它有一些实例，现在看如下代码： OntModel m = ModelFactory.createOntologyModel(); File myFile = ...; m.read(new FileInputStream(myFile), ""); ResIterator iter = m.listSubjectsWithProperty(RDF.type, m.getResource("http:// https://www.sodocs.net/doc/2412627729.html,/ont/Animal")); while (iter.hasNext()) { Resource animal = (Resource) iter.next(); System.out.println(animal.getLocalName()); } 和操作RDF(S)不同，com.hp.hpl.jena.ontology.OntModel是专门处理本体（Ontology）的，它是com.hp.hpl.jena.rdf.model.Model的子接口，具有Model的全部功能，同时还有一些Model没有的功能，例如listClasses()、listObjectProperties()，因为只有在本体里才有“类”和“属性”的概念。

DBpedia知识库本体分析

DBpedia知识库本体分析 [摘要]在现有的语义网项目架构中，基于关联数据形式的知识库项目往往处于整个语义网络的核心，如何对于这些知识库的知识内容进行组织、储存和查找就成为了决定整个语义网络运行效率的关键因素。在目前的关联数据知识库项目中，DBpedia是较为典型且成熟的一个，DBpedia网站使用本体的方法来对其条目内容进行组织和存储，本文旨在通过对DBpedia 现有本体结构的分析来说明知识库的本体结构对于知识库的组织、存储和查找有着怎样的影响，并试图从该例中分析归纳得出类似网站知识库内容的本体构建的一般要点。 [关键词]DBpedia 关联数据本体本体构建 1．概述及相关简介 1998年，WWW网络的发明者Berners-Lee提出了语义网的概念。这一概念的核心在于致力提高万维网络及其互联的资源的可用性和有效性，使得下一代的互联网更加智能和高效，能够有效处理目前网络中的大量信息内容。这一概念和其具体的技术实现几经波折，从一开始的基于本体的构想到2006年Berners-Lee提出的关联数据概念，在目前的语义网构想中，关联数据成为了其技术实现的核心概念。 关联数据是一种推荐的最佳实践，用来在与以往中使用URI和RDF发布、分享、连接各类数据、信息和只是，发布和部署实例数据和类数据，从而通过HTTP协议解释并获取这些数据同时强调数据的相互关联、相互联系以及有益于人际理解的语境信息。在目前的具体实践中，数据往往以RDF文件的形式发布到互联网络上，存储在关联数据知识库中。而大多数需要使用这些关联数据的网站可以直接从在线关联数据知识库的数据接口获取RDF文件并提取其中的相关信息反馈给用户，从而实现信息和数据的跨网站共享。从上面不难看出，在线关联数据知识库在当前的关联数据语义网构想中占据着核心位置。 DBpedia就是这样一个在线关联数据知识库项目。它从维基百科的词条中抽取结构化数据，以提供更准确和直接的维基百科搜索，并在其他数据集和维基百科之间创建连接，并进一步将这些数据以关联数据的形式发布到互联网上，提供给需要这些关联数据的在线网络应用、社交网站或者其他在线关联数据知识库。同时，与一些同时期的关联数据知识库项目不同，DBpedia提供的关联数据知识内容并不受限于某一较小的专业或学科领域，到2012年为止，DBpedia知识库项目已有超过3640000个条目，这些条目涉及人名、地名、音乐专辑、电影、组织、种族等等多个类目。在大数量和宽范围的前提下，DBpedia知识库的条目组织就成为决定其运行效率的关键因素。DBpedia知识库以构建本体的形式对条目进行组织，起到了一定的效果。 本体一词是指对客观世界存在的事物的系统描述，在信息科学的领域中，1991年Neches 等人最早给出的定义是：给出构成相关领域词汇的基本术语和关系，以及利用这些术语和关系构成，规定这些词汇外延规则。1993年Gruber将其定义表述为“概念模型的明确的规范说明”。1997年Borst进一步完善了该本体的定义，表述为“共享概念模型的形式化规范说

Protege基础教程

本体构建Protege基础教程 写在前面的话 Ontology，即本体，来源于哲学领域，但自从被图书情报领域专家运用于图书情报领域，便在此领域得到大家的一致认可，各种基于本体的研究论文也层出不穷，但Protege4.0以上版本较之Protege3.X版本，界面功能发生了很大变化，以前其他学者出的学习教程已经并不适合初入本体领域的学者，而Protege官方说明又是全英文解释，给初学者更是带来了很大不便，由此，本人这篇本体构建Protege基础教程应运而生，衷心希望可以给其他学者学习本体构建工具以及以后进行基于本体构建领域的研究工作带来便利。在此，特别感谢唐门的GGJJ在我学习运用Protege过程中给了我很多的理论支持，使我在这个学习过程中思维更加清晰。 ——soonfy 学习软件，首先还是看软件版本，本人演示的是Protege4.1版本，与Protege4.0版本以上的版本界面都较为相似，版本是4.0以上的学者，都可以借鉴。另外，本文档主要是界面介绍及逻辑推理，至于本体构建中的个体关联、实体查询请关注下期文档。

一、界面介绍 1、打开Protege软件。如图1所示。 图1 在图1中，方框1 Create new OWL ontology：新建OWL本体； Open OWL ontology：打开一个OWl本体； Open OWL ontology from URI：通过通用资源标识符（URI）打开一个OWL本体； Open from the TONES repository：从TONES库打开OWL本体。 方框2 Open recent：最近打开的OWL本体路径。

本体理论与领域本体的构建

第二章本体理论与领域本体的构建 2.1 本体理论 2.1.1 本体的基本概念 本体论（Ontology）的概念最初起源于哲学领域，是形而上学理论研究的一个分支，与认识论相对。认识论研究人类知识的本质和来源，即研究主观认知，而本体论研究的则是客观存在。Ontology一方面研究存在的本质，另一方面研究客体对象的理论定义，即整个现实世界的基本特征。现在哲学领域较多翻译为“本体论”。经过多年的演进，到今天，经过人们对“本体”这一概念的重新理解和定位，本体的理论与方法早已被信息领域采用，用于知识的组织、表示、共享和重用。 本体在计算机学科的使用可以追溯到上个世纪80年代，Alxenader在1986年发表的文章被视为本体在计算机领域获得不同于哲学领域的新的研究的起点。随后Ontolgoy在人工智能领域界获得稳步的发展，并被逐渐赋予了新的含义[8-9]。1991年，在人工智能领域，Neches等人最早给出Ontology定义，Neches认为[10]“An ontology defines the basic terms and relations comprising the vocabulary of a topic area,as well as the rules for combining termsand relations to define extensions to the vocabulary.”即“一个本体给出构成相关领域词汇的基本术语和关系，以及利用这些术语和关系构成的规则定义这些词汇的外延规则。”本体定义了组成主题领域的词汇表的基本术语及其关系，以及结合这些术语和关系来定义词汇表外延的规则[11]。1993年美国斯坦福大学知识系统实验室(Knowledge System Laborary，简称KSL)的Gruber给出了本体在信息科学领域被广泛接受的定义：“An ontology is an explicit specification of a conceptualization”[12]。即“本体是概念化的明确的规范化说明”。这也是最著名并被引用最为广泛的定义。1995年Guarino和Giaretta 将本体定义为[13]“本体是概念化的明确部分的说明一种逻辑语言的模型。”这个定义与Gruber的理解有异曲同工之妙。随后在1997年W.N.Borst对Gruber的定义进行了引申，提出了“本体是共享概念模型的形式化规范说明”，以及1998年J.Studer的“本体是共享概念模型的明确的形式化的规范说明”。 本体的定义随着时间的推移也在进行着不断的变化发展，为明确起见，现将本体发展史中较有代表性的定义列表如下： 表2.1 本体发展史中的定义列表时间/提出人定义 1991/Neches 一个本体给出构成相关领域词汇的基本术语 和关系，以及利用这些术语和关系构成的规

基于Jena的本体构建方法研究-计算机工程

—59— 基于Jena 的本体构建方法研究 向 阳，王 敏，马 强 (同济大学电子信息与工程学院，上海 200092 ) 摘 要：针对本体构建中构造方法不清晰、本体描述语言不统一、可用工具较少的难题，在Jena 的基础上提出了基于Jena 的本体构建方法。该方法由描述类、描述属性、将属性关联到类、定义实例和加入本体维护元数据5个步骤组成，有效地解决了本体构建中的难题。最后以一个实例验证了该方法的有效性。 关键词：本体；本体构建；Jena Research on Jena-based Ontology Building XIANG Yang, WANG Min, MA Qiang (School of Electronic Information and Engineering, Tongji University, Shanghai 200092) 【Abstract 】There are a lot of difficulties in the ontology building such as the unclear building methods, ununified ontology languages, lack of tools.To solve these problems, this paper presents an ontology building method with Jena. The method is composed of 5 parts: class description, property description, link of property and class, individual creation, ontology metadata adding. The validity of the method is proved with an instance. 【Key words 】ontology; ontology building; Jena 计 算 机 工 程Computer Engineering 第33卷 第14期 Vol.33 No.14 2007年7月 July 2007 ·软件技术与数据库· 文章编号：1000—3428(2007)14—0059—03 文献标识码：A 中图分类号：TP311 本体是对领域中的概念及概念之间联系的显式描述。具 体地说，就是要描述一个领域需要哪些概念，概念由哪些属性标识，属性又具有什么约束，概念对应于哪些实例。 在本体的构建中也存在一些问题：本体构造方法定义不清晰；本体构造语言繁多，不同语言构造出来的本体交互性弱；本体构建工具少，目前可供使用的有斯坦福大学的Protégé和HP 公司的Jena 等。本文在Jena 基础上，提出了OWL 本体构建方法。 1 Jena 体系结构 1.1 Jena 的接口功能 Jena 是HP 公司开发的一个基于Java 的开放源代码语义网工具包，为解析RDF 、RDFS 和OWL 本体提供了一个编程环境及一个基于规则的推理引擎[1]。语义网标准的核心是作为通用数据结构的RDF 图[1]。Jena 将RDF 图作为其核心的接口。Jena 有以下几个主要功能[2]： (1)RDF API(主要是com.hp.hpl.jena.rdf.model 包)。可将RDF 模型视为一组RDFstatements 集合。 (2)RDQL 查询语言(主要是com.hp.hpl.jena.rdql 包)。对RDF 数据的查询语言，可以伴随关系数据库存储一起使用以实现查询优化。 (3)推理子系统(主要是com.hp.hpl.jena.reasoner 包)。包括基于RDFS 、OWL 等规则集的推理，也可自己建立规则。 (4)内存存储和永久性存储 (主要是com.hp.hpl.jena.db)。 Jena 提供了基于内存暂时存储的RDF 模型方法， 目前仅支持MySQL 、Oracle 和PostgreSQL 的数据存储。 (5)本体子系统(主要是com.hp.hpl.jena.ontology 包)。 Jena 对OWL 、DAML+OIL 和RDFS 提供不同的接口支持。 1.2 Jena 的接口结构 Jena 主要由API ，SPI 组成。用户编程只需使用API 。SPI 为Jena 提供核心数据结构。Jena 库由包来管理，Jena API 以 接口方式定义。经常用到包的有： (1)com.hp.hpl.jena.rdf.model 包，可创建和操纵RDF 图，是本体API 的基础。结构如图1所示[3]。 图1 rdf.model 包主要接口函数 (2)com.hp.hpl.jena.ontology 包。为操纵基于RDF 的本体提供了抽象接口和实现，结构如图2所示。 图2 ontology 包的主要接口函数 基金项目：国家自然科学基金资助项目(70371054) 作者简介：向 阳(1962－)，男，教授、博士生导师，主研方向：语义网，本体，Web 挖掘；王 敏、马 强，硕士研究生 收稿日期：2006-07-25 E-mail ：drxigyang@https://www.sodocs.net/doc/2412627729.html,

基于本体化知识模型的知识库构建模式研究

基于本体化知识模型的知识库构建模式研究 袁磊1张浩2陈静3陆剑峰1 1(同济大学CIMS中心，上海2(0092) 2(上海电力学院，上海200092) 3(华东师范大学地理系，上海200062) 【摘要】在研究了知识模型及知识库相关理论和技术的基础上，结合本体论，提出了一种基于本体的知识模型，并从领域知识推理、方法知识和任务知识三个角度给出了本体化知识模型基于BNF范式的表达式;基于所建立的本体化知识模型，在对知识进行可拓性分析的基础上，提出了一种知识库结构模式，对于知识模型与知识库的匹配问题进行了讨论，并在理论研究的基础上，给出了利用SQL Server数据库系统建立的知识库示例。 【关键词】本体；知识模型；知识库；设计模式；知识工程 1引言 对于知识的研究与探索，人类自始至终从未停止过，直至人类进入信息化社会并正在向知识化社会迈进的过程中，人类通过计算机的应用才开始真正把知识从概念跃升到知识科学。知识工程便是一门新兴的关于知识获取、表示和推理，以及用一种特定形式把知识表示为计算机可操作对象的科学。其研究的目标是挖掘和抽取人类知识，这也使得计算机具有了人类的一定智能。 知识工程是在20世纪70年代后期，从构建专家系统、基于知识的系统和知识密集型的信息系统的技术发展而来的。Guus Schreiber认为"知识工程是一种建模活动，模型是对现实的某一部分进行的一种有目的的抽象。建模是对知识的少数几个方面建立一种好的描述，而忽略其他方面"。因此，知识工程领域最主要的研究内容是知识表示以及基于此的知识应用。知识模型本身是一个阐述"知识一密集型信息一处理任务结构"的工具。一个应用的知识模型可提供应用所需的数据和知识结构的规范说明。

Protege新手入门(基础篇)

此新手入门对应protege3.1.x版本。通过制作一个简单的动物本体，来使大家了解protege 建立owl的基础用法。 步骤1 建立新的项目。打开protege,然后会出现对话框，点击Create New Project...，出现Create New Project对话框后，选择OWL Flies(.owl or .rdf)后，点击Finish，而不选Next。 步骤2 建立类。protege的主页面中会出现，OWL Classes(OWL类),Properties(属性),Forms(表单),Individuals(个体),Metedata(元类)这几个标签。我们选择OWL Classes 来编辑。在Asserted Hierarchy（添加阶层）中，会有所有类的超类owl:Thing上点击Asserted Hierarchy旁边的Create subclass或者在OWL:Thing,点击右键选择Create subclass。会出现protege自动定义名为Class_1的类。在右边的CLASS EDITOR（类编辑

器）的Name选项中，输入Animal来替换自动定义的名字。(建议使用英文，因为下面会用到OWLViz来生成关系图，中文的话会容易出现问题。)

步骤3 建立Animal的子类，在Animal点击上右键，选择Create subclass，并按照上述方法将其名字变为Herbivore(素食动物)。 步骤4然后按照上面的方法，建立OWL:Thing的另一个子类Plant(植物)，然后建立Plant的子类Tree(树)。状态如下图

年度经营计划的结构制定原则与流程

学习导航 通过学习本课程,你将能够： ●了解年度经营计划的结构； ●掌握制定年度经营计划的原则; ●知道制定年度经营计划需要收集的背景资料； ●正确制定年度经营计划. 年度经营计划的结构、制定原则与流程 一、年度经营计划的结构 年度经营计划的内容由八部分组成，因而可称之为“八股文”。其中的核心部分是立项，此外还要考虑到立项的前因后果,在时间、资源上的配置等。年度经营计划的内容要适中,如果太长，会过于浪费精力;如果太短,说明思考得可能不够深入、完整。 年度经营计划的基本结构与格式，主要包括: 1.战略目标 这一部分是对企业整体战略目标的描述和回顾,目的是保证年度经营计划与企业发展战略一致。该内容中要包括本年度公司的发展战略就下年度在整体战略中的地位和状态，并据此确定本年度的主题—-工作主题。 ２．发展目标 这一部分很简略，用几行字简单阐述即可,专门介绍企业为下一年度设定的发展目标。 3.市场分析 这一部分是对整个市场的分析，并提出企业下一年度的经营整体策略。 4.具体立项 这一部分的内容是,基于企业的整体策略应该如何立项，具体要立哪些项目。 ５．项目资源需求 这一部分的内容是，为了实行具体项目，企业需要哪些资源,从而做出预算。有时也会涉及人力资源等因素的讨论. 6.执行时间计划 这一部分是关于企业全年所有项目的时间安排。企业要根据具体的时间安排，制定一张总体时间表,对所有项目进行排期。这张表要足够大,能包含所有项目。同时，所有项目的时间安排要科学，避免冲突，保证按时完成计划。 7.监控计划

在这一部分要列出保证计划实施的工具和方法，即为了实现计划，应当如何监控，以保证其质量. 8.风险评估与对策 这一部分是关于计划在执行过程中可能遇到的意外情况，要说明计划在哪些情况下需要调整或重新实行。正所谓计划赶不上变化,再好的计划也可能遇到意外情况，那些每遇到意外就需要重新制定的计划是没有指导意义的。因此，要事先设定修改计划的条件。 二、年度经营计划的制定原则 制定年度经营计划时，需要遵循以下四项基本原则: １.自上而下的制定模式 年度经营计划不是一项孤立的计划。很多企业在制定年度经营计划时，往往只参考上一年度的计划，这是一种目光短浅的做法。因此,在制定年度经营计划时，要始终以企业的总体战略规划为指导,从全局出发，做好每一项工作。 2.围绕目标 企业一旦确定目标，就要紧密围绕目标制定项目，切忌出现与目标毫无关系的项目,尤其不能看到竞争对手采取行动就盲目跟风，这是一种僵化的思考方式。企业应该围绕目标建立一套自己的逻辑方法,明确具体工作。 ３。以市场为导向 企业一定要以市场，即客户和消费者为导向制定年度计划。从根本上说,营销能否成功,不是取决于投入的多少,而是企业生产的产品能否满足客户的需求。以苹果公司为例,它对广告的投入并不比中国的很多公司多,但依然能赢得消费者的信任，最重要的原因是其设计出的产品以客户为导向。 企业要做到“把市场作为所有工作的中心”，在制定年度计划时就要真正从调研客户开始，思考或观察行情以了解行业的发展趋势,并以之为导向决定为客户提供的产品。因此，企业在制定年度经营计划时，必需要考虑的不是竞争对手在做什么，而是要牢牢抓住消费者。 ４。整合资源 年度经营计划是一个工业化的专业协作体,它不能由一个部门完成。企业在制定年度计划时，要把公司所有部门的主要负责人聚在一起，进行分工，全部参与。例如，生产计划由生产总监立项,销售计划由销售总监立项,人力资源计划由人力资源总监立项。最后,所有总监要达成协议，并在年度经营计划上签字，相当于对彼此和组织做出的承诺，因此，必须严肃对待。 三、年度经营计划的管理流程

知识工程中的知识库、本体与专家系统①

知识工程中的知识库、本体与专家系统① 魏圆圆1, 钱 平2, 王儒敬1, 王 雪1 1(中国科学院合肥智能机械研究所, 合肥230031) 2(中国农业科学院农业信息研究所, 北京100081) 摘 要: 随着语义Web思想的兴起, 对专家系统的互操作性和共享性也提出了更高的要求, 对新型知识表示方式和新型知识系统的研究是大势所趋. 本体作为共享概念模型的明确的形式化规范说明, 为不同系统之间的互操作提供了基本的框架, 是解决共享和互操作问题的有效的方法. 一些初学者对知识库、本体以及专家系统的概念产生了各种疑惑, 根据笔者的理解与实践, 对知识工程中的本体、知识库以及专家系统做出较系统的比较分析,对这几个术语做一个澄清. 关键词: 知识库; 本体; 专家系统; 知识表示 Knowledge Base, Ontology and Expert System in Knowledge Engineering WEI Yuan-Yuan1, QIAN Ping2, WANG Ru-Jing1, WANG Xue1 1(Institute of Intelligent Machines, Chinese Academy of Sciences, Hefei 230031, China) 2(Agricultural Information Institute, Chinese Academy of Agricultural Sciences, Beijing 100081, China) Abstract: With the development of the Semantic Web, the interoperability and sharing of expert system were put for- ward more advanced requests. The researches for new knowledge representation and knowledge base systems are im- portant trend. As a formal, explicit specification of a shared conceptualization, ontologies provide frames for inte- roperability between different systems and can solve the sharing and interoperability problem effectively. There were a variety of doubts in some beginners’ mind with the concepts of knowledge base, ontology and expert system. Based on the author's understanding and practice, the systematic comparative analysis between knowledge base, ontology and expert system in the domain of knowledge engineering were proposed in this paper, in order to make these terms less confused and more clearly comprehensible. Key words: knowledge base; ontology; expert system; knowledge representation 作为构建语义Web的基础, 本体论的研究及其应用是目前国内外非常关注的研究热点, 成为一个新的研究领域. 近年来, 本体的开发逐渐从人工智能实验室走向领域专家的桌面上. 本体的应用从网站的分类系统(比如Yahoo!)到网络产品销售的分门别类(比如https://www.sodocs.net/doc/2412627729.html,), 在互联网上的应用逐渐普及[1]. 某些学者将本体看作是构造知识库的一种途径, 另一些学者认为本体是知识库的重要组成部分[2,3], 此外还有专家将本体视为在不同平台间进行互操作处理的关键技术. 上世纪90年代, 随着本体定义的提出, 知识工程领域在建立知识库的方法上也产生了一种革命性思想, 即有关本体工程和构建本体知识库的思想[2]. 同时, 随着并行与分布式处理、语义Web等新思想与技术的引入, 对专家系统的互操作性和共享性也提出了更高的要求, 对新型知识表示方式和新型知识系统的研究是大势所趋. 本体作为共享概念模型的明确的形式化规范说明, 为不同系统之间的互操作提供了基本的框架, 是解决共享和互操作问题的有效的方法. 因此, 当初研究专家系统的专家学者都对本体产生了兴趣, ①基金项目:国家自然科学基金(31171456);中国科学院知识创新工程青年人才领域专项前沿项目 收稿时间:2012-02-09;收到修改稿时间:2012-03-25

本体构建方法

本体构建方法 本文通过借鉴其他领域本体的构建方法，尤其是苏格兰爱丁堡大学的企业本体的建立过程，首先尝试着一步步建立起自己的本体模型，并且经过反复迭代的过程，不断的进行排错和修改，直至本体模型初具雏形。然后在遵循本体建立准则的基础上，通过抽象总结出一套领域本体的知识工程构建方法。 领域本体构建过程 3.1 确定本体的领域与范围 首先要明确构建的本体将覆盖的专业领域、应将本体的目的、作用以及它的系统开发，维护和应用对象，这些对于领域本体的建立过程中有着很大的关系，所以应当在开发本体前注意。对于特定的专业领域的一些特殊的表达法和特定的详细内容等的注释，应当明确。另外能力问（competency questions）是由一系列基于该本体的知识库系统应该能回答出的问题组成（Gruninger和Fox，1995），能力问题被用来检验该本体是否合适：本体是否包含了足够的信息来回答这些问题？问题的答案是否需要特定的细化程度或需要一个特定领域的表示。 3.2 列举领域中重要的术语、概念。 在领域本体创建的初始阶段，尽可能列举出系统想要陈述的或要向用户解释的所有概念。这上面的概念和术语是需要声明或解释的。而不必在意所要表达的概念之间的意思是否重叠，也不要考虑这些概念到底用何种方式（类、属性还是实例）来表达。 3.3 建立本体框架。 上一步骤中已经产生了领域中大量的概念，但却是一张毫无组织结构的词汇表，这时需要按照一定的逻辑规则把它们进行分组，形成不同的工作领域，在同一工作领域的概念，其相关性应该比较强。另外，对其中的每一个概念的重要性要进行评估，选出关键性术语，摒弃那些不必要或者超出领域范围的概念，尽可能准确而精简的表达出领域的知识。从而形成一个领域知识的框架体系，得到领域本体的框架结构。 上述Step 2和Step 3并非是绝对的顺序，这两个步骤往往也可以颠倒过来进行，有时会先列举出领域中的术语和概念，然后从概念中抽象出本体框架；也可以先产生本体框架，再按照框架列举出领域的术语。至于如何具体进行，应该根据开发人员对领域的认识程度，如果领域内已经存在非常清晰的框架或者认识已经很深刻，则可以直接产生框架。当然，这两个步骤也可以交叉进行。 3. 4 设计元本体，重用已有的本体，定义领域中概念及概念之间的关系。 为了描述各个概念，利用术语对概念进行标识，并对其含义进行定义，在这一步定义时先采用自然语言进行定义。为了定义一个概念，设计了元本体。一个概念可以采用元本体中定义的元概念进行定义，或采用在本体中已经被定义的概念进行定义，或重用已有的本体。 元本体是指本体的本体，其术语用于定义本体中的概念，如实体、关系、角色等。它可以说是更高层次的本体，是领域内概念的抽象。在设计元本体时，尽量做到领域无关性，并且包含的元概念数目尽可能的少。目前，web上有许多可重用的本体资源库。重用已有的本体，既可以减少开发的工作量，又能增强与其它使用该本体的系统的交互能力。目前有许多本体可以通过internet获得，许多现成的本体，例如：UNSPSC、DMOZ、Ontolingua 的本体文库和DAML 的本体文库等，可以导入倒本体开发系统中。本体被表达的形式通常并不重要，因为许多知识表示系统能够导入和导出本体。即使某个知识表示系统不能直接使用某种形式的本体，将本体从一种形式到另一种形式通常也不难实现。 除了概念，还要定义概念之间的关系。这些关系不仅仅涉及同工作领域的概念，不同工作领域的概念也可以相关，只是这些关系总是属于某一个工作领域。 定义类（class）及类的层次体系。创建的概念中，很大一部分属于类，而对类的层次的定义有以下3种方法： (1) 自上向下法（top-down）：先定义领域中综合的、概括性的概念，然后逐步细化、说明。 (2) 自下向上法（bottom-up）：先定义具体的、特殊的概念，最底层、最细小的类的定义开始，然后对这些概念泛化成综合性的概念。