本体定义0827Word文件下载.docx

上传人:b****7 文档编号:21927925 上传时间:2023-02-01 格式:DOCX 页数:12 大小:211.26KB
下载 相关 举报
本体定义0827Word文件下载.docx_第1页
第1页 / 共12页
本体定义0827Word文件下载.docx_第2页
第2页 / 共12页
本体定义0827Word文件下载.docx_第3页
第3页 / 共12页
本体定义0827Word文件下载.docx_第4页
第4页 / 共12页
本体定义0827Word文件下载.docx_第5页
第5页 / 共12页
点击查看更多>>
下载资源
资源描述

本体定义0827Word文件下载.docx

《本体定义0827Word文件下载.docx》由会员分享,可在线阅读,更多相关《本体定义0827Word文件下载.docx(12页珍藏版)》请在冰豆网上搜索。

本体定义0827Word文件下载.docx

Cn-1—>

Cn。

例如:

MotherOf关系就是一个函数,其中Motherof(x,y)表示y是x的母亲,显然x可以惟一确定他的母亲y。

公理代表永真断言,比如概念乙属于概念甲的范围。

实例代表元素。

从语义上分析,实例表示的就是对象,而概念表示的则是对象的集合,关系对应于对象元组的集合。

概念的定义一般采用框架结构,包括概念的名称,与其他概念之间关系的集合,以及用自然语言对该概念的描述。

基本的关系有4种:

part-of,kind-of,instance-of,attribute-of.

3.构建本体的规则

明确性和客观性:

即本体应该用自然语言对所定义术语给出明确的、客观的语义定义。

完全性:

即所给出的定义是完整的,完全能表达所描述术语的含义。

一致性:

即由术语得出的推论与术语本身的含义是相容的,不会产生矛盾。

最大单调可扩展性:

即向本体中添加通用或专用的术语时,不需要修改其已有的内容。

最小承诺:

即对待建模对象给出尽可能少的约束。

4.本体构建方法

要构建领域本体,对该领域进行需求分析,确定本体的专业领域和范畴。

即明确领域本体建设的目的、范围、用途、使用者和维护者。

与软件开发过程类似,为了能提供更好的信息服务,在本体建设的规划期,应该首先了解其应用的具体背景和需求。

一般可通过如下问题进行需求分析:

所构建的本体将面向的专业领域;

建立该领域本体的目的;

需要满足的应用需求;

该领域本体的用户和维护者及系统能力问题,及本体信息可以“回答”的专业问题。

本体构建过程具体流程包括如下:

1.确定核心概念;

通过对一个领域信息的收集和获取,得到该领域的核心概念;

2.创建类和类的层次结构;

在确定了领域本体中的核心概念之后,定义类和类的层次结构是本体构建中的一项主要基本工作,也是关系着一个本体是否科学,结构是否合理的重要环节。

一般采用较多的定义和构建类层次结构的方法主要有3种:

自顶向下法、自底向上法和综合法。

在构建领域本体的类层次结构时,一般采用自顶向下法。

自顶向下法是从领域中概括的概念出发,先确立较粗的树形枝节,然后逐步细化,逐层建立子类的过程。

3.定义类的属性和属性约束;

定义了类和类的结构并不能对领域本体的个性化查询提供有效信息,还应该描述出这些概念的内部结构。

属性可以被用来说明类的共同特征以及某些实体的专有特征。

在OWL语言中有两种属性,即一种是实体类型属性,是用来表示两个实体之间的联系;

一种是数据类型属性,是用来表示属性的值。

在对属性进行编辑中,不仅要定义类的属性,还要为某些属性添加约束条件。

4.创建实例;

完成了类的层次结构、属性及属性约束的建立,为本体搭建了一个初步的整体框架结构,相当于人体的骨骼框架。

接下来为本体创建添加实例来描述领域概念中的个体,并为其属性赋值并加以约束,就可以逐步建立完善该领域的知识库,实例的部分就相当于人体的肌肉、经络、皮肤。

要确定一个特定的概念是本体中的一个类还是依赖于本体潜在应用的单个实例并不容易。

因为这涉及到一个本体的起始及表达的最低粒度。

而粒度水平的高低取决于本体的应用需求。

换言之,就是决定本体知识库中需要表达的最为精确的术语。

最小的单个实例是知识库中所要表达的最精确的概念。

如果概念被组织成为自然的等级体系,那么应该将这类概念表达为类。

要注意的是只有在等级体系中才可以设置类,知识表达系统中并没有子实例这样的概念存在。

因此,如果术语中有一种自然的等级体系,应该将这些术语定义为类,即使它们本身不包含任何实例。

所有定义类和类的实例与将来本体的应用有直接的关系。

5.本体评价;

经过前面几个步骤,已建立了一个初步的本体。

类似于软件开发中的测试阶段,本体也需要检验和评价。

目前还没有本体评价的标准方法,更无标准测试集,常用的本体评价指标是正确性、一致性、可扩展性、有效性、本体的规模及描述能力。

具体内容包括:

是否满足开始提出的需求;

是否满足本体的建立准则;

本体中术语的定义是否清晰;

本体中的概念及其关系是否完整;

本体系统能力问题是否得以“回答”;

“回答”是否详尽等等。

如果符合要求,则建立该本体的最终本体并形成文档;

如果不符合,则需要重新开始,循环往复,通过不断更新和修正本体,构建出该领域的核心本体。

6.本体维护;

包括本体的技术评估、相关的软件环境和各阶段文档的评估,详细文档资料的维护以及记录文档版本、软件和本体控制代码的配置管理等。

7.循环改进与扩展;

由于具体领域知识的复杂性和领域边界的模糊性,加上领域专家参与程度的不同,通过以上步骤可能还不能完全反应领域知识中全面的概念和关系。

而且随着具体领域的不断发展,本体的内容也不会一成不变,需要通过知识的进一步获取、概念的进一步扩充或更改等方式,不断改进和扩展领域本体。

5.本体的模型设计

5.1概念属性的设计

概念Ci:

:

=<

id,名称,词汇类型,同义词,描述,词汇添加人>

,对于一个概念,存在7个属性,具体如下所示:

Id:

数据库中的id,可以使用户添加,也可以自动生成,也可作为词汇存储的主键;

名称:

添加词汇的名称,一般情况下,该名称是唯一的;

词汇类型:

分为专业术语、硬件、非功能名词、动词、普通名词等;

可以方便用于后期的词汇查询等;

同义词:

词典中词汇可能存在同义词,可能不存在;

存在同义词的个数也不一定;

同义词与词汇的id和标识符不一样;

各个词汇的id和标识符是惟一的;

标识符:

词汇属性,每个词汇的标识符是唯一的;

描述:

用以进一步解释说明词汇,使得词汇在该领域使用更明确,方便用户理解;

词汇添加人:

词典的构建,包括词典的维护可能不止一个人,对于词典的添加、修改、编辑和删除,不同的人的操作可能不同,为了方便词典的维护,设置词汇添加人,方便词典的维护。

5.2关系的形式化设计

本体中的关系集为R={function,…}等。

函数function主要用来表示两两概念间的约束关系,约束关系包括:

可选关系、必选关系、多选一关系、多选多关系等;

函数function定义:

function(Ci,Cj),表示概念Ci和概念Cj之间的约束关系为函数function。

choose(Ci,Cj,min,max):

Ci,Cj表示概念,min表示关系个数的下线,max表示关系个数的上限。

当min=max=1时,表示概念Ci与概念Cj之间的关系是必选的;

当min=0,max>

1时,表示概念Ci与概念Cj之间的关系是可选的。

5.3本体的形式化设计

Concepts:

Property,subConcepts,Relations,Classify>

={<

Concept_name>

}

Property:

={id,名称,词汇类型,同义词,描述,词汇添加人}

subConcepts:

={子概念的集合}

Relations:

={关系的集合}

Relation:

Concepts,Relation_name,Argument(Cardinality[,Role])>

Argument属于subConcepts

Classify:

={功能,非功能,硬件设备},对所描述的概念进行归类。

6.呼吸机实例

以“呼吸机”本体为例:

1.呼吸机:

Property,subConcepts,Relations,Classify>

id,呼吸机,n.,—,描述,词汇添加人>

={安全性,高效性,稳定性,可靠性,可维护性,可扩充性,蜂鸣器,状态检测}

={具有,触发,检测}

具有:

呼吸机,具有,安全性,高效性,稳定性,可靠性,可维护性,可扩充性,>

触发:

呼吸机,触发,蜂鸣器>

检测:

呼吸机,检测,状态检测>

2.漏气补偿控制:

Property,subConcepts,Relations,Classify>

id,漏气补偿控制,n.,—,描述,词汇添加人>

={电机}

Relatons:

={require};

require:

漏气补偿控制,require,电机>

={功能}

3.爬坡控制:

Property,subConcepts,Relations,Classify>

id,爬坡控制,n.,—,描述,词汇添加人>

subConcepts:

={电机,稳定性,阀门}

Relations={require}

爬坡控制,require,电机>

爬坡控制,require,稳定性>

爬坡控制,require,阀门>

7.知识模型

7.1知识模型的设计

图:

知识模型的设计

TheknowledgemodelofCommonKADShasthreecategoriesofknowledge:

taskknowledgethatdescribestheorderofexecutionforthereasoningsteps,inferenceknowledgethatdescribesthereasoningstep(inference)performedusingthedomainknowledgeandthedomainknowledgeitselfincludingitsproperties,concepts,relations,andsoonintheapplicationdomain.

CommonKADSincorporatesanobject-orienteddevelopmentprocessandusesUMLnotationssuchasclassdiagrams,use-casediagrams,activitydiagramsandstatediagrams.CommonKADSalsohasitsowngraphicalnotationsfortaskdecomposition,inferencestructuresanddomainschemageneration.

1.领域层包含了对于给定领域的静态知识,但不限于解决问题所需要的静态知识,定义领域概念。

2.任务层是将问题解决任务分解成许多子任务,设定每个子任务的目标,描述这些任务的控制流。

3.推理层包含了解决问题的方法,包括推理步骤和领域知识的角色。

领域层构成了领域本体,任务层和推理层构成了任务本体。

即知识模型由领域本体和任务本体结合构成。

任务本体强调问题解决方法、方法的推理步骤和用于描述任务本体的领域知识角色。

7.2任务本体的模型设计

任务本体模型:

Task_Ontology:

Task,subTask,T_Relation>

Task:

id,Task_name,Situation,Specification>

Situation:

当前任务所处的环境或条件

Specification:

采用文本描述,所要完成的任务

subTask:

={子任务的集合,(包括活动,活动是一种特殊的子任务,一种不可再分解的子任务)}

T_Relation:

描述子任务之间的依赖关系。

该关联关系分为两种:

动态依赖和静态依赖。

动态依赖包括:

并行执行、顺序执行等;

静态依赖包括:

互斥、多选一、多选多、可选、必选等。

Activity:

Activity_name[Input_role,Output_role]>

Input:

定义任务的参数输入【可选的】

Output:

定义任务的参数输出【可选的】

7.3任务本体的实例说明

以“呼吸机功能分解”为例,其中治疗功能分解具体如图所示:

治疗功能分解

任务间的关联关系

呼吸暂停/呼吸不足相应:

Task,subTask,T_Relation>

id,Task_name,Situation,Specification>

Task_name:

=呼吸暂停/呼吸不足相应

Situation:

=用户在使用过程中

Specification:

=”检测用户当前呼吸气流,并进行相应处理”

={治疗压力搜索,升压搜索,降压搜索}

静态:

多选一关系;

动态:

顺序关系

(1)Activity_name:

=治疗压力与升压搜索

Input_role:

=检测到2个呼吸暂停

Output_role:

=升压1cmH2O

(2)Activity_name:

=治疗压力与降压搜索

Input_role:

=检测到1个呼吸暂停

Output_role:

8.采用本体描述的好处

(1)领域需求分析参与各方对领域知识理解有差异,所以需要通过本体将其知识形式化,统一化。

(2)在基于本体的领域工程框架中,本体是各个分析阶段的产品的载体。

各个阶段的输入模型和输出模型都采用本体描述,模型能够保证在各个阶段的统一性和一致性。

在领域体系结构分析的阶段,使用本体描述领域体系结构,利用可定制本体推理规则进行领域体系结构模型的一致性检查。

在基于本体的领域模型中这些特征都被表示为概念,并进一步细分为业务动作(Action)、动作刻面(Facet)和术语(Term)等建模元素。

(3)要精确地、一致地描述领域需求的话,领域内基础的术语需要在建模前定义。

确定领域术语的目的是,在领域建模人员内部,以及领域建模使用人员之间,统一领域内基本的概念和术语,避免出现概念混淆和术语误解。

确定领域术语的交付物是领域词典。

领域词典中描述了所有出现在领域模型中的术语和概念。

9.需求工程

需求工程把软件需求分为三个不同的层次:

业务需求、用户需求和功能需求。

业务需求描述了组织结构或客户对软件系统高层次的目标要求。

用户需求描述了用户和系统的交互过程。

功能需求描述了为实现特定的业务需求,软件系统必须具备的功能。

这三个层次都是特征可能存在的地方。

业务需求体现了软件系统具有的业务能力,这些能力是对系统所属领域的鲜明反映。

用户需求中记录的交互过程可能会体现该领域内普遍接受的业务流程或体现该系统具有特色的交互序列。

功能需求中记录的功能则是构成系统的基本元素,是实现业务需求和用户需求的载体。

我们把业务需求、用户需求和功能需求中具有的特征分别称为服务、用例和功能。

基于本体的需求模型中的主要任务:

1.根据领域词典知识,构建领域本体;

并将领域知识(包括概念、关系、约束等)形式化;

2.根据领域需求规范,构建任务本体;

任务本体包括子任务集合,任务描述需求的领域知识,以及推理步骤和步骤之间的控制流;

并将任务本体形式化。

3.构建知识模型,并将本体以XML形式化,在构建领域需求的过程中,本体作为知识库,对该XML文件进行操作,在前台相应的是UML图形设计或其它图形,构建需求模型。

10.基于属性文法的本体形式化描述

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 总结汇报 > 工作总结汇报

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1