The OpenBIM Pledge

The OpenBIM pledge is a no-nonsense, step-by-step practical strategy of adopting best practices in international, open data standards based BIM. If all companies agree to incrementally implement these principles, we can move towards standardised data across the world, and a strong foundation to build all digital processes, workflows, and future visions of our built environment.

This pledge is inspired by the pledge signed by browser vendors who stopped fighting and instead worked together to implement standards-compliant web technologies. It is entirely voluntary.

This is a draft. I did a braindump at 1am without holding back and haven't digested anything. Please braindump your own ideas by editing this page and we can collectively polish this.

Tier 0

This is basically the participation trophy. It's better than nothing.

• I solemnly swear to require an IFC as part of a deliverable. I will actually check it, and at least do some cursory checks (e.g. not empty file) to make sure it contains something that looks like the project.

Tier 1

• I will require and check for a specific IFC schema version, checking out practical differences between IFC versions.
• If I require for any simple property data attached to objects, I will specify and check for a property name, property set and IFC data type (e.g. IfcLabel, IfcIdentifier, IfcPositiveLengthMeasure) of the data.
• If an IFC is not delivered, I will withold payment if it is within my power to do so.
• My contract should not penalise any stakeholder from using any software they want, giving them freedom of using the best tool for the job, so long as OpenBIM deliverables are provided.

Tier 2

• In addition to any of my own preferred classification systems, all IfcProduct and IfcTypeProducts must be assigned to the correct IFC subclass. This means that regardless of people's favourite classification flavour of the day, there is a fallback "broad" classification that anybody can use for any process.
• If I require for any simple property data that already exists as part of a buildingSMART standardised property set template (i.e. those prefixed with Pset or Qto), I will use that, instead of reinventing my own.
• I will provide an IDS for simple property requirements so that audits are standardised and there are no ambiguities are nasty surprises.

Tier 3

• If I require anything to be georeferenced, I must require at least IFC4, and correctly implement IfcProjectedCRS and IfcMapConversion following the best practices of the buildingSMART user guide to georeferencing for vertical and horizontal projects. This is the first step to federating across models, GIS environments, and infra projects of the future.
• If anything is named in documentation (drawing, schedule, specification, etc), that name must be stored in the Name attribute (not a property!) of the relevant IfcTypeProduct and/or IfcProduct. This ensures that documentation at least correlates to BIM data (otherwise everything else becomes almost meaningless).
• If I additionally want my own classification system on top, it must be stored as a classification reference, not as a property. This means that filtering of classifiations can actually benefit from understanding the hierarchical nature of classifications.
• All physical products must additionally have a predefined type assigned. If any user defined values are used, it must be documented and audited. The rules of inheritance and override of predefined types must be followed. This leads to a more granular option of an international classification.
• If I want quantity data, it must be stored as a quantity set, not as a property. This allows us to separate calculable or geometry-derived data from semantic data so we can recalculate and check quantities properly.