In the previous article “Secrets of IFC format”, I have mentioned the structure of relationships in the IFC schema. This structure reminds of a simplified family tree with parent and child items, which are related, and also… inherit attributes. How does it work? Where do these attributes come from? I will try to explain this in the following article.
1. Classes in IFC schema
In the IT world, each item/object may be described as the so-called class with specified attributes and the type of a given attribute. I have written about this in the previous article “Secrets of IFC format”:
“The attributes assigned to them (objects) are also important from the engineer's point of view (the door has a dimension, the material it is made of, its position in space). IFC describes each element as a class. It may seem a bit confusing, but in a nutshell, the idea is that each element has a list of attributes (name, material, position, dimensions) and the type of attribute value (text, number, coordinates, etc.).“
1.1 Classes as attribute template
How can we imagine this template as a class in the simplest way? For the door object, it would be as follows:
This type of object description gives us confidence that regardless of which program we will use to generate the IFC model, the object attributes will always be in the same format, therefore “Name” will always be a text, and “Height” will always be a number.
Filled template of the door object looks as follows:
The classes are not necessarily a physical object, such as a door (IfcDoor) or a wall (IfcWall). It may also be a task (IfcTask), described through the attributes, as presented below:
Again, we know for sure that describing the class through the attributes as well as the value type, the IsMilestone attribute will always be Yes/No attribute (not for instance maybe, almost, 0/1, etc.)
The IFC schema also has more abstract classes, such as “relationships”, which describe the way of connecting objects with the use of attributes.
For more information on “relationships” in the IFC scheme, see the following graphic:
2. Attribute inheritance
In the previous article, I have also noted that the IFC schema “(…) isn’t composed of a flat structure with separate
In this type of a tree, it is possible to indicate “parent” and “child”. And there are many features we can inherit from parents, such as eye color, hair, height, character…
It means that the attributes of the templates in the IFC schema may be transferred from “parent” to “child”.
Before I start discussing the schema, I will use the example from everyday life to explain how the attribute inheritance works.
Imagine that you have a vehicle with the features (attributes) such as:
- Weight (1500 kg)
- Color (black)
This vehicle may be a car with the attribute:
- Brand (Audi)
The car may be a station wagon version and it may feature the following attribute:
- Capacity (200 kg)
What does the inheriting of attributes mean in this case?
The station wagon has the capacity and inherited attributes such as “brand” – Audi, “color” – black, and “weight” – 1500 kg. The car’s attributes are: “brand” – Audi, “weight” – 1500 kg, as well as “color” – black. However, it does not feature “capacity”. Whereas the vehicle has “weight” and “color”, but it does not feature “capacity” or “brand”.
The inheritance of attributes in the IFC schema is similar.
Let’s have another look at the door template:
The inheritance of attributes in the IFC schema is similar.
Let’s have another look at the door template:
And now, let’s compare the above template with the similar one representing a slab (IfcSlab).
In both cases, the attributes are repeated both in the door and the slab template.
By analogy to the vehicle example, both templates have a master template – in the schema, it is IfcBuildingElement.
This template will contain all attributes of the door and the slab.
IfcBuildingObject
Thus, how is “inheritance” implemented in the IFC schema?
The attributes in the template are entered only once. If an attribute is repeated in a “child” template, it is omitted to avoid duplicating the same attribute.
Therefore, in line with the above principle, the door template (IfcDoor) looks more or less like this:
IfcDoor
In turn, this is the slab template (IfcSlab)
The graphic below presents this process in a more accessible way:
In general, the final result is as if we would write all these attributes again. Eliminating the whole string of words means that if we would like to change an attribute, we would only have to do it in one position. It is useful, isn’t it?
3. IFC Schema - Family tree
If you visit the buildingSmart website and look at the IFC schema specification https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/FINAL/HTML/, you may feel a bit confused seeing this IfcDoor class graph:
But if I present it in a simplified form as a family tree, the scheme seems more understandable and transparent and the line of relationships between “parent” and “child” is much clearer.
Summary
Now, you can see, those apparently different elements in the schema are similar. The two so different classes, like object (IfcObject) and process (IfcProcess), in fact, share many mutual inherited attributes.
Each class in the schema has the Globally Unique Identification (GUID), owner history, name, and description inherited from the IFCROOT template, which is superior to all template classes.
The use of standard, universal templates makes the information, that is passed on and used in the construction process, easier to control and more predictable (after all, the most important element in BIM is I – information). Especially, if we want to automate, improve, and accelerate the processes with the usage of computer software. The fact that attributes in the whole schema (family tree) are inherited means that we are sure that the attribute format for different classes will always be the same. It will not happen that the door height will be expressed as 120 cm, and the window height as one meter twenty.
Another example? Imagine that you are using the program to create door lists. The program groups them using the Type attribute (IfcObjectType) – e.g. Door Type1, Door Type2, etc. It is easy to notice now, that the same program will easily create a list of windows (IfcWindow) or walls (IfcWall), because their structure, as I have written above, is very similar thanks to universal templates and inheritance of attributes. I hope this article has brought you a little closer to the IFC schema, its universality, and a wide range of uses. What about you? How do you use IFC models? Share your experiences and thoughts.
Very useful! Thanks alot.