本体与数据库

‘壹’ “本体”的定义是什么

一、 本体的概念

本体（Ontology ）的概念最初起源于哲学领域，可以追溯到公元前古希腊哲学家亚里士多德（384-322 b.c.）。它在哲学中的定义为“对世界上客观存在物的系统地描述，即存在论”，是客观存在的一个系统的解释或说明，关心的是客观现实的抽象本质。

在人工智能界，最早给出Ontology定义的是Neches等人，他们将Ontology定义为“给出构成相关领域词汇的基本术语和关系，以及利用这些术语和关系构成的规定这些词汇外延的规则的定义”。Neches认为：“本体定义了组成主题领域的词汇表的基本术语及其关系，以及结合这些术语和关系来定义词汇表外延的规则。”（“An ontology defines the basic terms and relations comprising the vocabulary of a topic area, as well as the rules for combining terms and relations to define extensions to the vocabulary.”）。后来在信息系统、知识系统等领域，越来越多的人研究Ontology，并给出了许多不同的定义。其中最着名并被引用得最为广泛的定义是由Gruber提出的，“本体是概念化的明确的规范说明”，原文参见：

"An ontology is an explicit specification of a conceptualization. The term is borrowed from philosophy, where an Ontology is a systematic account of Existence. For AI systems, what "exists" is that which can be represented. When the knowledge of a domain is represented in a declarative formalism, the set of objects that can be represented is called the universe of discourse. This set of objects, and the describable relationships among them, are reflected in the representational vocabulary with which a knowledge-based program represents knowledge. Thus, in the context of AI, we can describe the ontology of a program by defining a set of representational terms. In such an ontology, definitions associate the names of entities in the universe of discourse (e.g., classes, relations, functions, or other objects) with human-readable text describing what the names mean, and formal axioms that constrain the interpretation and well-formed use of these terms. Formally, an ontology is the statement of a logical theory."。

和这个定义类似的有N. Guarino and P. Giaretta (1995)“本体是概念化的明确的部分的说明/一种逻辑语言的模型”（“an ontology is an explicit, partial account of a conceptualization/ the intended models of a logical language.”）。

W. N. Borst对该定义也进行了引申“本体是共享的概念模型的形式化的规范说明”（“An ontology is a formal specification of a shared conceptualization”）

Fensel对这个定义进行分析后认为Ontology的概念包括四个主要方面：

1. 概念化（conceptualization）：客观世界的现象的抽象模型；

2. 明确（explicit）：概念及它们之间联系都被精确定义；

3. 形式化（formal）：精确的数学描述；

4. 共享（share）：本体中反映的知识是其使用者共同认可的。

原文：“an abstract model of a phenomenon termed ‘conceptualization’,a precise mathematical description hints the word ‘formal’, the precision of concepts and their relationships clearly defined are expressed by the term ’explicit’ and the existence of an agreement between ontology users is hinted by the term ‘shared’.”

Swartout将本体定义为：“本体是一个为描述某个领域而按继承关系组织起来作为一个知识库的骨架的一系列术语”。（“An ontology is a hierarchically structured set of terms for describing a domain that can be used as a skeletal foundation for a knowledge base.”）。他的定义强调了本体中术语（terms）的重要性。

Fensel定义“本体是对一个特定领域中重要概念的共享的形式化的描述”。（“An ontology is a common, shared and formal description of important concepts in an specific domain.”）。

Noy F.N. 认为“本体是对某个领域中的概念的形式化的明确的表示，每个概念的特性描述了概念的各个方面及其约束的特征和属性。”（“An ontology is a formal explicit representation of concepts in a domain, properties of each concept describes characteristics and attributes of the concept known as slots and constrains on these slots.”）。

Fonseca定义“本体是以某一观点用详细明确的词汇表描述实体、概念、特性和相关功能的理论”。（“An ontology is a theory which uses a specific vocabulary to describe entities, classes, properties and related function with certain point of view.”）。

Starla认为“本体必需包括所使用术语的规范说明、决定这些术语含义的协议、以及术语之间的联系，来表达概念”。（“An ontology necessarily includes a specification of the terms used (terminology) and agreements that allow to determine their meaning, along with the possible inter-relationships between these terms, standing for "concepts".”）。

M. Uschold and M. Gruninger认为“”（“Ontology is an explicit account or representation of (some part of) a conceptualisation.”）。他还推荐了一个来自SRKB（Shared Re-usable Knowledge Bases）电子邮件列表的定义“本体是关于共享的概念模型的协议。共享的概念模型包括进行领域知识建模的概念框架、互操作的agent之间进行交流的内容明确协议、以及表达特定领域理论的协定。在知识共享的上下文环境中，本体特指表达性词汇表的定义的形式。一个非常简单的例子就是分类的层次结构，指明了类和它们之间的包含关系。关系数据库模式的作用也和本体一样，它指定了某些共享数据库之间可以存在的关系以及必须保持的完整性约束”（“Ontologies are agreements about shared conceptualization. Shared conceptualizations include conceptual frameworks for modeling domain knowledge; content-specific protocols for communication among inter-operating agents; and agreements about the representation of particular domain theories. In the knowledge sharing context, ontologies are specified in the form of definitions of representational vocabulary. A very simple case would be a type hierarchy, specifying classes and their subsumption relationships. Relational database shemata also serve as ontologies by specifying the relations that can exist in some shared database and the integrity constraints that must hold for them.”）。

‘贰’ 数据库和本体构建的区别

数据库和本体构建的区别：
1、数据库按照数据结构来组织、存储和管理数据的仓库。
2、数据结构：是计算机存储、组织数据的方式。

‘叁’ 语义信息的存储

无论是知识库还是服务的语义描述都需要具有良好的组织和存储，以支持高效推理和服务检索发现。目前对于本体的存储方法基本有三种(李勇等，2008):

(1)纯文本，如 OWL 文件。由于 XML 的信息组织和存储方式结构复杂，而且存在冗余等，基于其上的查询检索效率通常会比较低。纯文本的方式适合本体比较小的时候，不适合本体大规模应用的情况。

(2)数据库: 是一种比较好的持久化存储方式，最大好处是便于查找，可存放大本体，查询效率高，特别在 I/O 效率上。但是数据库方式存在本体查询语言到 sql 的转换问题，需要借助于第三方中间件或自定义实现。

(3)专门的管理工具: 比如说 OMM(Ontology Middleware Mole)支持对 RDF、OWL 的存储管理，还提供各种接口，可以使用查询语言对 RDF 或者 OWL 进行查询。综合对比这三种本体存储方式，由于关系数据库存储几十年的技术积累，以及它的海量存储特点而成为了许多研究者的首选。

5.4.3.1 本体的关系数据库存储模式

由于本体模型和关系模型的差异，目前存在多种在关系模型中存储本体的方法，其主要可以分为以下四类(陶皖等，2007; 陈光仪，2009)。

5.4.3.1.1 水平模式

该模式只在数据库中保留一张通用表，表中列为本体中的属性。整个本体库中定义了多少个属性，这张表就有多少个列，具体如图 5.28 所示。本体中的每个实例对应该表中的一条记录。这种存储模式结构简单，执行查询操作比较方便。但是该通用表包含了大量的列，而现有的数据库系统对一张表中列的个数都是有限制的，所以该模式无法存储规模较大的本体。而且表中的数据过于稀疏。由于每个实例对应关系表中的一行，如果其在某些属性列上没有值，那么必须将对应的属性值设置为空，这将导致大量空字段的出现，不仅浪费存储空间，而且增加了索引维护的代价。另外该通用表中一个实例的属性和属性值只能是一对一，而实际情况往往是一对多，因此无法存储具有这种特征的本体。随着应用中本体的进化，还需要时常更新通用表中的列，重新组织表结构，这将耗费极大的系统代价。

图 5.28 水平存储模式

5.4.3.1.2 垂直模式

垂直模式包含一张三元组表，表中的每条记录都对应一个 RDF 三元组(主语，谓词，宾语)，具体如图 5.29 所示。因此这种模式下，需要将本体中的所有信息都以 RDF 三元组的形式表示出来。Protege(2002)中便是使用了这种存储模式将本体存储于数据库中。这种模式设计简单，并且结构稳定。如果本体进行了更新，只需修改表中相应的元组即可。另外，该模式通用性好，因为现有的本体模型都可以转换为 RDF 模型表示。但是这种模式的可读性较差，若对本体信息进行查询，那么设计对应的 SQL 语句比较麻烦。除此之外，由于所有信息都存放在三元组表中，导致任何一个本体信息查询都必须遍历整个数据表，特别是那些需要进行表连接的查询，使得查询效率非常低，这是这种模式最大的不足之处。

图 5.29 垂直存储模式

5.4.3.1.3 分解模式

该模式与水平模式和垂直模式的一个显着的区别是它使用了若干张表，其基本思想是将数据库进行模式分解。根据分解的对象不同，现有的采用分解模式的方法有两种。①基于类的分解模式，即为本体中的每个类都创建一张单独的表，表名为类名，表的列为类的属性，具体如图 5.30 所示。这种模式结构清晰，但是很难适应本体动态变化的情况，因为随着本体中类或者属性的变化，表结构都要随着变化。②基于属性的分解模式，即为本体中的每个属性创建一张单独的表，表名为属性名，每个表都包含两个列，分别代表RDF 三元组中的主语和宾语，具体如图 5.31 所示。在该模式中对类的隐含实例的查询代价很大，而且在现有的这两种分解模式的方法中，随着本体的变化都要不断的创建和删除表，而在数据库系统中创建和删除表的效率很低。

图 5.30 按类分解模式

图 5.31 按属性分解模式

5.4.3.1.4 混合模式

该模式通常将上述几种模式进行混合使用。例如，Pan 等(2003)提出这样一种将基于类的分解模式与基于属性的分解模式混合的存储模式，即在本体中定义一个类就为该类创建一个表(创建方法类似于基于类的分解模式)，在本体中定义一个属性就为该属性创建一个表(创建方法类似于基于属性的分解模式)。然而，与基于类的分解模式不同的是，该混合模式在类对应的表中不记录相应实例的所有信息，而只记录实例的 ID。实例在各个属性上的取值则分别记录在各属性对应的表中，所以和基于属性的分解模式类似，该模式在属性对应的表中仍然需要两列: 主语和宾语。对于本体类数目不多的情况下，这种模式在简单检索的情况下，运行得很好。但是，如果本体的类比较多，这种方式就会存在一些问题，例如: 数据库无法容纳这么多表，或者效率低下。

针对上述四种模式，陈光仪(2009)从四个方面对适用场合、查询和更新效率、结构清晰以及易理解性、可扩展性四个方面对他们进行了综合对比(表 5.4):

表 5.4 不同存储模式的综合对比

(修改自陈光仪，2009)

通过上述对本体存储模式的阐述及之间的综合对比发现，本体存储模式除了应该具有尽量高的规范化程度(例如满足第三范式或 BCNF 范围等)，还应该满足以下三个原则。

(1)模式结构易于理解。该原则是为了便于本体查询的实现。如果模式结构不直观，会给查询语句的设计带来困难。例如，垂直模式不满足该要求，它将所有的信息都采用三元组的形式存储在一张表中，不容易理解表中元组的含义，加重了本体查询设计的负担。

(2)模式结构稳定。即本体的变化不会引起数据库表结构的变化。因为本体是不断进化的，如果设计的模式结构会随着本体的变化而变化，数据库系统对其维护代价太大。现有的水平模式、分解模式和混合模式都不满足该要求。

(3)查询效率高。该原则是评价各种存储模式的一个重要指标。因为本体中不仅包含大量的数据，而且查询中还经常需要进行表连接。例如在现有的垂直模式和基于属性的分解模式中，那些涉及表连接的查询效率非常低。

目前在基于数据库的本体存储的实践上，一些学者开展了相关的研究工作:

燕云鹏(2007)和陈光仪(2009)提出了类似的针对于针对 OWL 的本体数据库的混合本体存储模式(图 5.32，5.33)。可以看出这种模式是以基于属性的分解模式与垂直模式的混合体，具有较好的扩展性。但是存在的问题是效率不够高，所有的类存储在一个表中，所有的实例也存储在一个表中，这种方式的检索效率比较低。另外存储实例的表(Instance，Proterty，Value)中字段 Value 必须存储许多种不同类型的数值，比如有的是文本型，而有的却是数值型，使得数据不够清晰。此外，在针对几何体这种复杂的地理对象，这种字段就比较难以存储。

图 5.32 本体的数据库混合存储模式(据燕云鹏，2007)

ebRIM(ebXML Registry Information Model)是一个主流的信息注册模型，已成为事实上的标准，得到了 OGC 等支持。OGC 已经实现了基于 ebRIM 的目录服务，并推荐其作为目录服务的实现规范。但是目前基于 ebRIM 的目录服务只支持普通的基于关键字的检索。为此，一些学者已经开始研究如何扩展 ebRIM 实现对语义信息特别是 OWL 的注册。Dogac 等(2004)提出了如图 5.34 所示的一种通过将 XML 形式存储的 OWL 文件转换为以数据库形式存储，使得查询检索更加快速，管理维护也更加方便。为了能在 ebRIM 存储复杂的地理空间信息对象，一些学者开展了基于 ebRIM 的地理扩展方面的研究工作。乐鹏(2007)在其论文中提出了两种扩展方式: ① 从类 “ExtrinsicObject” 派生了“CSWExtrinsicObject”来描述那些不是 ebRIM 自身定义的元数据对象。比如类 “Dataset”继承了 “CSWExtrinsicObject”来描述空间数据集。②对 ebRIM 已有的类别增加 “Slot”。每一个从 “RegistryObject”继承下来的类均允许添加 “Slot”。ebRIM 中的 “Service”类可以用来描述空间服务，但是已有的属性不足以描述空间网络服务。因此，通过添加“Slot”到 “Service”类中以定义从 ISO 19119 派生的属性。如图 5.35 所示为经扩展后的ebRIM 高层模型图，其中 灰 色 填 充 的 矩 形 框表示 扩 展 的对 象 类。该 模 式 与 前 面 燕 云 鹏(2007)和陈光仪(2009)提出的模式相比，本质上差别不大，也是以基于属性的分解模式与垂直模式的混合体，只不过是基于标准的 ebRIM 注册模型，并且将其中的分类系统相关的类单独以两张表存储。该模式也具有很好的扩展性，也存在同样的一些问题。

图 5.33 本体的数据库混合存储模式(据陈光仪，2009)

海洋信息网格技术与应用

续表

5.34 OWL 元素到 ebRIM 元素的映射(Dogac et al.，2004)

5.4.3.2 基于多分解策略的混合存储模式实现

对知识库以及服务语义注册信息的存储的实现上，本书在现有的研究成果的基础上，结合本体组织构成及特点等实际需求，提出了一种基于多分解策略的混合关系数据库存储模式。

该方法的指导思想是: 先按类对其中的数据专题、数据模式、处理模型等进行类的分解，然后结合属性的特性进行基于属性的分解。其中基于类的分解中，可能粒度的大小不一，可能是一个类或者具有相关或相似的一些类划分为一张表存储; 而基于属性的剖分，也并不是所有具有该属性的类以一个表存储，而可能是只针对一个类也单独组织为一张表，其具体思路如下:

图 5.35 经扩展的 ebRIM 高层模型图(据乐鹏，2007)

(1)类的分解: 因为本研究的存储模型不是为了实现一个通用的本体存储模型，而是为了实现一个服务于海洋信息服务领域的本体存储模型。海洋信息服务领域必然会牵涉到一些对象，比如对服务、模型、参数等对象，并且对这些对象的认识也基本上确定(也就是说这些对象类所具有的属性及之间的关系基本明确)，所以没必要像上面几种实现方案那样因为不能预知都有哪些类，各类都有哪些属性而将所有的实例的组织按垂直方式进行存储，也没有必要有一些表(比如独立的属性表，属性的作用域和值域表等); 而有必要针对海洋信息服务领域内的这些类的信息内容独立出一些表: 对于海洋专题，地理名实体、处理模型、数据模式等海洋信息检索发现中常用的对象，则有必要进行分开存储，否则必然使得结构不清晰，且检索查询效率低。

(2)对于专题、空间形态以及模型功效等只是简单的分类系统，所具有的属性少，而且今后存在派生新的种类的可能，因此必须具备一定的扩展性。针对这类数据。它们的存储方式是(ClassID，ParentClassID，ClassType)，其中 ClassType 标注本体类是属于专题(比如 “海流”)或者其他。

(3)对于取值不唯一的属性，且大部分类或实例都具有的属性，则采用基于属性的分解模式。比如对于别名属性(hasAliasName)，有可能一个类实例具有多个别名，这种情况下，则采取基于属性的组织方式。该表的形式是:(OntologyID，AliasName)，其中OntologyID 可以是本体类的 ID，也可以是本体实例的 ID，还可以是本体属性的 ID，因为类、实例和属性都可以有别名。

(4)对于复杂的属性，采取大二进制存储的方式。比如对于地名实例的空间覆盖范围，则不考虑其实际内部是包含多少个组成部分，统一按一个 shape 存储在数据库中。当然这里借助了 ArcGIS 的 GDB 的 FeatureClass 矢量数据模型，并对于不同空间形态的则采用了多张表(点状地名类、线状地名类、面状地名类)，其组织方式是(GeoNameObjec-tID，shape)。同样，对于模型本体中的内部流程本体，也采用了大二进制方式存储，将整个流程 XML 描述文件，作为一个整体存放于字段中，其大体组织方式为(ModelID，FlowXML)。

(5)本研究采用 ArcGIS 的 GeoDatabase 作为存储模型。本体类(ontClass)的存储结构如图 5.36 所示，数据库的总体组织结构如图 5.37 所示。

图 5.36 本体类(onClass)的存储结构

‘肆’ 用xml或什么数据库来实现本体描述，描述后怎样实现了语义检索

软件复用是近年来国内外软件界研究的热点之一,它能大幅度提高软件质量和生产率,降低软件丌发和维护的成本。基于构件的软件开发(CBSD)是软件复用的一种有效形式。而有效的构件描述和检索方法是实现软件复用的一项关键技术。现有的构件描述和检索技术大多没考虑语义描述能力,其查全率和查准率往往无法令人满意,不能很好地实现软件复用的目的。 针对上述问题,通过引入本体来弥补现有构件描述和检索技术中的语义缺失的方法已成为新的研究热点。本文分析了基于刻面的构件描述和检索方法,将其与本体技术相结合,提出以功能刻面为基础建立构件本体的方法,并在此基础上研究了本体对构件检索的语义支持,提出了相应的检索改进方案。 本文的工作主要有以下几个方面: 1、研究现有构件的刻面分类,分析不同刻面特征以及它们在描述和检索中的贡献,重点研究了功能刻面下的术语特征和它们之间语义依赖关系,将其归纳为功能依赖、数据依赖、控制依赖和通讯依赖关系,作为通用的功能语义关系;同时研究了构件间的非功能关系将其归纳为相似关系和层次关系,作为通用的构件语义关系;将上述关系间的关联提炼成规则,作为构件语义推理的基础。 2、研究本体建立方法,提出利用构件的功能刻面来建立构件本体模型的方法,将刻面术语映射成本体中的概念,利用功能依赖、数据依赖、控制依赖和通讯依赖关系等功能语义关系来描述概念间的关系,给出基于功能语义的构件本体的形式化描述,并以信用构件库系统中的功能刻面为例,给出一个本体建立的实例。 3、在构件本体描述基础上,本文给出综合概念距离、重合度和层次差的概念语义相似度计算方法,并结合构件属性相似度给出构件语义相似度计算方法。在概念间和构件间的语义关系基础上,给出概念的语义相关度计算方法和构件的语义相关度计算方法。 4、最后用上述技术对基于刻面描述和检索的信用构件库进行改造,通过整合语义相似度和相关度实现语义查询扩展、语义推理和语义推荐,为构件检索提供语义支持。

‘伍’ 一文极速读懂 Gene Ontology （GO）数据库

官方：基因本体（GO）知识库是有关基因功能的全球最大信息来源。 这些知识既是人类可读的，也是机器可读的，并且是生物医学研究中大规模分子生物学和遗传学实验的计算分析的基础。

在读懂基因本体论（Gene Ontology）前，我们先看看什么是本体论：

本体论（Ontology ）是探究世界的本原或基质的哲学理论 。

本体论通常处理的问题：存在哪些本质，如何将这些本质分组，在层次结构内关联以及如何根据相似性和差异进行细分 。

基因本体论（Gene Ontology）包含生物学领域知识体系本质的表示形式，本体通常由一组类（或术语或概念）组成，它们之间具有关系。 基因本体论（GO）从三个方面（GO domains）描述了我们对生物学领域的了解：

理解了上述的概念，现在举个例子，如果站在基因本体论GO的角度来解释一个基因的话：

基因产物：细胞色素C（cytochrome c）

分子功能：氧化还原酶活性

细胞组分：线粒体基质

生物过程：氧化磷酸化

自定义同义词类型也用于本体中。 例如，许多同义词被指定为系统同义词。 此类型的同义词是术语名称的确切同义词。

GO以图的形式构建，术语作为同种的节点，术语间的关系（对象属性）作为连接。

GO图中的节点与其他节点可以具有任意数量和类型的关系， 就像层次结构，例如，家谱或一个物种的分类法

一个节点可能与多个子节点（更特定的节点）具有连接，也可以具有多个父节点（较宽的节点）

利用关系与关系间的连接可以推断相应的分组注释，节点间关系的推断，这个会在后面详细研究：

上图表示：A is a B，B is part of C，所以可以推断 A is part of C

节点间总体与部分关系：

一个节点可能与一个节点有一部分关系。 下图说明了这一点：

上图： mitochondrion 是两个节点的父节点：it is an organelle and it is part of the cytoplasm ； organelle 有两个子节点: mitochondrion is an organelle, and organelle membrane is part of organelle

我们将上面的关系图简化表示为 箭头导向性图 ，这是图中常见的关系表示：

接下我们详细看看GO是怎样来描述这几种关系的：

如果我们说 A is a B ，则意味着节点A是节点B的子类型。例如，有丝分裂细胞周期是细胞周期，或者裂解酶活性是催化活性。

应该注意的是，a并不代表是实例。 从本体论上来说，一个实例是某个事物的具体示例。 例如 猫是哺乳动物，但加菲猫是猫的实例，而不是猫的亚型。 GO中的术语表示实体或现象的类别，而不是特定的表现形式（或实例）。 但是，如果我们知道猫是哺乳动物，则可以说猫的每个实例都是哺乳动物。

使用 is a 对批注进行分组是 安全的 。例如，如果将基因产物X注释为具有酪氨酸激酶活性，并且本体论证明酪氨酸激酶活性是激酶活性的一种（类型），那么我们可以安全地得出结论，基因产物X具有激酶活性。

利用上面得到结论，我们可以将 is a 关系和其他关系类型结合来推断，下图表示了可以推断的关系：

关系的一部分用于表示整个部分的关系。 part of 只有当B一定是A的一部分时，才会在A和B之间部分关系：无论B存在于何处，它都是A的一部分，B的存在意味着A的存在。但是，考虑到A的出现，我们不能肯定地说B的存在。

使用的 part of 进行分组注释是 安全的 。 例如，如果将基因产物X标注为位于线粒体内膜上，而本体论记录了线粒体内膜与线粒体之间的关系的一部分，则可以安全地得出结论X位于线粒体内。

利用上面得到结论，我们可以将 part of 关系和其他关系类型结合来推断，下图表示了可以推断的关系：

has part 是对关系部分的逻辑补充，它从父级的角度代表了“部分-整体”关系。

与 part of 一样，GO关系 has part 仅在A始终将B作为一部分的情况下使用，即A必定具有B的部分。 但是，如果B存在，我们不能肯定地说A存在。 即所有A都有B部分，但是A只是B的一部分。

使用 has part 注释进行分组是 不正确的 。 例如，我们可以在本体论中断言受体酪氨酸激酶活性具有部分激酶活性。 然而，将所有注释归类到受体酪氨酸激酶活性下的激酶活性将是不正确的。

利用上面得到结论，我们可以将 has part 关系和其他关系类型结合来推断，下图表示了可以推断的关系：

一种过程直接影响另一种过程或质量的表现，即前者调节后者。 调节的目标可以是另一种过程，例如调节途径或酶促反应，或者可以是质量，例如细胞大小或pH。 与 part of 关系类似，该关系专门用于表示必定的调节：如果同时存在A和B，则B总是调节A，但是A可能不总是受B调节，即所有B都调节A; 一些A受B调节。

如果将基因产物X注释为参与调节糖酵解的过程，则不能得出结论X参与糖酵解是 不正确的 。 但是，某些工具使用调节关系来对批注进行分组, 这可用于基因集富集, 所得的基因集包括与分组术语有因果关系的过程中涉及的基因。

利用上面得到结论，我们可以将 regulates 关系和其他关系类型结合来推断，下图表示了可以推断的关系：

GO的结构可以用下图来表示，这个图也叫有向无环图（Directed Acyclic Graph ，DAG）。

如上图所示，三个GO域（细胞成分，生物学过程和分子功能）分别由一个单独的根本体术语表示。

一个域中的所有术语都可以将其父源追溯到一个根术语，通过到本体根的中间术语可能存在许多不同的路径。

这三个根节点是不相关的，并且没有公共的父节点，这意味着来自不同本体的术语之间没有任何关系。但是，GO本体之间也存在其他关系，例如，分子功能术语“细胞周期蛋白依赖性蛋白激酶活性”是生物过程“细胞周期”的一部分。GO本体间相关 http://geneontology.org/docs/ontology-relations/ 。

某些基于图的软件可能需要一个根节点。在这种情况下，可以将“假”术语添加为三个现有根节点的代。

GO只代表生物学的当前认知，因此随着生物学知识的积累，它会不断地被修订和扩展。也就是说目前的GO术语不一定代表某个基因产物所有的功能，组分或参加的过程，只是现阶段对它的认知。

每周更新一次，由GOC本体团队与请求更新的科学家共同完成的。

‘陆’ 如何将数据库中的知识映射到本体中

模式模式又称概念模式或逻辑模式，对应于概念级。它是由数据库设计者综合所有用户的数据，按照统一的观点构造的全局逻辑结构，是对数据库中全部数据的逻辑结构和特征的总体描述，是所有用户的公共数据视图(全局视图)。它是由数据库管理系统提供的数据模式描述语言(Data Description Language，DDL)来描述、定义的，体现、反映了数据库系统的整体观。 2、外模式外模式又称子模式，对应于用户级。它是某个或某几个用户所看到的数据库的数据视图，是与某一应用有关的数据的逻辑表示。外模式是从模式导出的一个子集，包含模式中允许特定用户使用的那部分数据。用户可以通过外模式描述语言来描述、定义对应于用户的数据记录(外模式)，也可以利用数据操纵语言(Data Manipulation Lang uage，DML)对这些数据记录进行。外模式反映了数据库的用户观。 3、内模式内模式又称存储模式，对应于物理级，它是数据库中全体数据的内部表示或底层描述，是数据库最低一级的逻辑描述，它描述了数据在存储介质上的存储方式翱物理结构，对应着实际存储在外存储介质上的数据库。内模式由内模式描述语言来描述、定义，它是数据库的存储观。 在一个数据库系统中，只有唯一的数据库， 因而作为定义 、描述数据库存储结构的内模式和定义、描述数据库逻辑结构的模式，也是惟一的，但建立在数据库系统之上的应用则是非常广泛、多样的，所以对应的外模式不是惟一的，也不可能是惟一的。三级模式间的映射 数据库的三级模式是数据库在三个级别 (层次)上的抽象，使用户能够逻辑地、抽象地处理数据而不必关心数据在计算机中的物理表示和存储。实际上 ，对于一个数据库系统而言一有物理级数据库是客观存在的，它是进行数据库操作的基础，概念级数据库中不过是物理数据库的一种逻辑的、抽象的描述(即模式)，用户级数据库则是用户与数据库的接口，它是概念级数据库的一个子集(外模式)。 用户应用程序根据外模式进行数据操作，通过外模式一模式映射，定义和建立某个外模式与模式间的对应关系，将外模式与模式联系起来，当模式发生改变时，只要改变其映射，就可以使外模式保持不变，对应的应用程序也可保持不变；另一方面，通过模式一内模式映射，定义建立数据的逻辑结构(模式)与存储结构(内模式)间的对应关系，当数据的存储结构发生变化时，只需改变模式一内模式映射，就能保持模式不变，因此应用程序也可以保持不变。

‘柒’ OWL本体文件如何存储到数据库

安装好必要的软件并配置好开发环境

Eclipse

MySQLServer5.5-win32

jena2.6.4

protege4.3

mysql-connector-java-5.1.35（MySQL的JDBC）

1.利用MySQL创建一个数据库：createdatabasemilitary_ontology;

2.打开Eclipse，新建一个Java工程，起名为military_ontology。(File-New-JavaProject,输入名字military_ontology，点击next)

3.新建工程的同时，分别导入Jena包和MySQL的JDBC。（点击Libraries-点击AddExternalJARs，分别加入JDBC和Jena中全部.jar文件，C:和G:Jenalib目录中，点Finish）

4.在工程military_ontologysrc目录下新建一个Java文件（New-Class），名字为military_ontology.java；

5.在military_ontology.java中开始编写以下代码：

packagemilitary_ontology;

importjava.io.*;//导入IO包的所有类

importjava.sql.SQLException;//导入SQL有关异常处理包

importcom.hp.hpl.jena.db.*;//导入jena链接数据库的包

importcom.hp.hpl.jena.rdf.model.*;//导入jena有关模型的包

importcom.hp.hpl.jena.ontology.OntModel;//导入OntModel包

importcom.hp.hpl.jena.ontology.OntModelSpec;//导入OntModelSpec包

ModeldefModel=null;

if(connection.containsModel("militaryDB"))//判断名为militaryDB的模型是否已经存在数据

{

defModel=maker.openModel("militaryDB",true);//数据存在则打开此模型

System.out.println("打开已存在的模型");

}

else

{

defModel=maker.createModel("militaryDB");//数据不存在则创建此模型

System.out.println("创建一个新模型");

}

OntModelSpecspec=newOntModelSpec(OntModelSpec.OWL_MEM);

OntModelDBModel=ModelFactory.createOntologyModel(spec,defModel);

//将临时模型转换成本体模型（OWL格式），其中spec参数表示该模型是在内存中存在的。

FileInputStreamread=null;//定义并初始化文件输入流变量read

try

{

Filefile=newFile("g:/毕业设计/软件/本体实例/Ontology1428926241032/Ontology1428926241032.owl");

read=newFileInputStream(file);//读入OWL本体文件

}

catch(FileNotFoundExceptione)//抓取读入文件异常

{

e.printStackTrace();

System.out.println("未找到要存储的本体文件，请检查文件地址及名称");

}

System.out.println("已将本体文件转换为字节流文件。");

InputStreamReaderin=null;//定义并初始化输入流转换变量in

try

{

in=newInputStreamReader((FileInputStream)read,"UTF-8");//将字节流文件转换为UTF-8编码

System.out.println("已将字节流文件转换为UTF-8编码。");

}

catch(UnsupportedEncodingExceptione)//抓取转换异常

{

e.printStackTrace();

System.out.println("不支持上述字符集。");

}

defModel.read(in,null);//将流文件读入数据库模型

defModel.commit();//将模型保存到数据库中

System.out.println("数据转换执行完毕，已将本体文件存入数据库。");

try

{

in.close();

System.out.println("已将字节流文件关闭。");

}

catch(IOExceptione)//抓取输入输出异常

{

e.printStackTrace();

System.out.println("无法关闭字节流文件。");

}

try

{

connection.close();//关闭连接

System.out.println("已将连接关闭。");

}

catch(SQLExceptione)

{

e.printStackTrace();

System.out.println("连接无法关闭。");

}

}

catch(RDFRDBExceptione)

{

System.out.println("出现异常");

}

System.out.println("已将本体文件持久化到数据库中，无异常");

}

}

执行程序之后，本体被存入MySQL数据库中。数据库会生成以下几张表：

jena_g1t0_reif存储经过处理的本体数据

jena_g1t1_stmt存储了本体的数据信息

jena_graph存储每一个用户图的名字和唯一标志符

jena_long_lit存储陈述表中不便于直接存储的长字符创常量

jena_long_uri存储陈述表中不便于直接存储的长资源URI

jena_prefix存储URI的前缀。前缀只存储一次，节省空间

jena_sys_stmt存储了本体的元数据信息

主要数据存在两个表中。

1)military_ontology.jena_g1t1_stmt存储了本体的数据信息

2)military_ontology.jena_sys_stmt存储了本体的元数据信息

‘捌’ 本体文件持久化到数据库有什么用

持久化到数据库是位了便于本体文件的共享与重复用，建立本体的目的就是为了实现数据共享，如果没有良好的存储方式，共享何在？重复使用的宗旨何在？希望楼主能看明白

‘玖’ 计算机中数据库的本体特征是什么

一. 数据结构化二. 文件系统的本质区别。三. 数据独立性高四. 数据由DBMS统一管理和控制1. 数据的安全性保护2. 数据的完整性检查 3. 数据库的并发访问控制 4. 数据库的故障恢复

‘拾’ 关于本体数据库请问本体数据库是怎么样的，和数据库的

你是想把本体文件持久化到SQL里面吗？我之前学习时借助了Jena这个语义框架，连数据库还是借用了JDBC连接到MySQL数据库。