Shouldn’t this PropertySet be assigned to IfcTransportElement?
Shouldn’t this PropertySet be assigned to IfcSpace?
This is indeed somewhat questionable, but it was on purpose.
Both of these cases are associated to the supertype of the entity you are referring to, because the properties are also applicable to the sibling types. We however didn’t change the name of the property set for compatibility.
In the future we will not be using this EntityNameCommon naming schema, but rather use naming based on the specific traits that a property set provides.
1 Like
Well, nothing official, but I see the trajectory we’re on with things like e.g Pset_Tiling and the plans for IFC5 with an entity-component structure I think it’s a safe bet.
1 Like
Whatever IFC5 will finally provide regarding component-oriented development seems to demand another way to structure the current Standard Property Framework. Or do you think the current approach would suit what’s intended, or can we foresee following the GA of the Implementer’s discussions?
Indeed, I envision the coming two GA of Impl meetings being really instrumental in shaping that discussion. Coming one I won’t be present myself, but the one after I try to attend.
You can standardize components in an ECS. In fact, this is common in gaming systems… an example - a standard “ID” component can be attached to a variety of entities. It has a convention that works across all entities regardless of their type or what system they are being lumped into… kinda like a GUID.
I found this resource to help wrap my head around the concepts when first proposed. Another one I referenced was this.
With IFC5, there is an opportunity to review the previous logic and present a new one, maybe with updated logic and more… granular… to avoid large Psets (components) with a dump of properties that are loosely related. Of course, the beauty is on-the-fly extensibility (similar to custom property sets and properties, but the risk is letting those get out-of-hand and having duplication/redundancy/conflicts.
I think the session by @gschleusner in Lillestrom started to get into the “how” in defining components based on translating what we do know/use in the schema now. Some may disagree as the best place to start, but you gotta start somewhere.