本体的构建

本体的构建_多语种叙词本体

2.4　本体的构建

2.4.1　本体描述语言

本体描述语言，又称标置语言或构建语言，是表示本体的语言工具。它为本体的构建提供建模元语和标引工具，使得本体能够从自然语言的表示格式转化为机器可读的逻辑表达格式。本体描述语言使用形式化的语言表示本体，让本体可以直接被计算机存储、加工和利用。另外，本体描述语言通过提供标准的机读格式，实现了本体在不同系统之间的导入和输出。

以下重点介绍几种主要的本体描述语言。

2.4.1.1　RDF

RDF(Resource Description Framework，资源描述框架)，是由W3C于1999年开始研发的，旨在创建描述Web资源的元数据，支持互联网上的知识共享(Knowledge sharing)和知识交换(Knowledge exchange)。它提供了针对数据的模型及语法，使得独立的个人或团体也可以对其进行使用或交换。RDF是表述对象及对象之间二元关系的语言规范。

RDF文档使用XML编写，被RDF使用的XML语言称为RDF/ XML。通过使用XML，RDF信息可以轻易地在使用不同类型的操作系统和应用语言的计算机之间进行交换。RDF和XML之间是互补的: RDF的作用之一是以一种标准化的、具有互操作性的模式为基于XML的数据规定语义。

RDF数据模型包含3种类型的元素:

①资源(Resource)和实体(Entities):用统一资源标识符(URI，Uniform Resource Identifier)进行资源标识。例如网页、网站和书等，具体如“http://www.w3school. com. cn/rdf”。资源ID(Resource Identifier)是资源的唯一标识，资源ID由URI加上一个特定锚ID(Anchor)组成。

②属性(Proporties)，定义了资源的各个方面(Aspects)，包括特征(Characteristics)、属性(Attributes)或关系。比如“author”或“homepage”。

③声明(Statements)，即拥有已被命名的属性，属性又被赋值的特定资源就是RDF声明。RDF声明由3部分组成，类似于汉语中的主谓宾结构:主题(Subjects)，一项特定的资源，用椭圆标记;谓词(Predicates)，一个被命名的属性，用箭头标记;对象(Objects)，在该资源中属性的取值，用矩形标记。

RDF具有普遍性，它不局限于某个领域的网络资源定义，其描述的网络资源也不局限于某一种格式。RDF语言的主要功能特征所描述的内容包括以下几个方面:

①Resource:它是一类特定的信息条目，通常是一个Web站点。资源一般以URL进行标识。标识符并不一定必须用英语或其他自然语言来表示，也可以使用其他语种。

②Class/Subclass:由于资源能够被分成各种类(Class)，而每个类下面又可以分为更小的下位类(Subclass)，这些便构成了完整的分类体系系统。

③Property:用来连接两个相关的资源，描述它们之间的关系。

④Domain/Range:一个Property中的所描述资源可以受到限定，一个目标域(target“Domain”)以及目的文件范围(destination“Range”)会受到一个特定类的限制。

⑤Container:用于组织资源集合。Container包括:集(set)、元素次序(Sequence)以及其他的选择。

RDF研究队伍中的核心工作组为RDF制订了两个重要规范:

一是RDF Model and Syntax的推荐标准(Candidate Recommendation)。RDF Model and Syntax提出了一个由资源、属性和声明构成的数据模型。该数据模型通过命名属性和属性取值来描述资源之间的内在关系。此方法类似于E-R图模型(Entity-Relationship model)。该数据模型的基本语法为:

①规定了描述资源、属性和声明语法的巴科斯范式(一种严格的用递归定义式表达语法的方法)，以及一些缩写格式。

②使用bag、queue和alternative三种容器来表示资源集合。

③提出了具体化(Reification)的方法来实现声明的自定义，并使用4个属性(包括主题subject、谓词predicate、对象object和类型type)来对其进行描述。

二是RDF Schema的候选推荐标准。

2.4.1.2　RDFS

RDF使用命名特定和值来表达与资源有关的简单声明。但很多情况下，用户希望能够自定义一些词汇，然后用这些词汇来描述资源。总的说来，就是需要定义一些类和特性，比如定义Person类来描述人，定义Book类来描述图书，定义Author特性来描述图书的作者等。RDF本身并不能定义这些类和特性，它们需要用RDF的描述语言RDF Schema来定义。

RDF Schema以抽象世界中的主要关系为基础建立类型系统，从而支持了从客观世界到抽象世界的映射。属性即资源之间的关系，它提出了类的概念和限制(Constrain)的概念，不仅描述了该类具有哪些主要属性，也描述了该属性可以从属于哪些类。于是用户便可以依据RDFS定义一个自己的属于某个特定领域的Schema。

RDFS对资源的描述的数据模型是基于框架的(Framesbased)，并为定义资源与属性之间的关系提供了机制。RDFS定义了核心的概念和类，等级体系和类型约束(Hierarchies and Type Constraints)，核心属性(Core properties)，核心限制(Core Constraints)以及类型系统(Type System)。

RDFS的核心类有:

①Rdfs: Resource，表示RDF中所有资源的集合。

②Rdf: Property，表示RDF中所有属性的集合。此处属性也是一种资源。

③rdfs: Class，表示RDF中所有类的集合。此处的类与面向对象中的类的定义相似，是一种资源。

2.4.1.3　OWL

OWL语言是W3C Web-ontology工作小组于2001年开发的，旨在提供一种可以面向各种应用的语言。同时，W3C还发行了OW L的Web Service框架使用方案集合的工作草案，为下一代的Web服务提供使用案例和方案。它是结合了DAML+OIL应用经验而改进的修订版(因此就不再介绍DAML+ OIL)，建立在RDF基础上，以XML为书写工具。主要用来表达需要计算机应用程序来处理的文件中的知识信息，而不是呈递给人的知识。OWL能清晰地表达词表中各词条的含义及其之间的关系，这种表达被称为本体。OWL相对XML、RDF和RDF Schema拥有更多的机制来表达语义，从而OWL超越了XML、RDF和RDF Schema仅仅能够表达网上机器可读的文档内容的能力。

OWL分三个子语言: OWL Lite、OWL DL、OWL Full。相应简介如表2-4所示。

表2-4　OWL子语言简介表

以上3种子语言之间的关系如下:每个合法的OWL Lite都是一个合法的OWL DL;每个合法的OWL DL都是一个合法的OWL Full;每个有效的OWL Lite结论都是一个有效的OWL DL结论;每个有效的OWL DL结论都是一个有效的OWL Full结论。

对于以上3种子语言的选择，主要考虑的因素有:

①OWL Lite或OWL DL的选择，主要取决于用户需要整个语言在多大程度上给出约束的可表达性;

②OWL DL或OWL Full的选择，主要取决于用户在多大程度上需要RDF的元模型机制;

③在使用OWL Full而不是OWL DL时，推理的支持不可预测，是因为目前还没有完全的OWL Full的实现。

2.4.1.4　DL

描述逻辑(DL，Description Logics)是一种非常重要的知识表现形式，它为传统的、应用广泛的、基于框架的系统、语义网络、面向对象的表示法、语义数据模型和类型系统提供了统一的逻辑基础。

DL建立了若干种用于评价语义网(Semantic Networks)的重要指南。目前基于本体层面的比较流行的推理操作有如下几种:

①自动分类、归类(Automatic Classification/Subsumption)。该操作为基本操作，能够自动地判定对于一个给定的概念A是否属于另一个概念B的下位概念。该操作可以为构建分类体系提供帮助，也可以作为构造检索式的基础。

②概念匹配，检索式加工(Concept Matching，Query Processing)。通过定位一个基于一种描述的概念，在本体中找到一些在结构上与一个特定的、精确的对象相似的对象，完成检索过程。

③自动聚类(Automatic Clustering)。通过寻找一系列相关实例之间的相互关联关系，在此基础上构建一个新的类别。

④一致性检验(Consistency Checking)。通过寻找任何可能在逻辑关系上被错误放置的概念，检验已知本体在逻辑上是否具有一致性。

2.4.1.5　Ontolingua

Ontolingua是由斯坦福大学的知识系统实验室(KSL)在1995年开始进行研发的。Ontolingua是一种基于知识交互格式(KIF，Knowledge Interchange Format)和框架本体(FO，Frame Ontology)的构建语言，也是Ontolingua服务器用来进行本体构建的语言，它是一种本体形式化的工具，为本体的构建提供了统一规范的格式，使得本体构建的工作可以以标准化的形式进行，提高了本体构建的效率。

知识交互格式(KIF)是一种中性知识表示语言，能够满足目前高级知识表示语言中几乎所有重要的概念和区别，以及知识表示中语言的异构性问题。KIF被允许用来定义类、关系和对象，并且能将这些定义翻译成几种特定的表示语言，同时它也提供元知识的表示和非单调性的推理规则。KIF是基于一阶谓逻辑运算的知识表示语言，它拥有明确的语义，并且带有注释性的前缀。作为一种知识交互格式，KIF从本质上对本体进行了规定，但是这种用KIF写出来的与本体有关的规范说明却相当晦涩难懂。

框架本体(FO)是一种基于KIF的知识表示本体，它对本体的构建提出了一定的要求，即本体的构建必须遵循范例的框架。该框架提供了诸如class、instance、subclass-of、instance-of等类似术语。由于FO无法用来表达公理(Axioms)，因此Ontolingua允许定义中包含基于FO的KIF表达式。

Ontolingua允许用户自由选择合适的方式构建自己需要的本体。例如:只单独使用FO的词表(不能表示公理);利用KIF的表示法——表达式;同时使用两种表示语言。

Ontolingua中包含了大量用于知识表达的基本元素，如下:

①类(Class)。类是用来显示和表达一些相似概念集合的组织，每个类包括一个定义，用来描述类与实例之间的关系。同时，一个类也可以拥有一组逻辑声明，称为公理集。当用类结构无法显示某一知识时，公理集能够利用关系和属性值对其进行描述。

②上位类(Superclass)，也称母类。对于任意一个类A，如果其中的所有实例也是另一个类B中的实例，那么类B就是类A的上位类。一个类可以拥有多个上位类。

③下位类(Subclass)，也称子类。对于任意一个类A，如果其中的所有实例也是另一个类B中的实例，那么类A就是类B的下位类。一个类可以拥有多个下位类。

④个体(Individual)。在一个类中，特定发生的事件都可以称为个体。

⑤实例(Instances)。在一个本体中，所有的术语都有与之相关联的定义，如Classes、Slots、Relations以及Facets等都是某些类别的实例。实例不能等同于个体，实例可以是一个类，而个体不可能成为类。

⑥关系(Relation)。一个类中两个或更多概念之间的任何存在的关系。

⑦子关系(Subrelation)。它是某一关系集合的子集。

⑧元数(Arity)。元数是一个关系被允许携带自变量(arguments)的个数。对于一个可以携带任意数目自变量的关系函数，其元数就是不确定的。

⑨属性槽(Slot)。对于两个概念，如果它们之间存在一种严密的关系，即可称为属性槽。

⑩集的基数(Cardinality)，也称基数性。它指对一个属性槽(Slot)能够拥有的值的数量限制。

函数(Function)。函数是指将一个或多个概念关联到另一个概念(不属于前面的概念)的关系。例如，函数Father()表示一个动物只能关联另一个雄性动物。

域(Domain)。域是对概念的限制。用一种特定的属性对某一概念进行限制，使其成为某一特定类的成员。

明确的领域(Exact-domain)。

范围(Range)，也称范畴。范围是指对属性值的限制，以确保概念成为某一特定类的成员。

明确的范围(Exact-range)。

逆反(Inverse)。一对属性互为逆反属性。上位类(Superclass)和下位类(Subclass)就属于逆反关系。又例如:如果汽车(Auto)具有属性“has-wheel”，那么类别车轮(Wheel)就是“Wheel-of”的逆反属性。

公理(Axioms)。一般一个公理是一个一阶逻辑表达式，在逻辑上是重言式，即永真式。与公理相联系的类必须为真。对于某些不能用上述定义的适用限制条件来表示的复杂关系实例，可以用公理集来表达。

通过上述的内容可以发现，Ontolingua语言具有如下几个特点:

(1)提供了标准的、统一的以及可机读的方式，方便用户构建和维护本体。

(2)用Ontolingua构建的本体能够便捷地转换到各种知识表示和推理系统中，从而能够将本体的维护与使用它的目标系统分隔开来。

(3) Ontolingua主要用于本体服务器(ontology serve)，具有良好的构建机制。

2.4.1.6　OIL

OIL是由包括斯坦福大学、荷兰阿姆斯特丹大学、曼彻斯特大学计算机科学系、贝尔实验室、AIFB、麻省理工学院等在内的众多科研机构共同开发的，它以AIFB的Ontoknowledge项目为依托。OIL的全称为Ontology Interchange Language和Ontology Inference Layer，可译为“本体交换语言”和“本体推理层”。OIL实质为一种推荐标准，具有以下两种功能:一是合并和表示本体，二是进行系统间的交互。OIL统一了不同研究组的三个重要方面:描述逻辑，框架，基于XML和RDF语法的Web交换标准。

OIL使用若干元素和组件构成本体，这样的本体分为三个层次:①对象层(Object Level)，用来处理实例;②第一元层或本体定义层(The firstmeta level or ontology definition)，包含本体的定义;③第二元层或本体容器(The second meta level or ontology container)，包含本体特征的信息。利用这三层结构，OIL可以是概念、关系—函数和公理，但不能定义实例的语法结构、规则和公理。

由于OIL融合了基于框架语言以及DL提供的形式语义和推理功能的建模元语，使得它成为能够面向本体的基于Web的表示和推理层。OIL与RDFS是兼容的，并且包含用来描述术语含义的精确语义规范。以OIL为标准和本体描述语言具有分层的结构。每一个新增的层次(Additional Layer)都在前一层的基础上添加了功能性和复杂性(Functionality and Complexity)。因此，只能加工较低层次本体的人机代理可以部分地理解较高层次的本体。从图2-4中可以看出OIL和RDFS之间的关系以及OIL由外及里的四层子语言。

图2-4　OIL与RDFS的关系图像来源http://www.ontoknowlede.org/oil

OIL从外向里的四个子语言分别为:

①Heavy OIL，包含额外的表示(或推理)能力。但目前它的语法和RDF Schema还未被完整定义。

②Instance OIL，包含十分完备的个体集成。当其上一层Standard OIL包含着等待个体填充(individual fillers，会被定义和规范)的建模结构时，Instance OIL就成为一个资格完备、结构健全的数据库系统，专门等待实例个体来填充。Instance OIL的Schema与Standard OIL完全一样，每个实例都可以直接被描述为RDF格式。

③Standard OIL，其目的是为获得更多的具备充分表达能力的建模元语，而且这些建模元语要易于理解和掌握。因此，可以精确定义OIL本体中的语义，并从理论上实现推理。

④Core OIL，它基本上与RDF Schema相符合，使得简单的RDF Schema代理也能够处理OIL本体，并以自身有限的性能来说可能地“理解”OIL标引的本体含义。

在业界，RDF和Topic Maps已经是公认的描述Web资源的轻量级语言。随着研究的进展，DAML和OIL被逐步完善，成为在XML框架下构建复杂本体的语言。其中DAML被认为是OIL的扩充集合，而OIL的创立是基于DL的原则。

OIL的主要功能特征包括:

①类(Class)，在OIL中，一个类的成员需要得到规范的定义。此处的类与语义网络中最为通用的class/subclass分类体系中的class相同。

②下位类(Subclass)，也称子类，是置于某一类之下的更加专业性的类。

③类名(Name)，用于标识类或其他元素的唯一标识符。

④属性槽(Slot)，用于描述对象的特性，它与对象相关联，具有一个属性名和属性值。

⑤属性限制(Slot Constraint)，通过设置条件来限制属性的取值。这些限制条件在类的体系结构中必须得到定义，并被用来定义某一个类的成员。对于任何类，其中的所有实例必须满足属性限制，且任何类的下位类的属性限制必须与其上位类的属性限制一致。

⑥And/Or/Not，一个属性槽只能有一个以内的限制条件，且它们必须与布尔逻辑操作的使用结合在一起。

⑦Max-Cardinality/Min-Cardinality，它是用来对一个属性槽中“值”的数量进行限制，它不能超过/少于被限定的最大值/最小值。

⑧域、范围(Domain、Range)，属性限制的组成部分，其作用是合并某一领域中概念及属性相同的类，或确定类之间的隶属关系。

⑨逆反(Inverse)，属性值是可以配对的，即如果一个属性与另一个属性是相反的关系，则称这个属性是另一个属性的逆反属性。

⑩传递性、对称性(Transitive、Symmetric)，传递性是指关系的传递，例如:如果A包含B，B包含C，则A也包含C。对称性是指如果A包含B且B也包含A，则它们共用类中的属性槽的值。

Primitive/Defined class，在任何时候，属性限制是用来确定作为类的成员所应具有的充分条件和必要条件，只有明确了充分条件和必要条件的类才是确定的类(Defined class)。对于有些类，其限制条件是不能够完全得以明确的，例如限制条件是必要条件而不是充分条件的类，则称作元类(Primitive class)。

属性限制和Primitive/Defined class是DL的关键特征。它们是自动分类(决定一个类是否是另一个类的特定实例，或者一个对象是否属于一个特定的类)和其他推理操作的基础。

在OIL中，本体被定义为本体封装层(Container)和本体定义两部分。本体封装层直接引用都柏林核心集(Dublin Core)的15个元素来描述本体本身的作者、发表时间、领域、版权声明等，本体定义包括类定义、属性槽、公理及实例定义，如表2-5所示。

表2-5　OIL中的类定义、属性定义和公理定义

2.4.1.7　DAML，DAML+OI L

DAML(DARPA Agent Markup Language)，是由美国国防部高级研究计划署研发的。DAML的研发是基于XML和RDF的，实质上是XML和RDF的扩展。它与OIL相比，除了有许多相同的特性，又额外添加了一些足够引起重视的功能特性，主要包括:

①类(Class)，定义与OIL中类的定义相同。

②类标识符(Class Identifier)，用来确定类的唯一标识，以命名空间(name spaces)作为其限制。

③子类(Subclass)，定义与OIL中子类的定义相同。

④SameClass/EquivalentTo，用来说明两个类是完全相同的。

⑤Complement/Union/Disjoint/Disjoint Union/Intersection，将操作置于classes的成员之上。

⑥个体/实例(Individual/Instance)，某个类的一个个体或一个实例。

⑦子属性(Sub Property)，某一属性的子属性，前提是该属性能够形成一个分类体系。

⑧域/范围(Domain/Range)，对加入到某种特定关系中的个体所作的限制，以确保其属于某个类。

⑨属性限制(Property Restriction)，其作用类似于OIL中的Slot Constraint。

⑩Cardinality(extract，max，min) and qualified cardinality range，unique，一个属性的值的数量范围。

必要/充分条件(Necessary/Sufficient Conditions)，其作用类似于OIL中的Primitive/Defined。

逆反/传递性(Inverse/Transitive)，一个属性同另一个属性是逆反关系;属性具有传递性。

值域(Concrete domain)，某一属性的确定值，如整形(int)，字符串(string)，浮点数(float)等。

版本(Version)，某一本体可能有多个版本。

引入(Import)，从另一个本体中提取定义，添加到当前本体中。

Thing/Nothing，所有类都是类“Thing”的子集，也就是说类“Thing”是所有集的根;没有任何一个类是类“Nothing”的子集，类“Nothing”位于所有类的最底层。

其中，DAML+OIL是DAML的最新版本，它提供了丰富的结构组成元素和概念集合，用来构建本体和进行信息标记，使得机器可以解读和理解用DAML+OIL表示的本体和信息。

2.4.1.8　TM

主题图(Topic Maps，TM)最初是由独立的组织Topicmaps.Org于1999年开始开发的，现已成为ISO的主题图标准(ISO/IEC FCD 13250: 1999)。

主题图是利用图形方式表示某一主题的信息集合，信息集合中的每一部分以及它们之间的相互关系都与其表示的主题紧密相关。按照张晓林的观点，主题图是指“一定主题领域的概念集合，可以是正规叙词表或分类表，也可以是一定资源集合主题内容的结构化表现。主题图独立于技术平台，描述主题、主题关系以及主题与具体资源的联系，可‘标引’信息资源并建立相应索引、交叉参照、引文体系等，可链接复杂主题范围的分布资源来建立虚拟知识体系，可通过主题概念与资源的不同链接在同一资源集合上定制面向不同用户的界面”。

在提供标引Web资源的途径上，同RDF和其他语言相比，主题图的术语体系要更加的通俗易懂，以下介绍几个主题图中常用术语的功能特征:

①主题(Topic)，一个普通的类目，如昆虫(Insect)。

②主题名(Topic Name)，为主题命名的途径。在本体语言中，命名是非常重要的，对于本体中的每一个对象，必须有一个独一无二的名字以区别于其他对象。

③事件(Occurrence)，它是主题的一个实例，类似于RDF中的资源(Resource)以及其他语言中的对象或实例。一个事件可以是一个特定的Web站点。在Topic Maps中，一个事件的内在细节是表达语言的外在范围，它们被简单的指出，但在其他很多高级语言中，对象是属于表达语言的一部分，并且被规范定义。

④联系(Association)，描述两个主题之间的关系，类似于RDF中的属性(Property)。

⑤分面(Facets)，它是描述一个主题与一个简单值(Simple value)之间的关联，类似于联合。分面可以看成是联合中的不够典型的一种形式，因为分面描述的关联不是两个对象间的关系，也不是两个事件之间的关联，而是一个主题同一个简单值之间的关联。

⑥范畴(Scope)，主题图通过引入范畴来对那些用主题图标引的资源的概念进行分区，以便将那些与某一特定课题或学科领域相关的对象组织在一起，成为一个具有统一格式的大集合体。利用这种区分产生不同的背景，使得具有相同背景的术语能够被组织到同一范畴当中。而在不同的背景中，主题名具有不同的含义，被划分到不同的范畴中去。

2.4.1.9　SHOE

简单的HTML本体扩展(Simple HTML Ontology Extension，SHOE)是由马里兰大学计算机系并行理解系统研究组(Parallel Understanding Systems Group)于2000年开始研发的，主要用来进行高级本体标示语言(Ontology Markup Language，OML)的开发。

SHOE实质上是HTML的一个扩展，它能将机读的语义知识结合到HTML文档或Web文档中，直接在万维网上设计和应用本体。通过利用SHOE，代理能够进行有意义的Web页面和文档信息的收集，从而改善搜索机制和知识搜集。该过程包括三个阶段:

一是对本体进行定义;

二是使用本体信息对HTML页面进行注解以描述自身和其他页面;

三是通过搜索所有现存页面以及保持信息更新，使用代理在语义层面检索信息。

SHOE是一种基于HTML的、Web上的、具有XML兼容性的知识表示语言，作为HTML的扩展集，其开发的主要目的是扩展HTML，然后合并HTML或其他Web文档中的可机读的语义知识，使用代理收集Web及文档中的有用信息，改进搜索机制和知识搜集。上述过程可以分为两个步骤:

①定义本体，描述有效的对象分类体系及对象之间的关系。

②对HTML页面进行标引，从而描述自身和其他页面。

可以使用SHOE将本体标记为HTML格式的文件，也可以用概念元素资源形成HTML格式的元数据，例如:

＜ONTOLOGY＞＜/ONTOLOGY＞　　　　　文件定义符

＜DEF-RELATION＞＜/DEF-RELATION＞　类关系定义符

＜DEF-CATEGORY＞　　　　　　　　　　类定义符

＜DEF-INFERENCE＞＜/DEF-INFERENCE＞推理规则定义符

＜INF-IF＞＜/INF-IF＞　　　　　 　　推理规则条件语

　　　　　　　　　　　　　　 　　　　句定义符

＜INF-THEN＞＜/INF-THEN＞　　　　　 推理规则结论语

　　　　　　　　　　 　　　　　　　句定义符

＜CATEGORY＞　　　　　　　　　　 　　类标记符

＜RELATION＞＜/RELATION＞　 　　　　语义关系标记符

＜USE-ONTOLOGY＞　　　　　 　　　　　引入本体标记符

＜DEF_RENAME＞　　　　　　　　　　　 引入概念类或属

　　　　　　　　　　　　　　　　　　　性元素重命名标

　　　　　　　　　　　　　　　　　　　记符

＜INSTANCE＞＜/INSTANCE＞　　　　　　类实例标记符

2.4.1.10　FLogic

框架逻辑(Frame Logic，FLogic)是由德国弗赖堡大学Florid project项目组从1993年开发的，相比之前很多面向对象(Object oriented)和基于框架语言(Frame based)的结构化层次来说，FLogic具有格式新颖、清晰和共享的优势。另外，它为数据表示和知识表示提供了逻辑学基础。

FLogic拥有一套模式理论的语义(A Model-theoretic Semantics)和一套完备的基于问题解决方案的证明理论(Proof Theory)。FLogic软件平台从面向对象的演绎型数据库(Deductive Database)发展成为本体，它可以整合其他的专门逻辑(如高阶逻辑HiLog、事务逻辑Transaction Logic等)，并以此来改善本体中利用信息进行推理的功能。

2.4.1.11　Loom

Loom是由南加州大学ISI研究所的人工智能研究小组开发的，它是一种基于一阶谓词逻辑的高级编程语言，属于描述逻辑体系的语言工程，能够支持Ontosaurus工具进行本体构建的底层描述语言。经过一系列的发展，目前Loom已经发展为PowerLoom语言，PowerLoom以前后向链式规则(Backward and Forward Chainer)作为推理机制。

Loom具有如下特点:①提供的说明语言表达能力强、声明性规范;②具有强大的演绎推理能力;③拥有多种编程风格及知识库服务。

作为一种高水平的编程语言，Loom能够用于构建专家系统和其他智能软件程序的环境。Loom既是KL-ONE家庭的派生物，又是基于DL的，利用Loom可以获得一个基于规则和基于构架的两者严谨结合的范例。Loom具有以下功能:①支持为对象和关系建模的描述语言;②支持为在概念和关系上规范约束并声明有关个体事实的声明语言;③当基于产生式规则和基于分类法的推理能力支持强有力的演绎推理时，支持程序编写的功能可以通过面向模式的方法实现。

Loom在以DL的方法进行本体建模时，通过DL来定义概念并为概念加上一系列限制，完全不同于之前使用描述性语言所提供的基于框架的方法。

2.4.1.12　OKBC

基于连通的开放知识(Open Knowledge Base Connectivity，OKBC)协议是由斯坦福大学的KSL和SRI研究所的人工智能中心从1995年开始研发的，其前身是通用框架协议(Generic Frame Protocol，GFP)。OKBC定义了一个对底层知识表示系统(KRSs，Knowledge Representation Systems)进行定制的协议，弥补了用于支持知识共享的语言规范的不足。

通用框架协议的知识模型存在于OKBC基础之上，它支持以对象为中心的知识表示并提供一整套框架表示系统的表示构造方法，包括:常量(Constants)、框架(Frames)、属性槽(Slots)、属性分面(Facets)、类(Classes)、个体(Individuals)和知识库(Knowledge Bases)。

当需要通过网络来获取知识时，OKBC协议也用来为知识库定义一个完整的答问式(Tell＆Ask)界面和程序。最终，为了适应Ontolingua而发展成为OKBC ontology，它与OKBC协议是完全兼容的。

2.4.1.13　XOL

基于XML的本体交换语言(XOL，XML-based Ontolgoy Exchange Language)是由SRI研究所的人工智能中心从1999年起开发的。它以Ontolingua和OML(ontology markup language)作为基础，融合了OKBC的高层表达方式和OML语法，并借鉴XML的语法特点和OKBC的语义特点，旨在服务生物信息学领域的异构信息系统之间进行本体定义的交换。

XOL允许在XML的语法结构下定义OKBC的子集，称作OKBC-Lite。因为OKBC中定义了访问基于框架的表示系统(Framebased Representation Systems)的协议，使得XOL能在万维网上不同的系统间交换格式不同的信息。

由于目前没有支持XOL本体开发的工具，利用XOL借鉴XML语法的特点，大多采用XML编辑器创建XOL文件。尽管XOL有着良好的特性，但XOL设计的初衷是提供一种转换本体定义的格式，所以在实际中几乎不用XOL进行本体开发。

最初，XOL只是用于生物信息学本体的交互，后来才慢慢引进到本体研究的其他领域，如作为本体传递的中介语言，应用在不同的数据库系统之间或不同的本体开发工具之间。

综上所述我们得出几种本体语言之间的关系如图2-5所示。

图2-5　本体描述语言之间的关系

2.4.2　本体构建的原则及方法

本体的建库是一项庞大的工程，其过程往往表现为耗时长、花费大、精准度高以及协作性强。本体建库质量的高低，决定了所建本体能否准确表达现实世界中的概念及其之间的关系。尽管对于本体构建方法及构建工具的选择，与本体推理、本体检索、本体可视化等技术相对独立，但本体的建库过程是上述方法、技术、过程得到完美应用的保证。与此同时，本体建库的工作量是本体开发过程中的主要任务，其大小极大地影响着本体经济性和效率性。因此，在本体建库的过程中，构建方法及构建工具的选用是本体开发过程中的关键步骤。

本体构建方法论是当前本体研究领域的热点。目前本体的构建多是面向某一特定的领域，很少有面向多领域的本体，对于构建这样的本体，如果没有一种好的方法路线作为指导，就难以使不同领域的本体构建保持一致性，也不能使本体构建标准化与规模化。所以，本体构建方法的研究对于本体的应用起着至关重要的作用。

由于各自领域和具体工程的不同，本体构建选择的方法和过程也不相同。M.Uschold等人在1996年尝试制定出一套构建本体的方法，但其所做研究并不是要给出一整套关于构建本体的规范性指南，只是要表示这种方法在他们的研究环境中能很好地发挥作用。K.Mahesh和Bateman也根据自己的研究给出了相应的本体构建原则。但是这些原则都是研究人员建立在自己的系统开发经验之上，而不是针对所有的本体系统构建提出来的。因此，几乎每进行下个系统的开发，都可能会导致一些不同的本体构建方案的提出。由于现行的本体构建方法没有一个统一的标准，也没经过权威标准化机械的认证，不少研究人员出于指导人们构造本体的目的，从实践出发，提出了不少有益于构造本体的标准。到目前为止，公认的比较有影响力的本体构建规则是Gruber在1995年提出的。

(1)明确性和客观性。本体应能有效地说明所定义术语的内涵;定义应该是客观的、与背景独立的;当定义可以用逻辑公理表达时，它应该是形式化的;定义应该尽可能的完整;所有定义应该用自然语言加以说明。

(2)完整性。本体所给出的定义是完整的，能表达特定术语的含义，所有的定义应该用自然语言加以说明。

(3)一致性。由本体推导出来的概念含义应与本体中的概念含义本身一致;本体所定义的公理及用自然语言说明的文档都应该是一致的。

(4)最大单向可扩展性。向本体中添加通用或专用的术语时，不需要修改原有的内容。

(5)最小约束性。本体的约束应该最小，对待建模对象应该尽可能少的列出限定约束条件，只要能满足特定的知识共享需求即可。

以下介绍几种常用的本体构建方法。

2.4.2.1　七步法

七步法是由斯坦福大学医学院开发的，主要面向于领域本体的构建。它将本体构建划分为七个步骤，每一步骤都细分了详细的目标和任务，通过整合这七个步骤来完成本体的构建。七个步骤分别如下:

第一步:确定本体的专业领域或范畴。

在这一阶段，主要任务是要弄清以下几个基本问题:

①构建的本体将涵盖哪个专业领域?

②构建该本体的目的?是否为了更好地挖掘本领域的深层信息或知识?

③本体中的信息或知识能对哪些类型的问题做出回答或解释?

④该本体的主要用户或维护者分别是哪些人?

⑤确定本体可以解答的专业问题，即系统能力问题。

除最后一个问题，其他问题的答案在本体设计的过程中，会随着设计的进一步发展而做出相应的调整。但在任何一个特定的时间段里面，它们对于限制模型的范畴是有帮助的，所以需要相对稳定。

第二步:分析复用现有本体的可能性。

在某些情况下，如果构建的系统需要同其他应用平台进行一定交互，而该应用平台又与特定的本体或受控词表结合在一起，那么复用现有的本体就是最行之有效的办法。目前，许多本体都有相应的电子版本，而且能够输入到个人使用的本体开发系统中去。即使一种知识表达系统不能直接以某种特殊的格式来工作，将本体由一种格式转换为另一种格式并不困难。在Web上可以找到很多现在的本体文库。

第三步:列出本体中的重要术语。

构建领域本体时，需要列出一份包含所有术语的清单，清单中的术语是用来给用户进行解释的。首先，在不考虑概念间可能会出现的属性及表达上的重复情况下，列出一份尽可能全的术语清单，包含目前能够找到的所有术语。下面的两个步骤是定义概念属性和完善概念间的等级体系，这两个步骤是密不可分且相互交叉的，两者必须同时进行。这两个步骤是本体设计过程中最重要的两步。

第四步:定义类和类的等级体系(hierarchy)。

以下是完善类的等级体系的几种可行方法:

①自顶向下法:以某一领域中的最大的概念为起点，而后逐渐将这些概念细化。

②自底向上法:以底层的最小类的定义为起点，分别将这些被细化的类组织在更为综合的概念之下。

③综合法。综合上述两种方法。首先定义大量重要的概念，然后分别将它们进行恰当的归纳和演绎，再将它们与一些中级概念关联起来。

对于上述三种方法的选择，主要取决于开发者对该专业领域的理解程度和观点。如果开发人员对一专业具备一套自上而下的系统认识论，那么利用自顶向下的方法会事半功倍。由于在领域的概念中，“中层概念”是更具有代表性的，所以综合法对绝大多数开发而言，是最为敏捷的。如果想要收集更多更广泛的实例，那么自底向上的方法更加适合。当然，无论选择哪种方法进行，都需要从“类”的定义开始。

第五步，定义类的属性。

仅仅只有类的体系而没有概念间的内在结构的本体，是不足以提供系统能力问题所需要的答案信息。因此一旦定义好了类，就必须开始描绘概念间的内在结构。

首先从第三步建立的列表中选择好类。而绝大多数剩下的术语可能就是这些类的属性。一般情况下，有几种对象属性的类型能够成为一个本体中的属性:

①“内在”属性(intrinsic properties)，例如某种汽车的颜色。

②“外在”属性(extrinsic properties)，例如某种汽车的产地。

③如果对象是结构化的，那么它的一部分，可以是既具体又抽象的元素。

④与其他个体的关系。此处的“关系”是指某个类中的个体成员与其他类之间的关系。任意一个类的所有下位类都会继承其上位类的属性。

第六步:定义属性的分面(Facets)。

一个属性可能由多个“分面”组成。一个属性的“分面”就是属性取值的类型(Value Type)，容许的取值(Allowed Values)，取值个数(Cardinality集基数)和有关属性取值的其他特征。

第七步:创建实例。

此过程包括以下工作:确定一个类，创建该类的一个实例，以及添加这个类的属性值。

2.4.2.2　TOVE法

TOVE法，又称Gruninger＆Fox“评价法”。TOVE指多伦多虚拟企业(Toronto Virtual Enterprise)专用于构建TOVE本体(关于企业建模过程本体)，由多伦多大学企业集成实验室(Enerprise Integration Lab.)研发，使用一阶谓词逻辑进行集成。TOVE本体包括企业设计本体、工程本体、计划本体和服务本体。TOVE流程图如图2-6所示。

图2-6　TOVE流程图

①设计动机。定义直接可能的应用和所有解决方案。提供潜在的非形式化的对象和关系语义表示。

②将系统“能够回答的”问题作为约束条件，包括系统能解决什么问题和如何解决。这里的问题用术语表示，答案用公理和形式化定义回答，由于是在本体没有形式化之前进行的，所以又被称为非形式化的系统能力问题。

③术语的形式化。从非形式化系统能力问题中提取非形式化的术语，然后用本体形式化语言进行定义。

④形式化的系统能力问题。一旦本体内的概念得到了定义，系统能力问题就脱离了非形式化，演变为形式化的能力问题。

⑤将规则形式化为公理。术语定义所遵循的公理用一阶谓词逻辑表示，包括定义的语义或解释。

⑥调整问题的解决方案，从而使本体趋于完备。

2.4.2.3　骨架法

骨架法，也称Enterprise法，是专门用来构建企业本体的方法。(Enterprise ontology，关于企业建模过程的本体)。骨架法是建立在企业本体基础之上，关于商业企业间术语和定义的集合，该方法只提供开发本体的指导方针。目前企业本体项目由爱丁堡大学人工智能研究所(AIAI，the Artificial Intelligence Applications Institute)及合作伙伴——IBM，Llgyd's Register，Logica UK Limited和Unilever共同承担。骨架法流程图如所2-7所示。

图2-7　骨架法流程图

①确定本体应用的目的和范围:根据所研究的领域或任务，建立相应的领域本体或过程本体，领域越大，所建本体越大，因此需限制研究的范围。

②本体分析:定义本体所有术语的意义及其之间的关系，该步骤需领域专家的参与，对该领域越了解，所建本体就越完善。

③本体表示:一般用语义模型表示本体。

④本体评价:建立本体的评价标准是清晰性、一致性、完善性、可扩展性。清晰性就是本体中的术语应被无歧义的定义;一致性指的是术语之间关系逻辑上应一致;完整性，本体中的概念及关系应是完整的，应包括该领域内所有概念，但很难达到，需不断完善;可扩展性，本体应用能够扩展，在该领域不断发展时能加入新的概念。

⑤本体的建立:对所有本体按以上标准进行检验，符合要求的以文件的形式存放，否则转②，如此循环往复，直至所有步骤结果均达到要求。

2.4.2.4　METHONTOLOGY法

METHONTOLOGY法专用于构建化学本体(有关化学元素周期表的本体)，该方法已被马德里大学理工分校人工智能图书馆采用。它的流程包括三个阶段:

①管理阶段。这一阶段的系统规划包括任务的进展情况、需要的资源、如何保证质量等问题。

②开发阶段。分为规范说明、概念化、形式化、执行以及维护五个步骤。

③维护阶段。包括知识获取、系统集成、评价、文档说明、配置管理五个步骤。

目前，用这种方法开发的本体有:

①(Onto) Agent:基于ontology的Web代理，关于ontology使用参考ontology作为知识源进行一定约束条件的重新知识获取。

②Chemical OntoAgent:基于ontology的Web化学教育代理，允许学生进行化学学习，并在此基础上自测在该领域的水平。

③Ontogeneration:使用领域本体(化学家)和语言本体来产生西班牙文本描述，来作为对学生关于化学领域问题查询的回答。

2.4.2.5　KACTUS工程法

KACTUS工程法是基于欧洲的KACTUS项目而产生的，它是欧洲ESPRIT框架下的研发项目之一。KACTUS是“关于多用途复杂技术系统的知识建模”(Modeling Knowledge About Complex Technical Systems for Multiple Use)工程英文的缩写。该项目的目的是开发出技术系统全生命周期的知识重用方法学，以便在设计、诊断、操作、维护、再设计和培训时使用同一知识库。

这种方法开发本体由应用开发控制。所以每一个应用都有相应的表示该应用所需的ontology。这些本体既能重用其他的ontology，也能被后继应用集成，应用于电子网络的开发。具体的开发过程如下:

①应用说明。提供应用的上下文和应用模型所需的组件。

②相关本体范畴的初步设计。搜索已存在的本体，进行提炼、扩充。

③本体的构造。用最小关联原则来确保模型既相互依赖，又尽可能一致，以达到最大限度的系统同构。

KACTUS是ESPRIT的项目，支持EXPRESS和Ontolingua，目的是关于技术系统生命周期过程中的知识重用，用CML语言描述，CML是KADS工程语言，非形式化的，不能被程序执行。

2.4.2.6　SENSUS方法

SENSUS法是由美国USC/ISI研制开发的用于自然语言处理的SENSUS语言本体的方法。ISI自然语言研究小组旨在为机器翻译提供广泛的概念结构。SENSUS为机器翻译提供概念结构，用该方法开发的SENSUS本体系统用于自然语言处理程序。目前SENSUS语言本体共包括电子科学领域的7万多个概念。为了能在SENSUS基础上构造特定领域的本体，必须把不相关的术语从中剪除。SENSUS本体的构造流程如下:

①定义“叶子”术语(暂时还不属于SENSUS的术语)。

②用手工方法把叶子术语和SENSUS术语相连。

③找出叶子节点到SENSUS根节点的“路径”。

④增加和SENSUS本体中的域相关但是还未出现在SENSUS本体中的概念。

⑤用启发式思维找出全部特定域的术语:某些有两条以上的路径经过的节点必是一棵子树的父节点，那么这棵子树上的所有节点都和该域相关，是要增加的术语。对于高层节点则通常有多条路径经过。

具体流程图如图2-8所示。

现在，使用SENSUS法所构建的本体包括武器、原油、飞机等用于军事领域的本体。

2.4.2.7　IDEF5法

IDEF5(Integration Definition for Function Modeling)是由美国KBSI公司(Knowledge Based Systems Inc.)开发，主要用于描述和获取企业本体的方法，英文名为“IDEF5 Ontology Description Capture Method”。它是由KBSI开发的一系列“面向功能建模的集成定义”项目。该系列项目已由最初的IDEF0发展到如今的IDEF9，建模技术也由传统的面向对象技术发展到现今的构建技术及形式化语言描述。IDEF5通过使用图表语言(IDEF5 schematic language)和细节说明语言(IDEF5 elaboration language)，获取关于客观存在的概念属性和关系，并将它们形式化，作为本体的主要架构。

图2-8　SENSUS术语构造

IDEF5图表语言是一种图形化的语言，旨在能够使学科领域专家可以表达基于本体的最为通用的信息。IDEF5细节说明语言是一种结构化的文本语言，用来详细描述本体中的元素。IDEF5提出的本体建设方法包括以下五个步骤:

①组织和范围。确定本体建设项目的目标、观点和语境，并为组员分配角色。

②数据收集。收集本体建设需要的原始数据。

③数据分析。分析数据，为抽取本体做准备。

④初始化的本体建立。从收集的数据当中建立一个初步的本体。

⑤本体的精练与确认。完成本体建设过程。

在本体的构建过程中，研究人员首先对叙词集合进行编目，以此为基础建立领域模型。这一模型中的概念是用叙词集合中的叙词来进行表示的。为了完成本体的构建，需要做以下三个工作:一是对术语进行编目。二是获取用这些术语描述这一领域时的限制条件。三是建立一个模型，当在模型中加入一条特定的描述时，就会产生“适当的”附加描述声明。

KBSL的研究人员认为:任何领域的本质特征都可以通过3个元素得到提示。

①包含在特定领域里的特征对象和过程的词表;

②词表中基本术语的严格定义;

③术语间逻辑联系的特征表示。

本体是关于特定领域的一套完整的精确定义、规则和术语含义约束的词表，保证了知识复用的一致性，利用这种技术，领域专家可以有效开发和维护领域本体。IDEF5构建本体的方法在于获取现实世界客观对象的断言，以及它们的属性和它们之间的内在联系。

2.4.3　本体构建的工具

目前，网上可以找到的本体构建工具多达60多种，但很多并不属于完全意义上的本体构建工具，有些属于本体标引工具，有些属于本体评价工具，也有些属于本体合并和集成工具等。其中比较常用、发展成熟、知名度较高的工具只有10种左右，如DAMLImp(API)、KAON(包括OIModeller)、Ontolingua with Chimaera、OntoEdit、OilEd、Ontosaurus、OpenCyc Knowledge Server(简称Cyc)、Protégé2000、WebODE及WebOnto等。下面重点介绍其中的7种。

2.4.3.1　Protégé2000

Protégé2000是由斯坦福大学医学院的医学情报学研究小组(Stanford Medical Informatics，SM I)开发的一个开放源码的本体编辑器，它是用Java编写的。Protégé2000界面风格与普通Windows应用程序风格一致，用户比较容易学习使用。本体结构以树形的层次目录结构显示，用户可以通过点击相应的项目来增加或编辑类、子类、属性、实例等，使用户在概念层次上设计领域模型，所以本体工程师不需要了解具体的本体表示语言。

Protégé2000支持多重继承，对新数据进行一致性检查，并且具有很强的可扩展性，主要表现在如下几点:①Protégé2000是一个可扩展的知识模型。用户可以重新定义系统使用的表示原语。②文件输出格式可以定制。可以将Protégé2000的内部表示转换成多种形式的文本表示格式，包括XML、RDF(S)、OIL、DAML、DAML+OIL、OWL等系列语言。③用户接口可以定制。提供可扩展的API接口，用户可以更换Protégé2000的用户接口的显示和数据获取模块来适应新的语言。④有可以与其他应用结合的可扩展的体系结构。用户可以将其与外部语义模块(例如针对新语言的推理引擎)直接相连。⑤后台支持数据库存储，使用JDBC和JDBCODBC桥访问数据库。

与其他系统，Protégé2000的优势主要表现在:①具有图形化的用户界面;②对Unicode字符集输入的支持;③可以免费下载系统安装软件和插件;④支持DAML+ OIL和OWL，能够用RDF、RDFS、OWL等本体语言在系统外对本体进行编辑和修改。

由于Protégé2000开放源代码提供了本体建设的基本功能，使用简单方便，有详细友好的帮助文档，模块划分清晰，提供完全的API接口，因此，它已成为国内外众多本体研究机构的首选工具。但是，它基本上没有提供合作开发方面的支持，在实际应用中存在很多限制。

2.4.3.2　Ontolingua With Chimaera

Ontolingua是斯坦福大学知识系统实验室(KSL)开发的一个本体开发环境。它包括一个服务器和一个表示语言，服务器位于斯坦福大学。主要特点如下:

①使用Ontolingua语言的扩展版本作为半形式化的表示语言。

②使用满足面向对象的框架视图表示和浏览知识。浏览器使用超链接，使得用户的浏览可以方便、快速地从一个术语跳到另一个。用户还可以看到信息是如何推导的。Ontolingua使用类/子类的方式展现类层次。

③将Ontolingua语言进行扩展，使用户能迅速地从模块库中组合新本体。Ontolingua服务器允许用户通过包含、多态表示和限制的方式，重用模块的结构库中的已有本体。为了方便对已有本体的重用，Ontolingua服务器提供了将一个本体包含到另一个本体的方法。每个本体可以看作一个词汇集和公理集由于本体包含的结果是产生一个公理集的并集，因此不存在环包含。Ontolingua服务器既允许用户显式地表示本体之间的包含关系，也允许用户使用公理之间的参考隐式地创建包含关系。

④为用户提供三种与Ontolingua服务器交互的主要模式。第一，分布在远方的人们使用Web浏览器浏览、构建和维护存储于服务器的本体，服务器允许多个用户在共享的会话上并发地处理一个本体;第二，远程应用可以通过Internet查询、修改服务器上的本体，它使用扩展Generic Frame Protocol的网络API;第三，用户可以将本体转变为特定应用使用的格式。

⑤能够转换为其他语言(如IDL、Prolog、CLIPS、LOOM、Epikit、KIF)。

⑥支持合作开发本体。Ontolingua支持对本体的维护、共享、合作开发，而且Ontolingua满足易用性。用户通过比较两个本体，并观察从一个本体转变为另一个本体的动作集合，可以方便地监视本体的变化。通过检查槽、槽值、面、面值，确保它们满足已知的限制的方法，用户可以分析本体的一致性。服务器也提供了将大本体分解为几个小本体的方法。Ontolingua通过用户和组的访问控制，以及多用户的会话，提供合作开发机制。

⑦在Ontolingua中可以实现上下文敏感的搜索，术语的限制被用来限制搜索的结果。当前Ontolingua并不提供太多的推理能力。

Ontolingua是一个功能非常强大的本体开发环境，特别是它对本体的维护、共享、合作开发等环节的支持程度。

2.4.3.3　OntoEdit

OntoEdit是由卡尔斯鲁厄大学开发的，是分层构建本体系统工程的工作平台，它使用图形方法支持本体的开发和维护，将本体开发方法论(骨架法)与合作开发和推理的能力相结合，关注本体开发的三个步骤:收集需求阶段、提炼阶段、评估阶段。

开发OntoEdit所用的软件包是Java standalone application。OntoEdit支持推理的多重继承性系统的基本公理有不相交的概念(Disjoint Concepts)、对称性关系(Symmetric Relations)和传递性关系(Transactive Relations)。输入输出格式支持RDF(S)、DAML+OIL和FLogic，提供对于本体的并发操作。

OntoEdit构建在一个强大的内部本体模式之上，该模式可以通过XML的利用得到串行化，XML支持内部文档的处理。OntoEdit词形变化表尽可能地支持不依赖面向概念、关系和表达语言的建模。包含在本体中的几种图形视窗支持本体工程周期的几个不同的建模。OntoEdit的工作平台直接提供的工作插件包括:①概念和关系(Concepts and Relations);②实例(Instances);③互不相交的概念(Disjoint Concepts);④可视化显示(Visualizer);⑤认证(Identification);⑥元数据(Metadata)。

除此之外，OntoEdit还在其网站上提供输入输出插件，支持各种数据类型的插件，包含概念列表型(Concept List)、关系列表型(Relation List)、文档数据型(File List)、字符数据型(String List)、布尔数据型(Boolean Data)、数值数据型(Number Data)和整型数据型(Interger Data)等各种数据类型。

OntoEdit还提供了安装在界面面板上的工具插件，给用户提供了更多的便捷。这些插件包括图形规划插件(Graph Layout)、概念关系拆分插件(Concept Relation Split)、实例编辑器插件(Instance Editor)、本体属性插件(ontology Editor)以及统计插件(Statistics)。除此之外，还有数据模型插件，如本体高速缓冲存储器(Cached ontology)以及本体框架面板集成器(ontology Frame Panel Container)等。

OntoEdit的另一大特色是它的可视化显示插件(Visualizer)，它拥有多变的形式，能够按照用户的要求显示某几个概念某几个实例间的关系，而且概念间关系的表示简洁明了，通俗易懂。

目前OntoEdit已经产品化，不开放源代码，它可以作为KAON(Karlsruhe Ontology and Sematic Web Tool)的客户端软件。KAON是OntoEdit的后继版本。

2.4.3.4　Oi l Ed

OilEd是一个由曼彻斯特大学计算机科学系信息管理组构建的基于OIL的本体编辑工具，它允许用户使用DAML+ OIL构建本体。它的基本设计受到类似工具(如Protégé系列、OntoEdit)的很大影响。它的新颖之处在于对框架编辑器范例进行扩展，使之能处理表达能力强的语言;使用优化的描述逻辑推理引擎，支持可跟踪的推理服务。OilEd作为这些工具的原型测试和描述一些新方法，它不提供合作开发的能力，不支持大规模本体的开发，不支持本体的移植和合并、本体的版本控制，以及本体建设中本体工程师之间的讨论。OilEd中的中心组件是描述框架，它由父类的集合组成。OilEd描述框架与其他框架不同之处在于它允许使用匿名框架描述和高复杂性。OilEd提供源代码。

OilEd能使用推理检查类的一致性，推断出包含的关系。推理服务由FacT提供，FacT为两类描述逻辑SHF和SH IQ提供推理服务。FacT/OilEd并不为它的推理提供解释。OilEd也可以将本体导出为其他格式，如Simple RDFS、SH IQ、SHOQ(D)、HTML、DOTTY、DIG和图形格式。

2.4.3.5　Ontosaurus

OntoSaurus是南加州大学为Loom知识库开发的一个Web浏览工具，提供了一个与Loom知识库链接的图形接口。OntoSaurus同时提供了一些对Loom知识库的编辑功能，然而，它的主要功能是浏览本体。由于OntoSaurus使用Loom语言，它具有Loom语言提供的全部功能，例如支持自动的一致性检查、演绎推理，也支持多重继承。OntoSaurus目前只支持对KIF、OKBC语言的导入/导出。

OntoSaurus支持两种模式:一种模式是本体浏览模式，另一种是本体编辑模式。当一个用户进入编辑模式后，将阻塞其他希望进入本体编辑模式的用户，这样就允许多个用户同步对一个本体进行操作。但是用户很难辨认其他用户对本体做出的修改。如果要创建一个本体，特别是比较复杂的本体，那么用户就需要对Loom语言有一定的了解。对于一个新的用户，使用OntoSaurus编辑本体不是很方便。

Ontosaurus作为本体服务器主要有三个特点:①知识表示语言是以DL的Loom为基础;②推理能力主要依赖于Loom的推理功能;③其顶级本体使用了SENSUS。

虽然，Ontosaurus的开发受到Ontolingua的启示，但它们的开发方式存在明显的不同。Ontolingua的本体开发方式采用自底向上的方式，先建立许多范围小、内容丰富的本体，然后将这些小本体合并起来，生成更大的本体，逐步迭代。而OntoSaurus的本体开发方式则是自顶向下的。它先建立一个大的、通用的本体结构框架，然后逐步往这个框架添加领域知识，形成内容丰富的本体。

2.4.3.6　WebOnto

WebOnto是英国Open University的知识媒体研究所于1997年开发的。该项目的目的是开发一个基于Web的本体编辑器，它能提供比Ontolingua更为复杂的浏览、可视化和编辑能力。WebOnto是基于OCML的知识模型，提供多重继承、锁机制，支持用户合作地浏览、创建和编辑本体。WebOnto没有提供源代码。

Ontolingua、Ontosaurus等系统使用浏览器作为客户端接口，这样会导致三个问题。①数据的集中存放。由于所有数据集中存放于中央数据库，这样中间的用户修改就会被覆盖，而且无法提供迅速反馈的接口。②一次性连接。服务器仅仅对网页请求做出回应，这意味接口仅能对用户动作做出反应，因此本体建设工具无法包含异步通信(如周期地提醒存储数据)，也就是用户必须记住以前的页面。③浏览器展现的呆板。浏览器对于图形接口的支持是有限的。而WebOnto可以解决这些问题。WebOnto由一个中央服务器和Java编写的客户端组成。它包括一个图形用户接口和用于存放细节数据的检查窗口。WebOnto提供大量定制信息表示类型的选项。最后它提供一个客户端的API，用于从WebOnto的本体检索信息，以及运行WebOnto建成的应用。

与Ontolingua服务器一样，在使用WebOnto前必须注册成为其用户。在获取了系统维护人员发送的用户名和密码之后，用户才能够使用它的网络版工具，而不能下载到本地使用。

2.4.3. 7　WebODE

WebODE是马德里技术大学开发的一个本体建模工具，它支持本体开发过程中的大多数行为，并且能够支持METHON-TOLOGY本体构建方法论，目前只有WebODE和OntoEdit两个工具能够将本体构建方法与实际的本体构建环境对应。WebODE没有提供开放的源码，只能通过网络注册的方式进行使用，它是ODE(Ontology Design Environment)的一个网络升级版本，并提供了一些新的特性。

WebODE是通过Java、RM I、COBRA、XML等技术实现的，提供了很大的灵活性和可扩展性，可以方便地整合其他的应用服务。WebODE体系结构分为三层:第一层提供了用户接口。这个接口是通过使用Internet Explorer或Netscape等Web浏览器提供的，使用HTML或XML与其他应用进行交互。第二层提供了业务逻辑，包括两个子层:逻辑子层——通过Minerva Application Server使用一组定义好API来对本体进行直接访问;表示子层——生成需要在用户浏览器上显示的内容，并且处理客户端用户的请求。第三层是数据层，本体存储在关系数据库(Oracle)中，通过JDBC访问。

WebODE和Protégé2000一样，不需要使用具体的本体表示语言，而是在概念层构建本体，然后才将其转化成不同的本体表示语言。目前，WebODE支持的本体表示语言有XML、RDF(S)、DAML+OIL、OWL、X-CRAIN、FLogic。

WebODE通过定义实例集来提高概念模型的可重用性。这个特性使得不同用户可以使用不同方法对同一个概念模型进行实例化，每个用户使用自己的实例集，使得应用间的交互性得到提高。并且，WebODE对同一个概念模型可以提供不同的概念视图。同时，WebODE允许用户创建对本体的访问类型，使用组的概念，用户可以编辑或浏览一个本体，并且提供了同步机制来保证多个用户无差错地编辑同一个本体。

WebODE支持多重继承、支持类型一致性、数值一致性、集合一致性检查，并且提供了分类一致性验证机制。另外，虽然WebODE不遵循OKBC标准，但是在它的推理引擎中定义了所有的OKBC原语。