语义网赋能建筑信息交付及模型数据模式分析

2024-04-11刘吉明段立平林思伟缪季赵金城

土木与环境工程学报 2024年1期

刘吉明 ,段立平,b ,林思伟 ,缪季 ,赵金城,b

（上海交通大学 a.船舶海洋与建筑工程学院；b.上海市公共建筑和基础设施数字化运维重点实验室，上海 200240）

在推行数字化建造的过程中，项目各方信息流通困难、专业软件数据格式各异、建筑信息多源异构及大数据特征等问题严重阻碍了行业智能化转型。这些涉及信息集成、流通与管理的问题可统称为信息交付问题，而传统碎片化、分散式的交付方式已无法满足数字化建造需求，因此亟需革新建筑信息交付方式以打破信息孤岛壁垒。

建筑信息模型（Building Information Modeling，BIM）技术及其信息交付标准工业基础类（Industry Foundation Class，IFC）的兴起为上述问题带来了转机。IFC 是由buildingSMART International（bSI）提出的开放且中立的数据交换格式，其通过描述建筑模型的几何架构、语义架构以及二者的相互关系，实现了对建筑信息的完整描述。也正因如此，IFC被认为适用于建筑全生命周期中的大部分数据交换场景。例如，刘照球等[1]基于BIM 的模型集成框架、赖华辉等[2]基于IFC 标准的信息共享方法、马智亮等[3]基于IFC 标准的建筑能耗监测静态信息模型都有效提升了信息交付效率。然而，由于IFC 标准存在编写语言普及程度低和数据架构复杂、难以拓展的问题[4]，该技术仍无法解决信息交付难题。

此外，通过建立数学表达式或开发算法来建立数学模型的方法也是一种可行的数据集成方式，比如魏国海等[5]的火灾损伤多元信息融合模型、Liu等[6]基于数字孪生的信息融合框架，以及张立奎等[7]用于桥梁变形重构的基于LSTM 神经网络的多元信息融合方法。但现有的数学建模方法无法涵盖所有相关因素，并且所建模型高度抽象，故而也难以在实践中得到推广。

针对以上问题，笔者在IFC 标准基础上引入语义网以克服其局限性。首先，介绍语义网核心技术架构，并分析语义网拓展IFC 功能的可行性。然后，利用Pauwels 等[8]提出的转化方法执行建筑信息语义化建模，通过验证所建模型数据传递的准确性来说明该方法的可行性。最后，分析所建模型的数据模式以探讨制约该技术实践应用的关键因素，并基于分析的数据模式提出冗余信息规避的可行方法。

1 语义网核心技术与IFC 功能拓展

语义网是万维网之父Berners-Lee 等[9]于1998年提出的一种网络技术，旨在解决“传统网络仅作为给用户提供文档的媒介而无法直接处理数据信息”的问题。该技术的主旨是通过机器可理解的统一信息描述来共享暂存信息，而这一功能特征恰与建筑业亟需解决的信息交付难题高度契合。正因如此，语义网赋能建筑信息交付得到学者广泛探究。其中，专研建筑信息智能化的国际组织bSI 不仅成立链接数据工作组（Linked Data Working Group，LDWG）来实现IfcOWL 本体的标准化，同时还将语义网纳入其技术路线图[10]。

1.1 语义网核心技术

Berners-Lee 最早提出了语义网基本架构，其逐步发展完善为现行的语义网堆栈[11]。该技术架构下的资源描述框架（Resource Description Framework，RDF）、本体与网络本体语言（Web Ontology Language，OWL）以及 SPARQL（SPARQL Protocol and RDF Query Language）三项核心技术为其数据表示、逻辑推理和知识查询功能提供支持。

RDF 是万维网联盟（World Wide Web Consortium，W3C）提出的以相互关联的有向标记图描述资源信息的标准框架。通过以主体-谓词-客体的三元组表达式描述资源，实现对多源异构数据的统一表达，进而为语义化建模和知识查询推理奠定数据基础。

本体和OWL 是语义网体系中赋予模型高级知识逻辑的关键模块。本体原为哲学领域概念，知识工程引入该术语以创建自动推理信息模型。OWL特指W3C 推行的OWL2 网络本体语言，是一种旨在表述事物、事物组及事物间关系所蕴含知识的陈述性语言。在语义网架构中，把基于OWL 概念创建的RDF 图称为OWL 本体，用以弥补RDFS（Resource Description Framework Schema）语义丰富度不足的缺陷。图1 所示是W3C 倡议的OWL2本体的分类架构和主要配置文件[12]，其中OWL2 DL 本体在知识推理工具中应用最广。其原因在于OWL2 DL 可产生与SROIQ 描述逻辑兼容的语义，且根据相似理论[13]，其推论足够可信，故推理工具可参照描述逻辑的实践经验进行开发。

图1 OWL2 本体分类及语义层次关系Fig.1 Classification and semantics hierarchy relationships of OWL2 ontology

SPARQL 是基于图模式匹配的RDF 查询语言，可跨数据源作联合查询并返回RDF 图。SPARQL 可对匹配图模式作增删查改，进而实现RDF 数据集的动态更新。除查询外，知识推理也是语义网的重要功能。语义网不仅有源自RDFS 和OWL 的推理逻辑，还可借由SWRL、SPIN 和SHACL 规则语言实现高级知识推理。此外，辅助本体开发的本体推理也是一种知识推理形式[14]。

1.2 语义网拓展IFC 信息交付功能

在实际信息交付场景中，IFC 标准所面临的主要问题是数据模式难以拓展和信息提取修改困难。通过分析各问题致因以及语义网处理该问题的优势，论证了语义网拓展IFC 信息交付功能的可行性。

拓展性问题是指难以扩充既定的IFC 数据模式来满足个性化的信息表述需求，该问题主要源于定义数据模式的EXPRESS 语言。首先，这是一种不常用的声明性语言，难以被建筑业用户所掌握；其次，该语言可定义的信息类型繁杂（可同时定义实体、关系、规则及复杂数据结构），故由其声明的IFC数据模式复杂且难以扩展。bSI 针对该问题提供了自定义属性集和数据字典的解决方案，但前者难以实现术语对齐，后者缺乏灵活性而无法提供有效帮助。语义网能够集成本体和描述逻辑对各领域信息进行个性化知识表示，然后依托本体映射实现语义层面的一致性匹配，进而将IFC 兼容信息与其他信息进行统一表达。因此，语义网技术可有效解决IFC 标准面临的拓展性难题。

IFC 标准的另一个问题是缺乏高效的信息查改方法。IFC-SPF 文件是基于IFC 数据模式编写的纯文本文件，该文件不仅可读性差，而且难以对IFC语句进行修改。Mazairac 等[15]曾为此提出了一种检索IFC 信息的查询语言BIMQL，但该方法不仅只能用于信息查询，还难以被用户掌握，故未得到广泛应用。在语义网被引入建筑领域后，Krijnen 等[16]随即提出利用SPARQL 来弥补BIMQL 存在的不足。其原因在于：首先，SPARQL 用法与SQL 语言类似，容易被用户所掌握；其次，SPARQL 可直接对RDF 图进行增删改查；并且用户还能通过SPARQL 对SPARQL 端点中的RDF 数据进行远程访问，有助于开发项目信息管理的云服务。

除以上优势外，语义网的知识推理功能有助于高效利用建筑信息。在项目管理过程中，所集成数据增多，隐含知识也随即陡增。而挖掘隐含知识对于开发项目管理服务是有益的。如，Wu 等[17]将卷积神经网络识别的人的施工行为信息与人和构件空间关系信息集成，再引入从施工技术规范中转化的SWRL 规则，识别了危险施工行为。因此，语义网有助于让IFC 表达的信息切实服务于实际工程。

2 IFC 标准赋能BIM 信息集成共享

鉴于在IFC 模型基础上进行语义化建模，故对IFC 模型的生成方式和信息转化效率进行分析。

2.1 模型视图定义

模型视图定义（Model View Definition，MVD）是对BIM 模型作数据筛选输出IFC 模型的过滤器。其兴起的原因在于随着BIM 信息交付所涉及领域的不断扩张，IFC 标准面向不同专业的数据冗余问题愈发突出，因此，bSI 推出MVD 作为IFC 标准的子集以适应不同应用需求。

bSI 在其MVD 数据库收录了MVD 的所有可用版本，而在建筑业BIM 软件中得到应用的分别是IFC 2×3 协调视图2.0（Coordination View 2.0，CV 2.0）、IFC4 参照视图及IFC4 设计传递视图。其中CV 2.0 在各类软件中兼容性最好，应用也最为广泛。但bSI 正在积极推进IFC4 标准相关MVD 的研发与推广，从视图所涉范围的广度和更新速度来看，IFC4 全面取代IFC 2×3 标准是必然趋势。

图2 双层钢框架厂房BIM 模型结构示意Fig.2 BIM model of two-story steel frame building

2.2 不同IFC 模型数据转化效率对比

为对比经不同MVD 输出IFC 模型的数据转化效率，选取如图2 所示的双层钢框架厂房结构作案例分析。利用集成式IFC 解析器（https://github.com/Autodesk/revit-IFC）从Revit 中以CV 2.0、参照视图和设计传递视图分别输出IFC 模型，将其分别读取并汇总信息，如表1 所示。在所有输出模型中，参照视图（结构）丢失信息最为严重，该视图因忽略楼板的信息输出，直接导致实体总数异常；CV2.0 因对梁实体的区分只考虑构件截面类型而忽视建模方法与梁长差异，故输出的实体关系信息偏少；至于设计传递视图，由于其材料关系定义采取实例与材性映射方式，因而此关系数目多于其他输出结果，从语义化建模角度来看，这种表达形式能够涵盖更完备的构件信息，有助于提高语义化建模精度。

表1 钢框架厂房各MVD 输出模型组成信息汇总Tab.1 Composition information of each MVD output model of the steel frame structure

针对该案例的楼板信息转化结果，进一步对比各输出模型转化效率。楼板采用压型钢板-混凝土组合楼板，Revit 建模时采用双层组合形式。在楼板的信息转化过程中，参照视图与CV 2.0 只能将其简化为单层混凝土构件；并且前者还缩减了楼板的实体关系，尤其是材料关系的输出，导致建筑信息严重丢失。而设计传递视图对于组合楼板的信息转化效果明显优于前述视图，该视图不仅有效保留了构件应有的实体关系，还能将组合楼板以双层形式正常输出。因此，设计传递视图输出模型在保真度和信息丰富度方面有明显优势。

3 建筑信息语义化建模及其转化机制

语义化建模旨在以RDF 对IFC 实体信息作资源虚拟化。针对此转化需求，Karan 等[18]通过集成自定义BIM 本体与地理信息系统（Geographic Information Systems，GIS）本体来处理IFC 属性，进而生成BIM 与GIS 集成的RDF 模型；W3C 则致力于研发以BOT（Building Topology Ontology）为代表的轻量化本体[19]，并且由Bonduel 等[20]开发出的IFCtoLBD 转换器实现了基于BOT 本体的RDF 建模；此外，Niknam 等[21]也提出了一种可用于建筑信息共享的通用本体BIMSO。与上述3 种方法相比，Pauwels 等[8]倡议的基于IfcOWL 本体的转化方法能够对IFC 兼容的所有建筑信息执行语义化建模，在适用性与技术成熟性方面更具优势，因此应用其开发的IFCtoRDF-0.4 转换器（https://github.com/pipauwel/IFCtoRDF）作语义化建模。

对于已开发的IfcOWL 本体而言，IFC4 对应本体相较于IFC 2×3 对应本体在类层次关系及公理数目上更具优越性，再结合前文各IFC 模型的转化效果，最终选定设计传递视图输出模型进行语义化建模。建模步骤分为IFC-SPF 文件向Turtle 文件转化和引入IfcOWL 本体实现高阶语义赋能。在JDK17 的编译环境中启动转换器并执行文件转化，然后将初始RDF 模型导入Protégé 本体编辑器，最后用IfcOWL 本体为该模型赋予建筑语义内涵。

3.1 IFC to RDF 转化算法解析

为明晰转换器的工作原理，通过IntelliJ IDEA将其运行于maven 项目，并对其转化机制作源码分析。如图3 所示，主程序涵盖了IFC 模型转化从参数输入到初始RDF 模型输出的全过程；程序根据命令行参数自动识别转化模式，依次调用showFile()、setup()与convert()方法执行文件读取、规范设置和格式转化，并最终输出初始RDF 模型。其setup()方法用于确定IFC 标准的版本并导入为文件转化提供规范参照的序列化文件；convert()方法则实现了文件解析、本体注册、资源创建以及三元组编写。鉴于此二者在文件转化中的重要作用，图3 也对其运行流程予以展示。为提升所绘流程图的可读性，对某些不可能发生的条件分支进行甄别。例如，在转化模块的红框标识步骤，参照合法IFC 语句，不会将Type 类型实体作为其实体声明，把程序针对该情况对应的条件分支予以省略。

图3 IFCtoRDF-0.4 转换器运行流程Fig.3 Flow chart of IFCtoRDF-0.4 converte

转换器执行文件转化的核心步骤包括参考标准导入、IFC 语句解析和三元组编写。在设置模块中，通过反序列化IFC 标准的序列化文件导入参考标准；在转化模块加粗蓝框标识步骤中，调用parseIfcLineStatement()解析IFC 语句；三元组则在转化模块不同步骤中根据其类别调用特定方法予以编写。为分析语句解析的基本逻辑，绘制如图4（a）所示的算法伪代码。图示switch 分支语句的前两项分别完成语句编号和实体名称的解析，后两项则联合完成括号内各属性值的解析。在该算法中，程序主要利用IFC 语句的特定字符对控制条件state 作调控，进而执行恰当的分支语句以完成语句解析。另外，对于属性值为数组甚至是多维数组的复杂情形，程序则利用栈数据结构和双向链表数据结构进行分层解析。

图4 转化模块关键算法的运行逻辑Fig .4 Execution logic of key algorithms in convert module

IFC 语句对应三元组主要源于属性信息的转化，如图3 中属性转化子模块所示，程序将依据属性值所属类型来执行相应分支语句，进而编写三元组。分析了字符串属性值转化分支的运行逻辑，并将该分支调用的fillPropertiesHandleStringObject()方法的算法伪代码绘图如图4（b）所示。此算法的核心在于识别属性类别以及创建并添加属性资源集合键值对，主要遵循从字面值赋值到顶层属性赋值这一自下而上的逻辑。对于转化过程中遇到的非常规情况，将以不同级别示警在运行日志中予以提示。其余转化分支虽然具体流程与前述算法略有区别，但转化逻辑类似，可参照理解。

利用此转换器输出双层钢框架厂房的初始RDF 模型并导入Protégé 应用程序，由于转化过程已基于Apache Jena 框架实现本体类的注册，故可引入IfcOWL 完成建筑语义赋能。

4 语义化建筑信息模型数据模式分析

为探讨基于IfcOWL 语义化建模方法未得到有效使用的可能原因，对语义化模型单元实例的数据模式进行分析。鉴于RDF 模型数据模式的通用性，此内容也将为建筑信息的知识存取与逻辑推理研究提供技术参照。

4.1 建筑单元实例属性分析

建筑单元实例是指具体构件的实例对象。图5所示为分析案例涉及到的梁、板、柱构件的继承关系；图示层次关系采取了与IFC 模式一致的类继承方式，故而两种信息表达方式在类层次关系上具有一致性。

图5 RDF 模型中建筑单元的类继承关系Fig.5 Class hierarchy relationships of building elements in RDF model

在RDF 模型中，建筑单元实例的语义化描述均由图6 所示语义层次关系表示。如图6 所示，单元实例所具有的属性皆为对象属性，各属性所在三元组主体（定义域）皆为实例对象本身，三元组客体（值域）为字面值或RDF 资源。其中赋值三元组直接阐述了建筑单元的名称、标签和类型信息，3 个RDF 子图涵盖了业主历史、对象布置和几何表示的相关信息。此外，图6 所示图例说明了在执行数据模式分析时使用的各节点符号的具体含义。

图6 构件实例对象的属性架构Fig.6 Object property schema of building elements

4.2 梁柱单元数据模式分析

梁柱单元是钢框架结构主要的构件形式，因此，选取图2 中标识的单元实例IfcBeam_4072 和IfcColumn_421 进行数据模式分析，通过分析所选单元数据模式的建筑内涵来验证信息传递的准确性和语义可传递性。由于业主历史属性的层次关系简单，因此数据模式分析主要聚焦于对象布置和几何表示属性。

4.2.1 梁单元数据模式

图7 展示了IfcBeam_4072 对象布置属性的数据模式。该属性主要用于声明对象的局部坐标系，进而确定构件单元的空间方位。单元实例通过objectPlacement 属性与自身局部坐标系关联。然后，该局部坐标系通过placementRelTo 属性依次建立起与其他局部坐标系的相对关系，直至关联到模型的全局坐标系。图示IfcAxis2Placement3D 实体源自规范ISO 10303-42，用于以单个笛卡尔点和两个正交轴来声明空间方位或放置坐标系。图示该实体均用于放置三维坐标系，其中笛卡尔点为坐标系原点，参考方向为局部坐标系X方向，轴方向为局部坐标系Z方向。此外，ISO 10303-42 规定IfcAxis2Placement3D 代表的局部坐标系与整体坐标系一致时，参考方向和轴方向可以省略。正因如此，图示inst:IfcAxis2Placement3D_171 实体和inst:IfcAxis2Placement3D_32 实体均只有location 属性。对笛卡尔坐标和方向向量的数据模式进行简化，具体形式可参见文献[22]中图4 所示的链表结构。依据图7 所示的对象布置属性数据模式，IfcBeam_4072 的局部坐标系原点的绝对坐标为(5 600,3 150,5 960)，局部坐标X轴和Z轴的方向向量分别为(0,－1,0)与(0,0,1)。

图7 IfcBeam_4072 对象布置属性数据模式Fig.7 Object placement property schema of IfcBeam_4072

图8 为IfcBeam_4072 的几何表示属性的数据模式。IfcShapeRepresentation 实体是表达单元实例几何形状的关键，其representationType 属性声明了单元形状表示的几何模型类型，representationIdentifier属性声明了单元的形状表示形式。如图8（a）所示，该构件的模型类型为映射表示，即此单元实例是通过实体映射生成的。在映射表示中，MappingTarget属性用于表述生成实体对映射实体执行的空间变换。依据所选单元的缩放比例和转换坐标系可知，该单元的创建形式采取了不包含笛卡尔变换的直接映射，这与该构件在Revit 中的建模方式契合。图示Axis 模块描述了构件在局部坐标系下的方位信息。如图8（b）所示，梁单元起点为(－3 150,0,200)，终点为(3 150,0,200)。根据图2 所示构件参数及构件所属局部坐标系方位可知，该信息表述是准确的。图示Body 模块描述了单元实体建模的信息。如图8（c）所示，梁单元的拉伸长度为5 980.6 mm，在梁局部坐标系下，拉伸起点为(－2 990.3,0,0)，拉伸方向为(1,0,0)。与初始Revit 模型对比可知，该信息表述准确无误。图示IfcProfileDef 实体声明了构件的截面形状，鉴于建筑构件截面形式多样，不对截面的语义层次关系进行展开。

图8 IfcBeam_4072 几何表示属性数据模式Fig.8 Representation property schema of IfcBeam_4072

4.2.2 柱单元数据模式

在建立的钢框架语义化模型中，柱单元的数据模式与梁单元具有相似性。柱单元对象布置属性数据模式的分析结果表明，IfcColumn_421 的局部坐标系与结构整体坐标系一致，原点的绝对坐标为(－16 800,6 300,0)。

图9 展示了IfcColumn_421 几何表示属性的数据模式，所示层次关系仅保留与IfcBeam_4072 几何表示属性数据模式不同的部分。相比于梁单元实例，IfcColumn_421 的数据模式仅含有Body 模块。依据IfcExtrudedAreaSolid 实体的信息可知，该构件的拉伸长度为3 300 mm。依据inst: IfcAxis2 Placement3D_347 的转换坐标系可得，在柱局部坐标系下，构件拉伸方向为(0,0,1)，拉伸起点为(0,0,0)。再根据图2 所示构件参数和此构件所属局部坐标系方位可知，该信息表述是准确的。

图9 IfcColumn_421 几何表示属性数据模式Fig.9 Representation property schema of IfcColumn_421

4.2.3 数据模式冗余信息分析与规避

对于项目信息管理而言，几何表示属性中由IfcGeometricRepresentationContext 及其子类实例描述的背景信息是冗余的。以图10 所示的inst:Ifc-GeometricRepresentationSubContext_118 为例，它不但与每一个IfcShapeRepresentation 实体重复关联，同时所表示的信息也缺乏实际用途，故而导致所创建模型的信息冗余。此外，语义化模型中存在表达相同含义的冗余信息。如图8 所示，Axis 模块的OrientationDirection 和 Body 模块的 Extruded-Direction 均描述了梁单元的拉伸方向。

图10 几何表示实体中背景信息的数据模式Fig.10 Schema of geometric representation context

为SPARQL 语句设立精确图模式可有效规避冗余信息。比如，可为梁柱单元及其拉伸长度查询设立如下SPARQL 语句：

上述语句对谓词属性进行了简写，即省略了谓词的前缀与后缀。依据此精确图模式匹配，便能有效规避冗余信息。此外，基于此精确图模式编写DELECT 语句可移除用户不需要的冗余信息。笔者将此技术应用到所开发的SemBIMCURD-SJTU软件中。

通过以上对单元实例的对象布置和几何表示属性数据模式的分析，语义化模型对于建筑信息交付的准确性和建筑语义的可传递性得到验证。但不容忽视的是，采用的基于IfcOWL 的语义化建模方法仍然存在弊端。具体来说，IfcOWL 完全复现了IFC 标准，这使得所建立的语义化模型数据模式复杂，并且存在大量冗余信息。此外，引入IfcOWL本体作语义赋能后的语义化模型体量较大，难以发挥该模型在知识查询与推理方面的优势。