标准导读｜ISO 16739-1:2024 建筑和设施管理行业数据共享的行业基础类（IFC） 第 1 部分：数据模式

在 IFD–IFC–IDM 这组常被并提的 openBIM 基础标准中，IFC 是最常被提起、也最常被误解的一个。很多项目把“提交 IFC 文件”写进合同，交付后却发现模型能打开，构件的类型、属性和位置关系却对不上。问题往往不在文件本身，而在于对 IFC 究竟规定了什么、没有规定什么缺少清楚认识。

本系列前两期分别讨论了 ISO 12006-2 的分类框架和 ISO 12006-3 的数据字典模型。本期转向这组标准中的“数据”一角：ISO 16739-1:2024 如何把一个工程对象写成不同软件都能解析的结构化数据。

标准档案

一、模型交出去以后：IFC 要解决的问题

假设情境：某综合楼项目中，建筑专业用一种设计软件完成了外墙建模，节能顾问要用另一种软件计算围护结构传热，造价单位还要按国标分类统计工程量。三方各自的软件都有“墙”，但内部的数据结构、属性名称和几何算法各不相同。若没有中立的公共结构，每两种软件之间都要单独开发转换接口，参与方越多，接口数量越接近两两组合的增长。

IFC 的思路是在各软件之外约定一套公共数据模式：每个软件只需实现与 IFC 之间的导入导出，便能与其他实现了 IFC 的软件交换信息。

ISO 16739-1 把 IFC 界定为一项开放的国际标准（注意，不是所谓的“国外标准”），对象是建筑信息模型（BIM）中使用、并在建设和设施管理行业各参与方的软件之间交换和共享的信息。范围覆盖建筑与基础设施工程从提出需求、可行性研究、设计、采购、施工到运行维护的全生命周期。

这里要分清两件事。ISO 16739-1 规定的是数据模式（data schema），即可以表达哪些对象、属性和关系，以及它们必须满足的约束；它不规定某个项目必须交付哪些信息。后者属于信息需求的范畴，由 ISO 29481（IDM）、ISO 19650 系列的信息要求，以及下文提到的模型视图定义（MVD）和信息交付规格（Information Delivery Specification，IDS）等配套技术措施来回答。

在 IFD–IFC–IDM 的分工中，ISO 12006-3 回答“数据所指的概念是什么”，IDM 回答“哪个环节需要哪些信息”，IFC 回答“这些信息如何写下来”。

版本沿革

IFC 由 buildingSMART International（前身为国际互操作联盟 IAI）自 1994 年开始开发，经 ISO 发布为国际标准，中国建筑标准设计研究院、铁路 BIM 联盟、中国交通建设集团等组织深度参与了制定工作。按 buildingSMART 的规范数据库和版本说明，主要版本及其特点如下：

二、总体方法：EXPRESS 模式与四层架构

IFC 用 ISO 10303-11 定义的 EXPRESS 语言书写。EXPRESS 是 STEP 产品数据标准族的建模语言，可以声明实体（entity）、特性（attribute，实体自身声明的数据项，有别于后文属性集中的属性 property）、继承关系、枚举数据类型以及用规则表达的约束（形式化命题，formal propositions）。

按 EXPRESS 模式组织的数据可以写成 ISO 10303-21（交换文件结构的纯正文编码）规定的 STEP 物理文件，即常见的 .ifc 文件；也可以写成 ISO 10303-28（EXPRESS 模式与数据的 XML 表达）规定的 XML 文件，即 .ifcXML 文件。

注：上述三项 ISO 标准是 ISO 16739-1 的全部规范性引用文件，分别对应国家标准 GB/T 16656.11—2010、GB/T 16656.21—2008 和 GB/T 16656.28—2010。

IFC 由多个数据模式（schema）组成，每个模式归入四个概念层中的一层（图 1）：

1. 资源层（Resource layer）：几何、拓扑、材料、度量单位、日期时间等基础定义。资源层定义没有全局唯一标识符（GUID）。按 IfcRoot 条的说明，资源层实体不是 IfcRoot 的子类型，不作为独立实体使用，而是被上层实体引用。
2. 核心层（Core layer）：内核模式及核心扩展模式，提供最一般的实体定义。从这一层起，所有实体都带有全局唯一标识符，并可携带所有者与历史信息。
3. 互操作层（Interoperability layer）：跨专业通用的产品、过程或资源特化，如墙、板、门窗等，主要服务于专业之间的信息交换与共享。
4. 领域层（Domain layer）：特定专业的特化，如暖通、给排水、结构分析、铁路、水运中的对象，主要服务于专业内部的交换。

图 1　含概念层的数据模式架构。ISO 16739-1:2024 引言 Figure A 的中文译制图。

读图 1 时可以从下往上看：资源层提供几何、材料、单位等基础定义，需被上层实体引用才能使用；核心层是分界线，从这里开始每个实体都有 GlobalId，可以作为独立对象被交换和追踪；互操作层和领域层在核心层的一般定义上继续特化，前者服务跨专业交换，后者服务专业内部交换。图中虚线圆表示尚在扩展中的隧道领域（计划纳入开发中的 IFC 4.4）。

核心层的根是抽象实体 IfcRoot。它带有四个特性：全局唯一标识符 GlobalId，以及三个可选特性，即所有者历史 OwnerHistory、名称 Name 和说明 Description。IfcRoot 直接派生三个实体类型：

• IfcObjectDefinition：事物本身，包括构件、空间、过程、资源、参与者，以及它们的类型；
• IfcPropertyDefinition：描述事物的属性定义，包括属性集（property set）和属性集模板；
• IfcRelationship：事物之间的关系。

图 2　IfcRoot 的三个派生实体类型。据 ISO 16739-1:2024 第 5.1.3.44 条（IfcRoot）绘制的说明图，非标准原图。

图 2 中三个箭头汇向同一点，表示 IfcObjectDefinition、IfcPropertyDefinition 和 IfcRelationship 都直接继承 IfcRoot，因而都带有图中所列的四个特性。

三类之中最需要说明的是关系。很多软件把关系写成对象内部的一个字段，例如在墙的记录里填上“所在楼层 = 三层”。IFC 不这样做：墙的数据中不记录它在哪一层，楼层的数据中也不记录它有哪些墙，两者之间另有一个关系对象，一端指向墙，另一端指向楼层（图 3）。标准把这种做法称为对象化关系（objectified relationship），并说明它是处理对象之间关系的首选方式，理由是关系特有的属性可以直接记在关系上。

图 3　关系的两种写法：对象的字段与对象化关系。说明性示例，据 ISO 16739-1:2024 第 5.1.3.42 条（IfcRelationship）、第 5.1.3.40 条（IfcRelDefinesByType）和第 5.4.3.52 条（IfcRelContainedInSpatialStructure）绘制；构件编号与名称为假设，非标准原例。

图 3 上半部是字段式的写法：楼层和类型只是墙的两个字段值。下半部是 IFC 的写法：绿色的两个框是关系对象，各自继承 IfcRoot，有自己的 GlobalId；箭头从关系对象指向它所连接的两端，旁边的灰字是关系对象上的特性名。按标准的命名约定，关系的两端分别以 Relating 和 Related 开头命名，一对多关系中 Related 一端是一个集合，所以一个关系对象可以同时连接多面墙。

构件的类型、属性集、空间归属、分类和材料，都通过这样的关系对象与构件相连。

三、关键技术点与实例

1. 类型与实例、预定义属性集

说明性示例：项目中有 120 面做法相同的 200 mm 加气混凝土外墙。若每面墙都重复记录耐火极限和传热系数，修改做法时就要改 120 次，还容易漏改。IFC 用类型—实例（type–occurrence）机制处理这个问题：做法相同的墙共用一个 IfcWallType，各面墙作为 IfcWall 实例，通过 IfcRelDefinesByType 关联到这一类型。共性属性挂在类型上，个性属性挂在实例上。

属性以属性集的形式组织。IFC 规定，作为标准一部分定义的属性集名称使用 Pset_ 前缀，用户自定义的属性集不得使用这一前缀。墙通用属性集 Pset_WallCommon 包括 IsExternal（是否为外部，布尔型）、LoadBearing（承重）、FireRating（耐火极限，按国家消防分级给出的标签）、ThermalTransmittance（传热系数）等属性。标准同时以 Qto_WallBaseQuantities 等工程量集（quantity set，前缀 Qto 取自 quantity take-off）提供工程量。

当类型和实例上出现同名属性时，标准给出明确的覆盖规则：若实例的属性集中含有与类型定义中相同名称的属性，则实例的属性值覆盖类型的属性值。

图 4　一面外墙在 IFC 中的类型、实例与关系。说明性示例，据 ISO 16739-1:2024 第 5.1.3.40 条（IfcRelDefinesByType）、第 5.4.3.52 条（IfcRelContainedInSpatialStructure）及第 6.1.4.23 条（Pset_WallCommon）绘制；构件编号与属性值为假设，非标准原例。

图 4 把类型、实例和两种关系放在同一面墙上。绿色框是关系对象，白色框是对象和类型，灰色虚线框是属性集；箭头从关系对象出发，指向它的关联端，旁边的灰字是关系对象上对应的特性名。

自上而下看：IfcWallType 通过 HasPropertySets 挂着 Pset_WallCommon，其中写明“外部”“耐火极限 2.00h”。IfcRelDefinesByType 用 RelatingType 指向这一类型，用 RelatedObjects 指向两面墙，一个关系对象就把一种做法分配给了多个实例。W-3-017 自身没有写耐火极限，读取时继承类型上的 2.00h；W-3-018 在实例上另写了 FireRating = 3.00h，按覆盖规则，这面墙的耐火极限以 3.00h 为准，其余属性仍继承类型。下方的 IfcRelContainedInSpatialStructure 再用 RelatedElements 和 RelatingStructure 把两面墙放进“三层”。图中两个关系对象各自独立：改变墙的做法只动上面一个，调整楼层归属只动下面一个，互不牵连。

下面用 ISO 10303-21 明文格式（.ifc）写出上述外墙的一个简化片段（说明性示例，省略了几何、单位和所有者历史等实体；类型名称为便于阅读直接写出中文，实际文件中的非 ASCII 字符须按 ISO 10303-21 的规则编码）：

#10=IFCPROPERTYSINGLEVALUE('IsExternal',$,IFCBOOLEAN(.T.),$);
#11=IFCPROPERTYSINGLEVALUE('FireRating',$,IFCLABEL('2.00h'),$);
#12=IFCPROPERTYSET('3vB2YO$MX4xv5uCqZZG05x',$,'Pset_WallCommon',$,(#10,#11));
#20=IFCWALLTYPE('1kTvXnbbzCWw8lcMd1dR4o',$,'外墙-200加气混凝土',$,$,(#12),$,$,$,.STANDARD.);
#30=IFCWALL('0dWb1F$Hz3dPQo2r$Q1Xq6',$,'W-3-017',$,$,#31,#32,$,$);
#40=IFCRELDEFINESBYTYPE('2hQx7mN0b9$R5tLmWqE3aK',$,$,$,(#30),#20);
#50=IFCRELCONTAINEDINSPATIALSTRUCTURE('0Yt8sK1pQ3vN$a7cRb2dLf',$,$,$,(#30),#60);

这段花花的文字实际上是明文代码，耐心读完全可以从字面上读出含义，接收方软件也不需要知道发送方用的是什么软件。请大家跟随解读：

• 每行以 # 加编号开头，是一个实体实例；等号后面是实体名，括号内是它的各项特性值，以逗号分隔；
• #30 是一面墙（IFCWALL）。括号内按继承链上的声明顺序，从 IfcRoot 的特性开始依次给出 9 个特性值：第一个是 GUID（GlobalId），第三个是名称“W-3-017”。$ 表示该特性未赋值，只能出现在可选（OPTIONAL）特性的位置上。#31 和 #32 是第 6、第 7 个特性 ObjectPlacement 和 Representation 的值，分别指向这面墙的定位和几何表示，这两个实例在片段中省略；
• #40 是类型关系，它把墙 #30 关联到类型 #20，墙因此取得类型上的“外部”和“耐火极限 2.00h”两项属性；
• #20 中的 (#12) 指向属性集 #12，#12 又指向 #10 和 #11：#10 给出“是否为外部”的布尔真值，#11 给出耐火极限；
• #50 是空间包含关系，墙 #30 被包含于空间结构对象 #60（假定为三层楼层，片段中省略）。

这里有两点边界需要注意。第一，FireRating 的数据类型是标签（IfcLabel），标准只说明它按国家消防分级给出，没有规定取值格式，“2.00h”和“一级”在模式层面都合法，是否合格要由项目的信息要求判定。第二，墙的分类也可以用预定义类型特性 PredefinedType 的枚举值表达；若取值为 USERDEFINED，形式化命题要求同时填写 ObjectType 说明具体类型。这些约束保证了数据结构的一致，但并不保证语义的一致，后者需要数据字典（ISO 12006-3）和信息需求规格来补足。

2. 对象化关系：空间结构、包含与聚合

在 IFC 中，“这面墙在三层”不是墙的一个特性，而是一个 IfcRelContainedInSpatialStructure（关系-包含于空间结构）关系对象：它的一端是墙，另一端是楼层。“三层属于 A 栋”则由另一种关系 IfcRelAggregates（聚合，即整体与部分的关系）表达。标准明确指出，空间结构自身的层级用 IfcRelAggregates 定义，构件进入空间结构用空间包含关系定义。

两种关系的约束不同。标准规定，任何构件只能被包含于空间结构的一个层级；如果它还与其他空间相关，则使用另一种关系 IfcRelReferencedInSpatialStructure（引用）。标准自己举的例子是跨越多层的空间：它由其底面所在的楼层包含，同时被它所跨越的其他各层引用；电梯井可以由地下室包含，被所穿过的各层引用。聚合关系则有 NoSelfReference 约束，任何对象不能是自身的组成部分。屋顶由屋面板、椽、檩等组成，就是标准给出的聚合示例。

把关系独立出来的工程含义在于：同一构件可以同时处于多种结构中而互不干扰。一面外墙可以被三层包含，被“东立面”系统分组，通过开洞关系 IfcRelVoidsElement 与墙上的洞口构件相连，再通过 IfcRelAssociatesClassification 关联到外部分类表中的某个编码。每种关系有各自的语义和约束，软件可以分别检查，而不必在墙对象里塞进越来越多的字段。代价是数据更“碎”：读取一面墙的完整信息，需要沿多条关系检索，对实现者的要求也更高。

关系还用来确定实体的性质。一面墙是什么类型、带有哪些属性、用什么材料、属于哪一类，都不写在墙自身的特性里，而由不同的关系对象指明：

• IfcRelDefinesByType 指定类型；
• IfcRelDefinesByProperties 把属性集赋给一个或多个对象；
• IfcRelAssociatesMaterial 关联材料；
• IfcRelAssociatesClassification 关联分类。

前两种属于定义关系 IfcRelDefines；后两种属于关联关系 IfcRelAssociates，所指向的信息可以在项目数据之内，也可以在其外部。这样，同一个属性集可以被多个对象共用，同一个对象也可以随项目进展陆续挂接新的属性集，实体类型本身不必改动。只有类型上的属性集例外：它由类型对象的 HasPropertySets 特性直接引用，不经过关系对象。

3. 从建筑到基础设施：设施与路线

建筑以楼层组织空间，道路、铁路和桥梁则主要沿一条线展开。IFC 4.3 为此做了两项结构性扩展。

一是设施（IfcFacility）。按标准定义，设施可以是建筑 IfcBuilding、桥梁 IfcBridge、铁路 IfcRailway、道路 IfcRoad，或水运设施 IfcMarineFacility，也为将来可能加入的隧道等预留了位置。建筑因此从 IFC 中唯一的“设施”变为设施的一种，建筑仍以楼层划分，其他设施的空间分解则由设施组成部分（IfcFacilityPart）承担。

注：IFC 4.3 删除了 IfcBuildingElement，墙、梁、柱这类构件的上位实体更名为工程构件 IfcBuiltElement，涵盖建筑和基础设施中构成结构体系与空间分隔体系的各类构件，同一个 IfcWall、IfcBeam 因此既可用于建筑，也可用于桥梁和道路。

二是路线（IfcAlignment）。标准说明，路线用于为主要沿线展开的工程（如道路、轨道、桥梁）建立定位参照系。路线由平面线形（IfcAlignmentHorizontal）、纵断面线形（IfcAlignmentVertical）和路线超高（IfcAlignmentCant，主要用于铁路，用来补偿一部分横向加速度）三部分组成。标准特意把两个方面分开表达：一方面是业务逻辑，用行业术语描述各线形的线元及设计速度等专业参数；另一方面是几何定义，用 IfcCompositeCurve、IfcGradientCurve、IfcSegmentedReferenceCurve 等几何实体表达。这样，设计软件可以交换“这是一段缓和曲线、长度若干”的设计意图，也能交换计算后的空间曲线。

构件可以通过 IfcLinearPlacement（线性定位）沿曲线放置，其位置由指向曲线的参照确定。说明性示例：一座跨河桥的 3 号墩，可以表达为“沿主线里程 K12+350，向左偏移 4.5 m”，而不只是一个大地坐标。路线调整后，采用线性定位的构件仍保有与路线的关联，接收方可以据此重新计算位置。对于习惯以桩号组织图纸和计量的中国道路、铁路行业，这一表达方式更贴近工程语言。

图 5　沿路线定位：3 号墩的线性定位。说明性示例，据 ISO 16739-1:2024 第 8.7.3.13 条（IfcLinearPlacement）、第 8.9.3.4 条（IfcAxis2PlacementLinear）和第 8.9.3.48 条（IfcPointByDistanceExpression）绘制；里程与偏移量为假设，非标准原例。

注：图 5 上半部是平面示意。绿色粗线代表路线的平面线形，里程向右增加；3 号墩位于 K12+350 处，虚线表示它离路线的横向距离 4.5 m。标准规定横向偏移 OffsetLateral 以“面向曲线参数增加方向的左侧”为正，所以位于路线左侧的墩取 +4.5 m。DistanceAlong 是沿基准曲线量取的距离（也可以用曲线参数值给出），并不直接等于桩号：图中假设路线起点为 K0+000，K12+350 对应 12 350 m；若路线起点另有桩号或存在断链，两者之间还需换算。

下半部是同一位置在数据中的写法，从左向右读：墩的 ObjectPlacement 指向一个 IfcLinearPlacement；后者的 RelativePlacement 是一个 IfcAxis2PlacementLinear；它的 Location 必须是一个 IfcPointByDistanceExpression，其中记录沿线距离和偏移量；这个点再通过 BasisCurve 指回路线曲线。数据链的末端回到路线本身，因此改线后，墩的位置可以按同一组距离和偏移重新计算，而不必逐个改写坐标。

4. 交换格式、模型视图与信息需求

IFC 的模式与文件格式是两个层次。模式给出结构和规则；文件格式规定用什么语法把符合这些规则的项目数据写出来。前文的 .ifc 片段属于文件格式这一层。

完整的 IFC 模式过于庞大（ISO 16739-1:2024 的 HTML 文本有六千多个页面），任何一个交换场景（例如结构分析）都只用到其中一部分。标准因此引入模型视图定义（Model View Definition，MVD），即满足特定数据需求的模式子集。按范围条款的说明，每个 MVD 指明标准中的哪一部分定义对软件实现构成要求，软件申请认证时须说明所符合的 MVD。MVD 本身不在 ISO 16739-1 之内，而是作为相关规格另行发布。buildingSMART 为 IFC 4.3 确定的 MVD 有三个：参考视图（Reference View）、基于路线的参考视图（Alignment Based Reference View）和设计移交视图（Design Transfer View），三者构成逐级增加高级特性的三个实施层级。

MVD 解决的是“软件的某功能应支持哪些定义”，项目层面的“这一次交付必须有哪些属性、取值如何”还需要另一层规格。buildingSMART 于 2024 年 6 月批准的 IDS 1.0 即为此而设，按其说明，IDS 以人可读、机器可解析的方式定义信息需求，用于自动检查 IFC 数据是否满足交付要求。上例中“外墙必须填写 FireRating”这类要求，就适合写成 IDS，而不是停留在合同中的一句“提交 IFC 文件”。

注：对于项目甲方来说，提出清晰的信息需求（这是当前BIM实施层面最薄弱的环节）是项目做好BIM的基础，而实现手段之一就是制定 IDS。以后会出一期专门介绍。

四、深度分析与实际启示

1. 模式统一不等于语义统一

一套中立的数据结构是实现数据共享的必要条件，但不是充分条件。

本文前面的例子也说明了这一点：IFC 能保证“耐火极限”写在约定的位置、属于约定的属性集，但不保证不同参与方对“2.00h”的理解相同，也不保证该填的属性都已填写。IFC 提供了与外部体系衔接的接口：IfcRelAssociatesClassification 把对象关联到外部分类体系中的条目，属性则可以与数据字典中的概念对应。ISO 12006-2、ISO 12006-3、IDM（对应信息交付）与 IDS（对应信息需求）因此不是 IFC 的可选附件，而是让 IFC 数据真正可用的配套条件。

2. 对中国标准编制与工程实施的启示

IFC 名称中的“基础”（foundation）说明了它的定位：提供各专业共用的基础定义，不可能覆盖每个项目、每个地区的全部需要。标准为此留有扩展途径，使用者不必改动模式本身。扩展主要从四个方面进行：

• 自定义属性集。 标准把属性集和工程量集说明为模式中实现的一种可扩展机制。项目或企业可以定义自己的属性集，其名称不得使用 Pset_ 前缀；需要统一其结构时，可以用属性集模板（IfcPropertySetTemplate）声明属性集的名称、适用对象和所含属性。
• 用户自定义类型。 预定义类型的枚举值不够用时，取 USERDEFINED，并在 ObjectType 中写明具体类型。
• 通用实体。 没有合适子类型的构件，可以直接实例化工程构件 IfcBuiltElement。标准建议不再用建筑构件代理 IfcBuildingElementProxy 表示任意构件。若一定要自定义实体，首先，不能以 Ifc_ 为前缀，例如写为 IfcWeiLaiDefined；其次，存在无法被其他软件识别的风险。
• 外部分类与数据字典。 通过 IfcRelAssociatesClassification 和 IfcRelAssociatesLibrary，把对象、类型或属性集关联到外部的分类体系和库（例如按 ISO 12006-3 建立的数据字典），由外部体系承担本地化的语义。

这四种途径都不改变模式，扩展后的数据仍可按标准模式解析；自定义部分的含义则需要另行约定，这正是数据字典和 IDS 的作用所在。

结合上述分析，以下几点值得从标准编制和项目实施两方面考虑：

1. 引用时写明版本。 “符合 IFC 标准”至少有 IFC2x3、IFC4、IFC 4.3 三种现实含义，彼此并不完全兼容。按标准附录 F 的清单，相对 ISO 16739-1:2018，新版删除了 25 项实体、类型和函数，另有 11 个实体以及若干特性和枚举项被标为弃用。地方标准、企业标准和合同条款引用 IFC 时，应写明 ISO 文本或 IFC 版本号，必要时写明 MVD；等同采用的国家标准发布后，可同时写明国家标准编号。
2. 交付要求落到属性层。 合同中的“提交 IFC 模型”只约定了容器。更有效的做法是按交付环节写明对象、属性集、属性名和取值规则，并以 IDS 等可机读格式发布，使接收方可以自动检查。
3. 分类编码通过关系挂接。 以 GB/T 51269—2017 为代表的各层级分类编码可以通过分类关联关系附着到 IFC 对象上，而不必改写 IFC 的实体类型。这样，IFC 负责结构，国标分类负责本地业务视角，两者各守边界。
4. 基础设施项目优先使用 4.3。 道路、铁路、桥梁和港口项目若仍沿用 IFC2x3 或 IFC4，路线与沿线定位只能以代理对象或自定义属性近似表达。采用 IFC 4.3 前，仍需核实所用软件对相应 MVD 的实际支持程度。

五、结语

回到开头的综合楼：建筑、节能和造价三方之所以能读同一面墙，靠的不是同一款软件，而是 IFC 为“墙是什么、属于哪一层、是哪种类型、带有哪些属性”约定了公共结构。ISO 16739-1:2024 的价值，在于把这种结构写成了可以形式化校验的国际标准，并把适用范围从建筑延伸到线状基础设施。

同时也要看到它的边界：IFC 规定数据如何写，不规定项目应写什么，也不保证写进去的内容彼此同义。读者在评估一份“IFC 交付”时，可以依次追问：用的是哪一版 IFC 和哪一个模型视图，交付需求是否已落到属性层并可自动检查，关键属性又对应哪一个数据字典概念。三个问题都有答案时，IFC 文件才真正成为可用的工程信息。

参考文献

1. ISO. ISO 16739-1:2024, Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema. Geneva: ISO, 2024.
2. buildingSMART International. IFC 4.3.2.0 Documentation（与 ISO 16739-1:2024 对应的公开在线文档）. Accessed 2026-10-04.
3. buildingSMART International. IFC Specifications Database. Accessed 2026-10-04.
4. buildingSMART International. IFC Release Notes. Accessed 2026-10-04.
5. ISO. ISO 10303-11, Industrial automation systems and integration — Product data representation and exchange — Part 11: Description methods: The EXPRESS language reference manual; ISO 10303-21, Part 21: Implementation methods: Clear text encoding of the exchange structure; ISO 10303-28, Part 28: Implementation methods: XML representations of EXPRESS schemas and data, using XML schemas. Geneva: ISO.
6. ISO. ISO 12006-3:2022, Building construction — Organization of information about construction works — Part 3: Framework for object-oriented information. Geneva: ISO, 2022.
7. ISO. ISO 29481-1:2025, Building information models — Information delivery manual — Part 1: Methodology and format. Geneva: ISO, 2025.
8. buildingSMART International. “Information Delivery Specification (IDS) v1.0 is Approved as a Final Standard”, 2024. Accessed 2026-10-04.