本體模塊化的研究與實現

摘要：將軟件工程中模塊化的思想引入本體知識庫的構建過程中，將本體組織成多個本體模塊的集成形式，這樣不僅方便了本體的構建，更有利于本體知識庫的共享、重用和維護。用模塊化的方法構建了汽車駕駛培訓領域本體，建立方法庫，在本體模塊間用查詢方式實現模塊間的通信。這樣的開發經驗可以推廣到其他領域。

關鍵詞：本體； 模塊化； 方法庫； 方法； 查詢

中圖分類號：TP391文獻標志碼：A

文章編號：1001-3695(2007)11-0206-04

0引言

現在，本體已被知識工程界廣泛采用，它被Neches等人定義為“給出構成相關領域詞匯的基本術語和關系，以及利用這些術語和關系構成的規定這些詞匯外延的規則的定義”[1]。在知識工程、自然語言處理、信息檢索系統、智能信息集成和知識管理、信息交換和軟件工程等領域，本體技術都得到了研究和發展[2]。

然而畢竟本體技術還是一個比較年輕的技術，比起軟件工程經過幾十年的發展已形成的大量成功的程序設計方法，本體技術還有很多不完備之處有待改進。

現有的本體系統，往往將所有概念組織成一個概念網絡，概念之間存在著錯綜復雜的關系。這樣高耦合度的系統確實能夠體現現實世界事物之間廣泛存在的復雜關系。但是本體中所包含的概念往往很多，有時一個本體會包含超過10億個概念，對于某個概念的某個細微變更就可能影響到整個本體系統中的很大一部分。所謂牽一發而動全身，這樣的本體維護起來十分困難。另一方面，在本體重用時，往往并不會對整個本體感興趣，而只是想重用其中的一部分。但由于系統的高度耦合性，只能將整個本體全部重用（如使用RDF和OWL語言提供的import方法[3]），這不僅增大了開銷，也降低了效率。

模塊化思想在軟件工程中已被廣泛應用。一個大型軟件分成多個相互協作的模塊，每個模塊進而擁有各自的子模塊。模塊化能夠很好地支持重用，并能為系統維護提供很大的方便，但模塊化在知識表示和推理領域并沒有引起足夠的重視。但近年來也有人作過相關的嘗試。

W.Farmer和J.Guttman等人提出的運用模塊化與數學結構的結合來對復雜的問題進行推理，顯示了模塊化方法在重用和減少建模成本方面的優勢。在這以后，重用、組織知識塊而不是白手起家地建設知識庫的思想開始被知識工程界采用來構建現實世界的知識庫。McIlraith和Amir提出知識庫的模塊化對推理也十分有益，即使是對已有的知識系統進行分解，也能提高推理效率。Rector提出了一種使用描述邏輯來模塊化實現本體的策略。這種方法雖然能夠較方便地建立和重用本體知識，但它仍然將整個模型看做是一個單獨的本體，對世界進行耦合的概念描述。Giunchiglia等人提出了一種更直接的分布式表示法。他們提出將本地的模型語義作為一個標準的一階邏輯標準進行擴展。這種語義方法允許不同的模塊對同一事物用不同的視圖來表示?，F在流行的本體構建語言RDF與OWL提供了一些基本的結合模塊的表示機制。但它結合不同模型的能力僅限于一個完整的本體或者是直接引用其他模塊中的概念。

總的來說，本體的模塊化缺乏理論的指導，如何劃分模塊、如何實現模塊間通信和知識整合、如何進行知識推理都是需要解決的問題。

1本體模塊

1．1定義

一個本體可表示為T(C，R，σ)。

其中：C表示本體中所定義的所有概念的集合；R是所有本體中定義的關系的集合；σ是本體中概念和關系必須遵循的約束的集合。

本體中每個模塊可表示為Ti(id，Ci，Ri，σi)。

其中：id對應模塊Ti的URI[5](unique resource identifier，統一資源標志符)；Ci表示模塊中所定義的所有概念的集合；Ri是所有模塊中定義的關系的集合；σi是Ci與Ri中的元素必須遵循的約束的集合。

1．2劃塊原則

一個領域本體往往包含許多學科領域的知識，如汽車駕駛培訓領域就涉及包括機械動力、心理、生理醫學、交通法規等許多學科。這些學科領域知識之間關系錯綜復雜。如何將整個知識體系劃分成本體模塊呢？

1)模塊的劃分要使人易于理解本體系統一方面是使計算機理解所處理的知識，但最基本的還是要讓人來理解。這樣對于系統的共享和重用大有好處，也有利于系統的維護和擴展。

2)劃分的模塊應具有知識相對獨立性的特點知識相對獨立就能降低模塊間的耦合度，減少模塊間的通信。也即使整個本體系統T中跨模塊的概念間關系的集合R′和跨模塊的約束集合σ′應盡可能地小。與軟件工程中一樣，模塊間較小的耦合度能夠使得各個模塊易于重用和共享。

3)每個模塊與其有關系的模塊數盡量少減少相關的模塊數使得模塊間的依賴相對明晰，減少模塊間的復雜度。

根據模塊劃分的原則，汽車駕駛培訓系統中，整個本體系統劃分為車輛結構、駕駛技術、駕駛心理、生理醫學、交通法規五個模塊。這些模塊本身都是較為獨立的知識體系，其中駕駛心理模塊包含了大量的生理醫學和駕駛技術的知識，而汽車駕駛模塊則關系到車輛結構模塊的知識，交通法規模塊關系到汽車駕駛模塊的知識?？梢钥闯?，生理醫學和車輛結構模塊相對獨立，它并不調用其他模塊的領域知識。整個本體系統中，與模塊間知識的調用關系十分明晰。模塊及知識調用關系如圖1所示。這樣的領域模塊劃分也得到了領域專家的認可。

2推理方法庫

2．1推理方法與領域知識分離的知識推導方式

現在最常用的也是最簡單的本體推理方法，是在本體知識庫中定義一組邏輯公理或規則，借此新的事實可以由已有的事實中衍生出來。普通的推理引擎就可以基于這些規則（rules）或公理（axioms）得出結論，產生新的知識，最后解決一些簡單的問題。但這些規則和公理專適用于某一領域。另外規則常常潛藏隱含的過程性知識（如規則序、結合序），最終會影響引擎的實際運行。這些隱含的知識使規則庫不可靠，當領域知識發展時難以更新[4]。

方法庫利用領域知識解決某種任務。一方面，方法庫為獲取本體模塊中的知識提供了查詢、推理的方法；另一方面，也為本體模塊中的知識提供了一個對外的接口，應用程序能方便地通過它獲得模塊中的知識，而無須了解模塊中的內部結構。

使用獨立于本體知識庫的方法庫最大的優點是減少了本體知識庫與推理機制之間的耦合度，大大加強了本體知識庫的可重用性和可共享性。另外，由于可通過專門的與領域知識庫的接口獲取知識庫中的現有知識，獨立的方法庫能夠方便地處理數據，不用像設計規則、公理那樣考慮各種知識概念耦合的問題。

方法庫從領域知識抽象并分離出過程性知識，使系統的推理行為和系統中領域知識的任務清晰且易于更新。在領域知識庫中知識有所改變時，只要不涉及到過程性知識，那么方法庫就無須改動；同樣地，推理機制改變時，也只需要改變方法庫，領域知識庫可以不變。

2．2方法庫的組織

本體中模塊之間存在著通信，通信在模塊所對應的方法庫中實現。但為了確保通信的有序性，使得系統易于管理，各個模塊的方法庫必須有一個良好的組織結構，規范方法之間知識的調用。

將模塊的方法庫設計成類似于軟件工程中包(package)的形式[5]。一個方法庫可以引入(import)一個或多個方法庫，但每個方法庫只能被一個方法庫直接引入，且不能出現循環引入的現象。這樣保證了不會出現方法的循環調用。為方法庫中的方法定義一個使用范圍屬性，這個屬性的值可以是public、protected或是private，即公開、受保護或是私有。當此屬性值為public時，推理系統外的應用任務及系統中各個方法庫中的方法都能夠調用此方法；若值是protected，則只有直接或間接引入此方法庫中的方法才能夠調用此方法；若值是private，則只有方法所在的方法庫中的其他方法有權調用此方法。

例如，通過駕駛員的駕駛狀態獲得駕駛員的個性化心理指標。在此過程中，在駕駛心理學本體模塊方法庫中個性化心理指標的查詢qd用方法fqd。fqd是范圍屬性，標記為public的方法。在此方法中需要調用駕駛員情緒緊張度指標(it)、心臟收縮機能(hc)、駕駛員駕駛操作指標(dt)等一系列查詢。對情緒緊張度指標的查詢qit由駕駛心理方法庫中的private方法fqit完成。這樣緊張度指標對心理方法庫以外的方法來說就是不可見的，這就起到了知識隱藏的作用。心臟收縮機能的查詢qhc使用駕駛心理方法庫所引入的駕駛生理方法庫中的方法fqhc進行查詢。fqhc的范圍屬性被標記為protected。這樣只有引入駕駛生理方法庫的方法庫或者是駕駛心理方法庫本身的方法才能夠調用此方法。而對駕駛員駕駛操作指標的查詢qdt，則由駕駛技術方法庫中的方法fqdt來實現。注意駕駛技術方法庫并沒有被引入駕駛心理方法庫中，所以fqdt的范圍屬性是public。圖2詳細描述了各個方法的范圍屬性。

2．3方法的描述

方法庫中的方法分為原子方法和復合方法兩類。原子方法是不可再分的方法，可以直接被調用。復合方法是由若干個原子和復合方法構成的方法。每個方法都有一個IPOE。IPOE是指inputs、outputs、preconditions、effects。Inputs和outputs是指方法的輸入和輸出，可以理解為數據的變換。Preconditions和effects是指方法的前提條件和效果，即方法執行前應該滿足的條件和服務執行后實際產生的效果，它們都是約束，也就是方法執行前所必須滿足的約束以及方法執行后所產生的新的約束。一個復合方法還有一個controlConstruct定義。ControlConstruct定義了復合方法中每個子過程的執行順序，這里使用OWL－S[6]中定義的控制流，有sequence、split、split+join、unordered、choice、if－then－else、iterate、repeat－until。

下面的例子是用OWL語言來描述的汽車動力學方法庫中獲取物體加速度的方法：

〈process:CompositeProcess rdf:ID=\"getAcceleration_Process\"〉 

〈rdfs:label〉 This function is used to get the excitement of a particular driver〈/rdfs:label〉

〈process:composedOf〉

〈process:Sequence〉

〈process:hasSubProcess rdf:about=\"#GetObjectDetails\"/〉

〈process:hasSubProcess rdf:about=\"#GetForce\"/〉

〈process:hasSubProcess rdf:about=\"#ComputeAcceleration\"/〉

〈/process:Sequence〉

〈/process:composedOf〉

〈process:domain〉public〈/process:domain〉

〈/process:CompositeProcess〉

該方法由三個子方法組成，即GetObjectDetails、GetForce、ComputeForce，它們按照順序執行。方法被標志為public，它能被其他方法以及應用程序調用。

下面是方法計算物體加速度的IPOE描述：

〈process:AtomicProcess rdf:ID=\"ComputeAcceleration\"〉

〈process:hasInput rdf:resource=\"#OuterForce_In\"/〉

〈process:hasInput rdf:resource=\"#ObjectMass_In\"/〉

〈process:hasOutput rdf:resource=\"#ObjectAcceleration_Out\"/〉

〈process:hasPreCondition rdf:resource=\"#NoCircumrotation\"/〉

〈/process:AtomicProcess〉

〈process:Input rdf:ID=\"OuterForce_In\"〉

〈process:parameterType rdf:resource=\"physicalconcepts#Force\"/〉

〈/process:Input〉

〈process:Input rdf:ID=\"ObjectMass_In\"〉

〈process:parameterType rdf:resource=\"physicalconcepts#Mass\"/〉

〈/process:UnConditionalOutput〉

〈process:Output rdf:ID=\"ObjectAcceleration_Out\"〉

〈process: parameterType rdf:resource=\"physicalconcepts#Accele￣ration\"/〉

〈/process:UnConditionalEffect〉

ComputeAcceleration方法有兩個數據輸入，分別是物體所受外力outerAcceleration和物體質量objectMass，有一個數據輸出（物體所受外力outerForce）。這個方法的執行有一個前提條件noCircumrotation（無旋轉），它沒有任何的effect。

而后，指定computeAcceleration方法中涉及輸入/輸出數據的類型。這里acceleration、mass、force等概念都在汽車動力學本體模塊中定義。通過parameterType實現方法本體與領域知識本體的映射。

圖3是方法各個屬性的結構圖。其中：bag是方法庫的URI；beinBag關系表示某個方法所在的方法庫；range則是方法的作用范圍屬性。這樣將方法庫中的方法也按照本體概念的形式加以描述，把方法本身作為一個資源，用各種關系的形式表示方法的輸入/輸出、在執行前必須滿足的條件、調用后的影響等此方法的特性。這就用本體的方法使得應用程序和其他方法能夠理解方法提供的服務。圖3中矩形表示的都是本體知識庫模塊中的資源。

3系統構架

實際的應用系統可分為三個層次：a）專業模型（傳統意義上的領域本體）層，它是關于某一領域知識的集合；b）方法層，它是執行系統推導過程以完成任務的方法的集合，并且它實現每個本體模塊對其他模塊的查詢接口；c）任務層，它是系統必須具有的功能的集合。

其中最主要的是方法層。在任務處理方法庫層中，有一個針對系統外應用任務的任務處理方法庫，所有模塊的方法庫都直接或間接引入該方法庫中，任務模塊的任務只能調用該方法庫中的方法。任務方法庫負責將具體的任務描述、分解，將一個任務轉換為多個本體模塊方法庫中的方法及其相互協作關系。接著任務處理方法庫調用模塊方法庫中的方法，運用這些模塊中的知識進行推理。當推理遇到需要查詢基于其他本體模塊的知識時，可使用其他模塊中對其可見的方法fi進行查詢。每個本體模塊的方法庫可引入其他模塊方法庫中，但每個方法庫只能直接引入一個方法庫中，且不能循環引入，所有模塊的方法庫都直接或間接地引入任務處理方法庫中。這樣將各個模塊的方法庫組織成能夠引入其他方法庫的類似于包的關系，避免了傳統的直接引入本體知識庫的方法，使得各本體模塊之間的耦合度大大降低，本體模塊之間關系明晰，易維護性大大增強，也易于模塊的重用。因為每個模塊的方法庫相當于知識適配器，在模塊知識發生改變時，只要不影響查詢的結構，方法庫就無須改變；而當查詢要求改變時，無須改動知識庫的結構，只需將方法庫中的相應方法改變即可。當需要重用某個模塊時，由于所需要的查詢方法已在查詢庫中，知識模塊的對外接口十分明確，重用起來相當方便。

可以看到，目前系統的模塊之間還是存在一定的耦合度。這主要體現在范圍屬性被標志為public和protected的方法能夠被其他模塊的方法庫中的方法使用。特別是標志為public的方法，由于它的存在，不僅使系統的復雜性增大，在分布式或大型本體的情況下系統的推理效率會受到極大的影響。針對這一點，系統可將每個模塊需要使用的其他模塊的知識通過其他模塊的方法查詢后所得到的結果保存在本模塊的方法庫中，作為本模塊本地的知識，這樣就真正實現了模塊內推理[4]。但這種編輯映射并將結果加入到模塊中的方法對本體模塊的修改十分敏感。當查詢被編輯完成后，推理的正確性只能在被查詢的模塊結構不改變的情況下才能被保證。另一方面，并不是每一次模塊結構的改變都會影響接口的編輯結果，只有在查詢中使用到的概念發生改變或是包含查詢的類的結構發生變化時問題才會出現。在后一種情況下必須重新編輯接口；而在前一種情況下，可能需要考慮重新定義查詢。為了決定編輯的公理是否繼續有效，可以采取一種修改偵察機制，它基于一種對本體的修改的分類。這種分類的因素包括修改對類的組織結構的影響，及所影響的類在類結構中的位置。還可以采用一個表示本體模塊之間依賴關系的清晰的表達方式，從而能在需要時很容易地通知系統的相關部分某個模塊已經改變，從而作出相應的改變。

4結束語

本文模塊化的本體系統具有以下優勢：

a）模塊化使得開發時分工明確。在本體特別是大型本體的開發過程需要不同領域的專家所組成的團隊協作，每個參與團隊只負責本體一小部分的構建[7]。模塊化后，這樣的工作得到了規范，每個人的職責也明確了，從而每個人的構建成果易于集成，開發成本和效率因此提高。

b）模塊化降低了系統的復雜度。每個模塊內只存在模塊內概念間的關系，可以簡化模塊設計和模塊維護。一個模塊與另一個模塊的通信通過方法庫實現，模塊間的耦合度比較小，容易在不改變對外接口的情況下改變模塊內部的知識。這樣更新維護十分方便。

c）模塊化易于系統的共享和重用。由于在本體重用時往往只需要重用其中的一部分，而系統的每個模塊都是一個比較完整的理論體系，系統中的每個模塊都能夠被單獨重用。每個本體模塊的方法庫與知識庫獨立，在知識庫不變的情況下重新設計方法庫就能夠適應新的應用需求，為模塊的共享和重用提供了有利的保證。

d）本體雖然是為了達到知識共享目的，但在實際應用中可能出于隱私或安全性的考慮或是為了管理上的方便，會選擇性地隱藏本體中一些部分。運用模塊化技術，方法庫中方法的范圍屬性較好地解決了這一問題。

與軟件工程的模塊化相比，本體知識庫的模塊化顯得相當不成熟，還有許多需要解決的問題。該方法只是在汽車駕駛培訓領域的本體知識庫構建中得到應用。目前系統還有一些問題沒有得到很好的解決，如各模塊間若存在意義上有重疊的概念如何進行映射，如何在某一模塊更新后其他模塊作相應的改變等，在以后的工作中還將繼續優化。

參考文獻：

[1]鄧志鴻，唐世渭，張銘，等.Ontology研究綜述[J].北京大學學報：自然科學版，2002，38(5):24-27.

[2]NOY N， HAFNER C. The state of the art in ontology design[J]. AI Magazine， 1997，18(3):53-74.

[3]SMITH M K.OWL Web ontology language guide[K/OL].http://www.w3.org/TR/2004/REC－owl－guide－20040210.

[4]CRUBZY M， PINCUS Z， MUSEN M A. Mediating knowledge between application components[C]//Proc of the Semantic Integration Workshop of the 2nd International Semantic Web Conference， Sanibel Island， Florida:[s.n.]， 2003.

[5]BAO Jie， CARAGEA D， HONAVAR V. Towards collaborative environments for ontology construction and sharing[C]//Proc of International Symposium on Collaborative Technologies and Systems. Las Vegas， Nevada:[s.n.]， 2006:99－108.

[6]MARTIN D. OWL－S: semantic markup for Web services[EB/OL].http://www.daml.org/services/owl－s/1.1/.

[7]STUCKENSCHMIDT H， KLEIN M. Modularization of ontologies wonderWeb: ontology infrastructure for the semantic Web[EB/OL].http://wonderweb.semanticweb.org/ deliverables/documents/D21.pdf.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”