Introduce Machine-Readable-Names to General Types

[pranay2811]

This PR proposes introducing a dedicated name field to General Types in DBO. The name would be derived by extracting and standardizing the first portion of the existing description field. The goal is to improve machine-readability and simplify parsing of general-type names.

As an example, I have added name fields and cleared the first portion of the description field for the following types:

• VAV
• FCU
• AHU
• HX

We recognize this represents a structural change. This PR is intended as an illustrative example of the approach Onboard Data is proposing.

[pranay2811]

Hi @mschlaffer @tomfwilliams

Would love to get your thoughts on this proposal when you have a chance.

Thanks,
Pranay
@bsimmons-onboard for vis.

[shambersafai]

Hi @pranay2811, the Carson team is transitioning to new ownership. Looping in @nkilmer in place of Markus.

[pranay2811]

Hi @nkilmer I would love to get your thoughts on this proposed change for DBO. Happy to discuss further. Thanks!

[nkilmer]

Hi Pranay,

A few questions about your proposal:

The name would be derived by extracting and standardizing the first portion of the existing description field.

This is making certain assumptions about the description field that I don't believe are guaranteed by DBO standards. Would it be accurate to say that your intent is for this name to be the expansion of the type acronym?

The goal is to improve machine-readability and simplify parsing of general-type names.

Can you give an example of how you would use this feature? Are you already parsing type names in a more complex / less robust way?

My general opinion is that it would be nice to be clearer about the names of these types so that users who are less familiar with particular domains don't have to look up each acronym externally. However, as you noted, the description usually does expand the type acronym already. The addition of this feature also requires documentation updates and validator changes, so I want to understand its concrete benefits.

[pranay2811]

Hi Nigel,

Thank you for the feedback. Let me clarify the points you raised:

Would it be accurate to say that your intent is for this name to be the expansion of the type acronym?

Yes, that’s correct. The intent of the name field is to serve as the expanded form of the general type acronym (e.g., “Variable Air Volume” for VAV, “Fan Coil Unit” for FCU). This ensures consistency and avoids relying on the description field.

Can you give an example of how you would use this feature? Are you already parsing type names in a more complex / less robust way?

We have mapped the long-form names from the first portion of the description field. This approach is inconsistent since it assumes a uniform description structure. Moving to an explicit name field guarantees a clean and reliable source, which can be parsed automatically. We are using the long form names across our platform. As you have seen in our demos, we also surface them in our UI since acronyms alone aren’t always clear to end-users.

Documentation/validator changes and concrete benefits

We recognize this adds some maintenance overhead. The benefit will be clear separation of attributes:

• name: consistent & reliable source of long form names
• description: explanatory text about the type’s purpose/role