I personally believe we should not ingest the advanced procedural geometric concepts from IFC into GeoSPARQL, for the reasons of:
Complexity
Ambiguity and implementation differences
But we can retain design intent and allow for reverse engineering the procedural built up of geometries by supplying supplementary aspects of the geometry as universally understood primitives.
For example:
Boolean operations can be stored as the end-result but also storing the operands (i.e IFC4 Reference View)
Sweeps and extrusions can be stored as the end-result, but also storing the extrusion path as a polyline and the face as a polygon
I personally believe we should not ingest the advanced procedural geometric concepts from IFC into GeoSPARQL, for the reasons of:
But we can retain design intent and allow for reverse engineering the procedural built up of geometries by supplying supplementary aspects of the geometry as universally understood primitives.
For example:
See https://speakerdeck.com/aothms/ifc5-technical-prototypes?slide=13 and onwards for an visualization of these ideas (in the context of ifc5/usd).