we are currently refining our office IFC workflow (based on Allplan 2025), and several questions came up regarding the correct use of Name, Reference and Predefined Type.
From our understanding, Name is typically used to describe the instance of an element, for example a door number such as “105”. However, how should Name be used for elements such as walls or slabs? would something like “External Wall” be appropriate, or should Name remain instance-related only?
Regarding Reference, buildingSMART defines it as:
“An identification used to group similar elements into a building element type (also referred to as construction type). It can serve as an alternative to the name of the type object, especially if the software does not support types.”
In practice, how is Reference expected to be used? should it contain a structured type code from a catalog (e.g. AW01, FE05), or rather a descriptive type definition (e.g. AW-STB-200)?
What adds to our confusion is that in IFC 4.3, the property Reference within the Common Property Sets is marked as deprecated. Instead, the attribute Name is supposed to be used. Should the Name attribute now contain a human-readable description (“External Wall”) or a structured code (“AW01”)? Is there any official guidance on this semantic shift?
Finally, regarding PredefinedType / USERDEFINED: when no standard PredefinedType applies, IFC recommends using USERDEFINED and describing the specific type in ObjectType. In tools such as Revit or Archicad this seems possible, but in Allplan 2025 it is not entirely clear how IfcObjectType can be properly defined. Is there a recommended approach for this?
@victorgm very good question, I don’t know if there is a standard answer to it.
I use IFC4x3 and Name attribute is for some ‘tag’ information (apparently the actual Tag should be reserved to proprietary software for compatibility)
For me Name describes the element a bit more into details than Type, to indicate the arrangement of the instance or its given tag in original drawings (beams, columns, etc)
Looking forward to learning more on this subject
“Name” is the field that you would use to capture what you would call that object if you were putting it in a schedule on a set of plans. “Description” is a good place to put something like “External Wall”.
Questions specific to the 2025 version of Allplan will probably get a better response from the vendor support channels.
My hunch (as a user, not a developer of the 4.3 spec): “Reference” deprecation may be due to the fact that IfcClassificationReference and IfcDocumentReference are available for use in associating reference information to objects.
I have the habit of using Name as “identification” of an instance (wall 01, D0-05, L02.01, …), not typing, no (deep) semantics. But it’s confusing for users, when the modelling software makes it hard to distinguish between instance and type in their IFC export.
Don’t know how much control you have inside Allplan.
The deprecation of Reference is also a but unfortunate, especially within the same 4.x generation of the schema. A software like Revit copies its type name in many different places at the same time, including reference, but also in the name (type name + added instance identifier).
And while “tag” was used for such instance-fields, in practice this is where native software typically dumps their own internal ID or GUID.
In the case of elements, my advice to my clients is this:
The object name (IfcRoot.Name) should be unique to identifying the object. The type name (IfcElementType > IfcRoot.Name) should be used to identify the type (family) of object. For examples:
Walls:
Object name = “WALL W-01A 43” or simply “W 43”, aka the 43rd wall, maybe 01-43, as in 43rd wall on the first level
Type name = “W-01A” as it identifies the common “type” of material layers for specific purposes. You could also use terms like “interior partition”, “fire wall”, “exterior partition”, etc. if you wanted to be more generic, but such identifying info might also be found with the IfcMaterialLayer and IfcWallType.PreDefinedType
Door:
Object name = “D-02 12” or just “12”
Type name = “D-02”
Column:
Object Name = “Column B5_01”, meaning the column at grid intersection “B” and “5”, on the first floor
Type Name = “Col-04”, meaning the name of the column type/family.
In this way, one could schedule objects based on type and then enumerate further all the objects within a type.
Tag (IfcElement.Tag) might be useful, but I find is often inconsistent in implementation. I think Tag should be used in conjunction with a real-world Tag that might be attached to a prefabricated or manufactured item. Sometimes those have their own nomenclature and logic that should be correlated.
Thank you all for your advice and detailed answers!
I understand that the usual approach is to use Name to identify an instance (e.g. Wall 01, Door 05). For example, Revit automatically combines the type name and instance ID in IfcRoot.Name.
In our architecture office, however, we usually do not perform site supervision, construction progress tracking, or asset tracking, so numbering every wall is not necessary for us. We do use instance identifiers for doors or rooms, where schedules are required. Since we work in Germany, we were considering using Name instead as a human-readable element name in german to improve model readability (e.g. “Aussenwand” = “Exterior wall”, and similarly for slabs, beams, etc.). Would that make sense in practice? We normally do not use Description, but since it exists in Allplan, we could also consider using it for that purpose.
Regarding Type Name, I understand that it should define the element type and replace Reference. The difficulty is that Allplan currently does not support types, so we cannot use Type Name to define identifiers such as W-01A or D-02, nor use ObjectType for USERDEFINED PredefinedType. In this case, would you recommend continuing to use Reference (although deprecated since IFC 4.3), or rather using a custom attribute to define the element type?
Finally a suggestion: the use of the term “Name” both for IfcRoot.Name and IfcTypeObject.Name can be confusing for users. Would it make sense for software interfaces or documentation to distinguish them more clearly (e.g. “Instance Name” vs “Type Name”)?
Ooof. Is this really true? 2026, three versions of IFC, and two certification processes later, and still no Type support in Allplan? I think you have far bigger issues, then. The problem is then all the other stakeholders you share data with have to accommodate one tool’s (and one tool user’s) shortcomings… which is an anathema to the whole concept of openBIM. I suggest you contact Customer Support at Allplan to see what is going on… maybe you’re missing something? If not, and this really is an ongoing issue for Allplan, then you and your firm may have other conversations to consider moving forward.
Yes, it is true that Allplan does not support Types yet. I also confirmed this with their technical support, and this was their response last week:
“ALLPLAN currently does not support object ‘typification’ (except for macros, SmartParts and PythonParts). This means that even for elements with identical structure, such as walls or columns, there is no higher-level type definition that individual instances can reference. As a result, a USERDEFINED ObjectType cannot be created and the corresponding field cannot be populated. *There are ongoing internal discussions about when, whether, and how this could be implemented for all objects, where technically feasible, but unfortunately I cannot provide any information on that at the moment. However, the topic of Reference/Name is independent of this, since even with the Reference attribute it was not (and still is not) possible to create a USERDEFINED type description or to map its value to the IFC attribute Name. To achieve this, an additional IfcObjectType object would have to be created for each case within an IFC file. The Allplan IFC interface currently only supports this to a limited extent.”
In our case, we mainly design residential buildings, schools, and public buildings, where handover to facility management and the related processes are not yet very advanced either. Therefore, I do not consider it critical that our IFC models are currently not 100% aligned with the buildingSMART structure, although it would become an issue if this remains the case in the future. We are also considering the possibility of testing Revit and introducing it gradually, but this would involve many additional challenges in an office with more than 100 employees.
In any case, what would you recommend in our situation? Would you use Name only as an identifier for an instance, or also as a short designation of the object to simplify the readability? And since we cannot use TypeObject.Name, would you continue using Reference, or would a custom attribute be the better option?
Use Name. As in previous examples, you could include the type in the name logic (e.g., “D-01_45” or “W-A_14”).
Do not use deprecated concepts in a schema. Instead, you could consider using IFC4 instead of IFC4.3 (not widely supported anyways), where Reference has not been deprecated.