Very often we reuse data (especially geometries) in a model where it is unclear if this is for semantic reason (the elements should be in sync) or for storage efficiency.
The IfcReference - if changed into a rooted class - could provide a way to add this additional semantic dimension to unrooted elements.
Also, its usage should be extended to not only be used in metrics and applied values.
The problem might be that it would make it more difficult to enforce the correct class for attributes, though this is also the case in the current implementation.
With such a mechanism we could reuse local placements (named user coordinate systems), points (shared between an element and a dimensioning), etc. more effectively.
Very often we reuse data (especially geometries) in a model where it is unclear if this is for semantic reason (the elements should be in sync) or for storage efficiency.
The IfcReference - if changed into a rooted class - could provide a way to add this additional semantic dimension to unrooted elements.
Also, its usage should be extended to not only be used in metrics and applied values.
The problem might be that it would make it more difficult to enforce the correct class for attributes, though this is also the case in the current implementation.
With such a mechanism we could reuse local placements (named user coordinate systems), points (shared between an element and a dimensioning), etc. more effectively.