語義網(wǎng)絡(luò)環(huán)境下的本體存儲(chǔ)管理

語義網(wǎng)絡(luò)環(huán)境下的本體存儲(chǔ)管理

0查詢和管理的效率隨著意義網(wǎng)絡(luò)中資源的增加，對(duì)象的規(guī)模和結(jié)構(gòu)變得越來越復(fù)雜。在這一點(diǎn)上，閱讀和管理作品的效率已成為一個(gè)普遍關(guān)注的問題。如何在本體存儲(chǔ)管理系統(tǒng)中合理地存儲(chǔ)大規(guī)模的本體,支持高效的本體的管理是一件很有意義且具有挑戰(zhàn)性的任務(wù)。1基于系統(tǒng)分析模型的數(shù)據(jù)庫存儲(chǔ)管理信息數(shù)據(jù)庫在國(guó)內(nèi)隨機(jī)應(yīng)用狀況在一語義網(wǎng)的應(yīng)用需求促進(jìn)Ontology存儲(chǔ)管理工作的發(fā)展,目前已經(jīng)出現(xiàn)了很多Ontology存儲(chǔ)管理系統(tǒng),按照存儲(chǔ)介質(zhì)不同可以分為基于主存、基于文件系統(tǒng)、基于關(guān)系數(shù)據(jù)庫三類本體管理系統(tǒng)。1.1結(jié)構(gòu)式數(shù)據(jù)庫用戶數(shù)據(jù)查詢和管理數(shù)據(jù)的模塊這一類的Ontology數(shù)據(jù)管理工作的特點(diǎn)是將Ontology數(shù)據(jù)全部導(dǎo)入內(nèi)存,按照某種結(jié)構(gòu)進(jìn)行組織;在內(nèi)存結(jié)構(gòu)上執(zhí)行數(shù)據(jù)的查詢操作。此方法具有很高的運(yùn)行效率,但只能處理有限規(guī)模的數(shù)據(jù)。由于是內(nèi)存數(shù)據(jù)管理,不存在磁盤更新的問題。OWLim和OWLJessKB是兩個(gè)典型的基于主存的Ontology存儲(chǔ)管理系統(tǒng)。1.2在文件格式上進(jìn)行業(yè)務(wù)協(xié)同基于文件系統(tǒng)的存儲(chǔ):該方式實(shí)現(xiàn)起來比較簡(jiǎn)單,很多本體相關(guān)工具都支持對(duì)文件格式的本體進(jìn)行存取。但是,這種方法不僅效率低,而且很難適應(yīng)數(shù)據(jù)量較大的情況。基于文件系統(tǒng)的存儲(chǔ)方式一般只適用于規(guī)模比較小的本體,對(duì)于規(guī)模比較大的本體需要大量的內(nèi)存管理工作,而對(duì)于直接以XML格式這樣子一種樹形結(jié)構(gòu)組織的文件來表示的RDF數(shù)據(jù),當(dāng)文件很大時(shí),要把握RDF模型數(shù)據(jù)全局的結(jié)構(gòu),必須通過對(duì)文件進(jìn)行反復(fù)的掃描,大量的數(shù)據(jù)換進(jìn)換出工作,對(duì)系統(tǒng)的效率是一個(gè)很大的考驗(yàn)。而且為了保證系統(tǒng)的并發(fā)性,必須要建立相關(guān)的并發(fā)控制和事務(wù)管理系統(tǒng)。早期的一些Ontology數(shù)據(jù)管理工作是基于文件系統(tǒng)實(shí)現(xiàn)的,它們用簡(jiǎn)單的文件格式存儲(chǔ)Ontology數(shù)據(jù)并支持一些基本的操作。這類工作主要用來編輯和建立Ontology,并不是為大規(guī)模Ontology數(shù)據(jù)的存儲(chǔ)和查詢管理服務(wù)的,例如OntoEdit,Protégé。另外一些Ontology數(shù)據(jù)管理工作基于文件系統(tǒng)建立Native的Ontology數(shù)據(jù)管理系統(tǒng):設(shè)計(jì)專門的存儲(chǔ)模式,并基于Native存儲(chǔ)實(shí)現(xiàn)Ontology數(shù)據(jù)查詢等管理操作。Kowari是一個(gè)典型的NativeOntology數(shù)據(jù)管理系統(tǒng),它在存儲(chǔ)設(shè)計(jì)中利用數(shù)據(jù)冗余提高查詢效率。1.3nting信息管理用關(guān)系數(shù)據(jù)庫存取本體,關(guān)系數(shù)據(jù)庫技術(shù)發(fā)展成熟,關(guān)系模式容易建立查詢、便于事務(wù)處理、便于備份,充分的關(guān)系技術(shù)支持,大多數(shù)現(xiàn)有的Ontology數(shù)據(jù)管理工作使用關(guān)系或?qū)ο?關(guān)系數(shù)據(jù)庫管理系統(tǒng)作為后臺(tái)存儲(chǔ),代表系統(tǒng)包括Sesame,Rstar,Jena,3store等等?；陉P(guān)系數(shù)據(jù)庫存儲(chǔ)Ontology可能有多種模式設(shè)計(jì),現(xiàn)有的包括早期的水平表模式、垂直表模式、分解表模式、混合表模式和后來廣泛為Ontology數(shù)據(jù)管理系統(tǒng)采用的SesameforRDB存儲(chǔ)模式及SesameforORDB存儲(chǔ)模式。1.3.1模式2:通用表1階段,現(xiàn)有數(shù)據(jù)庫表1從自然更新模式到多表混合模式該模式只在數(shù)據(jù)庫中保留一張通用的表,這個(gè)對(duì)象擁有多少屬性,存儲(chǔ)它的表就要有多少字段。表中的列是本體中的屬性,本體中的每個(gè)實(shí)例都是該表中的一個(gè)記錄。文獻(xiàn)提到了這種存儲(chǔ)模式。這種存儲(chǔ)模式比較簡(jiǎn)單,但是該通用表包含了大量的列,進(jìn)行查詢操作會(huì)比較方便,但是也存在如下的問題:一是字段數(shù)目太多,目前的數(shù)據(jù)庫系統(tǒng)對(duì)一張表擁有的字段數(shù)目都加以限制,如DB2和Oracle中都限制數(shù)據(jù)庫的字段數(shù)目最多為1012個(gè),這對(duì)很多大型Ontology來說是遠(yuǎn)遠(yuǎn)不夠的;二是數(shù)據(jù)庫的表結(jié)構(gòu)很稀疏,本體中類的每個(gè)實(shí)體,如果只有幾個(gè)屬性,但是要占數(shù)據(jù)庫表的一行,必須把沒有用的屬性設(shè)置成空,這將導(dǎo)致大量的空字段。另外該通用表的模式會(huì)不斷變化,即隨著本體的修改需要不斷地增加或刪除表中的列,而在當(dāng)前數(shù)據(jù)庫系統(tǒng)中表模式變化的代價(jià)會(huì)很大。1.3.2bcp的存儲(chǔ)模式這種模式包含一張三元組表,表中的每個(gè)實(shí)例都對(duì)應(yīng)于一個(gè)RDF三元組。在這種模式下需要將本體中的所有信息都使用RDF三元組(即Subject,Predicate,Object)來表示。文獻(xiàn)使用這種存儲(chǔ)模式。這種模式設(shè)計(jì)簡(jiǎn)單,并且模式穩(wěn)定,隨著本體的修改只需要修改表中相應(yīng)的元組。另外,該模式通用性好,因?yàn)楝F(xiàn)有的本體模式都可以轉(zhuǎn)換為RDF模型來表示。但是,這種模式的可讀性差,設(shè)計(jì)有關(guān)的查詢語句比較困難。除此之外,該模式最大的不足在于,對(duì)于每個(gè)本體查詢都必須搜索整個(gè)數(shù)據(jù)庫,特別是那些需要進(jìn)行表連接的查詢效率非常低。1.3.3表中增加列數(shù),減少表的市場(chǎng)機(jī)制該模式與水平模式和垂直模式的一個(gè)顯著的區(qū)別是它使用了若干張表,其基本思想是將數(shù)據(jù)庫進(jìn)行模式分解。根據(jù)分解的對(duì)象不同,現(xiàn)有的采用分解模式的方法有兩種。一種分解模式是基于類的分解模式,即為本體中的每個(gè)類都創(chuàng)建一張單獨(dú)的表,表名為類名,表中的列為類的屬性。這種模式有點(diǎn)類似于水平模式,只不過具有更小的粒度,每張表就是一個(gè)類,這樣每張表的列由那些聲明了domain為該類的屬性組成,保證了表的非稀疏性。該模式結(jié)構(gòu)清晰,而且最大的優(yōu)點(diǎn)是能夠高效地查詢一個(gè)或一組實(shí)例的屬性值。但是很難適應(yīng)本體動(dòng)態(tài)變化的情況,因?yàn)殡S著本體中類或者屬性的變化,表結(jié)構(gòu)都要隨著變化。另外一種分解模式是基于屬性的分解模式,即為本體中的每個(gè)屬性創(chuàng)建一張單獨(dú)的表,表名為屬性名,每張表都只包含兩個(gè)列,分別代表RDF三元組中的Subject和Object。文獻(xiàn)采用為每個(gè)屬性創(chuàng)建一張表的方法,但是,在該模式中對(duì)類的隱含實(shí)例的查詢代價(jià)太大。而且,在現(xiàn)有的這兩種分解模式的方法中,隨著本體的變化都要不斷地創(chuàng)建和刪除表,而在數(shù)據(jù)庫系統(tǒng)中創(chuàng)建和刪除表的效率低、代價(jià)大。1.3.4基于類的分解模式該模式通常將上述幾種模式進(jìn)行混合使用。文獻(xiàn)提出了一種將基于類的分解模式與基于屬性的分解模式混合使用的存儲(chǔ)模式,即在本體中定義一個(gè)類就為該類創(chuàng)建一個(gè)表,在本體中定義一個(gè)屬性就為該屬性創(chuàng)建一個(gè)表,表名分別為相應(yīng)的類名和屬性名。然而,與基于類的分解模式不同的是,該模式中在類對(duì)應(yīng)的表中不記錄相應(yīng)實(shí)例的所有信息,只記錄屬于該類的實(shí)例的ID。而實(shí)例在各個(gè)屬性上的取值分別記錄在各個(gè)屬性對(duì)應(yīng)的表中,所以和基于屬性的分解模式類似,該模式中在屬性對(duì)應(yīng)的表中仍然需要兩列:Subject和Object。當(dāng)本體中只包含一百個(gè)左右的類時(shí),這種模式對(duì)于簡(jiǎn)單查詢運(yùn)行得很好,效率很高。但是,如果本體中的類比較多,這種方式就會(huì)存在一些問題,例如:數(shù)據(jù)庫無法容納那么多張表,而且查詢效率很低。1.3.5類型信息存儲(chǔ)模式Sesame實(shí)現(xiàn)了基于關(guān)系數(shù)據(jù)庫MySQL及基于對(duì)象關(guān)系數(shù)據(jù)庫PostgreSQL的存儲(chǔ)方法,對(duì)應(yīng)兩種不同的存儲(chǔ)模式,分別參見圖1和圖2。這兩種存儲(chǔ)模式的區(qū)別是:SesameforRDB模式用一張表(type表)存儲(chǔ)了所有實(shí)例的類型信息,而SesameforORDB模式為每個(gè)類單獨(dú)建立一張關(guān)系表,專門單獨(dú)存儲(chǔ)這個(gè)類的實(shí)例,并且用關(guān)系表之間的subtable關(guān)系記錄類之間的subClass關(guān)系。實(shí)例的屬性取值信息的存儲(chǔ)方法也有同樣的區(qū)別。2一些典型的體積存儲(chǔ)管理系統(tǒng)2.1查詢語言serqSesame是針對(duì)RDF數(shù)據(jù)管理提出的一個(gè)通用的系統(tǒng)框架,它是一個(gè)開源項(xiàng)目,提供了非常開放的API接口,使得人們可以很方便地集成不同的存儲(chǔ)系統(tǒng)、推理引擎以及查詢引擎等。它本身提供了基于關(guān)系數(shù)據(jù)(MySQL,PostgreSQL,Oracle)、基于文件系統(tǒng)以及基于主存的存儲(chǔ)系統(tǒng)的實(shí)現(xiàn),提供了推理算法以及更新算法的實(shí)現(xiàn),支持自定義的查詢語言SeRQL以及RDQL。Sesame旨在提供一個(gè)通用的系統(tǒng)框架,它不規(guī)定如何設(shè)計(jì)存儲(chǔ)模式,也不規(guī)定如何實(shí)現(xiàn)推理,而是通過定義一組接口來規(guī)定存儲(chǔ)模塊以及推理模塊等應(yīng)該完成什么樣的功能,方便人們可以集成不同的實(shí)現(xiàn)模塊。圖3中的RDFModel是指不同的存儲(chǔ)系統(tǒng)應(yīng)該提供的RDF數(shù)據(jù)模型Sail(StorageAndInferenceLayer)API提供在RDFModel層上RDF數(shù)據(jù)的存儲(chǔ)以及推理功能,同時(shí)為查詢引擎提供數(shù)據(jù)存取接口,Sesame的推理基于用戶定義的規(guī)則,用戶可自由定義規(guī)則以及規(guī)則之間的觸發(fā)關(guān)系;Rio表示RDFI/O,它包含許多的RDF文檔解析器(Parser)以及生成器(Writer),解析器將原始的RDF文檔解析成RDF語句(Statement),然后由RDFModel層負(fù)責(zé)語句的存儲(chǔ),生成器將RDF語句重新轉(zhuǎn)換為文檔。RepositoryAPI是用于封裝底層的QueryAPI以及RioAPI,對(duì)用戶提供統(tǒng)一的接口。用戶的應(yīng)用程序可通過本地的Reposito-ryAPI或是通過Http協(xié)議訪問來訪問Sesame。2.2jea的存儲(chǔ)Jena是由HP實(shí)驗(yàn)室開發(fā)的綜合系統(tǒng),它的系統(tǒng)框架見圖4。它包括了一個(gè)易于面向?qū)ο笫褂貌僮鱎DF的API,一個(gè)APRRDF/XML解析器,一個(gè)RDF/XML輸入器,可以使用RDQL查詢語言,支持DAML,即有持久穩(wěn)定的存儲(chǔ)能力。Jena的存儲(chǔ)功能包含有API的三種執(zhí)行方式:第一是存儲(chǔ)它的數(shù)據(jù)在主要的存儲(chǔ)器中;第二種是把數(shù)據(jù)存儲(chǔ)到關(guān)系數(shù)據(jù)庫中;第三種是用Sleepycat軟件的開源的植入式數(shù)據(jù)庫BerkeleyDB。關(guān)系數(shù)據(jù)庫的執(zhí)行方式可以用任何支持JDBC的數(shù)據(jù)庫。配置表允許對(duì)一個(gè)特殊的數(shù)據(jù)庫進(jìn)行特殊化的處理。如同關(guān)系數(shù)據(jù)庫一樣,Berkeley數(shù)據(jù)庫也是持久穩(wěn)固的,盡管它缺乏關(guān)系數(shù)據(jù)庫的事物處理支持能力,但它比關(guān)系數(shù)據(jù)庫可以快一個(gè)數(shù)量級(jí)。2.3基于所使用的u3000rall-roeth-uKAON(TheKarlsruheOntologyandSemanticWebInfrastructure)是德國(guó)Karlsruhe大學(xué)的一個(gè)科研項(xiàng)目。該項(xiàng)目致力于為語義Web提供所需的基礎(chǔ)本體系統(tǒng)和相關(guān)工具。它針對(duì)基于本體的上層商業(yè)應(yīng)用的需求提供了一個(gè)開放的本體管理軟件,為本體的存儲(chǔ)、創(chuàng)建和標(biāo)識(shí)提供了一個(gè)全面的支撐平臺(tái)。圖5是KAON平臺(tái)的體系結(jié)構(gòu)。RDFAPI采用的是斯坦福大學(xué)的RDFAPI,但做了相應(yīng)的重寫和擴(kuò)展,為上層應(yīng)用或KAONAPI提供了本體的內(nèi)存存儲(chǔ)機(jī)制。目前,RDFAPI不但包括了一個(gè)RDFParser可解析RDF文件,還包括了RDFSerializer可以將本體序列化到關(guān)系型數(shù)據(jù)庫和文件中去。KAONAPI為應(yīng)用屏蔽了底層的存儲(chǔ)機(jī)制,但實(shí)際上它也可以通過多種方式訪問KAON本體,一種是通過RDFAPI(然后通過RDFServer),另一種是直接通過EngineeringServer。KAONAPI的定義有其合理性,例如它有Observable這個(gè)設(shè)計(jì)范式,可以讓應(yīng)用自動(dòng)得到本體修改或升級(jí)的消息。RDFServer和EngineeringServer都基于關(guān)系型數(shù)據(jù)庫,可以提供并發(fā)控制和交易機(jī)制,它們還可以直接支持EJB(可選),提供EntityJavaBeans接口。不同的是RDFServer面向RDF,EngineeringServer面向KAON自己的本體標(biāo)準(zhǔn)。KAON的RDFCrawler用于crawling,并綜合Web上的RDF信息?？梢园袰rawling的深度、指定范圍等這樣的參數(shù)放到配置文件中,并把結(jié)果存于本地文件。KAONPortal用于建立一個(gè)多語種的、基于本體的門戶網(wǎng)站。需要先將網(wǎng)站內(nèi)容進(jìn)行本體標(biāo)識(shí)。在網(wǎng)站上可以基于本體進(jìn)行可視化的瀏覽導(dǎo)航。它把顯示與內(nèi)容做了嚴(yán)格的分離,有很好的可配置性。KAON的OI-Modeler是一個(gè)本體的建模工具,用于可視化地建立文件并維護(hù)它。3基于關(guān)系模型的大規(guī)模本體數(shù)據(jù)的存儲(chǔ)不匹配總之,現(xiàn)有的本體存儲(chǔ)方法解決了本體存儲(chǔ)管理的應(yīng)用,大大提高了本體高效的管理。但是目前現(xiàn)有的方法還存在很多問題:(1)現(xiàn)有的大多數(shù)研究工作嘗試基于關(guān)系數(shù)據(jù)庫的方式解決問題。但是,關(guān)系數(shù)據(jù)庫并不是針對(duì)本體數(shù)據(jù)的特點(diǎn)設(shè)計(jì)的,本體數(shù)據(jù)復(fù)雜的圖形結(jié)構(gòu)和關(guān)系數(shù)據(jù)簡(jiǎn)單的扁平結(jié)構(gòu)存在很大差異?；陉P(guān)系模型管理本體數(shù)據(jù),需要把復(fù)雜的本體圖拆分成簡(jiǎn)單的關(guān)系存