張越美 高 歌 彭 程 劉 寒 顧 明

(1.清華大學(xué)軟件學(xué)院，北京 100084； 2.北京信息科學(xué)與技術(shù)國家研究中心，北京 100084； 3.信息系統(tǒng)安全教育部重點實驗室，北京 100084)

引言

建筑信息模型(Building Information Model， BIM)是建設(shè)領(lǐng)域的全周期信息模型。BIM由數(shù)字技術(shù)作支撐，在簡化設(shè)計流程、計算工程算量、模型交付和檢查、后期運維等方面發(fā)揮了極大的作用[1]。BIM在建筑領(lǐng)域逐漸得到廣泛的應(yīng)用，buildingSMART組織推行了工業(yè)基礎(chǔ)類(Industry Foundation Classes， IFC)的標(biāo)準(zhǔn)數(shù)據(jù)模型，并被納入ISO標(biāo)準(zhǔn)(ISO16738:2013)，以解決多種BIM設(shè)計軟件之間的數(shù)據(jù)交換問題[2]。

隨著建筑設(shè)計軟件功能的完善，建筑模型的設(shè)計細(xì)節(jié)豐富，建模支持的專業(yè)增多，使模型的語義信息增長迅速，導(dǎo)出的IFC模型體積逐漸增大。在實際的工程項目中，單專業(yè)的IFC建筑模型體積已達(dá)百兆數(shù)量級，多專業(yè)模型體積接近千兆數(shù)量級。因此，如何高效存儲IFC模型，如何選取IFC存儲的數(shù)據(jù)庫類型以貼合IFC模型的結(jié)構(gòu)，以及如何在IFC模型中建立數(shù)據(jù)字典與數(shù)據(jù)模型的關(guān)聯(lián)是IFC模型在土木建筑行業(yè)應(yīng)用中的挑戰(zhàn)。

1 IFC模型存儲技術(shù)類型

1.1 文件系統(tǒng)

文件系統(tǒng)是目前IFC 模型的主要存儲方式。然而，IFC模型中對象的種類、數(shù)量繁多，對象中存在著大量的引用、連接、組合、包含、表示、分配等各類關(guān)系。IFC文件中復(fù)雜的構(gòu)件、關(guān)系信息被以非結(jié)構(gòu)化信息的方式以構(gòu)件為單位逐行存儲在IFC文件中，需要全部載入內(nèi)存才能進(jìn)行處理與利用。隨著IFC數(shù)據(jù)規(guī)模的增大，帶來了數(shù)據(jù)處理性能與可用性上的嚴(yán)重挑戰(zhàn)。

1.2 關(guān)系數(shù)據(jù)庫

關(guān)系數(shù)據(jù)庫是目前大規(guī)模數(shù)據(jù)表示的重要方式。采用關(guān)系型數(shù)據(jù)庫存儲IFC，通常是將IFC Schema轉(zhuǎn)化實體—關(guān)系(ER)模型，為IFC中的各種實體建立數(shù)據(jù)表，以實體內(nèi)部的屬性作為列，對象之間的關(guān)系需要采用外鍵來表示。例如Cruz采用了Oracle 進(jìn)行 IFC 數(shù)據(jù)存儲，開發(fā)了基于Web的工程管理平臺Active3D[3]。劉照球等基于關(guān)系數(shù)據(jù)庫開發(fā)了工程設(shè)計模型數(shù)據(jù)庫應(yīng)用系統(tǒng)[4]。張洋等利用關(guān)系數(shù)據(jù)庫SQLServer開發(fā)開發(fā)了基于IFC的信息集成系統(tǒng)[5]。然而，IFC Schema通常較大，如IFC 4x2具有816個不同的實體類型，且實體之間具有非常復(fù)雜的關(guān)系。因此采用關(guān)系數(shù)據(jù)庫存儲IFC，需要建立極為復(fù)雜的數(shù)據(jù)表，而且需要進(jìn)行大量耗時的跨表連接操作才能進(jìn)行各類復(fù)雜查詢。另外，IFC實體的屬性較多，在關(guān)系數(shù)據(jù)庫的實際存儲中較為稀疏。此外，由于BIM發(fā)展得較快，IFC標(biāo)準(zhǔn)還在不斷迭代之中，IFC標(biāo)準(zhǔn)版本的變化要求大幅度改動數(shù)據(jù)庫結(jié)構(gòu)，使得數(shù)據(jù)庫維護(hù)成本非常高，因此關(guān)系數(shù)據(jù)庫不適用于IFC模型的存儲。

1.3 面向?qū)ο髷?shù)據(jù)庫

IFC模型具備面向?qū)ο蟮奶卣?，針對于這一特性，很多學(xué)者提出了面向?qū)ο髷?shù)據(jù)庫實現(xiàn)對IFC數(shù)據(jù)的存儲。如Tanyer利用面向?qū)ο髷?shù)據(jù)庫EXPRESS Data Manager存儲IFC數(shù)據(jù)[6]。Farag利用面向?qū)ο髷?shù)據(jù)庫ObjectStore存儲IFC數(shù)據(jù)并開發(fā)了基于Web的IFC共享環(huán)境[7]。

陸寧等基于SQLServer與Versant分別實現(xiàn)了關(guān)系數(shù)據(jù)庫和對象關(guān)系數(shù)據(jù)庫的IFC管理系統(tǒng)，并經(jīng)過實驗比較指出面向?qū)ο髷?shù)據(jù)庫在性能上具有顯著優(yōu)勢[8]。然而，面向?qū)ο笮偷?BIM 數(shù)據(jù)庫本身技術(shù)尚不成熟、標(biāo)準(zhǔn)化程度較低，相比于現(xiàn)代的 NoSQL數(shù)據(jù)庫，可擴(kuò)展性較差。

1.4 NOSQL數(shù)據(jù)庫

NOSQL數(shù)據(jù)庫是無固定表結(jié)構(gòu)、不采用SQL查詢、避免使用連接操作的數(shù)據(jù)庫，通常包括鍵值數(shù)據(jù)庫、文檔數(shù)據(jù)庫、列數(shù)據(jù)庫等，近年來發(fā)展十分迅速。Beetz等基于鍵值型數(shù)據(jù)庫BerkeleyDB開發(fā)了開源BIM服務(wù)器BIMserver，提供了模型增量存儲、提取、轉(zhuǎn)換等功能[9]。林雅虹等人基于文檔數(shù)據(jù)庫MongoDB實現(xiàn)了IFC的存儲并應(yīng)用在室內(nèi)路徑規(guī)劃中[10]。Ma等人基于MongoDB開發(fā)了基于Web的BIM協(xié)同協(xié)同，可在線查詢和編輯模型中的對象[11]。余芳強等人基于列數(shù)據(jù)庫Hbase實現(xiàn)了半結(jié)構(gòu)化的數(shù)據(jù)庫，將IFC資源實體的數(shù)據(jù)直接存儲在使用它的可獨立交換實體的記錄中，減少了連接操作，但也增加存儲空間和數(shù)據(jù)冗余[12]。NOSQL數(shù)據(jù)庫通常在查詢速度和擴(kuò)展性等方面具有一定優(yōu)勢，但其數(shù)據(jù)查詢訪問方式上通常具有一定的局限性，占用的存儲空間也較多。

知識庫(或知識圖譜)是采用網(wǎng)狀的結(jié)構(gòu)對現(xiàn)實世界的事物及其相互關(guān)系進(jìn)行形式化地描述與表達(dá)。知識庫通常采用圖數(shù)據(jù)庫進(jìn)行存儲，通常利于處理大量復(fù)雜、互相關(guān)聯(lián)的數(shù)據(jù)。并且具有靈活的查詢方式。可以為信息查詢、專家系統(tǒng)、問答系統(tǒng)等多種應(yīng)用提供支撐。IFC模型數(shù)據(jù)規(guī)模較大，而且具有近千種對象類型，并且特定構(gòu)件的表示通常不具有唯一性，而是多種對象互相關(guān)聯(lián)表示，與知識庫的特點較為契合。因此，本文采用了知識庫建模的方式，以構(gòu)件為節(jié)點，構(gòu)件關(guān)系為邊，將IFC模型組織成具有圖結(jié)構(gòu)的知識庫，為開展IFC模型知識庫上的查詢、管理、檢查等應(yīng)用打下基礎(chǔ)。

2 IFC模型的知識庫構(gòu)建方法

2.1 知識庫數(shù)據(jù)存儲方法與IFC

知識庫(或知識圖譜)是采用網(wǎng)狀的結(jié)構(gòu)對現(xiàn)實世界的事物及其相互關(guān)系進(jìn)行形式化地描述與表達(dá)。知識庫通常采用圖數(shù)據(jù)庫進(jìn)行存儲，通常利于處理大量復(fù)雜、互相關(guān)聯(lián)的數(shù)據(jù)。并且具有靈活的查詢方式?？梢詾樾畔⒉樵?、專家系統(tǒng)、問答系統(tǒng)等多種應(yīng)用提供支撐。IFC模型數(shù)據(jù)規(guī)模較大，而且具有近千種對象類型，并且特定構(gòu)件的表示通常不具有唯一性，而是多種對象互相關(guān)聯(lián)表示，與知識庫的特點較為契合。因此，本文采用了知識庫建模的方式，以構(gòu)件為節(jié)點，構(gòu)件關(guān)系為邊，將IFC模型組織成具有圖結(jié)構(gòu)的知識庫，為開展IFC模型知識庫上的查詢、管理、檢查等應(yīng)用打下基礎(chǔ)。

IFC標(biāo)準(zhǔn)的表達(dá)主要分為兩個部分：標(biāo)準(zhǔn)SCHEMA的表達(dá)和實例模型文件的表達(dá)。SCHEMA文件在buildingSMART上以EXPRESS文件的形式定義。EXPRESS是ISO 10303-11中規(guī)定的數(shù)據(jù)模型表示方式。實例模型文件以STEP文件的形式存儲，STEP是ISO 10303-21中規(guī)定的實例數(shù)據(jù)表示方法。本研究中知識庫的生成，將緊密結(jié)合IFC的SCHEMA文件與STEP文件標(biāo)準(zhǔn)，解析關(guān)鍵語義信息存儲在知識庫中。

在構(gòu)建知識庫中，本研究選取了圖數(shù)據(jù)庫Neo4j作為IFC模型的存儲介質(zhì)。圖數(shù)據(jù)庫底層最大限度地貼合圖結(jié)構(gòu)，與圖相關(guān)的查詢具有語言簡單、高效的特點，適合表達(dá)IFC模型中的復(fù)雜關(guān)系圖譜。

Neo4j作為圖數(shù)據(jù)庫的代表之一，是第一個使用原生圖數(shù)據(jù)存儲的數(shù)據(jù)庫[13]。在容量方面，社區(qū)版最多支持320億個節(jié)點， 640億個屬性和320億個關(guān)系，百兆IFC模型經(jīng)過優(yōu)化后的存儲需要的節(jié)點數(shù)量為十萬級別，因此對于IFC相關(guān)模型的存儲完全夠用。在速度方面，由于Neo4j是原生的圖數(shù)據(jù)庫存儲，每個節(jié)點中存儲了每個邊的指針，因此遍歷效率非常高，屬性信息中也可以建立索引，加快屬性查找速度。除了Cypher查詢語言之外，Java平臺有原生的Embedded API可以更高效地完成圖數(shù)據(jù)庫的增刪改查操作，本研究在模型入庫階段即使用了其Embedded API[14]。因此，本文采用Neo4j數(shù)據(jù)庫作為知識庫的載體。

2.2 元數(shù)據(jù)知識的建模存儲

知識庫建立的第一步是對IFC SCHEMA在知識庫中建模、解析存儲。存儲IFC SCHEMA文件的作用有以下幾點：第一，IFC版本眾多，對模型的版本管理尤為重要，知識庫可以驗證模型文件的版本匹配； 第二，對IFC模型使用知識庫建模時，需要依賴SCHEMA知識進(jìn)行屬性推理。因此，本節(jié)將介紹IFC SCHEMA在知識庫中的建模存儲方法。

如圖1所示，將IFC SCHEMA文件建模存儲為知識庫中的元數(shù)據(jù)知識的步驟分為使用語法分析器ANTRL解析SCHEMA文件、抽取IFC實體信息、補充推理實體屬性信息、屬性類型關(guān)聯(lián)、Neo4j數(shù)據(jù)庫儲存。

圖1 元數(shù)據(jù)知識庫建模流程

根據(jù)ANTLR[15]對于Express Schema的解析結(jié)果，即可在Neo4j圖數(shù)據(jù)庫中建立元數(shù)據(jù)知識庫。首先，在Neo4j中定義兩個標(biāo)簽：Node和Attribute，分別代表實例節(jié)點和屬性節(jié)點標(biāo)簽。實例節(jié)點包含兩個屬性：實體名稱(name)和實體所屬版本(version)，屬性節(jié)點也包含兩個屬性：屬性名稱(name)和屬性下標(biāo)(index)。其次，在Neo4j中定義了三種關(guān)系：HAS_ATTR表示實例節(jié)點具有某個屬性，LINK_TO代表屬性節(jié)點的限定關(guān)系，即這個屬性的取值必須是哪一個實體類型，SUBTYPE_OF代表節(jié)點之間的繼承關(guān)系。

抽取實體信息后，基于IFC實體之間的繼承屬性，實體的全部屬性應(yīng)為其父類的全部屬性和自身屬性的并集，因此使用深度優(yōu)先搜索的方法推理出每個實體的完整屬性。最終根據(jù)堆屬性的引用實體類型定義，將每個屬性節(jié)點與相應(yīng)的引用實體連接，形成完整的元數(shù)據(jù)知識庫模型。

得到了元數(shù)據(jù)知識模型，可以通過可視化工具更為具體地了解不同的IFC版本中的區(qū)別與聯(lián)系，在IFC模型文件的建模過程中進(jìn)行版本驗證。也可通過簡單的語句對于IFC版本信息進(jìn)行挖掘和推理。

2.3 實例知識的建模與存儲

知識庫建立的第二步是對IFC實例知識建模存儲。對IFC實例文件的存儲是知識庫的關(guān)鍵部分，是在知識庫上查詢、檢查等應(yīng)用的基礎(chǔ)。在元數(shù)據(jù)知識的基礎(chǔ)下，實例知識的建立分為圖2幾個步驟：IFC文件解析、實體節(jié)點驗證存儲、引用關(guān)系建立。

圖2 實例知識庫建模流程

IFC模型文件解析的關(guān)鍵點在ANTLR對IFC文件的解析方式，如何建立語法樹來兼顧存儲速度和存儲所占內(nèi)存大?。?實例節(jié)點驗證存儲的關(guān)鍵點在如何通過元數(shù)據(jù)知識庫獲取屬性順序和對應(yīng)名稱，并在圖數(shù)據(jù)庫中建立索引的方式； 節(jié)點引用關(guān)系建立的關(guān)鍵點在于引用關(guān)系的發(fā)現(xiàn)和建立關(guān)系后的關(guān)系化簡過程。

實例知識庫建立的第一個關(guān)鍵點是：提高IFC模型文件解析速度、減少解析模型占用的內(nèi)存空間?；贗FC文件解析開源庫實現(xiàn)模型文件的解析有兩點不足，第一，解析方法包含知識庫所不需要的幾何造型重構(gòu)信息導(dǎo)致解析速度慢； 第二，基于將模型全部解析入計算機(jī)內(nèi)存對存儲空間的開銷巨大。因此，本研究采用ANTLR的Visitor模式，獨立構(gòu)建實例文件的語法樹，并使用如圖3語法樹拆分算法解決語法樹過大問題。高效對接實例知識庫，極大地提高了實例知識庫建立的時間、空間效率。

圖3 語法樹拆分示意圖

實例知識庫的第二個關(guān)鍵點是實例節(jié)點的存儲。在節(jié)點存儲的過程包含三個步驟：實例節(jié)點過濾、實例節(jié)點屬性推理、引用關(guān)系建立。IFC實例文件中有大量與語義信息無關(guān)的底層幾何信息，底層幾何信息節(jié)點的數(shù)量甚至占整個模型節(jié)點數(shù)量的一半以上。實例節(jié)點過濾的目的即為過濾無語義信息的節(jié)點，節(jié)省實例知識庫空間，提高實例知識庫生成速度。

實例節(jié)點的屬性推理原因是STEP文件中每個實體的屬性列表中是每個屬性的值，沒有屬性的名稱。而在建模過程中，屬性名稱是兩個節(jié)點關(guān)系建立時的關(guān)系名稱，因此必須通過推理元數(shù)據(jù)知識庫得到屬性對應(yīng)的名稱。其次，在推理屬性名稱的同時也可以檢查這個模型文件是否符合SCHEMA的基本規(guī)定，例如屬性數(shù)量是否與SCHEMA不對應(yīng)。屬性對應(yīng)關(guān)系如圖4所示。因此，通過查詢元數(shù)據(jù)只是庫中的屬性名稱，與實例知識庫實體進(jìn)行匹配，即可推理得到實例節(jié)點的具體屬性鍵值對。最終，單個實例節(jié)點滿足以下原則：第一，節(jié)點的類型標(biāo)簽為其自身IFC類型及其所有父類類型； 第二，節(jié)點屬性為鍵值對分別對應(yīng)了IFC SCHEMA中的屬性名和模型文件中的屬性值； 第三，每個節(jié)點加入lineId屬性代表節(jié)點編號，model屬性代表模型名稱。

圖4 屬性推理示意圖

實例節(jié)點存儲后，知識庫中的實例信息只有孤立的頂點，將有關(guān)系的節(jié)點連接起來，才能形成真正可推理的知識庫。引用關(guān)系的建立分為兩個主要步驟：第一步是逐個遍歷數(shù)據(jù)庫中的每個實例節(jié)點以及其全部屬性，發(fā)掘?qū)傩砸藐P(guān)系后建立有向連接，由引用節(jié)點指向被引用節(jié)點，關(guān)系名稱即為屬性名稱； 第二步是對部分引用路徑進(jìn)行合并精簡，減少不重要的節(jié)點。由于IFC實例文件中的實體的行號為唯一標(biāo)識，引用關(guān)系的設(shè)置便以行號為基礎(chǔ)。在使用行號查詢引用節(jié)點時，由于IFC實例文件規(guī)模巨大，往往一個模型包含數(shù)十萬節(jié)點，搜索開銷較大。本文利用圖數(shù)據(jù)庫的索引機(jī)制，在節(jié)點存儲時對行號建立索引，極大地降低了查詢的時間開銷。最終，IFC實例文件在知識庫中形成一張巨大的關(guān)系網(wǎng)。如圖5可見一個模型中的門(IFCDOOR)節(jié)點在知識庫中的展示。

圖5 IFCDOOR在實例知識庫中的表示

3 IFC知識庫的效率分析

本文所選的測試模型均來自實際的商業(yè)綜合體模型，測試模型有以下三個特點：其一，模型覆蓋了兩種主流IFC版本：IFC2X3和IFC4； 其二，模型涵蓋了建筑、暖通、排水三個專業(yè)，具有多專業(yè)的普適性； 第三，大體量模型的體積超過百兆，使用傳統(tǒng)的內(nèi)存模型將嚴(yán)重受限于用戶計算機(jī)的硬件配置，可以更加明顯地體現(xiàn)出知識庫存儲的優(yōu)勢。

表1分析了測試模型載入知識庫的時間效率，效率分析根據(jù)模型載入的幾個重要步驟進(jìn)行統(tǒng)計，包括：模型文件遞歸下降解析、實體節(jié)點插入知識庫、節(jié)點之間關(guān)系建立三個步驟。通過分析可得出以下幾個結(jié)論：第一，知識庫建立的總體時間在2分鐘以下，符合工程對于模型存儲的要求； 第二，三個步驟所需時間較為平均，其中模型的解析時間和模型大小呈現(xiàn)正相關(guān)，節(jié)點插入時間和關(guān)系建立時間和模型內(nèi)容緊密相關(guān)。

表2分析了測試模型在知識庫上查詢的時間效率。我們以構(gòu)件的存在性簡單查詢語句為例，以上模型需要的查詢初始化用時、單次查詢時間分別如表2所示。

表1 知識庫建立時間效率分析

文件名模型大小(MB)模型解析(ms)節(jié)點插入(ms)關(guān)系建立(ms)總時間(ms)綜合體建筑32723 33737 54122 74588 839綜合體暖通17417 95715 75517 25251 622綜合體給排水11016 66218 1494 48343 078

表2 知識庫查詢時間效率分析

文件名模型大小(MB)節(jié)點數(shù)(ms)初始化時間(ms)查詢時間(ms)綜合體建筑327180 39311 758350綜合體暖通174897 9652 255126綜合體給排水110503 4012 33364

此外，我們將本文方法與其它方法存儲過程的內(nèi)存空間效率進(jìn)行了對比。其中一種是將IFC解析為語義網(wǎng)三元組，存儲到Jena TDB數(shù)據(jù)庫； 另一種是將IFC實體解析為鏈表，存儲到MongoDB中。如表3所示，在16GB內(nèi)存計算機(jī)的實驗環(huán)境， 300M以上模型的三元組存儲創(chuàng)建過程失敗，而MongoDB的內(nèi)存占用與模型大小成正比?；谥R庫的模型存儲架構(gòu)采用逐行解析存儲，內(nèi)存占用與模型規(guī)模相關(guān)性較小，百兆模型的存儲過程占用內(nèi)存不超過500MB，顯著地提高了內(nèi)存空間的使用效率。

表3 內(nèi)存空間效率分析對比

文件名大小(MB)TDB(MB)MongoDB(MB)本文方法(MB)綜合體建筑327失敗13 190434.5綜合體暖通1746 7505 980216.2

4 IFC知識庫的應(yīng)用

在Neo4j上建立了元數(shù)據(jù)知識庫和實例模型知識庫，即可使用Cypher查詢語言，借助Neo4j可視化平臺，方便快捷地獲取IFC Schema信息和IFC模型信息。

4.1 IFC SCHEMA版本關(guān)系查詢

在知識庫的建立章節(jié)，本文介紹了將IFC SCHEMA文件建模存儲入知識庫形成元數(shù)據(jù)知識的方法。隨著BIM的發(fā)展和應(yīng)用，IFC版本的也做出配合的更新，將版本信息化為結(jié)構(gòu)化的知識，可以方便地查詢IFC版本之間的關(guān)系和差異。如下Cypher腳本即可將知識庫中的IFC4X1版本信息與IFC4版本信息做比對，查詢出IFC4X1中的增加元素和相關(guān)屬性。

MATCH(m:Entity { ifctype:‘IFC4′})WITH COLLECT(distinct m.name)as ifcnamesMATCH(n:Entity { ifctype:‘IFC4X1′ }),WHERE n.name NOt in ifcnamesRETURN n

4.2 類型繼承關(guān)系查詢

Cypher查詢語句在關(guān)系查詢上的模糊查詢功能，對于圖數(shù)據(jù)庫的查詢產(chǎn)生極大便利。在IFC SCHEMA定義的數(shù)據(jù)模型中，繼承關(guān)系網(wǎng)較為復(fù)雜。獲取一個實體的所有子類在官方文檔上查詢費時費力，在文檔類型的數(shù)據(jù)庫上的查詢語言復(fù)雜，學(xué)習(xí)成本較高。而在圖數(shù)據(jù)庫上，通過Cypher語句對于不定長關(guān)系鏈的語言設(shè)置和圖數(shù)據(jù)庫的底層存儲機(jī)制，使相關(guān)查詢語句易于理解和書寫，查詢速度快。如下簡單的Cypher腳本即可查詢IfcBuildingElement實體的子類。

MATCH(:Node { name:′IfcBuildingElement′, version:′IFC4′})<-[:SUBTYPE_OF?1..5]-(m:Node)RETURN m.name

如圖6在Neo4j平臺的可視化展示，可以簡潔明了地分析出IfcBuildingElement實體的繼承關(guān)系網(wǎng)絡(luò)。

圖6 IFC繼承關(guān)系可視化

4.3 建筑空間結(jié)構(gòu)查詢

IFC模型中使用IfcSpace實體表示建筑中的空間概念，一個樓層的房間聯(lián)通關(guān)系在IFC文件中使用BoundedBy關(guān)系表示，在傳統(tǒng)的存儲方式中，空間聯(lián)通關(guān)系的查詢難以直觀顯示，而圖數(shù)據(jù)庫對于拓?fù)潢P(guān)系的表達(dá)高效清晰，如下Cypher語句通過獲取門和空間的關(guān)系形成圖7所示的建筑的空間關(guān)系網(wǎng)絡(luò)，快捷地獲取樓層空間結(jié)構(gòu)。

MATCH p=(n:IfcDoor)-[r:isBoundedBy]->(m:Ifc-Space)RETURN p

圖7 實例知識空間關(guān)系可視化

5 討論與總結(jié)

隨著BIM技術(shù)的發(fā)展，IFC作為BIM國際交換標(biāo)準(zhǔn)的普及率逐漸增加，IFC模型的規(guī)模增大、語義信息復(fù)雜，IFC模型的存儲是IFC模型查詢的基礎(chǔ)，IFC模型的存儲方案研究關(guān)系著IFC模型相關(guān)應(yīng)用的便捷性和高效性。本文介紹了基于知識庫的IFC模型存儲方案和基于知識庫的IFC模型查詢應(yīng)用。在IFC知識庫的建立中，本文分別實現(xiàn)了以IFC Schema建模為基礎(chǔ)的元知識庫建模、以IFC模型文件為基礎(chǔ)的實例知識庫建模。元數(shù)據(jù)庫的建模為實例知識庫的建立打下基礎(chǔ)，實例知識庫為IFC查詢提供直接依據(jù)。

本文提出的基于知識庫的IFC存儲技術(shù)，與文件系統(tǒng)相比，模型不用全部加載到內(nèi)存，提高了模型信息訪問的效率以及對大模型的支持。與基于關(guān)系型數(shù)據(jù)庫存儲技術(shù)相比，關(guān)系型數(shù)據(jù)庫需要定義明確的表結(jié)構(gòu)以及進(jìn)行很多跨表操作。而IFC的復(fù)雜數(shù)據(jù)模型、稀疏的屬性以及豐富的關(guān)系導(dǎo)致建立與維護(hù)表結(jié)構(gòu)是困難的，跨表操作是低效的。與面向?qū)ο髷?shù)據(jù)庫相比，知識庫方案所采用的圖數(shù)據(jù)庫技術(shù)更加成熟，成本更低。以MongoDB為代表的文檔類數(shù)據(jù)庫是以JSON格式為基礎(chǔ)存儲數(shù)據(jù)，不受表結(jié)構(gòu)的限制，但存在難以完全表示IFC模型的圖結(jié)構(gòu)信息的缺點。而本文提出的存儲方法可以完善地表示IFC模型中的圖結(jié)構(gòu)信息，并提供了更加靈活的查詢方法。相較于其他圖數(shù)據(jù)庫的存儲方案(如ifcOWL)[16]，本文采用屬性標(biāo)簽圖對IFC在圖數(shù)據(jù)庫中直接存儲，不需將IFC模型轉(zhuǎn)換成更復(fù)雜圖結(jié)構(gòu)，提高了存儲效率。并通過元數(shù)據(jù)知識庫實現(xiàn)了Schema的動態(tài)綁定，使模型存儲不受制于IFC版本實現(xiàn)。在基于知識庫的應(yīng)用方面，本文主要基于Cypher語言對模型進(jìn)行查詢與可視化。相較于SPARQL[17]、SHACL[18]等固定路徑的查詢語言，基于知識庫的方法具有自適應(yīng)、不需指定匹配路由或路徑長度的特性。該方法一方面良好地適配了IFC數(shù)據(jù)關(guān)系復(fù)雜、對象的表示方式多樣化的特點，另一方面顯著降低了用戶的查詢難度，使用戶只需關(guān)注查詢的目標(biāo)，而不用關(guān)心查詢的實現(xiàn)方式。

本文以IFC版本查詢、類型繼承關(guān)系查詢、建筑空間結(jié)構(gòu)查詢等功能為例說明了基于知識庫的IFC查詢的靈活、高效性。在本文構(gòu)建的IFC知識庫的基礎(chǔ)上，可以利用簡潔靈活的語句實現(xiàn)更復(fù)雜的信息查詢，為進(jìn)一步基于知識庫進(jìn)行模型檢查、模型提取等應(yīng)用打下良好的基礎(chǔ)。