IFC for the Layman – Part 2: Exploring the family tree

This post I’m going to go into more detail about how the Industry Foundation Classes (i.e. templates of things in construction and facilities management: see IFC for the Layman Part 1) are built up. They aren’t, as you may think, a long flat list of separate templates but rather a big connected family tree of parent and child templates.

Bare in mind that throughout this post we’re only referring to how the templates themselves are organised, we’re not going to talk about how they’re filled in or how filled in templates relate to each other to build up a description of an actual construction or facilities management project. That’s coming up in Part 3.

Inheritance

From our parents we can inherit all sorts of things from genetics to, if we’re lucky, money. IFC templates can be parents as well that pass information to their children (just don’t ask how IfcBabies are made…).

Say we had a Door template and a Roof template like below:

Door template

Attribute	Value Type
Name	Text
Description	Text
Tag	Text
Shape	Shape
Overall Height	Number
Overall Width	Number

Roof Template

Attribute	Value Type
Name	Text
Description	Text
Tag	Text
Shape	Shape
Roof Shape	Flat, Pitched

You can see that a lot of the attributes appear in both, wouldn’t it be easier if we only had to describe the duplicate attributes once? Well, we could create a parent template called Building Element that contains all the attributes that both the Roof and Door templates have and in each of them make a note that they both also have all the attributes of a Building Element, this is shown below.

Building Element

Attribute	Value Type
Name	Text
Description	Text
Tag	Text
Shape	Shape

Door [parent: Building Element]

Attribute	Value Type
Overall Height	Number
Overall Width	Number

Roof [parent: Building Element]

Attribute	Value Type
Roof Shape	Flat, Pitched

In practical terms the end result is essentially the same as if we’d written them all again, but we’ve eliminated a whole bunch of text and if we needed to make a change to an attribute we would only have to do so in one place.

IFC makes extensive use of this idea and the entire IFC family tree is large with many branches that would take too long to fully explain in a single blog post, but by taking a look at a single path from the top to the bottom we’ll get a good insight into how it is made.

Lets get stuck in and find out exactly how a Door template comes to be, which has the following family tree: Root > Object Definition > Object > Product > Element > Building Element > Door 

Phew, that’s a lot of steps with some strange names but we’ll be taking a quick journey from the highly theoretical to the pleasing solid, via some perhaps confusingly conceptual stops along the way all in plain and simple language.

[For the geeky, I’m using the IFC2x3 spec just because it’s currently the most common, the newer IFC versions follow the same ideas and aren’t radically different. All IFC class names actually start with “Ifc” and there are no spaces in class and attribute names but I’m trying to make things as clear and legible as possible]

Root [abstract]

Ignoring the helper templates for now, at the top of the main IFC templates (i.e. classes) family tree there is Root.

I said Root, not Groot

Root is the biblical Adam template from which all the other main templates come from. Or maybe the Genghis Kahn of IFC land that spreads its attributes far and wide. The great great great grandparent. Basically this is the main template from which all the others come from.

Attributes

Root has 4 attributes:

Attribute	Value Type
Global ID	GUID
Owner History	OwnerHistory
Name	Text (optional)
Description	Text (optional)

Global ID

I’ve put this has a value type of GUID which stands for Globally Unique IDentifier. A GUID is literally just a bunch of random letters and numbers created by software that is SO random it should be completely unique and once created should never be modified. The Global ID attribute can be used to track a thing even when all other attributes have changed.

Owner History

This attribute can record who created this particular thing and when it was created. In practise IFC exporters often just assign every thing to the person exporting it so we aren’t going to worry too much about Owner History, but it’s useful to remember that such an attribute exists.

Name and Description

First thing to notice with these two attributes is that we’re introducing the idea that an attribute can be optional. It’s completely up to the user whether these attributes are filled in or not.

The Name could be something recognizable to the reader like “Roof Chiller North 1” and the Description could give further information “The chiller serving the North areas 1 and 2”.

Abstract

This special word doesn’t mean you should paint your walls and doors in a Pablo Picasso style.

Not a typical example of a ‘concept design’

All abstract means is that you’re not allowed to actually fill in this template. This might make it sound a bit pointless but an abstract template’s existence is purely for other templates to get attributes from it. This makes more sense the more we explore the tree.

Children

The Root template has 3 child templates:

• Object Definition
• Relationship Definition
• Property

I’ll be covering Relationship Definition and Property in more depth at a later date so lets just take a deeper look at Object Definition for now.

Object Definition [abstract]

In this context object doesn’t mean a physical object, but any thing that can be on its own.

An object can be all on it’s own, like me during my childhood

That’s a bit confusing so for this to make more sense I’ll compare this to the other children of Root. A relationship (or link) between things needs those things to exist to describe it. We can have a relationship between a wall and the door that goes in it. A wall can be on its own without a door and a door doesn’t necessarily need a wall (see: Monsters Inc) but without either of them a relationship between them simply wouldn’t exist. How could you describe a relationship between nothingness?

The same goes with a Property. A value of 250mm or 60 minutes makes no sense on its own without referencing something else.

A relationship or property can’t be meaningfully described on their own.

Walls, types of pipes, tasks, processes, even systems can actually be described pretty well without having to reference anything else so they will all inherit attributes from Object Definition.

Attributes

Object Definition has 4 attributes.

Attribute	Value Type
Is Decomposed By	Inverse
Decompose	Inverse
Has Assignments	Inverse
Has Associations	Inverse

You’ll no doubt have seen yet another new and strange word in addition to abstract, I’m now lobbing inverse at you.

Attributes labelled as inverse are great for anyone getting bored of completing templates because they’re filled in automatically. How can this be??

Lets look at Is Decomposed By first to find out.

Is Decomposed By

As mentioned earlier we’ll look into relationships more another time, but the inverse Is Decomposed By attribute simply searches for all the relationships that describe how this thing is made up of other things. Like a wall may be made up of many studs and partitions or an electric panel board made up of many circuit breakers. You never need to fill in values for inverse attributes, software will run off and do all the searches to find the values for you.

Decomposes

Is the opposite of the above, it returns (if any) the thing that this thing makes up. For a stud or parition Decomposes would list the wall object itself.

Has Assignments

Looks up relationships that assign tasks, processes, labour, etc.

Has Associations

Looks for classifications (Uniclass2015, NBS, Omniclass) and documents (O&Ms, Warranties) that you could perhaps associate with a thing.

Children

Object Definition has 2 child templates:

• Type Object
• Object

A Type Object is like a catalogue listing that describes a lot of information about something, but a catalogue listing only exists on paper, it’s not the real thing.

And you can’t beat the real thing (hint hint, I’m open to sponsorship…)

A Type Object is just a description. In many ways it is the same as AutoCAD blocks.

Object [abstract]

An Object is something that exists. Hurrah! We’re slowly making it closer to existence but, and it’s a big but, an object does not have to be physically something you can touch.

Attributes

Attribute	Value Type
Object Type	Text
Is Defined By	Inverse

Something special is happening now! Not only will we inherit attributes from Object‘s parent Object Definition, but also all the attributes from it’s grandparent Root! We’re beginning to save a lot of time by not rewriting attributes.

Object Type

This is where I have to apologize on behalf of IFC. We’ve just briefly talked about a template called Type Object (a “catalogue listing”) and now we have an attribute called Object Type, how very confusing! We’ll talk about this a little more at another time but for now you can think of it as an attribute that can store the objects general type. E.g. Scroll Chiller, Screw Chiller, Simultaneous Heating and Cooling Unit

Is Defined By

This is the attribute that has the relationship that links an Object (i.e. a thing that exists) to a Type Object. NOT the Object Type attribute, IFC would like to apologise for any confusion caused. It’s basically referring to it’s original catalogue listing.

Children

An Object has lots of children but fortunately they’re getting much more self explanatory.

• Actor: A template to describe individuals or organisations
• Control: The things used to control the works: standards, permits, requests, work orders, performance criteria
• Group: Things that represent groups of other things. E.g. inventories, building zones, M&E systems
• Process: Things that need doing. E.g. procedures and tasks
• Product: See below
• Project: The overall construction or facilities management project itself
• Resource: A thing used to build or operate a building doesn’t really get built itself. E.g. a spade, a crew of people, money, equipment

Product [abstract]

We’re not yet at the world of fully physical things but in IFC land Products are things that are at least related to the physical real world.

Attributes

Attribute	Value Type
Object Placement	Coordinate
Representations	Shapes
Referenced By	Inverse

Object Placement

This attribute describes where in the world the object is placed. The actual logic behind how this works can be a little complex but it can be thought of as 3D coordinates. (Remember coordinates from GCSE maths?? Bet you wish you paid more attention during Mr Whittaker’s double maths lessons now! I sure do…)

Representations

This attribute is all about shape. The shape of the product in 3D. If he did a course in Building Information Modelling instead of Artisitic Development perhaps Ed Sheeran would have sung “I’m in love with the IFC Representation of you”.

Singing to sell out crowds and winning grammies instead of efficently managing construction data, what a loser eh?!

Referenced By

This attribute is described in very general terms but can be used to link a Product template to any other template under Object.

Children

Product has 8 children:

• Annotation: Text, lines, and dimensions
• Element: See below
• Grid: A standard layout construction grid template
• Port: This represents a part of a product that can connect to a port on another product. Main example is a port on a piece of equipment can represent where water, gas, or electricity can come out of into a port on a pipe or cable.
• Proxy: If an item doesn’t match any of the existing templates, it can go here
• Structural Activity: This isn’t an activity that a person undertakes but an “activity” that the building does e.g. forces, displacement, and deformations
• Spatial Structural Element: Not actually to do with structural engineering, these are simply the different types of spaces and areas within a construction or facilities management project: e.g. a building site, a building, a building storey, or a room
• Structural Item: These aren’t actually the physical structural parts, they’re the theoretical bits and used in load calculations.

Element [abstract]

Hurrah! We’ve reached actual reality now. Elements are things that are purely and physically real. We can touch, feel, and see Elements.

Attributes

Element introduces a lot of new attributes but most are self explanatory or rarely used so to save on 1s and 0s I’m only going to go into more detail on a few of them. All except Tag are inverse (automatic) attributes so you shouldn’t have to worry too much about them anyway.

• Tag: Simply the traditional Tag ID / Mark code. For a radiator this could be R01 or for a door Z1-01-D01 or any format you want.
• Has Structural Member: Links a theoretical Structural Item (see Product children) with this Element
• Has Coverings: Links to cladding, insulation
• Has Projections: Used for 3D modelling complicated shapes
• Is Connection Realization: Links an Element to a connection such as to a bracket, hinge, or other fixing.
• And: Connected To, Connect From, Fills Voids, Referenced In Structures, Has Ports, Has Openings, Provides Boundaries, Contained In Structure

Children

Similar to attributes Element has lots of children but we’re getting to more familiar territory now so not much explanation is needed.

• Building Element: See below.
• Distribution Element: Building Services / M&E Distribution. E.g. pipes, cable trays, boilers
• Element Assembly: A grouping together of other parts. E.g. a reinforcement cage made up of multiple pieces of rebar.
• Element Component: Minor parts of a building. E.g. nuts, bolts, screws, fasteners
• Feature Element:  Used for 3D modelling complicated shapes
• Furnishing Element: E.g. furniture, sofas, tables, cupboards
• Transport Element: E.g. lifts, escalators, travelators
• Virtual Element: Imaginary boundaries between spaces. E.g. the boundaries between a kitchen, a work area, and a reception in an open plan office.

Building Element [abstract]

Attributes

Move along, nothing to see here. Building Element has zero additional properties, it’s really an organisational template to prevent it’s parent Element from having too many children.

Children

Building Element has only one attribute worth describing, the rest should require no more explanation to an audience of AEC professionals.

• Building Element Proxy: Similar to Object‘s child Proxy,  this is to be used if it’s definitely a Building Element but doesn’t fit anywhere else.
• And: Curtain Wall, Beam, Column, Covering, Door, Footing, Member, Pile, Plate, Railing, Ramp, Ramp Flight, Roof, Slab, Stair, Stair Flight, Wall, Window

Door

It’s been a wild ride but we’ve made it to our destination, the humble Door!

This is also the first one we’ve come across that is not abstract, therefore we can actually fill this one in.

Attributes

Attribute	Value Type
Overall Height	Number
Overall Width	Number

I’m not going to patronise you by explaining what these attributes mean.

Root is looking like a very distant ancestor now but we’re still inheriting ALL of their attributes and ALL the attributes of ALL the templates in between. You can see how powerful and efficient using this idea of attribute inheritance is.

---

There’s lots of templates (i.e. classes) that we’ve just skirted over here because we took just a single path through the IFC family tree and left many branches unexplored. There’s the many related to M&E, the different groupings possible, and relationships to name just a few that we haven’t looked at. No one blog post can cover every IFC template, there’s far too many for that.

In the last post I defined IFC as templates for things in construction and facilities management,  You can perhaps begin to appreciate just how comprehensive the list of templates that IFC has actually is, it has many capabilities that many people are not aware of. We have truly barely scratched the surface

How this family tree helps us

By using the idea that templates can pass down attributes to child templates, we can begin to see how similar seemingly separate things are. For example, we only mentioned the Control template in passing as a child of Object but straightaway we know it has a Global ID attribute, as well Owner History, Name, Description, and all the other attributes from Object Definition and Object. Door, Control, Structural Items, M&E Equipment, People, Spaces and more suddenly become very similar because they have these common attributes.

I’ve said previously that using standard templates with attributes and attribute types makes information much more predictable and much easier for a computer to use. Having a family tree “sharing” attributes between multiple templates improves this predictability even more because, for example, we can be certain that a Global ID for one thing is ALWAYS going to be in the same format as the Global ID of another thing. Because of this consistency between (often seemingly different) things, the same computer routines can be applied to many different areas and disciplines with only minimal tweaks. This in turn allows data in construction to start to be used at a massive scale in a simple and managable way.

For example, if you had a computer programme that created lists of Doors by reading the Tag attribute described in Element it would take very little extra work to make that also work for Walls, or Windows, or Stairs, or pieces of M&E equipment.

Or another example, say we had an app that linked pipes in a model to a pipe manufacturer’s ordering system by comparing Global IDs, it would not take much effort to instead compare Global IDs of cable trays, or boilers, or columns, or literally ANY thing that has Root as an ancestor. It also shouldn’t matter what software the IFC came from, freeing professionals to use the best tool for the job.

You can now see that having the IFC classes (i.e. templates) structured like this makes recording information and linking different parts of the industry together a much more simple task than it would otherwise first appear. Leading to a reduction in time consuming menial tasks and improving the quality of information that decision makers get. Both of which add towards the industry’s ultimate aim of increasing productivity.

---

Hope you enjoyed reading Part 2, Part 3 should be coming soon!