People that have followed me for a longer time know that up until a few years ago I would regularly post on forums and blogs. At some point, that just went away. Lack of time, working on subjects that really don’t turn into a blog so easily. But lately I have found myself wondering if I should take it up again. It’s always been fun to ponder on a subject, analyse it from all sides and then just write up what you find. Hopefully helping others with their own thoughts or even solving some issues for someone.
But when you, like me, are not a native English speaker, that does frequently associate with, work for or exchange knowledge with others from different countries, there’s always a struggle: am I going to write in Dutch, my native language, or English, the language of most of my peers, contacts and friends in the AEC business. As you might have guessed, I’m going with English for now. But might just as well switch to Dutch if it’s a local subject.
Anyway, after this lengthy “Hi, I’m back!”, let’s get into the subject that triggered me to finally flip open the good ol’ laptop and start typing away.
A few days ago, Tim Davies (@TimDaviesUK) posted a blog he wrote on Twitter. You can find the blog here. His Twitter post, and the equally interesting responses it sparked, can be found here. Amongst others, I encourage you to especially look at the extensive response written by Ian Keough (@ikeough). And the referral by IFC Overlord Jon Mirtschin (@geometrygym) to the buildingSMART International Forums where Ian made a new post to talk more about the subject. Even though I might not fully agree with a lot Tim is saying here (more on that later), I do want to commend Tim for putting out an honest and unbiased, thoroughly substantiated article. I really enjoyed reading it, and it triggered me to do some research of my own plus made me think about the way we use IFC in Bimforce and whether or not we share his experiences.
IFC schema size and complexity
So the central thesis in the analysis made by Tim is the question of whether or not IFC is (starting to get) bloated into a size and complexity that renders it unusable. To start with, Tim mentions that IFC currently has over 770 classes defined to describe a building. We can discuss the question on whether this is too much (I think buildings are complex and made out of a bunch of different components, so no, not necessarily). But more importantly: it’s not quite accurate. The IFC schema does hold over 770 classes, but they’re not all used to describe the actual building. There’s a lot of “overhead” in the schema, e.g. classes that are needed to describe the hierarchy tree (such as IfcElement). I know Tim also argues that the overall complexity of the schema is also an issue, but that constitutes to “double counting” imho.
Also, and more important, a lot of IfcClasses describe people or processes. Examples are IfcTask, IfcPerson, IfcWorkCalender, and so on. Valid stuff for the AEC, but NOT part of the building itself. So in the end, the actual amount of IfcClasses directly related to the description of a physical building is *just* 130 or so. Not saying that’s a little, but it’s hardly more then, for instance, Revit.
And how does that work the other way around? If you look at the Revit Categories available through the API, there’s 698 Revit Categories which, again, comes close to the number of IFC Classes. So in my humble opinion, it’s not really that bloated. I think the real issue here is User Experience: to the untrained eye there is no way of differentiating between Ifc Classes that are meant to describe building Components and Ifc Classes that describe the underlying structure.
Tim argues that all Property Sets should be removed from the schema, and placed in a different Standard, such as the buildingSMART Data Dictionary. I understand where he is coming from. And I would like to add that the current PSets are arbitrary, at best. Sometimes properties are implied. For instance: the PSet_PileCommon does not hold the IsExternal property, but does hold the LoadBearing property. Both of them are implied in the IfcClass since this describes a foundation pile but one is still a property whilst the other is not.
Besides that: they’re not remotely complete in defining all relevant properties for any given element. And frankly, I agree with Tim on this one when he says that the properties a certain component should have is a completely separate set of agreements. In other words: it doesn’t matter if you use the IFC schema, or Revit schema: in both instances you need a minimum set of properties to effectively describe the object. It shouldn’t be embedded in the IFC schema.
Remove the IFC prefix
Whilst I understand the issue Tim describes (it’s a needless extra 3 characters for every object), I think from a developers point of view the Prefix is important. It differentiates between IFC data and other data. If you remove it, you would have to add an attribute that describes where this piece of data is coming from.
This is less important when you work with IFC files (since the file itself can be defined as being built on the IFC schema, everything inside it automatically also is) but more important when you work with IFC-structured databases like we do at Bimforce.
Both our Content Management software VerteX and our Project Information Management software GRiDS are built upon the IFC schema. In VerteX we store object information using the IFC Project Library definitions, in the actual IFC schema. However, we also store Revit specific information, linked to the IFC schema that tells our Revit plugin how to effectively translate IFC data into the Revit format. For this to work, we need to know what the origin is of the data the software is trying to process. Quite simply put: our API queries the database to find an IFC definition (prefixed Ifc) and, assuming we’re generating Revit components, the accompanying translation for Revit (prefixed Rvt)
If we lose the Ifc prefix, we would either chose to re-implement it ourselves OR add a property to every node in our database and add the data source there. Simply because we need to be able to identify the object’s source. Simply because a definition for a Revit Wall is quite different from the definition of an IFC Wall. So yeah, if you *just* look at IFC, the prefix seems redundant. If you want to mix IFC data with data from other sources in a single database, the redundancy is not so obvious anymore.
Clean up the inheritance tree
Heavily disagree on this one. Even though the IFC inheritance tree is a HUGE pain in the ass, it is one of the most compelling parts of IFC for us as developers. Why is that? Well, let’s compare IFC with Revit on (one of many) usecase(s)…
The IFC inheritance tree does two things:
1. It connects (building) elements to each other that share a similar purpose or goal. If you want to look at the inheritance, check out this page. You will find that the inheritance tree is actually quite useful if you want to look at similar elements (e.g. find all Ifc Classes that represent an end-terminal in an MEP system).
2. It allows the use of shared attributes and properties. The inheritance tree allows you to say “ok, all physical elements need to have a name, description, and GUID. If you define these for the top element, as IFC does, all others derived from this top element also get these attributes. If you don’t do this, you will need to define name, description, and guid for each separate element.
Now, if you look at Revit, there is (almost) no inheritance. The Revit Categories are organized as a long list of definitions, (almost) all on the same level. This definitely makes the schema easier BUT it also prevents us from asking the schema the question “provide me with all components that have a similar usage as this one”.
If I wanted to know how many endpoints an electrical system has in my building, I can use the inheritance tree to define which type of objects I should look for. I start with selecting an IfcOutlet (an electrical power socket) and check the parent (which is IfcFlowTerminal) and the system the terminal belongs to. I can now query my database with the question:
“provide me with all objects that are part of System A, and are siblings of the selected object”.
In IFC, my algorithms could determine the selected object is an IfcOutlet, child of the IfcFlowTerminal. Moving up the inheritance tree to IfcFlowTerminal, we can then determine its siblings and return those. This automatically excludes cable trays, fittings, conversion devices, generators, and all other stuff that might be in the system but is not an actual endpoint.
If I wanted to do the same thing in a Revit based model, I can’t. Yes, I can query the Revit DB to provide me all components that are connected with System A. But I cannot find “relatives” to the Electrical Fixtures. So I would be able to find other power outlets, but not lighting devices, data Devices, and so on. I would have to provide the query with a list of all object types I want to search for, simply because the data schema does not allow me to intelligently query it.
In other words: the IFC inheritance tree, while being an utter nightmare to implement, is extremely useful once implemented when you use the right tools. So what are the right tools?
Tim refers to Microsoft documentation on how many levels of nesting should be used as a maximum. I’ve reviewed his source and I understand the issue discussed there. But I don’t quite feel that it’s a fair comparison. The source Tim refers to deals with nesting classes in source code, and IFC is a data schema. Having a highly nested data schema does not necessarily mean that you have to have equally complex source code.
Another issue Tim raised is with the large number of different relationships that exist in the schema. Again: whilst I understand the difficulties this imposes on the untrained person to actually understand the schema and be able to implement it, it would be devastating to the usefulness of IFC as a data structure to simply trim it down to a handful of relationship types.
At Bimforce we use nonSQL semantic databases. These allow us to travel through our database, explicitly using the relationship names. For instance, when we want to generate a Wall from our VerteX object database, we simply define the start point (IfcRoot) and endpoint (for the sake of argument let’s use IfcWall) and the allowed relationship types that can be used to describe a Wall. Our software then automatically follows the entire inheritance tree and composes the IFC Express definition based on every piece of data it encounters along the path.
So for us having just a handful of different relationships that are used arbitrarily would be a big issue. As I see it, this is more a problem of finding the right tools to do the job and not necessarily a problem related to the schema.
A single IfcPropertySet class
In the article, it’s suggested to use a single IfcPropertySet to list all properties. This confuses me a little because it contradicts the argument made about losing Property definitions all together. So which is it then?
I would rather lose all IfcPropertySet definitions and move those to the buildingSMART Data Dictionary. If that’s the case, we don’t need a single list either. If we’re not moving the Properties to bSDD, making a single list is a bad idea in my humble opinion. That would make assigning properties to a specific class completely arbitrary which would, in turn, lead to a lot of confusion.
Scrap the ISO10303 support
Tim argues that supporting IFC in the EXPRESS format is obsolete and should be replaced with just XML support. This, I don’t agree with. The assessment that the EXPRESS format is not widely supported is simply not true.
But even if we chose to ignore that (and why shouldn’t we?) there’s no reason to mandate the use of XML. Currently, one can choose the best implementation from a variety of languages. IFC definitions are available in EXPRESS, XML, JSON and TTL. I see no reason whatsoever to focus on a single language because different workflows work better with different languages.
I can’t stress enough that even though I don’t agree with some points in Tim’s post, I do think it’s a very valuable discussion to have and I appreciate and applaud any effort to start it up. However, my points of improvement would not focus on changing the IFC schema, but on making it more usable:
- Add a distinction between parts of the Schema that are valuable for the End User, and parts that are more on a system/developer level. That would cut down End User documentation with 70-80% thus making it more usable for everyday users.
- Could we all please stop with acting like this should be easy? It is not, and will never be, easy to digitally describe the complex reality of a complete building. Digitalization comes with a cost: it requires a different set of tools for people working with it. We, as an industry, need to start realizing that whilst we can take away the shovel and replace it with an excavator, this does imply you need a different set of skills to do your job. And that, even though you know how to operate that excavator, that might still mean that you have no knowledge of how the excavator itself works.
- Don’t get the previous point wrong. I was once told “Ifc isn’t for Dummies, Ifc is for real professionals” when I had the audacity to ask buildingSMART people if there was an IFC for Dummies out there. And that response really pissed me off. Cause I was trying to learn and all I got was a low blow. Luckily, that sort of thing usually just makes me bite down like a crocodile in a bad temper, but still. It’s not what I’m trying to say. There’s a lot to be improved in documentation, workflows, schema, basically anything and everything regarding implementation of IFC. People that want to get a better understanding should be guided, praised and cherished. We need them. But in my humble opinion one simply cannot expect every BIM modeller to grasp the IFC data schema and work with that. We should be focussing on creating tools that use IFC in such a way that people don’t even really see they’re using IFC.
- We should be looking at implementing IFC in different type of workflows. Regardless of discussing whether or not the EXPRESS format is the right one, what we should really be thinking about is whether FILES are the right way of storing that information. Filebased workflows fall short in many ways that are absolutely vital when looking at maintaining and operating a building:
- (IFC) Files do not store a history, do not support multiple “states of being”. Pretty annoying when you want to keep a digital building dossier.
- (IFC) Files cannot be accessed by multiple processes at once. And don’t bring the Google Docs example because that is not really a file. Also Worksharing / BIM360 does not count. You’re not really accessing the same file. You’re accessing multiple copies and keeping a list of things someone already touched.
- (IFC) Files cannot dynamically adopt their structure and way of presenting to the usecase. A BIM is set up in a way to best suit the modeller, like the architect or contractor. That setup is by definition not great for a building owner.
- (IFC) Files are an “all or nothing” type of workflow. You can’t just open the part you need, you’re stuck with tremendous overhead of information that is accidently in the same file as the stuff you need.
- (IFC) Files need a Tool. Whether it’s Revit, Archicad, Solibri, Navisworks, BIM360, or whatever tool you want to use: you have to use a Tool to get to your Data. They should be separate.
In the end, getting great IFC’s out of your authoring software is NOT the main goal. The main goal is getting your information into someone else’s workflow. With the littlest amount of hassle possible.