Protege40使用说明.docx

Protege40使用说明.docx

《Protege40使用说明.docx》由会员分享，可在线阅读，更多相关《Protege40使用说明.docx（26页珍藏版）》请在冰点文库上搜索。

Protege40使用说明

Protege4.0使用说明

OWL-Lite

∙它是OWL中句法最简单的一种子语言。

∙对于简单的继承或者约束，它就显得非常适用。

∙一般用于合并同类字典和简单继承。

∙lite是清淡的意思

OWL-DL

∙OWL-DL较之OWL-Lite，它的表达能力加强了。

是基于描述逻辑的（DescriptionLogics），所以以DL后缀。

∙正是因为有了描述逻辑，使自动推理成为了可能。

∙凡是遵循OWL-DL规范的本体都有可能自动计算类的继承性和检测本体之间的矛盾。

因此一般用于要推理本体之间的某种关系或者验证本体是否存在矛盾性，比OWL-Lite更进了一步。

∙这个教程就是基于OWL-DL的。

OWL-Full

∙OWL-Full是最具有表达能力的子语言了。

∙它适用于高表达性的场合，如果要把一个事物完整的、精确的、力求无二义性地表达出来，它就非常适用。

∙但正因为它把约束定义太死，所以已经不适合做推理了，一旦推理，会出现大量的矛盾，也不适合进行合并工作，因为它很难与别的本体兼容。

如何选择你需要的子语言

∙以下2个建议你可以参考下

∙选择Lite还是DL，在于你觉得用Lite来创建本体，是否已经够用。

∙选择DL还是Full，在于你觉得是自动推理更重要，还是精确表达更重要。

DL使建模更灵活，Full使建模更完整更精确、表达力更强。

∙注意：

Protégé4在编辑DL和Full的时候并没有什么明显区别，尺度把握在你自己心目中。

OWL本体的重要组成部分

在早期的Protégé版本中，你们会发现这样的术语，ProtégéframesInstances,SlotsandClasses，3个重要的部分是：

Instances、Slots、Classes，其实就对应OWL本体中的如下三个部分，它们是：

Individuals

个体。

代表一个领域里面的对象。

可以理解成一个类的实例（instancesofclasses）。

比如在工人这么一个类中，小李、老王、阿三等人就是一个一个的Individual。

Properties

Properties翻译为属性的意思。

但是它的真正含义不和面向对象编程语言中的属性一样，它的真正含义是2个个体之间的双重联系，或者可以认为是2个Individuals之间的桥梁。

比如，hasChild连接了老李和他的孩子狗剩这2个个体。

另外，Properties还有3个比较重要的特性，functional，transitive，symmetric，会在第四章详细介绍。

Classes

在OWL中Classes被翻译成个体的集合。

当然它是一系列概念的语义表达，和编程语言中的类非常相似，有继承体系，如果是OWL-DL版本还能推理出一些继承关系，后面会提到。

ClassAxiom

在OWL中，类的公理是非常重要和关键的一部分，它在验证一致性和推理中发挥着巨大的作用。

ClassExpression

类的表达非常为之丰富，有并交补类还是匿名类等等，后面章节将会重点讲述。

打开披萨饼的例子

∙打开Protégé，经过黑屏白字一番加载后，出现了3个选项的对话框。

∙我们选择打开一个网上已有的实例——openOWLontologyfromURI

∙系统会给出我们它内建的一些书签，我们选择pizza.owl那个本体。

∙

∙选择之后要保证你的网路是OK的，耐心等待一段时间后，Protégé的界面就出来了

∙

∙如果你发现你的Protégé版本和我说的不一样，点第二章，里面有下载。

∙我们看软件界面图，最重要的几个版面就是，Classes，ObjectProperties，DataProperties，Individuals。

你们可以大致点进去看看。

一进去的版面叫ActiveOntology，是这个本体的统计信息。

∙这里例子让你熟悉下Protégé的界面，下面我们开始自己构建本体。

在创建本体的时候，用的最多的当然是第一种方法————NamedClass。

这种Class也被称为PlainClass，意思就是没有任何语义的类，仅仅是一个标示。

好了，我们开始！

∙打开Protégé，这次我们要选第一个选项了，就是自己去创建本体。

∙接着要你输入URI，就是世界上唯一的地址，作为我这个本体的标示。

这里我们填

∙之后就选择这个本体，我们本体存放的位置。

∙点击Finish之后，我们实际上已经创建了一个空的本体了。

而且Protégé已经为你创建了RDF/XML，你可以去看看你保存着的OWL文件，表示形式为：

∙

1.

xmlversion="1.0"?

>

2. 

3. 

4.

DOCTYPE rdf:

RDF[

5.  

ENTITY owl"http:

//www.w3.org/2002/07/owl#">

6.  

ENTITY owl2"http:

//www.w3.org/2006/12/owl2#">

7.  

ENTITY xsd"http:

//www.w3.org/2001/XMLSchema#">

8.  

ENTITY owl2xml"http:

//www.w3.org/2006/12/owl2-xml#">

9.  

ENTITY rdfs"http:

//www.w3.org/2000/01/rdf-schema#">

10.  

ENTITY rdf"http:

//www.w3.org/1999/02/22-rdf-syntax-ns#">

11.]>

12. 

13. 

14.

RDF xmlns="

15.   xml:

base="

16.   xmlns:

rdfs="http:

//www.w3.org/2000/01/rdf-schema#"

17.   xmlns:

owl2xml="http:

//www.w3.org/2006/12/owl2-xml#"

18.   xmlns:

owl="http:

//www.w3.org/2002/07/owl#"

19.   xmlns:

xsd="http:

//www.w3.org/2001/XMLSchema#"

20.   xmlns:

rdf="http:

//www.w3.org/1999/02/22-rdf-syntax-ns#"

21.   xmlns:

owl2="http:

//www.w3.org/2006/12/owl2#">

22.  

Ontology rdf:

about=""/>

23.

RDF>

∙进来之后，我们选择Classes那个面板，开始建立出下面这样的一棵树。

∙

这棵树是由一些“兴趣爱好”这样的类组成的，一个社团有什么样的兴趣爱好，就将会是什么样的社团，当然一个社团也可以有多个兴趣爱好。

至于上图的操作我想就没必要讲了，重点要讲述的是大家在建模的时候要分清什么是分类，什么是继承。

∙继承：

只要学过面向对象编程的朋友都熟悉这个概念，在RDF和OWL里父类与子类的关系，远远没有OOP里面那么玄乎，我们来看W3C上的语法描述：

if

T（?

c1,rdfs:

subClassOf,?

c2）

T（?

x,rdf:

type,?

c1）

then

T（?

x,rdf:

type,?

c2）

意思就是如果C1是C2的子类，并且有一个实体或者类是属于C1的，那么它也属于C2。

记住！

推理机就只明白这点，仅此这么简单！

∙分类：

这里指的分类其实就是上面的继承，一模一样！

但是我们在建模的时候并没有把这些分类的类当作本体中的关键元素，而是属于辅助类。

辅助什么？

辅助我们建模，并不是辅助推理机，有了这些辅助类可以使我们的类机构图更加清晰，我这里举个例子，见下图：

我们可以看到这里多了几个类，我们来看哪些是分类关系，哪些是继承关系。

这里的Thing下面有一个分类叫Interest，Interest下面有3个被继承的子类，其中的NamedInterest就是典型的辅助类，也可以称为分类类，因为NonMusic和MusicAndFootball是一类兴趣爱好，我们暂且称为复合型的爱好，还有4个就叫做纯种爱好，或者原始爱好。

而NamedInterest的作用就是为了建模的时候有个清晰的建模思维，让建模更具有逻辑性和条理性，但是NamedInterest这种类将不会对推理起到任何作用，它仅仅是借用了SubClassOf公理（后面章节将会详述）来作为辅助的。

DisjointClasses

∙DisjointClasses、SubClassOf、EquivalentClasses是类的三大公理，见下图：

SubClassOf已经在上一节讲过了，EquivalentClasses和推理密切相关，在下面的章节将会讲述，DisjointClasses则是为了让推理能够顺利进行的一个必要条件，没有它的显式声明，有些推理将无法运行。

可以说，在OWL里面DisjointClasses无处不在，这也是和我们的思维非常不一样的。

因为我们在UML中的类，OOP中的类，都不需要申明它们之间的关系，类与类之间要么是父子关系，要么没有任何关系，一个对象只能是一个类的实例，比如JAVA中

StringtempStr=newString（）;

这里的tempStr就是类String的实例，不存在类似于

Stringinttemp=newString（）orint（乱写的）;

这样的形式，既是String又是int的类型。

然而，在OWL中，一个实例可以既是这个类的实例，又是其他类的实例，比如下图：

上面有2个集合，这里的集合就好比类，集合里面的小块块就是这个类的实例。

从这个图里，我们可以读出那几个类呢？

A、B、A∩B、A∪B...还有很多比如：

非A、A和B的交集的补集等等，我这里公式不打了，这些都是一个个的类

那么在上面这些类中的小块块，就是属于这个类的个体，也叫实例，我们发现，有些小方块可以属于很多类，比如中间的那些，既是属于A的，又是属于B的，也可以属于（A∪B），也可以属于……总之可能会属于很多类。

在这里，我们可以进行一个小小的总结了:

OWL中的类，和OOP中的类并不一样，只有继承上来说，是类似的，但我们更应该把这些类当作集合来考虑！

看到这里，我想大家就应该明白DisjointClasses的意思了，是的！

为了声明2个类没有交集！

！

只要2个类没有了交集，那么就不存在一个个体同时属于这2个类的情况了，这样推理机可以更加准确无误地表达出我们的意思了。

∙那么什么样的类需要去申明DisjointClasses呢？

答案：

同一层次的类！

这里涉及到一个模式，叫做UpperLevelOntology

这个设计模式给了我们建模一个指导规范：

将本体里面的类先按照层次划分，然后将一个层次的类相互DisjointClasses。

我们还是以我们的社团本体来举例：

这里，Music和Sport就是一个层次的，我们将它们2个相互DisjointClasses。

Guitar和Hominca是一个层次的，我们将它们2个相互DisjointClasses。

同理，Basketball和Football也是一样要被DisjointClasses。

这样设置好之后，思路就非常明确了，不会有一个兴趣爱好既是足球又是篮球的，但是，可以有一个个体的类型是（足球∪篮球），它的意思是，这个个体要么是足球，要么是篮球。

不过，没有一个个体的类型会是（足球∩篮球），因为（足球∩篮球）是空集。

当我们定义一个个体的类型为（足球∩篮球），进行推理的时候，会得到如下错误提示：

OWLProperties代表了一种关系relationship，在OWL里，有2种类型的Properties。

一种叫ObjectProperties，代表了individual到individual之间的一种关系。

还有一种叫DatatypeProperties，代表了individual和基本数据类型的关系，有点像类的属性，比如年龄、身高等。

还有一种叫Annotationproperties，是属于元数据，数据的数据，可以用来解释Classes、Individual、Object/DatatypeProperties。

下图以这3种类型，举个例子：

∙

∙一般来说ObjectProperties较为常用。

∙OK！

我们选择ObjectProperties面板，创建一个Properties。

如图：

∙

∙这里有几点要说明：

o命名约定，和Classes一样，虽然没有明文规范，但是最好以一个单词小写开头，后面一个单词首字母大写的方式书写。

o其次，OWL规范中，Properties也有继承性，比如hasMonther可能就是继承自hasParent，自然，如果2个individual之间存在hasMonther关系，则必定存在hasParent关系。

o要注意，在继承中，不要把ObjectProperties和DatatypeProperties相互继承，没有意义的。

∙更为复杂的创建属性方式我们参考了Pizza饼的例子：

∙

∙看它们的命名，就知道是反了一反，这么做也是为了morepowerfullexpression，比如，小张是老张的儿子，那么老张是小张的父亲，他们的关系必定存在反关系，是对应的，

∙

∙但这仅仅是我们人类看这命名之后推断出来的，得让计算机也知道这些关系它们有这么一层含义。

所以要用到inverseProperties了，我们先选中hasBase，然后点右边的inverseProperties旁边加号，选择isBaseOf，就可以了，之后我们点isBaseOf会发现，它的inverseProperties已经是hasBase了。

Functional翻译成中文是有用的，实用的，其实应该翻译成函数的，什么是函数，就是不管参数是什么，最后的答案都是唯一的，不会变化的，sin（30）只会等于1/2，但sin（30）也会等于0.5，当然1/2和0.5是等同的。

FunctionalProperties就是这个意思，比如、:

小张最好的朋友是李四，小张最好的朋友是小豆子，如果"最好的朋友"这个Properties是Functional的，那么可以推断，李四和小豆子是等同的，李四就是小豆子，小豆子就是李四，就好比1/2和0.5其实是一样的，写法不同而已。

下图表达的就是这个意思。

∙

这个就不用我解释了吧？

呵呵，看图就明白意思了。

传递性。

A->B，B->C，则我们推理出A->C。

如果一个属性有inverseProperties，并且这个属性是传递性的，那么那个inverseProperties也是传递性的，这个在Protégé4中没有自动完成，但是推理机可以推理出来。

千万记住！

传递性和函数性不兼容！

ifapropertyistransitivethenitcannotbefunctional.想想看，为什么？

对称性，对等性。

别把这个和InverseProperties混合。

我举个例子，你就明白了。

小张是老张儿子，老张是小张父亲，这个叫inverseproperties，是2个properties之间的对称关系，是2个individual和2个properties在做文章。

老张和老李是邻居，老李和老张是邻居，这个叫做properties的对等性，是1个property和2个individual在做文章。

反对称性，反对等性。

这个就很好理解了，最简单的例子就是：

小张是老张的儿子，那么老张就不会是小张的儿子。

如果有一天老张说：

如果你敢！

我就是当你儿子！

这时计算机就会推断，这个是反对称的，是悖论，则推断出，小张不敢。

自反性。

如果一个individual将一个property指向自身，那么这个properties就是自反的，比如小张知道小李，并且小张肯定知道小张自己。

反自反性，这个也很好理解，比如”是儿子“这个属性就不会是自反的，自己是自己的儿子显然是荒谬的。

其实就是一个属性的类型和范围，比如inti；3

用英文来形象的表达就是：

Propertieslinkindividualsfromthedomaintoindividualsfromtherange.

在我们这个Organization的例子中，我们拿hasInterest这个Property来说，它的domain就是Organization，它的Range就是Interest。

注意！

Properties的domain，range和Properties的6大特性不一样，6大特性那是一种推理机制要用到的约束——Constraint，而domain，range是一种公理——axiom。

什么意思？

约束是用来限制的，可以用推理机制来验证，如果限制出了问题就会推理出错。

而公理总是对的，推理要基于它们来推理。

举个例子，hasTopping的domain我们定义为Pizza，如果在本体上，发现hasTopping连接到了icecream，那么是不会报错的，OWL会认为，icecream为Pizza的子类，这在W3C的文档上有详细的语义推理定义，见下面的公式。

除非……你在构建本体的时候强行定义了，icecream和Pizza是相互Disjoint的，见3.5节。

if

T（?

p,rdfs:

domain,?

c1）

T（?

c1,rdfs:

subClassOf,?

c2）

then

T（?

p,rdfs:

domain,?

c2）

∙当我们再次回顾创建类的6种方法时，我们可曾反过来想想，如果让我们来设计OWL语言，我们会设计出几类创建类的方法？

这块板是属于木头的——类：

木头（名词型）

你是是很有理想的——类：

很有理想的（有：

动词；理想：

名词；属于动宾型）

这个材料既是属于树胶又是属于塑料的——类：

树胶∩塑料（名词和名词的集合型）

他是男人——类：

男人（名词型）

它是吃肉的。

（吃：

动词；肉：

名词；属于动宾型）

他是有一颗赤诚热心的人——类1∩类2；类1：

人（名词型）；类二：

有一颗赤诚热心的（量词动宾型）

这类皇冠都镶有No.1098型钻石——类：

镶有No.1098型钻石的（具体个体的动宾型）

这批货物要么是可乐瓶，要么是啤酒瓶——枚举类：

类1和类二

我们会发现，上面的这些类的定义方法，刚好对应于我们讲的6种方法，其中的动宾型、量词动宾型、具体个体的动宾型等就好比对应限制类，其中的名词型好比对应命名类，等等。

我们来看OWL官方对类的表达的定义：

ClassExpression :

=

   Class|

   ObjectIntersectionOf|ObjectUnionOf|ObjectComplementOf|ObjectOneOf|

   ObjectSomeValuesFrom|ObjectAllValuesFrom|ObjectHasValue|ObjectExistsSelf|

   ObjectMinCardinality|ObjectMaxCardinality|ObjectExactCardinality|

   DataSomeValuesFrom|DataAllValuesFrom|DataHasValue|

   DataMinCardinality|DataMaxCardinality|DataExactCardinality

看了这些定义，我们重新来整理下，总共有三类定义类的表达，第一行就是命名类，第二行就是对很多命名类的再次集合运算而杂糅出新的类，后面几行就是限制性的类，用动宾形式来表达。

∙我们来探讨下这些类的应用场景，命名类是最常用的，可以说，没有任何的语义，仅仅是ID号，一个标示，就像我们的姓名，无法从一个人的姓名推理出他的学习情况，他的生活情况（算命之类不在我们讨论范围内）。

那么在Protege中，命名类就是用来那棵类的层次树中的

∙限制类、匿名类、Restrictionclass应用场景:

在Protege中，限制类和命名类最大的区别就是，限制类没有一个命名，没有一个标志，没有一个名字，所以很多领域又叫它匿名类。

以后我们也称之为匿名类，那么匿名类在哪里声明的呢？

一般而言，会在每个命名类的父类声明。

这里涉及到一个建模原则：

把一个类的各个特征抽象出来，将每个特征转化为动宾结构，再将其表述为一个匿名类。

一个类有多少个特征，它就可能有多少个父类。

我们来举个一个例子，有一个Guitar协会，它有兴趣爱好在Guitar上，得到了学校器材的补助。

首先，命名三个类GuitarOrg、Guitar、EquipmentSubsidy，让它们归属到相应的类层次树下，如图：

接着，我们来定义2个ObjectProperty

回到类视图，我们点击GuitarOrg类，之后为它构建2个父类，一个父类代表它有兴趣爱好在Guitar上，另一个父类代表它得到学校器材的补助。

∙这个小节，主要大致简单描述下类的几种定义，帮助大家掌握一个体系。

对于类的集合表达，将在下面几个章节涉及到。

 真正的类公理在OWL2.0中只有3个，但是这3个公理却起着至关重要的作用，它们的组成关系如图所示。

        SubClassOf在推理中有很重要的一块就是Classify，能将所有的类与类之间的关系完整推理出来，推理之前由开发人员定义的，叫做被定义的类层次AssertedClasshierarchy，由推理机自动推理之后的所得到的叫被推理的类层次InferredClasshierarchy（大家可以在Protege类视图里面找到这2个概念Tab）。

前者是开发者设计视图，而后者是用户观看视图，这在OWL1.0中一直没有得到足够的重视。

在开发建模阶段，SubClassOf多用来分类，而不是建立子类用，比如：

先建立“Type”这么一个命名类，接着建立三个它的子类，叫TypeA，TypeB，TypeC，这3个子类其实并不是真正意义它的子类，而是在它这个范围内，为了建模逻辑的简便性。

经过推理后这个所谓的父-子关系将不会被用户所关心。

        EquivalentClasses和上面的SubClassOf其实是一个层次的公理，SubClassOf表示了类与类之间的层次关系，上下所属关系，而EquivalentClasses表示了类与类之间的等价关系。

这2者有所不同的是，SubClassOf是2目运算，由subClass和superClass组成，EquivalentClasses则是2目以上的多