how to map to other standards

[jgunstone]

over the past month we've been working with Building Smart to try and improve the way that BDNS maps to other standards like IFC, or BrickSchema.

currently every abbreviation maps to an IFC class, we are only really using IFC4.3 but as Alex Plenty pointed out in the call IFC2X3 is still probably the most common filetype in use in the industry right now. We would like to be able to map to IFC4.3 and IFC2x3, and also to other standards (e.g. BrickSchema) moving forward. Alex has progressed this work and we'd like to incorporate it into the BDNS. To do so we need to add some additional columns to the BDNS.

currently the column headings are as follows:

asset_description | asset_abbreviation | dbo_entity_type | ifc_class | ifc_type | can_be_connected

I think it is useful to think of "BDNS Core" column headings that define an Asset Type in BDNS, and "BDNS Mappings" which define how the map do other ontologies.

• asset_description CORE
• asset_abbreviation CORE
• can_be_connected CORE
• dbo_entity_type MAPPING
• ifc
  • ifc_class MAPPING
  • ifc_type MAPPING

After reviewing the BSDD IFC4.3 I have some thoughts and questions:

1. can we simplify the ifc_class and ifc_type columns into a single ifc_class column? this would simplify mapping as then 1no column is 1no mapping.
   1.1. on BSDD IFC4.3 all classes and class types are indicated as a single list. if we used this list exactly we could validate the IFC class exists before merging and automatically create links to the class definition
   1.1.1. there are not classes for USERDEFINED or NOTDEFINED types, so we could just use the class name in these cases.
   1.2. does the IfcTypeObject not refer to a specific obejct type within a model... therefore not relevant here?
2. The column heading ifc should be changed to indicate versions (i.e. ifc4.3 and ifc2x3 as Alex has already done).
   2.1. is there a need to support older versions? is yes can they have there own column?
3. We should add additional columns for other ontologies as required. e.g. brick for BrickSchema.
4. The simplest approach from a tidy data point of view would be to only allow 1no mapping per column. i.e. an abbreviation can only map to a single IFC class. If we need to map to multiple classes we could use a comma separated list in the column, I'll have a look at Alex's mark up to see how often this is required.

i.e. the column headings become:

• asset_description CORE
• asset_abbreviation CORE
• can_be_connected CORE
• dbo_entity_type MAPPING
• ifc4.3 MAPPING
• ifc2x3 MAPPING
• brick MAPPING
• etc.

side note.
we could consider defining the BDNS_Abbreviations_Register.csv as a Data Package for better interoperability.

[jgunstone]

done in mentioned PR