Native IFC and asynchronous workflows

[brunopostle]

@theoryshaw suggested that it would be a good idea to bring this discussion here.

First, some background, you can skip if you have heard all this before:

The Bonsai BIM tool is a Native IFC application, ie. instead of working with an application-specific data model, Native IFC tools operate by editing and authoring IFC models directly - rather than relegating IFC to a reference or archiving role.

Specifically, in a Native IFC application such as Bonsai BIM or FreeCAD, the data is serialised in a consistent format - to the extent that an edited and saved IFC file will be identical to the original file (aside from just those entities that have been edited).

IFC-SPF is a line-oriented file format, so this lends itself nicely to storage in a version control system such as Git. We find that because files are only partially updated and that repositories are compressed, a Git repository recording a full history of hundreds of discrete changes can be smaller than the raw IFC file itself.

A unexpected development that was that a combination of this parsimonious approach to file handling, and a quirk of the SPF file format, gives us an asynchronous collaboration workflow practically for free - we can have multiple authors working on the same IFC model without requiring a continuous connection to a central database.

Twenty-first century software development is characterised by this kind of asynchronous working. The reason we use Git for software development is that two authors can make independent changes to the same file, 'forking' it, and then what is called a three-way-merge can resolve these changes into a single combined result - unifying the forked 'branches'.

We can do exactly the same thing with IFC, in fact in many ways the process is more robust because in an IFC-SPF file every entity is fully addressable due to the STEP-IDs (the #12434 numbering you see when you open one in a text editor). Three-way-merging software sourcecode can easily result in invalid and broken files, but we don't have that problem because IFC-SPF files are well-structured and this kind of corruption is hard to achieve. For a live demonstration of this in action, see this video presentation using Bonsai BIM (at the time called BlenderBIM), you can browse a copy of the IFC repository used in the demonstration here.

That was an overview of the situation, hopefully the links above give more comprehensive information.

IFC5 is text based, the JSON encoding and other features have lots of potential. Native IFC editing will clearly continue to work, and storage in version control systems such as Git will be fine. However it would be a major backwards step if this asynchronous collaboration isn't supported (and potentially improved-on).

IFC5 does away with STEP-IDs, the file format appears to be one big anonymous list, but one where the order of entities is significant.

Entities have a 'name' attribute which resembles the SPF GUID, but it isn't unique: the hello-wall sample has six entities with the name N93791d5d5beb437bb8ec2f1f0ba4bf3b. Does each of them override or add-to information on the previous entity with the same name?

How do we address these entities? This is important to be able to track changes. Do we have to refer to the 'fifth N93791d5d5beb437bb8ec2f1f0ba4bf3b entity? What if some software deletes the second? (but then the fifth entity is now the fourth).

Is this intended to be an append-only file format? I can see that this would have some benefits, as the entire history could be reconstructed by trimming later entities? Is multi-user collaboration intended by simply appending all changes from all sources, with the most recent arrival 'winning'?

[yorikvanhavre]

Where can we see the hello-wall example you are referring to, @brunopostle ?

[brunopostle]

It's here: hello-wall.ifcx.

[aothms]

I think an important aspect in this discussion is that IFC5 borrows the concepts of layers from USD. So there is less of a need to work around express's limitations on not supporting relationships outside of file boundaries. Asynchronously created models can remain independent layers and folded into the same 'stage' conflict-free by means of selecting the layer order, while still allowing rich relationships and data integration by means of the central tree.

Of course this is only one possible way of working.

Working towards a single layer by means of explicit conflict resolution for the entire stage is still possible, either line-based or more maybe more object-model based. I think the models proposed in this repo work really well for that because the model is guaranteed to be a flat list, so no arbitrarily deep diffs.

The duplicate names you see are specific 'components' that all are to be superimposed/composed to form the complete definition of that node ({'def': 'over'}). These are namespaced, so the pair (N93791d5d5beb437bb8ec2f1f0ba4bf3b, 'ifc:class') maybe could be unique. But whether that is something that would be enforced is not clear to me.

Is this intended to be an append-only file format?

It could indeed be like that. If you look at USD, they indeed don't have a deletion operation specifically, but with an active=False (or similar) flag they can 'remove' subtrees from the model. So indeed that is akin to something append only. But of course you could also remove data from the model if you 'own' the layer.

The basis in all of this is very flexible and allows for multiple ways of working.

Also see the basic viewer prototype that is online now: https://ifc5.technical.buildingsmart.org/viewer/