File header, model view definitions and schema version

Summary

Every IFC file begins with a short header, written by the software that exported it. It states which version of IFC the file uses (the schema), which model view definition (MVD) it was exported for, who exported it, with which software and when. It is the label on the file. Model data stays in use for decades, and years after delivery the header is often the only record of where a file came from and what it was meant to contain.

forensicBIM shows the header in the File header card on the Validity page and tests it in several checks. A missing MVD leaves the recipient unable to tell what the file promises to contain. A placeholder author such as Architect means nobody can trace the data back to the party that delivered it. The schema version is shown for information and never scored.

What the header holds

An IFC file in its usual form is plain text, and the header is its first few lines. It consists of three statements:

Inside the model itself, the owner history (IfcOwnerHistory) records the owning person and organisation a second time, and IfcApplication names the authoring software. forensicBIM reads both and compares them with the header.

The File header card

On the Validity page, below the checks, the File header card shows these details as written by the exporting software:

A value that looks like a template default, such as Architect, Unknown, Default, Company or n/a, is marked (default). An empty value shows as missing. When the header and the owner history name a different author or organisation, the row says Inconsistent and shows both. The Units card next to it lists the units the file declares, explained in How we measure size, and which units you see.

Model view definitions

An MVD is a published subset of IFC for a particular kind of exchange, such as coordination between disciplines or handover for facility management. Coordination View 2.0 for IFC2X3 and Reference View for IFC4 are well-known examples. The MVD tells the receiving software, and you, what the export is meant to contain. Without one, nobody can tell whether something missing is a gap in the delivery or simply outside the scope of the export.

forensicBIM sorts each name in the header into one of four kinds:

The check is Model View Definition declared on the Validity page, with a weight of 0.5. A file that declares a recognised view as well as an add-on or a non-standard name still scores 100. For a non-standard name the report suggests exporting with a standard view such as CoordinationView_V2.0 or ReferenceView. Translator setting names in this place are common in ARCHICAD exports.

The MVD also counts towards the Coordination ready capability, whose condition Recognised MVD declared needs at least one recognised view. A declared view says what the file is meant to contain. Whether the elements really are contained, classified and carry data is measured by the other checks.

Schema version

The check IFC schema version shows the schema on a ladder of IFC2X3, IFC4 and IFC 4.3. It is for information only and never scored, because all three are valid choices. Newer versions add options: full georeferencing with a map conversion and a projected coordinate system needs IFC4 or later, and IFC 4.3 adds infrastructure entities for bridges, roads and railways.

Next to the schema, a label says whether the buildingSMART validation confirmed it: verified when the IFC schema topic passed, invalid when it failed, and unverified otherwise. On the Overview the last label reads not validated. The header only says what the file claims to be; the validation tests the claim. What the validation does and does not cover is explained in Passing the buildingSMART validation is not the same as good data.

forensicBIM will support IFC 4.4 and IFC 5 as they are released.

Checks that use the header

Gate checks are hygiene checks that nearly every file passes. They count for a quarter of their weight when the file scores 95 or more on them, and full weight when it does not. An author or organisation mismatch between the header and the owner history is counted once, in Header metadata coherent. The buildingSMART validation adds two topics on the header, Header syntax and Header fields, shown on the same page.

Getting the header right

Most header problems are fixed once in the export settings of the authoring tool and then stay fixed for every file. Fill in the author, organisation and project name in the project information, replace template values, and choose a standard MVD in the IFC export settings instead of a custom settings name. Check that the person and organisation in the project information match those in the header.

For an asset owner, the header is a cheap thing to specify in delivery requirements: a recognised MVD, the delivering organisation named as organisation, a real author and no placeholder values. The checks above show at a glance whether a delivery meets them.

Frequently asked questions