專家視圖與本體視圖的語義映射方法?

陳德彥 , 趙 宏 , 張 霞

1(東北大學 計算機科學與工程學院,遼寧 沈陽 110819)

2(計算機軟件國家工程研究中心(東北大學),遼寧 沈陽 110179)

3(沈陽東軟智能醫(yī)療科技研究院有限公司,遼寧 沈陽 110179)

4(東軟集團股份有限公司,遼寧 沈陽 110179)

本體(ontology)是共享概念模型的明確的形式化的規(guī)范說明[1],其提供了一種結構化地表示領域知識的形式化方法,并提供了推理能力,構造本體可以實現(xiàn)某種程度的知識共享和重用.由于本體具有的強大的知識表示和推理能力,已經在很多領域得到了廣泛的應用,例如語義Web[2]、知識工程、自然語言處理、信息獲取、信息集成、生物醫(yī)學等領域,用于領域問題求解、異構信息源之間的交互、輔助組織中人與人之間的溝通等.基于本體的信息建模主要借助于一個互補的語言集合,該集合包含3 種語言[3]:資源描述框架(resource description framework,簡稱RDF)[4]、RDF 詞匯定義(RDF schema,簡稱RDFS)語言[5]、Web 本體語言(Web ontology language,簡稱OWL)[6].由于直接使用這些本體描述語言來進行本體建模很不方便,也難以掌握,于是出現(xiàn)了一些圖形化的本體編輯工具,例如Protégé[7],OntoEdit[8],KAON[9]等.這些本體編輯工具很好地簡化了領域知識的形式化描述過程,但卻并不能很好地幫助指導如何建模領域知識庫,而這正是本體工程[10]所要研究和解決的核心問題.與軟件工程、面向對象設計和知識工程類似,本體工程研究本體構建的方法學,涉及本體構建的過程、采用何種工具和語言、以何種順序使用這些工具和語言、如何應用這些工具和語言、質量控制和資源管理等.針對不同學科領域、工程問題或應用場景,目前有多種本體構建方法,例如面向對象的本體建模方法[11,12]、基于層次的本體建模方法[13,14]、面向具體學科領域或工程問題的本體建模方法[15,16]等.但是目前尚沒有一種標準的、適用于所有學科領域或應用場景的本體建模方法,實際上也不可能存在建模本體的唯一的正確的方法,最好的解決方案總是依賴于具體的應用,對本體質量的評價也唯一取決于使用它的應用.因為構建本體本身并不是一個最終目標,而是為了應用的需求而提供一套數(shù)據(jù)集和它們之間的結構,而且本體開發(fā)總是一個迭代和不斷精化的過程[17].無論采用何種方法進行本體開發(fā),一般應遵循 Gruber 提出的 5 條原則[18]:清晰性(clarity)、一致性(coherence)、可擴展性(extendibility)、編碼偏好程度最小(minimal encoding bias)、本體約定最小(minimal ontological commitment).

現(xiàn)有的本體建模方法都只是對建模過程從不同的方法學、學科領域或工程問題的角度提出了一些簡單的指導原則和基本步驟,而在進行實際的領域語義知識庫建設時,會面臨大量更加具體的共性問題或者特定問題,使得知識工程師仍然無從下手.目前公認領域本體的開發(fā)需要領域專家的參與,并由知識工程師將領域專家提供的領域知識建模并形式化為可被計算機處理和共享利用的領域本體知識.于是,從專家角度看到的知識視圖(簡稱專家視圖,即領域知識模型)和從知識工程師角度看到的本體知識視圖(簡稱本體視圖,即本體知識模型)可能是不同的.專家并不理解也不關心基于本體的知識建模和形式化方法,而只關心知識對人的易理解性和易使用性.知識工程師建立本體知識視圖時更多考慮的是本體描述語言的描述能力、Gruber 提出的5 條原則、領域應用需求的可滿足性、知識服務實現(xiàn)的合理性和方便性等.由于領域知識本身的復雜性和這兩種視圖表示方法和目的的不同,專家視圖和本體視圖幾乎不可能是一樣的,也即需要建立專家視圖和本體視圖之間的正確語義映射,才能真正實現(xiàn)領域知識的存儲、共享、集成和復用.基于大量實踐發(fā)現(xiàn):這個映射過程存在大量需要解決的關鍵問題,而其中一些關鍵問題是在建模面向不同學科領域或工程問題的不同類型本體時面臨的共性問題,例如:

1) 在專家視圖中,一詞多義的現(xiàn)象很普遍,資源對象的語義一方面通過采用某種語言描述的資源名稱的含義來表達,另一方面,通過資源對象應用的領域上下文來豐富或限定其語義.以健康醫(yī)療領域為例,術語“疾病”有時指一個概念,代表所有疾病的集合,有時指一個屬性,代表某個疾病誘因關聯(lián)的疾病;“泌尿道感染”可能代表一種疾病,也可能是另一種疾病的誘因、風險因素或表現(xiàn)癥狀;“糖尿病”通常指一個疾病實例,但“糖尿病”還可以細分為“1 型糖尿病”、“2 型糖尿病”、“妊娠糖尿病”等,這時“糖尿病”又表示一些實例的集合,即代表一種疾病類型等.而在本體視圖中,某個資源對象一旦建立,其ID就是唯一的,當然可以明確聲明其與另一個資源對象在語義上是等價的或者完全不同的;

2) 在任何領域的知識描述中,都會涉及到對資源的某些量化指標的描述,例如人的身高、體重、血糖、血壓等.這些指標實際上是一個結構化的值,由數(shù)值和對應的單位構成,因為在不同的語境下(例如在不同國家),對相同指標的描述其默認指稱單位可能并不一樣,即同一個屬性存在不同方面的值.另外,在任何領域都存在一些模糊和不確定的知識,例如醫(yī)生對患者疾病的診斷或風險評估就是一種可能性的判斷,不但要表達患者與疾病的關系,還要描述這種關系的可能性大小或者風險等級.這些結構化值和不確定關系的描述都涉及到多元(n-ary)關系,而本體只能描述二元(binary)關系;

3) 訪問授權的語義映射.領域本體庫提供領域中共同認可的知識,一般不涉及安全或隱私問題[19];領域實例數(shù)據(jù)提供關于個體的知識,可能存在顯式的關于個體的敏感或隱私信息.基于領域本體庫和領域實例數(shù)據(jù)的語義推理,可能揭示隱含的關于個體的敏感或隱私信息.針對領域中涉及安全、敏感或用戶隱私相關的內容,領域安全專家、信息擁有者(例如醫(yī)院或患者)或信息來源者(例如患者)都可能提出訪問授權的需求,需要基于領域語義知識庫建立此訪問授權的語義映射.

以上列舉的部分語義映射的共性問題,在目前基于本體的知識建模方法、建模工具、知識獲取、知識復用的研究中并未進行深入探討,這阻礙了本體在各個領域中的廣泛應用.為此,本文就以上列舉的3 類語義映射的共性問題從5 個方面展開了深入研究,提出了相應的解決方法,總結了10 條本體建模約定.最后,對這5 類語義映射方法進行了應用驗證和評價.

本文第1 節(jié)給出相關定義.第2 節(jié)針對上述的3 類語義映射的共性問題從5 個方面進行深入探討,提出相應的解決方法.第3 節(jié)采用本文提出的語義映射方法構建一個完整的應用案例.第4 節(jié)對本文的方法進行評價.第5 節(jié)介紹相關研究工作及其存在的不足.最后一節(jié)對本文進行總結,并提出進一步的工作.

1 相關定義

定義1(領域專家知識(domain expert knowledge)或領域專家視圖(domain expert view)).區(qū)別于領域大數(shù)據(jù)中蘊含的碎片化的或者隱含的領域知識,領域專家知識是指領域專家整理的系統(tǒng)化的、顯式的領域專業(yè)知識以及專家積累的領域經驗知識,領域專家知識的形態(tài)可以是圖、表、文字等多種形式.領域專家知識主要是給人閱讀的,而不是計算機可處理的,需要由知識工程師將其映射為領域語義知識庫中的知識,以實現(xiàn)領域知識的共享、集成和復用.記領域專家視圖為EKBdomain,其定義如下:

其中,eki表示其中一位領域專家所貢獻的領域知識.

定義 2(領域本體定義(domain ontology schema)).領域本體定義[3]通過捕捉領域中共同認可的概念(concept)、概念屬性、概念分類關系、概念間存在的語義關聯(lián)關系及相關約束來描述領域知識.記Odomain表示領域本體,其定義如下:

其中,

·C表示概念(concept)集,概念又稱為類(class),用于表達具有某類相似特征的個體(individual)的集合,個體又稱為實例(instance).例如,概念“人(person)”代表所有個體人的集合;

·A表示所有概念的屬性(attribute)集,概念的屬性又稱為數(shù)據(jù)類型屬性(data type property),它描述概念所包含的實例本身的特征,例如人的姓名、性別、出生日期、身高、體重等;

·R表示語義關系(semantic relation)集,語義關系又稱為對象屬性(object property),包含分類關系(taxonomic relation)和非分類關系(non-taxonomic relation),即R=Rvtax∪Rhntax:

?Rvtax表示概念、屬性或語義關系的縱向分類關系,例如,概念“人”可以進一步劃分為“男人”和“女人”兩個子概念;

?Rhntax表示橫向的非分類關系,例如人的個體間存在的好友關系、父子關系、兄弟關系等;

·X表示公理集,公理(axiom)用于定義概念、屬性和關系之上的約束,比如限定概念某個屬性的數(shù)量(基數(shù)約束)或者在某個屬性之上的取值(值約束)、限定屬性和關系的定義域(domain)和值域類型(range)等,例如:人的出生日期只有一個,但不同人可以具有相同的出生日期,人在生物學意義上的父親和母親都是唯一的;出生日期屬性的定義域類型為人,值域類型為日期類型等;

·I表示實例數(shù)據(jù)集,用于描述領域中共同認可的常識知識,例如內分泌和代謝類疾病包含糖尿病、甲亢等.領域本體定義類似于面向對象中的類的定義,領域本體定義中一般不包含實例數(shù)據(jù),除非用于表達一般性的領域常識知識,但僅包含實例數(shù)據(jù)的RDF 描述片段不能稱之為本體定義[3].

定義3(領域本體庫(domain ontology base)).領域本體庫由一個或者多個領域子本體構成,它們分別用于描述領域中某個方面的知識.記OBdomain表示領域本體庫,其定義如下:

通常,一個本體不可能定義關于某個領域的全部知識,它可能只定義該領域中某一個方面的知識.Oi表示領域本體庫中的某個子本體,領域本體庫的子本體劃分和組織方式依賴于領域知識體系的構成、領域語義知識庫服務的應用需求和采用的領域語義知識庫建模方法.

定義4(領域實例數(shù)據(jù)(domain instance data)).領域實例數(shù)據(jù)[3]為基于領域本體庫中的定義來描述的領域中的常識知識或個體的知識.例如,基于醫(yī)療健康本體庫描述某個人的基本信息和健康狀態(tài).領域常識知識為領域中公認的知識,通常位于領域語義知識庫中.領域中具體環(huán)境或個體的知識,通常作為基于領域語義知識庫的知識服務的輸入,以獲得問題解.記Idomain表示領域實例數(shù)據(jù),其定義如下:

其中,

· (s,p,o)表示描述實例數(shù)據(jù)的陳述或稱為三元組(triple);

·s為某個實例對象;

·I表示實例對象集;

·p表示用于描述實例對象的屬性或者語義關系;

·A和R分別表示描述I中實例對象所用到的屬性集和語義關系集;

·o表示屬性或語義關系的取值,或者為實例對象,或者為字面值(literals)[4,10];

·V表示字面值的集合.

定義5(領域實例庫(domain instance base)).領域實例庫由一個或多個領域實例數(shù)據(jù)片段組成,它們分別用于描述領域中不同方面的常識知識或不同個體的知識,當然也有可能描述某個個體不同方面的知識,例如描述某個人的健康狀況、研究興趣、個人愛好等.記IBdomain表示領域實例庫,其定義如下:

定義6(領域語義規(guī)則集(domain semantic rule set)).領域語義規(guī)則同時服務于領域本體的定義和領域實例數(shù)據(jù)的描述,一方面用于描述領域中領域專家所獲得的啟發(fā)式經驗知識,另一方面用于補充本體描述語言的語義描述能力.記Fdomain表示領域語義規(guī)則集,其定義如下:

其中,ri表示其中一條語義規(guī)則.語義規(guī)則是典型的條件語句:if-then 子句,只有當特定陳述(statement)集合為真時,才會添加新的知識.語義Web 層次結構[2,3]提供了多種知識表示形式,包括從RDF 到最新版本的OWL 等多種格式,每一層都對表達能力進行了進一步的擴展,并且允許用戶根據(jù)語義程序具體所需的語義量來采用相應的表示方式.但本體描述語言在表達能力和靈活性方面仍然存在一些不足,語義規(guī)則用于擴展本體描述語言的描述能力以及靈活性.W3C 建議的語義規(guī)則描述語言為語義Web 規(guī)則語言(semantic Web rule language,簡稱SWRL)[20].

定義7(領域語義知識庫(domain semantic knowledge base)或本體視圖(domain ontology view)).領域本體庫、領域實例數(shù)據(jù)和領域語義規(guī)則集一起構成了領域語義知識庫.

記SKBdomain表示領域語義知識庫,其定義如下:

本體定義的結束,便是知識庫構建的開始[17].基于領域本體庫中的本體定義和語義規(guī)則來描述具體的實例,形成實例數(shù)據(jù)和語義規(guī)則集,以領域本體庫作為領域背景知識,以實例數(shù)據(jù)和語義規(guī)則集作為具體的知識,它們一起形成了面向特定應用需求的語義知識庫.例如,基于醫(yī)療健康領域本體庫構建面向慢性病患者的健康風險評估、疾病自我診斷、疾病輔助診斷、疾病干預方案(藥物、運動、飲食、心理、睡眠等)、遠程監(jiān)護服務、健康知識問答服務、健康教育/咨詢服務等需求的語義知識庫.

W3C 推薦的針對語義知識庫的語義層(即RDF 層)查詢標準語言為SPARQL[21],這種查詢語言不僅理解RDF 的語法,而且理解RDF 的數(shù)據(jù)模型和RDF 詞匯的語義,幾乎所有的RDF 查詢工具都提供了對SPARQL 查詢語義的支持[10,19].

2 語義映射方法

以本體視圖來建模領域知識,目的是為了實現(xiàn)領域知識的存儲、共享、集成和復用.為此,需要基于共同認可的標準或規(guī)范來對本體視圖進行形式化描述,以實現(xiàn)計算機可準確理解其語義并可做出正確的推理.本文對本體視圖的描述完全遵循W3C 推薦的本體描述語言規(guī)范(RDF,RDFS,OWL 等),使用這些標準本體描述語言提供的語義組件來描述領域專家知識.

本節(jié)針對專家視圖與本體視圖的語義映射中的5 個通用問題進行了深入探討,給出了相應的解決方案,總結了10 條約定,并分別通過實例對映射方法進行了詳細說明.

2.1 資源名的語義映射

針對引言中提到的一詞多義的語義映射問題有很多類型,本節(jié)探討專家視圖中的資源在本體視圖中的命名規(guī)則,以及在本體視圖中屬性的定義位置.

第2.2 節(jié)和第2.3 節(jié)分別探討了另外兩類問題及其語義映射解決方案.

如圖1(a)所示的專家視圖,如果進行直接的語義映射,將存在如下3 個問題.

1) 在圖1(a)中,專家同時定義了“疾病”概念和“疾病”屬性、“癥狀”概念和“癥狀”屬性,這對于人類理解并沒有問題.但在本體視圖中,概念和屬性對應的語義類型分別為owl:Class 和rdfs:Property,其定義和語義約束是完全不同的,無法將同一個ID 表示的資源同時聲明為類和屬性;

2) 在圖1(a)中,“疾病”屬性對應的定義域類型分別有“人”“風險因素”“醫(yī)學實驗”和“疾病誘因”,“癥狀”屬性對應的定義域類型有“人”和“疾病”,即分別通過屬性“疾病”“癥狀”建立了多個概念之間的語義關系.同樣,這對于人類理解并不會產生歧義;但如果在本體視圖中分別建立對應的對象屬性“med:diseases”和“med:symptoms”來描述這些概念之間的語義關系,或者不聲明屬性的定義域,或者將屬性的定義域同樣聲明為多種類型,這都將引起語義推理結果的歧義.例如,基于推理結果認為概念“人”“風險因素”“醫(yī)學實驗”和“疾病誘因”在語義上是等價的,因為它們的實例都可以作為屬性“med:diseases”的主語.對于癥狀屬性,存在同樣的問題;

3) 從本體工程的角度,同一個專家視圖可能被映射為一個或者多個本體視圖.在本體視圖中,由于屬性具有方向,屬性定義域和值域聲明中對應的概念的定義可能位于不同的Odomain中,屬性連接的兩個實例的定義也可能位于不同的Idomain中.這種情況下,屬性定義的位置約定就很關鍵,否則可能導致屬性的冗余定義(有可能不同位置定義的屬性其語義約束并不完全一致),進而導致知識的冗余定義,同時可能會引起語義理解和語義推理上的歧義.例如在圖1(b)中,疾病、癥狀等概念的定義位于Omedicine本體中,概念“人”的定義位于Opeople本體中,那么在定義人與疾病或者人與癥狀之間的語義關系時,需要決定該語義關系應該定義在哪個本體中.如果分別定義,可能會導致屬性冗余定義,除非明確聲明它們是等價的(通過owl:equivalentProperty)或者互逆的(通過owl:inverseOf),否則可能會引起語義理解和語義推理上的歧義.

在SKBdomain中,除了字面值(數(shù)值、布爾值、字符串等)和規(guī)則以外的所有對象都被稱為資源(resource).資源是我們想要討論或記錄的對象或事物[10],這些資源可以是物理存在并可通過網(wǎng)絡訪問的資源,例如網(wǎng)頁、網(wǎng)絡圖片、Web 服務等;或是物理存在但不可通過網(wǎng)絡訪問的資源,例如人、公司、圖書館中的書籍等;或是物理不存在的抽象概念,例如本體、語義Web 等.RDF 將資源定義為任何可被URI(uniform resource identifier)引用(URI references,簡稱URIrefs)標識的事物[4].URI 引用是一個在尾部附加了可選的片段識別符(fragment identifier)的URI.例如,在這個URI 引用“http://www.example.org/index.html#section2”中,符號#前面的部分為URI,#后面的部分為片段標識符.URI 引用可以包含 Unicode 字符,這就允許在 URI 引用中使用多種語言.因此,使用URIrefs,RDF 實際上可以描述任何事物,并陳述這些事物之間的關系.在領域語義知識庫中,除了不使用URI 引用格式表示的字面值以外,其余對象都為資源,包括概念、屬性、語義關系和實例對象.

在本體視圖中,資源ID 采用URIrefs 進行標識,只需要保證其唯一性即可,這個ID 對于語義推理來說沒有任何語義貢獻,因為推理是基于本體描述語言中定義的語義組件的語義(即本體推理)和定義的語義規(guī)則的語義(即規(guī)則推理)來進行的.由于在SKBdomain中,OBdomain中的對象規(guī)模相比IBdomain中的對象規(guī)模少很多,幾乎不是一個數(shù)量級的,比如一個疾病概念下的疾病實例可能有幾萬種.所以一般情況下,可以對OBdomain中的資源對象取一個不重復的、有意義的人類可識別ID.由于實例的規(guī)模非常大,對于IBdomain中實例的ID,要取一個不重復的、有意義的名稱比較困難,所以可以根據(jù)領域特定上下文或應用需求采用某種約定的編碼規(guī)則,例如,健康醫(yī)療領域中的疾病診斷的ICD-10 編碼[22]、臨床操作的ICD-9-CM 編碼[22]等;或者取一個不重復的隨機數(shù),例如Freebase[23]知識庫中的對象ID 采用MID(a machine identifier)進行標識,例如ns:m.0c58k 表示“糖尿病”實例的ID,ns 表示Freebase 的默認名稱空間.對于實例的人類可識別名稱和描述,可以通過本體描述語言提供的標注屬性(比如rdfs:label,rdfs:comment)去體現(xiàn).

約定1.在OBdomain中,概念和屬性ID 的命名規(guī)則如下.

· 概念:namespace:domain.concept;

· 屬性:namespace:domain.concept.property.

其中,

· namespace 表示領域的名稱空間(例如med 表示medicine 領域的名稱空間);

· domain 表示領域ID,名稱空間內唯一;

· domain.concept 表示以領域ID 為前綴的概念ID,名稱空間內唯一;

· domain.concept.property 表示以概念ID 為前綴的屬性ID,名稱空間內唯一.

這種命名規(guī)則約定,對于機器處理和人類理解都是有價值的.語義描述的原則是,盡可能清晰明確地描述所有對象的語義(包括語義約束)及與其他對象的語義關系(包括語義約束).圖1(b)為基于約定1 對這些概念間的語義關系的定義,明確給出了屬性的定義域和值域限定,無論對于計算機推理還是人類理解都不會存在歧義.rdf,rdfs,owl分別為本體描述語言RDF,RDFS 和OWL 提供的語義組件定義的名稱空間前綴,med和pp分別為本體Omedicine和本體Opeople的名稱空間前綴,在本體模型的形式化描述中進行聲明.

針對以上的問題3),這里做出如下的本體建模約定.

約定2.如果屬性的定義域所對應的概念定義在某個Odomain中,那么也將該屬性定義在此Odomain中.

約定2 的含義是:無論是數(shù)據(jù)類型屬性還是對象屬性,根據(jù)其定義域所對應的概念所在的本體來確定該屬性定義所在的本體.這樣做的理由是:屬性用于描述概念所代表的實例集合中的實例的特征或者這些實例指向其他概念代表的實例集合中的實例的語義關聯(lián),所以屬性的定義理應與其服務的概念的定義綁定在一起.如圖1(b)所示:將描述概念“人”的疾病和癥狀的屬性定義在Opeople本體中,將描述Omedicine本體中概念的屬性定義也定義在Omedicine本體中.

某些情況下,可能需要通過導入其他本體中的概念,并對其屬性進行擴展,使得屬性定義和其定義域聲明中的概念的定義位于不同的本體中.但通常情況下,在定義某個新的概念時,往往都會同時定義此概念的一些屬性.此時,應盡可能將概念和描述此概念的屬性(以此概念為定義域的屬性)定義在一起,以避免屬性的冗余定義.

2.2 同一實例具有多種類型或角色

健康醫(yī)療領域的專家可能構建如圖2(a)所示的專家視圖,在多個概念的實例定義中同時包含了糖尿病、泌尿道感染等實例.而在本體視圖中,每個實例對象的ID 必須是唯一的,但多個ID 不同的實例對象,在語義上可以是等價的.在本體視圖中,某個實例對象也可以具有多種類型,或者屬于由多種類型通過復雜類[6]構造方法構造的復雜類.

約定3.在專家視圖中,基于不同的語義類型定義了多個相同的實例時,在對應的本體視圖中可以定義一個唯一的實例,并聲明其具有多種語義類型.在進行語義理解或語義推理時,實例對象在具體語境下的語義類型由連接該實例的屬性的定義域或值域的類型來確定.

例如,圖2(a)所示的專家視圖對應的本體視圖如圖2(b)所示,其中,白色橢圓表示類和屬性,灰色橢圓表示實例.下同.

下面為采用Turtle[3]語法描述的Omedicine本體的一個片段.

1.med:medicine.disease.risk_factors rdf:type owl:ObjectProperty;

2.rdfs:domain med:medicine.disease;

3.rdfs:range med:medicine.risk_factor;

4.owl:inverseOf med:medicine.risk_factor.diseases.

5.med:medicine.symptom.symptom_of rdf:type owl:ObjectProperty;

6.rdfs:domain med:medicine.symptom;

7.rdfs:range med:medicine.disease;

8.owl:inverseOf med:medicine.symptom.symptom_of.

9.med:m.07x16 rdfs:label “泌尿道感染”@zh;

10.rdfs:label “Urinary tract infection”@en;

11.rdf:type med:medicine.disease,

12.med:medicine.disease_cause,

13.med:medicine.risk_factor,

14.med:medicine.symptom.

15.med:m.0c58k rdfs:label “糖尿病”@zh;

16.rdfs:label “Diabetes mellitus”@en;

17.rdf:type med:medicine.disease,

18.med:medicine.disease_cause,

19.med:medicine.risk_factor,

20.med:medicine.symptom.

21.med:m.07x16med:medicine.disease.risk_factors med:m.0c58k.

22.med:m.07x16 med:medicine.symptom.symptom_of med:m.0c58k.

第1 行～第4 行為對屬性med:medicine.disease.risk_factors 的定義的一個片段;第5 行～第8 行為對屬性med:medicine.symptom.symptom_of 的定義的一個片段;第9 行～第14 行是對實例med:m.07×16 的聲明,該實例被聲明為了多種類型;第15 行～第20 行是對實例med:m.0c58k 的聲明,該實例也被聲明為了多種類型;第21 行、第22 行是對實例med:m.07×16 和med:m.0c58k 之間語義關系的聲明.基于屬性med:medicine.disease.risk_factors的定義和第21 行中的實例語義關系聲明,可以推理出在第21 行中的實例med:m.07×16 的類型為med:medicine.disease,實例med:m.0c58k 的類型為med:medicine.risk_factor;而基于屬性med:medicine.symptom.symptom_of的定義和第22 行中的實例語義關系聲明,可以推理出在第22 行中的實例med:m.07×16 的類型為med:medicine.symptom,實例med:m.0c58k 的類型為med:medicine.disease.

在執(zhí)行SPARQL 檢索時,語義也是很清晰的.例如,在以上Omedicine的本體片段中,實例med:m.0c58k 被同時聲明為了4 種類型:med:medicine.disease,med:medicine.disease_cause,med:medicine.risk_factor 和med:medicine.symptom.當分別檢索這4 種類型的實例時都會包含med:m.0c58k,這也符合醫(yī)學上的解釋:在醫(yī)學上,糖尿病是一種疾病,同時也是其他疾病的誘因、風險因素和表現(xiàn)癥狀.在基于圖模式執(zhí)行復雜語義關聯(lián)的檢索時,基于實例的類型聲明和屬性的定義域和值域限定,可以檢索出正確的結果.如果語義關系中的實例類型不符合屬性的定義域和值域限定,在本體構建過程中可以通過語義一致性檢查進行正確識別,從而進行修正.例如Protégé 就提供了本體創(chuàng)建過程中的語法和基于推理的語義一致性檢查機制.

在圖2(a)所示的情況中,類似“泌尿道感染”、“糖尿病”這樣屬于多種類型的實例可能并不是很多,大部分病因可能只是一種病因,而不是一種疾病;同樣,大部分癥狀可能只是代表一種癥狀,而不屬于疾病.而有些情況下,幾乎所有實例都可以映射到多種類型下的某種子類型,如圖3(a)所示的專家視圖.在圖3(a)中,運動項目從不同角度進行分類,而羽毛球(單打)、羽毛球(雙打)實例可以映射到每種分類方法中的某個子類中.在此專家視圖中,雖然將運動項目按不同科目類型、不同強度、不同能量代謝類型和不同運動益處進行分類,但它們都屬于運動項目的子類,對于描述運動項目的屬性和語義關系,也并不需要按子類的不同進行區(qū)分.而在圖2(a)所示的專家視圖中,疾病、癥狀、病因和風險因素是完全獨立的一級概念,它們在語義上也是完全不同的.

約定4.在專家視圖中,所有實例都歸屬于同一祖先類下的不同子類時,在對應的本體視圖中,可以將這些子類建模為類型實例,實例對象通過分類屬性連接這些類型實例.

基于約定4,對于圖3(a)所示的專家視圖,可以建立如圖3(b)所示的本體視圖.在如圖3(b)所示的本體視圖中,針對運動項目實例,只建立了一個運動項目一級分類,并將所有運動項目建模為其實例;而將專家視圖中的不同特化(specialization)分類建模為類型實例,同時增加多個對應的分類屬性來連接運動項目實例和這些類型實例.

2.3 同一資源既是類型又是實例

在所有領域的知識中都會存在這樣的情況,即某個資源自身既表示實例又可以作為分類代表更多實例對象的集合.例如在健康醫(yī)療領域,糖尿病和高血壓都屬于典型、多發(fā)的慢性疾病,大多數(shù)時候都表示疾病實例,但糖尿病還可以進一步細分為1 型糖尿病、2 型糖尿病、妊娠糖尿病、糖尿病前期、糖尿病性神經病等多種疾病,如圖4(a)所示的專家視圖.

參考ICD-10 可以知道,1 型糖尿病還可以進一步細分為脆弱型糖尿病、幼年型糖尿病、趨酮癥性糖尿病等疾病.同樣,高血壓等疾病也可以做進一步的細分.

針對以上情形,盡管OWL 提供了這樣的表達能力,但我們需要在表達能力和推理能力上做出平衡.OWL 提供了3 種表達能力遞增的子語言OWL Lite、OWL DL 和OWL Full,以分別用于特定的實現(xiàn)者和用戶團體[3,6].OWL Lite 僅提供用于描述分類關系和簡單約束的語義組件.OWL DL(description logic)包括了OWL 語言的所有成分,但有一定的限制,如類型的分離,即一個類不能同時是一個個體或屬性,一個屬性不能同時是一個個體或類.采用OWL DL 語義組件描述的本體能夠確保語義推理計算的完全性(computational completeness)和可判定性(decidability).OWL Full 具有最強的表達能力和完全自由的RDF 語法,例如,在OWL Full 中,一個類本身可以作為一個個體,并允許一個本體增加預定義的(RDF,OWL)詞匯的含義.但由此帶來的問題是,沒有推理系統(tǒng)能夠支持對OWL Full 所有成分的完全推理.

為了平衡表達能力和推理能力,這里選擇OWL DL 作為本體視圖的描述語言.同時,為了支撐這里的領域知識描述需求,即某個資源自身既表示實例又可以作為分類代表更多實例對象的集合,這里提出了約定5 的領域知識建模方法.

約定5.在專家視圖中,對于自身既表示實例又可以作為分類代表更多實例對象的集合的資源對象,在對應的本體視圖中,將其所在分支的父類、子類及實例對象都建模為最近公共父類的實例,并通過對象屬性表達實例間的分類關系.

基于約定5,對于圖4(a)所示的專家視圖,可以建立如圖4(b)所示的本體視圖.本體視圖將專家視圖中疾病的所有子類及實例都建模為疾病類的實例,并通過對象屬性med:medicine.disease.parent_disease 表達實例的父類(實例),通過對象屬性med:medicine.disease.includes_diseases 表達實例作為類型包含的實例集合.這里,對象屬性med:medicine.disease.parent_disease 和med:medicine.disease.includes_diseases 都是傳遞(transitive)屬性,具有類型owl:TransitiveProperty[3].如果屬性p為傳遞屬性,那么如果存在陳述(ApB)和(BpC),則意味著存在陳述(Ap C).

除了這里的情況以外,在本體視圖中,將一個資源表示為一個概念(即類)還是一個實例,或者將資源建模為實例還是某個數(shù)據(jù)類型屬性的值,這依賴于具體的領域范圍和該本體潛在的應用需求.

如果具有超類(superclass)沒有的附加屬性,或者具有不同于超類的約束,或者參與了與超類不同的語義關聯(lián),這時可以建模新的子類而不是超類的實例[17];如果資源具有很多屬性特征,或者與其他資源存在語義關聯(lián),那么應該將資源建模為實例而不是作為某個數(shù)據(jù)類型屬性的值.

2.4 多元關系的語義映射

在任何領域的知識描述中,都會涉及到對資源的某些量化指標的描述,例如人的身高、體重、體溫、心跳次數(shù)等.在不同的國家和地區(qū),對相同指標的默認指稱單位并不完全一樣,例如在中國,衡量人的身高、體重一般使用米(m)和公斤(kg),而在英國,計量人的身高、體重的單位分別為英寸(inch)和磅(pounds).一些領域專家在建模領域知識時,會假定領域知識的使用區(qū)域或使用者,確信使用此領域知識的使用者會正確推斷出默認的計量單位,從而在表示領域知識時常常省略計量單位,如圖5(a)所示.但在將專家視圖映射為本體視圖并應用到語義Web 中時,這種假定是不成立的,所以必須對計量單位或類似的信息進行明確表述.

另外,在任何領域的知識描述中都存在一些模糊和不確定的知識,例如醫(yī)生對患者疾病的診斷就是一種可能性的判斷,這種可能性的判斷依賴患者主訴的癥狀、體征、檢查、化驗、醫(yī)生經驗等.醫(yī)生在給出診斷結果時,并不能給出這種可能性的大小.健康醫(yī)療大數(shù)據(jù)的出現(xiàn),一些基于數(shù)據(jù)挖掘、機器學習等方法構造的針對單病種或者專病的疾病輔助診斷模型,不但可以提供比單個醫(yī)生(基于大數(shù)據(jù)的疾病輔助診斷模型綜合了更多醫(yī)生的經驗知識)更高的疾病檢出率,而且還能提供鑒別診斷,給出數(shù)值化的患病可能性參考值.本文不探討各種模糊性和不確定知識的建模方法,而是給出這種數(shù)值化關系的語義描述方法.

在本體視圖中,為了描述張三的身高及度量單位,可以在描述身高的屬性的ID 中附上度量單位,比如pp:people.person.height(m),或者在屬性的標注屬性(rdfs:label,rdfs:comment 等)中注明使用的計量單位,或者將身高屬性的值表示為字符串,在字符串中同時表達身高的數(shù)值和單位,例如“1.75m”.對于描述張三與疾病診斷關系的概率值也可以采用類似的方法.這些描述方式對人是可理解的,但卻不是機器可處理的;而且對于不同的度量單位和關系權重(例如描述張三患某種疾病的風險等級),需要分別處理,可擴展性差.

描述身高的數(shù)值和單位組成了一個結構(structure),要描述張三和這個結構的關系,就要涉及到處理一個N元(n-ary)關系[24].在這里N為3,分別是張三、身高數(shù)值和身高單位.要描述張三與診斷關系的概率值,需要一個附加的屬性用于描述這個關系的概率,同樣構成了一個N元關系.而RDF 只能表示二元(binary)關系,為此作出如下的建模約定:

約定6.對于專家視圖中明確描述或隱含的結構化值,在本體視圖中引入N元關系來進行明確表示;使用空節(jié)點(blank nodes)[4,10]或有名資源(具有URIrefs)表示N元關系:對于每一個N元關系,將其切分為一元(作為這個N元關系的主體,比如張三)和N-1 元(比如身高值和計量單位),并創(chuàng)建一個空節(jié)點或有名資源及其相關屬性來進行連接(即描述).如果N-1 元中仍然存在多元關系,可采用相同的方法進行切分和描述.

如圖5(b)所示,分別建立了描述人和描述度量單位的本體Opeople和Omeasurement_unit,這兩個本體定義中的資源ID 對應的名稱空間前綴分別為pp和mm.然后定義了一個Izhangsan(名稱空間為ps),基于Opeople,Omeasurement_unit和Odomain來描述個體張三.圖中創(chuàng)建了3 個空節(jié)點,分別用于描述張三的身高、體重和診斷結果.這里并沒有為空節(jié)點分配URIrefs,但表達了它應該表達的含義即提供了圖中各個部分之間必需的連通作用.這個空節(jié)點本身可能從來不會被從這個RDF 圖的外部引用,因此可能不需要通用的標識符.如果需要被從外部引用,則可以創(chuàng)建有名資源來代替這里的空節(jié)點.但在把RDF 圖序列化成三元組形式的時候,需要空節(jié)點標識符來表示和區(qū)分圖中的空節(jié)點.因此,在三元組表示法中,使用“_:name”形式的空節(jié)點標識符來表示空節(jié)點[4],例如圖 5(b)中的_:height10338,_:weight10245 和_:disease12227.在使用工具程序(例如Apache Jena[25])創(chuàng)建空節(jié)點時,可以指定空節(jié)點標識符,也可以由程序自動生成.

與URIref 和字面值不同,空節(jié)點標識符并不被認為是RDF 圖的一個實際組成部分(因為圖中的空節(jié)點可以沒有空節(jié)點標識符).另外,因為空節(jié)點標識符表示的是空節(jié)點而非弧,所以在一個圖的三元組表達式中:空節(jié)點標識符只能出現(xiàn)在三元組主體和客體的位置上,而不能出現(xiàn)在謂詞的位置上[4].

結構化值中包含兩個或者多個元素,有時領域專家可能想強調某個元素的重要性,例如前面討論領域專家在描述某些量化指標時通常省略其單位,因為領域專家認為指標的值更重要,單位在某個語境中很容易達成共識.這種重要性更多的是一種主觀認識,在領域專家的知識中可能不會特意強調,更多地是一種習慣認識.例如,在描述張三的身高和體重的結構化值中,身高和體重的數(shù)值對結構化值的貢獻最大,而身高和體重的記錄單位用于修飾身高和體重的數(shù)值.在其他類型的結構化值中,可能也存在這樣的情況.

約定7.識別專家視圖中明確描述或隱含的結構化值的主值(main value)[5],在本體視圖中使用RDF 提供的預定義的屬性rdf:value 來描述結構化值中的主值.

盡管rdf:value 本身沒有含義,但RDF 鼓勵這樣使用.如圖5(b)所示,圖中屬性pp:people.diagnosis.value 為屬性rdf:value 的子屬性,以表明診斷結果的重要性.

2.5 訪問授權的語義映射

針對領域中涉及安全、敏感或用戶隱私相關的內容,領域安全專家、信息擁有者(例如醫(yī)院或患者)或信息來源者(例如患者)都可能提出訪問授權的需求.如何基于領域語義知識庫建立此訪問授權的語義映射,是本節(jié)要討論的主題.

所有領域(尤其是醫(yī)療健康、金融等領域)都會涉及到與安全、敏感或用戶隱私相關的內容[19,26].信息共享與隱私保護的目標是共享數(shù)據(jù),同時保護個人身份信息,并確保信息的使用與信息收集的目的相一致.隱私保護的核心是隱私控制,即信息的擁有者是否有權完全控制個人信息(全部或部分)的收集、訪問和共享,并可以要求停止對個人信息的處理.隨著信息化程度的不斷提高,越來越多的組織和個人開始擔心安全和隱私問題,安全和隱私也成為信息化時代需要首先解決的關鍵問題[19].

領域專家在建模領域知識的時候,關心的是盡可能全面、詳盡、準確、一致地表達領域中的知識;但在提供知識服務時,領域安全專家必須要考慮領域知識中顯式存在的涉及安全、敏感或用戶隱私相關的內容的管理和控制問題,或者可能由推理、授權傳播、數(shù)據(jù)集成、數(shù)據(jù)挖掘等過程導致的隱含的安全、敏感或隱私信息泄露問題[19].領域本體定義提供領域中共同認可的知識,一般不涉及安全和隱私問題;而領域實例數(shù)據(jù)描述領域中個體(比如人、組織等)的知識,會涉及到與個體相關的安全、敏感或隱私問題;但領域本體定義為個體的描述提供語義支持,并為個體知識的推理提供背景知識.本體描述語言提供的語義描述組件可能為基于推理和數(shù)據(jù)集成的安全和隱私泄露提供支持.例如,電子郵件地址通常是唯一的,可以唯一標識一個人,所以描述人的電子郵件屬性一般定義為owl:InverseFunctionalProperty 類型的,即一個人可以有多個電子郵件,但一個電子郵件地址可以唯一地確定一個人;一本書的ISBN 號是唯一的,所以書籍的ISBN 屬性通常定義為owl:FunctionalProperty類型的,即一本書可以唯一的確定一個ISBN 號.在語義Web 上,可以通過郵件地址聚合關于某個人的很多信息,通過ISBN 號可以聚合關于一本書籍及其作者的很多信息,從而可能引發(fā)安全和隱私泄露問題.

語義Web 技術提供的知識表示和推理能力可以增強傳統(tǒng)的數(shù)據(jù)安全和隱私保護能力,并為語義Web 本身提供保駕護航.本體模型可以很好地建模領域知識,同樣可以細粒度地捕捉領域安全和隱私保護需求.基于本體建模的領域知識,為發(fā)現(xiàn)顯式的和隱含的安全和隱私保護需求提供了很好的支持.傳統(tǒng)的安全和隱私保護模型采用增量式的實現(xiàn)方法,沒有詳細的、一致的形式化模型,不適用于包含大量涉及安全和用戶隱私敏感信息的系統(tǒng),而本體正好提供了一種可擴展的、靈活的、健壯的形式化模型.使用SWRL 作為安全策略規(guī)范,并基于領域語義知識庫中定義的資源和陳述,可以構建基于語義的安全和隱私保護約束規(guī)則,一方面可以發(fā)現(xiàn)由推理引發(fā)的安全和隱私泄露問題,另一方面可以檢查在策略執(zhí)行上的一致性,避免授權沖突[19].

圖6 為一個本體庫定義的示例,包含Opeople和Omedicine的部分片段,其名稱空間前綴分別為pp和med.

圖中連接概念的屬性除了表達分類關系(rdfs:subClassOf)以外,僅用于聲明屬性的定義域和值域類型,例如屬性pp:people.person.diseases 的定義域為pp:people.person,值域為med:medicine.disease.本體定義中包含的一級概念有數(shù)字對象(電子病歷、醫(yī)療處方等)、人、疾病、癥狀;數(shù)字對象包含患者記錄和醫(yī)療處方兩個二級概念,人包括醫(yī)生、患者、顧問這3 個二級概念;人的主要屬性有身份ID、擁有的數(shù)字對象、患有疾病等.

圖7 為基于圖6 的本體定義構建的實例數(shù)據(jù)示例,分別構建了一個顧問、患者和疾病實例及它們之間的語義關系,描述了患者患有的疾病、擁有的患者記錄和身份ID.

為了實現(xiàn)患者和顧問之間的服務功能,領域安全專家或者患者需要授權顧問(訪問主體)對患者相關健康狀況(訪問客體)的訪問權限,例如允許顧問查看患者的診斷結論、電子病歷或某次影像診斷結果.從傳統(tǒng)的安全視角,訪問主體和訪問客體都是孤立的,它們通過訪問行為建立聯(lián)系.而在領域語義知識庫中,資源之間以及資源和字面值之間都可能存在某種語義關系.與患者相關的信息都和患者存在語義關聯(lián),患者和他/她的顧問之間也可能建立了顯式的顧問/會員關系.構成領域語義知識庫的最小單位是三元組,對語義知識庫的訪問實際就是對某個或某些三元組的訪問,比如張三的診斷、張三的患者記錄等.為此,作出如下的約定.

約定8.基于SKBdomain提供語義知識服務時,將三元組作為最小的訪問控制保護單元,即訪問客體.

領域安全專家或者患者可能為顧問做出如下的授權.

1) 允許顧問李四訪問患者張三的診斷記錄;

2) 允許顧問李四訪問患者張三的患者記錄.

為基于領域語義知識庫建立此訪問授權的語義映射,作出如下的建模約定.

約定9.為基于SKBdomain的三元組建立訪問控制策略規(guī)則,采用RDF 陳述具體化(reification)[4,10]的方法建模和引用三元組.

一條陳述是由客體、謂詞和主體構成的三元組,陳述的RDF 具體化用于表達關于該三元組的附加信息,例如三元組的創(chuàng)建時間、創(chuàng)建人等.RDF 具體化詞匯包括類型rdf:Statement、屬性rdf:subject,rdf:predicate 和rdf:object.RDF 具體化詞匯被設計用于討論陳述本身,即rdf:Statement 的實例.圖8 所示建立了兩條陳述的具體化,med:triple0001a 和med:triple0001b 為陳述實例,通過具體化詞匯分別指向了兩條陳述.陳述實例的ID 可以是有名ID,也可以是無名的空節(jié)點.但為了在訪問控制策略規(guī)則中引用此陳述實例,需要采用有名ID.

為建立授權和許可規(guī)則,作出如下的約定.

約定10.基于本體模型建立授權和許可訪問控制原語,使用SWRL 作為訪問控制策略規(guī)范,建立授權和許可規(guī)則.

基于本體模型建立如圖9 所示的訪問控制原語本體Oaccess_control,即連接人和陳述實例的授權和許可屬性.

ac為訪問控制本體的名稱空間前綴,授權原語有ac:authorizes 和ac:deny,許可原語有ac:permitted 和ac:prohibitted.建立授權和許可兩級訪問控制策略模型,分別對應用戶級和系統(tǒng)級[19].在用戶級,每個用戶可以就個人擁有的資源定制靈活的訪問授權策略規(guī)則.在系統(tǒng)級的策略規(guī)則治理整個系統(tǒng)的安全與隱私策略.由于某些受保護資源可能關聯(lián)多個授權方用戶(比如患者與醫(yī)生或者顧問之間的關系,如果要訪問此關系,需要患者和醫(yī)生或顧問的同時授權),所以需要通過聚合用戶級的授權來判斷是否對受保護的資源提供了合適的授權,也即最終的許可需要通過系統(tǒng)級的策略規(guī)則來授權.授權和許可同時支持肯定和否定,這樣可以簡化訪問控制策略規(guī)則的定義以及解決基于本體知識和規(guī)則推理的授權傳播問題;如果出現(xiàn)授權沖突,否定授權的優(yōu)先級高于肯定授權.

3 應用案例

糖尿病、高血壓等慢性病患者,除了按醫(yī)生指導進行日常的用藥治療以外,合理的飲食、適量的運動作為生活方式,對控制血糖、血壓等指標同樣非常重要.例如,經常有規(guī)律的運動不僅可減少2 型糖尿病的發(fā)生率,還可降低血糖,提高胰島素敏感性,延緩其慢性并發(fā)癥的發(fā)生和發(fā)展.但并不是所有慢性病患者都適合做運動,即使適合做運動,還需要考慮適合做多大強度的運動、適合做什么類型的運動、適合什么時間做運動、每次運動的持續(xù)時間、運動的注意事項(比如可能需要考慮與藥物、飲食的配合,運動環(huán)境和裝備等)等.運動對糖尿病的防治效果是肯定的,但糖尿病患者運動也有風險,安全有效的運動需要配合調節(jié)飲食和用藥[27].著名的Joslin 紀念章用“胰島素、運動和飲食三駕馬車”來表示成功地治療糖尿病的3 個主要方面[28].

本節(jié)采用本文提出的5 類語義映射方法構建了一個健康醫(yī)療領域的語義知識庫,用于向慢性病患者推薦個性化的干預方案(飲食處方、運動處方等).當然,這5 類映射方法并不受限于該特定的領域或應用場景,而是針對幾乎在所有領域中都存在的共性問題的解決方案,所以適用于所有類似的應用場景.

3.1 領域本體庫的構建

為了支撐向慢性病患者推送個性化的干預方案應用的問題求解需求,這里基于本文提出的語義映射方法約定來將專家知識映射為基于本體和語義Web 規(guī)則語言描述的領域知識.領域專家知識EKBhealthcare來源于以下幾個途徑.

· 醫(yī)療健康領域的標準術語集,例如ICD-10,ICD-9-CM,Snomed CT[29],Mesh[30],UMLS[31]等;

· 公開知識庫,例如OpenGallen[32],Freebase,OBO[33],OBI[34]等;

· 公開項目,例如K4CARE[35],PIPS[36]等;

· 論文文獻[36-39]和專業(yè)著作[27,28];

· 網(wǎng)絡資料;

· 專家貢獻等.

例舉的多個標準術語集中,主要都是一些概念分類體系,而沒有實例以及實例之間的語義關系.由于不同標準術語集誕生的背景和應用場景的不同,它們中的一些概念分支存在重疊,但又不完全一樣,例如,關于疾病、癥狀、運動設施等的分類體系有部分重疊.而且部分概念同時出現(xiàn)在多個分支,但表達的語義不一樣.為此,由醫(yī)學專家針對本文的應用場景對其進行了整合.

在列舉的幾個公開知識庫中,除了Freebase 以外的幾個知識庫仍然以概念分類體系為主,而Freebase 正好相反,只有一級概念,以實例關系為主,實例關系主要用于表達領域常識知識,例如某個疾病的主要表現(xiàn)癥狀、誘因、風險因素等.同時,Freebase 知識庫中還包含了度量單位、位置領域的知識.

在例舉的幾個公開項目中,K4CARE 項目中定義的CPO(case profile ontology)本體用于描述患者病情概況所需要的知識,比如癥狀、體征、疾病、綜合征、社會問題等及其語義關系,其中,疾病僅僅涵蓋了一些慢性病.PIPS 項目中創(chuàng)建了疾病(doid.rdf)、臨床記錄(PIPSClinicalRecord.owl)、食物(PIPSFood.owl)、菜單(PIPSMenu.owl)、菜譜(PIPSRecipe.owl)、個人概況(PIPSPerson.owl)等本體,但主要是概念分類體系.

列舉的論文文獻和專業(yè)著作主要用于提供運動、飲食相關的專家知識,也從網(wǎng)絡上收集了一些資料.

為此,基于本文提出的語義映射方法,由醫(yī)學專家參與,針對本文的應用場景對幾個來源的概念體系進行了整合,實例數(shù)據(jù)主要參考Freebase 知識庫(并保留了實例數(shù)據(jù)的MID)、K4CARE 項目和相關文獻.除了Freebase知識源以外,其他標準術語集、知識庫和公開項目中的知識均為英文描述.Freebase 知識庫中的資源對象,其標注屬性采用了20 多種語言分別進行描述.Freebase 知識庫中的所有資源對象都具有英文描述,但只有約一半的資源對象具有中文描述.為此,在建立領域語義知識庫時,對于參考的英文素材,在保留英文描述的同時,還采用翻譯工具對其進行了中文翻譯,并由醫(yī)學專家對其進行了校對.對于醫(yī)學專家補充的知識,只有中文描述.

領域本體庫OBhealthcare的定義如下:

各個子本體說明如下.

1)Omedicine用于定義醫(yī)療健康領域的相關概念(例如疾病、癥狀、檢查、藥物、手術、解剖結構、病因、醫(yī)療設備等)及其屬性(例如疾病概念包含的部分屬性有疾病表現(xiàn)的癥狀、疾病適用的藥物、疾病病因、疾病并發(fā)癥、疾病包含的子疾病、疾病歸屬的父疾病等);

2)Opeople用于定義與人相關的概念(例如人、人群、孩子、父母、兒子、女兒、父親、母親等)及其屬性(例如人的部分屬性有性別、出生日期、身高、體重、有身體殘疾、有身體損傷、感興趣/適合/不適合的運動、感興趣/適合/不適合的飲食等);

3)Ofood用于定義與食材、食譜相關的概念(例如食材、食譜、中醫(yī)功效、營養(yǎng)素、堅果種子、奶、水產、水果、油脂、糖品、肉等)及其屬性(例如食材包含的營養(yǎng)素、食材功效、食材適宜攝入量、食材推薦攝入量、營養(yǎng)素計量單位、營養(yǎng)素參考值等);

4)Oexercise用于定義康復運動相關的概念(例如運動項目、運動設備、運動強度、能量代謝類型、運動益處等)及屬性(例如運動項目需要的運動設備、運動項目包含的子運動項目、運動項目歸屬的父運動項目、運動項目的能量代謝類型、運動項目的運動強度、運動項目的運動益處、運動項目的鍛煉部位、運動項目依賴的運動場地等);

5)Omeasurement_unit包含度量相關的概念(例如長度單位、質量單位、時間單位、貨幣單位等)及其屬性(例如長度計量單位、長度計量單位的標準縮寫等);

6)Olocation包含地理位置、場所相關的概念(例如地址、郵編、洲、國家、省、市、縣、鎮(zhèn)、場所、部門等)及其屬性(例如編碼、名稱、包含關系、隸屬關系等).

領域本體庫OBhealthcare中的主要概念及其屬性關系如圖10 所示,其中,橢圓表示概念,帶箭頭的連線表示屬性,箭頭源端連接的概念表示該屬性的定義域,箭頭目的端連接的概念表示該屬性的值域.

在定義各個子本體時遵循的約定見表1.

Table 1 Conventions followed by the domain ontology library definitions表1 領域本體庫定義遵循的約定

對于表達一般性領域常識知識的實例數(shù)據(jù),這里直接定義在對應的領域本體中了,例如疾病實例、癥狀實例、藥物實例、手術實例、解剖結構實例等及這些實例間關系的定義都直接定義在本體Omedicine中了;不同類別的食材實例及其屬性的定義(例如包含的營養(yǎng)素、功效等)直接定義在本體Ofood中了;不同類別的運動實例及其屬性的定義(例如運動項目的強度、能量代謝類型、益處、技術結構等)直接定義在本體Oexercise中了;度量單位實例及其屬性的定義直接定義在本體Omeasurement_unit中了;位置相關的實例及其屬性的定義直接定義在本體Olocation中了.在定義領域常識知識時遵循的約定見表2.

Table 2 Conventions followed by the domain commonsense knowledge definitions表2 領域常識知識定義遵循的約定

以Turtle RDF[40]表示的領域語義知識庫的文件(擴展名為.ttl)大小約為1.8GB,知識庫中包含144 個概念、82 個數(shù)據(jù)類型屬性、166 個對象屬性、888 308 個實例和7 076 316 個三元組.

該知識庫的規(guī)模和內容可以滿足臨床科研、臨床診療、健康管理中一些基本的知識服務需求,例如提供數(shù)據(jù)的共享與互操作服務.在健康醫(yī)療領域中,同一種疾病、同一種癥狀等在不同醫(yī)療機構可能有不同的描述方法,甚至在同一醫(yī)療機構也存在許多不同的描述方法.這些不同描述方法與標準描述方法的歸一化是一項知識密集型、時間密集型的工作.但此項工作不解決,領域知識庫的作用便不能得到有效地發(fā)揮.為向領域應用提供智能知識服務,還需要結合特定領域的問題求解需求,補充問題求解知識,知識的形態(tài)可以是語義Web 規(guī)則集(參見第3.3 節(jié))、算法、模型等.

3.2 領域實例庫的構建

為了對知識庫在問題求解上的可滿足性進行驗證,這里以推薦個性化運動處方場景為例,分別定義了3 個個體的實例數(shù)據(jù),即個體張三、李四、王二的實例數(shù)據(jù),包括他們的基本信息(性別、年齡、身高、體重)、健康狀況(患病情況、殘疾情況、損傷情況)、興趣愛好(運動、飲食等)、日常體力活動水平、生活習慣、具有的運動條件(場地、設備、經濟條件等).領域實例庫IBhealthcare定義如下:

在定義個體實例數(shù)據(jù)時遵循的約定見表3.

Table 3 Conventions followed by the individual instance data definitions表3 個體實例數(shù)據(jù)定義遵循的約定

在使用Protégé 定義對象屬性的值域、實例間的語義關系和個體實例數(shù)據(jù)時,需要引用或導入(owl:imports)關聯(lián)本體中的概念和實例,本體間的引用關系如圖11 所示.在基于專家知識構建的運動推薦模型中,個體的這些實例數(shù)據(jù)的作用見表4.

Table 4 Roles of individual instance data in the exercise recommendation model表4 運動推薦模型中個體實例數(shù)據(jù)的作用

3.3 領域語義規(guī)則集的定義

任何基于知識的系統(tǒng),其知識庫至少由兩個基礎部分組成:靜態(tài)領域知識和動態(tài)推理知識[1].靜態(tài)領域知識描述領域明確的靜態(tài)知識;動態(tài)推理知識又稱為問題求解知識,問題求解知識從抽象層描述問題求解方法所需要的知識,也就是關于如何滿足需求的知識,它描述了要實現(xiàn)的目標、實現(xiàn)這些目標必要的行為、這些行為的激活順序以及執(zhí)行這些行為所需要的領域知識.領域知識會影響問題求解知識,而問題求解方法可以用于指導獲取靜態(tài)領域知識.為此,本體視圖僅僅在語義上準確反映專家視圖還不夠,還需要從滿足領域應用問題求解的角度,調整本體視圖中包含的對象類型、數(shù)量及其組織方式的合理性,或者補充問題求解所需要的知識.

基于表4 可以知道:為了問題求解的需要,即為了描述推薦模型(運動推薦模型、飲食推薦模型等),還需要基于SWRL 構建動態(tài)推理規(guī)則集Fhealthcare.例如在運動推薦模型中,基于個體的實例數(shù)據(jù)和推理規(guī)則,判斷患者是否適合做運動;如果適合做運動,是否需要做運動耐量實驗,適合多大強度的運動;基于身體殘疾、損傷、日常體力活動水平、興趣愛好、生活習慣、運動條件等因素判斷適合個體的最佳運動項目.

SWRL 規(guī)則有3 種不同的語法[3,20]:抽象語法(abstract syntax)、XML 具體語法(XML concrete syntax)以及RDF 具體語法,其中,XML 具體語法基于OWL XML 表示語法和RuleML XML 語法.但采用這幾種SWRL 語法對規(guī)則進行序列化描述時,語句非常冗長,人類不容易閱讀.于是,在規(guī)則表示中,經常使用一種相對非正式的“人類可讀的”語法形式[20]:

一個SWRL 規(guī)則包含了一個前提(antecedent)部分和一個結論(consequent)部分,前提又稱為規(guī)則體(body),結論部分又稱為規(guī)則頭(head).規(guī)則體和規(guī)則頭可以只有一個原子公式(atomic formula),或者是多個原子公式的合取(conjunction),其表示形式如下:

一個SWRL 規(guī)則可以這樣理解:如果在前提中的所有原子是真實的,那么結果也必須是真實的.一個原子的表示形式為

p是謂詞符號,arg1,arg2,…,argn是術語或表達式的參數(shù).在SWRL 中,謂詞符號包括OWL 類、屬性、數(shù)據(jù)類型或內置原語(builtin primitives)等.參數(shù)可以是OWL 實例、數(shù)據(jù)值或者引用它們的變量.

另外,在本應用場景中,將個體的年齡、患病情況、殘疾情況、損傷情況、經濟條件等識別為個體的敏感和隱私數(shù)據(jù),為實現(xiàn)對這些數(shù)據(jù)的訪問控制,首先需要建立用于授權和許可規(guī)則的訪問控制原語本體Oaccess_control,參見圖9.然后將識別出的敏感和隱私保護內容映射為領域實例庫中的三元組,如圖7 所示.然后在訪問控制本體中將這些受保護的三元組具體化為陳述對象,如圖8 所示.最后,基于訪問控制需求、陳述對象和訪問控制原語建立相應的訪問控制策略規(guī)則Faccess_control,這個過程中遵循的約定見表5.

Table 5 Conventions followed by the definitions of the data security and privacy protection model表5 數(shù)據(jù)安全和隱私保護模型定義遵循的約定

最終形成的領域語義知識庫SKBhealthcare定義如下:

3.4 案例實現(xiàn)

Protégé 和Jena 都提供了對本體標準描述語言很好的支持,應用中的本體視圖采用Protégé 4.3 進行構建,將每個本體和實例數(shù)據(jù)分別存儲到不同的文件中,并以Turtle 語法格式進行表示,文件擴展名為.ttl.

原型系統(tǒng)基于Jena 2.12.0 語義Web 編程框架實現(xiàn),使用Jena 提供的命令行工具tdbloader 將領域本體庫和實例庫加載到名為healthcare 的TDB[41]存儲中,TDB 版本為TDB 1.1.0.

Jena TDB 是一個高性能的RDF 專用存儲.

使用Jena 通用規(guī)則引擎[42]提供的規(guī)則語法格式來描述領域規(guī)則集,并存儲到擴展名為.rules 的規(guī)則文件中,運動處方推薦模型包含51 條規(guī)則,部分規(guī)則如下.

· 規(guī)則文件中,“@include 〈RDFS〉”表示導入規(guī)則推理所需要的RDFS 規(guī)則集;

· 每條規(guī)則中,“:”前為規(guī)則名,可選;“→”表示規(guī)則的方向,這里為前向規(guī)則(forward rule),方向的左邊表示規(guī)則體,即推理條件,右邊表示規(guī)則頭,即推理結論;

· 規(guī)則體和規(guī)則頭中的多個項(term)之間使用逗號分隔,每個項可以是一個三元組模式或者Jena 規(guī)則引擎的內置原語,這里用斜粗體表示內置原語,用于提供一些通用的計算功能;

· 三元組模式中包含變量(?person,?value等)、本體描述語言語義組件、SKBhealthcare中定義的語義組件.

Jena 通用規(guī)則引擎可用于實現(xiàn)RDFS,OWL 推理以及通用目的的推理,提供了正向鏈接推理、反向鏈接推理和混合執(zhí)行模式.本體推理、規(guī)則推理和應用的執(zhí)行邏輯如圖12 所示.本體推理基于領域本體庫中的語義組件(即資源)進行推理,例如基于類和屬性的分類關系、類和屬性的約束(例如復雜類構造中的實例值約束、存在限定、完全限定;屬性的取值約束、基數(shù)約束、定義域和值域約束)[3,6,10]、屬性的特征(傳遞性、對稱性、非對稱性、自反性、非自反性、函數(shù)屬性、逆函數(shù)屬性)[3,6,10]等;規(guī)則推理基于語義知識庫和規(guī)則體中的條件模式進行推理,如果滿足規(guī)則體的條件,那么得出規(guī)則頭的陳述結論,作為蘊含的知識和領域本體庫、領域實例庫中的顯式知識一起作為可查詢的領域語義知識庫.

基于領域本體庫和領域實例庫中定義的顯式知識和基于本體推理與規(guī)則推理得到的蘊含知識,執(zhí)行SPARQL 查詢得到的張三的個性化運動處方推薦示例如圖13 所示.首先基于個體的實例數(shù)據(jù)和運動評估模型,判斷個體是否適合做運動;如果適合做運動,進一步判斷是否需要做運動耐量實驗;然后,基于個體實例數(shù)據(jù)、評估結果和領域語義知識庫推薦個性化的運動處方,包括適合的運動項目、適合的運動強度、運動頻率、適合的運動進行時間、適合的運動持續(xù)時間和運動注意事項.

4 方法評價

目前,相關研究工作還沒有深入討論本文提出的語義映射問題,也沒有給出相應的語義映射方法.本文的研究動機和內容完全是基于實踐中遇到的一部分問題,這些問題在相同領域的其他實踐中以及其他領域中也都會遇到,屬于共性問題.這些問題如果不解決,本體工程也得不到很好的實施和落地.

第3.1 節(jié)的應用案例覆蓋了本文提出的5 類語義映射方法,當然,針對其他應用案例可能還會遇到其他需要解決的語義映射問題.基于本節(jié)提出的領域應用需求和本文提出的語義映射方法建立了領域語義知識庫.基于領域應用的問題求解需求補充了領域語義規(guī)則集.通過向規(guī)則引擎?zhèn)鬟f個體實例數(shù)據(jù)(已知條件,也是顯式知識)、領域語義知識庫(顯式知識)和領域語義規(guī)則集,獲得推理結果(隱式知識).最后,基于SPARQL 查詢以獲得個體的運動、飲食等干預方案.案例實現(xiàn)結果可以成功獲取個體的運動處方.從推薦結果上看,干預計劃完全符合個體的身體狀況和干預需求.當然,推薦結果的好壞不僅僅是一個方法的問題,還涉及到領域語義知識庫的規(guī)模和質量,尤其是面對具體應用場景的問題求解知識的科學性和正確性.基于知識的智能決策支持系統(tǒng)依賴領域專家和知識工程師的密切配合,以及適當?shù)姆椒ā⑹侄魏凸ぞ叩闹?

5 相關工作

目前,相關工作主要集中在以下幾個方面.

1) 為知識工程師或者領域專家提供方便的本體編輯工具.

近年來,隨著本體的應用范圍越來越廣泛,已經出現(xiàn)了很多本體構建工具,例如Protégé,OntoEdit,KAON 等,本體構建工具為用戶提供了友好的圖形化操作界面,并通過集成語義推理引擎提供了本體構建過程中的語義一致性檢查機制.借助這些工具,用戶不必了解本體描述語言的細節(jié),就可以方便地構建本體.而且,通過本體構建工具集成的語法和語義一致性檢查機制,避免了很多錯誤的發(fā)生[43].

以上這些工具僅僅提供了本體的輔助編輯功能,可以方便本文討論的語義映射結果的創(chuàng)建和輸入,但并未提供具體的本體建模方法.或者說,在使用這些本體編輯工具之前,需要事先在紙面上或者頭腦中形成需要的本體模型,然后借助這些工具進行方便地形式化.

2) 從本體工程或本體論的角度提出本體建模的一些方法學.

文獻[44]介紹了用于創(chuàng)建企業(yè)本體的IDEF5 方法、骨架法以及用于創(chuàng)建領域本體的七步法以及TOVE,Methontology 等通用本體創(chuàng)建方法.這些本體建模方法只提供本體建模的基本步驟和指導方針.

本體與面向對象對客觀世界的認識方法有許多相似之處,可以借助面向對象的建模方法來建模本體.文獻[11]從UML 的靜態(tài)模型和動態(tài)模型兩個方面研究了本體的面向對象建模方法.文獻[12]通過UML 的類圖來描述環(huán)境領域的本體模型,并提出了一種從UML 類圖各元素到本體OWL 描述各元素的轉換方法,詳細闡述了從本體模型到OWL 描述邏輯的轉換過程和轉換規(guī)則.

面向對象的本體建模方法主要是通過類圖描述本體中的概念、屬性和關系,但是由于領域知識體系的復雜性,類圖這種簡單的結構難以建模概念屬性繁多、關系錯綜復雜的本體.因此,研究者們利用層次結構中層次結構清晰簡潔的特點,通過層次建模方法對復雜本體進行建模.文獻[13]提出了領域本體建模的4 層模型,通過領域層、分類層、類層和實例層這4 個層次構建領域本體.其中:領域層表示領域本體的領域名稱,由領域專家定義的領域分類組成;分類層包括該領域的具體分類項;類層由各應用領域的類組成,每個類包括類名、屬性集合和操作集合;實例層由各應用領域的實例組成,每個實例包括實例所屬類的名稱、屬性集合和操作集合.文獻[14]中提出了領域本體自頂向下建模的5 層模型,用于自適應Web 系統(tǒng)的本體建模.5 層框架中包括數(shù)據(jù)層、概念層、用戶層、自適應層和表示層,其中:數(shù)據(jù)層包括所有松散的Web 數(shù)據(jù)單元;概念層包括由數(shù)據(jù)層的數(shù)據(jù)單元抽象而來的概念與概念之間的關系;用戶層包括用戶訪問Web 的方式及行為的信息;自適應層包括Web 中的自適應規(guī)則和邏輯規(guī)則;表示層包括Web 系統(tǒng)內容和結構的信息.

除了以上較通用的一些方法學以外,還有一些針對具體問題域或領域的領域語義知識庫構建的方法學研究.文獻[45]從本體論的角度出發(fā),探討了幾何學知識的獲取及表示方法,然而僅簡單描述了幾何學本體的結構,列舉了部分屬性和關系,識別了一些簡單的公理,并未清晰完整地給出幾何學知識中的每類對象的本體描述方法,也未針對幾何學本體知識在用于問題求解時可能需要補充的語義規(guī)則集進行討論.文獻[46]提出了基于OWL 本體與Prolog 規(guī)則的平面幾何知識庫的構建方法,用Protégé 和Prolog 構建了一個基于本體和規(guī)則的平面幾何知識庫,但還都是一些簡單對象的語義映射.文獻[47]設計了一個本體制導的基于問題框架方法的需求建模過程,為需求分析員提供建模指導并規(guī)范其建模活動.

文獻[15,16]對幾種面向具體學科領域或工程問題的本體建模方法進行了比較.以上本體建模方法或者只是提供基本的步驟和簡單的指導原則,或者基于面向對象和層次化建模的思想提供了識別領域中類、類屬性及類之間關系的方法,或者討論了本體在特定領域中的一些應用,但僅僅構建了一些簡單的類和實例對象.均未提及本文討論的深層次語義映射問題.

3) 如何從領域數(shù)據(jù)源中半自動或自動地構建垂直領域語義知識庫或知識圖譜.

目前公認領域本體的開發(fā)需要領域專家的參與,但由于領域知識體系的復雜性,完全由人工構建幾乎是不可能的,并且在時間上也是不可接受的.因此,如何利用知識獲取技術來降低本體構建的開銷,已成為一個非常活躍的研究方向,相關技術被稱為本體學習(ontology learning)技術[43,48-50].本體學習,又稱為本體獲取(ontology acquisition),即采用自然語言處理、統(tǒng)計分析、機器學習等技術自動或半自動地從領域數(shù)據(jù)中獲取領域知識,并基于本體進行描述.領域數(shù)據(jù)的類型多種多樣,不同類型的數(shù)據(jù)可能需要采用不同的本體學習方法,可以按領域數(shù)據(jù)的結構化程度將現(xiàn)有的本體學習技術大致分為基于結構化數(shù)據(jù)的本體學習技術、基于半結構化數(shù)據(jù)的本體學習技術和基于非結構化數(shù)據(jù)的本體學習技術.文獻[43]對現(xiàn)有的本體學習技術和學習工具進行了調查.由于實現(xiàn)完全自動的知識獲取技術還不現(xiàn)實,整個本體學習過程還是在用戶指導下進行的一個半自動的過程.本體學習中的很多技術都依賴于對自然語言的處理,所以本體學習工具具有很強的語言特征,目前還沒有一個能夠很好地支持中文的本體學習工具.雖然目前已經提出了很多本體學習方法,但大部分方法都不理想.目前的本體學習工具的功能都非常有限,它們都僅能處理某些類型的數(shù)據(jù)源,獲取某些本體學習對象,例如,將關系數(shù)據(jù)庫中的表映射為本體模型中的概念,將表字段映射為概念的屬性,將字段值映射為屬性值等.文獻[3]也探討了如何將基于XML 的Web 服務、關系數(shù)據(jù)庫以及其他類型數(shù)據(jù)源映射為RDF 模型,但也是提取一些簡單的對象和關系.

近年來,對知識圖譜技術[51,52]的研究越來越受到關注.知識圖譜是結構化的語義知識庫,其描述方法同基于本體的知識表示模型.知識圖譜可以用于支撐語義搜索、智能問答、知識推理等智能化、精準化的應用.各個垂直領域存在大量結構化、半結構化和非結構化的數(shù)據(jù),如何發(fā)揮這些數(shù)據(jù)的價值,一種最可行的解決方法就是建立面向垂直領域的知識圖譜,用于支撐垂直領域的語義搜索、數(shù)據(jù)集成、數(shù)據(jù)分析等智能化的應用.華東理工大學的阮彤教授就垂直領域的知識圖譜,面向圖書館、證券、醫(yī)療等行業(yè)做了部分探索[53-56],其研究工作聚焦在如何迭代式構建領域本體(即領域本體Schema 定義)、如何從行業(yè)擁有的多種中文數(shù)據(jù)源(例如關系數(shù)據(jù)庫、文本、網(wǎng)頁等)中自動或半自動地抽取出結構化的領域知識(即領域實例數(shù)據(jù)定義)、如何實現(xiàn)異源數(shù)據(jù)的融合(即本體映射)等.

本體學習中的領域數(shù)據(jù)源往往并不是專家整理后的知識,而是一些面向業(yè)務過程的數(shù)據(jù)或者面向領域教育的素材.所以,現(xiàn)有的本體學習技術和工具還沒有深入探討本文提出的語義映射問題.

4) 通過本體集成和本體映射對現(xiàn)有的本體進行復用.

由于本體具有的強大的知識表示和推理能力,已經出現(xiàn)了很多基于本體構建的領域語義知識庫.現(xiàn)有的本體構建方法[15-17]都強調在基于本體構建領域語義知識庫之前,考慮集成和復用已經存在的領域本體庫.一方面,因為構建領域本體庫的目的本身是為了領域知識的共享、集成和復用,通過集成和復用已有的領域本體庫,既體現(xiàn)了這個目的的價值,也有利用所構建的領域知識庫的共享、集成和復用;另一方面,通過集成和復用已有的領域本體庫,在此基礎上進行修訂和擴展,可以幫助快速構建滿足領域應用問題求解需求的新的領域本體庫,例如通過本體集成(ontology integration)[57]和本體映射(ontology mapping)[58]的方法來快速構建所需要的領域本體知識庫.本體集成是指在建立一個新本體時重用其他現(xiàn)有的本體,大多數(shù)本體的創(chuàng)建都重用了已有的其他本體;本體集成通過本體擴展(ontology extension)構建新的本體.

本體映射又稱為本體對準(ontology alignment)[3,59],本體映射是指通過對兩個本體進行語義的聯(lián)系,實現(xiàn)將源本體的實體(即資源)映射到目標本體實體上的過程;本體映射通過本體比較(ontology comparison)將兩個或多個本體歸并或合并為一個本體.本體集成和本體映射企圖復用已有的本體快速構建新的領域本體,以滿足領域應用的知識需求.本體集成過程會基于領域知識對復用的本體內容進行調整、修正和擴展,本體映射過程也會參考領域知識實現(xiàn)資源間語義的對準和修正,但現(xiàn)有的研究更多的強調對復用本體的處理,并未涉及本文的研究工作.

6 總結和進一步的工作

本文從具體實踐中識別了5 類語義映射的共性問題,對其進行了討論,提出了對應的解決方案.然后,通過一個完整的應用案例對這5 類語義映射方法進行了驗證,證明了其可用性.這5 類語義映射問題在所有領域中都存在,這里提出的語義映射方法也適用于各種類似的應用場景.語義映射的結果最終會用于領域問題的求解,所以還需要根據(jù)具體應用場景補充問題求解知識.問題求解結果的好壞取決于很多因素,例如語義映射方法的正確性、領域語義知識庫的規(guī)模和質量、面對具體應用場景的問題求解知識的科學性和正確性等.

除了本文討論的幾個語義映射的通用問題以外,在不同領域的各種應用場景中還存在很多其他需要解決的語義映射問題或建模方法問題,例如各個領域中都存在大量模糊的和不確定性的知識,如何對這些知識進行準確的語義建模和語義推理,是一個值得研究的共性問題.對于此類問題,現(xiàn)有的研究主要分為兩類:從邏輯層面通過引入模糊邏輯對描述邏輯進行擴展,形成模糊描述邏輯;從本體描述語言層面對領域本體進行模糊擴展,形成模糊本體.但這兩類研究都存在很多不足,需要深入探討.