Ontogator combining view- and ontology-based search with semantic browsing

ontology的释译【摘要】ontology是西方哲学的奠基性范畴，通过对其起源及国内哲学界释译梳理发现，国内外学者对它的翻译和诠释存在诸多争议。

由此，笔者认为，当代国内哲学界对西方哲学某些精深部分的把握，并非如我们想象的那样容易。

【关键词】ontology；诠释；翻译；哲学ontology这个词在国内外的解释翻译甚多，它的研究对象、任务含有多义性，有点不可言说的味道，但我们还要说。

为此要把哲学史上和国内近现代关于它的研究理顺一下，方便我们探讨。

一、ontology的产生及定义最先构成ontology的是德国人郭克兰纽，像一部分表示学科的词语一样，它也是由希腊文构成的。

如biology，sociology这类词分别由词干bio、socio结合词尾-logy构成，ontology是由onto加上-logy构成，显而易见是关于onto的学问。

虽名称出现，但具体的定义、概念却没出现。

我们读到关于ontology的定义，见于黑格尔的《哲学史讲演录》--本体论，论述各种抽象的、完全普遍的哲学范畴，如"有"以及"有"之成为一和善，在这个抽象的形而上学中近一步产生出偶性、实体、因果、现象等范畴。

再看"百科全书"关于ontology的定义，笔者按俞宣孟对《不列颠百科全书》（第15版）中的ontology的翻译：关于"是"本身，即关于一切实在的基本性质的理论或研究。

这个术语直到17世纪时才首次拼造出来，然而本体论同公元前4世纪亚里士多德所界定的"第一哲学"或形而上学同义，由于后来形而上学包括其他的研究（例如，哲学的宇宙论和心理学），本体论就毋宁指对"是"的研究了。

本体论在近代哲学中成为显学，是由于德国理性主义者克里斯蒂?沃尔夫，以他看，本体论是走向关于诸"是者"之本质的必然真理的演绎的学说。

第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 的定义：Ontology 是⼀种能在语义和知识层次上描述信息系统的概念模型建模⼯具。

Ontology 是对概念模型的明确的、形式化的、可共享的规范。

这包含4层含义：概念模型( conceptualization)、明确(explicit)、形式化( formal)和共享(share)。

概念模型：指通过抽象出客观世界中⼀些现象( Phenomenon)的相关概念⽽得到的模型。

概念模型所表现的含义独⽴于具体的环境状态。

明确：指所使⽤的概念及使⽤这些概念的约束都有明确的定义。

形式化：指Ontology 是计算机可读的(即能被计算机处理)。

共享：指Ontology 中体现的是共同认可的知识, 反映的是相关领域中公认的概念集,即Ontology 针对的是团体⽽⾮个体的共识。

Ontology 的⽬标是捕获相关领域的知识,提供对该领域知识的共同理解,确定该领域内共同认可的词汇,并从不同层次的形式化模式上给出这些词汇(术语)和词汇间相互关系的明确定义。

补充1：在与领域的本体概念计算机科学信息科学在与领域，理论上，本体是指⼀种“形式化的，对于共享概念体系的明确⽽⼜详细的说明”。

本体提供的是⼀种共享词表，也就是特定领域之中那些存在着的或概念及其属性和；或者说，本体就是⼀种特殊类型的，具有结构化的特点，且更加适合于在之中使⽤；或者说，本体实际上就是对特定之中某套及其相互之间的形式化表达（formal representation）。

计算机科学信息科学对象类型相互关系术语集计算机系统领域概念关系⼆、Ontology 的建模元语Perez 等⼈认为Ontology 可以按分类法来组织,他归纳出Ontology 包含5个基本的建模元语(Modeling Primitive)。

这些元语分别为：类(classes),关系(relations),函数(functions),公理(axioms)和实例(instances)。

2006年1月湖南师范大学社会科学学报V01．35N o．1第35卷第l期J o u ma l of S0c i a l Scierlce of H哪锄Nor ma】Uni ver sity J粕．，2006巴门尼德ontology浅释张红霞1，李海青2(1．中国石油大学人文社会科学学院，山东东营257061；2．北京师范大学哲学与社会学学院，北京100875)摘要：巴门尼德哲学是西方ontology的缘起，但对其思想的解释却极不统一。

基于思维的时代性原则，通过对古希腊哲学内在演进逻辑的考察，发现巴门尼德所谓的eon就是指本质，他认为只有本质才具有实在性。

但由于抽象思维水平的限制，他并没有对此作出清楚的表述。

反而由于语言的形象化妨碍了人们对其哲学自身的理解。

巴门尼德的0Iltolo删实际上内蕴着现象与本质等多重的矛盾关系。

关键词：0ntolo灯；是；本质中图分类号：B12文献标识码：A文章编号：1000-2529(2006)01．00肄04巴门尼德哲学是西方0ncolog)，的开端，意义、影响之深远动词形式，其希腊文主动语态现在称述式单数第三人称，相自不待言。

然对其残篇如何理解与翻译国内外学界却分歧当于英文的is，eiIlai是其不定式，相当于to be，e o n是o n的早甚大，比如e s血的内涵与译法。

笔者以为，要真正把握巴门期写法，是第一人称单数eiIlli的中性分词。

在上面一段引文尼德思想的精义，首先必须依据正确的方法论原则。

其一，中，对于把握巴门尼德残篇最关键的是对eiIlai的理解。

据美对其思想必须放在古希腊哲学的初始阶段予以考察，既不要国学者卡恩考证，在希腊文中，eil】ai是最普遍的动词，有三种贬低，但也不要夸大其抽象与深奥程度。

特定的时代决定了主要用法：系词用法、存在用法、断真用法；其中，系词用法最巴门尼德哲学的特定含义与缺陷。

其二，马克思在分析人类普遍。

下面我们逐一考察哪一种是einaj在此的恰当含义。

“Ｏｎｔｏｌｏｇｙ”的意义及翻译作者：邹诗鹏近年来，Ontology问题复又成为学界的热点研究领域，问题仍然集中于如何理解和翻译Ontology，大多数的意见认为应当放弃“本体”及“本体论”，而选择“存在”及“存在论”，或者干脆就是“是”及“是论”。

但到底是“存在”及“存在论”，还是“是”及“是论”(“是态论”)，则形成了争论的焦点。

这场争论的实质是反映了学界对于西方学术研习的质量要求，同时也表现了学界对于中西方文化在根源上是否能够形成沟通的困惑与思考。

一、Ontology及其复杂的汉译问题存在论(Ontology)是哲学的核心领域。

顾名思义，存在论即关于“存在”的理论，是关于存在是什么以及存在如何存在的理论。

存在论虽然是在17世纪才由德国经院学者郭克兰纽命名并由沃尔夫加以完善并从理论上系统化，但就存在论这一学问而言，则是早已由古希腊哲学确定了其基本框架及理论内容的。

事实上，存在论本身就是古希腊哲学的主题形态。

不过，Ontology并不是一劳永逸的理论体系。

对于不断追求理论超越的西方哲学传统而言，后世的西方哲学显然有理由构造与古希腊哲学的“Ontology”有所突破甚或根本不同的Ontology结构。

Ontology的复杂性从词源角度说源于其核心概念toon(tobe)在西方思想演进中的复杂性，从本质上说则是源于哲学家们不同的哲学观念，这种状况必然导致人们对Ontology的不同理解。

特别是，由于Ontology在文化传播中与异文化传统及其语言习惯的冲突、融汇与涵化，从而使得在西方哲学那里本就十分复杂的Ontology的异文化翻译显得更为复杂。

Ontology的汉译就充分地表明了这一点。

近百年来，Ontology先后被译为“物性学”“万有学”(卫礼贤)、“实体论”(陈大年)、“本体学”(常守义)、“万有论”(陈康)、“凡有论”、“至有论”(张君劢)、“存有论”(唐君毅)、“有根论”(张岱年)，“是论”(陈康、汪子嵩、王太庆等)以及“是态论”(陈康)等等。

A Good Role Model for Ontologies:CollaborationsMichael Pradel,Jakob Henriksson,and Uwe AßmannFakultät für Informatik,Technische Universität Dresden michael@binaervarianz.de,{jakob.henriksson|uwe.assmann}@tu-dresden.de Abstract.Ontologies are today used to annotate web data with machine pro-cessable semantics and for domain modeling.As the use of ontologies increasesand the ontologies themselves grow larger,the need to construct ontologies ina component-based manner is becoming more and more important.In object-oriented software development,the notions of roles and role modeling have beenknown for many years.We argue that role models constitute attractive ontologi-cal units—components.Role models,among other things,provide separation ofconcerns in ontological modeling.This paper introduces roles to ontologies anddiscusses relevant issues related to transferring these techniques to ontologies.Examples of role models enabling separation of concerns and reuse are providedand discussed.1IntroductionOntology languages are emerging as the de facto standard for capturing semantics on the web.One of the most important ontology languages today is the Web Ontology Language OWL,standardized and recommended by W3C[12].One issue currently addressed in the research community is how to define reusable ontologies or ontology parts.In more general terms,how to construct an ontology from possibly independently developed components?OWL natively provides some facilities for reusing ontologies and ontology parts. First,a feature inherited from RDF[7](upon which OWL is layered)is linking—loosely referencing distributed web content and other ontologies using URIs.Second,OWL provides an owl:imports construct which syntactically includes the complete refer-enced ontology into the importing ontology.The linking mechanism is convenient from a modeling perspective,but is semantically not well-defined—there is no guarantee that the referenced ontology or web content exists.Furthermore,the component(usually an ontology class)is small and often hard to detach from the surrounding ontology in a semantically well-defined ually a full ontology import is required since it is un-clear which other classes the referenced class depends on.The owl:imports construct can only handle complete ontologies and does not allow for partial reuse.This can lead to inconsistencies in the resulting ontology due to conflicting modeling axioms.Over-all,OWL seems to be inflexible in the kind of reuse provided,especially regarding the granularity of components.Existing approaches addressing these issues often refer to modular ontologies and, in general terms,aim at enabling the reuse of ontology parts or fragments in a well-defined way(for some work in this direction,see[4–6,11]).That is,investigate howonly certain parts of an ontology can be reused and deployed elsewhere.While it is interesting work and allows for reuse,we believe that such extracted ontological units fail to provide an intuitive meaning of why those units should constitute components—they were not designed as such.The object-orientated software community has long discussed new ways of model-ing software.One interesting result of this research is the notion of role modeling[13]. The main argument is that today’s class-oriented modeling mixes two related but ulti-mately different notions:natural types and role types.Natural types capture the identity of its instances,while a role type describes their interactions.Intuitively,an object can-not discard its natural type without losing its identity while a role type can be changed depending on the current context of the object.Person for example,is a natural type while Parent is a role type.Parent is a role that can be played by persons.A role type thus only models one specific aspect of its related natural types.Related role types can be joined together into a role model to capture and separate one specific concern of the modeled whole.In this paper we introduce role modeling to ontologies.Role modeling can bring several benefits to ontologies and ontological modeling.Roles provide:–More natural ontological modeling by separating roles from classes–An appropriate notion and size of reusable ontological components—role models –Separation of concerns by capturing a single concern in a role modelWe believe that role models constitute useful and natural units for component-based ontology engineering.Role models are developed as components and intended to be de-ployed as such,in contrast to existing approaches aimed at extracting ontological units from ontologies not necessarily designed to be modular.While we argue that modeling with roles is beneficial to ontological modeling and provides a new kind of component not previously considered for ontologies,the transition from object-orientation is not straightforward.The contribution of this paper is the introduction of modeling prim-itives to support roles in ontologies and a discussion of the main differences for role modeling between ontologies and object-oriented models.1The semantics of the new modeling primitives is provided by translation into the assumed underlying ontologi-cal formalism of Description Logics(DLs)[3].That way,existing tools can be reused for modeling with roles.To convince the reader of the usefulness of role models,we demonstrate their use on two examples.Thefirst example shows separation of concerns and the second example demonstrates reuse of role models in different contexts.The remaining part of the paper is structured as follows.Section2introduces roles as used and understood in object-orientation and discusses what the main differences are between models and ontologies.Section3introduces role models to ontologies and gives examples of their use.Section4discusses related work to component-based ontology modeling and Section5concludes the paper and discusses open issues.1When we simply say model,we shall mean a model in the object-oriented sense.2From Roles in Software Modeling to OntologiesThe OOram software engineering method[13]was thefirst to introduce roles in object-orientation.The innovative idea was that objects can actually be abstracted in two ways: classifying them according to their inherent properties,and focusing on how they work together with other objects(collaborate).While the use of classes as an object abstrac-tion is a cornerstone in object-oriented modeling,focusing on object collaborations using roles has not been given the attention it deserves(however,for some work ad-dressing these issues,see CaesarJ[1]and ObjectTeams[8]).There are different views in the object-oriented community[15,16]on what roles really are.However,some basic concepts seem to be accepted by most authors:–Roles and role types.A role describes the behavior of an object in a certain context.In this context the object is said to play the role.One object may play several roles at a time.A set of roles with similar behavior is abstracted by a role type(just as similar objects are abstracted by a class).–Collaborations and role models.Roles focus on the interaction between objects and consequently never occur in isolation,but rather in collaborations.This leads to a new abstraction not available for classes—the role model.It describes a set of role types that relate to each other and thus as a whole characterizes a common collaboration(a common goal or functionality).–Open and bound role types.Role types are bound to classes by a plays relation,e.g.Person plays Father(a person can play the role of being a father).However,not all role types of a role model must be bound to a class.Role types not associated witha class are called open and intuitively describe missing parts of a collaboration.It is important to note that class modeling and role modeling do not replace each other,but are complementary.A purely class-based approach arguably leads to poor modeling by enforcing the representation of role types by classes and thus disregards reuse possibilities based on object collaborations.However,roles cannot replace classes entirely since this would disallow modeling of properties that are not related to a specific context.Adapting roles for ontology modeling There is currently no consensus on the exact re-lationship between models and ontologies,although the question is a current and impor-tant one(see e.g.[2]).There is however some agreement upon fundamental differences between models and ontologies which will have an impact on transferring the notion of roles from models to ontologies.One difference is that models often describe something dynamic,for example a system to be implemented.In contrast,ontologies are static entities.Even though an ontology may evolve over time,the entities being modeled do not have the same no-tion of time.Models often describe systems that are eventually to be executed,while ontologies do not(although some approaches exist that compile ontologies to Java2). The dynamism and notion of executability in modeling is closely connected to func-tionality(or behavior).A collaboration in object-oriented modeling often captures a 2See for example,http://www.aifb.uni-karlsruhe.de/WBS/aeb/ontojava/.separate and reusable functionality.For example,a realization of depth-first traversal over graph structures may require several collaborating methods in different classes for its implementation.The collection of all the related dependencies between the classes constitutes a collaboration and thus implements this functionality[14].Because of the non-existence of dynamism and behavior in ontologies,roles and collaborations neces-sarily capture something different.Instead of describing the behavior of an object using the notion of a role,ontological roles describe context-dependent properties.Definition1(Ontological roles and role types).An ontological role describes the properties of an individual in a certain context.A set of roles with similar properties is abstracted by an ontological role type.Based on this we define what we consider a role model(collaboration)to be in an ontological setting.Definition2(Ontological collaborations and role models).An ontological role model describes a set of related ontological role types and as such encapsulates com-mon relationships between ontological roles.For example,an ontology may describe the concept Person.If john,mary and sarah are said to be persons,but in fact belong to a family,the needed associations may be encoded in a Family collaboration describing relationships such as parents having chil-dren.The existing Family collaboration could then simply be imported and employed to encode that john and mary are the parents of sarah.Another difference between models and ontologies are their implicit assumptions. In models,classes are assumed to be disjoint,which is,however,not the case for on-tologies.This implies that role-playing individuals may belong to classes to which the corresponding role type is not explicitly bound.To avoid unintended role bindings,the ontology engineer explicitly has to constrain them in the ontology.3Using Role Models in OntologiesClass-based modeling,as used in ontologies today,has proven to be successful,but ex-perience in object-orientation has lead to role modeling as a complementary paradigm. This section shows how roles and role models can beneficially be used in ontologies. One of our main motivations is to promote role models as a useful ontological unit—a component—in ontological modeling.We therefore show how role models can be incorporated and reused in class-based ontologies.The following example is intended to demonstrate how classes can be split into separate concerns where each concern is modeled by employing a different role model. Figure1shows parts of a wine ontology modeled with roles.Classes are represented by gray rectangles while white rectangles with rounded corners denote role types.The definition of a role type is specified inside its rectangle(in standard DL syntax).In addition,role types are tagged with the name of their role model,e.g.(Product).Labeled arrows represent binary properties between types.The ontology in Figure1models three natural types(classes):Wine,Winery and Food.In a class-based version of the ontology in Figure1,the concerns of wine bothFigure1.Different concerns of the Wine class are separated by the role types Product and Drink. being a product and a drink(to be had with a meal)would be intermingled in a single class definition of Wine.The most natural way of modeling this would be to state that Wine is a subclass of the classes Product and Drink.However,this would not be ideal since a wine does not always have to be a product.Rather,we would like to express that a wine can be seen as a product(in the proper context).This can be expressed using roles where these concerns are instead explicitly separated into the role types Product and Drink.The motivation from a modeling perspective is that wines are always wines (that is,wine is a natural type).A wine may however be seen differently in different contexts:As a product to be sold,or as a drink being part of a meal.Modeling the role-based ontology from Figure1in a more concrete syntax could look like this(based on Manchester OWL syntax[9]):The import statements import the needed role models and the Plays primitive binds roles to classes.The translation of the ontology into standard DL giving the on-tology meaning is discussed in Section3.1.The above mentioned modeling distinction can also be helpful in other situations. Imagine the existence of an ontology with the classes Person and PolarBear(naturally) stated to be disjoint.The modeler now wants to introduce the concept of Parent and decides that parents are persons.Furthermore,while being focused on polar bears for a while decides that since obviously not all polar bears are parents,the opposite should hold and states that parents are also polar bears.This unfortunate and unintentional mistake makes the class Parent unsatisfiable(i.e.it is always empty).A more natural way to solve this problem would be to import a Family role model(modeling notions such as parents etc.)and state that Person s can play the role of Parent and PolarBear scan do the same.Thus,instead of intermingling a class Parent with the definitions of Person and PolarBear,possibly causing inconsistencies,the role type Parent cross-cuts the different involved(natural)classes as a separate concern.Doing this will prevent the role type Parent from being empty.This example has shown that employing roles can be more natural than using classes to describe non-inherent properties of individuals.Note that we do not claim that it is not possible to solve the above mentioned model-ing problem strictly using classes as is done today.In fact,we very much recognize this fact by giving role-based ontologies a translational semantics to standard DL semantics (see Section3.1).Instead we argue that modeling with roles is more natural and easier from the perspective of the modeler.Apart from the rather philosophical distinction between classes and roles described above,roles are important in collaborations.A set of collaborating roles may be joined together in a role model,which may effectively be reused in many different ontologies. Thus,role models provide an interesting reuse unit for ontologies.Figure2shows an example of reusability.There are two class-based ontologies, one modeling wines and the other pizzas.Both the concept of Wine and Pizza in the different ontologies can in certain contexts be considered as products(as one concern). To capture this concern and the relationships the role of being a product has with other roles,for example being a producer,we reuse the Product role model introduced in Figure1.Figure2.The Product role model reused in two different ontologies.The example shows how a set of related relationships(for example produces and consumes)can be encapsulated in a role model and reused for different domains.Not only relationships are encapsulated,but also the related role types that act as ranges and domains for the relationships.As another example we can again consider the previously mentioned Family role model where relationships such as hasChild and hasParent are modeled.This role model may not only be used in an ontology catered to modeling persons.Consider forinstance the same notions being needed in an ontology modeling tree data structures. There,possible relationships between nodes may also be modeled by reusing the same role model.Another example would be an ontology describing operating systems and their processes,new child processes being spawned from parent processes,etc.After having looked at some examples of ontologies being modeled using role mod-els,we will in the following section discuss their semantics.3.1Semantics of Role-Modeled OntologiesWe argue that modeling with roles should be enabled by introducing new ontological modeling primitives.Roles allow modelers to separate concerns in an intuitive manner and provide useful ontological units(components).At the same time,current class-based ontology languages(e.g.OWL)are already very expressive.Thus,we believe that there is no lack in expressiveness,but rather in modeling primitives and reuse.We therefore aim for a translational approach where role-based ontologies may be com-piled to standard(DL-based)ontologies.A great advantage is that this permits to reuse existing tools,in particular already well-developed reasoning engines.A class-based ontology is considered to be a set of DL axioms constructed using class descriptions(or simply classes),property descriptions(or properties),and individ-uals.For supporting roles,we enhance the syntax with role types and role properties. For the sake of simplicity,we restrict role types to be conjuncts of existential restric-tions limited to atomic role types.That is,of the form∃p1.R1 ... ∃p n.R n,where R i are role types and p i are role properties.Role properties simply define their domain and range(both have to be role types).Classes(respectively properties)and role types (respectively role properties)are built from disjoint sets of names.This disjointness corresponds to the underlying difference of natural types and role types.To support role modeling,we introduce two new axioms.Thefirst axiom expresses that individuals of a class can play a role:R£C(role binding)binds role type R to class C.The second axiom expresses that some specific individual plays a role:R(a)(role assertion),where R is a role type and a an individual.Additionally,we add syntax for ontologies to import role models.The extended syntax may now be translated to the underlying ontology language by the following algorithm:31.Make all imported role type definitions available as classes in the ontology.2.For each role type R used in the ontology:(a)Let{C1,...,C n}be the set of classes to which R is bound(R£C i).Then addthe axiom R C1 ... C n ⊥to the ontology.(b)For each role assertion R(a),make the same assertion available in the resultingontology,now referring to the class-representative for the role type R.3.Remove import and Plays statements.This translation captures the can-play semantics of roles by defining role types as subtypes of classes.It implies that an open role R may not be played by any individual 3Role properties and role property assertions are left out here but can be easily integrated into the syntax extensions and the translation algorithm.since R ⊥would be added to the ontology(i.e.R is always interpreted as the empty set).The semantics of our role modeling extension is an immediate consequence of the translation by using the standard semantics of DLs.We will now look at an example of how a role-based ontology is compiled to a standard class-based ontology.The ontology from Figure1imports the role models Product and Meal.The Product role model could for example be defined by:4To illustrate the impact of binding one role type to multiple classes,we assume that the Product role type is also bound to the class Food in Figure1(and in the subsequent listing).That is,also foods can be considered products in some contexts.Our trans-lation as defined above results in the following class-based ontology(for the example disregarding the Meal role model):The resulting ontology consists of only standard OWL constructs and can thus be used by existing tools such as reasoners.A consequence of this resulting ontology is for example that an individual playing the role of a product has to be either a wine or a food.We can thus single out and study the concern of being a product,but not having to consider in detail what those products are.We could have done the same in a class-based ontology by stating that wines and foods are products,thus using Product as a super-class to both Wine and Food.However,as already mentioned,this would disregard the fact that wines and foods are not always products.4Related WorkModularizing ontologies andfinding appropriate ontology reuse units are becoming important issues.Several works address this issue,most having a strong formal founda-tion.A common property between existing work seems to be the desire to reuse partial ontologies.That is,enable more refined reuse of ontologies by allowing to import and share vocabulary(classes,in some sense meaning)rather than axioms(ontologies,that is,syntactical units).4The definitions of the role properties produces and consumes are left out.One work in this direction proposes a new import primitive:semantic import[11]. Semantic import differs from owl:imports(referred to as syntactic import)by allow-ing to import partial ontologies and by additionally enforcing the existence of any re-ferred external ontologies or ontology elements(classes,properties,individuals)by the notion of ontology spaces.The goal in this work is controlled partial reuse.The work in[5]defines a logical framework for modular integration of ontologies by allowing each ontology to define its local and external signature(that is,classes, properties etc.).The external signature is assumed to be defined in another ontology. Two distinct restrictions are defined on the usage of the external signatures.Thefirst syntactically disallows certain axioms which are considered harmful,while the second restriction generalized thefirst by taking semantical issues into consideration.The gen-eral goal,apart from a formal framework,is to allow safe merging of ontologies.The work in[6]also proposes partial reuse of ontologies by allowing to automat-ically extract modules from ontologies.One interesting requirement put on such an extracted module is that it should describe a well-defined subject matter,that is,be self-contained from a modeling perspective.In contrast to these works on partial ontology reuse,in particular how to extract or modularize existing ontologies,our work aims at defining a more intuitive ontological unit—an ontological component that was defined as such.5Conclusions and OutlookIn this paper we have proposed an ontological unit able to improve modeling and pro-vide a means for reuse—the ontological role model.The concept of roles has its roots in software modeling and we have taken thefirst steps to transfer this notion to the world of ontologies.Role models provide a view on individuals and their relationships that is different from the abstractions provided by purely class-based approaches.As such, role models provide a reusable abstraction unit for ontologies.Furthermore,due to the translational semantics,the approach is compatible with existing formalisms and tools.As a next step we aim at integrating role modeling into tools,for example the Protégéontology editor[10].This is important since we argue that ontology engineers should treat roles asfirst class members of their language and distinguish them from classes.Other issues also remain to be further clarified.The semantics of roles may be subject of discussion.Apart from focusing on can-play semantics,must-play may in some cases be desirable for role bindings.Another issue to clarify is the implication of applying one role model several times in an ontology.One could argue for multi-ple imports where each import is associated with a unique name space.However,this would disallow to refer to all instances of a certain role type,for instance to all products in an ontology.Finally,further investigations into the implications of the open-world semantics of ontologies relating to role bindings and role assertions should be done.In conclusion,we argue that role models provide an interesting reuse abstraction for ontologies and that roles should be supported as an ontological primitive.AcknowledgementThis research has been co-funded by the European Commission and by the Swiss Fed-eral Office for Education and Science within the6th Framework Programme project REWERSE number506779(cf.).References1.I.Aracic,V.Gasiunas,M.Mezini,and K.Ostermann.An Overview of CaesarJ,pages135–173.Springer Berlin/Heidelberg,2006.2.U.Aßmann,S.Zschaler,and G.Wagner.Ontologies,Meta-Models,and the Model-DrivenParadigm,pages249–273.Springer,2006.3. F.Baader,D.Calvanese,D.L.McGuinness,D.Nardi,and P.F.Patel-Schneider,editors.TheDescription Logic Handbook.Cambridge University Press,2003.4. B.Cuenca Grau,I.Horrocks,Y.Kazakov,and U.Sattler.Just the right amount:Extractingmodules from ontologies.In Proc.of the Sixteenth International World Wide Web Conference (WWW2007),2007.5. B.Cuenca Grau,Y.Kazakov,I.Horrocks,and U.Sattler.A logical framework for modu-lar integration of ontologies.In Proc.of the20th Int.Joint Conf.on Artificial Intelligence (IJCAI2007),pages298–303,2007.6. B.C.Grau,B.Parsia,E.Sirin,and A.Kalyanpur.Modularity and web ontologies.In P.Do-herty,J.Mylopoulos,and C.A.Welty,editors,Proceedings of KR2006:the20th Interna-tional Conference on Principles of Knowledge Representation and Reasoning,Lake District, UK,June2–5,2006,pages198–209.AAAI Press,2006.7.P.Hayes et al.RDF Semantics.W3C Recommendation,10February2004.Available at/TR/rdf-mt/.8.S.Herrmann.Object teams:Improving modularity for crosscutting collaborations.In Proc.Net Object Days2002,2002.9.M.Horridge,N.Drummond,J.Goodwin,A.Rector,R.Stevens,and H.Wang.The manch-ester owl syntax.OWL:Experiences and Directions(OWLED),November2006.10.H.Knublauch,R.W.Fergerson,N.F.Noy,and M.A.Musen.The ProtégéOWL plugin:Anopen development environment for semantic web applications.Third International Semantic Web Conference(ISWC),November2004.11.J.Pan,L.Serafini,and Y.Zhao.Semantic import:An approach for partial ontology reuse.In Proc.of the ISWC2006Workshop on Modular Ontologies(WoMO),2006.12.P.F.Patel-Schneider,P.Hayes,and I.Horrocks.OWL web ontology language semantics andabstract syntax.W3C Recommendation,10February2004.Available at http://www.w3.org/TR/owl-semantics/.13.T.Reenskaug,P.Wold,and O.Lehne.Working with Objects,The OOram Software Engi-neering Method.Manning Publications Co,1996.14.Y.Smaragdakis and D.Batory.Mixin layers:an object-oriented implementation tech-nique for refinements and collaboration-based designs.ACM Trans.Softw.Eng.Methodol., 11(2):215–255,2002.15. F.Steimann.On the representation of roles in object-oriented and conceptual modelling.Data Knowl.Eng.,35(1):83–106,2000.16. F.Steimann.The role data model revisited.Roles,an interdisciplinary perspective,AAAIFall Symposium,2005.。

Domain-Driven Modeling with Aspects and OntologiesPavel HrubyMicrosoftFrydenlunds Allé 62950 Vedbaek, Denmark+45 29229183phruby@1.SUMMARYA common task during developing software applications inspecific domains is to identify application objects and theirbehavior. In this paper, we will illustrate in the domain-drivendevelopment of software applications, application designers canuse domain ontologies as one of the sources for creatingapplication models, in addition to traditional analysis based onuser requirements. The conceptualized domain knowledge in theform of domain ontology can be used as a metamodel forapplication object models.However, domain ontologies cannot describe specificfunctionality and the differences between different applications ina given domain, which originate in user requirements, because theconcepts of the domain ontology must be applicable to all systemsin the domain. Application objects often cannot be extended byadditional functionality in a modular way, because the modules offunctionality resulting from the user requirements are often notlocalizable into application objects that originate in the domainontology.To solve this conflict, we will illustrate that the domain-specificsoftware applications lead to the architecture of a component with two orthogonal dimensions. The object dimension represents the categories originating in the domain ontology and the aspect dimension represents the functional modules that originate from user requirements.2.APPLICATION OBJECTS“An ontology is an explicit specification of a conceptualization” [Gruber 1993]. Ontological categories define the concepts that exist in the domain, as well as relationships between these concepts. For object-oriented applications, domain ontology defines the metamodel for application models in this domain. Ontological categories correspond to the metaclasses for application objects. For example, in the ontology for business systems called REA (Resources, Events, Objects), the economic agent is a metaclass for objects such as customer and vendor, the economic event is a metaclass for objects such as sale and payment receipt. Economic resource is a metaclass for objects such as money and item. Likewise, relationships between ontological categories become metarelationships for the relationships between application object, such as stockflow is a metarelationship for relationships called outflow and inflow; duality between economic events is a metarelationship for the reconciliation relationship between Sale and Payment Receipt, see Figure 1.«instance of»«instance of»«instance of»«instance of»dualityparticipationFigure 1. Application Model and its REA Metamodel 3.APPLICATION BEHAVIOR3.1Functionality of Domain ObjectsThe previous section illustrated that structure of a software application can be derived from ontological categories that apply to the application’s domain. However, to build a useful software application, the mere structure of domain objects is not sufficient. Domain objects need functionality that is often not specified by the ontological categories, but is required by the application’s users. For example, the REA ontology does not specify how to determine the identity of business objects, or how to collect financial data. However, functionality such as serial numbers and accounts are essential for the users of business applications. Application functionality is not specified by domain ontologies for a good reason. Domain ontologies specify the structure of concepts that can be applied to all systems in the domain. Domain ontologies attempt to find the minimal, yet complete set of concepts covering the domain.The functionality of application objects usually differs from one system to another because of specific user requirements, local conventions, as well as several other reasons. For example in business applications, some objects need human readable serialnumbers, such as customers and products; some do not, such as order lines. Financial reporting depends on local legislation, lines of business and reporting usually varies from one application to another, reflecting the fact that every company is somehow different than the other. A complete list of functionality of the domain objects probably cannot be specified in general for the whole domain; users of software applications would always need new features or new versions of existing features, which cannot be foreseen by those who create the ontology.3.2Cross-Cutting Domain ObjectsOntological categories determine one dimension of decomposition of the domain. The other dimension of decomposition is the application functionality. In this section we will show that in many cases the modules of application functionality are not localizable into a single application object.In the business domain, for example, the serial number of an item is an attribute of the item object. The serial number is usually not a random number. The item serial number is chosen from a number series, which is an attribute of a group of the economic resources, to which the number series is applied. Thus, the object representing the item group contains rules specifying things such as the format of the serial number, whether a serial number should be unique, how does it depend on previous numbers of the series, rules determining whether serial numbers of deleted items can be reused, and other similar rules. The number series module cross-cuts two domain objects, the item object and the item group object, and the number is constructed by mutual collaboration between the part that resides on the item and the part that resides on the item group. It is useful to think of the number series as a single module, but this module cross-cuts two application objects.Figure 2. Number Series Cross-Cuts Application Objects Aspect-oriented programming is one of the approaches, and an addictive convention of thought on how to deal with cross-cutting concerns in a modular way. In the scope of domain-driven development, it is useful to think about entities derived from ontological categories as objects and about functionality of the software applications as aspects.3.3Aspect CategoriesIn the section about domain objects we have shown that ontological categories correspond to metaclasses of the application objects. A similar approach can be also applied to the entities in aspect dimension.For example, we have shown that the number series is an aspect in the application model. However, the fundamental purpose of the number series is to give the application object unique identity. Therefore, we can think of the number series as a specific instance of a more general aspect category called identification. Other instances of the identification aspect category are the name, phone number, e-mail address, URL (Uniform Resource Locator), GUID (Globally Unique Identifier) and ISBN (International Standard Book Number). More examples of the aspects categories are illustrated in Figure 5; instances of address aspect category are Billing Address or Shipping Address, instances of posting aspect category are G/L entry and Inventory entry.4.DOMAIN-DRIVEN DEVELOPMENT4.1Object and Aspect DimensionIn this section we illustrate how these concepts can be used to develop a software application in a specific domain.We have shown that a domain-specific model can be decomposed along two dimensions: the object dimension that reflects the ontological categories of the domain and the aspect dimension that reflects the behavior, which the software application must have in order to be useful, see Figure 3. We have also shown that the components both in the object dimension and the aspect dimension can be specified at two levels of abstraction; the level of ontological categories and aspect categories, and the level ofapplication objects and application aspects.Figure 3. Objects, Aspects and Domain-Driven Development 4.2Application ConfigurationThe configured software application is an application that conforms to the ontology for the particular domain and also contains specific functionality that meets user’s needs. As the application objects are determined by the domain ontology, the process of creating an application model consists of assigning application aspects to application objects. This architecture isoutlined in Figure 4.Figure 4. Application ConfigurationFigure 3 illustrates the key message of this paper, which is, using domain ontologies to determine the application object modelleads to a software architecture with two orthogonal dimensions. An example of a business application configured in this way is illustrated in Figure 5. This application is a model of a simple sales module.The ontological categories in this application are Economic Agent, Economic Event and Economic Resource; their instances are application objects Customer, Sale, Payment, Item and Cash. The aspect categories in this application are Identification, Account, Address and Posting. Instances of the Identification aspect are Name, Item Number, Customer Number and Transaction ID. Instances of the Account aspect are Inventory Account, Bank Account, Customer Account and Cash Account. Instances of the Address aspect are Billing Address and Shipping Address. Instances of the Posting aspect are G/L (General Ledger) Entry and Inventory Entry. The choice of the aspect categories is determined by user’s needs. Other configurations of the sales process in the software applications for different users would contain a different set of aspect categories.The configured application model illustrated in Figure 5 contains the Application Objects with Application Aspects. The Customer object contains the aspects Name and Number (identification aspects), Customer Account (account aspect), Billing Address and Shipping Address (address aspects). The Sales object contains the aspects Transaction ID (identification aspect) and G/L Entry (posting aspect). Payment Receipt contains the aspects Transaction ID and G/L Entry (posting aspect). The Item object contains the Item Number (identification aspect), and the Money object contains the Bank Account and Cash Account aspects.outflowdualityparticipation stockflow«aspects»NameCustomer NumberCustomer Account«aspects»Transaction IDG/L Entry«aspects»Transaction IDG/L Entry«aspects»Item Number«aspects»Cash AccountconfigurationFigure 5. Example of Application Configuration5.REFERENCES[1]Geerts, G. McCarthy, W. The Ontological Foundation ofREA Enterprise Information System s, Michigan StateUniversity, August 2000[2]Hruby, P.: Ontologies in Aspect-Oriented Domain-DrivenDevelopment, ECOOP 2005 workshop on Views, Aspectsand Roles, Glasgow 2005.。

A Framework for Ontology IntegrationDiego Calvanese,Giuseppe De Giacomo,Maurizio LenzeriniDipartimento di Informatica e SistemisticaUniversit`a di Roma“La Sapienza”Via Salaria113,00198Roma,Italy{calvanese,degiacomo,lenzerini}@dis.uniroma1.itAbstract.One of the basic problems in the development of techniques for the semanticweb is the integration of ontologies.Indeed,the web is constituted by a variety ofinformation sources,each expressed over a certain ontology,and in order to extractinformation from such sources,their semantic integration and reconciliation in termsof a global ontology is required.In this paper,we address the fundamental problemof how to specify the mapping between the global ontology and the local ontologies.We argue that for capturing such mapping in an appropriate way,the notion of queryis a crucial one,since it is very likely that a concept in one ontology correspondsto a view(i.e.,a query)over the other ontologies.As a result query processing inontology integration systems is strongly related to view-based query answering in dataintegration.1IntroductionOne of the basic problems in the development of techniques for the semantic web is the inte-gration of ontologies.Indeed,the web is constituted by a variety of information sources,and in order to extract information from such sources,their semantic integration and reconcilia-tion is required.In this paper we deal with a situation where we have various local ontologies, developed independently from each other,and we are required to build an integrated,global ontology as a mean for extracting information from the local ones.Thus,the main purpose of the global ontology is to provide a unified view through which we can query the various local ontologies.Most of the work carried out on ontologies for the semantic web is on which language or which method to use to build the global ontology on the basis of the local ones[13,2].For example,the Ontology Inference Layer(OIL)[13,2]proposes to use a restricted form of the expressive and decidable DL studied in[4]to express ontologies for the semantic web.In this paper,we address what we believe is a crucial problem for the semantic web:how do we specify the mapping between the global ontology and the local ontologies.This aspect is the central one if we want to use the global ontology for answering queries in the context of the semantic web.Indeed,we are not simply using the local ontologies as an intermediate step towards the global one.Instead,we are using the global ontology for accessing information in the local ones.It is our opinion that,although the problem of specifying the mapping between the global and the local ontologies is at the heart of integration in the web,it is not deeply investigated yet.We argue that even the most expressive ontology specification languages are not sufficient for information integration in the semantic web.In a real world setting,different ontologiesare build by different organizations for different purposes.Hence one should expect the same information to be represented in different forms and with different levels of abstraction in the various ontologies.When mapping concepts in the various ontologies to each other,it is very likely that a concept in one ontology corresponds to a view(i.e.,a query)over the other ontologies.Observe that here the notion of“query”is a crucial one.Indeed,to express mappings among concepts in different ontologies,suitable query languages should be added to the ontology specification language,and considered in the various reasoning tasks,in the spirit of[4,5].As a result query processing in this setting is strongly related to view-based query answering in data integration systems[20,17].What distinguishes ontology integration from data integration as studied in databases,is that,while in data integration one assumes that each source is basically a databases,i.e.,a logical theory with a single model,such an assumption is not made in ontology integration,where a local ontology is an arbitrary logical theory,and hence can have multiple models.Our main contribution in this paper is to present a general framework for an ontology of integration where the mapping between ontologies is expressed through suitable mechanisms based on queries,and to illustrate the framework proposed with two significant case studies.The paper is organized as follows.In the next section we set up a formal framework for on-tology integration.In Sections3and4,we illustrate the so called global-centric approach and local-centric approach to integration,and we discuss for each of the two approaches a specific case study showing the subtleties involved.In Section5we briefly present an approach to in-tegration that goes beyond the distinction between global-centric and local-centric.Finally, Section6concludes the paper.2Ontology integration frameworkIn this section we set up a formal framework for ontology integration systems(OISs).We argue that this framework provides the basis of an ontology of integration.For the sake of simplicity,we will refer to a simplified framework,where the components of an OIS are the global ontology,the local ontologies,and the mapping between the two.We call such systems “one-layered”.More complex situations can be modeled by extending the framework in order to represent,for example,mappings between local ontologies(in the spirit of[12,6]),or global ontologies that act as local ones with respect to another layer.In what follows,one of the main aspects is the definition of the semantics of both the OIS,and of queries posed to the global ontology.For keeping things simple,we will use in the following a unique semantic domain∆,constituted by afixed,infinite set of symbols.Formally,an OIS O is a triple G,S,M G,S ,where G is the global ontology,S is the set of local ontologies,and M G,S is the mapping between G and the local ontologies in S. Global ontology.We denote with A G the alphabet of terms of the global ontology,and we assume that the global ontology G of an OIS is expressed as a theory(named simply G) in some logic L G.Local ontologies.We assume to have a set S of n local ontologies S1,...,S n.We denotewith A Si the alphabet of terms of the local ontology S i.We also denote with A S theunion of all the A Si ’s.We assume that the various A Si’s are mutually disjoint,and eachone is disjoint from the alphabet A G.We assume that each local ontology is expressed asa theory(named simply S i)in some logic L Si ,and we use S to denote the collection oftheories S1,...,S n.Mapping.The mapping M G,S is the heart of the OIS,in that it specifies how the concepts1 in the global ontology G and in the local ontologies S map to each other. Semantics.Intuitively,in specifying the semantics of an OIS,we have to start with a model of the local ontologies,and the crucial point is to specify which are the models of the global ontology.Thus,for assigning semantics to an OIS O= G,S,M G,S ,we start by considering a local model D for O,i.e.,an interpretation that is a model for all the theories of S.We call global interpretation for O any interpretation for G.A global interpretationI for O is said to be a global model for O wrt D if:•I is a model of G,and•I satisfies the mapping M G,S wrt D.In the next sections,we will come back to the notion of satisfying a mapping wrt a local model.The semantics of O,denoted sem(O),is defined as follows:sem(O)={I|there exists a local model D for Os.t.I is a global model for O wrt D}Queries.Queries posed to an OIS O are expressed in terms of a query language Q G over the alphabet A G and are intended to extract a set of tuples of elements of∆.Thus,every query has an associated arity,and the semantics of a query q of arity n is defined as follows.The answer q O of q to O is the set of tuplesq O={ c1,...,c n |for all I∈sem(O), c1,...,c n ∈q I} where q I denotes the result of evaluating q in the interpretation I.As we said before,the mapping M G,S represents the heart of an OIS O= G,S,M G,S . In the usual approaches to ontology integration,the mechanisms for specifying the mapping between concepts in different ontologies are limited to expressing direct correspondences between terms.We argue that,in a real-world setting,one needs a much more powerful mechanism.In particular,such a mechanism should allow for mapping a concept in one ontology into a view,i.e.,a query over the other ontologies,which acquires the relevant information by navigating and aggregating several concepts.Following the research done in data integration[16,17],we can distinguish two basic approaches for defining this mapping:•the global-centric approach,where concepts of the global ontology G are mapped into queries over the local ontologies in S;•the local-centric approach,where concepts of the local ontologies in S are mapped to queries over the global ontology G.We discuss these two approaches in the following sections.1Here and below we use the term“concept”for denoting a concept of the ontology.3Global-centric approachIn the global-centric approach(aka global-as-view approach),we assume we have a query language V S over the alphabet A S,and the mapping between the global and the local on-tologies is given by associating to each term in the global ontology a view,i.e.,a query,over the local ontologies.The intended meaning of associating to a term C in G a query V s over S,is that such a query represents the best way to characterize the instances of C using the concepts in S.A further mechanism is used to specify if the correspondence between C and the associated view is sound,complete,or exact.Let D be a local model for O,and I a global interpretation for O:•I satisfies the correspondence C,V s,sound in M G,S wrt D,if all the tuples satisfying V s in D satisfy C in I,•I satisfies the correspondence C,V s,complete in M G,S wrt D,if no tuple other than those satisfying V s in D satisfies C in I.•I satisfies the correspondence C,V s,exact in M G,S wrt D,if the set of tuples that satisfy C in I is exactly the set of tuples satisfying V s in D.We say that I satisfies the mapping M G,S wrt D,if I satisfies every correspondence in M G,S wrt D.The global-centric approach is the one adopted in most data integration systems.In such systems,sources are databases(in general relational ones),the global ontology is actually a database schema(again,represented in relational form),and the mapping is specified by as-sociating to each relation in the global schema one relational query over the source relations. It is a common opinion that this mechanism allow for a simple query processing strategy, which basically reduces to unfolding the query using the definition specified in the mapping, so as to translate the query in terms of accesses to the sources[20].Actually,when we add constraints(even of a very simple form)to the global schema,query processing becomes even harder,as shown in the following case study.3.1A case studyWe now set up a global-centric framework for ontology integration,which is based on ideas developed for data integration over global schemas expressed in the Entity-Relationship model[3].In particular,we describe the main components of the ontology integration system, and we provide the semantics both of the system,and of query answering.The OIS O= G,S,M G,S is defined as follows:•The global ontology G is expressed in the Entity-Relationship model(or equivalently as UML class diagrams).In particular,G may include:–typing constraints on relationships,assigning an entity to each component of the relationship;–mandatory participation to relationships,saying that each instance of an entity must participate as i-th component to a relationship;–ISA relations between both entities and relationships;–typing constraints,functional restrictions,and mandatory existence,for attributes both of entities and of relationships.•The local ontologies S are constituted simply by a relational alphabet A S,and by the extensions of the relations in A S.For example,such extensions may be expressed as relational databases.Observe that we are assuming that no intensional relation between terms in A S is present in the local ontologies.•The mapping M G,S between G and S is given by a set of correspondences of the form C,V s,sound ,where C is a concept(i.e.,either an entity,a relationship,or an attribute) in the global ontology and V s is a query over S.More precisely,–The mapping associates a query of arity1to each entity of G.–The mapping associates a query of arity2to each entity attribute A of G.Intuitively, if the query retrieves the pair x,y from the extension of the local ontologies,this means that y is a value of the attribute A of the entity instance x.Thus,thefirst argument of the query corresponds to the instances of the entity for which A is defined,and the second argument corresponds to the values of the attribute A.–The mapping associates a query of arity n to each relationship R of arity n in G.Intuitively,if the query retrieves the tuple x1,...,x n from the extension of the local ontologies,this means that x1,...,x n is an instance of R.–The mapping associates a query of arity n+1to each attribute A of a relationship R of arity n in G.Thefirst n arguments of the query correspond to the tuples of R, and the last argument corresponds to the values of A.As specified above,the intended meaning of the query V s associated to the concept C is that it specifies how to retrieve the data corresponding to C in the global schema starting from the data at the sources.This confirms that we are following the global-as-views approach:each concept in the global ontology is defined as a view over the concepts in the local ontologies.We do not pose any constraint on the language used to express the queries in the mapping.Since the extensions of local ontologies are rela-tional databases,we simply assume that the language is able to express computations over relational databases.To specify the semantics of a data integration system,we have to characterize,given the set of tuples in the extension of the various relations of the local ontologies,which are the data satisfying the global ontology.In principle,one would like to have a single extension as model of the global ontology.Indeed,this is the case for most of the data integration systems described in the literature.However,we will show in the following the surprising result that, due to the presence of the semantic conditions that are implicit in the conceptual schema G, in general,we will have to account for a set of possible extensions.Example1.Figure1shows the global schema G1of a data integration system O1= G1,S1,M1 ,where Age is a functional attribute,Student has a mandatory participation in the relationship Enrolled,Enrolled isa Member,and University isa Organization.The schema models persons who can be members of one or more organizations,and students who areFigure1:Global ontology of Example1enrolled in universities.Suppose that S is constituted by S1,S2,S3,S4,S5,S6,S7,S8,and that the mapping M1is as follows:Person(x)←S1(x)Organization(x)←S2(x)Member(x,y)←S7(x,z)∧S8(z,y)Student(x)←S3(x,y)∨S4(x)Age(x,y)←S3(x,y)∨S6(x,y,z)University(x)←S5(x)Enrolled(x,y)←S4(x,y)From the semantics of the OIS O it is easy to see that,given a local model D,several situations are possible:1.No global model exists.This happens,in particular,when the data in the extension of thelocal ontologies retrieved by the queries associated to the elements of the global ontology do not satisfy the functional attribute constraints.2.Several global models exist.This happens,for example,when the data in the extensionof the local ontologies retrieved by the queries associated to the global concepts do not satisfy the ISA relationships of the global ontology.In this case,it may happen that several ways exist to add suitable objects to the elements of G in order to satisfy the constraints.Each such ways yields a global model.Example2.Referring to Example1,consider a local model D1,where S3contains the tuple t1,a1 ,and S6contains the tuple t1,a2,v1 .The query associated to Age by the mapping M1specifies that,in every model of O1both tuples should belong to the extension of Age. However,since Age is a functional attribute in G1,it follows that no model exists for the OIS O1.Example3.Referring again to Example1,consider a local model D2,where S1contains p1 and p2,S2contains o1,S5contains u1,S4contains t1,and the pairs p1,o1 and p2,u1 are in the join between S7and S8.By the mapping M1,it follows that in every model of O1,wehave that p1,p2∈Person, p1,o1 , p2,u1 ∈Member,o1∈Organization,t1∈Student,and u1∈University.Moreover,since G1specifies that Student has a mandatory participation in the relationship Enrolled,in every model for O1,t1must be enrolled in a certain university. The key point is that nothing is said in D2about which university,and therefore we have to accept as models all interpretations for O1that differ in the university t1is enrolled in.In the framework proposed,it is assumed that thefirst problem is solved by the queries extracting data from the extension of the local ontologies.In other words,it is assumed that, for any functional attribute A,the corresponding query implements a suitable data cleaning strategy(see,e.g.,[15])that ensures that,for every local model D and every x,there is at most one tuple(x,y)in the extension of A(a similar condition holds for functional attributes of relationships).The second problem shows that the issue of query answering with incomplete informa-tion arises even in the global-as-view approach to data integration.Indeed,the existence of multiple global models for the OIS implies that query processing cannot simply reduce to evaluating the query over a single relational database.Rather,we should in principle take all possible global models into account when answering a query.It is interesting to observe that there are at least two different strategies to simplify the setting,and overcome this problem that are frequently adopted in data integration sys-tems[16,20,17]:•Data integration systems usually adopt a simpler data model(often,a plain relational data model)for expressing the global schema(i.e.,the global ontology).In this case,the data retrieved from the sources(i.e.,the local ontologies)triviallyfits into the schema,and can be directly considered as the unique database to be processed during query answering.•The queries associated to the concepts of the global schema are often considered as exact.In this case,analogously to the previous one,it is easy to see that the only global exten-sion to be considered is the one formed by the data retrieved by the extension of the local ontologies.However,observe that,when data in this extension do not obey all semantic conditions that are implicit in the global ontology,this single extension is not coherent with the global ontology,and the OIS is inconsistent.This implies that query answering in meaningless.We argue that,in the usual case of autonomous,heterogeneous local on-tologies,it is very unlikely that datafit in the global ontology,and therefore,this approach is too restrictive,in the sense that the OIS would be often inconsistent.The fact that the problem of incomplete information is overlooked in current approaches can be explained by observing that traditional data integration systems follow one of the above mentioned simplifying strategies:they either express the global schema as a set of plain relations,or consider the sources as exact(see,for instance,[11,19,1]).In[3]we present an algorithm for computing the set of certain answers to queries posed to a data integration system.The key feature of the algorithm is to reason about both the query and the global ontology in order to infer which tuples satisfy the query in all models of the OIS.Thus,the algorithm does not simply unfold the query on the basis of the mapping,as usually done in data integration systems based on the global-as-view approach.Indeed,the algorithm is able to add more answers to those directly extracted from the local ontologies, by exploiting the semantic conditions expressed in the conceptual global schema.Let O= G,S,M G,S be an OIS,let D be a local model,and let Q be a query over the global ontology G.The algorithm is constituted by three major steps.1.From the query Q,obtain a new query expand G(Q)over the elements of the global ontol-ogy G in which the knowledge in G that is relevant for Q has been compiled in.2.From expand G(Q),compute the query unfold MG,S (expand G(Q)),by unfoldingexpand G(Q)on the basis of the mapping M G,S.The unfolding simply substitutes each atom of expand G(Q)with the query associated by M G,S to the element in the atom.The resulting unfold MG,S(expand G(Q))is a query over the relations in the local ontologies.3.Evaluate the query unfold MG,S(expand G(Q))over the local model D.The last two steps are quite obvious.Instead,thefirst one requires tofind a way to compile into the query the semantic relations holding among the concepts of the global schema G.A way to do so is shown in[3].The query expand G(Q)returned by the algorithm is exponential wrt to Q.However,expand G(Q)is a union of conjunctive queries,which,if the queries in the mapping are polynomial,makes the entire algorithm polynomial in data complexity. Example4.Referring to Example3,consider the query Q1to O1:Q1(x)←Member(x,y)∧University(y)It is easy to see that{p2,t1}is the set of certain answers to Q1with respect to O1and D2. Thus,although D2does not indicate in which university t1is enrolled,the semantics of O1 specifies that t1is enrolled in a university in all legal database for O1.Since Member is ageneralization of Enrolled,this implies that t1is in Q O1,and hence is in unf M1(exp G1(Q1))evaluated over D2.4Local-centric approachIn the local-centric approach(aka local-as-view approach),we assume we have a query lan-guage V G over the alphabet A G,and the mapping between the global and the local ontologies is given by associating to each term in the local ontologies a view,i.e.,a query over the global ontology.Again,the intended meaning of associating to a term C in S a query V g over G,is that such a query represents the best way to characterize the instances of C using the concepts in G.As in the global-centric approach,the correspondence between C and the associated view can be either sound,complete,or exact.Let D be a local model for O,and I a global interpretation for O:•I satisfies the correspondence V g,C,sound in M G,S wrt D,if all the tuples satisfyingC inD satisfy V g in I,•I satisfies the correspondence V g,C,complete in M G,S wrt D,if no tuple other than those satisfying C in D satisfies V g in I,•I satisfies the correspondence V g,C,exact in M G,S wrt D,if the set of tuples that satisfy C in D is exactly the set of tuples satisfying V g in I.As in the global-centric approach,we say that I satisfies the mapping M G,S wrt D,if I satisfies every correspondence in M G,S wrt D.Recent research work on data integration follows the local-centric approach[20,17,18,6, 8].The major challenge of this approach is that,in order to answer a query expressed over theglobal schema,one must be able to reformulate the query in terms of queries to the sources. While in the global-centric approach such a reformulation is guided by the correspondences in the mapping,here the problem requires a reasoning step,so as to infer how to use the sources for answering the query.Many authors point out that,despite its difficulty,the local-centric approach better supports a dynamic environment,where local ontologies can be added to the systems without the need for restructuring the global ontology.4.1A case studyWe present here an OIS architecture based on the use of Description Logics to represent ontologies[6,7].Specifically,we adopt the Description Logic DLR,in which both classes and n-ary relations can be represented[4].Wefirst introduce DLR,and then we illustrate how we use the logic to define an OIS.4.1.1The Description Logic DLRDescription Logics2(DLs)are knowledge representation formalisms that are able to capture virtually all class-based representation formalisms used in Artificial Intelligence,Software Engineering,and Databases[9,10].One of the distinguishing features of these logics is that they have optimal reasoning algo-rithms,and practical systems implementing such algorithms are now used in several projects.In DLs,the domain of interest is modeled by means of concepts and relations,which denote classes of objects and relationships,respectively.Here,we focus our attention on the DL DLR[4,6],whose basic elements are concepts(unary relations),and n-ary relations. We assume to deal with an alphabet A constituted by afinite set of atomic relations,atomic concepts,and constants,denoted by P,A,and a,respectively.We use R to denote arbitrary relations(of given arity between2and n max),and C to denote arbitrary concepts,respectively built according to the following syntax:C::= 1|A|¬C|C1 C2|∃[i]R|(≤k[i]R)R::= n|P|i/n:C|¬R|R1 R2where i denotes a component of a relation,i.e.,an integer between1and n max,n denotes the arity of a relation,i.e.,an integer between2and n max,and k denotes a nonnegative integer. We consider only concepts and relations that are well-typed,which means that only relations of the same arity n are combined to form expressions of type R1 R2(which inherit the arity n),and i≤n whenever i denotes a component of a relation of arity n.The semantics of DLR is specified as follows.An interpretation I is constituted by an interpretation domain∆I,and an interpretation function·I that assigns to each constant an element of∆I under the unique name assumption,to each concept C a subset C I of∆I, and to each relation R of arity n a subset R I of(∆I)n,such that the conditions in Figure2 are satisfied.Observe that,the“¬”constructor on relations is used to express difference of relations,and not the complement[4].A DLR knowledge base is a set of inclusion assertions of the formC1 C2R1 R22See for the home page of Description Logics.I1=∆IA I⊆∆I(¬C)I=∆I\C I(C1 C2)I=C I1∩C I2(∃[i]R)I={d∈∆I|∃ d1,...,d n ∈R I.d i=d}(≤k[i]R)I={d∈∆I| { d1,...,d n ∈R I1|d i=d}≤k}I n⊆(∆I)nP I⊆ I ni/n:C I={ d1,...,d n ∈ I n|d i∈C I}(¬R)I= In \R I(R1 R2)I=R I1∩R I2Figure2:Semantic rules for DLR(P,R,R1,and R2have arity n)where C1and C2are concepts,and R1and R2are relations of the same arity.An inclusion assertion C1 C2(resp.,R1 R2)is satisfied in an interpretation I if C I1⊆C I2(resp.,R I1⊆R I2).An interpretation is a model of a knowledge base K,if it satisfies all assertions inK.K logically implies an inclusion assertionρifρis satisfied in all models of K.Finally,we introduce the notion of query expression in DLR.We assume that the al-phabet A is enriched with afinite set of variable symbols,simply called variables.A query expression Q over a DLR knowledge base K is a non-recursive datalog query of the formQ( x)←conj1( x, y1)∨···∨conj m( x, y m)where each conj i( x, y i)is a conjunction of atoms,and x, y i are all the variables appearing in the conjunct.Each atom has one of the forms R( t)or C(t),where t and t are variables in x and y i or constants in A,R is a relation of K,and C is a concept of K.The number of variables of x is called the arity of Q,and is the arity of the relation denoted by the query Q. We observe that the atoms in query expressions are arbitrary DLR concepts and relations, freely used in the assertions of the KB.Given an interpretation I,a query expression Q of arity n is interpreted as the set Q I of n-tuples of constants c1,...,c n ,such that,when substituting each c i for x i,the formula∃ y1.conj1( x, y1)∨···∨∃ y m.conj m( x, y m)evaluates to true in I.DLR is equipped with effective reasoning techniques that are sound and complete with respect to the semantics.In particular,checking whether a given assertion logically follows from a set of assertions is EXPTIME-complete in(assuming that numbers are encoded in unary),and query containment,i.e.,checking whether one query is contained in another one in every model of a set of assertions,is EXPTIME-hard and solvable in2EXPTIME[4]. 4.1.2DLR local-centric OISWe now set up a local-centric framework for ontology integration,which is based on ideas developed for data integration over DLR knowledge bases[6,5].In particular,we describe。