劉吉明 ,段立平,b ,林思偉 ,繆季 ,趙金城,b
(上海交通大學 a.船舶海洋與建筑工程學院;b.上海市公共建筑和基礎設施數(shù)字化運維重點實驗室,上海 200240)
在推行數(shù)字化建造的過程中,項目各方信息流通困難、專業(yè)軟件數(shù)據(jù)格式各異、建筑信息多源異構及大數(shù)據(jù)特征等問題嚴重阻礙了行業(yè)智能化轉型。這些涉及信息集成、流通與管理的問題可統(tǒng)稱為信息交付問題,而傳統(tǒng)碎片化、分散式的交付方式已無法滿足數(shù)字化建造需求,因此亟需革新建筑信息交付方式以打破信息孤島壁壘。
建筑信息模型(Building Information Modeling,BIM)技術及其信息交付標準工業(yè)基礎類(Industry Foundation Class,IFC)的興起為上述問題帶來了轉機。IFC 是由buildingSMART International(bSI)提出的開放且中立的數(shù)據(jù)交換格式,其通過描述建筑模型的幾何架構、語義架構以及二者的相互關系,實現(xiàn)了對建筑信息的完整描述。也正因如此,IFC被認為適用于建筑全生命周期中的大部分數(shù)據(jù)交換場景。例如,劉照球等[1]基于BIM 的模型集成框架、賴華輝等[2]基于IFC 標準的信息共享方法、馬智亮等[3]基于IFC 標準的建筑能耗監(jiān)測靜態(tài)信息模型都有效提升了信息交付效率。然而,由于IFC 標準存在編寫語言普及程度低和數(shù)據(jù)架構復雜、難以拓展的問題[4],該技術仍無法解決信息交付難題。
此外,通過建立數(shù)學表達式或開發(fā)算法來建立數(shù)學模型的方法也是一種可行的數(shù)據(jù)集成方式,比如魏國海等[5]的火災損傷多元信息融合模型、Liu等[6]基于數(shù)字孿生的信息融合框架,以及張立奎等[7]用于橋梁變形重構的基于LSTM 神經(jīng)網(wǎng)絡的多元信息融合方法。但現(xiàn)有的數(shù)學建模方法無法涵蓋所有相關因素,并且所建模型高度抽象,故而也難以在實踐中得到推廣。
針對以上問題,筆者在IFC 標準基礎上引入語義網(wǎng)以克服其局限性。首先,介紹語義網(wǎng)核心技術架構,并分析語義網(wǎng)拓展IFC 功能的可行性。然后,利用Pauwels 等[8]提出的轉化方法執(zhí)行建筑信息語義化建模,通過驗證所建模型數(shù)據(jù)傳遞的準確性來說明該方法的可行性。最后,分析所建模型的數(shù)據(jù)模式以探討制約該技術實踐應用的關鍵因素,并基于分析的數(shù)據(jù)模式提出冗余信息規(guī)避的可行方法。
語義網(wǎng)是萬維網(wǎng)之父Berners-Lee 等[9]于1998年提出的一種網(wǎng)絡技術,旨在解決“傳統(tǒng)網(wǎng)絡僅作為給用戶提供文檔的媒介而無法直接處理數(shù)據(jù)信息”的問題。該技術的主旨是通過機器可理解的統(tǒng)一信息描述來共享暫存信息,而這一功能特征恰與建筑業(yè)亟需解決的信息交付難題高度契合。正因如此,語義網(wǎng)賦能建筑信息交付得到學者廣泛探究。其中,專研建筑信息智能化的國際組織bSI 不僅成立鏈接數(shù)據(jù)工作組(Linked Data Working Group,LDWG)來實現(xiàn)IfcOWL 本體的標準化,同時還將語義網(wǎng)納入其技術路線圖[10]。
Berners-Lee 最早提出了語義網(wǎng)基本架構,其逐步發(fā)展完善為現(xiàn)行的語義網(wǎng)堆棧[11]。該技術架構下的資源描述框架(Resource Description Framework,RDF)、本體與網(wǎng)絡本體語言(Web Ontology Language,OWL)以 及 SPARQL(SPARQL Protocol and RDF Query Language)三項核心技術為其數(shù)據(jù)表示、邏輯推理和知識查詢功能提供支持。
RDF 是萬維網(wǎng)聯(lián)盟(World Wide Web Consortium,W3C)提出的以相互關聯(lián)的有向標記圖描述資源信息的標準框架。通過以主體-謂詞-客體的三元組表達式描述資源,實現(xiàn)對多源異構數(shù)據(jù)的統(tǒng)一表達,進而為語義化建模和知識查詢推理奠定數(shù)據(jù)基礎。
本體和OWL 是語義網(wǎng)體系中賦予模型高級知識邏輯的關鍵模塊。本體原為哲學領域概念,知識工程引入該術語以創(chuàng)建自動推理信息模型。OWL特指W3C 推行的OWL2 網(wǎng)絡本體語言,是一種旨在表述事物、事物組及事物間關系所蘊含知識的陳述性語言。在語義網(wǎng)架構中,把基于OWL 概念創(chuàng)建的RDF 圖稱為OWL 本體,用以彌補RDFS(Resource Description Framework Schema)語義豐富度不足的缺陷。圖1 所示是W3C 倡議的OWL2本體的分類架構和主要配置文件[12],其中OWL2 DL 本體在知識推理工具中應用最廣。其原因在于OWL2 DL 可產(chǎn)生與SROIQ 描述邏輯兼容的語義,且根據(jù)相似理論[13],其推論足夠可信,故推理工具可參照描述邏輯的實踐經(jīng)驗進行開發(fā)。
圖1 OWL2 本體分類及語義層次關系Fig.1 Classification and semantics hierarchy relationships of OWL2 ontology
SPARQL 是基于圖模式匹配的RDF 查詢語言,可跨數(shù)據(jù)源作聯(lián)合查詢并返回RDF 圖。SPARQL 可對匹配圖模式作增刪查改,進而實現(xiàn)RDF 數(shù)據(jù)集的動態(tài)更新。除查詢外,知識推理也是語義網(wǎng)的重要功能。語義網(wǎng)不僅有源自RDFS 和OWL 的推理邏輯,還可借由SWRL、SPIN 和SHACL 規(guī)則語言實現(xiàn)高級知識推理。此外,輔助本體開發(fā)的本體推理也是一種知識推理形式[14]。
在實際信息交付場景中,IFC 標準所面臨的主要問題是數(shù)據(jù)模式難以拓展和信息提取修改困難。通過分析各問題致因以及語義網(wǎng)處理該問題的優(yōu)勢,論證了語義網(wǎng)拓展IFC 信息交付功能的可行性。
拓展性問題是指難以擴充既定的IFC 數(shù)據(jù)模式來滿足個性化的信息表述需求,該問題主要源于定義數(shù)據(jù)模式的EXPRESS 語言。首先,這是一種不常用的聲明性語言,難以被建筑業(yè)用戶所掌握;其次,該語言可定義的信息類型繁雜(可同時定義實體、關系、規(guī)則及復雜數(shù)據(jù)結構),故由其聲明的IFC數(shù)據(jù)模式復雜且難以擴展。bSI 針對該問題提供了自定義屬性集和數(shù)據(jù)字典的解決方案,但前者難以實現(xiàn)術語對齊,后者缺乏靈活性而無法提供有效幫助。語義網(wǎng)能夠集成本體和描述邏輯對各領域信息進行個性化知識表示,然后依托本體映射實現(xiàn)語義層面的一致性匹配,進而將IFC 兼容信息與其他信息進行統(tǒng)一表達。因此,語義網(wǎng)技術可有效解決IFC 標準面臨的拓展性難題。
IFC 標準的另一個問題是缺乏高效的信息查改方法。IFC-SPF 文件是基于IFC 數(shù)據(jù)模式編寫的純文本文件,該文件不僅可讀性差,而且難以對IFC語句進行修改。Mazairac 等[15]曾為此提出了一種檢索IFC 信息的查詢語言BIMQL,但該方法不僅只能用于信息查詢,還難以被用戶掌握,故未得到廣泛應用。在語義網(wǎng)被引入建筑領域后,Krijnen 等[16]隨即提出利用SPARQL 來彌補BIMQL 存在的不足。其原因在于:首先,SPARQL 用法與SQL 語言類似,容易被用戶所掌握;其次,SPARQL 可直接對RDF 圖進行增刪改查;并且用戶還能通過SPARQL 對SPARQL 端點中的RDF 數(shù)據(jù)進行遠程訪問,有助于開發(fā)項目信息管理的云服務。
除以上優(yōu)勢外,語義網(wǎng)的知識推理功能有助于高效利用建筑信息。在項目管理過程中,所集成數(shù)據(jù)增多,隱含知識也隨即陡增。而挖掘隱含知識對于開發(fā)項目管理服務是有益的。如,Wu 等[17]將卷積神經(jīng)網(wǎng)絡識別的人的施工行為信息與人和構件空間關系信息集成,再引入從施工技術規(guī)范中轉化的SWRL 規(guī)則,識別了危險施工行為。因此,語義網(wǎng)有助于讓IFC 表達的信息切實服務于實際工程。
鑒于在IFC 模型基礎上進行語義化建模,故對IFC 模型的生成方式和信息轉化效率進行分析。
模型視圖定義(Model View Definition,MVD)是對BIM 模型作數(shù)據(jù)篩選輸出IFC 模型的過濾器。其興起的原因在于隨著BIM 信息交付所涉及領域的不斷擴張,IFC 標準面向不同專業(yè)的數(shù)據(jù)冗余問題愈發(fā)突出,因此,bSI 推出MVD 作為IFC 標準的子集以適應不同應用需求。
bSI 在其MVD 數(shù)據(jù)庫收錄了MVD 的所有可用版本,而在建筑業(yè)BIM 軟件中得到應用的分別是IFC 2×3 協(xié)調(diào)視圖2.0(Coordination View 2.0,CV 2.0)、IFC4 參照視圖及IFC4 設計傳遞視圖。其中CV 2.0 在各類軟件中兼容性最好,應用也最為廣泛。但bSI 正在積極推進IFC4 標準相關MVD 的研發(fā)與推廣,從視圖所涉范圍的廣度和更新速度來看,IFC4 全面取代IFC 2×3 標準是必然趨勢。
圖2 雙層鋼框架廠房BIM 模型結構示意Fig.2 BIM model of two-story steel frame building
為對比經(jīng)不同MVD 輸出IFC 模型的數(shù)據(jù)轉化效率,選取如圖2 所示的雙層鋼框架廠房結構作案例分析。利用集成式IFC 解析器(https://github.com/Autodesk/revit-IFC)從Revit 中以CV 2.0、參照視圖和設計傳遞視圖分別輸出IFC 模型,將其分別讀取并匯總信息,如表1 所示。在所有輸出模型中,參照視圖(結構)丟失信息最為嚴重,該視圖因忽略樓板的信息輸出,直接導致實體總數(shù)異常;CV2.0 因對梁實體的區(qū)分只考慮構件截面類型而忽視建模方法與梁長差異,故輸出的實體關系信息偏少;至于設計傳遞視圖,由于其材料關系定義采取實例與材性映射方式,因而此關系數(shù)目多于其他輸出結果,從語義化建模角度來看,這種表達形式能夠涵蓋更完備的構件信息,有助于提高語義化建模精度。
表1 鋼框架廠房各MVD 輸出模型組成信息匯總Tab.1 Composition information of each MVD output model of the steel frame structure
針對該案例的樓板信息轉化結果,進一步對比各輸出模型轉化效率。樓板采用壓型鋼板-混凝土組合樓板,Revit 建模時采用雙層組合形式。在樓板的信息轉化過程中,參照視圖與CV 2.0 只能將其簡化為單層混凝土構件;并且前者還縮減了樓板的實體關系,尤其是材料關系的輸出,導致建筑信息嚴重丟失。而設計傳遞視圖對于組合樓板的信息轉化效果明顯優(yōu)于前述視圖,該視圖不僅有效保留了構件應有的實體關系,還能將組合樓板以雙層形式正常輸出。因此,設計傳遞視圖輸出模型在保真度和信息豐富度方面有明顯優(yōu)勢。
語義化建模旨在以RDF 對IFC 實體信息作資源虛擬化。針對此轉化需求,Karan 等[18]通過集成自定義BIM 本體與地理信息系統(tǒng)(Geographic Information Systems,GIS)本體來處理IFC 屬性,進而生成BIM 與GIS 集成 的RDF 模型;W3C 則致力于研發(fā)以BOT(Building Topology Ontology)為代表的輕量化本體[19],并且由Bonduel 等[20]開發(fā)出的IFCtoLBD 轉換器實現(xiàn)了基于BOT 本體的RDF 建模;此外,Niknam 等[21]也提出了一種可用于建筑信息共享的通用本體BIMSO。與上述3 種方法相比,Pauwels 等[8]倡議的基于IfcOWL 本體的轉化方法能夠對IFC 兼容的所有建筑信息執(zhí)行語義化建模,在適用性與技術成熟性方面更具優(yōu)勢,因此應用其開發(fā)的IFCtoRDF-0.4 轉換器(https://github.com/pipauwel/IFCtoRDF)作語義化建模。
對于已開發(fā)的IfcOWL 本體而言,IFC4 對應本體相較于IFC 2×3 對應本體在類層次關系及公理數(shù)目上更具優(yōu)越性,再結合前文各IFC 模型的轉化效果,最終選定設計傳遞視圖輸出模型進行語義化建模。建模步驟分為IFC-SPF 文件向Turtle 文件轉化和引入IfcOWL 本體實現(xiàn)高階語義賦能。在JDK17 的編譯環(huán)境中啟動轉換器并執(zhí)行文件轉化,然后將初始RDF 模型導入Protégé 本體編輯器,最后用IfcOWL 本體為該模型賦予建筑語義內(nèi)涵。
為明晰轉換器的工作原理,通過IntelliJ IDEA將其運行于maven 項目,并對其轉化機制作源碼分析。如圖3 所示,主程序涵蓋了IFC 模型轉化從參數(shù)輸入到初始RDF 模型輸出的全過程;程序根據(jù)命令行參數(shù)自動識別轉化模式,依次調(diào)用showFile()、setup()與convert()方法執(zhí)行文件讀取、規(guī)范設置和格式轉化,并最終輸出初始RDF 模型。其setup()方法用于確定IFC 標準的版本并導入為文件轉化提供規(guī)范參照的序列化文件;convert()方法則實現(xiàn)了文件解析、本體注冊、資源創(chuàng)建以及三元組編寫。鑒于此二者在文件轉化中的重要作用,圖3 也對其運行流程予以展示。為提升所繪流程圖的可讀性,對某些不可能發(fā)生的條件分支進行甄別。例如,在轉化模塊的紅框標識步驟,參照合法IFC 語句,不會將Type 類型實體作為其實體聲明,把程序針對該情況對應的條件分支予以省略。
圖3 IFCtoRDF-0.4 轉換器運行流程Fig.3 Flow chart of IFCtoRDF-0.4 converte
轉換器執(zhí)行文件轉化的核心步驟包括參考標準導入、IFC 語句解析和三元組編寫。在設置模塊中,通過反序列化IFC 標準的序列化文件導入?yún)⒖紭藴?;在轉化模塊加粗藍框標識步驟中,調(diào)用parseIfcLineStatement()解析IFC 語句;三元組則在轉化模塊不同步驟中根據(jù)其類別調(diào)用特定方法予以編寫。為分析語句解析的基本邏輯,繪制如圖4(a)所示的算法偽代碼。圖示switch 分支語句的前兩項分別完成語句編號和實體名稱的解析,后兩項則聯(lián)合完成括號內(nèi)各屬性值的解析。在該算法中,程序主要利用IFC 語句的特定字符對控制條件state 作調(diào)控,進而執(zhí)行恰當?shù)姆种дZ句以完成語句解析。另外,對于屬性值為數(shù)組甚至是多維數(shù)組的復雜情形,程序則利用棧數(shù)據(jù)結構和雙向鏈表數(shù)據(jù)結構進行分層解析。
圖4 轉化模塊關鍵算法的運行邏輯Fig .4 Execution logic of key algorithms in convert module
IFC 語句對應三元組主要源于屬性信息的轉化,如圖3 中屬性轉化子模塊所示,程序將依據(jù)屬性值所屬類型來執(zhí)行相應分支語句,進而編寫三元組。分析了字符串屬性值轉化分支的運行邏輯,并將該分支調(diào)用的fillPropertiesHandleStringObject()方法的算法偽代碼繪圖如圖4(b)所示。此算法的核心在于識別屬性類別以及創(chuàng)建并添加屬性資源集合鍵值對,主要遵循從字面值賦值到頂層屬性賦值這一自下而上的邏輯。對于轉化過程中遇到的非常規(guī)情況,將以不同級別示警在運行日志中予以提示。其余轉化分支雖然具體流程與前述算法略有區(qū)別,但轉化邏輯類似,可參照理解。
利用此轉換器輸出雙層鋼框架廠房的初始RDF 模型并導 入Protégé 應用程序,由于轉化過程已基于Apache Jena 框架實現(xiàn)本體類的注冊,故可引入IfcOWL 完成建筑語義賦能。
為探討基于IfcOWL 語義化建模方法未得到有效使用的可能原因,對語義化模型單元實例的數(shù)據(jù)模式進行分析。鑒于RDF 模型數(shù)據(jù)模式的通用性,此內(nèi)容也將為建筑信息的知識存取與邏輯推理研究提供技術參照。
建筑單元實例是指具體構件的實例對象。圖5所示為分析案例涉及到的梁、板、柱構件的繼承關系;圖示層次關系采取了與IFC 模式一致的類繼承方式,故而兩種信息表達方式在類層次關系上具有一致性。
圖5 RDF 模型中建筑單元的類繼承關系Fig.5 Class hierarchy relationships of building elements in RDF model
在RDF 模型中,建筑單元實例的語義化描述均由圖6 所示語義層次關系表示。如圖6 所示,單元實例所具有的屬性皆為對象屬性,各屬性所在三元組主體(定義域)皆為實例對象本身,三元組客體(值域)為字面值或RDF 資源。其中賦值三元組直接闡述了建筑單元的名稱、標簽和類型信息,3 個RDF 子圖涵蓋了業(yè)主歷史、對象布置和幾何表示的相關信息。此外,圖6 所示圖例說明了在執(zhí)行數(shù)據(jù)模式分析時使用的各節(jié)點符號的具體含義。
圖6 構件實例對象的屬性架構Fig.6 Object property schema of building elements
梁柱單元是鋼框架結構主要的構件形式,因此,選取圖2 中標識的單元實例IfcBeam_4072 和IfcColumn_421 進行數(shù)據(jù)模式分析,通過分析所選單元數(shù)據(jù)模式的建筑內(nèi)涵來驗證信息傳遞的準確性和語義可傳遞性。由于業(yè)主歷史屬性的層次關系簡單,因此數(shù)據(jù)模式分析主要聚焦于對象布置和幾何表示屬性。
4.2.1 梁單元數(shù)據(jù)模式
圖7 展示了IfcBeam_4072 對象布置屬性的數(shù)據(jù)模式。該屬性主要用于聲明對象的局部坐標系,進而確定構件單元的空間方位。單元實例通過objectPlacement 屬性與自身局部坐標系關聯(lián)。然后,該局部坐標系通過placementRelTo 屬性依次建立起與其他局部坐標系的相對關系,直至關聯(lián)到模型的全局坐標系。圖示IfcAxis2Placement3D 實體源自規(guī)范ISO 10303-42,用于以單個笛卡爾點和兩個正交軸來聲明空間方位或放置坐標系。圖示該實體均用于放置三維坐標系,其中笛卡爾點為坐標系原點,參考方向為局部坐標系X方向,軸方向為局部坐標系Z方向。此外,ISO 10303-42 規(guī)定IfcAxis2Placement3D 代表的局部坐標系與整體坐標系一致時,參考方向和軸方向可以省略。正因如此,圖示inst:IfcAxis2Placement3D_171 實體和inst:IfcAxis2Placement3D_32 實體均只有l(wèi)ocation 屬性。對笛卡爾坐標和方向向量的數(shù)據(jù)模式進行簡化,具體形式可參見文獻[22]中圖4 所示的鏈表結構。依據(jù)圖7 所示的對象布置屬性數(shù)據(jù)模式,IfcBeam_4072 的局部坐標系原點的絕對坐標為(5 600,3 150,5 960),局部坐標X軸和Z軸的方向向量分別為(0,-1,0)與(0,0,1)。
圖7 IfcBeam_4072 對象布置屬性數(shù)據(jù)模式Fig.7 Object placement property schema of IfcBeam_4072
圖8 為IfcBeam_4072 的幾何表示屬性的數(shù)據(jù)模式。IfcShapeRepresentation 實體是表達單元實例幾何形狀的關鍵,其representationType 屬性聲明了單元形狀表示的幾何模型類型,representationIdentifier屬性聲明了單元的形狀表示形式。如圖8(a)所示,該構件的模型類型為映射表示,即此單元實例是通過實體映射生成的。在映射表示中,MappingTarget屬性用于表述生成實體對映射實體執(zhí)行的空間變換。依據(jù)所選單元的縮放比例和轉換坐標系可知,該單元的創(chuàng)建形式采取了不包含笛卡爾變換的直接映射,這與該構件在Revit 中的建模方式契合。圖示Axis 模塊描述了構件在局部坐標系下的方位信息。如圖8(b)所示,梁單元起點為(-3 150,0,200),終點為(3 150,0,200)。根據(jù)圖2 所示構件參數(shù)及構件所屬局部坐標系方位可知,該信息表述是準確的。圖示Body 模塊描述了單元實體建模的信息。如圖8(c)所示,梁單元的拉伸長度為5 980.6 mm,在梁局部坐標系下,拉伸起點為(-2 990.3,0,0),拉伸方向為(1,0,0)。與初始Revit 模型對比可知,該信息表述準確無誤。圖示IfcProfileDef 實體聲明了構件的截面形狀,鑒于建筑構件截面形式多樣,不對截面的語義層次關系進行展開。
圖8 IfcBeam_4072 幾何表示屬性數(shù)據(jù)模式Fig.8 Representation property schema of IfcBeam_4072
4.2.2 柱單元數(shù)據(jù)模式
在建立的鋼框架語義化模型中,柱單元的數(shù)據(jù)模式與梁單元具有相似性。柱單元對象布置屬性數(shù)據(jù)模式的分析結果表明,IfcColumn_421 的局部坐標系與結構整體坐標系一致,原點的絕對坐標為(-16 800,6 300,0)。
圖9 展示了IfcColumn_421 幾何表示屬性的數(shù)據(jù)模式,所示層次關系僅保留與IfcBeam_4072 幾何表示屬性數(shù)據(jù)模式不同的部分。相比于梁單元實例,IfcColumn_421 的數(shù)據(jù)模式僅含有Body 模塊。依據(jù)IfcExtrudedAreaSolid 實體的信息可知,該構件的拉伸長度為3 300 mm。依據(jù)inst: IfcAxis2 Placement3D_347 的轉換坐標系可得,在柱局部坐標系下,構件拉伸方向為(0,0,1),拉伸起點為(0,0,0)。再根據(jù)圖2 所示構件參數(shù)和此構件所屬局部坐標系方位可知,該信息表述是準確的。
圖9 IfcColumn_421 幾何表示屬性數(shù)據(jù)模式Fig.9 Representation property schema of IfcColumn_421
4.2.3 數(shù)據(jù)模式冗余信息分析與規(guī)避
對于項目信息管理而言,幾何表示屬性中由IfcGeometricRepresentationContext 及其子類實例描述的背景信息是冗余的。以圖10 所示的inst:Ifc-GeometricRepresentationSubContext_118 為例,它不但與每一個IfcShapeRepresentation 實體重復關聯(lián),同時所表示的信息也缺乏實際用途,故而導致所創(chuàng)建模型的信息冗余。此外,語義化模型中存在表達相同含義的冗余信息。如圖8 所示,Axis 模塊的OrientationDirection 和 Body 模塊的 Extruded-Direction 均描述了梁單元的拉伸方向。
圖10 幾何表示實體中背景信息的數(shù)據(jù)模式Fig.10 Schema of geometric representation context
為SPARQL 語句設立精確圖模式可有效規(guī)避冗余信息。比如,可為梁柱單元及其拉伸長度查詢設立如下SPARQL 語句:
上述語句對謂詞屬性進行了簡寫,即省略了謂詞的前綴與后綴。依據(jù)此精確圖模式匹配,便能有效規(guī)避冗余信息。此外,基于此精確圖模式編寫DELECT 語句可移除用戶不需要的冗余信息。筆者將此技術應用到所開發(fā)的SemBIMCURD-SJTU軟件中。
通過以上對單元實例的對象布置和幾何表示屬性數(shù)據(jù)模式的分析,語義化模型對于建筑信息交付的準確性和建筑語義的可傳遞性得到驗證。但不容忽視的是,采用的基于IfcOWL 的語義化建模方法仍然存在弊端。具體來說,IfcOWL 完全復現(xiàn)了IFC 標準,這使得所建立的語義化模型數(shù)據(jù)模式復雜,并且存在大量冗余信息。此外,引入IfcOWL本體作語義賦能后的語義化模型體量較大,難以發(fā)揮該模型在知識查詢與推理方面的優(yōu)勢。
通過案例分析驗證了語義化模型進行建筑信息交付的數(shù)據(jù)準確性和語義可傳遞性,進而論證了該建模方法的可行性。此外,通過對所轉化模型數(shù)據(jù)模式進行建筑內(nèi)涵分析發(fā)現(xiàn),于IfcOWL 的語義化建模方法尚未在建筑業(yè)全面推廣有如下原因:
1)建筑業(yè)通用本體不夠完善,IfcOWL 本體數(shù)據(jù)模式完整繼承了IFC 標準,這種復雜的數(shù)據(jù)層次關系制約了模型知識查詢與推理功能的實踐。
2)IFC 模型向RDF 模型轉化數(shù)據(jù)冗余現(xiàn)象突出,完全轉譯IFC 模型信息的語義化建模手段信息傳遞效率較低。
3)建筑項目的信息管理具有大數(shù)據(jù)特征,對所有建筑信息執(zhí)行該語義化建模的經(jīng)濟性和可行性不足。
針對上述問題,除本文提及的冗余信息規(guī)避方法外,還可以結合語義化模型各模塊的建筑信息內(nèi)涵,通過領域本體開發(fā)和輕量化語義建模來實現(xiàn)高效的信息表達和交付,進而將該技術推廣實踐于安全風險分析、建筑性能管理和數(shù)字孿生建模等涉及異源數(shù)據(jù)集成的應用領域。