Abbreviations for building systems

[RitaLav]

Is there a way to introduce abbreviations for building systems in BDNS in order to be able to assign status for an overall system? Eg Underfloor Heating System Lighting Control System

Comments/feedback on whether abbreviating systems would be useful or not?

[blockchainaspirant]

Hello, Rita and future readers!

I agree entirely I believe this might be a useful feature in further building relationships within a building. I think that it would be good to be able to "group" assets under a system umbrella. Like having cameras/access control readers under a security umbrella (perhaps making it granular like security-accesscntrl_sys really depends here though).

I have been working on a glossary of terms, I might upload it here to explain further, but I think it's a conversation worth having.

Connor.

[jgunstone]

some thoughts - that probably don't quite fit neatly in this discussion but I'll go ahead anyway....

my understanding is that BDNS is for asset identification, not categorisation. It provides a simple way to refer to a specific thing. That thing could then be tagged with a category (product category, system category, ...) , to further indicate its use and function.

grouping products into product families

currently BDNS sudo implements grouping in an adhoc sort of way using the abbreviation_description - formalising this could certainly have benefit.

but caution! other categorisation systems exist (Uniclass probably being the most common/popular in the UK) for organising product families into groups, and as the README.md suggests, BDNS compliments other standards rather than replacing them.

my feeling is that BDNS would be best mapping to these categorisation systems rather than trying to implement its own. my preference would be for Uniclass, as to my knowledge this is the most complete and in-use in the UK.

to try and imagine an approach... add a Compliant Uniclass Pr Codes column or something similar. I think that 1 issue is that the mapping will probably not be one-to-one (i.e. 1 abbrevation could fit in multiple NBS Pr categories) so it would probably need to be a list ... or maybe 2 columns, where one is Uniclass Pr Code (best match) and the other is Other Compliant Uniclass Pr Codes(others that are also compliant). This would need some thought and consideration. see https://uniclass.thenbs.com/taxon/pr

grouping products into systems

in a construction project, products exist as a part of a building system. A given product can feasibly appear in many different types of system (e.g. PUMP could exist in a Ss_55_70_38 Hot and cold water supply systems or a Ss_60_40_37_48 Low-temperature hot water heating systems or many other system types... I think listing all the systems that I product could below to might be challenging.

in the same way that the abbreviations here are used to create a human readable reference to a specific product or product type in a project - one could imagine an analogous approach with systems. e.g. LTHW | Low Temperature Hot Water System

LTHW could be the abbreviation denoting a Low Temperature Hot Water System. its category would be Ss_60_40_37_48 Low-temperature hot water heating systems it could get a reference, e.g. LTHW-1, a specific system within the project. then PUMP-1 could have a metadata field Parent System or similar which would link it to LTHW-1.

I think for this approach, it would probably make sense to have a separate table for system abbrevations. ideally these abbreviations would be mapped to a categorisation system : https://uniclass.thenbs.com/taxon/ss

[RitaLav]

Further to today's discussion - it could potentially be addressed by having additional rows (eg adding the lighting control system as a row to the register). The use case being being able to attach a bit of data to a system in a more abstract way (eg points to a lighting control system overall, rather than a controller.

[jgunstone]

aha - that makes more sense - the system abbreviations would not be about grouping products, they would just be names that data-tags can be attached to. Perhaps it would be worth having an additional column called something like "Abbreviation Type" ... ? This could indicate if the data is attributed to a product or a system.

In the meeting we also talking about how some examples would be good for demonstrating expected use cases.

[RitaLav]

Meeting suggestion - open to feedback - @blockchainaspirant it would be interesting to hear your thoughts too:

• Add systems (eg lighting control system) as additional rows to the register
• Add a column named 'Abbreviation Type' that can have one of two values: 'equipment' or 'system' tag