本體與資料庫

『壹』 「本體」的定義是什麼

一、 本體的概念

本體（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資料庫。