基于XML Schema分塊的快速本體構建方法

何 杰, 屈國興

(寧夏大學 地理科學與規劃學院, 銀川 750021)

0 引 言

本體(ontology)是指對共享概念模型明確的形式化規范說明[1], 在解決信息的語義異構、 實現知識共享與重用等方面具有重要作用, 目前已被廣泛應用于信息檢索、 語義網、 異構數據集成與融合及農業、 軍事、 旅游、 地理信息、 生物等領域[2-7]. 領域本體為某領域中的概念及概念間的關系提供了規范化表達, 通過定義類、 實例、 屬性、 關系、 公理等元素描述某領域中的類與實例及其之間的層次關系, 對領域知識進行歸納和抽象[8]. 但如何有效構建本體, 提高本體的構建效率、 質量及應用效果是本體大規模應用要解決的主要問題.

由于本體應用主要面向特定領域, 所以本體構建也與具體領域相關. 不同領域知識、 概念的差異性導致了本體構建方法的多樣性. 本體構建方法主要包括： 以本體論工程構建方法為主的本體構建方法和以敘詞表轉換為本體為主的本體構建方法[9], 前者從知識工程的角度研究如何構建本體, 后者主要研究如何根據現有的詞表資源生成本體. 目前, 國外典型的本體構建方法有IDEF5法、 骨架法、 TOVE法、 METHONTOLOGY 法、 KACTUS工程法、 SENSUS法、 七步法、 循環獲取法及五步循環法等[10]. IDEF5法使用結構化本體開發方法構建企業本體, 其優點是利用圖表語言和細節說明語言構建本體, 方便本體的重用并利于理解, 但缺點是缺乏循環開發思想； 骨架法也是一種企業本體構建方法, 該方法對本體的開發流程描述清晰, 但不支持本體演進； TOVE法主要用于商業和公共企業建模, 是一種基于本體評價的本體建模方法, 缺點是不支持演進且建模過程缺少文檔； METHONTOLOGY法是一種化學本體構建方法, 優點是利用知識完成本體構建, 本體重用性好, 但該方法缺少迭代進化； KACTUS工程法是一種基于應用知識庫的抽象化本體構建方法, 其優點是知識重用性好； SENSUS法基于自然語言處理方法構建本體, 常用于構建面向特定領域的本體； 七步法是一種實用的領域本體開發方法, 但該方法缺乏對本體檢查、 評估及用戶的反饋； 循環獲取法基于文本數據源, 通過概念學習、 關系學習、 評價等循環迭代過程構建本體, 該方法通過對本體構建過程的不斷學習和評價提高本體構建質量, 但未提供具體的方法和技術; 五步循環法是一種語義網環境下的基于本體學習的本體構建方法, 其通過對導入的本體進行重用、 抽取、 修減、 精煉、 應用等過程完成本體構建, 但該方法不成熟, 語義網自身的復雜性導致利用該方法建模的難度大、 時間長, 構建的本體應用性不強. 在上述幾種本體構建方法中, IDEF5法、 骨架法、 TOVE法、 METHONTOLOGY法都是手工構建方式, 效率較低, 方法細節較簡單, 相關技術較少. 七步法、 循環獲取法和五步循環法采用半自動構建方式, 方法細節詳細, 常用于醫學等多領域建模. 國內本體構建方法相對較晚, 但發展較快, 在本體論工程法和敘詞表轉換法方面都取得了許多成果. 如杜小勇等[11]提出了一種基于本體學習的本體構建方法, 根據數據源結構及本體學習對象的不同層次, 從9個方面分析本體學習問題的特征、 常用方法和研究進展, 并指出了本體構建在方法、 學習工具、 評價標準上是未來的研究重點； 何琳等[12-13]借鑒軟件工程中的領域建模和本體學習的方法論, 結合專家給出的領域上層知識模式, 通過機器學習技術從領域語料庫中學習概念關系, 最后綜合專家的自頂向下和機器學習的自底向上的結果半自動化地構建本體； 劉柏崇[14]提出了中文領域本體自動構建理論, 解決了快速自動化構建領域本體的問題, 同時提出了一種新的本體自動構建模塊化方法及本體評價標準, 并在本體構建多語種自適應性方面進行了改進； 李景[15]以農業敘詞表為中心知識庫, 在系統分析領域本體構建關鍵技術的基礎上, 設計并構建了基于花卉學領域本體模型和農業敘詞表的原型系統, 同時對大規模、 多人協同構建本體系統的方法和流程進行了探索； 余凡[16]將敘詞表和文本兩種不同數據源進行綜合運用, 通過對文本信息進行概念提取、 概念過濾、 詞匯篩選、 關系提取及形式化處理, 以測繪學敘詞表和文獻為例構建了測繪學領域本體； 任飛亮等[17]通過對以文本為數據源構建本體的相關研究進行詳細分析, 介紹了本體構建結果的常用評價方法及常見的本體構建系統, 并針對本體構建存在的本體更新、 關系消歧、 概念屬性自動獲取及概念消歧等問題, 提出了更高效的機器學習方法, 并根據文本數據特點進行了本體構建.

為提高本體的構建效率, 目前已有許多本體開發工具[18-19]幫助快速構建本體, 主要包括WebOnto[20],Protégé-2000[21],OntoEdit[22],WebODE[23]和KAON[24]等. 每種工具都有自己的特點, 各自有自己的輸入/輸出格式, 定義的概念缺乏通用性, 界面不友好, 協作能力較弱, 推理能力有限. 因此, 目前的本體構建方法仍有許多不足, 主要包括： 1) 現有方法大多數都是面向某個領域或行業, 通用性較弱; 2) 自動化程度低, 需要大量人工參與, 費時費力; 3) 缺乏有效的本體構建工具支持; 4) 沒有統一的評價標準, 本體構建質量無法保障; 5) 本體應用程度較低, 大規模本體應用尚未實現.

雖然開放式地理信息聯盟(OGC)標準規范能解決網絡服務在語法上的異質性問題, 但因語義信息缺乏, 無法解決語義異質性問題[25]. 同時, OGC定義的不同標準規范都是通過XML模式描述, 如網絡覆蓋服務(WCS)規范有不同版本, 每種版本規范中定義了不同XML模式描述WCS不同的操作(wcsGetCapbilities.xsd, wcsDescribeCoverage.xsd, wcsGetCoverage.xsd等), 并從語法上隱含地表達了相關模式元素(概念)間的某種關系, 但語義上的異質阻礙了其在大規模異構網絡服務集成中的應用. 因此, 本文基于現有OGC定義的標準XML模式文件(XML Schema), 提出一種基于XML Schema分塊的快速本體構建方法, 實現XML模式到本體的快速轉換, 通過本體顯示描述概念及其之間的關系, 實現異構網絡服務的共享與互操作.

1 XML Schema轉換本體方法

1.1 系統體系結構

XML作為一種通用的擴展標記語言, 可提供統一的方法描述和交換獨立于平臺、 編程語言、 操作系統、 應用程序或供應商的結構化數據, 是萬維網中處理分布式結構信息的重要工具. XML Schema是對XML文檔結構的定義和描述, 其主要用于約束XML文件, 并驗證XML文件的有效性. 組成XML Schema的主要元素包括Element,ComplexType,Annotation,Sequence等.

OWL是一種建立在DAML+OIL基礎上的網絡本體描述語言, 其目的是清晰明確地表達術語表中術語的含義及其之間的關系, 即本體. OWL本體的基本元素由類、 個體和屬性構成. 類是具有相同屬性和特征的對象總稱, 是個體的集合. 類通常使用正式的描述精確表明其需求, 如類Sensor包含領域中所有的Sensor個體. 類可以被組織為超類-子類的層級關系, 即分類關系. 在OWL中這種分類關系可由推理機自動計算得出. 個體表示感興趣領域中的對象. 在OWL中, 個體間的等同關系必須明確, 否則其可能相同也可能不同. 屬性是個體間的二元關系, 兩個個體通過屬性相互關聯. 屬性擁有多種特征, 如轉置、 被限制為單值、 傳遞性、 對稱性等.

圖1 XML轉換OWL的體系結構Fig.1 Architecture of transformation between XML and OWL

將XML轉換為OWL本體的方法目已有許多研究成果[26-30], 這些方法的共同點就是將轉換過程分為三步完成, 即先從XML文檔中提取XML Schema, 再將XML Schema轉換為OWL模型, 最后通過本體模型將XML文檔映射為本體實例. 上述方法的不足之處是未考慮對本體實例的驗證, 同時模型演進性較弱. 基于此, 本文在綜合考慮相關研究的基礎上, 提出一種基于XML Schema分塊的快速本體構建方法. 圖1是XML Schema轉換OWL本體的系統結構. 整個轉換過程分以下4步完成：

1) 根據XML Schema和OWL描述模型間的關系定義映射規則；

2) 根據映射規則實現XML Schema到OWL模型的轉換；

3) 根據設計好的OWL模型引擎將實驗的WCS模式文檔實例化為OWL本體實例；

4) 在領域專家幫助下對本體實例進行驗證, 驗證成功則輸出最后的轉換結果, 否則修改完善映射規則, 使用新規則重新返回步驟2), 重復后面的轉換步驟, 直至驗證成功為止.

1.2 映射規則

OWL本質上是基于XML/XML Schema這些語言演化而來, 比后者具有更強大的語義表達能力. OWL與 XML Schema在語法上相似, 結構上相關. 基于這些關聯, 定義如下映射規則[28,30].

1) SimpleType(簡單類型)： 對于內置簡單類型、 派生簡單類型、 列表和聯合類型, 只需將包含聲明這類類型的元素或屬性的復合類型元素與其之間的關系映射為owl: DatatypeProperties, 如果元素或屬性聲明包含匿名簡單類型時, 則將元素或屬性的父元素與它們的關系映射為owl: DatatypeProperties.

2) ComplexType(復雜類型)： 對于復雜類型, 一般將復雜類型定義及其內部的復雜類型子元素映射成owl: Class, 而復雜類型與其復雜類型子元素之間的關系映射成owl: ObjectProperties, 將復雜類型與其簡單類型子元素或屬性之間的關系映射成owl: DatatypeProperties.

3) Element(元素)： 如果是一個XML葉子節點元素且只包含簡單文本或一個屬性, 則映射為owl: DatatypeProperties, 其他類型元素映射為owl: ObjectProperties.

4) Attribute(屬性)： 對于全局屬性, 當有局部屬性引用其時, 將局部屬性聲明的父元素與該全局屬性間的關系映射為owl: DatatypeProperties； 對于局部屬性, 只需將該屬性聲明的父元素與其直接的關系映射為owl: DatatypeProperties.

5) Sequence(特定順序)和Choice(選擇順序)： 常用于定義語境, 前者定義的元素是有序的, 后者則無序. 由于OWL中無與之對應的組件, 因此需在這兩個元素被定義或引用的復雜類型所對應的OWL類中定義一個新類完成對應順序選項功能.

6) Ref(引用)： 對于被復雜類型引用的屬性或簡單類型(或包含屬性或簡單類型)映射為owl: DatatypeProperties, 如果被引用的元素包含復雜類型時, 將被映射為owl: ObjectProperties.

7) Annotation(注釋)： 將直接映射為owl: comment.

8) xsd: minOccurs： 將直接映射為owl: minCardinality, xsd: maxOccurs映射為owl: maxCardinality.

1.3 模式分塊

現有的本體構建方法是半自動化的, 本體構建效率有待進一步提高, 特別是大規模的本體構建問題, 由于模式大而復雜, 各種類型節點間包含各種嵌套關系, 影響了OWL實體集的生成效率. 因此, 先將模式圖/樹分割為簡單的圖/樹, 然后基于這些子圖/樹構建本體. 本文采用基于圖/樹分裂方式的分割算法, 即根據樹節點的度的大小對樹進行分割, 分割步驟為： 首先按照廣度優先方法對樹進行遍歷, 并計算每個節點的出度和入度, 若入度為0則節點為根節點, 若出度為0則節點為葉子節點, 若出入度都為0則節點為孤節點； 然后對樹進行分割, 即從根節點開始, 將根節點出度置0, 根節點所有直接子節點的入度減1； 最后確定分割后子樹, 即統計所有入度為0的節點, 每個入度為0的節點及其子節點組成一棵新的子樹. 每個節點用其ID號表示, ID號由3位數字組成, 第一位表示該節點深度, 如根節點深度為0, 依次類推, 第二位表示父節點的位置, 第三位表示本節點在該層中位置, 如ID號為123的節點表示第二層第三個節點, 其父親節點是第一層第二個節點. 節點旁標注節點度的大小, 左邊表示入度值, 右邊為出度值. 最后根據樹的深度確定分割是否結束, 本文算法在確定樹的深度小于等于3時停止分割, 算法的偽代碼描述如下.

算法1模式分塊.

輸入： 模式表示圖G；

輸出： 模式子圖集Gi；

DivideGraph(G)

步驟1) Nodes=SetNumber(G);//給圖G所有節點編號

步驟2) foreach (node in Nodes)

步驟3) inDegree=GetNodeInDegree(node); //計算節點入度

步驟4) outDegree=GetNodeOutDegree(node); //計算節點出度

步驟5) depth=GetNodeDepth(node); //計算節點深度

步驟6)Gs=GetSubGraph(G,node); //生成節點子圖

步驟7) if(inDegree==0 and depth>3) //對入度為0且深度大于3的節點進行分割

步驟8)Gss=DivideGraph(Gs); //對子圖進行分割

步驟9) foreach(G′ inGss)

步驟10) goto 1); //返回步驟1)重新計算分割后每個子圖的節點度及深度

步驟11) else

步驟12)Gi=Gi+Gs; //將最終不需要進一步分割的子圖添加到結果子圖集

步驟13) returnGi. //算法結束, 返回分割后子圖集

2 網絡服務模式本體構建

2.1 模式轉換

XML模式轉換為OWL本體模型主要通過模式轉換器完成, 轉換過程如下.

1) XML Schema解析. XML模式的解析主要通過讀取或分析XML模式包含的信息內容, 讀取和識別各類模式元素對象并確定這些對象間的關系, 然后根據解析后的XML模式元素對象及其關系生成對應的模式圖. 當模式圖中的所有元素都未被重用時, 模式圖便退化為模式樹. 模式圖中頂點集包括所有元素、 屬性、 非原子類型、 元素組和屬性組等. 邊集包括連接每個元素與其非原子類型的邊及所有類型、 元素組和屬性組到它們所包含的元素或屬性的邊. 圖2為模式文件wcsGetCoverage.xsd的模式圖表示形式.

圖2 WCS模式圖表示形式Fig.2 Representation of WCS schema graph

2) 模式圖分割. 以圖2中模式圖為例, 基于模式分塊算法, 先對圖2中的節點進行編號并計算對應的度, 根據圖結構特點, 先將入度為0的根節點進行分裂, 編碼為111的節點入度減為0, 再將該節點進行分裂, 其對應的直接子節點211,212,213,214,215入度都變為0, 其中節點213的深度為4, 繼續進行分割, 其直接子節點331,332,333入度減少為0, 但由于它們的深度都小于3, 故分割結束, 分割結果如圖3所示.

圖3 wcsGetCoverage.xsd模式圖分割結果Fig.3 Partition results of schema graph of wcsGetCoverage.xsd

3) OWL實體集生成. 利用Jena(http://jena.sourceforge.net/)提供的API函數實現將上一步生成的模式圖轉化為OWL實體集. 根據1.2節的映射規則, 將對應的復雜類型、 元素組、 屬性組聲明轉化為OWL類, 元素與對應子元素的關系用OWL對象屬性表達, 屬性及簡單類型則轉化為OWL數據類型.

在圖3分割后的8個子圖中, 5個節點111,211,332,411,432為復雜類型, 其他節點為元素. 根據1.2節給出的映射規則, 節點001直接映射為owl: Class, 111是001的直接子類, 與001間關系映射為owl: DatatypeProperties； 節點211為復雜類型, 其為111的直接子類, 同時其包含一個屬性元素, 故節點211映射為owl: Class, 它與節點111關系映射為owl: DatatypeProperties； 節點212,213,214,215等均為元素, 直接映射為owl: DatatypeProperties； 節點331,333是復雜類型元素, 映射為owl: ObjectProperties； 節點332為復雜類型, 映射為owl: Class. 圖4為wcsGetCoverage模式經過轉換后的OWL本體.

圖4 轉換后的OWL本體模式圖Fig.4 Transformed OWL ontology schema graph

2.2 本體實例化

本體實例化操作主要通過OWL模型引擎完成. 模型引擎在現有OWL模型框架基礎上, 讀取給定的XML文檔, 根據XML文檔元素與OWL模型元素間的對應關系, 提取對應的XML文檔元素實例數據, 生成對應的OWL模型實例. 本文以requestGetCoverageTrimmingSlicing.xml為例, 具體文檔內容如圖5所示, 該文檔實例化一個本體類GetCoverage請求的具體Coverage實例對象, 定義了請求Coverage對象的CoverageId,DimensionTrim,DimensionSlice,format,mediaType等信息.

圖5 XML文檔實例片段Fig.5 Instance fragment of XML document

圖5中文檔實例類GetCoverage映射為owl: class,Coverage對象的CoverageId, DimensionTrim,DimensionSlice,format,mediaType等屬性映射為owl: DatatypeProperty,DimensionTrimType和DimensionSliceType, 用于定義屬性DimensionTrim,DimensionSlice的取值范圍, 所以映射為rdfs: range. DimensionTrimType使用屬性Dimension,TrimLow,TrimHeigh具體定義屬性的取值范圍. 同理, DimensionSliceType使用屬性Dimension,SlicePoint具體定義取值范圍, 這些屬性都映射為rdf: datatype. 圖6為圖5轉換后的OWL本體實例片段.

圖6 轉換后的OWL本體實例Fig.6 Transformed OWL ontology instance

2.3 實例驗證

目前本體評價尚無比較系統化、 實用化的方法, 通常需根據某個具體應用場景的具體需求構建對應的指標體系, 然后建立評價模型進行評價[31-33]. 本文先通過Wonder Web OWL Ontology Validator軟件(http://www.mygird.org.uk/OWL/Validator)對構建的OWL本體模型進行語法驗證, 然后人工對本體實例進行驗證. 主要驗證以下三方面：

1) 類和屬性定義的清晰性, 即根據給定的轉換模式文件, 準確抽取相關類和屬性, 對其進行明確定義, 保證定義的類與屬性準確、 無二義性；

2) 類的關系邏輯一致性, 包括類層次關系的一致性, 即根據文中定義的模式圖結構、 各模式元素間邏輯關系及轉換規則驗證類的關系在邏輯上的一致性；

3) 類與屬性定義的完整性及可擴展性.

一方面, 本文在驗證完前兩項內容后, 重新對轉換后的本體模型與原XML模式原型進行對比分析, 保證定義的完整性； 另一方面, 從應用的角度分析本體模型的可擴展性, 根據本體擴展能力驗證相關類和屬性可擴展性. 本文實驗中邀請了相關領域專家對本體模型進行評估和驗證, 重點按上述定義驗證標準分別對本體實例中類與屬性定義的清晰性、 類的邏輯關系一致性、 完整性和可擴展性進行人工驗證. 專家組的結論是本文方法構建的網絡服務模式本體實例滿足給定的標準和領域應用要求, 但實驗數據結構簡單、 數據量小, 對大規模、 復雜本體實例構建結果還需進一步驗證.

2.4 性能實驗

為有效驗證本文方法在性能上的優勢, 選擇OGC定義的WFS(網絡要素服務)和WCS兩種不同類型的標準模式文件作為本體構建實例, 所有實驗統一使用Win7 64位PC機上安裝的Sun Java 1.8.0庫, PC機配置為3.2 GHz Intel(R) Core(TM)i5-6500處理器和8.0 GB RAM, 不同配置的電腦運行實驗結果在性能上會有差異. 選擇模式文件包含的節點數見表1, 統計本文使用的基于模式分塊方法(B1)和非分塊方法(B2)性能, 由于人工輔助時間受具體人員經驗和水平的影響, 不同經驗和水平人員輔助時間差異較大, 對實驗結果影響也較大, 所以本文在統計時未考慮人工輔助時間. 表1列出了不同本體構建方法性能的比較結果. 由表1可見： 本體構建時間與模式包含的節點數成正比； 基于WCS模式構建本體所需時間總體比WFS多, 這主要是由于WCS模式文件節點數量多且結構更復雜； 兩種構建方法中, 基于分塊的本體構建方法由于采用分治思想, 將復雜的XML模式圖分割成更簡單的子圖, 從而提高了本體構建效率, 與傳統方法相比, 基于分塊的方法性能約提高10%.

表1 本體構建方法性能比較

綜上所述, 本文在綜合分析現有本體模型構建及評價方法的基礎上, 根據現有網絡服務集成應用存在的語義異質問題, 提出了一種基于XML 模式分塊的OWL本體轉換方法, 實現了在線網絡服務模式的半自動本體化及驗證工作, 為網絡服務特別是語義網環境下的異構網絡服務共享與互操作提供了支持. 同時, 為提高本體構建效率, 通過一種基于模式圖節點分裂的方法將一個較大的XML模式圖分割成多個模式子圖, 再基于模式子圖構建本體. 實驗結果表明, 該方法在一定程度提高了本體構建性能.