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

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

1.构建过程

在这里，将详细介绍“国共合作”历史领域构建的总体思路和流程。在参考Skeletal Methodology(骨架法)的基础上，根据“国共合作”领域本体构建实际情况，确定了构建思路和流程，如图6-5所示。

图6-5　“国共合作”领域本体构建流程图

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

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

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

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

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

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

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

我们认为领域本体应该具有以下4个特征:

●简单、良好定义的概念层次结构性;

●结构可重用性和历史细节表现力之间的平衡性;

●在蕴涵概念公理上资源的可扩展性;

●互操作和多语言的支持性。

(2)确定核心概念

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

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

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

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

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

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

(3)建立概念层次结构

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

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

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

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

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

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

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

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

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

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

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

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

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

(西安事变，事件参与角色，周恩来)

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

(事件参与角色，参与时间，1936年12月12日)(www.xing528.com)

(事件参与角色，参与地点，西安)

(事件参与角色，参与身份，中共谈判代表)

(事件参与角色，作用，……)

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

(西安事变，事件参与角色，中共谈判代表周恩来)

(“事件参与角色”属性类的个体)

(中共谈判代表周恩来，具体人物，周恩来)

(中共谈判代表周恩来，关系发生时间，1936年12月12日)

(中共谈判代表周恩来，关系发生地点，西安)

(中共谈判代表周恩来，事件关系描述，……)

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

(5)本体编码

在这个阶段，我们利用OWL描述语言显式地、形式化地完成了的概念模型。

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

(owl:imports rdf:resource=“http://localhost/gghzOntPro/owl/ resource.owl”/)

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

经过本体编码的概念模型如图6-7、图6-8所示。

图6-7　Protégé中的类结构编辑界面图

图6-8　Protégé中的属性编辑界面图

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

(6)实例化

实例化工作包括实例声明、实例描述和关系关联三个部分。由于我们本体构建的特点是侧重信息描述(实例表现)，所以实例化是整个开发工程过程中工作量最大、最为烦琐的部分。虽然Protégé可以帮助我们自动生成符合OWL语法的库文件，但是手工方式在Protégé中进行大量的实例声明、实例描述和关系关联仍然是非常烦琐的。实例化工作的Protégé界面如图6-9所示。

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

(7)逻辑检测和评价

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

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

(8)文档化

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

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

图6-11　“事件”本体的类层次结构文档图

2.工作成果

我们建立的“国共合作”历史领域本体库中包含了167个本体类、108个关系属性、100个推理属性和13 142个实例，其中事件本体实例761个，资源本体实例678个，组织本体实例951个，人物本体实例1 712个，地点本体实例1 361个，时间本体实例3 361个，角色类实例2 838个，其他类实例1 480个。这种规模在类似的中文系统中实属少见。

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