# How do you store element "codes" in IFC? **URL:** \ **Category:** Developers\ **Created:** [January 17, 2019, 3:30am UTC](https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884 "2019-01-17T03:30:28Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [January 17, 2019, 3:30am UTC](https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884/1 "2019-01-17T03:30:28Z")
As an example: For architectural uses, traditionally we record three pieces of information about a door: its door type (e.g. D01, D02, D03, for instance D01 would be a 2400x920 metal door with 2 hour fire rating, and D02 would be a 2100x820 wooden door), and its door number, which is simply an identifier for that door (e.g. 01, 02, 03). Usually these identifiers are paired with the room that the door opens to, so a door D01, with number 01, might be in room G01. Where should these attributes be stored in IFC? Or should they be stored at all? Programmatically, without any human data, we can extract the following: - The spatial relationship with the door and an IfcSpace can derive the room the door is part of. If nothing else, the IfcSpace _must_ have a GlobalId, so we can schedule and identify it. - The door type can be derived by the IfcDoorType IsTypedBy relationship, and each IfcDoorType has a GlobalId. Not exactly pronounceable, but it can be identified and scheduled. - The door number can be derived by the IfcDoor’s GlobalId itself. Again, not a traditional “number” by any means, but it is technically unique. However, where is the proper place to store this information? Should I store the name of a room in `IfcSpace.Name`? Or should I store it in `IfcSpace.Pset_SpaceCommon.Reference`? Similarly, should I store the door number in `IfcDoor.Name`, or in `IfcDoor.Pset_DoorCommon.Reference`? Should I store the door type in `IfcDoorType.Name`, or is there another location that I am unsure of? ---
**Author:** ![stefan.markic](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/stefan.markic/32/168_2.png) [@stefan.markic](https://forums.buildingsmart.org/u/stefan.markic)\ **Post date:** [January 17, 2019, 5:49pm UTC](https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884/2 "2019-01-17T17:49:01Z")
Perhaps this link can help you with your questions: [http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/ifcexternalreferenceresource/lexical/ifcclassificationitemrelationship.htm](http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/ifcexternalreferenceresource/lexical/ifcclassificationitemrelationship.htm) ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [January 17, 2019, 9:11pm UTC](https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884/3 "2019-01-17T21:11:05Z")
I think you may have misunderstood my question. IfcClassification is meant for classification systems such as Uniclass, Uniformat, Omniclass, etc. So no, this doesn’t help answer my question unfortunately. I am talking about simple identifiers within a building, like this door belongs to room G01, is of door type D01 detailed in our door schedule, and is door 01 in the room. ---
**Author:** ![TLiebich](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/tliebich/32/71_2.png) [@TLiebich](https://forums.buildingsmart.org/u/TLiebich)\ **Post date:** [January 18, 2019, 10:12pm UTC](https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884/4 "2019-01-18T22:12:23Z")
If I understand you correctly, then what you refer to as door type D01 is what has been called “construction type” in IFC development. There is a rule to store it either as Name attribute in the according type object, e.g. as IfcDoorType.Name=“D01”, or (if no type objects are provided) as Reference property in the according property set, e.g. Pset\_DoorCommon.Reference=“D01” See also: [http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-136](http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-136) ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [January 19, 2019, 1:45am UTC](https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884/5 "2019-01-19T01:45:18Z")
That’s exactly what I’m looking for. Thanks! It is clear that the two locations (i.e. `Name` and `Pset_*.Reference` is a source of confusion. I think `Name` makes much more sense. ---
**Author:** ![TLiebich](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/tliebich/32/71_2.png) [@TLiebich](https://forums.buildingsmart.org/u/TLiebich)\ **Post date:** [January 20, 2019, 4:34pm UTC](https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884/6 "2019-01-20T16:34:54Z")
sure, two locations are less good than one. The agreement dates back to a time, when there was little support of type objects, and should read: 1. if a type object is assosziated to the occurrence object (e.g. IfcWallType to IfcWall) then the construction type is provided by the Name attribute (e.g. IfcWallType.Name) 2. if not, then the Pset\_XxxCommon Reference property associated to the occurrence object shall be used (e.g. Pset\_WallCommon.Reference) 3. if both are present, the Name at the type object takes precedence (need to be added to the concept definitions in the specification) ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [January 20, 2019, 9:27pm UTC](https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884/7 "2019-01-20T21:27:53Z")
Thanks for the clarification, as that last sentence (“If both information is present, the construction type assigned to the occurrence shall override the construction type assigned to the type.”) was really confusing. Your clarification of “if both are present, the Name at the type object takes precedence” makes much more sense. In that case, if the preferred method is to store it in `Name`, I propose to mark as obsolete, or deprecate the `Pset_DoorCommon.Reference` field, unless there is a valid explanation as to its existence. This proposal goes not just for `IfcDoor`, but for all IFC elements that have this source of confusion. What is the process to get this proposal approved and implemented? I can create a list of property sets which need changing. I notice that the JIRA instance has a message saying that it will be moved and no new issues will be accepted. ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [February 25, 2019, 12:00am UTC](https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884/8 "2019-02-25T00:00:09Z")
Just following up on this - what is the process to mark the `Reference` field as obsolete to prevent confusion in the future? Also, rereading [http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-136](http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-136) actually says the opposite to what @TLiebich answered - the website says that occurrence (i.e. `Reference`) trumps type (i.e. `Name`). ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [June 17, 2021, 11:07pm UTC](https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884/9 "2021-06-17T23:07:17Z")
Bumping to finally include officially in the docs, not as an implementer agreement (link is now broken). > > > Full discussion \[here\](https://forums.buildingsmart.org/t/how-do-you-store-eleme…nt-codes-in-ifc/884/3). > > In short, architecture defines codes for construction types, such as \`D01\` for a fire-rated, single leaf, metal framed door, and \`D02\` for a non-fire rated, timber framed door. > > The IFC documentation does not make it clear that these codes should be stored in the IfcTypeObject's Name attribute, even though that is the intention as mentioned by @TLiebich. > > Also, there is a legacy \`Reference\` property when vendors didn't have support for types. But in 2021, most vendors do have type support. There is already an implementer agreement about this conflict, but let's resolve it and include in the docs. > > I propose to remove this legacy Reference property so there is no more confusion, also I propose that on the IfcDoorType, IfcWallType, and IfcWindowType pages, a sentence be added basically giving an example of \`D01\` like I gave above. More relatable examples I think will help ensure IFC data is more useful. The majority of export mappings currently get this wrong, and I see all sorts of stuff populated in the Name fields. > > Ping @berlotti @TLiebich @aothms