I’ve recently got to wondering what workflows are afforded if, instead of storing an IFC file per project, asset, or trade, you stored one IFC file per IFC entity. I wrote what amounts to an “executable napkin sketch” to find out:
I’ve included the summary description from the README below. Curious to get this group’s thoughts on the general approach and prior art. Thanks! – Devon
IfcObjAsm is an experimental command-line utility for transforming IFCXML files into networks of small, hyperlinked documents. It does this exploding an IFCXML file into its constituent IFC entities, with one entity per file. Each entity file is named by its IFC GloballyUniqueId and placed in a common folder repository (named “objects”) on the local file system. IFCObjAsm then rewrites all references between IFC entities as references into this common repository. This approach has a few consequences:
Monolithic IFC(XML) files are transformed into networks of small, linked objects, represented as files.
Subsets of data can be extracted on demand by traversing the object graph. This affords a modular decomposition of IFC data and reduces demand on authoring environments. You only ever transact the subgraph of data you need.
Because IFC entities are stored as files, they can be managed directly by version control systems like git. This offers new patterns of open, distributed collaboration based on IFC.
By using standard XML linking technologies, stakeholders can create “views” into their object repositories organized by use case. Xincludes, for example, can be used to symlink IFC objects into arbitrary containers, classification structures, or folders. Because the XIncludes only ever reference object data, it’s possible to build up as many “views” onto the object repository as needed.
Composition of IFC data reduces to folder merging. Conflicts now occur at the level of individual IFC entities, not project files.