下载

2下载券

加入VIP
  • 专属下载券
  • 上传内容扩展
  • 资料优先审核
  • 免费资料无限下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 Protege4.0使用说明

Protege4.0使用说明.doc

Protege4.0使用说明

979839586
2012-05-01 0人阅读 举报 0 0 0 暂无简介

简介:本文档为《Protege4.0使用说明doc》,可适用于高等教育领域

Protege使用说明OWLLite·它是OWL中句法最简单的一种子语言。·对于简单的继承或者约束它就显得非常适用。·一般用于合并同类字典和简单继承。·lite是清淡的意思OWLDL·OWLDL较之OWLLite它的表达能力加强了。是基于描述逻辑的(DescriptionLogics)所以以DL后缀。·正是因为有了描述逻辑使自动推理成为了可能。·凡是遵循OWLDL规范的本体都有可能自动计算类的继承性和检测本体之间的矛盾。因此一般用于要推理本体之间的某种关系或者验证本体是否存在矛盾性比OWLLite更进了一步。·这个教程就是基于OWLDL的。OWLFull·OWLFull是最具有表达能力的子语言了。·它适用于高表达性的场合如果要把一个事物完整的、精确的、力求无二义性地表达出来它就非常适用。·但正因为它把约束定义太死所以已经不适合做推理了一旦推理会出现大量的矛盾也不适合进行合并工作因为它很难与别的本体兼容。如何选择你需要的子语言·以下个建议你可以参考下·选择Lite还是DL在于你觉得用Lite来创建本体是否已经够用。·选择DL还是Full在于你觉得是自动推理更重要还是精确表达更重要。DL使建模更灵活Full使建模更完整更精确、表达力更强。·注意:Protégé在编辑DL和Full的时候并没有什么明显区别尺度把握在你自己心目中。OWL本体的重要组成部分在早期的Protégé版本中你们会发现这样的术语ProtégéframesInstances,SlotsandClasses个重要的部分是:Instances、Slots、Classes其实就对应OWL本体中的如下三个部分它们是:Individuals个体。代表一个领域里面的对象。可以理解成一个类的实例(instancesofclasses)。比如在工人这么一个类中小李、老王、阿三等人就是一个一个的Individual。PropertiesProperties翻译为属性的意思。但是它的真正含义不和面向对象编程语言中的属性一样它的真正含义是个个体之间的双重联系或者可以认为是个Individuals之间的桥梁。比如hasChild连接了老李和他的孩子狗剩这个个体。另外Properties还有个比较重要的特性functionaltransitivesymmetric会在第四章详细介绍。Classes在OWL中Classes被翻译成个体的集合。当然它是一系列概念的语义表达和编程语言中的类非常相似有继承体系如果是OWLDL版本还能推理出一些继承关系后面会提到。ClassAxiom在OWL中类的公理是非常重要和关键的一部分它在验证一致性和推理中发挥着巨大的作用。ClassExpression类的表达非常为之丰富有并交补类还是匿名类等等后面章节将会重点讲述。打开披萨饼的例子 ·打开Protégé经过黑屏白字一番加载后出现了个选项的对话框。·我们选择打开一个网上已有的实例openOWLontologyfromURI·系统会给出我们它内建的一些书签我们选择pizzaowl那个本体。··选择之后要保证你的网路是OK的耐心等待一段时间后Protégé的界面就出来了··如果你发现你的Protégé版本和我说的不一样点第二章里面有下载。·我们看软件界面图最重要的几个版面就是ClassesObjectPropertiesDataPropertiesIndividuals。你们可以大致点进去看看。一进去的版面叫ActiveOntology是这个本体的统计信息。·这里例子让你熟悉下Protégé的界面下面我们开始自己构建本体。在创建本体的时候用的最多的当然是第一种方法NamedClass。这种Class也被称为PlainClass意思就是没有任何语义的类仅仅是一个标示。好了我们开始!·打开Protégé这次我们要选第一个选项了就是自己去创建本体。·接着要你输入URI就是世界上唯一的地址作为我这个本体的标示。这里我们填http:wwwcrabonecomontologiesorganizationowl注意这种规范的写法是很重要的。这是RDF的知识点了我就不啰嗦了有兴趣朋友看这里RDF入门教程·之后就选择这个本体我们本体存放的位置。·点击Finish之后我们实际上已经创建了一个空的本体了。而且Protégé已经为你创建了RDFXML你可以去看看你保存着的OWL文件表示形式为:<xmlversion="">  <!DOCTYPE rdf:RDF  <!ENTITY owl"http:wwwworgowl#">  <!ENTITY owl"http:wwwworgowl#">  <!ENTITY xsd"http:wwwworgXMLSchema#">  <!ENTITY owlxml"http:wwwworgowlxml#">  <!ENTITY rdfs"http:wwwworgrdfschema#">  <!ENTITY rdf"http:wwwworgrdfsyntaxns#">>  <rdf:RDF xmlns="http:wwwcrabonecomontologiesorganizationowl#"   xml:base="http:wwwcrabonecomontologiesorganizationowl"   xmlns:rdfs="http:wwwworgrdfschema#"   xmlns:owlxml="http:wwwworgowlxml#"   xmlns:owl="http:wwwworgowl#"   xmlns:xsd="http:wwwworgXMLSchema#"   xmlns:rdf="http:wwwworgrdfsyntaxns#"   xmlns:owl="http:wwwworgowl#">  <owl:Ontology rdf:about="">·<rdf:RDF>·进来之后我们选择Classes那个面板开始建立出下面这样的一棵树。·这棵树是由一些“兴趣爱好”这样的类组成的一个社团有什么样的兴趣爱好就将会是什么样的社团当然一个社团也可以有多个兴趣爱好。至于上图的操作我想就没必要讲了重点要讲述的是大家在建模的时候要分清什么是分类什么是继承。·继承:只要学过面向对象编程的朋友都熟悉这个概念在RDF和OWL里父类与子类的关系远远没有OOP里面那么玄乎我们来看WC上的语法描述:ifT(c,rdfs:subClassOf,c)T(x,rdf:type,c)thenT(x,rdf:type,c)意思就是如果C是C的子类并且有一个实体或者类是属于C的那么它也属于C。记住!推理机就只明白这点仅此这么简单!·分类:这里指的分类其实就是上面的继承一模一样!但是我们在建模的时候并没有把这些分类的类当作本体中的关键元素而是属于辅助类。辅助什么?辅助我们建模并不是辅助推理机有了这些辅助类可以使我们的类机构图更加清晰我这里举个例子见下图:我们可以看到这里多了几个类我们来看哪些是分类关系哪些是继承关系。这里的Thing下面有一个分类叫InterestInterest下面有个被继承的子类其中的NamedInterest就是典型的辅助类也可以称为分类类因为NonMusic和MusicAndFootball是一类兴趣爱好我们暂且称为复合型的爱好还有个就叫做纯种爱好或者原始爱好。而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中一个实例可以既是这个类的实例又是其他类的实例比如下图:上面有个集合这里的集合就好比类集合里面的小块块就是这个类的实例。从这个图里我们可以读出那几个类呢?A、B、A∩B、A∪B还有很多比如:非A、A和B的交集的补集等等我这里公式不打了这些都是一个个的类那么在上面这些类中的小块块就是属于这个类的个体也叫实例我们发现有些小方块可以属于很多类比如中间的那些既是属于A的又是属于B的也可以属于(A∪B)也可以属于……总之可能会属于很多类。在这里我们可以进行一个小小的总结了:OWL中的类和OOP中的类并不一样只有继承上来说是类似的但我们更应该把这些类当作集合来考虑!看到这里我想大家就应该明白DisjointClasses的意思了是的!为了声明个类没有交集!!只要个类没有了交集那么就不存在一个个体同时属于这个类的情况了这样推理机可以更加准确无误地表达出我们的意思了。·那么什么样的类需要去申明DisjointClasses呢?答案:同一层次的类!这里涉及到一个模式叫做UpperLevelOntology这个设计模式给了我们建模一个指导规范:将本体里面的类先按照层次划分然后将一个层次的类相互DisjointClasses。我们还是以我们的社团本体来举例:这里Music和Sport就是一个层次的我们将它们个相互DisjointClasses。Guitar和Hominca是一个层次的我们将它们个相互DisjointClasses。同理Basketball和Football也是一样要被DisjointClasses。这样设置好之后思路就非常明确了不会有一个兴趣爱好既是足球又是篮球的但是可以有一个个体的类型是(足球∪篮球)它的意思是这个个体要么是足球要么是篮球。不过没有一个个体的类型会是(足球∩篮球)因为(足球∩篮球)是空集。当我们定义一个个体的类型为(足球∩篮球)进行推理的时候会得到如下错误提示:OWLProperties代表了一种关系relationship在OWL里有种类型的Properties。一种叫ObjectProperties代表了individual到individual之间的一种关系。还有一种叫DatatypeProperties代表了individual和基本数据类型的关系有点像类的属性比如年龄、身高等。还有一种叫Annotationproperties是属于元数据数据的数据可以用来解释Classes、Individual、ObjectDatatypeProperties。下图以这种类型举个例子:··一般来说ObjectProperties较为常用。·OK!我们选择ObjectProperties面板创建一个Properties。如图:··这里有几点要说明:·命名约定和Classes一样虽然没有明文规范但是最好以一个单词小写开头后面一个单词首字母大写的方式书写。·其次OWL规范中Properties也有继承性比如hasMonther可能就是继承自hasParent自然如果个individual之间存在hasMonther关系则必定存在hasParent关系。·要注意在继承中不要把ObjectProperties和DatatypeProperties相互继承没有意义的。·更为复杂的创建属性方式我们参考了Pizza饼的例子:··看它们的命名就知道是反了一反这么做也是为了morepowerfullexpression比如小张是老张的儿子那么老张是小张的父亲他们的关系必定存在反关系是对应的··但这仅仅是我们人类看这命名之后推断出来的得让计算机也知道这些关系它们有这么一层含义。所以要用到inverseProperties了我们先选中hasBase然后点右边的inverseProperties旁边加号选择isBaseOf就可以了之后我们点isBaseOf会发现它的inverseProperties已经是hasBase了。Functional翻译成中文是有用的实用的其实应该翻译成函数的什么是函数就是不管参数是什么最后的答案都是唯一的不会变化的sin()只会等于但sin()也会等于当然和是等同的。FunctionalProperties就是这个意思比如、:小张最好的朋友是李四小张最好的朋友是小豆子如果"最好的朋友"这个Properties是Functional的那么可以推断李四和小豆子是等同的李四就是小豆子小豆子就是李四就好比和其实是一样的写法不同而已。下图表达的就是这个意思。·这个就不用我解释了吧?呵呵看图就明白意思了。传递性。A>BB>C则我们推理出A>C。如果一个属性有inverseProperties并且这个属性是传递性的那么那个inverseProperties也是传递性的这个在Protégé中没有自动完成但是推理机可以推理出来。千万记住!传递性和函数性不兼容!ifapropertyistransitivethenitcannotbefunctional想想看为什么?对称性对等性。别把这个和InverseProperties混合。我举个例子你就明白了。小张是老张儿子老张是小张父亲这个叫inverseproperties是个properties之间的对称关系是个individual和个properties在做文章。老张和老李是邻居老李和老张是邻居这个叫做properties的对等性是个property和个individual在做文章。反对称性反对等性。这个就很好理解了最简单的例子就是:小张是老张的儿子那么老张就不会是小张的儿子。如果有一天老张说:如果你敢!我就是当你儿子!这时计算机就会推断这个是反对称的是悖论则推断出小张不敢。自反性。如果一个individual将一个property指向自身那么这个properties就是自反的比如小张知道小李并且小张肯定知道小张自己。反自反性这个也很好理解比如”是儿子“这个属性就不会是自反的自己是自己的儿子显然是荒谬的。其实就是一个属性的类型和范围比如inti<i<那么int就是i的domainrange就是。用英文来形象的表达就是:Propertieslinkindividualsfromthedomaintoindividualsfromtherange在我们这个Organization的例子中我们拿hasInterest这个Property来说它的domain就是Organization它的Range就是Interest。注意!Properties的domainrange和Properties的大特性不一样大特性那是一种推理机制要用到的约束Constraint而domainrange是一种公理axiom。什么意思?约束是用来限制的可以用推理机制来验证如果限制出了问题就会推理出错。而公理总是对的推理要基于它们来推理。举个例子hasTopping的domain我们定义为Pizza如果在本体上发现hasTopping连接到了icecream那么是不会报错的OWL会认为icecream为Pizza的子类这在WC的文档上有详细的语义推理定义见下面的公式。除非……你在构建本体的时候强行定义了icecream和Pizza是相互Disjoint的见节。ifT(p,rdfs:domain,c)T(c,rdfs:subClassOf,c)thenT(p,rdfs:domain,c)·当我们再次回顾创建类的种方法时我们可曾反过来想想如果让我们来设计OWL语言我们会设计出几类创建类的方法?这块板是属于木头的类:木头(名词型)你是是很有理想的类:很有理想的(有:动词理想:名词属于动宾型)这个材料既是属于树胶又是属于塑料的类:树胶∩塑料(名词和名词的集合型)他是男人类:男人(名词型)它是吃肉的。(吃:动词肉:名词属于动宾型)他是有一颗赤诚热心的人类∩类类:人(名词型)类二:有一颗赤诚热心的(量词动宾型)这类皇冠都镶有No型钻石类:镶有No型钻石的(具体个体的动宾型)这批货物要么是可乐瓶要么是啤酒瓶枚举类:类和类二我们会发现上面的这些类的定义方法刚好对应于我们讲的种方法其中的动宾型、量词动宾型、具体个体的动宾型等就好比对应限制类其中的名词型好比对应命名类等等。我们来看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让它们归属到相应的类层次树下如图:接着我们来定义个ObjectProperty回到类视图我们点击GuitarOrg类之后为它构建个父类一个父类代表它有兴趣爱好在Guitar上另一个父类代表它得到学校器材的补助。·这个小节主要大致简单描述下类的几种定义帮助大家掌握一个体系。对于类的集合表达将在下面几个章节涉及到。 真正的类公理在OWL中只有个但是这个公理却起着至关重要的作用它们的组成关系如图所示。        SubClassOf在推理中有很重要的一块就是Classify能将所有的类与类之间的关系完整推理出来推理之前由开发人员定义的叫做被定义的类层次AssertedClasshierarchy由推理机自动推理之后的所得到的叫被推理的类层次InferredClasshierarchy(大家可以在Protege类视图里面找到这个概念Tab)。前者是开发者设计视图而后者是用户观看视图这在OWL中一直没有得到足够的重视。在开发建模阶段SubClassOf多用来分类而不是建立子类用比如:先建立“Type”这么一个命名类接着建立三个它的子类叫TypeATypeBTypeC这个子类其实并不是真正意义它的子类而是在它这个范围内为了建模逻辑的简便性。经过推理后这个所谓的父子关系将不会被用户所关心。        EquivalentClasses和上面的SubClassOf其实是一个层次的公理SubClassOf表示了类与类之间的层次关系上下所属关系而EquivalentClasses表示了类与类之间的等价关系。这者有所不同的是SubClassOf是目运算由subClass和superClass组成EquivalentClasses则是目以上的多目运算。        DisjointClasses是起到限制性的作用将类与类从一个概念上完全隔离DisjointClasses(CECEn)CEi,≤i≤n,里面的类相互之间分离也就是说没有一个个体同时属于CEi和CEj(i≠j)。        下面这个表格是个类公理的描述逻辑是属于Tbox的内容理解起来并不难供大家参考这是推理机里面的规则。IFTHENT(c,rdfs:subClassOf,c)T(x,rdf:type,c)T(x,rdf:type,c)T(c,owl:equivalentClass,c)T(x,rdf:type,c)T(x,rdf:type,c)T(c,owl:equivalentClass,c)T(x,rdf:type,c)T(x,rdf:type,c)T(c,owl:disjointClasses,c)T(x,rdf:type,c)T(x,rdf:type,c)falseSubClassOf作为目运算在实际的建模过程中一般有种用途。第一种用途就是OWL官方文档的使用场景如果定义SubClassOf(CECE)则代表CE是CE的子类也可以大致理解为CE比CE描述的更为细致深入。但是这种定义方式是显式的定义用公理强加给本体让其者产生关系这只能用在已知的公认的关系上比如:女人是人的子类这些平时就被冠名为公理的事物在建模中可以用这种显式定义的方式定义。然而比如:吉他协会是优秀协会的子类这种父子关系在现实生活中并不能称为公理只是有些地方适用而已这时就不能用SubClassOf显式地去定义它们的父子关系而应该通过推理机制来获取这些隐含的语义下文将会对此讲述。第二个用途作为辅助类。在本体建模的时候往往让一系列的类去继承于一个辅助类但是这个继承关系并不是真正意义的父子关系相反它们没有任何的关系可能只是一个包含关系。比如:在owl:Thing下面建立个子类分别称作NamedOrganization和AbstractOrganization然后创建SportOrganization和MusicOrganization这个类让它们归属于NamedOrganization。之后创建NoMusicAndSportOrg和NoSportAndMusicOrg这个类让它们归属于AbstractOrganization。可以发现这里用公理去定义了它们的父子关系但是这种公理并非公认的公理而且它们之间也不存在父子关系没有继承任何的性质和概念最合理的解释就是进行了一个分类。在建模中往往会涉及到大量的类如果不对这些类进行一个分类则很容易遗漏一些需求信息还会给后期的维护带来麻烦。因此辅助类在建模中起到了非常关键的作用但是OWL甚至OWL却没有总体与部分的语义关键字因此建模设计者们只能借用SubClassOf来模拟总体与部分的关系。这个用途虽然没有用到任何的语义知识点但是能给本体建模者们提供一个工具使建模更加清晰明了。第三个用途是和推理密切相关的可以用来表达类的很多性质。比如:有足球爱好的享受学校体育津贴的规模是中等的社团该社团现在有个性质第一它是有足球爱好的第二它是享受学校体育紧贴的第三它是中等规模的。如果某个社团现在需要享有这个性质那么就应该去继承个匿名类这个匿名类就是前面所提到的“用限制对象属性的客体来表达类的概念”分别代表前面所提到的个性质用UML类图来表达即为:在图中这个社团继承了个匿名类分别代表了它的个性质其中“hasInterestsomeFootball”是它的第一个性质hasInterest是一个对象属性some关键字就是类表达能力里面描述的ObjectSomeValuesFrom存在限制Football是一种兴趣爱好类这种动宾结构式的表达常常用在匿名类中然后让其它类去继承以此来达到表现性质的效果。但是这里的匿名类“hasInterestsomeFootball”是内部类也即“某社团”内部的父类该父类无法被其他类共享其他类也无法去继承它。第三个用法总结起来有如下几个步骤:(提取出一个类的性质将每个性质写成动宾结构。对每个动宾结构提取相应的动词对应对象属性提取相应的宾语对应对象属性的客体。((将每组动宾结构写成匿名类的方式然后作为该类的父类。完成如上步骤后该类就具有了相应的性质这种性质是具有语义信息的能够被推理机识别、读懂、理解、推理。同时这些性质就像对外的接口能被其他类识别以此作为桥梁和自身产生关联比如推理出存在隐含的父子关系。公理EquivalentClasses(CECEn)表达了这样一个概念对于任意一个CEi≤i≤n它们之间都是语义对等的这是官方定义的多元原语然而在实际用途中常见的是二目运算(当然是属于多目运算范围内的)EquivalentClasses(CECE)其实就等价于:SubClassOf(CECE)SubClassOf(CECE)这种等价关系相当于对SubClassOf公理进行了扩展SubClassOf仅仅能作为一种必要条件而EquivalentClasses能作为一种充分条件。例如:类A是一个匿名类的子类这个匿名类带有B性质(如上一节所述)那么凡是A的子类或者A的实例或者个体都含有性质B但是凡是含有性质B的类却不一定是属于类A的只能正向推导却无法逆向反推。EquivalentClasses刚好弥补了这个缺陷使得推理机可以反向推导回来形成了一个充分必要条件。文献中将被EquivalentClasses所连接的类描述为DefinedClass将SubClassOf所连接的类描述为PrimitiveClass。这里的意思是一个类作为一个性质匿名类的等价类它就是一个DefinedClass定义的类一个类作为一个性质匿名类的子类它就是一个PrimitiveClass原始的类即:有待推理的类。文献的作者在这里其实想要表达的意思就是SubClassOf用来等待被推理EquivalentClasses用来驱动推理。为了更好表述清楚这个概念用下图作为一个例子来阐述。上图所展示的是一个推理过程在该推理过程之前有个没有任何关联的类ClassA和ClassB都具有同一个性质该性质就是上图的匿名类。而AbstractClass则是定义了与这个匿名类等价。需要注意的是这里其实有个匿名类每个匿名类都被包含在它们的主类中但推理机会判断这些匿名类是否指的是同一个概念图其实是一种推理机的视角来看待问题通过一个匿名类将者产生了关联。AbstractClass这里的语义信息为:只要某个类具有这个匿名类的性质则它就是AbstractClass的子类。经过推理可以得到图的下半部分该部分阐述了者的父子继承关系是推理之后的视图。这种通过推理得到的父子关系称为隐式的SubClassOf它包含在本体的语义信息中与本体设计师显式定义的公理无关这种形式其实大大增大了本体的可维护性比如:假设用显式的SubClassOf来定义它们的父子关系接着删除了ClassA那么不仅要删除ClassA这个概念还要将它和AbstractClass的关联给删除而通过推理得到的继承关系则有推理机来维护只需要去删除ClassA本身即可它和AbstractClass的关系是通过推理后产生的无需手工删除。通过上面的分析其实可以看出EquivalentClasses公理可以起到桥梁作用它所等价的性质会被推理机利用来寻找其他的性质只要有类具有这样的性质接口(见SubClassOf用途三)它们就会产生关联。更为巧妙的是如果让DefinedClass去继承某一个性质而这个性质又能被其他DefinedClass探测到从而产生关联那就可以推断出很深层次的语义关系了如下图所示。上图对前面的例子又做了一个延伸这里AbstractClass起到了明细的桥梁作用将本来连性质上都没有任何关联的个类(SuperClass、ConcreteClassA和ConcreteClassB)赋予了父子继承关系。这其中EquivalentClasses起到了关键的连接作用为推理机提供了语义线索这种模式其实就是后面章节要阐述的ODPsIfThen结构。disjointClasses在描述逻辑中清晰地表明了这样一个意思:对于表达式disjointClasses(C,C,C…)不存在一个个体同时属于(C,C,C…)当中的任意个或多个类也即:(C,C,C…)之间的交集为空。文献的作者AlanRector在那场报告中指出disjointClasses是一种不被大家熟知的表达方式。不管在UML、面向对象编程语言以及其他一些所熟悉的技术都不用显式去定义个类之间没有交集。比如在JAVA中类就是类个类不会产生关系除非它们是父子关系或者是实现类和接口的关系没有一个实例既是属于A类又是属于B类的。但是在OWL世界中这些陈规旧条变得不通用如果个类没有显式去定义它们之间的disjointClasses关系那么就会存在一个个体它同时属于这个类而且是这是被推理机默认的。因此如果要让推理机明白不会存在一个个体同时属于个类那么就必须把这个类定义成disjointClasses关系。那么在具体应用中不见得将所有本体中的类都定义成disjointClasses关系那显然是不符合逻辑的这就提出了一种叫做UpperLevelOntology的ODPs。这个ODPs对如何使用disjointClasses公理提出了很好的一种应用场景。它的建模过程如下:首先对本体进行一个层次的划分比如:兴趣爱好下面分为音乐兴趣爱好和球类兴趣爱好音乐兴趣爱好可以衍生出吉他爱好、口琴爱好、钢琴爱好等等球类兴趣爱好可以衍生出足球爱好、篮球爱好、棒球爱好等等。这里音乐兴趣爱好和球类兴趣爱好就是同一个层次吉他爱好、口琴爱好、钢琴爱好又是属于另一个层次同样足球爱好、篮球爱好、棒球爱好也是单独属于一个层次。接着对每个层次的类进行disjointClasses公理应用就上面这个例子来说disjointClasses公理总共应用了次每个层次各一次。但是由于这些层次之间存在一个继承关系层次与层次之间其实已经隐式地划分开来了。比如这里足球爱好和吉他爱好是disjointClasses关系尽管没有显式定义它们个的disjointClasses关系。定义disjointClasses公理的首要功能就是使得推理机能够顺利推理出补类的关系。依然以上面这些爱好类为例兴趣爱好下面分为音乐兴趣爱好和球类兴趣爱好这其实就是向推理机表明兴趣爱好=音乐兴趣爱好∪球类兴趣爱好并且音乐兴趣爱好∩球类兴趣爱好=。这样容易推理出非球类兴趣爱好就是音乐兴趣爱好。如果没有显式定义它们之间的disjointClasses关系是无法进行这些推理的。这在后续的ODPs中用到非常多会逐渐成为一种规范在这种规范下定义出来的本体是语义精确的。上图中音乐兴趣爱好和球类兴趣爱好互为disjointClasses足球爱好和篮球爱好互为disjointClasses吉他爱好和口琴爱好互为disjointClasses有了这个disjointClasses就足够了。比如:非吉他爱好会首先推断是口琴爱好还会推断出是球类兴趣爱好进而推断出足球爱好和篮球爱好这些都是属于非吉他爱好的。这个推导过程很简单首先按照上面的方法都将这些兴趣爱好建好记住个disjointClasses关系别漏了看上面的那副图。接着我们创建一个测试类出来叫做notGuitar。如图:选择notGuitar然后点旁边的addequivalentClass在跳出的框中写上notGuitar注意大小写只有写对后那个确定按钮才会出来的如果这个框跳出不来那就说明你下了一个有bug的版本我是遇到过的去换个版本吧或者我提供的下载地址也可以的。最后选择推理机。推理出最终结果如下可以看到notGuitar类自动成为了它们的父类它们也的确不是Guitar类。

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

评分:

/27

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利