Deciphering Concept Usage in MVDs: Identifying Compatibility, Incompatibility, and Irrelevance for Export

Hello, everyone.
I’ve recently been delving into information exchange requirements based on MVDs. However, I’m facing some uncertainties regarding the fundamental concepts. Specifically:

(1) How do we categorize concept usage into groups such as ‘Compatible but not in the scope,’ ‘Incompatible,’ ‘Not relevant,’ ‘Mandatory for export,’ or ‘Optional for export’? I have an example illustrated in the figures below.

(2) I’m curious about the process of marking concept usage that falls outside the existing scope defined by buildingSMART. For instance, the BACnet Performance History Predefined Type lies beyond the IFC scope but has been designated as Import/Export mandatory.

(3) In the event that I aim to create a private MVD tailored to my specific information exchange requirements, I’m wondering if I have the freedom to designate entities, determining whether the concept usage should be marked as import/export mandatory or optional.

Here are two examples of MVD based information exchange.

MVD based information exchange between BIM and building energy performance simulation

BIM assisted Building Automation System information exchange using BACnet and IFC

IfcController (

Thank you for your attentions!
Best regards.

I try to summarize some of the recent thinking (not universally accepted though) in the bSI community regarding MVDs The curious case of the MVD - buildingSMART International

  • MVDs as arbitrary selections of concepts are not easily computable. So things like compatibility or conversion are impossible.
  • It’s rather unsemantic. Concept graphs are described, but any formal description on what that means remains solely in human readable text or unspecified.
  • As such, a runtime implementation of MVD is impossible. You can test whether an exported model complies with an MVD (to some extent if the semantics were a bit more precise), but a mapping from the domain model constructed at runtime is impossible.
  • Given limited resources with software vendors and software release cycles this makes the MVD concept more or less infeasible.
  • If followed in software. It creates widespread incompatibilities. But this is not observed in practice due to the fact that MVD is barely implemented in mainstream software.

The workflow of thinking about exchange requirements remains incredibly valuable, but in the current software landscape it’s a lot easier to conceptualize these as IFC4(.3)RV + IDS GitHub - buildingSMART/IDS: Computer interpretable (XML) standard to define Information Delivery Specifications for BIM (mainly used for IFC)