In the following screenshot, two IFC files are loaded into the same program. The first IFC file contains a lot of architectural elements, and the second IFC file contains a structural element (a single slab).
This is a very common scenario, where multiple IFC files are created by different disciplines, different roles, responsibilities, and timeframes, but all merge together to create a federated BIM model. The ability to split and combine files is vital and common in many other industries (software, CG, VFX), yet I get the impression that the BIM industry still tends to create a single, big, unwieldy 2GB IFC files 
We should expect them to provide a collection of neatly segmented IFC files that reference each other to build a federated BIM model. This allows you to apply version control much easier, implement model servers easier, and do analysis faster. If I modify a single wall, or just add a few properties (e.g. as part of a digital twin sensor output), I should not need to rewrite an entire 2GB IFC file. There could be hundreds of IFC files that create a building - some may contain as little as purely CRS definitions, some may just contain PSets related to a discipline, and others may contain geometry.
In the screenshot below, both project, site, building, and storey share the same GlobalId, and therefore a referring to the same element. However, you can see that the IfcProject.Name of the second IFC file is My identical project, which is different to the IfcProject.Name of the first IFC file, which is My project. In this scenario, which data should the BIM tool consider to be the master of truth?
I can think of a few approaches:
- Establish a convention where the master of truth IFC file defines the element in its entirety. Any IFC file which merely references the same element should have blank attributes (
$).
Here is an example of it:
building-structure.ifc - used to define spatial hierarchy:
...
#30=IFCPROJECT('0ovDN8c9v9xABetj5G4Toz',$,'My project',$,$,$,$,(#28),#19);
#193=IFCBUILDING('0tjzSZIM97xO19qEfAUfEt',#5,'My building',$,$,#192,$,$,$,$,$,$);
#195=IFCBUILDINGSTOREY('0GelCcLR9Cf9zvW$jhWkTS',#5,'Ground floor',$,$,#194,$,$,$,$);
#28=IFCGEOMETRICREPRESENTATIONCONTEXT('Foo','Model',3,1.E-05,#9,$);
surveyor.ifc - used by surveying discipline to define GIS CRS, inherits building-structure.ifc
...
#30=IFCPROJECT('0ovDN8c9v9xABetj5G4Toz',$,$,$,$,$,$,(#28),#19);
#28=IFCGEOMETRICREPRESENTATIONCONTEXT('Foo','Model',3,1.E-05,#9,$);
#34=IFCPROJECTEDCRS('EPSG:28356','Sydney','GDA94','AHD','MGA','56',#33);
#35=IFCMAPCONVERSION(#28,#34,334902.775,6252274.139,4.,0.,1.,0.98);
architectural.ifc - used by architectural discipline, inherits building-structure.ifc and inherits surveyor.ifc:
...
#30=IFCPROJECT('0ovDN8c9v9xABetj5G4Toz',$,$,$,$,$,$,$,$);
#5365=IFCBUILDING('0tjzSZIM97xO19qEfAUfEt',$,$,$,$,$,$,$,$,$,$,$);
#5367=IFCBUILDINGSTOREY('0GelCcLR9Cf9zvW$jhWkTS',$,$,$,$,$,$,$,$,$);
- Put owner history to good use and somehow use it to determine who is the most recent owner and have that be considered the master of truth.
- Create a mechanism where IFC files can actually reference each other, like
#123=IFCREFERENCE('0ovDN8c9v9xABetj5G4Toz', 'relative/path/to/foo.ifc')rather than matchingGlobalIds.
Ideas? How do you split and merge your IFC files?