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.
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.
