在探讨IFC（Industry Foundation Classes）的背后实质时，我们发现它是一个关于对象语义、它们之间关系以及属性的广泛协议集合
在IFC 2x3版本中，这一协议集合涵盖了653个标准化实体，拥有约12,000个属性的语义定义
IFC标准化的工作量可谓巨大，被普遍视作跨行业中最大规模的标准化努力之一
我们也能观察到，IFC模式具有模块化特性，涵盖了特定领域的实体
这一标准的目标在于为不同的软件工具之间建立一个接口，因为并不是每个工具都内置了包含各领域特定实体的数据模式
例如，结构分析软件通常不涵盖与加湿器、许可、占用者或风管配件相关的数据，这只是其中少数示例
当不同的软件工具尝试实现IFC的导入和导出功能时，会遇到难以管理的挑战
如何知道每个软件工具支持IFC的哪些实体？为了解决这个问题，BuildingSMART创立了模型视图定义（Model View Definitions，简称MVD）
模型视图定义是确定软件工具实现的IFC模式中哪些部分被包含的方式
通过模型视图定义，软件开发人员能够从IFC实体列表中选择适合其导入和导出功能的实体
模型视图定义可被理解为一种设定规范，指导开发人员实现特定需求的数据交换功能
在实际情况中，每个软件工具的每个IFC导出功能都是基于相应的模型视图定义创建的
BuildingSMART还为2x3版本创造了一个名为“Coordination View”的模型视图定义
该视图是完整IFC模式的精简版本，特别为多个项目合作伙伴之间的项目协调性而设计
尽管Coordination View并未包含IFC许可和IFC占用者等内容，但它涵盖了完整IFC模式中约80%到90%的内容
关于Coordination View版本2.0的内容概述可在知识库中获得
BuildingSMART的Coordination View也被用于官方的BuildingSMART IFC软件认证，该认证是基于模型视图定义对IFC的导入和导出功能进行的，而非针对完整IFC模式
总之，模型视图定义的创立初衷是为了支持软件开发人员，然而它的应用方式千变万化
在建筑行业，业主有时会利用模型视图定义来规定数据交付要求，以确保所需的数据在建筑物中得以提供
以Cobie标准为例，它就是一个用于创建设施管理和运营模型视图定义的范例
随着IFC 4版本的发布，BuildingSMART引入了两个官方模型视图定义，分别是“Reference View”和“Design Transfer View”
软件供应商可以选择为其软件实现其中一个或两个模型视图定义，以根据功能需求进行认证
值得注意的是，每个软件开发人员也可自行定义适合其软件的模型视图定义
随着IFC的不断扩展，其中的协议集合也在不断膨胀
在IFC 5版本中，将涵盖基础设施元素，如桥梁和铁路
BuildingSMART目前的观点是，IFC在定义协议时，将会针对不同领域创造多个模型视图定义
这也带来了潜在的挑战，例如，未来的铁路模型视图定义可能与用于疏散模拟的模型视图定义存在不兼容性，尽管两者都是100%基于IFC的，具有相同的文件格式
这可能会导致混淆，因为它们都被称为IFC
作为用户，我们应始终谨记，在谈论IFC数据交换时，实际上是在讨论模型视图定义
通常情况下，并不存在所谓的“普通IFC文件”
在BIM执行计划生成器中，对不同的BuildingSMART模型视图定义进行了明确区分，因此，当涉及IFC时，需准确辨别不同的模型视图定义
总结而言，模型视图定义是一种用于对IFC协议集合进行过滤的方法，用于设定软件工具所支持的实体和功能
每位软件工具开发者都可根据需求选择支持的模型视图定义，以确保数据交换的精准性和一致性
虽然模型视图定义不直接用于定义BIM数据质量检查规则，但在实现不同领域和用途的BIM数据交换方面，其具有重要作用
需要明确的是，模型视图定义是在IFC模式定义基础上建立的，是协议层次的过滤方式，而非文件数据级别的过滤