这个模式是从继承的角度来描述的,并非我们所熟悉的因果关系。它不能描述例如“如果今天下雨,我们不去春游”这样的语义,但它能描述例如“如果这个社团的兴趣是足球,则它就是球类社团”。前者不能用OWL来描述语义是因为下雨和春游没有内在的关联,后者能用OWL来描述语义是因为足球和球类社团存在着关系。从一些案例中,总结出If-Then结构能将某些类用前因后果联系起来,但是必须的一个条件是它们之间存在着一定的关联。我们来看UML结构图:
从图中我们可以总结出这个模式中含有2个公理,1个表达方式,第一个公理是EqualentClasses,意思是将一个命名类与一个匿名类等价,模拟其If条件,这之中用到了表达方式someValuesFrom,意思为只要这个命名类有了这个条件后,即会如何。第二个公理是SubClassOf,描述了Then之后的条件,也运用到了someValuesFrom。在这个模式中有一个命名类if_then_class,这个类属于中间过渡类,在这个设计模式之后的类或许根本都不知道这样的类存在,但却在被它的If-Then结构引导着。
我们设计出了这样一个应用场景:在一个学校中,只要是球类社团,就有体育经济补助,反过来说,只要一个社团它是球类社团,它不自觉地就成为了体育经济补助类社团。
我们首先把if_then_class构造出来,先命名If_BallOrg_Then_SportSubsidyOrg,之后让它去继承一个匿名类,这个匿名类就是Then之后的结果,最后利用EquivalentClasses公理和另外一个匿名类等价,表示了If 的条件:
- <SubClassOf>
- <OWLClass URI="&organizations;If_BallOrg_Then_SportSubsidyOrg"/>
- <OWLClass URI="&organizations;Organization"/>
- </SubClassOf>
- <SubClassOf>
- <OWLClass URI="&organizations;If_BallOrg_Then_SportSubsidyOrg"/>
- <ObjectSomeValuesFrom>
- <ObjectProperty URI="&organizations;HasSubsidy"/>
- <OWLClass URI="&organizations;SportSubsidy"/>
- </ObjectSomeValuesFrom>
- </SubClassOf>
- <EquivalentClasses>
- <OWLClass URI="&organizations;If_BallOrg_Then_SportSubsidyOrg"/>
- <ObjectSomeValuesFrom>
- <ObjectProperty URI="&organizations;hasInterest"/>
- <OWLClass URI="&organizations;BallSport"/>
- </ObjectSomeValuesFrom>
- </EquivalentClasses>
完成了这个if_then_class的定义后,我们来加入应用元素进行测试。第一个类是一个足球社团FootballOrg,让它满足if_then_class中的If条件,值得注意的是FootballOrg对if_then_class一无所知,它根本不知道有这样一个条件性的类存在,就好比每个网站并不知道自己的排名,自己也无法排名,但专业的排名机构会对其排名。第二个类是体育经济补助类社团SportSubsidyOrg,这个类同样也不知道if_then_class,更不会知道FootballOrg。
- <SubClassOf>
- <OWLClass URI="&organizations;FootballOrg"/>
- <OWLClass URI="&organizations;Organization"/>
- </SubClassOf>
- <SubClassOf>
- <OWLClass URI="&organizations;FootballOrg"/>
- <ObjectSomeValuesFrom>
- <ObjectProperty URI="&organizations;hasInterest"/>
- <OWLClass URI="&organizations;Football"/>
- </ObjectSomeValuesFrom>
- </SubClassOf>
-
- <SubClassOf>
- <OWLClass URI="&organizations;SportSubsidyOrg"/>
- <OWLClass URI="&organizations;Organization"/>
- </SubClassOf>
- <EquivalentClasses>
- <OWLClass URI="&organizations;SportSubsidyOrg"/>
- <ObjectSomeValuesFrom>
- <ObjectProperty URI="&organizations;HasSubsidy"/>
- <OWLClass URI="&organizations;SportSubsidy"/>
- </ObjectSomeValuesFrom>
- </EquivalentClasses>
FootballOrg继承了一个匿名类,说明这个社团有一些兴趣爱好是在足球上的。SportSubsidyOrg等价一个类,说明了凡是有体育津贴的,一律是属于SportSubsidyOrg类的。当推理完成后,这3个类发生了关系。首先,If_BallOrg_Then_SportSubsidyOrg由于已经继承了一个匿名类,这个匿名类是有体育津贴的,因此If_BallOrg_Then_SportSubsidyOrg被Classify到了SportSubsidyOrg下属。其次,FootballOrg继承了一个匿名类,这个匿名类是有兴趣爱好足球的,因此FootballOrg被Classify到了If_BallOrg_Then_SportSubsidyOrg下属。由于If_BallOrg_Then_SportSubsidyOrg这座桥的原因,现在FootballOrg被归属到了SportSubsidyOrg类里面,即:FootballOrg在毫不知情的情况下,成为了SportSubsidyOrg的子类。我们在总结中,发现了这3个类的关联都是由于EquivalentClasses这个公理起到了连接作用,将本来并不认识的2个类,通过类的属性将它们关联了起来,从来形成了一张语义大网。if_then_class在这个模式中也起到了这种作用。
本体建模设计模式ODPS
if-then, ODPS, ontology design patterns, ontology model
问题提出
和封闭性类似,有一类问题值得我们去思考。例如:一个学校社团的规模,小于10人的为小型,等于10人到小于30人的为中型,大于等于30人的为大型。那么对于规模的子类有小型、中性、大型三种,并且仅仅只有这么三种,不允许有其它规模类型的存在,小型、中型、大型直接没有交集。
目标
为了某些特性的值有效准确建模。
结构图


该设计模式在实际应用中被广泛应用,使语义更为精确。
本体建模设计模式ODPS
ODPS, ontology design patterns, ontology model, Value Partition
问题提出
OWL有些时候与我们的本能思维模式有些背离,因为我们不是生活在一个逻辑的世界里,不可能任何事物都能准确定义的。比如这样一个例子:肉食动物,草食动物,不偏食动物。
按照我们的思维模式,草食动物是要吃一些草的
- <owl:Class rdf:about="#carnivore">
- <owl:equivalentClass>
- <owl:Restriction>
- <owl:onProperty rdf:resource="#eats"/>
- <owl:someValuesFrom rdf:resource="#meat"/>
- </owl:Restriction>
- </owl:equivalentClass>
- <rdfs:subClassOf rdf:resource="#animal"/>
- </owl:Class>
按照我们的思维模式,肉食性动物是要吃一些肉的
- <owl:Class rdf:about="#herbivore">
- <owl:equivalentClass>
- <owl:Restriction>
- <owl:onProperty rdf:resource="#eats"/>
- <owl:someValuesFrom rdf:resource="#veg"/>
- </owl:Restriction>
- </owl:equivalentClass>
- <rdfs:subClassOf rdf:resource="#animal"/>
- </owl:Class>
按照我们的思维模式,不偏食性动物既是吃肉也是吃草的
- <owl:Class rdf:about="#omnivore">
- <owl:equivalentClass>
- <owl:Class>
- <owl:intersectionOf rdf:parseType="Collection">
- <owl:Restriction>
- <owl:onProperty rdf:resource="#eats"/>
- <owl:someValuesFrom rdf:resource="#meat"/>
- </owl:Restriction>
- <owl:Restriction>
- <owl:onProperty rdf:resource="#eats"/>
- <owl:someValuesFrom rdf:resource="#veg"/>
- </owl:Restriction>
- </owl:intersectionOf>
- </owl:Class>
- </owl:equivalentClass>
- <rdfs:subClassOf rdf:resource="#animal"/>
- </owl:Class>
如果我们这样定义之后,经过推理机的整理,如下图所示:

我们发现,omnivore成为了herbivore和carnivore的子类,而实际上,这3各类应该各自不相干,没有谁是谁的子类那种关系,它们是平行的。就这是因为在OWL的推理世界中,有一种原则叫Open World Reasoning,在这种原则下,肉食性动物也会吃草,因为eats这个object property仅仅定义了someValueFrom meat,推理机认为只要有一些meat就可以了,但没有排他性,即也可以吃其他类型的食物。在这里例子里面,当然omnivore会成为carnivore的子类。
目标
精确表达OWL一些类直接的从属关系,达到无二义性。这就是封闭性设计模式。
实现
在原有基础上,分别给carnivore和herbivore加上
注意
这里容易搞混的是allValuesFrom的准确含义,它所限制的是object property的范围,而没有限制object property本身。这里的allValuesFrom指要么没有,要么就是指定的类的实例,而someValuesFrom是指必须有一个或者一个以上指定的类的实例,但同时有其他类的实例也被允许。因此,这里少了这2个限制都不行。
本体建模设计模式ODPS
Closure, ODPS, ontology design patterns, ontology model
问题提出
有些本体所描述的类具有大量的父类,比如“女大学生”这个类,它可以有这些父类:学生,大学生,女人,人,参加过高考的人,不同于男人的人,等等描述逻辑的表达。如果所有的这些类都由我们直接定义,会产生2个问题:
维护困难。当我们要删除一个类别的时候,比如删除“大学生”这个类,那么下面的子类“女大学生”也要做相应的更改。又或者,我们添加了一个新的类,相应要添加其子类(如果存在)。这些人工完成的任务不仅效率低下,而且极易出错。
失去语义的功能。在这种父子类的建模方法下,语义信息被隐含地表达了,但是没有明显地体现出来。推理机仅仅知道我们人工定义了父类与子类的父子关系,但是它无法知道为何它们是父子关系,它无法通过语义去推理。
目标
用restrictions限制类来表达父子关系,而不要用 class-subclass这样的形式定义。
首先,我们建立如下一些类

总共有3个大类,社团类型,其他信息,电子商务社团。在社团类型里面有3个类,分别为:大学社团,优秀社团,技术社团。在其他信息里有3个类:领域(内有技术子类),大学,奖励。
我们的推理模式为:有大学归属的社团称为大学社团,获奖3次以上的称为优秀社团,研究领域是技术的称为技术社团。
经过推理,可以表达成如下概念

可见,建模的时候,我们完全没有定义电子商务社团有上面3个父类,但是经过推理、经过OWL的语义推理,又能清晰展现出我们所需要的逻辑结构。更令人欣慰的是,这时不管我们删除电子商务社团还是其中的某个社团类别,都不会将影响扩展。
URL
http://www.crabone.com/ontologies/odps/Normalisation.owl
本体建模设计模式ODPS
Normalisation, ODPS, ontology design patterns, ontology model, Untangling