To use PredefinedTypes or not for IDS?

Read why creating rules for IfcEntities in IDS is insufficient and how the PredefinedType could be an alternative. Moreover get a list of translated PredefinedTypes to ease your start.

In software development, the concept of test-driven development exists, and I believe many BIM requirements would benefit from this approach as well. In short, it means don't formulate a requirement you can't formulate a test for.

One key ingredient in doing so with the IDS is the applicability. The applicability describes when to apply a ruleset. The picture below from the free Sortdesk IfcViewer shows how the definition of applicability can look like:

Unfortunately, most IDS I saw use the IfcEntity as the only differentiator. As in this case the IfcWindow.

The problem with this approach is that it's not specific enough, and you will likely have Elements with the same Entity but with different rules. For example, the classic IfcSpace is for the net room, and the Space could have an attribute for the floor material with a corresponding test in the IDS.

At the same time, the Space could be used to model the gross floor area.

When we test with the applicability IfcSpace, we would get an error message with all the gross spaces, as they should not define any floor materials.

The applicability has to be narrower to avoid this mismatch. For example, we could use IFC's PredefinedType and define a ruleset for PredefinedType.INTERNAL and PredefinedTyp.GFA.

Unfortunately, most models I see, and I see a lot of models due to the abstractBIM converter, don't use the PredefinedTyp. I blame the modeling software tools for this because they usually don't make it easy to work with them. For example, most of the time, if they have the PredefinedTyp selection lists, they are in English and not translated into their native language. Although my English is quite good, I struggle to explain the difference between a JOIST and a BEAM that both can translate to "Balken" in German (now I have looked it up and know it for the rest of my life, though :-).

To ease the beginning, I created this list with ChatGPT with many common PredefinedTypes and their translation to German, French, and Italian (so be careful when using it).

You can access the full list here.

Although the list of PredefindTypes is extensive there will always be something missing. The standard allows for this by choosing USERDEFINED and when defining the ObjectTyp. But once again, this is too complicated for the end user, and software tools should provide this logic in the background.

To end this article, I would like to start a Philosophical discussion. Do we need PredefinedTypes, or should this be country-specific?

The advantage of general predefined types is that software tools can implement them and automate more in the background without having to deal with country specifics.

The disadvantage is that something will always be missing, and adding new ones through the BuildingSMART organization can be cumbersome and slow.

So I leave it to you, but my opinion is that it’s great to have some standards to build on (although it’s not perfect). And I hope that now, with the introduction of the IDS, more people will start using the PredefinedTyp, as it is really quite extensive. Or, even better, more software tools start implementing the logic of the PredefinedTypes without forcing users to become IFC specialists.