buildingSMART / buildingSMART/IFC4.x-development

Documentation of appropriate usage of Name, Description, and LongName, and the type Name

Open
#178 1 comment 0 reactions 0 assignees View on GitHub
allocated-core ifc-update-out proposal
Dominant language
Python
Stars
234
Forks
123
Avg merge
15h 4m
Merged PRs (30d)
5

Description

Brought up [here](https://forums.buildingsmart.org/t/proper-use-of-name-type-type-name-and-description/2542) in the bSI forums but definitely a recurring topic I have heard countless times: users and implementers are not sure exactly how to fill in these attributes for common elements. This is not a schema problem, but just a documentation problem, but a really important one as it is how users find things.

For an architect, an IfcElementType.Name should match the name of the type in their schedule. For example, a door type of "DT01" as labeled in documentation and in schedules should have IfcDoorType.Name = "DT01". Then, IfcDoorType.Description should be the human description of that door type, typically seen as something like "Solid core double panel door blah blah". Then, the individual instance IfcDoor should have the exact door number as labeled on the drawing, such as "D01".

For spaces, let's say there is a room number of "1021", with a room name of "Communications room", then IfcSpace.Name should be "1021" and LongName should be "Communications room".

The concept of Name being the short code / label typically seen in documentation, and Description/LongName being the human description or full name is not something that is clear to users and implementers. To the extent that these things that should belong in Name is hidden in psets, the "ObjectType/ElementType" attributes are abused, and so on. There is also confusion about the "Reference" property seen in various psets.

Users are also not aware that these can be NULL. Architects label every door instance, but do not typically label every wall instance (unless it's precast, etc), and MEP people almost never label every valve instance uniquely in drawings, but do label each pump, etc. Making it clear that it can be NULL helps people understand it is optional.

I want to write a few documentation sentences describing examples of how to use this. Where would be the right place to write this? IfcElement? IfcElementType?

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the examples in this issue and the linked bSI forum discussion, then inspect the documentation context for IfcElement and IfcElementType. Identify the appropriate location for guidance on Name, Description, LongName, and Reference, including when values may be NULL. Done means the examples and optional-value guidance are documented in an agreed location.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.