Ontology Design Patterns for Semantic Web Content
- 格式:pdf
- 大小:512.63 KB
- 文档页数:15
关于ontology 的讨论董云卫:你问道关于ontology, 直译是哲学上的存在论或本体论,现在用于系统的概念模型很热。
大体意思是说,客观世界是由很多元素组成,而元素之间又具有各种联系,把这些元素和关系画出来就是一个ontology。
这里有几篇文章可供参考,都是2002年国际会议的文章,比较新。
1,25030001 Conceptual Modeling and Ontology: Possibilities andPitfalls2,25030003 An Ontology for m-Business Models3, 25030012 Ontology-Driven Conceptual Modeling: Advanced Concepts4, 25120174 DAML+OIL:A Reason-Able Web Ontology Language郝克刚。
2003年1月15日Sent: Wednesday, January 15, 2003 8:49 PMSubject: RE: 关于ontology郝老师及各位:The 10th international human-computer interaction conference (2003)刚接受了我一篇文章:Ontology-based Conceptual Modeling for InteractionDesign. 创新和质量都得了满分:-) 事实上,其内容是讨论软件系统的概念建模的,但和建模交互有一定关系。
我和董云卫争论过2小时,但他不相信我的。
本体论的常用定义是:分享概念化的形式、显式规约(但有争论),其内容包括一个概念分类,关系及公理。
本体论一般是静态的,不包括动态概念。
换言之,本体论描述的是说明式知识,不包括过程序知识,因为本体论的目的是表示,不是使用知识。
所谓分享概念化指是在一个问题域中现象的抽象模型,其中概念是公认的,形式化指机器可处理性,显式指概念的类型和使用限制都是明确定义的(一般得有一个meta-ontology或叫ontology assumptions定义概念类型和类型之间的关系,一个具体的概念模型中的概念及关系是它的实例)。
第43卷第9期2009年9月浙 江 大 学 学 报(工学版)Journal of Zhejiang U niver sity (Eng ineering Science)Vol.43No.9Sep.2009收稿日期:2008-06-02.浙江大学学报(工学版)网址:w w w.journals.z /eng基金项目:国家 十一五 重大科技攻关资助项目(2001BA101A08 03).作者简介:欧阳杨(1982-),女,湖南长沙人,博士生,从事教育语义网和本体建模研究.E mail:oyy.lily@gm 通信联系人:朱淼良,男,教授,博导.E mail:zhu m@DOI:10.3785/j.issn.1008 973X.2009.09.008教育语义网中的知识领域本体建模欧阳杨,陈宇峰,陈溪源,朱淼良(浙江大学计算机科学与技术学院,浙江杭州310027)摘 要:针对多学科领域知识本体构建难度大和难以普及的问题,提出了适用于教育领域的基于知识工程的本体建模方法,通过确定领域知识的范围,对领域知识进行概念和术语的提取,然后基于分类后的概念集定义层次结构和构建关系模型,构建出完整的本体结构模型.该方法不仅简化了本体建模的过程,还可以使学科领域专家能够独立地开发出学科课程相关的本体.以 统一建模语言(U M L) 课程为实例,示范了课程本体开发的过程,验证了上述学科领域知识本体开发方法的可行性.关键词:语义网;本体;领域知识;本体建模中图分类号:T O 182;T P 393 文献标志码:A 文章编号:1008-973X(2009)09-1591-06Ontology modeling of domain knowledge in semantic learning WebOU YANG Yang,CHEN Yu feng ,CH EN Xi yuan,ZHU M iao liang(College of Comp uter S cience and T echnology ,Zhej iang Univer sity ,H angz ho u 310027,China)Abstract:A methodo logy of onto logy modeling on educational do main based on know ledge eng ineering w as pro posed to so lve the pr oblem of difficulty to construct domain know ledge ontolog y fo r multi subjects.A com plete ontolog y constr uctional model w as built by defining domain know ledge scope,ex tracting concepts fro m dom ain know ledge,defining taxo nom y and co nstructing relationship mo del based on concepts agg re g ation.The process to build domain o ntolo gy w as sim plified and domain ex perts w ere enabled to develop course onto logy auto no mously.A use case of onto logy m odeling for unified mo deling language (UM L)course w as introduced and discussed,and the feasibility of the m ethodo logy w as ev aluated.Key words:sem antic Web;onto logy ;domain kno w ledge;onto logy mo deling Bemers Lee 等[1]提出了语义Web (sem antic Web)的概念, 语义Web 是现有Web 的扩展,信息被赋予定义良好的含义,更便于计算机和人的协同. 语义Web 实现了机器自动处理信息,提供了诸如信息代理、检索代理、信息过滤等智能服务[2].语义Web 实现中最为重要的关键技术是本体(onto lo g y),本体为语义Web 提供了一套共享的术语和信息表示结构,多数据源上的异构信息通过共享的术语和信息表示结构可以成为同构的信息,从而使语义网上的通讯和互操作成为可能.Stutt 等[3]首次提出了教育语义Web (semanticlearning Web)的概念,指出在教育语义Web 环境中,利用本体将原有教育资源中的概念描述抽象成领域知识是一个核心任务.在给定的知识领域中,本体定义了描述和代表该领域知识的词汇,包括了可被计算机识别的基本概念的定义以及它们之间的关系[4].本体技术被越来越多的学者应用于教育技术领域[5 6],Sampson 等[7]提到本体支持从由多个学科领域本体表示的知识域中构建学习内容,本体中对知识概念和关系的描述可以使得学习内容的制定更加规范和清晰,学习内容通过本体中的学习主题、指令以及用户知识域进行描述后可以达到被重用的目的.本文研究了本体建设的研究现状,针对教育领域学科知识的特点,提出了学科知识本体的开发方法,并给出了统一建模语言(UML)课程的本体构建示例.1 本体的概念和方法论1.1 本体的概念本体的概念还没有一个统一的定义,在人工智能界,Neches等[2]最早给出了本体定义,将本体定义为 给出构成相关领域词汇的基本术语和关系,以及利用这些术语和关系构成的规定这些词汇外延的规则的定义 .Neches等[2]认为: 本体定义了组成主题领域的词汇表的基本术语及其关系,以及结合这些术语和关系来定义词汇表外延的规则. 本体是构建知识领域的重要组成部分,是对某领域应用本体论方法分析、建模的结果,即把现实世界中的某个领域抽象为一组概念及概念之间关系的规范化描述,勾画出这一领域的基本知识体系,为领域知识的描述提供术语.本体定义了描述和象征某个知识领域的词汇,它不仅以机器可读的形式定义了该领域中的基本概念,同时还涵盖了这些概念之间的关系模型.而一个领域本体通常定义了一个特殊主题的概念及其之间的关系,而不仅仅是一些通用的普通概念.Guarino[8]通过领域依赖度将本体细分为顶级(toplev el)、领域(domain)、任务(task)和应用(ap plication)本体4类:1)顶级本体,描述的是最普通的概念及概念之间的关系,如空间、时间、事件、行为等,与具体的应用无关,其他种类的本体都是该类本体的特例.2)领域本体,描述的是特定领域(例如医学、汽车、食品等)中的概念及概念之间的关系.3)任务本体,描述的是特定任务或行为中的概念及概念之间的关系.4)应用本体,描述的是依赖于特定领域和任务的概念及概念之间的关系.本文研究的教育领域学科本体属于领域本体的范畴.1.2 本体建设的方法论目前已经开发出了很多本体,出于对各自问题域和具体工程的考虑,构造本体的过程各不相同.很多研究人员出于指导人们构造本体的目的,提出了有益于构造本体的标准,例如Guar ino[8]根据研究项目T OVE(To ronto virtual enter prise)总结出来的TOVE本体开发方法.该方法的目的是构造企业本体,主要为企业的应用软件提供共享的术语,同时用一阶谓词逻辑为每个术语进行定义,用一组Prolog公理来实现本体语义约束,它还定义了一套符号对术语和概念进行图形化的描述.Lo pez等[9]提出了M ETH ONT OLOGY开发方法,与软件工程的开发方法类似,将本体开发过程分为规格说明、知识获取、概念化、集成、实现、评价和形成文档等步骤.Knig ht等[10]提出了KACTU S方法开发本体,采用工程的模式通过概念建模语言(conceptual m odeling language,CML)表达,构造支持产品知识重用的本体,支持计算机集成制造方法和知识工程方法的集成.由ISI信息科学研究所自然语言组开发的SEN SU S本体[11]主要为机器翻译提供广泛的概念结构,目前主要用于军事领域的本体中. U scho ld等[12]提出了骨架法,该方法建立在企业本体基础之上,是相关企业间术语和定义的集合,只提供开发本体的指导方针.本体的开发需要领域专家和计算机科学领域的本体工程师的共同参与,这使得本体开发难度加大,难以普及.知识的多样化导致不同学科领域的知识(包括概念、概念之间的关系等)各有特点,而同一领域的知识又存在不同的粒度和难度层次,因此如何在不同学科领域本体的构建中找到高效可行的建模方法是研究的重点.2 学科知识本体开发方法论本体的结构(onto logy structure)是一个五元组O:={C,R,H C,R el,A O}.其中,C和R是两个不相交的集合,C中的元素称为概念(concept),R中的元素称为关系(relation);H C表示概念层次,即概念间的分类关系(taxonomy relation);R el表示概念间的非分类关系(non tax onomy relation);A O表示本体公理(axiom)[13].从本体的结构可以看出,本体学习的任务包括概念的获取、概念间关系(包括分类关系和非分类关系)的获取和公理的获取.这3种本体学习对象构成了从简单到复杂的层次.从本体结构的定义可以看到,概念和关系是最基本的两个元素,因此构建本体最重要的工作是从知识领域中提取出概念,对概念进行层次划分,构建概念间的关系模型.Noy等[14]提出了知识工程方法,该方法通过7个步骤完成本体的开发:1)确定本体的领域范围和使用目的;2)重用已有的本体;3)穷举该本体中的重要词汇;4)定义类和类的层次结构;5)定义类的属性;6)定义类属性的值域;7)创建实例.在该方法中, 4)~6)通常需要同时进行,相辅相成,如何将已有的词汇区分是否是类或者类的属性是一项复杂的工作.基于本体的结构,本文在知识工程方法的基础上1592浙 江 大 学 学 报(工学版) 第43卷提出了关系模型的概念,增加了构建关系模型的步骤,通过构建关系模型可以更加方便地构建知识空间拓扑结构.2.1 确定本体的知识领域开发本体的第一步是要确定该本体的领域范围和使用目的,可以通过了解本体涵盖的领域,如何使用以及使用对象来确定要创建的本体的学科分类、应用背景、使用对象.例如计算机学科领域,IEEE/ ACM公布了Com puting Cur ricula研究成果CC2001[15],该报告涵盖了计算科学领域的本科教学课程示范结构.在CC2001中,计算机学科被划分为14个子领域:离散结构、程序设计原理、算法与数据结构、程序设计基础、操作系统、人机交互、图形学、智能系统、信息系统,网络计算、软件工程、计算科学、社会和职业问题.对于同一个教学主题,有不同的应用背景和使用对象,在CC2001中介绍了3种教学难度:介绍性(intr oductor y)、中等(interme dia)、高级(adv anced),分别面对不同年级不同学习能力的学生.2.2 重用已经存在的本体在开发新的本体前,可以从目前在进行或者已完成的相关工作中学习,并且从已有的资源中进行提取和扩充[14].在已有的基础上进行改进比创建新的本体要容易的多.当我们的系统需要同其他已经使用某一特定本体或者词汇库的应用程序进行交互时,重用已有的本体就变得非常重要.目前在网络上已经有不少成熟的本体资源可以使用,例如Onto lingua本体库、DAM L本体库、Wo rdNet,同时还有很多公开的商业性质的本体资源,例如UNSPSC、RosettaNet、DMOZ等.2.3 领域知识概念提取,定义层次结构和关系模型领域知识概念提取主要列出本领域中最基本、最有代表性的术语,那些需要被用户了解和学习的概念以及需要注释和解释的词汇.需要指出的是,在这个步骤中只需要穷举出所有可能的术语,不需要去考虑它们的概念是否重叠,也不要考虑它们之间的关系和属性.接下来对提取的概念按照分类学的观点进行组织,形成系统的分类结构.构建分类结构要遵循一些基本的原则,如:满足分类学基本原则,明确父概念和兄弟概念的区别与联系,满足必要的语义约束等[16].定义概念的层级结构有许多方法[10],最常用的有2种:1)自上而下的方法.该方法从定义知识领域中最常规的概念开始,接着定义更为特殊的概念.2)自下而上的方法.该方法从最详细最底层的概念开始定义,即层次结构的叶子部分,然后将这部分的概念组合成更概括更上层的概念.然后定义概念间的关系模型,包括分类关系和非分类关系.通过定义关系模型,能将更多的概念联系起来,扩展知识空间的拓扑结构.将各个步骤结合起来,定义完整的本体结构模型,包括定义类的属性、取值范围、类之间的关联等.2.4 分析、改进和评价改进事实上是构建过程的一个组成部分,在构建的过程中不断改进原有的结构,在不断改进的过程中构建起整体的结构.改进的方法包括合并、编辑及自然语言处理的一些方法.在改进的过程中要注意分类系统整体的一致性.对本体进行分析和评价,确定本体结构是否能准确反映事物的本质和联系,本体系统是否一致、相对完备、无冗余等.分析评价与改进共同构成了本体的维护过程.3 U M L课程本体开发示例3.1 本体的领域和范围本文选取UM L作为范例.U ML是一种建模语言,是用来对面向对象开发系统的产品进行说明、可视化和编制文档的方法.确定领域后,需要定义该本体的使用对象.在CC2001中定义了课程的3种层次:introductory、interm ediate、advanced.开发计算机相关的介绍性课程主要是要完成以下几个目标:1)给学生介绍一系列相关的计算机科学基本概念;2)帮助学生在基本概念的基础上构建认知模型;3)鼓励学生学习相关的技术将概念化的知识模型运用起来.本研究开发的UM L本体面向的是基础性介绍课程.确定好本体的领域和范围后,需要选取建设本体的知识来源,本文选取了多本U ML经典书籍作为知识获取来源,例如Ivar Jacobson、Grady Booch、Jam es Rum baugh3位U ML创始人编写的 统一软件开发过程 ,M artin Fow ler编写的 U ML精粹:标准对象建模语言简明指南 (UML distilled:a br ief guide to the standard obj ect modeling lan guage),Jam es Rum baugh等编著的 UM L参考手册 UM L与面向对象设计影印丛书 .选取经典书籍作为课程本体开发的来源有许多可取之处[17],作为入门和介绍性的教材是一门课程起步的良好选择,它涵盖了该领域基础的概念和相关知识,提供了基础和详尽的解释.本文的目的是给出建设课程本体1593第9期欧阳杨,等:教育语义网中的知识领域本体建模的示范,不使用已经存在的本体库信息(见2 2节).3.2 课程本体建模的系统方法3.2 1 概念提取,构建类层次结构 首先从选取的教材中收集和提取该本体中将包含的各种相关概念和词汇,并且同领域专家进行讨论、筛选.这一步骤是整个本体建模的基础,采用穷举的方式,尽量多地列举出所需要的基本概念和词汇集.表1示范了列举出的部分词汇集.然后采用自上而下的方法对穷举出的词汇进行分类和分层,定义类的属性和约束.首先提取最通用最基本的词汇作为基本类,例如图、视图、元素等,然后再向更详细更底层次的词汇进行划分,定义相应的子类、属性、约束等.分类关系一般用 Is a 来描述.图1展示了模型元素概念的层次结构模型.表1 UML本体概念术语提取表T ab.1 Co ncepts in U M L ontolog y知识分类概念和术语类图类,系统静态结构,关联,泛化,依赖关系,实现,接口序列图交互,对象,消息,激活用例图用例,参与者,系统功能,关联,扩展,包括,用例泛化对象图范例,动态,协作协作图协作,教育,角色,消息组件视图组件图,模块,依赖关系并发视图并发,动态图,状态图,序列图,协作图,活动图,执行图,组件图,展开图逻辑视图静态结构,类图,对象图,动态行为,状态图,序列图,协作图和活动图结构模型元素用例,接口,角色,类,结点,动作,组件,二进制组件,可执行组件,源组件行为模型元素决策,消息,对象,状态组织模型元素包注解模型元素笔记,约束3.2 2 定义关系模型 很显然, Is a 关系仅仅代表了一种简单的分类关系,代表了父子概念关系.而本体模型中类之间的关系比分类关系更为复杂和多样化.在IEEE学习对象元数据(IEEE learning ob jects metadata,LOM)规范中定义了learning object 之间的关系模型[18],如表2所示.类似地,在面向对象建模中定义了关系的几种表2 IEEE学习对象元数据中的关系定义T ab.2 R elatio ns defined in IEEE LO MIEEELOM关系名称对应OOP中的关系关系类型Ispartof;haspart;is versionof;has version;is formatof;hasformat;refereces;is referencedby;is bas edon;isbasisfor;requires;isrequir edbyAggregate(聚合)Dependency(依赖)Generali zation(通用化)Association(关联)图1 模型元素概念层次结构模型F ig.1 H ier archy mo del of modeling elements类型,例如关联、聚合、依赖、通用化,也可以在LOM中找到对应的关系映射.这些关系类型是基于Dublin Core标准而定义的,它们通常以成对的形式出现,便于创建两个学习对象之间单向的关系,因此关系都是有向的.知识的多样性和复杂性使得不同学科不同课程具有各自独特的关系模型,因此将关系模型分为基本关系模型和特殊关系模型.基本关系模型涵盖了知识空间一些基本的连接关系,而特殊关系模型则是针对具体的学科具体的课程所具备的特殊的关系而构建的.关系通常由动词、介词或者词组定义而成,表3描述了UM L本体中定义的关系模型.在定义可使用的关系模型后,可以构建更丰富更完善的本体.图2展示了U ML本体的使用多种关系模型的一部分.3.2 3 本体模型的验证和维护 本体的建模过程是一个不断循环改进优化的过程,对本体模型的评价和验证也穿插在整个本体开发的过程中.评价和验证主要从以下2个方面进行:1)与领域的专家和研究人员进行讨论,针对本体中的知识表达部分验证词汇的正确性、准确性以及类之间关系的可行性.2)与知识工程相关的研究学者讨论本体模型的方法可行性以及模型本身的正确性,包括一致性、完整性.另外用来作为本体建模的经典书籍以及广泛的网络资源都可以用来对本体进行验证和完善.对本体模型的验证包括对类的划分和定义、类层次结构模型、以及类的属性和关系模型的验证.1594浙 江 大 学 学 报(工学版) 第43卷表3 UML 本体的关系定义T ab.3 Relat ions in U M L Ontolog y关系对应的反转关系关系定义U M L 本体基本关系模型特殊关系HasSubty pe Is a 所描述的概念拥有的子概念.同 Is a 一样,该关系是用来构建层次结构的.HasPar tIsPar tOf 所描述的资源在物理上或逻辑上包含的其他资源Co nsistO f 与H asPart 类似,用于表示整体由部分组成的关系.与H asPar t 不同的是,Co nsist Of 通常表示一个概念由若干个相同的其他概念构成.IsBasisOf BasedO n 所描述的概念构成了另一个概念的理论基础.Oppo siteOf 所描述的概念是另一个概念的对立.此关系为双向.SpecializeO f 所描述的概念是另一个概念的特殊化形式.Ex ampleO f所描述的概念是另一个概念的例子.Descr ibedBy Descr ibes 表示的是一个概念由另一个概念描述.HasPr operty所描述的概念具有另一个概念描述的属性.HasRelationO f 这个关系是U M L 本体的特有关系,U M L 包含了 关系 这一类,用来表示各种模型元素之间的各类关系.所描述的概念具有某种关系类型.Car ry Out这个关系是U M L 本体中的特有关系.描述 执行 这个动作.图2 UML 本体模型示例Fig.2 U M L ontolog y mo del1)检查类的层次结构是否合理.类的层次结构主要由 Is a 关系表示,代表父子关系,包括是否存在环、同一层的相邻概念是否粒度相同.2)检查新的类的产生是否合理.例如某一概念是应该为一个新的类,还是某一个类的属性值,或者某一概念应该为类或者是类的实例.3)检查类的关系模型是否合理,是否存在冗余.关系的定义应遵循精简合理的原则,只需要能充分准确地描述类之间的关系,不需要复杂的附加的冗余关系.对本体模型的维护主要包括原有本体的可扩展性和可移植性.随着信息的飞速发展和知识的不断扩充,知识领域也不断的扩充和完善,更多的新知识被引入和学习,原有的知识结构体系也将被修改,因此原有的本体模型需要不断地添加新的词汇概念,同时对已有的类结构和关系模型也需要进行调整和改进,这就需要对本体模型中类的提取和划分、以及类层次结构有比较高的要求,能够方便地进行增添1595第9期欧阳杨,等:教育语义网中的知识领域本体建模和修改.例如UM L已经在原有的版本上相继开发出了新的版本:UM L1 3在原来U ML1 1和UM L1 2的基础上增加了对活动图的说明;在UM L1 1中定义了2个用例关系 使用(uses)和扩充(extends),它们都是通用化关系的衍型(stere o ty pe),而1 3版本则提供了3种关系:包含(in clude)(依赖关系的衍型,替代了 使用 原来的用途)、用例通用化和扩充.4 结 语本文提出了适用于教育领域知识本体建模的方法,通过将各个学科领域的知识用本体建模的方式进行组织和构架,可以将各种学习资源同领域知识关联起来,并且进行更高层次的应用扩展.以 U ML 建模语言 这门课程作为示例,演示了建模的过程,验证了该建模方法.该方法还可推广到其他领域的建设中,例如:1)用户本体,主要描述使用各种学习资源的主体对象的各种属性;2)教育服务提供者本体,主要描述提供各种教育服务的开发方的相关属性;3)学习平台本体,主要描述各种已经存在的学习平台的相关属性;4)学习行为本体,主要描述各种与学习相关的行为的属性.未来的研究工作包括学科本体建模方法的完善和在更多学科中的应用,同时将在已建立的学科本体上进行学习资源个性化系统的开发.参考文献(References):[1]BEMERS LEE T,HENDLER J,LASSILA O.T he semanticWeb[J].S cientific A m erican,2001,284(5):34-43.[2]N ECH ES R,F IK ES R E,GRU BER T R,et al.Enabling techno log y for know ledge shar ing[J].AIMagazine, 1991,12(3):36-56.[3]ST UT T A,M OT TA E.Semantic learning Webs[J].J ournalo f Interactive M edia in Education,2004(10):1-32.[4]WA L LER J C,F OST ER N.T raining via the w eb:avir tual instrument[J].C omputers and Education,2000, 35(2):161-167.[5]SANT OS J M,ANIDO L,L LA M AS M.Design ofsemantic web based brokerag e architecture for the E learn ing domain:a proposal for a suitable ontolog y[C] Pro ceedings o f the35th IEEE Frontiers in Education C onfer ence.N ew York:IEEE,2005,S3H:18-23.[6]M IZOG U CHI R,BO U RDEA U J.U sing ontolog icalengineering to ov ercome co mmon AI_ED pr oblems[J].International Journal of Artificial Intelligence in Educa tion,2000,11(2):107-121.[7]SA M P SO N D G,L YT R AS M D,W AG N ER G,et al.O ntolog ies and the semantic w eb fo r E learning[J].Journal of Educational Technology and Society,2004, 7(4):26-142.[8]G U A RIN O N.Semantic matching:fo rmal onto log icaldistinctio ns fo r info rmatio n o rg anizat ion,ex traction and int eg rat ion[C] Lecture Notes in C omputer Science.Berlin:Spring er,2006:139-170.[9]LOPEZ M F,GOM EZ PEREZ A,SIERRA J P,et a1.Building a chemical o ntolog y using M ET HON T OLOGY and the ontology design environment[J].IEEE Intellig ent S ystems and Their A pplications,1999,14(1):37-46. [10]K NIGHT K,CHA NDER I,HA INES M,et al.Fillingknow ledge gaps in a bro ad coverage MT system[C] Proceedings of International J oint C onference on A rtif icia l Intellig ence.M ontreal:Q uebec,1995:1390-1397. [11]K NIG HT K,WH IT N EY R.O nto lo gy cr eat ion anduse:sensus[EB/O L].[1997 08 28].ht tp://ww /natural lang uag e/r eso ur ces/sen sus.html.[12]U SCHO L D M,K IN G M.T o war ds a met ho do log y forbuilding o nt olo gies[C] Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing,Inter national Joint Conference on Artificial Intelligence.M ontr eal:Wilson,1995:25-34.[13]杜小勇,李曼,王珊.本体学习研究综述[J].软件学报,2006,17(9):1837-1847.DU X iao y ong,L I M an,W A NG Shan.A sur vey on onto log y learning research[J].Journal of Software,2006,17(9):1837-1847.[14]NOY N F,M CGU INN ESS D L.Ontolog y development101:guide to creating your first ontology[R].Stanford:Stanford University,2001.[15]A CM,f inal repo rt of the joint A CM/IEEE CS taskfor ce o n comput ing cur ricula2001for comput er science [EB/OL].[2001 12 15].htt p://ww w.acm.o rg/edu cation/curr icula.html#cc2001 fr.[16]顾芳.多学科领域本体设计方法的研究[D].北京:中国科学院研究生院,2004:14-16.GU Fang.Research o n design of multi disciplinar y Onto log y system[D].Beijing:Institute o f Computing Techno log y Chinese A cademy of Sciences,2004:14-16.[17]BO YCE S,P AH L C.Developing do main o nto lo gies forcourse content[J].Educational Technology and Socie ty,2007,10(3):275-288.[18]IEEE LO M,draft st andard fo r lear ning o bject metadata[EB/OL].[2002 07 15].htt p: ltsc.ieee.o rg/w g12/ 20020612 F inal L OM Draft.html.1596浙 江 大 学 学 报(工学版) 第43卷。
Ontology-based Reasoning about Lexical ResourcesJan Scheffczyk,Collin F.Baker,Srini NarayananInternational Computer Science Institute1947Center St.,Suite600,Berkeley,CA,94704jan,collinb,snarayan@AbstractReasoning about natural language most prominently requires combining semantically rich lexical resources with world knowledge, provided by ontologies.Therefore,we are building bindings from FrameNet–a lexical resource for English–to various ontologies depending on the application at hand.In this paper we show thefirst step toward such bindings:We translate FrameNet to the Web Ontology Language OWL DL.That way,FrameNet and its annotations become available to Description Logic reasoners and other OWL tools.In addition,FrameNet annotations can provide a high-quality lexicalization of the linked ontologies.1.IntroductionCombining large lexical resources with world knowledge, via ontologies,is a crucial step for reasoning over natu-ral language,particularly for the Semantic Web.Concrete applications include semantic parsing,text summarization, translation,and question answering.For example,ques-tions like“Could Y have murdered X?”may require sev-eral inference steps based on semantic facts that simple lexicons do not include.Moreover,they require so-called open-world semantics offered by state-of-the art Descrip-tion Logic(DL)reasoners,e.g.,FaCT(Horrocks,1998) or Racer(Wessel and M¨o ller,2005).The FrameNet lex-icon(Ruppenhofer et al.,2005)has a uniquely rich level of semantic detail;thus,we are building bindings from FrameNet to multiple ontologies that will vary depending on the application.That way,we enable reasoners to make inferences over natural-language text.In this paper,we report on thefirst step toward this goal:we have automatically translated a crucial portion of FrameNet to OWL DL and we show how state-of-the-art DL reasoners can make inferences over FrameNet-annotated sentences. Thus,annotated text becomes available to the Semantic Web and FrameNet itself can be linked to other ontologies. This work gives a clear motivation for the design of our pro-posed ontology bindings and defines the baseline for mea-suring their benefits.This paper proceeds as follows:In Sect.2.we briefly intro-duce FrameNet–a lexical resource for English.We present our design decisions for linking FrameNet to ontologies in Sect.3.Sect.4.includes the heart of this paper:A formal-ization of FrameNet and FrameNet-annotated sentences in OWL DL.In Sect.5.we show how our OWL DL represen-tation can be used by the DL reasoner RacerPro in order to implement tasks of a question answering system,based on reasoning.We evaluate our approach in Sect.6.Sect.7. concludes and sketches directions for future research.2.The FrameNet Lexicon FrameNet is a lexical resource for English,based on frame semantics(Fillmore,1976;Fillmore et al.,2003; Narayanan et al.,2003).A semantic frame(hereafter sim-ply frame)represents a set of concepts associated with an event or a state,ranging from simple(Arriving,Placing)to complex(Revenge,Criminalaffect(which in turn inherits from the frames Transitiveact).In addition,Attack uses the frame Hos-tileact frame.3.Linking FrameNet to Ontologies forReasoningNLP applications using FrameNet require knowledge about the possiblefillers for FEs.For example,a semantic frame parser needs to know whether a certain chunk of text(or a named entity)might be a properfiller for an FE–so it will check whether thefiller type of the FE is compatible with the type of the named entity.Therefore,we want to provide constraints onfillers of FEs,so-called semantic types(STs). Currently,FrameNet itself has defined about40STs that are ordered by a subtype hierarchy.For example,the Assailant FE and the Victim FE in the Attack frame both have the ST Sentient,which in turn is a subtype of Animatething,Physical entity. It is obvious that FrameNet STs are somewhat similar to the concepts(often called classes)defined in ontologies like SUMO(Niles and Pease,2001)or Cyc(Lenat,1995). Compared to ontology classes,however,FrameNet STs are much more shallow,have fewer relations between them(we only have subtyping and no other relations),and are notFigure1:Abridged example frame Attack and some connected frames.context specific.Naturally,in a lexicographic project like FrameNet STs play a minor role only.Therefore,we want to employ the STs from existing large ontologies such as SUMO or Cyc;in this way we will gain a number of advantages almost for free:AI applications can use the knowledge provided by the target ontology.We can provide different STs suitable for particular applications by bindings to different ontologies.We can use ontologies in order to query and analyze FrameNet data.For example,we can measure the se-mantic distance between frames based on different tar-get ontologies or we can check consistency and com-pleteness of FrameNet w.r.t.some target ontology.The target ontologies would benefit from FrameNet, supplementing their ontological knowledge with a proper lexicon and annotated example sentences. Compared to other lexicon-ontology bindings(Niles and Pease,2003;Burns and Davis,1999),our bindings offer a range of advantages due to specific FrameNet character-istics:FrameNet models semantic and syntactic valences plus the predicate-argument structure.FrameNet includes many high-quality annotations,providing training data for machine learning.In contrast to WordNet synset annota-tions,our annotations include role labelling.Frame seman-tics naturally provides cross-linguistic abstraction plus nor-malization of paraphrases and support for null instantiation (NI).Notice that a detour via WordNet would introduce ad-ditional noise through LU lookup(Burchardt et al.,2005). In addition,WordNet synset relations are not necessarily compatible with FrameNet relations.The bindings from FrameNet to ontologies should be de-scribed in the native language of the target ontologies,i.e., KIF(for bindings to SUMO),CycL(for bindings to Cyc), or OWL(for bindings to OWL ontologies).This allows the use of standard tools like reasoners directly,without any intermediate steps.Also,arbitrary class expressions can be used and ad-hoc classes can be defined if no exact corre-sponding class could be found in the target ontology.We expect this to be very likely because FrameNet is a lexico-graphic project as opposed to ontologies,which are usually driven by a knowledge-based approach.Finally,the bind-ing should be as specific as possible for the application at hand.For example,in a military context we would like to bind FEs to classes in an ontology about WMD or terror-ism instead of using a binding to SUMO itself,which only provides upper level classes.2The vital precondition for any such bindings is,however, to have FrameNet available in an appropriate ontology language(e.g.,KIF,CycL,or OWL).A representation of FrameNet in an ontology language bears the additional ad-vantages of formalizing certain properties of frames and FEs,and enabling us to use standard tools to view,query, and reason about FrameNet data.For querying,one could, e.g.,use the ontology query language SPARQL.Next,we describe a formalization of a portion of FrameNet in OWL DL,which easily generalizes to more expressive ontology languages like KIF or CycL.4.Formalizing FrameNet in OWL DL Our major design decisions for representing FrameNet as an ontology are:1.to represent frames,FEs,and STs formally as classes,2.to model relations between frames and FEs via exis-tential property restrictions on these classes,and3.to represent frame and FE realizations in FrameNet-annotated texts as instances of the appropriate frame and FE classes,respectively.Building on(Narayanan et al.,2003),we have chosen OWL DL as representation language mainly because better tools are available for it(particularly for reasoning)than for OWL Full or other similarly expressive languages.Our representation differs from many WordNet OWL represen-tations,which represent synsets as instances and hence can-not use class expressions for ontology bindings.3Instead, WordNet bindings to SUMO employ a proprietary mecha-nism,4which cannot be used“out of the box”by ontology tools like reasoners.In order to keep the size of our ontology manageable, we have chosen to split it into the FrameNet Ontology and Annotation Ontologies.The FrameNet Ontology in-cludes FrameNet data like frames,FEs,and relations be-tween them.Annotation Ontologies represent FrameNet-annotated sentences and include parts of the FrameNet On-tology that are necessary.4.1.The FrameNet OntologyFig.2shows a simplified excerpt of the FrameNet On-tology.The subclasses of the Syntax class are used for annotations and are connected to frames and FEs via the evokes andfillerOf relations,respectively.Frames and FEs are connected via binary relations,e.g.,the usesF prop-erty or the hasFE property,which connects a frame to its FEs.Consider our example frame Attack,which inher-its from the frame Intentionallyencounter.We model frame and FE inheritance via subclassing and other frame and FE relations via existen-tial property restrictions(owl:someValuesFrom).Thus,the class Attack is a subclass of Intentionallyencounter connected via the usesF property.The FEs of Attack are connected via an ex-istential restriction on the hasFE property.FE relations are modeled similarly to frame relations.Recall that class restrictions are inherited.Therefore,the class Attack inherits the restrictions hasFE Patient and hasFE Agent from the class Intentionallyaffect has exactly one instance of type Patient con-nected via the hasFE property:Intentionallyaffect hasFE or Intentionally5see /2001/sw/BestPractices/OEP/QCR/6Even now,the FrameNet Ontology reaches a critical size of 100,000triples.class Sentient.We intend to use this mechanism for link-ing FrameNet to other ontologies also.So we can use ar-bitrary OWL DL class expressions for our bindings and at the same time achieve a homogeneous formal representa-tion that OWL tools can make use of.One could use the FrameNet Ontology for querying and reasoning over FrameNet itself.For reasoning over natu-ral language text,however,we mustfind a way to incorpo-rate this text into the FrameNet Ontology.We do this by means of Annotation Ontologies,which we generate from FrameNet-annotated text.4.2.Annotation OntologiesFrameNet-annotated text provides textual realizations of frames and FEs,i.e.,the frames and FEs cover the se-mantics of the annotated sentences.In ontological terms, FrameNet-annotated text constitutes instances of the appro-priate frame and FE classes,respectively.From an anno-tated sentence we generate an Annotation Ontology,which includes parts of the FrameNet Ontology and fulfills all its class restrictions.In other words,the FrameNet Ontology provides a formal specification for Annotation Ontologies. Consider an example sentence,which we derived from an evaluation exercise within the AQUINAS project called “KB Eval;”where sentences for analysis were contributed by various members of the consortium.S48Kuwaiti jetfighters managed to escape the Iraqi invasion.7This sentence has three annotation sets:1.The target word invasion evokes the Attack frame,where Iraqifills the Assailant FE.The Victim FE has nofiller,i.e.,it is null instantiated(NI).2.The target word escape evokes the Avoiding frame,with FEfillers48Kuwaiti jetfighters Agent,the Iraqi invasion Undesirableaction frame,with FEfillers48Kuwaiti jetfightersProtagonist,to escape the Iraqi invasion Goal. From this annotated sentence wefirst create a syntactic de-pendency graph and generate the appropriate frame and FE instances as shown in Fig.3A Span represents a chunk of text that can evoke a frame or provide afiller for an FE. We derive Spans,syntactic subsumption,and the relations to frames and FEs based on the annotations.For example, invasion evokes the Attack frame.Thus we(1)generate a Span that represents the text invasion and place it properly into the Span dependency graph,(2)generate the frame in-stance Attack S(with type Attack),and(3)connect the Span to Attack S via the evokes property.We proceed similarly with the FEfiller Iraqi Agent.Here we generate the FE instance Agent S,connect it to its frame instance Attack S via the hasFE property,and connect the Span representing Iraqi to Agent S via thefillerOf property.Finally,we iden-tify FEs that are evoked by the same Span via owl:sameAs.Figure2:Part of the FrameNet Ontology for the Attack frame and some connected frames.Figure3:Annotation Ontology for:48Kuwaiti jetfighters managed to escape the Iraqi invasion.(Step1)We can do this purely based on syntactic evidence.For ex-ample,the FE instances Protagonist S and Agent S are iden-tified because the are bothfilled by the Span representing the text48Kuwaiti jetfighters.This significantly aids rea-soning about FrameNet-annotated text.8The second step in generating an Annotation Ontology is to satisfy the class restrictions of the FrameNet ontology, i.e.,to generate appropriate instances and to connect them properly.Thus,for a frame instance of type we1.travel along each existential class restriction on a prop-erty to a class(),2.generate an instance of type,3.connect the instances and via the property,and4.proceed with instance.Fig.4illustrates this algorithm for our example frame instance Attack.We generate the frame instance Hos-tile1S and Sideencounter S via usesF.Sim-ilarly,we connect Assailant S to Side2S via usesFE.In addition,we identify the connected FE instances via owl:sameAs,which expresses the seman-tics of FE mappings:The Victim in an Attack is the Side encounter,i.e.,theirfillers are the same.In addition to the class restrictions,we also travel along the inheritance hierarchy,which could be useful,e.g.,for paraphrasing.Therefore,we generate the instance Inten-tionally8Alternatively,we could formalize a SWRL rule fillerOffillerOf owl:sameAs.We do not do so because not all reasoners provide a SWRL implementa-tion.9see succeeds,then the Spans bound to these FEs contain the an-swer,otherwise the question cannot be answered from the text.Consider three example questions.Q1How many Kuwaiti jetfighters escaped the Iraqi inva-sion?Q2How many Kuwaiti jetfighters escaped?Q3Did Iraq clash with Kuwait?Q4Was there a conflict between Iraq and Kuwait? Partial Annotation Ontologies for these questions are illus-trated in Fig.5.Given the Annotation Ontology of the question,we let Rac-erPro perform the following queries,which can be formal-ized in nRQL.10In the following we will use question Q1 as an example of how the algorithm works.1.For the question get the evoked frames instances,theirFEs,and Spans.Avoiding Q1Undesirables.Q1Undesirables.Undesirables.S the Iraqi invasionAgent S48Kuwaiti jetfightersAssailant S IraqiVictim S NIFigure4:Connecting the Attack instance(Step2of Annotation Ontologygeneration) Figure5:Abridged Annotation Ontologies for example questionsSince RacerPro is a reasoner(and no NLP tool), checking the compatibility of Spans is limited to checking syntactic equality.Therefore,the Span48 Kuwaiti jetfighters does not match the Span How many Kuwaiti jetfighters.We can,however,easily de-termine the Spans that are supposed to be compatible in order to yield an answer.Then Span compatibility can be determined by other NLP tools such as question type recognizers.Question Q2is simpler than Q1because we are asking for only one frame in which one FE is null instantiated.In this case our approach only using a reasoning engine yields the final answer:Undesirableencounter.Our ap-proach proceeds as follows:1.Get evoked frames instances,FEs,and Spans:Hostile1Q3IraqSideencounter Q3Hostile1Q3Side2Q3Sideencounter Hostile1Side2Side1S IraqiSide1S isthe same as Assailant S and Side1and Side1and Side1and Side11see /services/named entity recognizers.Also,we plan to evaluate the utility of DL reasoners in a fullyfledged question answer-ing system.Finally,we will translate FrameNet to other ontology languages such as KIF or CycL,in order to link FrameNet to SUMO or Cyc ontologies.AcknowledgementsThefirst author enjoys funding from the German Aca-demic Exchange Service(DAAD).The FrameNet project is funded by the AQUINAS project of the AQUAINT pro-gram.8.ReferencesA.Burchardt,K.Erk,and A.Frank.2005.A WordNet detour to FrameNet.In Proceedings of the GLDV2005 Workshop GermaNet II,Bonn.K.J.Burns and A.R.Davis.1999.Building and maintain-ing a semantically adequate lexicon using cyc.In Eve-lyne Viegas,editor,Breadth and Depth of Semantic Lex-icons.Kluwer.K.Erk and S.Pad´o.2005.Analysing models for semantic role assignment using confusability.In Proceedings of HLT/EMNLP-05,Vancouver,Canada.K.Erk and S.Pad´o.2006.Shalmaneser–a toolchain for shallow semantic parsing.In Proceedings of LREC-06, Genova,Italy.to appear.C.J.Fillmore,C.R.Johnson,and M.R.L.Petruck.2003. Background to FrameNet.International Journal of Lex-icography,16(3):235–250.C.J.Fillmore.1976.Frame semantics and the nature of language.Annals of the New York Academy of Sciences, (280):20–32.I.Horrocks.1998.The FaCT system.In H.de Swart, editor,Automated Reasoning with Analytic Tableaux and Related Methods:International Conference Tableaux’98,number1397in Lecture Notes in Artificial Intelligence,pages307–312.Springer-Verlag,May. D.B.Lenat.1995.Cyc:a large-scale investment in knowl-edge mun.ACM,38(11):33–38.K.Litowski.2004.Senseval-3task:Automatic labeling of semantic roles.In Senseval-3:Third International Work-shop on the Evaluation of Systems for the Semantic Anal-ysis of Text,pages9–12.Association for Computational Linguistics.S.Narayanan and S.McIlraith.2003.Analysis and simu-lation of Web works,42(5):675–693.S.Narayanan,C.F.Baker,C.J.Fillmore,and M.R.L. Petruck.2003.FrameNet meets the semantic web:Lexi-cal semantics for the web.In The Semantic Web—ISWC 2003,pages771–787.Springer-Verlag,Berlin.S.Narayanan.1999.Moving right along:A computational model of metaphoric reasoning about events.In Pro-ceedings of the/National Conference on Artificial Intel-ligence(AAAI’99),pages121–128.AAAI Press.I.Niles and A.Pease.2001.Towards a standard upper on-tology.In Proceedings of the2nd International Confer-ence on Formal Ontology in Information Systems(FOIS-2001),Ogunquit,Maine.I.Niles and A.Pease.2003.Linking lexicons and ontolo-gies:Mapping wordnet to the suggested upper merged ontology.In Proceedings of the2003International Conference on Information and Knowledge Engineering (IKE03).J.Ruppenhofer,M.Ellsworth,M.R.Petruck, and C.R.Johnson,2005.FrameNet: Theory and Practice.ICSI Berkeley. /framenet/book/book.html.J.Scheffczyk and M.Ellsworth.2006.Improving the qual-ity of FrameNet.In Proc.of the Wkshp.on Quality assurance and quality measurement for language and speech resources,Genoa,Italy.to appear.M.Wessel and R.M¨o ller.2005.A high performance se-mantic web query answering engine.In Proc.Interna-tional Workshop on Description Logics.。
An Ontological Approach to Oracle BPMJean Prater, Ralf Mueller, Bill BeauregardOracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065, USA **********************,***********************,*****************************The Oracle Business Process Management (Oracle BPM) Suite is composed oftools for Business Analysts and Developers for the modeling of BusinessProcesses in BPMN 2.0 (OMG1 standard), Business Rules, Human Workflow,Complex Events, and many other tools. BPM operates using the commontenants of an underlying Service Oriented Architecture (SOA) runtimeinfrastructure based on the Service Component Architecture (SCA). OracleDatabase Semantic Technologies provides native storage, querying andinferencing that are compliant with W3C standards for semantic (RDF/OWL)data and ontologies, with scalability and security for enterprise-scale semanticapplications.Semantically-enabling all artifacts of BPM from the high-level design of aBusiness Process Diagram to the deployment and runtime model of a BPMapplication promotes continuous process refinement, enables comprehensiveimpact analysis and prevents unnecessary proliferation of processes andservices. This paper presents the Oracle BPM ontology based upon BPMN 2.0,Service Component Architecture (SCA) and the Web Ontology Language(OWL 2). The implementation of this ontology provides a wide range of usecases in the areas of Process Analysis, Governance, Business Intelligence andSystems Management. It also has the potential to bring together stakeholdersacross an Enterprise, for a true Agile End-to-End Enterprise Architecture.Example use cases are presented as well as an outlook of the evolution of theontology to cover the organizational and social aspects of Business ProcessManagement.1.IntroductionIn the 1968 film, 2001: A Space Odyssey, the movie’s antagonist, HAL, is a computer that is capable not only of speech, speech recognition, and natural language processing, but also lip reading, apparent art appreciation, interpreting and reproducing emotional behavior, reasoning, and playing chess, all while maintaining the systems on an interplanetary mission. While the solution we present in this paper does not possess all of the capabilities of HAL, the potential benefits of combining semantic technology with Oracle BPM provides the ability to define contextual relationships between business processes and provides the tools to use that context so that ‘software agents’ (programs working on behalf of people) can find the right1 Object Management Group, see 2 Jean Prater, Ralf Mueller, Bill Beauregardinformation or processes and make decisions based on the established contextual relationships.Organizations can more efficiently and effectively optimize their information technology resources through a service-oriented approach leveraging common business processes and semantics throughout their enterprise. The challenge, however, with applications built on Business Process Management (BPM) and Service Oriented Architecture (SOA) technology is that many are comprised of numerous artifacts spanning a wide range of representation formats. BPMN 2.0, the Service Component Architecture Assembly Model, Web Service definitions (in the form of WSDL), XSLT transformations, for example are all based on well defined but varying type models. To answer even simple queries on the entire BPM model, a user is left with a multitude of API’s and technologies, making the exercise difficult and highly complicated. Oracle has developed an ontology in OWL that encompasses all the artifacts of a BPM application and is stored in Oracle Database Semantic Technologies that provides a holistic view of the entire model and a unified and standardized way to query that model using SPARQL.Oracle is actively involved in the standards process and is leading industry efforts to use ontologies for metadata analysis. Oracle is also investigating the integration of organizational and social aspects of BPM using FOAF2. BPMN 2.0 task performers can be associated with a FOAF Person, Group or Organization and then used in Social Web activities to enable Business Users to collaborate on BPM models.1.1 BenefitsThe benefits of adding semantic technology to the database and to business process management in the middleware, driven by an underlying ontology are three fold:1.It promotes continuous process refinement. A less comprehensive processmodel can evolve into a complete executable process in the same model.2.It makes it easy to analyze the impact of adding, modifying or deletingprocesses and process building blocks on existing processes and webservices.3.It helps prevent unnecessary proliferation of processes and services. Combining semantic technology and business process management allows business users across organizational boundaries to find, share, and combine information and processes more easily by adding contextual relationships.1.2 Customer Use CaseThe US Department of Defense (DoD) is leading the way in the Federal Government for Architecture-driven Business Operations Transformation. A vital tenet for success is ensuring that business process models are based on a standardized representation, thus enabling the analysis and comparison of end to end business processes. This will lead to the reuse of the most efficient and effective process patterns (style guide), comprised of elements (primitives), throughout the DoD Business Mission Area. A key principle in DoD Business Transformation is its focus on data ontology. The 2 The Friend of a Friend (FOAF) project, see An Ontological Approach to Oracle BPM 3 Business Transformation Agency (BTA), under the purview of the Deputy Chief Management Officer (DCMO), has been at the forefront of efforts to develop a common vocabulary and processes in support of business enterprise interoperability through data standardization. The use of primitives and reuse of process patterns will reduce waste in overhead costs, process duplication and building and maintaining enterprise architectures. By aligning the Department of Defense Architecture Framework3 2.0 (DoDAF 2.0) with Business Process Modeling Notation 2.0 (BPMN 2.0) and partnering with industry, the BTA is accelerating the adoption of these standards to improve government business process efficiency.2.The Oracle BPM OntologyThe Oracle BPM ontology encompasses and expands the BPMN 2.0 and SCA ontologies. The Oracle BPM ontology is stored in Oracle Database Semantic Technologies and creates a composite model by establishing relationships between the OWL classes of the BPMN 2.0 ontology and the OWL classes of the SCA runtime ontology. For example, the BPMN 2.0 Process, User Task and Business Rule Task are mapped to components in the composite model. Send, Receive and Service Tasks, as well as Message Events are mapped to appropriate SCA Services and References and appropriate connections are created between the composite model artifacts. Figure 1 illustrates the anatomy of the Business Rule Task “Determine Approval Flow” that is a part of a Sales Quote demo delivered with BPM Suite.Figure 1: Anatomy of a BPMN 2.0 Business Rule Task4The diagram shows that the Business Rule Task “Determine Approval Flow” is of BPMN 2.0 type Business Rule Task and implemented by a SCA Decision Component that is connected to a BPMN Component “RequestQuote”. Also of significance is that the Decision Component exposes a Service that refers to a specific XML-Schema, which is also referred to by Data Objects in the BPMN 2.0 process RequestQuote.bpmn.3See /products/BEA_6.2/BEA/products/2009-04-27 Primitives Guidelines for Business Process Models (DoDAF OV-6c).pdf4 Visualized using TopBraid Composer TM4 Jean Prater, Ralf Mueller, Bill Beauregard3.An Ontology for BPMN 2.0With the release of the OMG BPMN 2.0 standard, a format based on XMI and XML-Schema was introduced for the Diagram Interchange (DI) and the Semantic Model. Based on the BPMN 2.0 Semantic Model, Oracle created an ontology that is comprised of the following5:•OWL classes and properties for all BPMN 2.0 Elements that are relevant for the Business Process Model.6The OWL classes, whenever possible,follow the conventions in the BPMN 2.0 UML meta model. OWL propertiesand restrictions are included by adding all of the data and object propertiesaccording to the attributes and class associations in the BPMN 2.0 model.7•OWL classes and properties for instantiations of a BPMN 2.0 process model. These OWL classes cover the runtime aspects of a BPMN 2.0process when executed by a process engine. The process engine createsBPMN 2.0 flow element instances when the process is executed. Activitylogging information is captured, including timestamps for a flow elementinstance’s activation and completion, as well as the performer of the task. The implicit (unstated) relationships in the Oracle BPM ontology can be automatically discovered using the native inferencing engine included with Oracle Database Semantic Technologies. The explicit and implicit relationships in the ontology can be queried using Oracle Database Semantic Technologies support for SPARQL (patterns matching queries) and/or mixed SPARQL in SQL queries. [6] Example SPARQL queries are shown below:Select all User Tasks in all Lanesselect ?usertask ?lanewhere {usertask rdf:type bpmn:UserTask .usertask bpmn:inLane lane}Select all flow elements with their sequence flow in lane p1:MyLane (a concrete instance of RDF type bpmn:Lane)select ?source ?targetwhere {flow bpmn:sourceFlowElement source .flow bpmn:targetFlowElement target .5 All of the classes of the BPMN 2.0 meta model that exists for technical reasons only (model m:n relationship or special containments) are not represented in the ontology6 The work in [2] describes an ontology based on BPMN 1.x for which no standardized meta model exists7 Oracle formulated SPARQL queries for envisioned use cases and added additional properties and restrictions to the ontology to support those use casesAn Ontological Approach to Oracle BPM 5 target bpmn:inLane p1:MyLane}Select all activities in process p1:MyProcess that satisfy SLA p1:MySLA select ?activity ?activityInstancewhere {activity bpmn:inProcess p1:MyProcess .activityInstance obpm:instanceOf activity .activityInstance obpm:meetSLA p1:MySLA}A unique capability of BPMN 2.0, as compared to BPEL, for instance, is its ability to promote continuous process refinement. A less comprehensive process model, perhaps created by a business analyst can evolve into a complete executable process that can be implemented by IT in the same model. The work sited in Validating Process Refinement with Ontologies[4] suggests an ontological approach for the validation of such process refinements.4.An Ontology for the SCA composite modelThe SCA composite model ontology represents the SCA assembly model and is comprised of OWL classes for Composite, Component, Service, Reference and Wire, which form the major building blocks of the assembly model. Oracle BPM ontology has OWL classes for concrete services specified by WSDL and data structures specified by XML-Schema. The transformation of the SCA assembly model to the SCA ontology includes creating finer grained WSDL and XML-Schema artifacts to capture the dependencies and relationships between concrete WSDL operations and messages to elements of some XML-Schema and their imported schemata.The SCA ontology was primarily created for the purpose of Governance and to act as a bridge between the Oracle BPM ontology and an ontology that would represent a concrete runtime infrastructure. This enables the important ability to perform impact analysis to determine, for instance, which BPMN 2.0 data objects and/or data associations are impacted by the modification of an XML-Schema element or which Web Service depends on this element. This feature helps prevent the proliferation of new types and services, and allows IT to ascertain the impact of an XML-Schema modification.5.The TechnologiesAs part of the customer use case, as referenced in section 1.2 above, we implemented a system that takes a BPM Project comprised of BPMN 2.0 process definitions, SCA assembly model, WSDL service definitions, XML-Schema and other metadata, and created appropriate Semantic data (RDF triples) for the Oracle BPM ontology. The6 Jean Prater, Ralf Mueller, Bill Beauregardtriples were then loaded into Oracle Database Semantic Technologies [3] and a SPARQL endpoint was used to except and process queries.6.ConclusionOracle BPM ontology encompasses and expands the generic ontologies for BPMN 2.0 and the SOA composite model to cover all artifacts of a BPM application from a potentially underspecified8process model in BPMN 2.0 down to the XML-Schema element and type level at runtime for process analysis, governance and Business Intelligence. The combination of RDF/OWL data storage, inferencing and SPARQL querying, as supported by Oracle Database Semantic Technologies, provides the ability to discover implicit relationships in data and find implicit and explicit relationships with pattern matching queries that go beyond classical approaches of XML-Schema, XQuery and SQL.7.AcknowledgementsWe’d like to thank Sudeer Bhoja, Linus Chow, Xavier Lopez, Bhagat Nainani and Zhe Wu for their contributions to the paper and valuable comments.8.References[1] Business Process Model and Notation (BPMN) Version 2.0,/spec/BPMN/2.0/[2] Ghidini Ch., Rospocher M., Serafini L.: BPMN Ontology,https://dkm.fbk.eu/index.php/BPMN_Ontology[3] Oracle Database Semantic Technologies,/technetwork/database/options/semantic-tech/[4] Ren Y., Groener G., Lemcke J., Tirdad R., Friesen A., Yuting Z., Pan J., Staab S.:Validating Process Refinement with Ontologies[5] Service Component Architecture (SCA), [6] Kolovski V., Wu Z., Eadon G.: Optimizing Enterprise-Scale OWL 2 RL Reasoning in aRelational Database System, ISWC 2010, page 436-452[7] “Use of End-toEnd (E2E) Business Models and Ontology in DoD Business Architectures”;Memorandum from Deputy Chief Management Office; April 4, 2011, Elizabeth A.McGrath, Deputy DCMO.[8] “Primitives and Style: A Common Vocabulary for BPM across the Enterprise”; DennisWisnosky, Chief Architect & CTO ODCMO and Linus Chow Oracle; BPM Excellence in Practice 2010; Published by Future Strategies, 20108A BPMN 2.0 model element is considered underspecified, if its valid but not all attribute values relevant for execution are specified.。
本体(Ontology)与传统知识组织体系的比较分类表/主题词表作为传统的知识组织工具与本体具有相似性,即它们都是以提高检索效率和知识共享为目的;都用来描述特定领域的学科知识,都可以用作特定学科的知识组织工具;两者都包含词(概念、类)及词(概念、类)间关系;两者都具有等级结构,并通过等级关系及词(概念、类)间关系将词(概念、类)组织起来。
然而Ontology与这些传统知识组织工具有着本质的区别。
Ontology中概念之间的关系的表达比分类表/主题表等工具要广而且深。
本体更强调对具体事物属性和关系的描述,强调构建领域概念的形式化模型,重视术语体系的模型化、明晰化、形式化和概念模型的共享性。
分类表、主题词表的词间关系精确程度不高,无法揭示更深更广的语义关系。
并且它们没有自身的知识表示语言、无法实现形式化编码,无法支持知识资源的知识标注和知识检索。
一个完善的Ontology能够提出结构的主体概念的关系,包括superclass\Psubclass\Pinstance(超类\亚类飞实例)关系、property value(特征值)、时间关系以及依赖于所用的表达语言的关系等。
通常一个Ontology包含的不止是关系,与分类表、主题词相比这些关系被正式地定义并不模糊。
Ontology用基于描述逻辑的知识表示语言对概念体系(类、关系、函数、公理、实例)进行形式化描述,能支持本体标引工具对资源进行语义标注,支持以知识网络的方式展示知识结构。
因此,Ontology对概念的揭示程度远远高于分类表飞主题词表。
本体( Ontology)在数字图书馆知识组织中的作用1.规范描述知识间的语义关系运用本体方法对数字图书馆的知识进行组织,可以减少概念和术语上的歧义,概念间的关系可以被描述得更加广泛、详细、深入和全面,通过对概念添加属性值,对属性与属性之间再添加映射关系,一些在正规词表中不能描述的语义关系就可以清晰的描述出来。
本体描述为数字图书馆提供了一个统一框架或规范模型,使得来自不同背景,持不同观点和目的的人们之间的理解和交流成为可能,并保持语义上的一致性。
Reviewing the Design of DAML+OIL: An Ontology Language for the Semantic WebIan Horrocks University of Manchester Manchester,UK horrocks@ Peter F.Patel-SchneiderBell Labs ResearchMurray Hill,NJ,U.S.A.pfps@Frank van HarmelenVrije UniversiteitAmsterdam,the NetherlandsFrank.van.Harmelen@cs.vu.nlAbstractIn the current“Syntactic Web”,uninterpreted syntactic con-structs are given meaning only by private off-line agreementsthat are inaccessible to computers.In the Semantic Web vi-sion,this is replaced by a web where both data and its se-mantic definition are accessible and manipulable by computersoftware.DAML+OIL is an ontology language specificallydesigned for this use in the Web;it exploits existing Webstandards(XML and RDF),adding the familiar ontologicalprimitives of object oriented and frame based systems,andthe formal rigor of a very expressive description logic.Thedefinition of DAML+OIL is now over a year old,and the lan-guage has been in fairly widespread use.In this paper,wereview DAML+OIL’s relation with its key ingredients(XML,RDF,OIL,DAML-ONT,Description Logics),we discuss thedesign decisions and trade-offs that were the basis for thelanguage definition,and identify a number of implementa-tion challenges posed by the current language.These issuesare important for designers of other representation languagesfor the Semantic Web,be they competitors or successors ofDAML+OIL,such as the language currently under definitionby W3C.IntroductionIn the short span of its existence,the World Wide Web hasresulted in a revolution in the way information is transferredbetween computer applications.It is no longer necessary forhumans to set up channels for inter-application informationtransfer;this is handled by TCP/IP and related protocols.Itis also no longer necessary for humans to define the syntaxand build parsers used for each kind of information transfer;this is handled by HTML,XML and related standards.How-ever,it is still not possible for applications to interoperatewith other applications without some pre-existing,human-created,and outside-of-the-web agreements as to the mean-ing of the information being transferred.The next generation of the Web aims to alleviate thisproblem—making Web resources more readily accessible toautomated processes by adding information that describesWeb content in a machine-accessible and manipulable fash-ion.This coincides with the vision that Tim Berners-Leecalls the Semantic Web in his recent book“Weaving theWeb”(Berners-Lee1999).1/XML/Schema/2/RDF/they are to be used effectively by automated processes,e.g., to determine the semantic relationships between syntacti-cally different terms.DAML+OIL is the result of merging DAML-ONT(an early result of the DARPA Agent Markup Language (DAML)programme3)and OIL(the Ontology Inference Layer)(Fensel et al.2001),developed by a group of(largely European)researchers,several of whom were members of the European-funded On-To-Knowledge consortium.4 Until recently,the development of DAML+OIL has been undertaken by a committee largely made up of members of the two language design teams(and rather grandly titled the Joint EU/US Committee on Agent Markup Languages).5 More recently,DAML+OIL has been submitted to W3C as a proposal for the basis of the W3C Web Ontology language.6 As it is an ontology language,DAML+OIL is designed to describe the structure of a domain.DAML+OIL takes an object oriented approach,with the structure of the domain being described in terms of classes and properties.An on-tology consists of a set of axioms that assert characteristics of these classes and properties.Asserting that resources are instances of DAML+OIL classes or that resources are re-lated by properties is left to RDF,a task for which it is well suited.Since the definition of DAML+OIL is available else-where,7we will not repeat it here.Instead,in the follow-ing sections,we will review a number of fundamental design choices that were made for DAML+OIL:foundations in De-scription Logic,XML datatypes,layering on top of RDFS, comparison with its predecessor OIL,and the role of infer-ence for a Semantic Web ontology language.Foundations in Description LogicDAML+OIL is,in essence,equivalent to a very expressive Description Logic(DL),with a DAML+OIL ontology cor-responding to a DL terminology.As in a DL,DAML+OIL classes can be names(URI’s in the case of DAML+OIL)or expressions,and a variety of constructors are provided for building class expressions.The expressive power of the lan-guage is determined by the class(and property)constructors provided,and by the kinds of axioms allowed.Figure1summarises the constructors in DAML+OIL. The standard DL syntax is used in this paper for compact-ness as the RDF syntax is rather verbose.In the RDF syntax, for example,Human Male would be written as <daml:Class><daml:intersectionOfrdf:parseType="daml:collection"> <daml:Class rdf:about="#Human"/><daml:Class rdf:about="#Male"/></daml:intersectionOf></daml:Class>DL SyntaxintersectionOf Human Male unionOf Doctor Lawyer complementOf MaleoneOf john marytoClass hasChild Doctor hasClass hasChild Lawyer hasValue citizenOf USA minCardinalityQ hasChild Lawyer maxCardinalityQ hasChild Male cardinalityQ hasParent Female Figure1:DAML+OIL class constructorsThe meanings of thefirst three constructors from Figure1 are just the standard boolean operators on classes.The oneOf constructor allows classes to be defined by enumerat-ing their members.The toClass and hasClass constructors correspond to slot constraints in a frame-based language.The class is the class all of whose instances are related via the property only to resources of type,while the class is theclass all of whose instances are related via the property to at least one resource of type.The hasValue constructor is just shorthand for a combination of hasClass and oneOf. The minCardinalityQ,maxCardinalityQ and cardinalityQ constructors(known in DLs as qualified number restrictions) are generalisations of the hasClass and hasValue construc-tors.The class(,)is the class all of whose instances are related via the property to at least(at most,exactly)different resources of type.The emphasis on different is because there is no unique name as-sumption with respect to resource names(URIs):it is possi-ble that many URIs could name the same resource.Note that arbitrarily complex nesting of constructors is possible.The formal semantics of the class constructors is given by DAML+OIL’s model-theoretic semantics8or can be derived from the specification of a suitably expressive DL (e.g.,see(Horrocks&Sattler2001)).Figure2summarises the axioms allowed in DAML+OIL. These axioms make it possible to assert subsumption or equivalence with respect to classes or properties,the dis-jointness of classes,the equivalence or non-equivalence of individuals(resources),and various properties of properties.A crucial feature of DAML+OIL is that subClassOf and sameClassAs axioms can be applied to arbitrary class ex-pressions.This provides greatly increased expressive power with respect to standard frame-based languages where such axioms are invariably restricted to the form where the left hand side is a class name,there is only one such axiom per name,and there are no cycles(the class on the right hand side of an axiom cannot refer,either directly or indirectly,to the class name on the left hand side).A consequence of this expressive power is that all of the class and individual axioms,as well as the uniquePropertyAxiom ExampleBush G Bush differentIndividualFrom john peterinverseOf hasChild hasParent transitiveProperty ancestor ancestor uniqueProperty hasMother unambiguousProperty isMotherOfFigure2:DAML+OIL axiomsand unambiguousProperty axioms,can be reduced to sub-ClassOf and sameClassAs axioms(as can be seen from theDL syntax).As we have seen,DAML+OIL also allows properties of properties to be asserted.It is possible to assert that a prop-erty is unique(i.e.,functional)and unambiguous(i.e.,its inverse is functional).It is also possible to use inverse prop-erties and to assert that a property is transitive.XML Datatypes in DAML+OILDAML+OIL supports the full range of datatypes in XML Schema:the so called primitive datatypes such as string,decimal orfloat,as well as more complex derived datatypes such as integer sub-ranges.This is facilitated by main-taining a clean separation between instances of“object”classes(defined using the ontology language)and instances of datatypes(defined using the XML Schema type system). In particular,the domain of interpretation of object classesis disjoint from the domain of interpretation of datatypes, so that an instance of an object class(e.g.,the individual “Italy”)can never have the same denotation as a value ofa datatype(e.g.,the integer5),and that the set of object properties(which map individuals to individuals)is disjoint from the set of datatype properties(which map individualsto datatype values).The disjointness of object and datatype domains was mo-tivated by both philosophical and pragmatic considerations: Datatypes are considered to be already sufficiently struc-tured by the built-in predicates,and it is,therefore,notappropriate to form new classes of datatype values using the ontology language(Hollunder&Baader1991). The simplicity and compactness of the ontology language are not compromised:even enumerating all the XML Schema datatypes would add greatly to its complexity, while adding a logical theory for each datatype,even if it were possible,would lead to a language of monumental proportions.The semantic integrity of the language is not compromised—defining theories for all the XML Schema datatypes would be difficult or impossible without extending the language in directions whosesemantics would be difficult to capture within the existing framework.The“implementability”of the language is not compromised—a hybrid reasoner can easily be im-plemented by combining a reasoner for the“object”language with one capable of deciding satisfiability ques-tions with respect to conjunctions of(possibly negated) datatypes(Horrocks&Sattler2001).From a theoretical point of view,this design means that the ontology language can specify constraints on data val-ues,but as data values can never be instances of object classes they cannot apply additional constraints to elements of the object domain.This allows the type system to be ex-tended without having any impact on the ontology language, and vice versa.Similarly,the formal properties of hybrid reasoners are determined by those of the two components; in particular,the combined reasoner will be sound and com-plete if both components are sound and complete.From a practical point of view,DAML+OIL implementa-tions can choose to support some or all of the XML Schema datatypes.For supported datatypes,they can either imple-ment their own type checker/validater or rely on some exter-nal component.The job of a type checker/validater is simply to take zero or more data values and one or more datatypes, and determine if there exists any data value that is equal to every one of the specified data values and is an instance of every one of the specified data types.Extending RDF SchemaDAML+OIL is tightly integrated with RDFS:RDFS is used to express DAML+OIL’s machine readable specification,9 and RDFS provides the only serialisation for DAML+OIL. While the dependence on RDFS has some advantages in terms of the re-use of existing RDFS infrastructure and the portability of DAML+OIL ontologies,using RDFS to com-pletely define the structure of DAML+OIL is quite difficult as,unlike XML,RDFS is not designed for the precise spec-ification of syntactic structure.For example,there is no way in RDFS to state that a restriction(slot constraint)should consist of exactly one property(slot)and one class.The solution to this problem adopted by DAML+OIL is to define the semantics of the language in such a way that they give a meaning to any(parts of)ontologies that conform to the RDFS specification,including“strange”constructs such as restrictions with multiple properties and classes.The meaning given to strange constructs may,however,include strange“side effects”.For example,in the case of a restric-tion with multiple properties and classes,the semantics in-terpret this in the same way as a conjunction of all the con-straints that would result from taking the cross product of the specified properties and classes,but with the added(and probably unexpected)effect that all these restrictions must have the same interpretation(i.e.,are equivalent).DAML+OIL’s dependence on RDFS may also have con-sequences for the decidability of the language.Decidability is lost when cardinality constraints can be applied to proper-ties that are transitive,or that have transitive sub-properties. (Horrocks,Sattler,&Tobies1999).There is no way to for-mally capture this constraint in RDFS,so decidability in DAML+OIL depends on an informal prohibition of cardi-nality constraints on non-simple properties.DAML+OIL vs.OILFrom the point of view of language constructs,the differ-ences between OIL and DAML+OIL are relatively trivial. Although there is some difference in“keyword”vocabulary, there is usually a one to one mapping of constructors,and in the cases where the constructors are not completely equiva-lent,simple translations are possible.OIL also uses RDFS for its serialisation(although it also provides a separate XML-based syntax).Consequently, OIL’s RDFS based syntax would seem to be susceptible to the same difficulties as described above for DAML+OIL. However,in the case of OIL there does not seem to be an assumption that any ontology conforming to the RDFS meta-description should be a valid OIL ontology—presumably ontologies containing unexpected usages of the meta-properties would be rejected by OIL processors as the semantics do not specify how these could be translated into .Thus,OIL and DAML+OIL take rather differ-ent positions with regard to the layering of languages on the Semantic Web.Another effect of DAML+OIL’s tight integration with RDFS is that the frame structure of OIL’s syntax is much less evident:a DAML+OIL ontology is more DL-like in that it consists largely of a relatively unstructured collec-tion of subsumption and equality axioms.This can make it more difficult to use DAML+OIL with frame based tools such as Prot´e g´e(Grosso et al.1999)or OilEd(Bechhofer et al.2001)because the axioms may be susceptible to many different frame-like groupings.(Bechhofer,Goble,&Hor-rocks2001).The treatment of individuals in OIL is also very different from that in DAML+OIL.In thefirst place,DAML+OIL re-lies wholly on RDF for assertions involving the type(class) of an individual or a relationship between a pair of objects. In the second place,DAML+OIL treats individuals occur-ring in the ontology(in oneOf constructs or hasValue restrictions)as true individuals(i.e.,interpreted as single elements in the domain of discourse)and not as primitive concepts as is the case in OIL.This weak treatment of the oneOf construct is a well known technique for avoiding the reasoning problems that arise with existentially defined classes,and is also used,e.g.,in the C LASSIC knowledge representation system(Borgida&Patel-Schneider1994). Moreover,DAML+OIL makes no unique name assumption: it is possible to explicitly assert that two individuals are the same or different,or to leave their relationship unspecified. This treatment of individuals is very powerful,and justi-fies intuitive inferences that would not be valid for OIL,e.g., that persons all of whose countries of residence are Italy are kinds of person that have at most one country of residence: Person residence Italy residenceInference in DAML+OILAs we have seen,DAML+OIL is equivalent to a very ex-pressive DL.More precisely,DAML+OIL is equivalent to the DL(Horrocks,Sattler,&Tobies1999)with the addition of existentially defined classes(i.e.,the oneOf constructor)and datatypes(often called concrete domains in DLs(Baader&Hanschke1991)).This equivalence al-lows DAML+OIL to exploit the considerable existing body of description logic research to define the semantics of the language and to understand its formal properties,in par-ticular the decidability and complexity of key inference problems(Donini et al.1997);as a source of sound and complete algorithms and optimised implementation tech-niques for deciding key inference problems(Horrocks,Sat-tler,&Tobies1999;Horrocks&Sattler2001);and to use implemented DL systems in order to provide(partial) reasoning support(Horrocks1998a;Patel-Schneider1998; Haarslev&M¨o ller2001).A important consideration in the design of DAML+OIL was that key inference problems in the language,in partic-ular class consistency/subsumption,to which most other in-ference problems can be reduced,should be decidable,as this facilitates the provision of reasoning services.More-over,the correspondence with DLs facilitates the use of DL algorithms that are known to be amenable to optimised im-plementation and to behave well in realistic applications in spite of their high worst case complexity(Horrocks1998b; Haarslev&M¨o ller2001).Maintaining the decidability of the language requires cer-tain constraints on its expressive power that may not be ac-ceptable to all applications.However,the designers of the language decided that reasoning would be important if the full power of ontologies was to be realised,and that a pow-erful but still decidable ontology language would be a good starting point.Reasoning can be useful at many stages during the design, maintenance and deployment of ontologies.Reasoning can be used to support ontology design and to improve the quality of the resulting ontology.For example, class consistency and subsumption reasoning can be used to check for logically inconsistent classes and(possibly un-expected)implicit subsumption relationships(Bechhofer etal.2001).This kind of support has been shown to be par-ticularly important with large ontologies,which are often built and maintained over a long period by multiple authors.Other reasoning tasks,such as“matching”(Baader et al.1999)and/or computing least common subsumers(Baader &K¨u sters1998)could also be used to support“bottom up”ontology design,i.e.,the identification and description ofrelevant classes from sets of example instances.Like information integration(Calvanese et al.1998), ontology integration can also be supported by reason-ing.For example,integration can be performed usinginter-ontology assertions specifying relationships between classes and properties,with reasoning being used to com-pute the integrated hierarchy and to highlight any prob-lems/inconsistencies.Unlike some other integration tech-niques,this method has the advantage of being non-intrusivewith respect to the original ontologies.Reasoning with respect to deployed ontologies will en-hance the power of“intelligent agents”,allowing them todetermine if a set of facts is consistent w.r.t.an ontology,to identify individuals that are implicitly members of a givenclass etc.A suitable service ontology could,for example,allow an agent seeking secure services to identify a service requiring a userid and password as a possible candidate.ChallengesClass consistency/subsumption reasoning in DAML+OIL is known to be decidable(as it is contained in the C2fragmentoffirst order logic(Gr¨a del,Otto,&Rosen1997)),but manychallenges remain for implementors of“practical”reasoning systems,i.e.,systems that perform well with the kinds ofreasoning problem generated by realistic applications. Individuals Unfortunately,the combination of DAML+OIL individuals with inverse properties is sopowerful that it pushes the worst case complexity of theclass consistency problem from E XP T IME(for/OIL) to NE XP T IME.No“practical”decision procedure is cur-rently known for this logic,and there is no implementedsystem that can provide sound and complete reasoning for the whole DAML+OIL language.In the absence ofinverse properties,however,a tableaux algorithm has beendevised(Horrocks&Sattler2001),and in the absence of individuals(in extensionally defined classes),DAML+OILcan exploit implemented DL systems via a translation into (extended with datatypes)similar to the one used by OIL.It would,of course,also be possible to translateDAML+OIL ontologies into using OIL’s weaktreatment of individuals,but in this case reasoning with individuals would not be complete with respect to thesemantics of the language.This approach is taken by someexisting applications,e.g.,OilEd(Bechhofer et al.2001) Scalability Even without the oneOf constructor,class con-sistency reasoning is still a hard problem.Moreover,Web ontologies can be expected to grow very large,and with de-ployed ontologies it may also be desirable to reason w.r.t.a large numbers of class/property instances.There is good evidence of empirical tractability and scalability for implemented DL systems(Horrocks1998b; Haarslev&M¨o ller2001),but this is mostly w.r.t.logics that do not include inverse properties(e.g.,(Horrocks, Sattler,&Tobies1999)).Adding inverse properties makes practical implementations more problematical as several im-portant optimisation techniques become much less effec-tive.Work is required in order to develop more highly opti-mised implementations supporting inverse properties,and to demonstrate that they can scale as well as implemen-tations.It is also unclear if existing techniques will be able to cope with large numbers of class/property instances(Hor-rocks,Sattler,&Tobies2000).Finally,it is an inevitable consequence of the high worst case complexity that some problems will be intractable,even for highly optimised implementations.It is conjectured that such problems rarely arise in practice,but the evidence for this conjecture is drawn from a relatively small number of applications,and it remains to be seen if a much wider range of Web application domains will demonstrate similar char-acteristics.New Reasoning Tasks So far we have mainly discussed class consistency/subsumption reasoning,but this may not be the only reasoning problem that is of interest.Other tasks could include querying,explanation,matching,computing least common subsumers,etc.Querying in particular may be important in Semantic Web applications.Some work on query languages for DLs has already been done(Calvanese, De Giacomo,&Lenzerini1999;Horrocks&Tessaris2000), and work is underway on the design of a DAML+OIL query language,but the computational properties of such a lan-guage,either theoretical or empirical,have yet to be deter-mined.Explanation may also be an important problem,e.g.,to help an ontology designer to rectify problems identified by reasoning support,or to explain to a user why an applica-tion behaved in an unexpected manner.As discussed above, reasoning problems such as matching and computing least common subsumers could also be important in ontology de-sign.DiscussionThere are other concerns with respect to the place DAML+OIL has in the Semantic Web.After DAML+OIL was developed,the W3C RDF Core Working Group devised a model theory for RDF and RDFS10,which is incompati-ble with the semantics of DAML+OIL,an undesirable state of affairs.Also,in late2001W3C initiated the Web On-tology working group11,a group tasked with developing an ontology language for the Semantic Web.DAML+OIL has been submitted to this working group as a starting point for a W3C recommendation on ontology languages.A W3C ontology language needs tofit in with other W3C recommendations even more than an independent DAML+OIL would.Work is thus needed to develop a se-mantic web ontology language,which the Web Ontologyworking group has tentatively name OWL,that layers bet-ter on top of RDF and RDFS.Unfortunately,the obvious layering(that is,using the same syntax as RDF and extending its semantics,just as RDFS does)is not possible.Such an extension results in se-mantic paradoxes—variants of the Russell paradox.These paradoxes arise from the status of all classes(including DAML+OIL restrictions)as individuals,which requires that many restrictions be present in all models;from the sta-tus of the class membership relationship as a regular prop-erty(rdf:type);from the ability to make contradictory state-ments;and from the ability to create restrictions that refer to themselves.In an RDFS-compliant version of DAML+OIL, a restriction that states that its instances have no rdf:type re-lationships to itself is not only possible to state,but exists in all models,resulting in an ill-formed logical formalism. The obvious way around this problem,that of using non-RDF syntax for DAML+OIL restrictions,appears to be meeting with considerable resistance so either further edu-cation or some other solution is needed.ConclusionWe have discussed a number of fundamental design deci-sions underlying the design of DAML+OIL,in particular its foundation in Description Logic,its use of datatypes from XML Schema,its sometimes problematic layering on top of RDF Schema,and its deviations from its predecessor OIL. We have also described how various aspects of the language are motivated by the desire for tractable reasoning facilities. Although a number of challenges remain,DAML+OIL has considerable merits.In particular,the basic idea of having a formally-specified web language that can repre-sent ontology information will go a long way towards allow-ing computer programs to interoperate without pre-existing, outside-of-the-web agreements.If this language also has an effective reasoning mechanism,then computer programs can manipulate this interoperability information themselves, and determine whether a common meaning for the informa-tion that they pass back and forth is present.ReferencesBaader,F.,and Hanschke,P.1991.A schema for integrating concrete domains into concept languages.In Proc.of IJCAI-91, 452–457.Baader,F.,and K¨u sters,puting the least com-mon subsumer and the most specific concept in the presence of cyclic-concept descriptions.In Proc.of KI’98,129–140. Springer-Verlag.Baader,F.;K¨u sters,R.;Borgida,A.;and McGuinness,D.L. 1999.Matching in description logics.J.of Logic and Compu-tation9(3):411–447.Bechhofer,S.;Horrocks,I.;Goble,C.;and Stevens,R.2001. OilEd:a reason-able ontology editor for the semantic web.In Proc.of the Joint German/Austrian Conf.on Artificial Intelli-gence(KI2001),396–408.Springer-Verlag.Bechhofer,S.;Goble,C.;and Horrocks,I.2001.DAML+OIL is not enough.In Proc.of the First Semantic Web Working Sym-posium(SWWS’01),151–159.CEUR Electronic Workshop Pro-ceedings,/.Berners-Lee,T.1999.Weaving the Web.San Francisco:Harper. Borgida,A.,and Patel-Schneider,P.F.1994.A semantics and complete algorithm for subsumption in the CLASSIC description logic.J.of Artificial Intelligence Research1:277–308. Calvanese,D.;De Giacomo,G.;Lenzerini,M.;Nardi,D.;and Rosati,rmation integration:Conceptual modeling and reasoning support.In Proc.of CoopIS’98,280–291. Calvanese,D.;De Giacomo,G.;and Lenzerini,M.1999.An-swering queries using views in description logics.In Proc. of DL’99,9–13.CEUR Electronic Workshop Proceedings, /V ol-22/.Decker,S.;van Harmelen,F.;Broekstra,J.;Erdmann,M.;Fensel, D.;Horrocks,I.;Klein,M.;and Melnik,S.2000.The semantic web:The roles of XML and RDF.IEEE Internet Computing4(5). Donini,F.M.;Lenzerini,M.;Nardi,D.;and Nutt,W.1997.The complexity of concept rmation and Computation 134:1–58.Fensel,D.;van Harmelen,F.;Horrocks,I.;McGuinness,D.L.; and Patel-Schneider,P.F.2001.OIL:An ontology infrastructure for the semantic web.IEEE Intelligent Systems16(2):38–45. Gr¨a del,E.;Otto,M.;and Rosen,E.1997.Two-variable logic with counting is decidable.In Proc.of LICS-97,306–317.IEEE Computer Society Press.Grosso,W.E.;Eriksson,H.;Fergerson,R.W.;Gennari,J.H.; Tu,S.W.;and Musen,M.A.1999.Knowledge modelling at the millenium(the design and evolution of prot´e g´e-2000).In Proc.of Knowledge acqusition workshop(KAW-99).Haarslev,V.,and M¨o ller,R.2001.High performance reasoning with very large knowledge bases:A practical case study.In Proc. of IJCAI-01.Hollunder,B.,and Baader,F.1991.Qualifying number restric-tions in concept languages.In Proc.of KR-91,335–346. Horrocks,I.,and Sattler,U.2001.Ontology reasoning in the(D)description logic.In Proc.of IJCAI-01.Morgan Kaufmann.Horrocks,I.,and Tessaris,S.2000.A conjunctive query language for description logic Aboxes.In Proc.of AAAI2000,399–404. Horrocks,I.;Sattler,U.;and Tobies,S.1999.Practical reasoning for expressive description logics.In Ganzinger,H.;McAllester, D.;and V oronkov,A.,eds.,Proc.of LPAR’99,161–180.Springer-Verlag.Horrocks,I.;Sattler,U.;and Tobies,S.2000.Reasoning with individuals for the description logic.In Proc.of CADE-17,LNAI,482–496.Horrocks,I.1998a.The FaCT system.In de Swart,H.,ed.,Proc. of TABLEAUX-98,307–312.Springer-Verlag.Horrocks,ing an expressive description logic:FaCT orfiction?In Proc.of KR-98,636–647.McGuinness,D.L.1998.Ontological issues for knowledge-enhanced search.In Proc.of FOIS,Frontiers in Artificial Intelli-gence and Applications.IOS-press.McIlraith,S.;Son,T.;and Zeng,H.2001.Semantic web services. IEEE Intelligent Systems16(2):46–53.Patel-Schneider,P.F.1998.DLP system description.In Proc. of DL’98,87–89.CEUR Electronic Workshop Proceedings, /V ol-11/.。
比较句论文:留学生比较句的习得与偏误分析【中文摘要】比较句是对外汉语语法教学的重要组成部分,同时也是留学生日常交际中常用句式之一。
在对外汉语比较句教学中,留学生对比较句掌握得不是特别好,其主要表现在留学生在比较句习得过程和使用时都出现了不同程度的偏误,所以本文试对留学生比较句的习得与产生的偏误进行研究,希望能对比较句的教学有所建议和帮助,将研究的结论更好的应用于比较句教学。
本文主要运用第二语言习得理论,借鉴中介语理论、认知理论和偏误分析理论,对教材和语料库中相关句式及平时教学中收集的语料进行分析,得出留学生习得常用比较句式的一般规律和顺序,同时总结偏误,将偏误进行分类,从而对对外汉语比较句教学提出一些建议。
本文绪论部分主要回顾了比较在本体研究方面的相关理论,分别从比较范畴、比较句的句法结构、语义限制等方面对“比”字句及常用比较句式的研究理论进行了探讨。
从对外汉语教学角度总结比较句的研究成果,从中找出可以用来指导比较句教学的相关理论。
第一章结合前文的理论基础,以《对外汉语教学语法大纲》中所列举的常用比较句式为研究对象,对对外汉语教学中常用的口语教材进行分析。
通过分析了解口语教材中比较句式的编排特点,找出学生习得比较句的顺序,并对教材中介绍的比较句式和不同类型的“比”字句进行了研究,分析各句式的特点。
由于口语教材所具有的特殊性,文章对比较句式的省略形式和条件限制也做了简单的说明。
第二章在对各比较句式特征进行研究的基础上,对“HSK动态作文语料库”中的偏误句进行分析和总结。
对学生在使用比较句式时出现的偏误句,从比较值的限制及句法结构等方面进行了分类,并对每一类型的偏误进行分析。
第三章结合中介语、偏误分析理论等相关理论,对偏误产生的原因进行分析,究其产生的原因,从学生的学习策略、语泛化及母语负迁移等方面进行了系统地分析。
总结全文的分析结果,找到比较句教学中所存在的问题,用对比分析的方法对学生在习得比较句过程中可能出现的问题进行预测,并提出相应的解决办法及教学建议。
Y. Gil et al. (Eds.): ISWC 2005, LNCS 3729, pp. 262 – 276, 2005.© Springer-Verlag Berlin Heidelberg 2005 Ontology Design Patterns for Semantic Web ContentAldo GangemiLaboratory for Applied Ontology, ISTC-CNR, Rome, Italy a.gangemi@r.itAbstract. The paper presents a framework for introducing design patterns thatfacilitate or improve the techniques used during ontology lifecycle. Some dis-tinctions are drawn between kinds of ontology design patterns. Some content-oriented patterns are presented in order to illustrate their utility at different de-grees of abstraction, and how they can be specialized or composed. The pro-posed framework and the initial set of patterns are designed in order to functionas a pipeline connecting domain modelling, user requirements, and ontology-driven tasks/queries to be executed.1 IntroductionThroughout experiences in ontology engineering projects 1 at the Laboratory forApplied Ontology (LOA), typical conceptual patterns have emerged out of differentdomains, for different tasks, and while working with experts having heterogeneous backgrounds. For example, a simple participation pattern (including objects taking part in events) emerges in domain ontologies as different as enterprise models [11], legal norms [30], sofware management [17], biochemical pathways [9], and fishery techniques [10]. Other, more complex patterns have also emerged in the same disparate domains: the role<->task pattern, the information<->realization pattern, the description<->situation pattern, the design<->object pattern, the attribute parametrization pattern , etc.Those emerging patterns are extremely useful in order to acquire, develop, andrefine the ontologies from either experts or documents. Often it’s even the case that a community of expertise develops its own conceptual pattern, usually of an informal1For example, in the projects IKF : /About.htm,FOS : /agris/aos/, and WonderWeb : . http://www.loa-cnr.it 2 2,33The lifecycle of ontologies over the Semantic Web involves different techniques, ranging from manual to automatic building, refinement, merging, mapping, annota-tion, etc. Each technique involves the specification of core concepts for the popula-tion of an ontology, or for its annotation, manipulation, or management[7][9][10][11][14][19]. For example, an OWL ontology of gene expression for bioin-formatics can be manually built by encoding experts’ conceptual patterns [20], or can be automatically learnt e.g. out of a textual corpus by encoding natural language pat-terns, then refined according to conceptual patterns provided by experts [3], and fi-nally annotated with meta-level concepts for e.g. confidence measurement, argumen-tation, etc.Ontology Design Patterns for Semantic Web Content 263 diagrammatic sort, which can be reengineered as a specialization of the mentioned patterns, for the sake of an ontology project. In some situations, experts do not grasp the utility of ontologies until they realize that an ontology can encode effectively a domain conceptual pattern. Once experts realize it, they usually start discussions on how to improve their own rational procedures by means of ontology engineering techniques!Following this evidence, for two years a set of conceptual patterns has been usedfor practical, domain ontology design while still being based on a full-fledged, richlyaxiomatic ontology (currently DOLCE and its extension s [14][15]). A major attention has been devoted to patterns that are expressible in OWL [18], and are therefore easily applicable to the Semantic Web community.Independently, in 2004 the W3C has started a working group on Semantic WebBest Practices and Deployment, including a task force on Ontology Engineering Patterns (OEP) [21], which has produced some interesting OWL design patterns that are close, from the logical viewpoint, to some of the ontology design patterns that the LOA has been developing.In this paper a notion of pattern for ontology design is firstly introduced,contrasting it to other sibling notions. Then a template to present ontology design patterns that are usable to assist or improve Semantic Web ontology engineering is sketched, focusing on patterns that can be encoded in OWL(DL). Some distinctions are drawn between patterns oriented to individuals, to classes or properties, to logical primitives, and to argumentation. Some content-oriented patterns are discussed in order to illustrate that notion at different degrees of abstraction, and how they can be composed. Finally, some conclusions are provided.2 Some Bits of HistoryThe term “pattern” appears in English in the 14th century and derives from Middle Latin “patronus” (meaning “patron”, and, metonymically, “exemplar”, something proposed for imitation). As Webster’s puts it, a pattern has a set of senses that show a reasonable degree of similarity (see my italics): «a) a form or model proposed for imi-tation , b) something designed or used as a model for making things , c) a model for making a mold , d) an artistic, musical, literary, or mechanical design or form , e) a natural or chance configuration , etc., and, f) a discernible coherent system based on the intended interrelationship of component parts».In the seventies, the architect and mathematician Christopher Alexander introducedthe term “design pattern” for shared guidelines that help solve design problems. In [1] he argues that a good design can be achieved by means of a set of rules that are “packaged” in the form of patterns, such as “courtyards which live”, “windows place”, or “entrance room”. Design patterns are assumed as archetypal solutions to design problems in a certain context.Taking seriously the architectural metaphor, the notion has been eagerly endorsedby software engineering [2][6][13], where it is used as a general term for formatted guidelines in software reuse, and, more recently, has also appeared in requirements Cf. Online Etymology Dictionary: ) 4In software engineering, formal approaches to design patterns, based on dedicated ontologies, are being investigated, e.g. in so-called semantic middleware [17].455264 A.Gangemianalysis, conceptual modelling, and ontology engineering [12][20][21][24][29]. Traditional desing patterns appear more like a collection of shortcuts and suggestions related to a class of context-bound problems and success stories. In recent work, there seems to be a tendency towards a more formal encoding of design patterns (notably in [2][12][13][19]). [24] also addresses the issue of ontology design patterns for the Semantic Web, taking a foundational approach that is complementary with that presented here.2.1 The Elements of a Design Pattern from Software to Ontology Engineering For space reasons, a review of the existing literature, and how this proposal differs from it, is not attempted here. Instead, the typical structure of design patterns in soft-ware engineering is presented, and contrasted with typical patterns in ontology engi-neering and with the so-called content patterns.The mainstream approach in Software Engineering (SE) patterns is to use a template that can be similar to the following one (adapted from [22]), used to address a problem of form design in user interfaces:Slot ValueType UI formExamples • Tax forms• Job application forms• Ordering merchandise through a catalogContext The user has to provide preformatted information, usually short (non-narrative) answers to questionsProblem How should the artifact indicate what kind of information should be supplied, and the extent of it?Forces • The user needs to know what kind of information to provide.• It should be clear what the user is supposed to read, and what to fillin.•The user needs to know what is required, and what is optional.•Users almost never read directions.•Users generally do not enjoy supplying information this way, and aresatisfied by efficiency, clarity, and a lack of mistakes.Solution Provide appropriate “blanks” to be filled in, which clearly and cor-rectly indicate what information should be provided. Visually indicatethose editable blanks consistently, such as with subtle changes in back-ground color, so that a user can see at a glance what needs to be filled in.Label them with clear, short labels that use terminology familiar to theuser; place the labels as close to the blanks as is reasonable. Arrange themall in an order that makes sense semantically, rather than simply groupingthings by visual appearanceOntology Design Patterns for Semantic Web Content 265 The slots used here follow quite closely those suggested by Alexander: given an artifact type, the pattern provides examples of it, its context, the problem addressed by the pattern, the involved “forces” (requirements and constraints), and a solution.In ontology engineering, the nature of the artifact (ontologies) requires a more formal presentation of patterns.5 For example, the pattern for “classes as property values” [16] produced by the OEP task force [21] can be sketched as follows (only an excerpt of the pattern is shown here):Slot ValueGeneral issue It is often convenient to put a class (e.g., Animal) as a property value (e.g., topic or book subject) when building an ontology. While OWL Full and RDF Schema do not put any restriction on using classes as property values, in OWL DL and OWL Lite most properties cannot have classes as their values.Use case example Suppose we have a set of books about animals, and a catalog of these books. We want to annotate each catalog entry with its subject, which is a particular species or class of animal that the book is about. Further, we want to be able to infer that a book about African lions is also a book about lions. For example, when retrieving all books about lions from a repository, we want books that are annotated as books about African lions to be included in the results.Notation In all the figures below, ovals represent classes and rectangles represent individuals. The orange color signifies classes or individuals that arespecific to a particular approach. Green arrows with green labels areOWL annotation properties. We use N3 syntax to represent the exam-ples.Approaches Approach 1: Use classes directly as property valuesIn the first approach, we can simply use classes from the subject hierar-chy as values for properties (in our example, as values for the dc:subjectproperty). We can define a class Book to represent all books.Consideratio-ns • The resulting ontology is compatible with RDF Schema and OWL Full, but it is outside OWL DL and OWL Lite.• This approach is probably the most succinct and intuitive among all the approaches proposed here.• Applications using this representation can directly access the informa-tion needed to infer that Lion (the subject of the LionsLifeIn-ThePrideBook individual) is a subclass of Animal and that Afri-canLion (the subject of the TheAfricanLionBook individual) is a sub-class of Lion.OWL code (N3 syntax) default:BookAboutAnimalsa owl:Class ;rdfs:subClassOf owl:Thing ;rdfs:subClassOf[ a owl:Class ;owl:unionOf ([ a owl:Restriction ;266 A.GangemiSlot Valueowl:onProperty dc:subject ;owl:someValuesFrom default:Animal] [ a owl:Restriction ;owl:onProperty dc:subject ;owl:someValuesFrom[ a owl:Restriction ;owl:hasValue default:Animal ;owl:onProperty rdfs:subClassOf] ]) ]As evidenced from the examples, an ontology engineering pattern includes some formal encoding, due to the nature of ontological artifacts. OEP slots seem to “merge” some SE slots: examples and context are merged in the “use case”, while the slot “forces” is missing, except for some “considerations” related to the “solution” slot (called “approach” in OEP).In this paper, a step towards the encoding of conceptual, rather than logical design patterns, is made. In other words, while OEP is proposing patterns for solving design problems for OWL, independently of a particular conceptualization, this paper proposes patterns for solving (in OWL or another logical language) design problems for the domain classes and properties that populate an ontology, therefore addressing content problems.3 Conceptual Ontology Design Patterns3.1 Generic Use CasesThe first move towards conceptual ontology design patterns requires the notion of a “Generic Use Case” (GUC), i.e. a generalization of use cases that can be provided as examples for an issue of domain modelling. Differently from the “artifact type” slot in SE patterns and from the “issue” slot in OEP patterns, a GUC should be the expres-sion of a recurrent issue in many domain modelling projects, independently of the particular logical language adopted. For example, this is a partial list of the recurrent questions that arise in the modelling practice during an ontology project:•Who does what, when and where?•Which objects take part in a certain event?•What are the parts of something?•What’s an object made of?•What’s the place of something?•What’s the time frame of something?•What technique, method, practice is being used?•Which tasks should be executed in order to achieve a certain goal?•Does this behaviour conform to a certain rule?•What’s the function of that artifact?•How is that object built?Ontology Design Patterns for Semantic Web Content 267 •What’s the design of that artifact?•How did that phenomenon happen?•What’s your role in that transaction?•What that information is about? How is it realized?•What argumentation model are you adopting for negotiating an agreement?•What’s the degree of confidence that you give to this axiom?Being generic at the use case level allows us to decouple, or to refactor the design problems of a use case, by composing different GUCs. Ideally, a library of GUCs should include a hierarchy from the most generic to the most specific ones, and from the “purest” (like most of the examples above) to the most articulated and applied ones (e.g.: “what protein is involved in the Jack/Stat biochemical pathway?”).The intuition underlying GUC hierarchies is based on a methodological observation: ontologies must be built out of domain tasks that can be captured by means of competency questions [11]. A competency question is a typical query that an expert might want to submit to a knowledge base of its target domain, for a certain task. In principle, an accurate domain ontology should specify all and only the conceptualizations required in order to answer all the competency questions formulated by, or acquired from, experts.A GUC can thus be seen as the preliminary motivation to build the pipeline connecting modelling requirements, expected queries (semantic services), and ontology population. Following the distinction between tasks, problem-solving methods, and ontologies that underlies recent architectures for Semantic Web Services [26], GUCs can be used to access at a macroscopic level (partly similar to “use-case diagrams” in UML) the profile (or registries) for a service, the available ontology design patterns (see next section), as well as existing ontologies and knowledge bases. GUC taxonomy is not addressed here for space reasons.3.2 Features of Conceptual Ontology Design PatternsA GUC cannot do much as a guideline, unless we are able to find formal patterns that encode it. A formal pattern that encodes a GUC is called here a Conceptual (or Con-tent) Ontology Design Pattern (CODeP).CODePs are characterized here in a twofold way. Firstly, through an intuitive set of features that a CODeP should have; secondly, through a minimal semantic characterization, and its formal encoding, with the help of some examples.•A CODeP is a template to represent, and possibly solve, a modelling problem.•A CODeP “extracts” a fragment of either a foundational [14] or core [8] ontology, which constitutes its background. For example, a connected path of two relations and three classes (Ax ∧ By ∧ Cz ∧ Rxy ∧ Syz) can be extracted because of its do-main relevance. Thus, a CODeP lives in a reference ontology, which provides its taxonomic and axiomatic context. A CODeP is axiomatized according to the frag-ment it extracts. Since it depends on its background, a CODeP inherits the axioma-tization (and the related reasoning service) that is already in place.•Mapping and composition of patterns require a reference ontology, in order to check the consistency of the composition, or to compare the sets of axioms that are to be mapped. Operations on CODePs depend on operations on the reference ontologies. However, for a pattern user, these operations should be (almost) invisible.268 A.Gangemi•A CODeP can be represented in any ontology representation language whatsoever (depending on its reference ontology), but its intuitive and compact visualization seems an essential requirement. It requires a critical size, so that its diagrammatical visulization is aesthetically acceptable and easily memorizable.•A CODeP can be an element in a partial order, where the ordering relation requires that at least one of the classes or relations in the pattern is specialized. A hierarchy of CODePs can be built by specializing or generalizing some of the elements (either classes or relations). For example, the participation pattern can be specialized to the taking part in a public enterprise pattern.•A CODeP should be intuitively exemplified, and should catch relevant, “core” no-tions of a domain. Independently of the generality at which a CODeP is singled out, it must contain the central notions that “make rational thinking move” for an expert in a given domain for a given task.•A CODeP can be often built from informal or simplified schemata used by domain experts, together with the support of other reusable CODePs or reference ontolo-gies, and a methodology for domain ontology analysis. Typically, experts sponta-neously develop schemata to improve their business, and to store relevant know-how. These schemata can be reengineered with appropriate methods (e.g. [10]).•A CODeP can/should be used to describe a “best practice” of modelling.•A CODeP can be similar to a database schema, but a pattern is defined wrt to a ref-erence ontology, and has a general character, independent of system design.4 Examples of CODePs4.1 Some Foundational and Core PatternsSome examples of CODePs are shown here, but many others have been built or are being investigated. Due to space restrictions, the presentation is necessarily sketchy.As proposed in the previous section, a CODeP emerges out of an existing or dedicated reference ontology (or ontologies), since it needs a context that facilitates its use, mapping, specialization, and composition.Fig. 1. The basic DOLCE design pattern: participation at spatio-temporal locationOntology Design Patterns for Semantic Web Content 269A first, basic example (Fig. 1) is provided by the participation pattern, extracted from the DOLCE [14] foundational ontology, developed within the WonderWeb Project [5]. It consists of a “participant-in” relation between objects and events, and assumes a time indexing for it. Time indexing is provided by the temporal location of the event at a time interval, while the respective spatial location at a space region is provided by the participating object.Some inferences are automatically drawn when composing the participation CODeP with the part CODeP (not shown here, see [14]). For example, if an object constantly participates in an event, a temporary part of that object (a part that can be detached), will simply participate in that event, because we cannot be sure that the part will be a part at all times the whole participates. For example, we cannot infer for each member of a gang that she participated in a crime, just because she is a member.An alternative CODeP (Fig. 2) for time-indexed participation can be given by reifying the participation relation (in OWL a ternary relation cannot be expressed conveniently). The reified participation pattern features a kind of “situation” (see next example), called time-indexed-participation, which is a setting for exactly one object, one event, and one time interval. This simple reification pattern can be made as complex as needed, by adding parameters, more participants, places, etc.A third, more complex example, is the Role<->Task CODeP (Fig. 3). This CODeP is based on an extension of DOLCE, called D&S (Descriptions and Situations) [9][15], partly developed within the Metokis Project [4]. D&S provides a vocabulary and an axiomatization to type-reified [27] classes and relations (“concepts” and “descriptions”), and to token-reified [27] tuples (“situations”; for a semantics of D&S, see [28]).Fig. 2. A pattern for reification of time-indexed relations (in this case, participation): a situation (like time-indexed participation) is a setting for an event, the entities participating in that event, and the time interval at which the event occursIn practice, the Role<->Task pattern allows the expression, in OWL(DL), of the temporary roles that objects can play, and of the tasks that events/actions allow to execute. The reified relation specifying roles and tasks is a description, the reified tuple that satisfies the relation for certain individual objects and events is called situation. Roles can have assigned tasks as modal targets. This CODeP is very expressive, and can be specialized in many domains, solving design issues that are quite hard without reification. For example, the assignments of tasks to role-players in a workflow can be easily expressed, as well as plan models [28].270 A.GangemiFig. 3. A pattern for roles and tasks defined by descriptions and executed within situations By composing the Role<->Task pattern with the Collection<->Role pattern (not shown here), and specializing such composition to the domain of material design, we obtain the so-called Design<->Artifact CODeP (Fig. 4). This pattern is very expressive and quite complex. Starting from Role<->Task, and Collection<->Role, and specializing objects to material artifacts, descriptions to designs, situations to design materialization, and substituting tasks with functions, we can conceive of a functional unification relation holding between a design model and a material artifact. The internal axiomatization operates by unifying the collection of “relevant” components (“proper parts”) of the material artifact within a “collection”, where each component plays a functional role defined by the design model.Fig. 4. A pattern for talking about relations between design models and material artifacts The design materialization keeps together the actual physical components of an individual material artifact. This CODeP can be easily specialized for manufacturing, commercial warehouses, etc.The previous CODePs are foundational. An example of a core CODeP is instead provided here with reference to the NCI ontology of cancer research and treatment [23] (Fig. 5). It specializes the foundational Role<->Task CODeP (Fig. 3).Ontology Design Patterns for Semantic Web Content 271Fig. 5. A core pattern for chemotherapy, specializing the Role<->Task CODeP4.2 How to Introduce a CODePA template can be used to annotate CODePs, to share them in pre-formatted docu-ments, to contextualize them appropriately, etc. Here the following frame is proposed, and presented through the previous example from the NCI ontology [23]: Slot ValueGeneric usecase (GUC)Chemicals playing roles in biological processes for chemotherapy.Local use case(s) Various chemical agents, mostly drugs, are used to control biological processes within a chemotherapeutical treatment. When talking about drugs and processes, there is a network of senses implying a dependence on roles and functions (or tasks) within a clinical treatment.Intended meanings include the possible functional roles played by certain substances, as well as the actual administration of amounts of drugs for controlling actually occurring biological processes. Therefore, both class- and instance-variables are present in the maximal relation for this pattern.LogicaddressedOWL, DL speciesReferenceontologiesDOLCE-Lite-Plus, NCI OntologySlot Value SpecializedCODePRole<->TaskComposed CODePs Time-Indexed-Participation, Concept<->Description, Description<->SituationFormal relation rChemical_or_Drug_Plays_Role_in_Biological_Process(,ψ,x,y,t, c1,c2,d,s), where (x) is a chemical agent class, ψ(y) is a biological process class, t is a time interval, c1 and c2 are two reified intensional concepts, d is a reified intensional relation, and s is a reified extensional relation.Sensitive axioms rChemical_or_Drug_Plays_Role_in_Biological_Process(,ψ) =df ∀x,y,t((x) ∧ψ(y) ∧ participates-in(x,y,t) ∧ Chemical-Agent(x) ∧Biological-Process(y) ∧ Time-Interval(t)) ↔∃c1,c2,d(CF(x,c1,t) ∧MT(c1,c2) ∧ CF(y,c2,t) ∧ DF(d,c1) ∧ DF(d,c2) ∧∀s(SAT(s,d)) ↔(SETF(s,x) ∧ SETF(s,y) ∧ SETF(s,t))Explanation Since OWL(DL) does not support relations with >2 arity, reification is required. The Description<->Situation pattern provides typingfor such reification.Since OWL(DL) does not support classes in variable position, weneed reification for class-variables. The Concept<->Descriptionpattern provides typing for such reification.Similarly, since participation is time-indexed, we need the time-indexed-participation pattern, which is here composed with theprevious two patterns (time indexing appears in the setting of thegeneral treatment situation).OWL(DL) encoding (abstract syntax) Class(Chemical_Plays_Role_in_Bio_Process completeDescriptionrestriction(defines someValuesFrom(Chemical-Agent))restriction(defines someValuesFrom(Biological-Task)))Class(Chemical-Agent completeRolerestriction(defined-bysomeValuesFrom(Chemical_Plays_Role_in_Bio_Process))restriction(classifies allValuesFrom(Substance))restriction(modal-target someValuesFrom(Biological-Task))) Class(Biological-Task completeTaskrestriction(classifies allValuesFrom(Biological-Process))restriction(modal-target-of someValuesFrom(Chemical-Agent))) Class(Chemical-in-Biological-Process_Situation completeφφφφSlot ValueSituationrestriction(satisfiessomeValuesFrom(Chemical_Plays_Role_in_Bio_Process))restriction(setting-for someValuesFrom(Substance))restriction(setting-for someValuesFrom(Biological-Process))restriction(setting-for someValuesFrom(Time-Interval)))ClassdiagramThe CODeP frame consists of:•Two slots for the generic use case, and the local use cases, which includes a de-scription of context, problem, and constraints/requirements.•Two slots for the addressed logic, and the reference ontologies used as a back-ground for the pattern.•Two slots for -if any- the specialized pattern and the composed patterns.•Two slots for the maximal relation that encodes the case space, and its intended axiomatization: a full first-order logic with meta-level is assumed here, but the slot can be empty without affecting the functionality of a CODeP frame.•Two slots for explanation of the approach, and its encoding in the logic of choice.•A last slot for a class diagram that visually reproduces the approach.The frame for introducing CODePs can be easily encoded in XSD or in richer frameworks, like semantic web services (e.g. [25]) or knowledge content objects [26], for optimal exploitation within Semantic Web technologies. The high reusability of CODePs and their formal and pragmatic nature make them suitable not only for isolated ontology engineering practices, but ideally in distributed, collaborative environments like intranets, the Web or the Grid.CODePs can also be used to generate intuitive, friendly UIs, which can present the user with only the relevant pattern diagram, avoiding the awkward, entangled graphs currently visualized for medium-to-large ontologies.5 ConclusionsConceptual Ontology Design Patterns (CODePs) have been introduced as a useful resource and design method for engineering ontology content over the Semantic Web. CODePs are distinguished from architectural, software engineering, and logic-oriented design patterns, and a template has been proposed to describe, visualize, and make operations over them.。