Thoughts about Git for IFC (2)

In my previous post I described why we would need a versioning system like Git for IFC. Now, let's focus a bit on what would be necessary for this to work.

Can't we just start using Git?

Git is all about versioning ASCII based files, and IFC files are ASCII based as well (both the STEP files as the XML files). So can't we just start using Git right away?

No.

Let me explain. In Git, whenever a file changes, the hash of the file changes. This results in a new "blob" being stored inside the Git database. So in essence, Git stores files completely no matter how small the change. However, the power of Git is in the fact that it can display changes between versions of files on the level of lines. 

Now, IFC's file scheme fails completely at this point. Let's have a look at 2 STEP lines:

#6= IFCCARTESIANPOINT((0.,0.,0.));
#80= IFCAXIS2PLACEMENT3D(#6,$,$);

What you see here is the definition of an IfcAxis2Placement3d. The definition is assigned to #80 points to an IfcCartesionPoint (#6). It's important to understand that the numbers starting to the # define the IFC graph (or entity network), and that is exactly what makes IFC so powerfull. So the line above actually shows is:

1. Two graph nodes (IFCCARTESIONPOINT and IFCAXIS2PLACEMENT3D)
2. A graph edge (#6, pointing from IFCAXIS2PLACEMENT3D to IFCCARTESIONPOINT)

IFC graph of a small example file

Now, the numbers starting with # are purely numbers that are defined within the scope it the IFC file. They have nothing to do with the bim-model data, nor do they have any relation to anything in the original source file the IFC was exported from. So, whenever something changes in a model, and the IFC is re-exported, these numbers could be completely different. #80 could than just as well be an IfcWall! This problem is present in the XML files as well.

So although tracking changes on line level is possible because the IFC files are ASCII bases, it's quite useless since differences between files could be almost 100%. 

And what about Git LFS?

There is an extension to Git which allows to track large files (LFS). But really, what's the point in version tracking whole models? You want to track changes on the element level right? 

Versioning separate entities: a necessity

Instead of looking for ways to version complete IFC files, we need to start looking for ways to version separate entities. This is an absolute necessity. Mainly because of the fact that we never know what the scope of and IFC file is (one storey or a full building?), but also because we need to be able version data changes on the smallest of entities, like properties.

IFC already provides some sort of versioning through the ChangeAction property on the IFCOWNERHISTORY entity. However, this particular property remains often unused, mainly because IFC exporters will simply export the model as-is. Often, BIM software itself doesn't even store model/entity versions, so there is nothing for the IFC exporter to export.

Furthermore, the IFCOWNERHISTORY only reflects changes on rooted items (entities which are descendants of IFCROOT). So single properties, or geometries are not included.

Where IFC fails

When it comes to versioning IFC data, IFC fails at the exact point where its strength is: the definition of it's data graph. It is important to understand that it is not the IFC schema that fails, but the way the data is written to IFC STEP or XML files. The problem lies in the fact that arbitrary integers are being used to define the graph edges, which are only defined within the scope of the file.

The main problem is that most data storage systems are hierarchical, while IFC's graph is not.

So in order to be able to start versioning IFC data, we need to redefine how the data is saved to disk. We need to:

• Define a pure mechanism for identifying all IFC entities.
• Define a pure mechanism for identifying the links (graph edges) between entities.

What's next?

In my next post, I'll present some thoughts on how to redefine how data is stored.