IFC for content

I got myself into an interesting twitter discussion last friday regarding the use of IFC. It started out as a complaint from someone stating "why does one format (presumably Revit) get native content, whilst I have to deal with IFC (in Archicad). It evolved in a debate about whether there is something as a single-format-solution for all BIM software. And should we be able to all work together on a single IFC model, all being able to alter it.

Unfortunately as more and more people got into the debate, you end up having to send two tweets just to get one proper sentence out. So I figured I'd compose some thoughts here. Let's start with the first part, IFC for content. The part about a single IFC model will have to wait until later this week.

IFC for content

IFC was never intended for "dynamic" use. It is a format to hand information to someone else down the line. It was not meant for weekly exchange between design partners. That can be done, but is a stretch and needs further development.
What it certainly is NOT meant for, and imho is very very bad for, is creating content libraries. Allow me to give you a few reasons why it's a bad idea:

#1: IFC is meant for projects.

Here's a challenge: show me an IFC-file that is not formatted as a project. Because the assumption when creating an IFC from any vendor software is that you are creating a project. Not a piece of content. Off course, you can bypass this. And it's just a minor glitch. But it should be taken as a sign: it's not suitable.

Check the content in the UK National BIM Library. It's all formatted as a project... Which means the user will need to do some work (or the software) to get this imported as an object. Or it will just not work as expected...

#2: Object definition

The definition of an object in IFC can be done in several ways. There's ways that give you nice and crispy clean IFC's. There's also ways that give you a 3000 line of code to define a single water closet. Check the UK National BIM Library, go to the toilet section, download an IFC called "Concealed cistern" and open in Notepad. It has 2640 lines of code to describe a freaking cistern.

It would be too easy to call that a stinkin' pile of crap... Point is: this is modelled in some vendor software and exported. You don't have anything to say on how it's exported. The vendor software just does what needs to be done... Without any way of controlling this (unless you code a custom exporter).

But seriously? Stuff 300 of these in your project and let me see you twirl your model around...

#3: IFC Dialects

We all have different software. With different ways of defining components. With different source code and kernels. There is no way in hell there is going to be a one-size-fits-all content library. It won't work. That's the same as saying "I got tires that will suit a Mini, a Jaguar, a Land Rover and a tank. I guarantee equal performance on all". Not going to happen.

Also because a tank doesn't need tires...

Like I said, not going to work. The needs and desires from a piece of library content are just too different. What works for one software creates a mess in the other. Why is it that Archicad has different export settings for Tekla and Revit? Because they both interpret IFC differently. All three speak IFC dialects. IF you were to create an IFC object library, you would have to have several IFC dialects to make it work. Which is insane, cause then you could just as well simply create native stuff.

Enough with the freaking libraries!

Get it into your heads people: common content libraries are a thing of the past. It's thinking CAD in a BIM world. It's like wanting to invest heavily in a telephone landline infrastructure in Africa, while people there are standing around texting each other on their mobile about what those crazy foreigners are doing.
We once needed those because they were a graphical interpretation of object specifications. Back in the day when we didn't virtualize the entire building but only did a graphical interpretation of it in a bunch of 2D drawings.

The misconception about needing libraries is that we need something different from what manufacturers already have. I don't want a manufacturers library! I want them to give me the data they already have from their manufacturing or sales processes in a structured, uniform way. Every manufacturer with an automated production line has every piece on information we need to fully automate object creation.

Geometric data? They have machines actually making that stuff! Any pipe, desk, air handling unit, sink, window or steel beam that is created in an automated assembly line is fully digitized. Or do you imagine them turning on the machines in the monring just waiting to see what happens? It HAS to be specced, or they won't be any product at the end of the line!
So just give me the data you use there, and I can ask a software engineer to write me a nice little addon that takes that data and automatically creates the families I need.

Performance data? How do you choose which door you want to use? You go online, Google, look at websites and pick a door. Not just any door, but the door that meets your specifications. How did that info get on that website? Someone from the manufacturer put it there. If they're smart, they have this big database that's hooked into their internal Product Management System, and a selection menu on their website. You know, one that let's you specify if it's an interior or exterior door, fire rating, what kind of operation, and so on. When you checked the boxes, there's a list of possible doors. With a link to a downloadsite so I can get a component for my project.

Here's a suggestion: do that inside my software. Create an internet database with all geometric and performance data. Hell, let an organisation such as the NBS in the UK govern it and add as many manufaturers as possible. Build a plugin for my software that connects to it and give me that selection tree inside my software. Then let me use that database to create objects as I need them. Do you have new products? Add them to the database and send me an email. 

And we're all done. For a fraction of a tiny bit of a small percentage of the costs it would take you to get a global, all-encompassing library of manufacturers products. The manufacturer doesn't need to keep a gazillion families up to date for several versions of multiple software platforms. I don't need to worry about stripping manufacturers content off useless garbage such as 2D representations and wrong linestyles, repathing parameters and object styles, and all that other stuff I do to get the content to look the way I want it and carry the information I need.

Too expensive? Not doable? Think again. I've seen a Dutch company that sells interior doors taking their "webshop", put the desired parameters in an Excel workbook and let the entire family be created from a Revit plugin that reads that database. As a user you just type in some specs and it will create the families needed. This is done by 1 guy without any previous experience with coding...
Agreed, it took him some time and he had help from an experienced programmer (who knew diddly squat about Revit or the Revit API) but it's there. With very limited resources. They are now working on expanding the addon to include more detail (locks and hinges, and so on). You know what the fun part is? They don't have to redo a whole library. Just add some code. They don't have to re-publish the whole library. Their users don't have to re-download the whole library. Just update the addin.

IMHO that's the way we should go: get some data-architects in a room, let them agree on a common output specification for manufacturers and let them develop some plugins for different software vendors that can read and translate this output specification using user-defined project and family templates.
Then, manufacturers only need to provide us with data instead of countless digital versions of their products . And we can re-use that to create content that is always up to date in our own native formats.