The OpenBIM Pledge

The OpenBIM pledge is a no-nonsense, step-by-step practical strategy to raise adoption of 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. This is a technical document, aimed at a technical audience of digital engineers. Signing this document 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.

The following tiers are aimed at both those requesting and providing BIM.

Tier 0

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

• I solemnly swear to require "IFC" (as vague as that is) as part of a deliverable. I will actually check that I've received something, and at least open it to make sure it contains information relevant to the project.

Tier 1

• I will require and check for a specific IFC schema version (IFC2X3, IFC4, IFC4X3), acknowledging practical differences between IFC versions.
• If I require for any simple properties attached to objects, I will specify and check for a property name, property set name and IFC data type (e.g. IfcLabel, IfcIdentifier, IfcPositiveLengthMeasure) of the data.
• I will 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.
• If an IFC is not delivered, I will withold payment if it is within my power to do so.

Signatories: your company here?

Tier 2

• All IfcProduct and IfcTypeProducts must be assigned to the correct IFC class. 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. This does not stop you from using additional classifications on top of IFC's built-in classes.
• If I require properties or quantities that already exists as part of a buildingSMART standardised template (i.e. those prefixed with Pset or Qto), I will use that instead of reinventing my own.
• I will specify the applicable IFC class for all properties that I require. This ensures people understand which objects need which properties, and it can be automatically checked.
• I will provide an IDS for simple property requirements so that audits are standardised and there are no ambiguities are nasty surprises.
• I will validate IFCs and report validation bugs to software vendors. This provides a reliable technical foundation that we can build systems upon.

Signatories: your company here?

Tier 3

• If I require anything to be georeferenced, I will 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 and/or IfcSpatialElement. This ensures that documentation at least correlates to BIM data (otherwise everything else becomes almost meaningless).
• If any name is not self-explanatory (e.g. a coded naming or numbering system), then a Description attribute (not a property!) must be provided of all IfcTypeProduct and/or IfcProduct and/or IfcSpatialElement (LongName instead of Description). Descriptions should be sufficient so that those reading a schedule of my objects can understand what the object is without visually looking at a 3D model. This provides a strong foundation to any non-graphical scheduling or query.
• If I additionally want my own classification system on top, it must be stored as a classification reference in an IfcClassification, 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.

Signatories: your company here?

Tier 4

• If I require information about the system that a product is part of, I will use IfcSystem classes appropriately, instead of storing this information in a property set. This is the first step to semantically storing useful system connectivity.
• If I have my own invented classifications, properties, or materials, I will submit and maintain a register of the in the bSDD. This allows tools to integrate with my data schemas in a standardised manner.

... more to come.