Lesson 4.3Lesson 4.3 · Interoperability & openBIM
BCF, bSDD & IDS
The open toolkit beyond the model — issues, shared meaning, and checkable requirements
You found a clash. Do you email the whole 2 GB model — or just the problem?
IFC moves the model between tools. But most of a project's collaboration is not moving models — it is moving *conversations about* models: this clash needs resolving, that object is misclassified, is this fire rating confirmed? Send the whole model every time and you drown; keep the conversation trapped in one vendor's tool and you are locked in all over again.
So openBIM has a toolkit *beyond* IFC, and three open standards do most of the work. BCF carries the issues without the model. bSDD makes sure everyone means the same thing by the same word. IDS turns 'what information do we need' into a rule a computer can check. Together they make the *collaboration* vendor-neutral, not just the geometry — and they are the difference between openBIM as a file format and openBIM as a way of working.
Send the issue, not the model. Agree the words, then the data. Write the requirement as a rule, then let the machine check it.
BCF: send the issue, not the model
BCF — the BIM Collaboration Format — solves a beautifully specific problem. When you find a coordination issue (a duct clashing with a beam, a door that opens the wrong way), you do not need to send the entire model to raise it. A BCF issue carries just what is needed to talk about the problem: a comment, a viewpoint (the exact camera angle so the recipient sees precisely what you see), and a location or reference to the specific elements involved — often with a status (open, assigned, resolved).
That is enormously practical. A coordinator can run clash detection, package the real issues as BCF, and send them to the architect and engineer, who open them in *their own* tools, jump straight to the problem, fix it, and send the resolution back — all without anyone shipping gigabytes of model back and forth or being forced onto the same software. BCF is the open conversation layer of coordination: lightweight, tool-independent, and focused on the issue rather than the whole building.
bSDD: everyone meaning the same thing
Open exchange is worthless if two tools use the same word for different things, or different words for the same thing. Is it a 'door', a 'doorset', a 'DR'? What exactly does 'fire rating' mean, and in what units? Without shared definitions, IFC moves data that is technically readable but semantically confused.
bSDD — the buildingSMART Data Dictionary — is the answer: a shared, online library of classifications, properties and their allowed values, so that objects and their data can be tagged against agreed, unambiguous definitions. When a project references bSDD, everyone's 'fire door' points to the same definition and everyone's 'thermal transmittance' means the same measured thing in the same units. It is the standard that gives the shared *vocabulary* real, machine-readable meaning — the dictionary behind the language IFC speaks. Unglamorous, and absolutely fundamental: data you cannot interpret consistently is not information.
IFC is the grammar. bSDD is the dictionary. Without the dictionary, everyone speaks fluent nonsense.
IDS: turning requirements into rules a computer can check
For years, information requirements lived in prose — a client's document saying 'every fire door shall carry its rating, manufacturer and certification'. Prose cannot be checked automatically; someone has to read the model and the document and compare, by hand, which does not scale.
IDS — Information Delivery Specification — fixes that by making requirements machine-readable. An IDS is a precise, computable statement of what information must be present: which objects, carrying which properties, in what form, referencing which bSDD definitions. Feed a model and an IDS to a checker and it reports, automatically, exactly where the model meets the requirement and where it falls short. This is transformative: it turns 'is the data complete and correct?' from a slow manual audit into an automatic, repeatable test. IDS is the natural partner of the EIR and BEP in Module 5 — it is how the information requirements stated there become something you can actually *validate* rather than merely hope for. Together, BCF, bSDD and IDS extend openBIM from moving models to running the whole collaboration — issues, meaning and verification — in the open.
Three altitudes on the same idea
Read the band that fits you — or all three.
Learn the three by their jobs. BCF (BIM Collaboration Format) sends a coordination *issue* — a comment, a viewpoint, and which elements — without sending the whole model, so people fix problems in their own tools. bSDD (buildingSMART Data Dictionary) is a shared online dictionary of classifications and properties, so everyone's 'fire door' and 'U-value' mean the same thing. IDS (Information Delivery Specification) makes information requirements machine-checkable, so a computer can verify whether a model actually carries the required data. IFC moves the model; these three make the *collaboration* — issues, meaning, checking — open too.
Put each to work. Package clashes and review comments as BCF so disciplines resolve them in their own software and send resolutions back — no giant model transfers, no forced common tool. Tag objects and properties against bSDD definitions so your data means the same thing to everyone downstream. And where a project has an IDS, run your model against it before you share or hand over, so you catch missing or wrong data automatically instead of discovering it at review. These are the standards that make your open exchange actually usable, not just technically valid.
Specify the toolkit, not just IFC. Require BCF for issue exchange (keeps coordination tool-neutral and auditable), reference bSDD (or an agreed classification) so data is semantically consistent across the supply chain, and — increasingly the highest-leverage move — define your information requirements as IDS so they can be validated automatically rather than checked by eye. IDS is what turns the EIR/BEP from a wish into an enforceable, testable contract for data quality. Adopting these alongside IFC is the difference between 'we exchange files openly' and 'we run our whole collaboration in the open, and can prove the data is right'.
“openBIM is just IFC — one open file format for the model, and that's the whole story.”
Do it yourself
Match each open standard to the real problem it solves.
- 1Write three problems on a page: (a) 'I found 40 clashes and need the architect to fix them without me emailing a 2 GB model.' (b) 'Their model calls it a doorset, mine calls it a door, and the schedules won't reconcile.' (c) 'The client requires every fire door to carry its rating and certificate — how do I check 800 of them?'
- 2Now assign the standard: (a) → BCF, (b) → bSDD, (c) → IDS. Say in one line, for each, *why* that standard is the fit.
- 3Take (c) and imagine checking it by hand versus running an IDS: estimate the difference in time and reliability for 800 doors. That gap is why machine-checkable requirements matter.
- 4Finally, connect it forward: which of these three will directly turn the client's information requirements (the EIR, coming in Module 5) into something you can automatically validate? (Answer: IDS — and note why prose requirements never could.)
The one line to carry out
We can move models, issues, meaning and requirements — all in the open. The last piece is the handover itself: distilling all this into the structured data an operator can actually use. Next: COBie and structured handover.
The author
Amogh N P
Architect, interior designer, and creative polymath. Studio Matrx began in his notebooks — his vision of design made honest, useful, and open to everyone. Its Academy is written and taught in his memory, and free, forever.
More about Amogh →