基于本体的数字图书馆检索模型研究(三)--历史领域资源本体的构建_数字图书馆论文

基于本体的数字图书馆检索模型研究(Ⅲ)——历史领域资源本体构建,本文主要内容关键词为:本体论文,数字图书馆论文,模型论文,领域论文,历史论文,此文献不代表本站观点,内容供学术参考,文章仅供参考阅读下载。

1 引言

近些年来,本体(Ontology)已经在知识工程、人工智能、语义网等相关领域得到了广泛关注和深入研究,被广泛应用以解决通信、异构环境互操作和系统工程中的知识重用和共享、知识获取和系统集成等问题[1—3]。但是目前在数字图书馆领域,本体资源仍然是种稀缺资源。大部分的可公开获取的资源也主要局限在几个有限的自然科学知识领域,如生命科学、地理空间科学、农业科学等。而数字图书馆资源中很重要的一部分——人文历史学科知识的本体构建研究非常少。人文历史领域知识的时空依赖性、主观性强、不确定性、模糊性和争议性等特性也使得构建历史领域本体是非常复杂和困难的[4]。

同时,下一代数字图书馆将呈现以网格为运行环境,和Web资源相融合,实现面向全球开放模式的特点[5]。其对目前的知识表示、信息组织、资源发现、海量数据处理和软件重用提出了一系列挑战。具体而言,网格环境分布式的本质自然提出了异构环境下互操作的问题(包括技术互操作、资源互操作和组织互操作等);与Web资源相融合则意味着数字图书馆成指数级增长的海量信息将带来扩展性和可管理性的问题;而面向全球开放模式必然涉及跨语言和跨文化的问题。这三者又相互交织在一起,对数字图书馆的信息存储和信息服务提出了更高的要求。

在这种背景下,我们利用本体的思想和方法来对数字图书馆中的人文历史学科资源进行知识组织和知识表现,构建了“国共合作”历史领域本体。本文将向大家介绍我们在“国共合作”历史领域本体构建上所做的工作,希望和大家分享我们的经验和成果,交流和探讨我们在开发过程中遇到的问题和解决方法。

2 项目背景

2.1 选题背景

“国共合作”历史领域本体构建是“基于本体的数字图书馆检索模型研究”自然科学基金项目的一部分。该课题目标是建立数字图书馆平台上蕴涵语义的检索模型,帮助用户检索和理解数字图书馆的Web资源。“国共合作”历史领域本体在其中发挥着重要作用:其界定了系统所要表现的知识领域的边界和范围;为检索服务提供了具有计算机可以理解语义的资源以及推理蕴涵知识所需要的公理和规则。

2.2 领域本体及其构建特点

我们所构建的“国共合作”历史领域本体描述了从五四运动开始一直到前不久连战访问大陆的这段历史时期涉及的概念、术语、关系、个体。其中包括以“国共合作”为轴线涉及的人物、组织、事件、资源等,以及政治、经济、文化教育、军事等多学科领域知识。领域本体的目标用户可以是普通用户、历史知识爱好者、近现代史研究专家以及党建党史专家。

通过构建领域本体,一个统一的知识描述模型为实现互操作提供了可能;本体库中基于描述逻辑的概念蕴涵公理为实现Web 资源的知识框架可扩展奠定了坚实的基础;同时基于规则的推理可以帮助发现领域知识中的蕴涵知识;RDF 资源描述框架则较好解决了信息资源多语言描述问题。

此外,我们构建的历史领域本体和目前大部分集中在抽象概念层次关系描述和信息组织领域的本体不同,它不仅仅是信息组织(概念分类)实现,更重要的是尝试利用本体进行信息描述(实例表现),即用本体的语义描述能力来展现历史学科领域错综复杂的人物、组织、事件等个体以及它们之间错综复杂的关系。已建的本体库包含了167个本体类、108个关系属性、100个推理属性和13142个实例,平均关系复杂度为5(目前该领域研究的平均关系复杂度为2)。相对于本体类个数,如此巨大的实例数量,即使在国外的本体构建项目中也是很少见的。

3 构建领域本体的必备条件

“工欲善其事必先利其器”。本体构建是一项十分复杂的系统工程,需要正确的开发思想指导和合适的开发工具辅助。我们认为构建历史领域本体至少需要以下4个方面的准备。

3.1 本体形式化描述语言的选择

本体形式化描述语言直接影响本体模型的表达能力和可扩展能力。目前的形式化的本体描述语言非常多,主要有RDF和RDF-S、OIL、DAML、OWL、KIF、SHOE、XOL、OCML、Ontolingua、CycL、Loom。经过比较,我们选用了OWL(Web Ontology Language)。

OWL的优点是以Web资源为描述对象,而且是W3C的推荐标准,所以具有良好的应用前景。另外,OWL是基于描述逻辑的。描述逻辑(Description Logic,DL)是一阶谓词逻辑的可判定子集,能够提供可判定的推理服务,并且具有语义特征[6—8]。这就意味着基于描述逻辑的OWL的类构造算子和公理都有相应的逻辑描述表示, 这样利用OWL构建的本体库在具备良好的表现能力的同时具有强大的推理能力。这对于Web资源的逻辑检测、本体集成、知识整合是非常重要的。

3.2 本体开发工具的选择(Protégé+OWL plugin)

目前国内外已经有许多成熟的本体开发平台软件可供选择。经过我们对部分常见工具的试用与比较,选择的是其中的佼佼者Protégé3.1(用户界面截图如图1所示)。Protégé是由斯坦福大学医学信息化研究小组开发的,一个基于Java环境的开放式架构的开源知识建模工具[9]。其扩展的OWL插件是目前最为强大的OWL本体构建工具。Protégé不仅具有良好的可扩展性和简单灵活的用户定制界面,还具有如下一些特性:支持图形化本体编辑模式、支持数据库存储模式、基于OWL数据库的多人开发模式和支持逻辑检测功能等。最新版本的Protégé还增加了对资源多语言描述的支持。更为重要的是,Protégé还拥有超过50000人的注册用户和邮件列表用户,高效的技术服务支持以及丰富的技术资料和本体资源。这些都极大地方便了我们本体构建的学习和问题的解决。

图1 Protégé界面截图[9]

3.3 确立本体工程指导思想

本体构建是一个复杂的系统工程,需要明确的开发思想、方法和规划来推动项目。近年来,本体工程的思想和方法已经被大家广泛接受。不少国内外专家提出了本体构建的方法论:如IDEF-5、Skeletal Methodology(骨架法)、企业建模法(TOVE)、METHONTOLOGY以及Cyclic Acquisition Process方法等[10]。经过研究,我们发现现有方法论的指导思想和构建流程并没有太大的差别,我们可以在借鉴现有几种方法基础上,结合“国共合作”领域本体构建的实际情况提出自己的思路与流程。

3.4 领域专家的参与

领域本体构建是本体开发人员与领域专家共同努力的结果。开发人员虽然具有丰富的本体知识和较强的开发能力,但是对特定领域知识却知之甚少,很难建立起面向特定领域的本体模型。所以本体构建非常需要领域专家的参与。在“国共合作”领域本体构建过程中,我们邀请了华中师范大学近现代史研究所的两位博士参与本体库构建。在整个过程中,他们细致而专业的历史理论支持给予了我们很大帮助。

4 “国共合作”领域本体构建过程

4.1 构建过程

在这里,我们将详细介绍“国共合作”历史领域构建的总体思路和流程。在借鉴3.3小节提及的几种本体构建方法论,特别是在参考Skeletal Methodology(骨架法)的基础上,根据“国共合作”领域本体构建实际情况,我们确定的构建思路和流程如图2所示。

图2 “国共合作”领域本体构建流程图

整个开发过程不是简单的从上而下顺次推进,而是一个增量迭代的过程。

1)识别本体构建目标、范围

首先,我们需要确定的是本体构建的目标和需要解决的问题,即需要建立怎么样的领域本体。经过分析,认为构建本体有3个重要性依次递减的目标:

(1)利用本体思想和OWL语言组织和描述“国共合作”历史领域知识;

(2)建立具有逻辑检测和可扩展性的本体库;

(3)为数字图书馆资源的互操作和跨语言提供实现基础。

根据这个目标,历史领域知识的模糊性和不确定性不是我们需要首要解决的问题,即我们研究的是信息处理方法,而不关注信息本身真实性鉴别问题。

最终我们构建的领域本体应该具有以下4个特征:

(1)简单、良好定义的概念层次结构;

(2)取得结构可重用性和历史细节表现力之间的平衡;

(3)具有建立在蕴涵概念公理上的资源可扩展性;

(4)支持互操作和多语言特性。

2)确定核心概念

识别本体构建目标、范围后,首先要做的就是利用本体建立领域知识概念模型。目前建立领域本体概念模型通常有三种方法:

(1)自顶向下(top-down)方法,其表现形式是由现有的领域本体模型构建应用本体模型,其中应用本体为针对特定对象而生成的本体;

(2)自底向上(bottom-up)方法,其表现形式为将领域知识中名词性的概念、术语等进行识别、处理二义性、归纳、聚类、泛化等处理,建立概念模型;

(3)核心扩展(middle-out)方法, 其表现形式为由具有本体雏形的一组核心概念入手,不断扩展本体概念模型。

其中(1)和(3)方法在目前的本体构建项目中应用比较多,(2)适用于拥有大量领域知识资料并且能够使用自动或者半自动本体采集生成工具的情况。虽然我们将《国共合作通史五卷本》与《中国革命历史文献采集标准》作为领域知识来源,而且得到了领域专家的帮助。但是,我们认为采取自底向上方法过于烦琐,而且目前的自动或者半自动本体采集生成工具使用效果也不好。所以我们决定采用核心扩展的方法建立本体概念模型。

使用核心扩展的方法首先需要确定核心概念集。以《国共合作通史五卷本》与《中国革命历史文献采集标准》为基础,我们在领域专家帮助下通过头脑风暴法产生所有潜在的核心概念,经过识别、分析和统计,最终确定了“时间”、“地点”、“人物”、“组织”、“资源”和“事件”六个核心概念。核心概念作为概念模型的顶级概念,必须满足没有二义性、互不相交和并集覆盖整个历史领域知识的要求。

3)建立概念层次结构

确立核心概念之后,我们对由这组具有本体雏形的核心概念进行扩展,建立整个本体概念模型。这个过程也是一个自顶向下的过程,即根据事先定义好的上一层抽象父类,分别逐步细化说明其下一级子类。

在建立概念体系过程中,有两个问题需要我们认真考虑和解决:

(1)概念间关系的选择和层次结构的组织;

(2)概念层次结构可用性和表达精确性的平衡。

领域本体的概念之间存在许多关系,仅仅“部分—整体”关系据统计就达6 种之多[11]。“部分—整体”关系是本体构建中常用的层次结构划分标准, 其中“Kind of”和“Part of”是两个最常用的,也经常被混用的“部分—整体”关系。一个结构良好的、可扩展的概念模型要求其层次结构中的概念关系必须是同质的、直接父子概念之间具有相同的泛化程度。“Kind of”关系能够很好满足这些要求。因为其相当于面向对象思想中“is a”,利用这种关系来组织概念(对象)的稳定性和可扩展性已经在实际工程应用中得到了检验。而且面向对象的封装性、父子类继承等特性也能较好地帮助我们进行本体模块化构建。

另一个问题是本体概念模型的可用性、可理解性和其表达精确性之间的两难选择。领域本体的目标是完整清晰地描述领域知识框架,达到重用和分享的目的[12]。这目标本身就是一个“悖论”。我们本意也想建立一个完整详尽的概念模型精确描述历史领域本体。但是当领域专家建立了一个很详尽完整的概念模型后,我们发现这个模型非常难以掌握和理解,甚至领域专家之间对其中一些概念和结构争论不休。这触发了我们的思考:需不需要一个复杂且精确的概念模型来描述一个希望被大多数人理解和重用的本体。我们认为不需要,一个简单清晰的模型更加适合项目的实际需要。

经过对概念模型中的概念进行消除二义性、同层次概念间互不相交以及并集覆盖整个父类概念范围的处理,最后我们得到了3 层结构的“国共合作”历史领域本体概念化模型,其2层结构如图3所示。

4)定义概念、术语和属性

概念层次结构还只是本体的骨架,其血肉就要通过概念间的关系,即属性来充实了。根据我们的项目的特点,概念需要定义两种属性,一种用于描述概念的自身信息和结构,另一种用于描述概念之间的关系,即数值属性与对象属性。同时,还需要进行概念和关系明确定义的工作,即对属性自身的性质,如取值类型、允许取值以及属性的基数进行说明。

在这一阶段,同样有两个问题值得注意:

(1)面向对象类继承特性的应用。 我们根据概念模型是基于面向对象的特点,充分利用类继承的方法进行属性定义。子概念通用的属性在父概念中定义,子概念继承父概念的所有属性,再定义自己特有的属性。这样减少了属性冗余,增强了概念模型的表达能力。以图3中的“人物”父概念和“国际人士”子概念为例,姓名和性别是所有人物都有的属性,所以是“人物”父概念的共有属性。而字、号等属性是中国人才用的,“国际人士”的个体是没有的,所以字、号的属性不属于“人物”父概念的共有属性,只能在中国人相关的子概念中定义。

图3 “国共合作”历史领域本体概念化模型(2层结构)

(2)N—元关系分解。因为OWL语言只能通过“主体—属性—客体”三元组来描述二元关系。而在历史领域中,各对象间有很多复杂的关系,有些关系不是二元的,而是多元的。这种多元关系主要体现在许多概念的属性中还具有属性,即带属性的属性。如“事件”概念中的“事件参与角色”对象属性有如下个体知识:

〈西安事变,事件参与角色,周恩来〉

而实际上,“事件参与角色”还应该反映出更多的信息,如参与的时间、地点、人物在事件中的作用、地位等。这些就可以看成是“事件参与角色”对象属性的属性。用三元具体描述如下所示:

〈事件参与角色,参与时间,1936年12月12日〉

〈事件参与角色,参与地点,西安〉

〈事件参与角色,参与身份,中共谈判代表〉

〈事件参与角色,作用,……〉

我们的解决办法是将带属性的属性定义为一个属性类,将属性本身具有的属性定义为该属性类的属性。如“事件参与角色”定义为“事件参与角色”属性类,其包括时间、地点等属性。这个属性类就是角色个体的集合。这样〈西安事变,事件参与角色,周恩来〉三元组就可以表示成:

〈西安事变,事件参与角色,中共谈判代表周恩来(“事件参与角色”属性类的个体)〉

〈中共谈判代表周恩来,具体人物,周恩来〉

〈中共谈判代表周恩来,关系发生时间,

1936年12月12日〉

〈中共谈判代表周恩来,关系发生地点,西安〉

〈中共谈判代表周恩来,事件关系描述,……〉

在此基础上,我们认为历史领域知识的时空间依赖性都可以转化为N—元关系分解问题加以解决。例如,人物的职务,人物与组织的关系,人物、组织与资源的关系,人物、组织、资源与事件的关系等属性都涉及时间和空间的属性。将这些问题综合起来考虑,在六个核心概念的基础上,我们提出了“角色”概念。这一概念作为六个原始概念的补充,具有增强历史领域本体语义表现能力的作用。

5)本体编码

在这个阶段,我们利用OWL描述语言显式地形式化上个阶段完成的概念模型,这部分工作主要是通过Protégé+OWL插件的本体开发工具来完成的。

出于本体资源可重用性和开发协同性的考虑,我们没有像大多数本体构建项目一样,将六个核心概念和角色属性类本体定义在一个owl文件里。 而是将六个核心概念分开定义到六个owl文件, 角色属性类根据其语义增强的对象的不同定义到不同的本体文件中,这样就得到六个本体文件。在文件中,利用owl:imports属性可以在六个本体文件之间实现资源调用,如下所示:

〈owl:imports rdf:resource=″http://localhost/gghzOntPro/owl/resource.owl#″/〉

同时,我们通过OWL中的注释属性(annotaion)来对本体资源(类、属性、实例等)进行标注。Protégé可用到的注释属性包括OWL预先定义好的owl:versionInfo、rdfs:label、rdfs:comment、rdfs:seeAlso、rdfs:isDefinedBy五个注释属性和外部调用的Dublin Core元数据模型中的属性,如title、creator、subject、description、contributor。 利用这些属性我们可以标注本体资源的版本信息、领域信息、分类信息以及开发者、备注等。这有助于开发人员的分享、交流以及其他Web服务和本体获取工具对该领域本体资源的识别和使用。

最后经过本体编码的概念模型在Protégé中如图4、图5所示。

图4 Protégé中的类结构编辑界面

图5 Protégé中的属性编辑界面

Protégé中还提供了逻辑检测的功能。我们利用Racer推理机对本体库概念和属性进行逻辑检测,保证了所建立的本体库结构的正确性。

6)实例化

实例化工作包括实例声明、实例描述和关系关联三个部分。因为我们本体构建项目的特点是侧重信息描述(实例表现),所以实例化是整个开发工程过程中工作量最大,最为烦琐的部分。虽然Protégé可以帮助我们自动生成符合OWL语法的库文件,但是手工在Protégé中进行大量的实例声明、 实例描述和关系关联仍然是非常烦琐的。所以在今后本体构建中我们希望引入能从原始领域知识源中自动抽取知识,进行实例声明、实例描述和关系关联的工具,减轻本体构建的工作量。

实例化工作的Protégé界面如图6所示。

图6 Protégé中的实例浏览与编辑界面

7)逻辑检测和评价

在进行实例化工作时应注意,由于是人工录入,多人协作,所以比较容易出错。我们利用Racer推理机的逻辑检测对本体概念进行一致性和包含性检测, 对实例进行冲突检测,以发现本体中概念定义矛盾和实例属性关系关联有误的情况,确保本体库在逻辑上的正确性。

同时在每个阶段和阶段之间,我们还将从正确性和有效性两个角度对本体、软件环境、文档进行技术判断,做出阶段工作和阶段成果的评价,对问题和变化做出快速反应,保证本体构建工作按照目标顺利进行。

8)文档化

在整个本体构建过程中,我们非常重视开发文档的规范化工作。我们认为将技术资料和工作成果形成文档可以有效促进知识共享和传承。Protégé中的某些文档生成功能也为文档规范化提供了方便。

由Protégé生成的本体文档如图7、图8所示。

图7 “国共合作”领域本体库的OWLDoc文档

图8 “事件”本体的类层次结构文档

4.2 工作成果

我们建立的“国共合作”历史领域本体库中包含了167个本体类、108个关系属性、100个推理属性和13142个实例,其中事件本体实例761个,资源本体实例678个,组织本体实例951个,人物本体实例1712个,地点本体实例1361个,时间本体实例3361个,角色类实例2838个,其他类实例1480个。

同时我们还解决了本体库数据库存储、owl数据库模式多人协作开发、 本体资源多语言描述等问题。

5 一些需要探讨的问题

本体构建开发工程,其实也是一个发现问题和解决问题的过程。下面我们列出一些本体构建中值得进一步探讨的问题,希望对其他领域的本体构建有所参考价值。

5.1 多语言支持

根据数字图书馆资源、服务开放性和全球性的特点,我们在构建过程中非常注意多语言问题的解决。在领域本体资源构建中,我们对此主要做了两个方面的工作:一是本体资源多语言描述,二是用于资源互操作的资源注释属性(annotation property)多语言标注。

OWL的xml:lang属性为实现资源注释属性多语言标注提供了很好的支持。经过多语言标注的资源注释属性如以下owl代码所示:

〈rdfs:label xml:lang=″cn″〉历史事件〈/rdfs:label〉

〈rdfs:label xml:lang=″en″〉Event〈/rdfs:label〉

通过定义不同语言的注释属性,本体资源就可以在多语言环境下被识别和共享,实现资源互操作的多语言特性。

最新的Protégé也增加了对本体属性值多语言描述的支持,即本体资源可以用多种语言进行描述。如“地点”本体中实例“西安”的地名“name”属性的值用中英文描述的owl代码如下所示:

〈City rdf:ID=″西安″〉

……

〈name xml:lang=″cn″〉西安〈/name〉

〈name xml:lang=″en″〉Xi'an〈/name〉

……

〈/City〉

在此基础上,我们可以进一步研究如何将本体库多语言描述和前台服务的多语言结合起来,以解决数字图书馆多语言环境的问题。

5.2 开放世界理论和封闭世界理论

进行领域本体构建时还特别需要注意开放世界假设对本体构建的影响。本体作为一种对现实世界问题的形式化描述,经常会遇到不完全知识的处理问题。通常的做法有两种:开放世界假设(Open World Assumption)和封闭世界假设(Closed World Assumption)。在大多数情况下,我们都是采用封闭世界理论,如数据库。但是,在基于网格的数字图书馆环境下,因为Web的开放性, 相关的知识很可能分布在Web上不同的场所,因此在语义Web上推理,用封闭世界假设是很不恰当的。而且,OWL的逻辑基础——描述逻辑中的推理也是基于开放世界假设的, 所以我们采用了开放世界假设。

开放世界假设直接影响到本体库逻辑推理的结果。我们从唯一名假设、概念的分离和覆盖、实例识别、封闭公理的应用等方面来尽量减小开放世界假设带给本体构建的不确定性。随着Web上本体资源的增多,开放世界假设对本体资源构建、 整合影响将越来越大,也越来越需要我们谨慎处理。

5.3 本体的可重用性和面向特定领域

在领域本体构建领域,本体的可重用性和面向特定领域一直是一个两难问题。因为本体的根本目的就是知识的重用和共享,所以最理想的目标就是建立一个任务独立的可重用的本体模型。但是作为面向特定领域的领域本体,其又是必须依赖领域的,只有这样才能使得领域本体具有良好的领域知识表达能力。在项目中,我们希望在两者之间找到一个平衡点,在不影响本体表达领域知识的前提下,尽可能使得本体模型简单清晰、容易理解,至少在历史领域内可被重用。将六个本体分开定义也是出于可重用性的考虑。

尽管如此,当涉及Web上本体资源的集成、重用时,情况将变得更为复杂。最近两年来,本体标准化和模块化构建已经成为本体领域新的研究热点[6]。 这方面研究的突破可能为解决这个两难问题提供方法。

6 结论

在这篇文章中,主要介绍了我们在“基于本体的数字图书馆检索模型研究”课题中所做的本体构建工作,总结了项目实施的经验和对本体构建中一些问题的思考。

虽然目前数字图书馆和本体都是信息管理领域的热点,但是数字图书馆领域资源组织和历史领域本体构建还是两个有待深入研究的领域。我们相信利用本体的思想和方法来组织历史领域知识,构建面向语义的“国共合作”历史领域本体库是在这两个研究领域里一次非常有意义的尝试。当然,我们的研究中也还存在一些问题,需要进行进一步的深入和完善。希望我们在该项目上所做的工作能够对大家有所帮助,也衷心希望和大家交流经验、相互学习。

收稿日期:2006年1月16日

标签:;  ;  ;  ;  ;  ;  ;  ;  

基于本体的数字图书馆检索模型研究(三)--历史领域资源本体的构建_数字图书馆论文
下载Doc文档

猜你喜欢