Are you allowed to link multiple ifc-defined dynamic property sets (IfcPropertySet, “Pset_…”) with identical name directly to the IfcObject (IfcRelDefinesByProperties); or directly to the IfcTypeObject (HasProperties)?
This seems like a mess when both the IfcObject and the IfcTypeObject have at least one like-named dynamic property set attached, and at least one of the IfcObject and IfcTypeObject has two like-named ones directly attached…
I’m asking becuase Ifc4 Add2 Tc1 allows multiple occurrences of e.g. IfcWindowPanelProperties, and Ifc4x3 Add2 deprecates this entity but provides Pset_WindowPanelProperties as a replacement. Note that the Pset_WindowPanelProperties is TypeDrivenOverride.
Question tree:
Is is allowed to attach multiple dynamic property sets with the same same directly to an IfcObject / IfcTypeObject?
If so: How does this work for TypeDrivenOverride properties?
If not: How to handle multiple occurrences of e.g. IfcWindowPanelProperties inside Ifc4x3?
I see your point. Over time as maturity increases, I think property sets will get a proper compatibility assessment between releases, but my perception of the current viewpoint in the community is that given the current inconsistencies, misspellings and idiosyncrasies in ifc4 property sets, it’s better to look forward and improve where we can, rather than be too limited by compatibility and unable to address issues. This is also the intention behind property sets, to allow a higher degree of changes between releases as they do not affect serialization.
I understand that the intention is present to reach full backwards compatibility, up to the same level that the c++ 2017 standard encompasses the entire c++ 1999 standard. I hope this soon becomes a goal for buildingSMART.
I’m not entirely sure about that. Within the community there are voices that IFC is acceptable and only needs incremental (compatible) improvements. On the other side there are voices that see fundamental issues with the current IFC.
In the world of software development it’s not so essential to keep these kind of voices on board (these same negative voices exist in the C++ discourse as well - backwards compatibility in C++ is a real concern for these people as it really limits the the expressiveness of certain direly needed extensions such as modules / concepts / etc.), but they can move to Rust if they want higher degrees of memory safety or Nim or Haskell if they want a more expressive or functional syntax. And they can still interoperate by means of JSON REST apis or foreign function interfaces or wrappers or stdout pipes or whatever.
In the world of IFC that is different. Interoperability with other data modelling standards is much harder.
In the world of IFC that is different. Interoperability with other data modelling standards is much harder.
Ifc is currently not one data format, but there are three separate data formats (ifc2x3, ifc4, ifc4x3), which just happen to have the same file extension. Conversions between ifc versions require quite a bit of hand-typed code to convert the odd cases.
It doesn’t help interoperability with other file formats (like revit or qonic) that there are interoperability issues between ifc versions, au contraire. I understand breaking changes can be needed to reach an ultimate goal, but I don’t get the goal of buildingsmart and ifc : is it an ongoing perpetual experiment, do you even aim to converge towards a backwards compatible (but extendable) file format, will it forever be something in between?
In the first case, it doesn’t make sense for implementers to spend time in supporting (one or more versions of) ifc for 100% to the bottom line, because part of the work will become obsolete when the experiment chooses another direction, and the bar lies exactly at supporting what other programs export of ifc. In the second case, it does make sense to invest the time and to even encapsulate everything that can be expressed in ifc in full in an internal file format.
Making (one or more versions of) ifc an ISO standard gives the impression that it has left the stage of experimentation.
To come back to C++ : there was an experimentation zoo for C++ : boost. And it was very clear which was experimentation and which was standard. Perhaps such a clear distinction should also be made within ifc.
16y ago when IFC2X3 was released, I don’t think we as a community had the same view on what BIM interoperability looked like. That’s why indeed IFC4 with ReferenceView is rather different paradigm in a rather similar schema. IFC4.3 was aimed at solving again different challenges. If I look ahead at the direction in which IFC5 is heading it is aimed at yet again solving a different set of challenges that are poorly managed in the express ecosystem such as incremental, partial exchanges and more seamless information sharing. So what you’re seeing is a response to market (and member - I reckon) demands. I would advise to get more involved (if not already) on a technical level or organizational level.