Value Comparison

[atomczak]

From Mohit Mangal (SBI International): Current IDS do not support checking using the comparison of two values (E.g., “Warranty End Date” to be later than the “Warranty Start Date”) Good to allow such comparisons.

[atomczak]

That is an advanced feature that would make IDS more complicated, let's first make sure there is enough demand for it. Please add your vote if you find this feature worth considering by the group for future versions of the IDS standard. Examples of what you plan to use it for are also welcome. I can think of sanity checks like "GrossVolume" > "NetVolume".

[aothms]

At some point we'll likely get to this, some form of function evaluation or relational predicates instead of a direct unary value to compare to. But I think the increase in complexity is large and the utility gained from this is fairly low. You can also see this in the IFC Express schema. In the end we didn't actually write a lot of rules (but some of them are very powerful and valuable), but the increase in complexity of being able to evaluate them is huge. You can also think of rules like: is my date actually valid: "29th of Feb only allowed on leap years", etc. People will likely ask for this at some point, but the amount of intellectual effort required to encode this in the standard is most likely not worth it unless we have researched and grouped a wider set of use cases that can be addressed preferably by using a pre-existing vocabulary.

[oscarjacobsen]

Hi! I would like to add a comment to this idea

As you know @atomczak, the Norwegian Road Administration(SVV) (and I ++) is nowadays doing a Proof of Concept, looking into:
"How can the complete bS-openBIM framework give value to SVV, as the largest Norwegian Roads asset owner?"

From before, SVV has published their 188 AIM-classes to bSDD; where this PoC is testing/proving capabilities and values of using bSDD + IFC-IDS-BCF for one of the classes.

https://search.bsdd.buildingsmart.org/uri/NVDB/nvdb/6.0/class/NVDB_Trekkekum_853
(Norwegian classification for electrical cable draw pit)

Our results have not yet been published, but we find the main missing capability for the current version of IDS, is not being able to check one value against another. Which is seen as an valuable part of typical logical requirements one would/could/should want to check.

Taking it one "giant leep" further, would be being able to do checks not only across properties of one instance, but also across instances.
Within the 188 SVV AIM-classifications, a typical example here is street lights, which could be seen as an assembly of all these classifications:

Light Source (Belysningspunkt_87)
Light Fixture (Lysarmatur_88)
Light Pole (Lysmast_181)
++

Where there often exists reasonable logical relations between the instances, that would be best if checked. :)

Hoping and looking forward to the furter development of IDS and it's companion three-capitol-letter solutins 💯
(Other than this, the value in use of bSDD + IFC-IDS-BCF is looking really good for our case!)