Repository navigation
Cannot specify predefined type in IFC #129
Description
IFC classifications (classes) are a bit special :)
In most classification systems, they have N levels in their hierarchy, and these are set in stone. You cannot make up your own classification code.
In IFC, however, there are 2 levels. The first level is set in stone (and varies per IFC version). The second level (predefined type) has some set in stone, but you can also set it to a userdefined value.
This is great, because you can "extend" IFC quite easily when a predefined type doesn't exist. It's not so great, because there is no way to currently publish your userdefined types. bSDD cannot do this :(
This becomes quite a big issue because many psets in IFC are applicable only to specific predefined types. This cannot currently be captured in bSDD, so we end up with a bunch of irrelevant properties showing up.
I totally get how the problem with predefined type is that it's sort of a weird attribute thing (not property) with userdefined, which is different to most other classification systems.
So I guess either:
- Adapt bSDD to specify attributes, perhaps on the "Class" object as well as Class-Property relationships.
- Explain in docs what the alternative is. But I can't really imagine how to do this well because predefined types is critical to how buildingSMART psets work. Literally every single authoring tool has both class and predefined type baked in as a dedicated interface.
Note that this is not just classes, IFC also has material categories, which define how properties are applicable too.
Activity
atomczak commentedon May 19, 2025
(IFC) Entity / Predefined type --> (bSDD) Class
In bSDD we have Classes that represent both IFC entities and predefined or user-defined types. For example, RETAININGWALL is a predefined type of an IfcWall, but is represented as a sub-class in bSDD: https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/class/IfcWallRETAININGWALL
This way users can extend IFC by defining more sub-classes of IfcWall, or even sub-classes of RETAININGWALL. And they can also relate properties to them.
The idea of bSDD is to discourage inventing new user-defined types, and add classification-references instead, as they provide more metadata like the author and identifier. I get your point that market is used to predefined types and those are here to stay as long as IFC2x3-4.3 are in use. I hope, going forward, IFC will not have attributes and predefined/user-defined types, just (sub)classes and properties.
To enable software to distinguish which bSDD class was meant to be represented in IFC2x3-4.3 as a predefined/object/element type we could add an optional boolean attribute "IsPredefinedType" (default: no). Would that be helpful in your case @Moult?
Yes, you can define those in bSDD as a Class of type Material, for example: https://identifier.buildingsmart.org/uri/sbe/swedishmaterials/1/class/CE12
(IFC) Attribute --> (bSDD) Property
Attributes, similarly to predefined types, are also very unique to IFC. In bSDD, both properties and attributes are captured as properties.
Moult commentedon May 19, 2025
Totally agree that the whole predefined type thing is an anomaly, and going forward it's better to reconcile with all classification systems. It would be good if this was formally confirmed by bS, which can then be explained in the bSDD docs.
That would be a great way to support IFC2X3/4/4X3 for the many years to come. I am also OK with the harsh approach of not supporting it and being opinionated against predefined type.
Sorry I don't quite understand this - which data in here correlates to the IfcMaterial
Categoryattribute?Categoryis essentially the equivalent of predefined type for IFC materials.I respectfully disagree here. Attributes are used for identification, where without it the object can be meaningless. Properties are used for enhancement, to enrich the information about the object. Most schemas distinguish between mandatory identifiers versus extensible properties. But I guess this is beside the point of this bugreport :)
atomczak commentedon May 19, 2025
Are you referring to the list of values from the IFC docs: 'concrete', 'steel', 'aluminium', 'block', 'brick', 'stone', 'wood', 'glass', 'gypsum', 'plastic', 'earth'? Or just to the general 'Category' attribute of IfcMaterial? So, right now, there is no such a link in bSDD. People can define a Class of Type: "Material", which is listed in a separate table later on. This can be used by software to pull only the classes that define materials. Would it help if we define the 11 basic values (categories) in the bSDD under the IFC dictionary? The list is not perfect, I'm missing categories that would cover, for example: ceramic, asphalt, other metals, textiles, mineral wool, but I also don't want to alter the standard.
It is possible to add a ClassProperty with an attribute "Category" from IfcMaterial, but that would probably list in IDS/IFC tools as a property, not an attribute, so I wouldn't recommend that. Better to express it in an IDS.
GlobalId is fine to me, but many attributes in IFC are properties in disguise. For example, OverallHeight of IfcWall. Name, Description, Tag, could all be properties. What I meant with 'attributes (...) are unique to IFC' is that in common BIM tools there is no distinction between the two.
Going back to your original request, I'm adding on the list o bSDD improvements:
Moult commentedon May 19, 2025
Yes. The Category attribute and the documented list of values (it was agreed that in the future that list would become an enum not just a text recommendation).
Agreed the list is not perfect, and will never be, but at least it allows any project around the world to ask the question "show me the steel elements" or "isolate concrete in my project".
This is very similar to the predefined type issue, do we:
My gut feel after sleeping on it is that it's better to keep bSDD leaner and encourage classifications for both objects and materials instead of this anomalous attribute. Thoughts? @berlotti @aothms ? That keeps "classifications" consistent. It's easy to add things, hard to take them away :)
Moult commentedon Oct 6, 2025
The more I think about it, the more I think predefined types should be supported. The reason is that if it's not supported, it encourages users to invent entire new classification systems independent from IFC. This fragments the industry and is against the spirit of standardisation. If predefined types are supported, then it encourages users to extend IFC and therefore standardisation.
We've published a bunch currently as classifications but our intention is to use them only as predefined types. It would be great if there was a boolean flag to indicate this somehow.
atomczak commentedon Dec 15, 2025
We are going to add a toggle attribute 'IsIfcPredefinedType' (default: no) that will indicate whether a class is a predefined type or not.