明清木结构古建筑汇聚了卓越的营造工艺,具有深厚的文化内涵和极高的研究价值,是建筑文化遗产保护的重点
[1]. 传统的古建筑保护通常依赖人工维护,存在保护周期长、消耗资源多、主观性强等不足
[2-3]. 随着数字化手段在古建筑保护领域的广泛应用,减少资源消耗、提高保护效率的目标得以实现
[4-5]. 但名目繁多且结构复杂的存储方式阻碍了信息跨平台交互
[6-7],根源在于该领域缺乏标准统一的信息媒介.
Murphy等
[8]和Dore等
[9]提出古建筑信息模型(historic building information modeling,HBIM)概念,用来记录和管理古建筑全生命周期信息,展现出信息管理潜力
[10-11]. 该方法能够确保各相关方有效参与并实现信息共享
[10]. 其对信息交互问题的解决取决于平台支持的交互格式. 此外,利用数据库存储非几何遗产信息也是常用手段之一,其通过对象属性间的关联进行存储表达,这与文物保护中的“类型学”原理类似
[12]. 一些学者将数据库与BIM相结合,通过发挥数据库数据整合的优势来处理BIM中逐渐增多的信息
[13-14]. 然而,研究结果表明这种数据库方法在数据整合时不仅要求专业人员具有较高技术水平,还极易出现描述对象匹配不一致的状况,因而未能从根本上解决遗产信息存储问题.工业基础类(industry foundation classes,IFC)作为一种开放、标准的中间格式,为解决此类信息存储与传递问题带来了新思路
[15]. Wang等
[16]在IFC标准体系下进行扩展,成功实现了古建筑残损监测信息的表达与应用. 但就目前而言,IFC体系中缺少有关古建筑领域本体语义的信息表述,如何在该体系中全面、准确、快速地建立古建筑信息框架是该领域亟待解决的难题.
本文基于本体论及国际文献工作委员会概念参考模型(International Committee for Documentation conceptual reference model,CIDOC CRM,简称CRM)提出了一种明清木结构古建筑IFC架构的构建方法体系. 首先借助本体框架明确明清木结构古建筑的信息传递需求;在此基础上结合CIDOC CRM建立了明清木结构古建筑遗产信息描述框架;最后将该框架映射至IFC标准,完成IFC架构的表达. 结合文物保护领域的CIDOC CRM,最大限度确保明清木结构古建筑描述框架的完整性;同时,实现了明清木结构古建筑在国际建筑信息统一标准IFC中的完整表达,从标准化角度为领域内遗产信息存储难题提供了进一步的解决方案.
1 CIDOC CRM
CRM通过形式化描述定义了文化遗产信息涉及的知识
[17],提供了一个兼具普适性和可扩展性的语义框架.将CRM中的实体与古建筑领域具体语义进行匹配,可使得CRM框架具备描述领域信息的功能.
在CRM中,实体以“E”开头,实体架构描述由抽象到具体递进;属性以“P”开头,根据作用的实体对象不同进行划分. 尽管CRM中的实体及属性与IFC体系在表达形式上存在差异,但二者在实体及连接关系的划分原则上类似,均按照连接对象划定边界.
2 明清木结构古建筑CRM定义
2.1 明清木结构古建筑遗产信息框架
明清木结构古建筑(以下简称“古建筑”)相较于唐、宋时期的古建筑,在斗栱形制、榫卯技术以及彩绘装饰等方面均存在差异,所对应的遗产信息也各有不同. 清代颁布的《工程做法则例》针对古建筑的营造设计、材料选用、形制规格等制定了规范化的表述,是对前朝营造方法的传承与提升,本文主要依据《工程做法则例》梳理古建筑遗产信息框架.
古建筑遗产信息包含了其存续期间所衍生的营造技艺、人文背景以及艺术表现等多维度信息. 这些信息由管理方统一提取并应用于残损修缮、科学研究和文化价值挖掘等多个领域. 本文聚焦于古建筑遗产信息在全生命周期内的跨专业交互情况,通过深入剖析信息内容和交互流程,来明确各参与方的信息需求. 根据不同专业领域和使用阶段进行细致划分后,最终构建了覆盖全时域和全领域的古建筑遗产信息框架.
本文将古建筑保护工程中的遗产信息分为营造、文保、艺术、残损和修缮5个核心维度,将全生命周期总结为日常维护和工程修缮保护两大部分. 其中,工程修缮保护涵盖勘察、设计、施工及验收4个阶段,而各个阶段又包含运维管理、勘察设计和施工这3个参与方. 各方信息交互的内容及需求点如
表1所示.
2.2 古建筑CRM实体定义
借助成熟的CRM模型对每个维度的遗产信息予以表达. 实体的构建是在其原始概念类的基础上完成的,针对概念模型中所缺失的古建筑特有的要素进行定义和补充,同时根据领域特性,对概念类实施扩充和分层管理,进而实现古建筑实体的定义. 古建筑CRM实体定义如
表2所示,其中标签名称以“E”开头的是CRM原有实体,以“T”开头的是根据古建筑特定要素添加的新实体.
2.3 古建筑CRM属性定义
在CRM中,属性用于描述实体之间的特定关系. 通过区分不同实体对象及其所表达的关系,进行概念定义并赋予一定的限定域值,确保连接的完整性. 属性除了具备连接实体的作用外,还应具备实际的意义关系,属性的值域也是定义属性时必不可少的一个部分,有效地约束属性值域可以建立更有效的实体属性,从而提高知识图谱的丰富性. 根据关系内容和所表达语义的不同,可对涉及的古建筑属性关系进行定义,属性定义如
表3所示,其中以“P”开头的为CRM原有属性,“Q”开头的为新增属性.
3 古建筑CRM知识图谱创建
3.1 CRM营造知识图谱创建
古建筑营造信息是古建筑在空间组成及构件功用等方面所蕴含的特征信息,可分为“空间实体”“单元实体”“构件实体”“分类实体”4个板块,从空间和分类两个维度(E55 Dimension)进行描述. 构建完成的营造知识图谱如
图1所示.
空间实体是对各类古建筑营造要素所构成的内外部空间的统称. 梁思成
[18]将古建筑根据空间位置划分为阶基、墙柱、斗栱和屋顶4个空间层级. 这4个层级不仅包含几何尺寸描述信息,还涵盖古建筑特有的建筑语义. 每个层级包含的构件可认为是通过人为分类集合而成的,因此以E99产品分类实体进行表达.
在每个建筑空间层级中都包含多个建筑实体,刘敦桢
[19]将古建筑构件分为台基、踏跺、斗栱等建筑单元. 依此原则,在古建筑E99空间单元中可包含多个E24单元实体(Physical Human-Made Thing),根据建筑功用不同对每个单元实体再划分. 每个功能单元内包含多个E22构件实体(Human-Made Object).
分类实体是依据《工程做法则例》中的工艺做法和材质语义规则对古建筑构件再分类. 将涉及的工程分为木作、瓦作和石作等13类,这些类别信息以E99产品分类实体来表达. 每个类别分别从古建筑的形制、工艺、材质、尺寸4个方面进行阐述,因此分别使用T1制作信息、E57材料信息进行表述.
3.2 CRM文保、艺术知识图谱创建
文保实体与艺术实体在信息表达方面存在颇多相似之处. 文保、艺术等抽象概念适用于E2临时实体(Temporal Entity),从二者的异同进行描述.
一方面,文保、艺术的创作属于事件,均包含E4时间段(Period)、E27发生/创作地点(Place)和E39参与/创造人员(Actor)3个基本要素. 另一方面,二者在信息属性上的区别在于其信息描述方法和侧重点. 历史事件需使用E4时间段实体描述其存续状态,还需用E6时间点(Time Primitive)实体记录其创作时间. 同时,文物的艺术价值不仅是艺术信息的表达,还融合了当时的历史、人文信息,因此需要表达E31背景信息(Document). 历史事件在表达时同样需要E31背景信息,以及产生的E31历史影响信息. 最后,由于古建筑艺术品本身具备一定的价值属性,因此还应考虑E59古建筑艺术价值(Primitive Value)信息.
图2为文保、艺术知识图谱.
3.3 CRM残损、修缮知识图谱创建
残损实体与修缮实体之间存在密切关联.在CRM原有实体E11变化(Modification)下新增T3残损实体(Degradation Entity)来表达古建筑残损. 在勘察中,残损需记录发生E4时间、Q5位置(has worsen)等基本信息,以及影响、形态、类别等描述信息以E99分类表达. 残损发生后进行E7残损勘察(Activity),并形成相应的E13残损勘察信息(Attribute Assignment),将这些信息汇总成文本,形成E31残损的勘察报告信息(Document).
修缮信息的表述类似于残损信息. 需要在E11实体下扩充T5修缮实体(Restoration Entity). 在信息描述上,修缮工程的工程活动性质包含E4时间、Q3修缮关系(has replaced)、E39修缮人员3个基本要素. 修缮完成后还会形成附加于古建筑本身的E13修缮工程信息(Attribute Assignment). 竣工验收后,所有过程修缮信息同样会被整理成为E31保护工程修缮信息报告(Document).
图3为残损、修缮知识图谱.
4 古建筑IFC实体映射
4.1 IFC标准架构关系
在IFC框架中,描述工程信息主要涵盖3大实体、两类属性及6种连接关系. 其中,3大实体包括项目的基本信息实体、工程实例实体以及工程类型实体定义;两类属性分别是包含属性内容的静态属性和包含属性关系的动态属性;6大连接关系包括声明关系、关联关系、定义关系、分配关系、连接关系以及分解组合关系,用于实现信息的关联表达.
一个完整的IFC数据描述由多个不同的部分通过6类关系关联组合而成. 每个IFC文件仅包含一个项目实体(IfcProject),通过关联关系上下文实体(IfcContext)规定了项目的类型库、单位、精度等基本信息,且分别与项目计划资源描述的工作计划实体(IfcWorkPlan)及项目结构描述的空间场地实体(IfcSite)进行连接. 工作计划主要通过关联外部工程资源与项目实体,实现项目进度、资源、成本等信息的管理目的,具体组成模式如
图4所示.
空间场地实体(IfcSite)与建筑实体(IfcBuilding)和项目的坐标实体(IfcCoordinateReferenceSystem)通过关联关系连接(IfcRelAssociates),构建项目的基本几何描述框架. 楼层实体(IfcBuildingStorey)通过逻辑关联多个构件实例实体(IfcProduct)及类型实体(IfcTypeProduct)来表达物理模型.
4.2 映射原则
CRM与IFC并没有直接的映射规则,本文针对覆盖领域、全生命周期应用与建筑领域关系等因素,确定古建筑IFC实体映射应遵循以下原则:
1)标准架构应与建筑工程领域的总体架构体系和层次描述原则保持一致.
2)映射的古建筑架构应与已发布的IFC标准保持最大限度的兼容.
3)尽量沿用既有实体进行扩展,可增加属性来扩充实体,赋予更多维度的描述方法.
4)若原有IFC实体无法完整表达CRM实体语义,则需要定义新增实体进行映射.
4.3 营造实体映射
根据CRM,古建筑的营造实体由营造构件、类型关系组合和空间组合描述,分别与IFC中的建造实体(IfcBuiltElement)、组实体(IfcGroup)以及空间实体(IfcSpatialElement)相对应,其映射框架参见
图5.
IFC实体具有继承性,底层的IfcBuiltElement实体能通过其父级实体(如IfcObjectDefinition、IfcProduct等)继承属性来表达定义、资源、引用、嵌套等多种关系. 统计发现,既有的IFC建筑构件实体已能实现平面坐标、形状几何、材质属性、对象关联、空间关联、物理运算等6个方面的定义及表达,因此可沿用IFC中的构件实体的部分语义. 但对于
图1中古建筑所特有的构件语义、榫卯连接、空间语义、彩绘做法,仍需要在IfcBuiltElement基础上进行扩充,如
图6中扩展营造实体所示.
4.4 文保、艺术实体映射
通过CRM知识图谱可了解到,古建筑的文保、艺术价值依附于古建筑构件本身,但与其他属性的不同之处在于,古建筑的文保、艺术价值本身是一种抽象元素,不存在与之对应的实体对象. 作为一种非几何的价值信息,文保、艺术价值会随着时间的推移而发生变化,而且与构件实体相伴相生.
如
图5所示,在IFC中描述这类非几何实体信息资源主要涉及两类实体. 第一类是IfcContext,用于存储项目基本信息. 它是各种对象实体的容器,包括项目实体IfcProject和项目库实体IfcProject- Library两个子类. 每个项目模型只能有一个IfcProject实体,用于定义模型单位和几何表达. 相反, IfcProjectLibrary用于提供某类型对象实体放置环境的实体,例如建筑构件、设备库等. 第二类实体则是派生自IfcObject的IfcResource实体,用于表示抽象实体信息,如成本、进度等. 其继承了IfcObjectDefinition的嵌套、声明、指派关系及IfcObject的声明接收、定义关系. 此外,该实体还具备描述实体及分配关系属性实体IfcRelAssignsToResource. 通过这些关系,可以实现时间段内与构架之间的分配. 这种特征与古建筑的文保、艺术信息表达特征非常相似,因此IfcResource实体能够满足古建筑文保和艺术两类非几何实体资源分配的需求.
但目前,IfcResource仅涵盖了人力、材料、产品、分包等生产过程所需资源的分配属性,缺乏对建筑艺术和文化遗产价值资源的分配能力,在一定程度上限制了其应用范围. 因此,需要扩展IfcResource以满足对建筑艺术和文化遗产价值资源的描述需求,如
图6的扩展文保、扩展艺术实体所示.
4.5 残损、修缮实体映射
残损实体与修缮实体均具有空间几何表达需求,同时,作为劣化、补强实体,具备独特的功用语义表达. 因此,在表达残损、修缮实体时需要考虑其几何、语义的表达. 此外,这两者作为附属实体不能单独存在,还要考虑其与构件连接关系的表达. 由于二者不具备任何工程语义,但仍然具有资源的连接和指派关系,因此可以考虑使用IfcElement来实现它们的几何和连接关系表达. 然而,由于它们具有独特的时间、等级和做法表达属性,这些属性与已有的IfcElement下的实体元素不同,因此需要在其基础上进行扩展.
残损和修缮与构件之间的联系属于物体元素在物理意义上的连接关系. 这种关系是一对一的,仅用于表达连接对象之间的逻辑. 考虑到这一特点,可使用连接关系实体IfcRelConnectsElements来表达残损构件及修缮构件之间的对象连接关系. 然而,修缮工程并不仅作用于实体本身,也涉及对残损实体的改造和扩充. 因此,修缮工程与残损实体之间也存在连接关系. 这种三方语义关系是目前IFC实体无法表达的,可以基于连接关系实体 IfcRelConnectsElements来扩充表达修缮连接关系IfcRelConnectsWithRestoration,以实现对修缮实体三方连接属性的表达. 派生关系如
图6的扩展残损、修缮实体所示.
5 案例验证
5.1 案例基本信息
本文以西安都城隍庙大殿(简称大殿)为例,通过对案例中的典型古建筑遗产保护全生命周期的信息需求进行分析,验证所建立的IFC表达框架的完备性.
大殿始建于明洪武二十年,面阔五间,进深三间,单檐庑殿顶,清雍正年间大殿曾遭火灾,后修复,大殿既参考了明代的工艺做法,又极具清代营造特色,属于典型的明清木结构古建筑. 大殿现场及BIM模型图如
图7所示.
5.2 信息需求分析及需求验证
在大殿的保护工程中,不同阶段重点工作内容如下:
1)运维阶段:对大殿进行日常巡检、监测,定期检测及清洁维护等.
2)勘察阶段:整理历史资料,现场勘测等.
3)设计阶段:修缮设计、抢险加固设计,编制文件与图纸、方案会审等.
4)施工阶段:施工组织设计,结构加固与修缮,装饰修复,进度造价管理等.
5)验收阶段:工程质量验收、竣工验收及竣工报告编制等.
提取具体工作内容细节与对应的信息需求并与建立好的CRM知识图谱进行对应. 如
图8所示,以大殿檐柱及上部斗栱为例:在构件测绘、资料记录等工作中需明确构件类别(E22构件实例:檐柱)、尺寸材质(T1工艺做法:木作)等信息;在残损检测、修缮设计等工作中需明确梁下(Q5位置)裂缝(E99残损种类)、损伤程度(E99残损分级)、长宽深(E13勘察信息添加)等信息,括号内为CRM知识图谱中对应实体或属性. 依据实体映射后的IFC表达框架,在IfcBuildElement基础上扩展表达檐柱、斗栱类别、尺寸、材质等信息;裂缝损伤程度、尺寸信息在IfcElement基础上进行扩展表达. 大殿保护工程各阶段信息需求与IFC表达框架中对应实体如
表4所示.
5.3 扩展实例
选取斗栱为实例进行IFC扩展示意,以IfcElement为基础,新建子类实体IfcBracketSet,综合考虑专属遗产信息及独有结构语义表达,新建IfcBracketSetTypeEnum枚举类型表达不同类型斗栱构造语义,尺寸参数以长度实体IfcLengthMeasure及曲率丈量实体IfcCurvatureMeasure表达,营造年代以新建的年代实体IfcDynasty表达,ID属性以标签描述实体Ifc Identifier表达, 彩绘做法以文本描述实体IfcText表达. 斗栱EXPRESS语义描述如
表5所示.
通过总结和对比大殿保护工程过程中的信息需求,发现建立的IFC框架能够满足古建筑项目各阶段实际需求的遗产信息交互,具备科学性和实践性. 以往的项目实践中,不同阶段的信息分别存储在不同的信息环境中,不仅导致遗产信息难以交互,而且因降低了遗产信息的沟通效率. 区别于以往案例,本项目将各方信息整合至一个IFC模型中,避免了信息孤岛和交互困难. 不仅明确了遗产信息内容,还降低了信息调用成本、提升了信息使用效率,为未来的数字化保护提供了可借鉴的经验和支持.
6 结 论
为促进古建筑领域的BIM信息共享,提高古建筑保护领域的数字化管理水平,本文通过建立明清古建筑CIDOC CRM知识图谱,在此基础上结合IFC建筑领域架构,建立了明清木结构古建筑IFC的描述框架. 主要结论如下:
1)梳理了明清木结构古建筑遗产信息多维度内容. 将遗产信息分为营造、文保、艺术、残损和修缮5方面要素,与古建筑保护工程全生命周期各参与方交互信息相对应.
2)建立了明清木结构古建筑遗产信息表达框架. 根据保护过程中涉及的信息交互,定义了明清木结构古建筑CIDOC CRM模型实体、属性. 在此基础上,结合古建筑遗产信息要素,提出了明清木结构古建筑信息模型数据存储国际标准CIDOC CRM知识图谱.
3)完成了明清木结构古建筑IFC实体定位映射. 基于建立的CIDOC CRM明清木结构古建筑知识图谱,实现了模型实体的定位,以确保遗产信息的完备性和有效性. 在IFC体系中建立了明清木结构古建筑遗产信息表达框架.
陕西省重点研发计划项目(2024SF2-GJHX-65)
Key Research & Development Program of Shaanxi Province(2024SF2-GJHX-65)
西安市社会发展科技创新示范项目(23SFSF0013)
Demonstration Project for Social Development and Technological Innovation in Xi’an City(23SFSF0013)