Protege4.0使用说明 问题整理.docVIP

Protege4.0使用说明1 准备知识OWL-Lite它是OWL中句法最简单的一种子语言。对于简单的继承或者约束，它就显得非常适用。一般用于合并同类字典和简单继承。lite是清淡的意思OWL-DLOWL-DL较之OWL-Lite，它的表达能力加强了。是基于描述逻辑的(Description Logics)，所以以DL后缀。正是因为有了描述逻辑，使自动推理成为了可能。凡是遵循OWL-DL规范的本体都有可能自动计算类的继承性和检测本体之间的矛盾。因此一般用于要推理本体之间的某种关系或者验证本体是否存在矛盾性，比OWL-Lite更进了一步。这个教程就是基于OWL-DL的。OWL-FullOWL-Full是最具有表达能力的子语言了。它适用于高表达性的场合，如果要把一个事物完整的、精确的、力求无二义性地表达出来，它就非常适用。但正因为它把约束定义太死，所以已经不适合做推理了，一旦推理，会出现大量的矛盾，也不适合进行合并工作，因为它很难与别的本体兼容。如何选择你需要的子语言以下2个建议你可以参考下选择Lite还是DL，在于你觉得用Lite来创建本体，是否已经够用。选择DL还是Full，在于你觉得是自动推理更重要，还是精确表达更重要。DL使建模更灵活，Full使建模更完整更精确、表达力更强。注意：Protg 4在编辑DL和Full的时候并没有什么明显区别，尺度把握在你自己心目中。OWL本体的重要组成部分在早期的Protg版本中，你们会发现这样的术语，Protg frames Instances, Slots and Classes，3个重要的部分是：Instances、Slots、Classes，其实就对应OWL本体中的如下三个部分，它们是：Individuals个体。代表一个领域里面的对象。可以理解成一个类的实例（instances of classes）。比如在工人这么一个类中，小李、老王、阿三等人就是一个一个的Individual。PropertiesProperties翻译为属性的意思。但是它的真正含义不和面向对象编程语言中的属性一样，它的真正含义是2个个体之间的双重联系，或者可以认为是2个Individuals之间的桥梁。比如，hasChild连接了老李和他的孩子狗剩这2个个体。另外，Properties还有3个比较重要的特性，functional，transitive，symmetric，会在第四章详细介绍。Classes在OWL中Classes被翻译成个体的集合。当然它是一系列概念的语义表达，和编程语言中的类非常相似，有继承体系，如果是OWL-DL版本还能推理出一些继承关系，后面会提到。Class Axiom在OWL中，类的公理是非常重要和关键的一部分，它在验证一致性和推理中发挥着巨大的作用。Class Expression类的表达非常为之丰富，有并交补类还是匿名类等等，后面章节将会重点讲述。2 打开披萨饼的例子打开Protg，经过黑屏白字一番加载后，出现了3个选项的对话框。我们选择打开一个网上已有的实例open OWL ontology from URI，系统会给出我们它内建的一些书签，我们选择pizza.owl那个本体。选择之后要保证你的网路是OK的，耐心等待一段时间后，Protg的界面就出来了如果你发现你的Protg版本和我说的不一样，点第二章，里面有下载。我们看软件界面图，最重要的几个版面就是，Classes，Object Properties， Data Properties， Individuals。你们可以大致点进去看看。一进去的版面叫Active Ontology，是这个本体的统计信息。这里例子让你熟悉下Protg的界面，下面我们开始自己构建本体。在创建本体的时候，用的最多的当然是第一种方法Named Class。这种Class也被称为Plain Class，意思就是没有任何语义的类，仅仅是一个标示。好了，我们开始！打开Protg，这次我们要选第一个选项了，就是自己去创建本体。接着要你输入URI，就是世界上唯一的地址，作为我这个本体的标示。这里我们填/ontologies/organization.owl，注意这种规范的写法是很重要的。这是RDF的知识点了，我就不啰嗦了，有兴趣朋友看这里RDF入门教程之后就选择这个本体，我们本体存放的位置。点击Finish之后，我们实际上已经创建了一个空的本体了。而且Protg已经为你创建了RDF/XML，你可以去看看你保存着的OWL文件，表示形式为：!DOCTYPErdf:RDF 进来之后，我们选择Classes那个面板，开始建立出下面这样的一棵树。这棵树是由一些“兴趣爱好”这样的类组成的，一个社团有什么样的兴趣爱好，就将会是什么样的社团，当然一个社团也可以有多个兴趣爱好。至于上图的操作我想就没必要讲了，重点要讲述的是大家在建模的时候要分清什么是分类，什么是继承。继承：只要学过面向对象编程的朋友都熟悉这个概念，在RDF和OWL里父类与子类的关系，远远没有OOP里面那么玄乎，我们来看W3C上的语法描述：ifT(?c1, rdfs:subClassOf, ?c2)T(?x, rdf:type, ?c1)thenT(?x, rdf:type, ?c2)意思就是如果C1是C2的子类，并且有一个实体或者类是属于C1的，那么它也属于C2。记住！推理机就只明白这点，仅此这么简单！ 分类：这里指的分类其实就是上面的继承，一模一样！但是我们在建模的时候并没有把这些分类的类当作本体中的关键元素，而是属于辅助类。辅助什么？辅助我们建模，并不是辅助推理机，有了这些辅助类可以使我们的类机构图更加清晰，我这里举个例子，见下图：我们可以看到这里多了几个类，我们来看哪些是分类关系，哪些是继承关系。这里的Thing下面有一个分类叫Interest，Interest下面有3个被继承的子类，其中的NamedInterest就是典型的辅助类，也可以称为分类类，因为NonMusic和MusicAndFootball是一类兴趣爱好，我们暂且称为复合型的爱好，还有4个就叫做纯种爱好，或者原始爱好。而NamedInterest的作用就是为了建模的时候有个清晰的建模思维，让建模更具有逻辑性和条理性，但是NamedInterest这种类将不会对推理起到任何作用，它仅仅是借用了SubClassOf公理（后面章节将会详述）来作为辅助的。 Disjoint ClassesDisjointClasses、SubClassOf、EquivalentClasses是类的三大公理，见下图：SubClassOf已经在上一节讲过了，EquivalentClasses和推理密切相关，在下面的章节将会讲述，DisjointClasses则是为了让推理能够顺利进行的一个必要条件，没有它的显式声明，有些推理将无法运行。可以说，在OWL里面DisjointClasses无处不在，这也是和我们的思维非常不一样的。因为我们在UML中的类，OOP中的类，都不需要申明它们之间的关系，类与类之间要么是父子关系，要么没有任何关系，一个对象只能是一个类的实例，比如JAVA中String tempStr = new String(); 这里的tempStr就是类String的实例，不存在类似于String int temp = new String() or int(乱写的); 这样的形式，既是String又是int的类型。然而，在OWL中，一个实例可以既是这个类的实例，又是其他类的实例，比如下图：上面有2个集合，这里的集合就好比类，集合里面的小块块就是这个类的实例。从这个图里，我们可以读出那几个类呢？A、B、AB、AB.还有很多比如：非A、A和B的交集的补集等等，我这里公式不打了，这些都是一个个的类，那么在上面这些类中的小块块，就是属于这个类的个体，也叫实例，我们发现，有些小方块可以属于很多类，比如中间的那些，既是属于A的，又是属于B的，也可以属于（AB），也可以属于总之可能会属于很多类。在这里，我们可以进行一个小小的总结了:OWL中的类，和OOP中的类并不一样，只有继承上来说，是类似的，但我们更应该把这些类当作集合来考虑！ 看到这里，我想大家就应该明白DisjointClasses的意思了，是的！为了声明2个类没有交集！只要2个类没有了交集，那么就不存在一个个体同时属于这2个类的情况了，这样推理机可以更加准确无误地表达出我们的意思了。 那么什么样的类需要去申明DisjointClasses呢？答案：同一层次的类！这里涉及到一个模式，叫做Upper Level Ontology这个设计模式给了我们建模一个指导规范：将本体里面的类先按照层次划分，然后将一个层次的类相互DisjointClasses。我们还是以我们的社团本体来举例：这里，Music和Sport就是一个层次的，我们将它们2个相互DisjointClasses。Guitar和Hominca是一个层次的，我们将它们2个相互DisjointClasses。同理，Basketball和Football也是一样要被DisjointClasses。这样设置好之后，思路就非常明确了，不会有一个兴趣爱好既是足球又是篮球的，但是，可以有一个个体的类型是（足球篮球），它的意思是，这个个体要么是足球，要么是篮球。不过，没有一个个体的类型会是（足球篮球），因为（足球篮球）是空集。当我们定义一个个体的类型为（足球篮球），进行推理的时候，会得到如下错误提示：OWL Properties代表了一种关系 relationship，在OWL里，有2种类型的Properties。一种叫Object Properties，代表了individual到individual之间的一种关系。还有一种叫Datatype Properties，代表了individual和基本数据类型的关系，有点像类的属性，比如年龄、身高等。还有一种叫Annotation properties，是属于元数据，数据的数据，可以用来解释Classes、Individual、Object/Datatype Properties。下图以这3种类型，举个例子：一般来说Object Properties较为常用。OK！我们选择Object Properties面板，创建一个Properties。如图：这里有几点要说明： 命名约定，和Classes一样，虽然没有明文规范，但是最好以一个单词小写开头，后面一个单词首字母大写的方式书写。其次，OWL规范中，Properties也有继承性，比如hasMonther可能就是继承自hasParent，自然，如果2个individual之间存在hasMonther关系，则必定存在hasParent关系。要注意，在继承中，不要把Object Properties和Datatype Properties相互继承，没有意义的。更为复杂的创建属性方式我们参考了Pizza饼的例子：看它们的命名，就知道是反了一反，这么做也是为了more powerfull expression，比如，小张是老张的儿子，那么老张是小张的父亲，他们的关系必定存在反关系，是对应的，但这仅仅是我们人类看这命名之后推断出来的，得让计算机也知道这些关系它们有这么一层含义。所以要用到inverse Properties了，我们先选中hasBase，然后点右边的inverse Properties旁边加号，选择isBaseOf，就可以了，之后我们点isBaseOf会发现，它的inverse Properties已经是hasBase了。Functional翻译成中文是有用的，实用的，其实应该翻译成函数的，什么是函数，就是不管参数是什么，最后的答案都是唯一的，不会变化的，sin(30)只会等于1/2，但sin(30)也会等于0.5，当然1/2和0.5是等同的。Functional Properties就是这个意思，比如、:小张最好的朋友是李四，小张最好的朋友是小豆子，如果最好的朋友这个Properties是Functional的，那么可以推断，李四和小豆子是等同的，李四就是小豆子，小豆子就是李四，就好比1/2和0.5其实是一样的，写法不同而已。下图表达的就是这个意思。这个就不用我解释了吧？呵呵，看图就明白意思了。传递性。A-B，B-C，则我们推理出A-C。如果一个属性有inverse Properties，并且这个属性是传递性的，那么那个inverse Properties也是传递性的，这个在Protg 4中没有自动完成，但是推理机可以推理出来。千万记住！传递性和函数性不兼容！if a property is transitive then it cannot be functional.想想看，为什么？对称性，对等性。别把这个和Inverse Properties混合。我举个例子，你就明白了。小张是老张儿子，老张是小张父亲，这个叫inverse properties，是2个properties之间的对称关系，是2个individual和2个properties在做文章。老张和老李是邻居，老李和老张是邻居，这个叫做properties的对等性，是1个property和2个individual在做文章。反对称性，反对等性。这个就很好理解了，最简单的例子就是：小张是老张的儿子，那么老张就不会是小张的儿子。如果有一天老张说：如果你敢！我就是当你儿子！这时计算机就会推断，这个是反对称的，是悖论，则推断出，小张不敢。自反性。如果一个individual将一个property指向自身，那么这个properties就是自反的，比如小张知道小李，并且小张肯定知道小张自己。反自反性，这个也很好理解，比如”是儿子“这个属性就不会是自反的，自己是自己的儿子显然是荒谬的。其实就是一个属性的类型和范围，比如 int i；3i10 那么int就是i的domain，range就是3-10。用英文来形象的表达就是：Properties link individuals from the domain to individuals from the range.在我们这个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节。ifT(?p, rdfs:domain, ?c1)T(?c1, rdfs:subClassOf, ?c2)thenT(?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中，命名类就是用来那棵类的层次树中的限制类、匿名类、Restriction class应用场景:在Protege中，限制类和命名类最大的区别就是，限制类没有一个命名，没有一个标志，没有一个名字，所以很多领域又叫它匿名类。以后我们也称之为匿名类，那么匿名类在哪里声明的呢？一般而言，会在每个命名类的父类声明。这里涉及到一个建模原则：把一个类的各个特征抽象出来，将每个特征转化为动宾结构，再将其表述为一个匿名类。一个类有多少个特征，它就可能有多少个父类。我们来举个一个例子，有一个Guitar协会，它有兴趣爱好在Guitar上，得到了学校器材的补助。首先，命名三个类GuitarOrg、Guitar、EquipmentSubsidy，让它们归属到相应的类层次树下，如图：接着，我们来定义2个Object Property回到类视图，我们点击GuitarOrg类，之后为它构建2个父类，一个父类代表它有兴趣爱好在Guitar上，另一个父类代表它得到学校器材的补助。这个小节，主要大致简单描述下类的几种定义，帮助大家掌握一个体系。对于类的集合表达，将在下面几个章节涉及到。真正的类公理在OWL2.0中只有3个，但是这3个公理却起着至关重要的作用，它们的组成关系如图所示。SubClassOf在推理中有很重要的一块就是Classify，能将所有的类与类之间的关系完整推理出来，推理之前由开发人员定义的，叫做被定义的类层次Asserted Class hierarchy，由推理机自动推理之后的所得到的叫被推理的类层次Inferred Class hierarchy(大家可以在Protege类视图里面找到这2个概念Tab)。前者是开发者设计视图，而后者是用户观看视图，这在OWL1.0中一直没有得到足够的重视。在开发建模阶段，SubClassOf多用来分类，而不是建立子类用，比如：先建立“Type”这么一个命名类，接着建立三个它的子类，叫TypeA，TypeB，TypeC，这3个子类其实并不是真正意义它的子类，而是在它这个范围内，为了建模逻辑的简便性。经过推理后这个所谓的父-子关系将不会被用户所关心。EquivalentClasses和上面的SubClassOf其实是一个层次的公理，SubClassOf表示了类与类之间的层次关系，上下所属关系，而EquivalentClasses表示了类与类之间的等价关系。这2者有所不同的是，SubClassOf是2目运算，由subClass和superClass组成，EquivalentClasses则是2目以上的多目运算。DisjointClasses是起到限制性的作用，将类与类从一个概念上完全隔离， DisjointClasses( CE1 . CEn ) CEi, 1 i n, 里面的类相互之间分离，也就是说，没有一个个体同时属于CEi 和 CEj ( i j )。下面这个表格是3个类公理的描述逻辑，是属于Tbox的内容，理解起来并不难，供大家参考，这是推理机里面的规则。 IFTHENT(?c1, rdfs:subClassOf, ?c2)T(?x, rdf:type, ?c1)T(?x, rdf:type, ?c2)T(?c1, owl:equivalentClass, ?c2)T(?x, rdf:type, ?c1)T(?x, rdf:type, ?c2)T(?c1, owl:equivalentClass, ?c2)T(?x, rdf:type, ?c2)T(?x, rdf:type, ?c1)T(?c1, owl:disjointClasses, ?c2)T(?x, rdf:type, ?c1)T(?x, rdf:type, ?c2)falseSubClassOf作为2目运算在实际的建模过程中一般有3种用途。第一种用途就是OWL2.0官方文档的使用场景，如果定义SubClassOf (CE1 CE2)，则代表CE1是CE2的子类，也可以大致理解为，CE1比CE2描述的更为细致深入。但是这种定义方式是显式的定义，用公理强加给本体，让其2者产生关系，这只能用在已知的公认的关系上，比如：女人是人的子类，这些平时就被冠名为公理的事物，在建模中可以用这种显式定义的方式定义。然而，比如：吉他协会是优秀协会的子类，这种父子关系在现实生活中并不能称为公理，只是有些地方适用而已，这时就不能用SubClassOf显式地去定义它们的父子关系，而应该通过推理机制来获取这些隐含的语义，下文将会对此讲述。 第二个用途，作为辅助类。在本体建模的时候，往往让一系列的类去继承于一个辅助类，但是这个继承关系并不是真正意义的父子关系，相反它们没有任何的关系，可能只是一个包含关系。比如：在owl:Thing下面建立2个子类，分别称作NamedOrganization和AbstractOrganization，然后创建SportOrganization和MusicOrganization这2个类，让它们归属于NamedOrganization。之后创建No_Music_And_SportOrg和No_Sport_And_MusicOrg这2个类，让它们归属于AbstractOrganization。可以发现，这里用公理去定义了它们的父子关系，但是这种公理并非公认的公理，而且它们之间也不存在父子关系，没有继承任何的性质和概念，最合理的解释就是进行了一个分类。在建模中往往会涉及到大量的类，如果不对这些类进行一个分类，则很容易遗漏一些需求信息，还会给后期的维护带来麻烦。因此辅助类在建模中起到了非常关键的作用，但是OWL1.0甚至OWL2.0却没有总体与部分的语义关键字，因此建模设计者们只能借用SubClassOf来模拟总体与部分的关系。这个用途虽然没有用到任何的语义知识点，但是能给本体建模者们提供一个工具，使建模更加清晰明了。第三个用途是和推理密切相关的，可以用来表达类的很多性质。比如：有足球爱好的享受学校体育津贴的规模是中等的社团，该社团现在有3个性质，第一它是有足球爱好的，第二它是享受学校体育紧贴的，第三它是中等规模的。如果某个社团现在需要享有这3个性质，那么就应该去继承3个匿名类，这3个匿名类就是前面所提到的“用限制对象属性的客体来表达类的概念”，分别代表前面所提到的3个性质，用UML类图来表达即为：在图中，这个社团继承了3个匿名类，分别代表了它的3个性质，其中“hasInterest some Football”是它的第一个性质，hasInterest是一个对象属性，some关键字就是类表达能力里面描述的ObjectSomeValuesFrom存在限制，Football是一种兴趣爱好类，这种动宾结构式的表达常常用在匿名类中，然后让其它类去继承，以此来达到表现性质的效果。但是这里的匿名类“hasInterest some Football”是内部类，也即“某社团”内部的父类，该父类无法被其他类共享，其他类也无法去继承它。第三个用法总结起来有如下几个步骤：l 提取出一个类的性质，将每个性质写成动宾结构。 对每个动宾结构提取相应的动词，对应对象属性，提取相应的宾语，对应对象属性的客体。ll 将每组动宾结构写成匿名类的方式，然后作为该类的父类。完成如上步骤后，该类就具有了相应的性质，这种性质是具有语义信息的，能够被推理机识别、读懂、理解、推理。同时这些性质就像对外的接口，能被其他类识别，以此作为桥梁和自身产生关联，比如推理出存在隐含的父子关系。 公理EquivalentClasses (CE1 . CEn)表达了这样一个概念，对于任意一个CEi，1 i n，它们之间都是语义对等的，这是官方定义的多元原语，然而在实际用途中，常见的是二目运算（当然，是属于多目运算范围内的），EquivalentClasses (CE1 CE2)其实就等价于：SubClassOf (CE1 CE2)SubClassOf (CE2 CE1)这种等价关系相当于对SubClassOf公理进行了扩展，SubClassOf仅仅能作为一种必要条件，而EquivalentClasses能作为一种充分条件。例如：类A是一个匿名类的子类，这个匿名类带有B性质（如上一节所述），那么凡是A的子类或者A的实例或者个体，都含有性质B，但是凡是含有性质B的类却不一定是属于类A的，只能正向推导，却无法逆向反推。EquivalentClasses刚好弥补了这个缺陷，使得推理机可以反向推导回来，形成了一个充分必要条件。文献10中将被EquivalentClasses所连接的类描述为Defined Class，将SubClassOf所连接的类描述为Primitive Class。这里的意思是，一个类作为一个性质匿名类的等价类，它就是一个Defined Class定义的类，一个类作为一个性质匿名类的子类，它就是一个Primitive Class原始的类，即：有待推理的类。文献10的作者在这里其实想要表达的意思就是，SubClassOf用来等待被推理，EquivalentClasses用来驱动推理。为了更好表述清楚这个概念，用下图作为一个例子来阐述。上图所展示的是一个推理过程，在该推理过程之前有3个没有任何关联的类，ClassA和ClassB都具有同一个性质，该性质就是上图的匿名类。而AbstractClass则是定义了与这个匿名类等价。需要注意的是，这里其实有3个匿名类，每个匿名类都被包含在它们的主类中，但推理机会判断这些匿名类是否指的是同一个概念，图3.11其实是一种推理机的视角来看待问题，通过一个匿名类将3者产生了关联。AbstractClass这里的语义信息为：只要某个类具有这个匿名类的性质，则它就是AbstractClass的子类。经过推理可以得到图3.11的下半部分，该部分阐述了3者的父子继承关系，是推理之后的视图。这种通过推理得到的父子关系，称为隐式的SubClassOf，它包含在本体的语义信息中，与本体设计师显式定义的公理无关，这种形式其实大大增大了本体的可维护性，比如：假设用显式的SubClassOf来定义它们的父子关系，接着删除了ClassA，那么不仅要删除ClassA这个概念，还要将它和AbstractClass的关联给删除；而通过推理得到的继承关系则有推理机来维护，只需要去删除ClassA本身即可，它和AbstractClass的关系是通过推理后产生的，无需手工删除。 通过上面的分析，其实可以看出，EquivalentClasses公理可以起到桥梁作用，它所等价的性质会被推理机利用来寻找其他的性质，只要有类具有这样的性质接口（见SubClassOf用途三），它们就会产生关联。更为巧妙的是，如果让DefinedClass去继承某一个性质，而这个性质又能被其他DefinedClass探测到，从而产生关联，那就可以推断出很深层次的语义关系了，如下图所示。上图对前面的例子又做了一个延伸，这里，AbstractClass起到了明细的桥梁作用，将本来连性质上都没有任何关联的3个类（SuperClass、ConcreteClassA和ConcreteClassB）赋予了父子继承关系。这其中EquivalentClasses起到了关键的连接作用，为推理机提供了语义线索，这种模式其实就是后面章节要阐述的ODPsIf-Then结构。 disjointClasses在描述逻辑中清晰地表明了这样一个意思：对于表达式disjointClasses(C1,C2,C3)，不存在一个个体同时属于(C1,C2,C3)当中的任意2个或多个类，也即：(C1,C2,C3)之间的交集为空。文献5的作者Alan Rector在那场报告中指出，disjointClasses是一种不被大家熟知的表达方式。不管在UML、面向对象编程语言以及其他一些所熟悉的技术，都不用显式去定义2个类之间没有交集。比如在JAVA中，类就是类，2个类不会产生关系，除非它们是父子关系，或者是实现类和接口的关系，没有一个实例既是属于A类又是属于B类的。但是在OWL世界中，这些陈规旧条变得不通用，如果2个类没有显式去定义它们之间的disjointClasses关系，那么就会存在一个个体，它同时属于这2个类，而且是这是被推理机默认的。因此，如果要让推理机明白不会存在一个个体同时属于2个类，那么就必须把这2个类定义成disjointClasses关系。 那么在具体应用中，不见得将所有本体中的类都定义成disjointClasses关系，那显然是不符合逻辑的，这就提出了一种叫做Upper Level Ontology 的ODPs。这个ODPs对如何使用disjointClasses公理提出了很好的一种应用场景。它的建模过程如下：首先对本体进行一个层次的划分，比如：兴趣爱好下面分为音乐兴趣爱好和球类兴趣爱好，音乐兴趣爱好可以衍生出吉他爱好、口琴爱好、钢琴爱好等等；球类兴趣爱好可以衍生出足球爱好、篮球爱好、棒球爱好等等。这里音乐兴趣爱好和球类兴趣爱好就是同一个层次；吉他爱好、口琴爱好、钢琴爱好又是属于另一个层次；同样足球爱好、篮球爱好、棒球爱好也是单独属于一个层次。接着对每个层次的类进行disjointClasses公理应用，就上面这个例子来说，disjointClasses公理总共应用了3次，每个层次各一次。但是由于这些层次之间存在一个继承关系，层次与层次之间，其实已经隐式地划分开来了。比如这里足球爱好和吉他爱好是disjointClasses关系，尽管没有显式定义它们2个的disjointClasses关系。定义disjointClasses公理的首要功能就是使得推理机能够顺利推理出补类的关系。依然以上面这些爱好类为例，兴趣爱好下面分为音乐兴趣爱好和球类兴趣爱好，这其实就是向推理机表明，兴趣爱好=音乐兴趣爱好球类兴趣爱好，并且，音乐兴趣爱好球类兴趣爱好=NULL。这样容易推理出，非球类兴趣爱好就是音乐兴趣爱好。如果没有显式定义它们之间的disjointClasses关系，是无法进行这些推理的。这在后续的ODPs中用到非常多，会逐渐成为一种规范，在这种规范下定义出来的本体是语义精确的。 上图中，音乐兴趣爱好和球类兴趣爱好互为disjointClasses，足球爱好和篮球爱好互为disjointClasses，吉他爱好和口琴爱好互为disjointClasses，有了这3个disjointClasses就足够了。比如：非吉他爱好，会首先推断是口琴爱好，还会推断出是球类兴趣爱好，进而推断出足球爱好和篮球爱好，这些都是属于非吉他爱好的。这个推导过程很简单，首先按照上面的方法都将这些兴趣爱好建好，记住，3个disjointClasses关系别漏了，看上面的那副图。 接着，我们创建一个测试类出来，叫做not_Guitar。如图：选择not_Guitar，然后点旁边的add equivalent Class 在跳出的框中，写上not Guitar，注意大小写，只有写对后，那个确定按钮才会出来的，如果这个框跳出不来，那就说明你下了一个有bug的版本，我是遇到过的，去换个版本吧，或者我提供的下载地址也可以的。 最后选择推理机。 推理出最终结果如下，可以看到not_Guitar类，自动成为了它们的父类，它们也的确不是Guitar类。 1、用protege4构建中文本体，类名称的大小写问题如何处理？Protege4构建英文本体时，有一个约定俗成的要求，就是类名称首字母要大写，属性名称首字母要小写，如果构建中文本体时，不知如何处理这类问题？这个无所谓的，j