标准导读｜ISO 12006-3:2022 建筑工程信息组织，面向对象信息框架

ISO 12006-3 是 BIM 三大基石之一（IFD-IFC-IDM），却也是 BIM 实施层面最薄弱的环节，直到今天，数据字典要么是刚刚起步状态，要么对其认知还在“津津乐道的 BIM 大道理”之外。 在常见的 IFD–IFC–IDM 关系图中，ISO 12006-3 关联的是术语和概念一侧：模型能交换数据，还需要参与方对数据所指有共同理解。

标准档案

一、从静态分类到面向对象字典：解决什么工程痛点

很多同行都看过 IFD–IFC–IDM 关系图，但可能不是所有人都留意过其中“术语与概念”这一角与数据字典的关系。

图 1　IFD–IFC–IDM 三角关系中的术语、过程和数据。依据 NBIMS-US V3 第 2.5 节图 2.5-1 的三个互操作性侧面重新绘制，非 ISO 标准原图。

在 openBIM 标准谱系中，如果说 ISO 16739-1（IFC）定义了建筑对象的数据模式，ISO 29481-1（IDM）给出了信息交付过程方法，那么 ISO 12006-3 则提供组织术语、概念和属性的数据字典信息模型。IFD 是与这一模型相关的传统称谓，不等于 ISO 12006-3 本身；ISO 12006-2 则提供分类体系开发框架。

这本标准定义了面向对象的数据字典信息模型；buildingSMART 数据字典（buildingSMART Data Dictionary，简称 bSDD，原称 IFD Library）是相关在线服务，不能与标准等同。2022 年 7 月，ISO 发布了 ISO 12006-3:2022 第二版，取代 2007 年的第一版。新版在字典关联、物理量纲、语境化关系和变更请求等方面扩展了模型。

上一期讲述了 ISO 12006-2，那部标准讨论了“建设活动信息应如何按不同视角编目”的宏观框架，我国 GB/T 51269—2017、北美 OmniClass、英国 Uniclass 等是各自的分类体系。工程信息用于数字交付与计算时，单纯依赖树状分类表还会遇到三个问题：

1. 分类标签还需明确属性定义。 分类表主要提供编码和层级。例如“外墙”有了分类名称，仍需说明它的传热系数、耐火极限等属性各指什么，采用何种数据类型和单位；合格取值还取决于具体要求。
2. 产品数据模型（IFC）与外部字典需要配合。 IFC 可通过 IfcPropertySet 承载用户定义的属性，但同名的局部属性未必同义。外部字典可为属性提供独立于项目文件的概念定义、标识及关联，供不同软件核对和复用。
3. 语言鸿沟与多源词汇割裂。 同一个工程对象在不同语言、不同地域或不同软件中往往使用不同的词汇表达。缺乏明确的概念层关联，跨国跨软件的数据交换便常需人工判读。

针对上述困难，ISO 12006-3 给出的解法是：不规定具体某张分类表或某个属性库的内容，而是定义一套独立于语言、为对象提供全局唯一标识（UUID）的面向对象数据字典信息模型。

它可以在分类体系（ISO 12006-2）、产品建模（IFC / ISO 16739-1）与数据模板（ISO 23387）之间发挥语义衔接作用。国家、行业、协会或企业可基于该框架建立各自的数据字典，再审查字典间的概念关系；采用同一框架，并不使名称相近的属性自动等价。

二、核心架构：xtd 元模型与三大抽象层级

为了确保模型的严密与统一，ISO 12006-3 的实体以 xtd（extensible taxonomy definition）作为命名前缀。标准以 EXPRESS 语言给出形式化定义，并在资料性附录中提供 UML 与 XML 表达。其核心结构可以从自顶向下的三层抽象类及派生体系入手理解。

图 2　xtd 核心实体与继承架构。据 ISO 12006-3:2022 第 5.2、5.3 条提炼绘制；实线箭头指向上位类型，绿色虚线表示字段引用。底部的 xtdFilter 与 xtdQuantityKind 也派生自 xtdConcept，图中省略了相应继承线。

图注：查看图 2 原尺寸图片。

1. 根基：xtdRoot

xtdRoot 是整个框架的最顶层抽象超类。它通过 UniqueId : xtdUUID，为派生对象赋予全局唯一标识符（UUID），使概念可以独立于名称和语言被引用。

无论是数据字典本身（xtdDictionary）、具体概念、一段特定语种的文本说明（xtdText），还是用户身份（xtdUser），都可以通过这一机制获得唯一标识。这避免仅用字符串名称作主键时的同名歧义；但两个对象是否同义，仍须核对定义。

2. 受控实体：xtdObject

继承自 xtdRoot 的抽象实体 xtdObject，是承载生命周期治理与版本追溯的控制层。它不直接描述工程特性，而是为所有具名对象赋予管理属性：

• 字典归属（Dictionary）：明确当前对象属于哪个数据字典；该字段本身不判定知识产权；
• 多语言名称集（Names : SET OF xtdMultiLanguageText）：支持一个对象同时挂接不同语言的名称与同义词；标准要求至少提供国际英语和创建者的原始语言名称；
• 版本与历史替代：包含主版本号（MajorVersion）与次版本号（MinorVersion），并与 ISO 23386 的相关版本字段对应。新对象的 ReplacedObjects 列出它所替代的旧对象；旧对象可由反向属性 ReplacingObjects 找到替代者。DeprecationExplanation 可说明弃用原因或转换方式，但不规定软件自动迁移旧数据。

3. 概念核心：xtdConcept

作为 xtdObject 的抽象特化，xtdConcept 构成字典的核心语义节点。它集成了定义（Definition），还可包含多语言描述（Descriptions）、示例（Examples）、创建者语言与需求来源国，并能通过 ReferenceDocuments 关联外部文献。

在此基础之上，标准派生出知识体系的两个核心锚点：

• xtdSubject（本文译为“主体”）：代表工程世界中被感知的物理构件或逻辑对象类（如“外墙”“防火门”“变风量末端”“机场跑道”）。主体不是项目中的具体实例，可通过关联属性（Properties）描述其特征；标准将它与 ISO 23386 的“属性组（group of properties）”对应。
• xtdProperty（属性）：用于对主体进行定性或定量描述的特征。每个属性记录量纲（Dimension）与数据类型（DataType），并可关联允许值列表（PossibleValues）、取值区间（BoundaryValues）及计量单位（Units）。这些信息支持数据检查，不能自行决定项目的性能合格标准。

三、物理属性的数学约束：量纲分解与单位换算

说明性示例：如果两个系统都记录“门宽 900”，却分别采用毫米和厘米，单靠字段名与数值就无法判断数据是否可比。属性库若只以文本记录单位，而没有明确的属性定义、量纲和单位关联，不同程序交换数据时便容易混淆。

ISO 12006-3:2022 对物理属性的表达，主要体现在以下三个环节：

1. 严格的有理数七元组量纲（xtdDimension）

标准依据 ISO 80000 系列，将量纲分解为 7 个基本量的有理数指数（长度 $L$、质量 $M$、时间 $T$、电流 $I$、热力学温度 $\Theta$、物质的量 $N$、发光强度 $J$）。在 EXPRESS 实体中，这表现为 7 对由分子与分母构成的有理数对（xtdRational）：

$$\text{Dimension} = \langle L^{a/b},\; M^{c/d},\; T^{e/f},\; I^{g/h},\; \Theta^{i/j},\; N^{k/l},\; J^{m/n} \rangle$$

例如，力（Force）的量纲为 $\text{LMT}^{-2}$，对应长度指数 1、质量指数 1、时间指数 −2，其余 4 个基本量指数均为 0 （这里有点抽象。 这是由 力(F)=质量(m)×加速度(a)， 且 加速度(a)=位移/时间平方 推导而来）。

标准在第 5.3.18 条还区分了两种模型表示：

• 量纲为 1（dimension one）：7 个基本量的指数均为 0；
• 无量纲（dimensionless）：至少一个指数的分母为 0，表示模型中量纲未定义。后一术语是本标准的特定编码约定，不宜直接等同于物理学中“量纲为 1”的量。

2. 量类（xtdQuantityKind）的语义隔离

在物理学中，存在量纲完全相同但意义不同的物理量。典型例子是“力矩（Torque）”与“功／能量（Work/Energy）”：二者的量纲均为 $\text{L}^2\text{MT}^{-2}$。如果仅依据量纲进行检查，就不足以判断将焦耳（J）赋予力矩属性是否合适。

为此，ISO 12006-3 设立了 xtdQuantityKind（量类）实体：它引用特定量纲，并可关联该量类所用的单位。力矩与能量即使量纲相同，也可以在量类上加以区分；但 EXPRESS 模式只明确约束关联单位的量纲一致，不能据此声称标准自动禁止所有“同量纲、错量类”的赋值。

3. 公式化的单位转换（xtdUnit）

标准在第 5.3.40 条中以数学方程描述从国际单位制基本单位分解值 $M_0$ 到目标单位值 $M$ 的换算机制：

• 线性标度（Linear Scale）：

  $$M = C \cdot \left(\frac{M_0}{B}\right) + D$$

  式中 $M_0$ 为国际单位制基准物理量数值；$C$ 为有理数比例系数（Coefficient : xtdRational，由整数分子与分母构成）；$B$ 为换算基数枚举（Base : xtdUnitBaseEnum，支持 1、2、$e$、$\pi$、10 等特殊基数）；$D$ 为有理数零点偏移量（Offset : xtdRational）。 比例因子 $C$ 与偏移量 $D$ 由整数有理数对表达；无理数常数（如 $\pi$ 或 $e$）可由枚举基数 $B$ 承接。这避免预先把参数写成近似小数，但不消除软件执行浮点计算时的舍入误差。例如：

  • 开尔文（K）换算为华氏度（°F）（附录 F.2.1）：$C = 9/5$、$B = 1$、$D = -45\,967/100$，即 $f = \frac{9}{5}\cdot\frac{k}{1} - \frac{45\,967}{100}$；
  • 弧度（rad）换算为角度（°）（附录 F.2.2）：$C = 180$、$B = \pi$、$D = 0$，即 $d = \frac{180r}{\pi}$。

• 对数标度（Logarithmic Scale）：

  $$M = C \cdot \log_B(M_0) + D$$

  附录 F.2.3 用分贝（dB）衰减量说明此式，给出 $C = 10$、$B = 10$、$D = 0$。

计算软件可以读取字典中的换算参数，但仍须正确实现计算、核对量纲与量类，并检查原始数值的单位是否可信。

四、关系的精细语义：模式层、上下文作用域与分类过滤

现实工程对象之间存在复杂的关联网络。若只用一张没有类型和语境的“关联表”连接两端，就难以区分概念层面的关系与具体产品中的关系。ISO 12006-3 分别提供关系类型、上下文作用域和过滤条件等表达机制。

图 3　关系语义：模式级与实例级、带上下文的作用域。据 ISO 12006-3:2022 资料性附录 F.3 及第 5.3.33 条提炼绘制；供暖系统示例来自正文，不是附录 F.3 原图。

1. 模式级关系 vs 实例级关系

标准在 xtdRelationshipKindEnum 中区分两类关系类型（如图 3 所示）：

• 模式级关系（XTD_SCHEMA_LEVEL）：用于组织字典中的概念结构。标准以电机为例：Electric motor 与 Combustion motor 是 Motor 的特化类型（is-subtype-of）。具体产品可以是电动机，却不会在产品文件中实例化出抽象的“是子类”关系。
• 实例级关系（XTD_INSTANCE_LEVEL）：在数据字典中定义，可以在产品数据中实例化。例如电动机与其组成部分（定子、转子、机壳）之间的“包含（has-part）”关系。具体电机的交换文件可以记录定子与转子的实例及其连接，但标准不保证每个文件都生成这些对象。

这一区隔有助于避免把概念的继承层级误写成产品的装配结构。

2. 带上下文的作用域（ScopeSubjects）

两个工程主体之间的关系，往往在特定环境下才成立。ISO 12006-3 通过 xtdRelationshipToSubject 中的 ScopeSubjects 属性解决了上下文绑定难题。

标准第 5.3.33 条给出一个例子：暖气片（Radiator）与控制器（Controller）之间的“受控于（is driven by）”关系，可以把供暖系统（Heating System）设为作用域（ScopeSubjects）。这一限定说明该字典关系适用的语境，并不意味着离开这一系统，两个物理产品的一切连接都必然消失。

3. 分类过滤器（xtdFilter）

说明性示例：一堵外墙在不同交付要求下，可能需要填写 GB/T 51269、OmniClass 或 Uniclass 的分类编码。如果只按类名逐项对照，而不检查各体系的分类依据，就容易把相似名称误作概念等价。

图 4　分类过滤器（xtdFilter）的关联条件。据 ISO 12006-3:2022 资料性附录 F.4 提炼绘制；线段表示字典关联，不是运行时的数据流。

ISO 12006-3 的 xtdFilter（过滤器）为分类关联提供了可记录的条件。在资料性附录 F.4 的例子中，xtdFilter 由多个字典主体关联（如图 4 所示）：

• 过滤器自身定义了触发条件：属性指向 IsExternal（布尔型），目标过滤值 FilteringValue = TRUE；
• IFC 字典中的主体 IfcWall 通过 Filters 关联该过滤器；
• 匿名分类体系 I 中的主体 Exterior walls 也关联该过滤器；
• 匿名分类体系 II 中的主体 Exterior walls 同样关联该过滤器。原例没有给出这两套分类体系的国家或具体标准编号。

这为跨字典分类映射提供了候选条件，却不等于自动确认概念等价。实施系统仍需决定何时执行筛选、如何核对类定义、处理冲突及回写结果。标准没有规定解析引擎必须将满足 IsExternal = TRUE 的每个 IfcWall 自动路由到所有外部分类。

五、协同治理与开放互联：2022 版的扩展

相较于 2007 年的第一版，ISO 12006-3:2022 增加了变更请求等管理实体，并规定查询接口的最低能力，使数据字典的维护与调用有了更明确的信息结构。

图 5　变更请求与专家评审信息。据 ISO 12006-3:2022 第 5.3.14 条及资料性附录 F.1 提炼绘制，不表示统一的强制审批流程。

1. 与 ISO 23386 相关的变更治理信息

工程数据字典是动态演进的。若没有明确的维护规则，同名不同义或已弃用的概念便难以处理。ISO 23386 提供属性描述与维护方法；ISO 12006-3 的模型与之相关，但没有包含 ISO 23386 的全部概念。2022 版可记录下列信息（图 5）：

• 用户角色：可记录读者（XTD_READER）、贡献人（XTD_CONTRIBUTOR）、专家（XTD_EXPERT）与管理员（XTD_ADMINISTRATOR）等角色；这不是标准规定的四级权限体系；
• 结构化变更请求（xtdChangeRequest）：记录申请人、新对象、变更性质、请求状态和申请说明，资料性附录 F.1 展示了给主体增加属性的例子；
• 专家领域与状态：xtdExpert 的 AreasOfExpertise 可记录专家擅长的主体范围，xtdExpertWithStatus 可记录其分析、补充信息、验证或驳回等状态。ExpertExplanation 是可选字段；模型并不自动限制专家只能评审某专业；
• 版本与追溯：对象可记录主、次版本及替代关系。何时批准和发布、如何决定版本变化，仍由字典的治理规则确定。

2. 标准化 OData REST API

2007 版没有规定统一的字典查询接口。ISO 12006-3:2022 在正文第 6 章与规范性附录 B 中对符合标准的实现作出技术约定：

• 统一服务接口协议：实现须提供符合 ISO/IEC 20802-1 与 ISO/IEC 20802-2 的 Open Data Protocol（OData v4.0，JSON 格式）接口；
• 最低查询能力基准：服务接口必须支持 HTTP GET 动词，支持 $select、$filter、$expand、$orderby、$count 参数，且多级嵌套查询深度不低于 2 层。

这一规定为 BIM 工具、分析插件或业主平台查询数据字典提供了共同方式。但接口一致不保证字典公开访问，也不保证不同字典的概念天然一致；访问许可和语义审查仍需另外处理。

六、对中国工程建设数字化的深度启示

我国已发布 GB/T 51269—2017《建筑信息模型分类和编码标准》等文件。对照 ISO 12006-3:2022。但我国各层级标准中，尚无对照 ISO 12006-3 的标准，因此，以下四点值得从标准编制和工程实施等方面考虑：

1. 摆脱“重分类树、轻数据字典”的单一路径

如果把“分类与编码”视为信息组织的全部，成果止步于层级式编码清单，构件即使贴上分类代码，其属性定义和单位仍可能各不相同。

分类体系框架（ISO 12006-2）帮助组织不同视角的工程信息，数据字典模型（ISO 12006-3）则有助于明确对象、属性及其关系，数据模板（ISO 23387:2025）可按交付用途组织所需属性。三者可以配合，而不应把分类代码直接当作属性定义。知识工程中“共享概念化”的讨论也提示：编码只有与清楚的概念约定相连，才便于跨组织理解。

2. 引入物理量纲的数学约束机制

如果属性标准只用字符写单位，而不声明量纲和量类，模型进入能耗或碳排放计算时就需要额外核对。说明性示例：“门宽 900”若没有可信单位，系统不能判断是毫米还是厘米；有了长度量纲和毫米单位，才有条件换算为 0.9 m。属性库可借鉴标准的量纲与量类表达，具体计算仍要核查原始数据质量。

3. 理顺继承结构与装配实体的概念边界

自建构件库时，应区分模式级关系（XTD_SCHEMA_LEVEL）与实例级关系（XTD_INSTANCE_LEVEL），避免把“概念上的特化”与“物理上的装配”混为一谈。说明性示例：“钢筋混凝土柱”可以是“柱”的子类，而某根柱中的钢筋则是具体构件的组成部分；若两者都被笼统写成“子项”，下游应用就难以判断关系应否出现在实例数据中。

4. 建立开放的协同治理与 API 服务生态

大型企业或行业协会建设共用字典时，可以借鉴 ISO 12006-3 的变更请求结构与 ISO 23386 的维护方法，明确谁提出变更、谁审查定义以及何时发布新版本。是否设立跨企业委员会，属于实施组织的治理选择，并非标准要求。OData 接口便于软件查询字典，但开放程度、版本选择和数据质量仍需分别管理。

参考文献

1. ISO. ISO 12006-3:2022, Building construction — Organization of information about construction works — Part 3: Framework for object-oriented information. Geneva: ISO, 2022.
2. ISO. ISO 12006-2:2015, Building construction — Organization of information about construction works — Part 2: Framework for classification. Geneva: ISO, 2015.
3. ISO. ISO 23386:2020, Building information modelling and other digital processes used in construction — Methodology to describe, author and maintain properties in interconnected data dictionaries. Geneva: ISO, 2020.
4. ISO. ISO 23387:2025, Building information modelling (BIM) — Data templates for objects used in the life cycle of assets. Geneva: ISO, 2025.
5. 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.
6. ISO. ISO 29481-1:2025, Building information models — Information delivery manual — Part 1: Methodology and format. Geneva: ISO, 2025.
7. ISO/IEC. ISO/IEC 20802-1:2016, Information technology — Open data protocol (OData) v4.0 — Part 1: Core; ISO/IEC 20802-2:2016, Part 2: OData JSON Format. Geneva: ISO/IEC, 2016.
8. buildingSMART International. Terminology, IFD, IFC and IDM entries. Accessed 2026-09-29.
9. buildingSMART International. buildingSMART Data Dictionary. Accessed 2026-09-29.
10. Gruber, Thomas R. “A Translation Approach to Portable Ontology Specifications.” Knowledge Acquisition 5, no. 2 (1993): 199–220. doi:10.1006/knac.1993.1008.
11. National Institute of Building Sciences. National BIM Standard—United States, Version 3, §2.5, “International Framework for Dictionaries Library / buildingSMART Data Dictionary,” Figure 2.5-1. Washington, DC: NIBS, 2015.
12. buildingSMART International. IFC 4.3.2.0 Documentation, §5.1.3.14, “IfcPropertySet”. Accessed 2026-09-29.