Ifc Core Mvd

IFC Core : Model View Definitions (MVD)

The full IFC schema is intentionally huge (over 1300 entities, roughly 2500 properties, over 750 property sets in IFC4.3). No single software exchange uses all of it. A Model View Definition (MVD) is a standardized, formally documented subset of the IFC schema, scoped to one exchange scenario. The MVD names exactly which entities, attributes, property sets, and geometry types a conforming exporter must produce and a conforming importer must read. This skill covers which MVD to target, how each MVD is declared in the file header, and what geometry each one permits.

Quick Reference

What an MVD is, and is NOT

• An MVD IS a documented subset of the IFC schema for a specific exchange use case.
• An MVD IS the contract that makes certification and validation testable : it scopes "correct IFC" down to a finite, checkable set of entities and rules.
• An MVD is NOT a separate file format. An MVD file is still a normal IFC file in a standard encoding (STEP Physical File, ifcXML, ifcJSON). The MVD only restricts which entities appear.
• An MVD is NOT a version. IFC2x3, IFC4, IFC4.3 are schema versions; MVDs are subsets layered on top of a version.
• The machine-readable description language for MVDs is mvdXML. Authoring mvdXML is out of scope for this package : ALWAYS treat mvdXML as a published artifact to read about, NEVER hand-write it.

The MVD catalog (the load-bearing four)

Other registered MVDs (Quantity Takeoff View, Energy Analysis View, Structural Analysis View, Space Boundary Add-On View, IFC4Precast) exist; see references/methods.md for the full list.

Geometry each MVD permits

The MVD declaration in the file header

ALWAYS declare the MVD in the first string of FILE_DESCRIPTION, in the HEADER section. Verified syntax (IFC Header Data Implementation Guide v1.0.2) :

FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1');

• The keyword is ViewDefinition, followed by [, a comma-separated value list, ].
• implementation_level (the second string) is always 2;1 for IFC files.
• The verified IFC2x3 base keyword for design coordination is CoordinationView; exporters commonly suffix a version, for example CoordinationView_V2.0.
• IFC4 base keywords are ReferenceView and DesignTransferView; files commonly carry ReferenceView_V1.2 and DesignTransferView_V1.0.
• ALWAYS match a header by the base keyword prefix (ReferenceView), NEVER by an exact version suffix : the suffix convention varies by exporter.

Decision Trees

Which MVD to target

What is the exchange scenario?
|
+-- Multi-discipline coordination / clash detection on an IFC2x3 toolchain
|   --> Coordination View 2.0
|
+-- Distribute a reference model (coordination, takeoff, sequencing, IFC4+)
|   the receiver only needs to view and measure, NEVER edit
|   --> Reference View
|
+-- Hand a model to another authoring tool so it becomes the editable basis
|   --> Design Transfer View (IFC4)
|
+-- Facility-management handover (spaces, components, types, jobs, spares)
|   --> COBie / Basic FM Handover View
|
+-- Scenario not covered by a registered MVD
    --> agree an Exchange Requirement with the receiver before exporting;
        NEVER export the full schema "to be safe".

Read the MVD from an existing file

Open the HEADER section ; read FILE_DESCRIPTION's first string.
Find the substring starting with 'ViewDefinition ['.
|
+-- contains CoordinationView    --> IFC2x3 coordination model (view-only)
+-- contains ReferenceView       --> IFC4/IFC4.3 reference model (view-only)
+-- contains DesignTransferView  --> IFC4 transfer model (editable target)
+-- contains FMHandOverView      --> FM-handover data model (COBie family)
+-- no 'ViewDefinition' string   --> MVD undeclared
                                     treat geometry coverage as UNKNOWN ;
                                     do not assume the model is complete.

Can the receiver edit the model?

Does the receiving tool import the Design Transfer View?
|
+-- YES --> it can ALSO import Reference View datasets
|           (Reference View is a true subset of Design Transfer View).
|
+-- NO, the tool imports Reference View only
    --> it CANNOT import Design Transfer View datasets.
        Send Reference View ; expect view-and-measure use, NOT editing.

Patterns

Pattern : Declare the MVD in the file header

ALWAYS write the ViewDefinition keyword into the first FILE_DESCRIPTION string when producing an IFC file. A missing ViewDefinition leaves consumers unable to know which subset they received.

ALWAYS keep implementation_level as 2;1 : IFC files use ISO 10303-21 conformance class 1 and never the complex-entity features that would require class 2.

To declare more than one view, list them comma-separated inside one bracket, or repeat the keyword in separate strings :

FILE_DESCRIPTION(('ViewDefinition [CoordinationView, QuantityTakeOffAddOnView]'),'2;1');

NEVER put two keyword sets in a single unseparated string : each ViewDefinition set is one element of the description LIST OF STRING. See references/examples.md.

Pattern : Pick the MVD from the scenario, not from file size

ALWAYS choose the MVD by the exchange scenario and the receiver's capability. NEVER choose an MVD to make the file smaller : the three coordination MVDs differ by the level of parametric information captured, not by level of detail.

• Reference View keeps the originator's parametric "intellectual engineering property" with the originator : the receiver gets tessellated, non-parametric geometry.
• Design Transfer View hands over editable, parametric geometry so the receiver can continue authoring.

Pattern : Reference View geometry is tessellated and not editable

ALWAYS expect Reference View geometry to be tessellation-based (triangulated or polygonal face sets), plus simple swept solids and swept disk solids.

NEVER expect CSG, Boolean clipping, or dimension-driven parametric geometry in a Reference View file : the Reference View specification deliberately excludes them.

The intent is one-directional exchange : the receiver views, measures, clashes, and sequences, then requests changes via BCF rather than by editing the file. If a workflow needs the receiver to edit the geometry, Reference View is the wrong MVD.

See ifc-syntax-geometry-tessellation for the face-set entities and ifc-syntax-geometry-swept-solid for the permitted swept solids.

Pattern : Design Transfer View is a superset of Reference View

The Reference View is a true subset of the Design Transfer View. The relationship is asymmetric :

• A tool that imports the Design Transfer View MUST also correctly import Reference View datasets.
• A tool that imports the Reference View only CANNOT import Design Transfer View datasets.

ALWAYS confirm the receiving tool's import capability before sending a Design Transfer View file. The Design Transfer View is still Draft status : verify the receiver supports it rather than assuming.

Pattern : COBie carries FM data, not geometry

COBie (Construction-Operations Building Information Exchange) is an MVD subset focused on facility-management handover data : spaces, zones, components, types, systems, spares, resources, jobs, documents, and attributes. It captures the non-graphic data an owner needs to populate an asset-management system.

• The IFC2x3 binding is the buildingSMART Basic FM Handover View MVD (Final). Its header keyword is FMHandOverView.
• COBie is exchanged as an IFC STEP file or ifcXML for large projects, and as a spreadsheet for small projects.

ALWAYS treat COBie as a data exchange : a valid COBie deliverable needs the FM entity set populated, NOT geometry. For the COBie export workflow and spreadsheet duality, see ifc-impl-cobie.

Pattern : NEVER hand-author mvdXML

mvdXML is the machine-readable language used to define MVDs (concept templates, Root Concepts, semantic and geometric constraints). It is published by buildingSMART for each MVD.

NEVER hand-write mvdXML to "configure" an export : real exporters implement MVD support internally and expose it as an export preset. ALWAYS select the MVD through the exporting tool's settings, and verify the result by reading the ViewDefinition string back from the produced file. mvdXML authoring is excluded from this package.

Reference Links

• references/methods.md : the full registered-MVD catalog, the file_description EXPRESS entity, the description-field BNF grammar, the predefined ViewDefinition keyword list, and per-MVD geometry rules.
• references/examples.md : verified header strings for each MVD, reading an MVD from a header, multi-view headers, and the Option keyword.
• references/anti-patterns.md : the failure modes this skill prevents, each with the reason it fails.

Official sources

• MVD database : https://technical.buildingsmart.org/standards/ifc/mvd/mvd-database/
• IFC4 Reference View MVD : https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/schema/views/reference-view/index.htm
• IFC Header Data Implementation Guide v1.0.2 : https://standards.buildingsmart.org/documents/Implementation/ImplementationGuide_IFCHeaderData_Version_1.0.2.pdf
• IFC schema specifications : https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/

Related skills

• ifc-impl-mvd-export : the workflow for producing an MVD-conformant export.
• ifc-impl-cobie : the COBie handover workflow and spreadsheet duality.
• ifc-syntax-step-physical-file : the STEP Physical File HEADER and DATA sections.
• ifc-core-standards-overview : the IFC versions, certification, and validation.
• ifc-core-version-evolution : version-by-version schema changes.