buildingSMART Forums

Annotation shouldn't be added back into the IFC spec

This post is prompted by a Twitter discussion about the removal of annotation features from the IFC spec.

Here are some reasons to not include annotation in an IFC model (or any other 3D model format for that matter).

I am defining annotation as anything that is not physically part of construction works. For example, text, dimensions, lines, symbols, hatches, and more.

1. Seperation of concerns

A model is intended to represent a building with its geometry and related properties.

Annotation is intended to communicate information about the model’s geometry and properties.

I believe tightly coupling the representation and communication is not a good idea.

2. Visual clutter

Traditionally, a simple wall would appear on many drawings with lots of different annotations depending on the drawing’s purpose.

If all that annotation was to be embedded into the same 3D model in the same place you would have loads of text and dimensions in 3D overlapping each other, it becomes a nightmare to filter out objects and see what you want to see.

3. Bloat

Embedding annotation would increase the size of IFC files requiring more storage space, better internet connections and more powerful graphics hardware to render the models. I believe we should be looking to make models more accessible for everyone by decreasing IT requirements.

It would also increase the size of the IFC spec when it is already so big that implementers are struggling.

4. Makes change management more difficult

If annotation was embedded within a model then everytime there was an annotation change the whole model would need to be reissued. Because the model is technically changing there’d be no guarantee that the design geometry or properties hadn’t inadvertently changed too. Therefore the whole model change management and checking process would need to be redone.

If annotation was held in a seperate file or system, we could reissue clarifying annotation without having to reissue models. We could guarantee the design model hadn’t changed, only some clarifying information added or modified. No clash checks or Solibri rule sets would have to be rerun.

5. Drawings are dying

While it always makes me feel very ungrateful and a bit of an ass to speak negatively about open source developments, I was disappointed to see the new Blender for IFC having put a lot of effort into features for “documentation” (i.e. drawings) at a time when we should be moving away from drawings.

I know of efforts by real world projects to go drawing-free by eliminating all (or as many as possible) drawings and have only the model as the contractual deliverable.

While it’s a bigger topic for another day, the industry is moving away from traditional static annotation, tools of the future will display dynamic information based on model properties depending on who is viewing the model.

I think it would be wasted effort and a distraction to put annotation back into the IFC spec when we should be thinking about how the next generation of projects will be delivered without annotation.

We should accept that over 90% of the industry “love” use “outdated things”

This is why some big software vendors still live in caves

Before dropping annotation, drop using “DWG” and some software like Autocad, drop Excel, drop PDF, drop …

However, you talk about a familiar issue but I don’t see you provide a solution

That needs a “dynamic and federated system”

We’re following an idea which is not a common usage in the industry, but we know what we want

Could you please post a link to the Twitter discussion? It might be insightful. I’d like to address your concerns first, followed by my opinion of how things should proceed:

1. Separation of Concerns

In software architecture, and indeed schema development, there are clear ways to define a separation of concerns as well as direction of dependencies (i.e. abstractions should not depend on concretions). So long as two criteria are met: 1. the annotation entities are separate entities to existing entities, and 2. annotation entities depend on existing entities, and no dependencies are introduced pointing the other way, then the SoC principle (and similar as developed by Robert Martin et al) is adhered to.

In short, this particular concern is invalid from a technical standpoint.

2. Visual clutter

This depends on the authoring tool. I’ve developed tools in Blender which effectively isolate and display annotation, and do not result in any visual clutter at all. One could equally argue that IFC’s multiple representation contexts issue could lead to visual clutter, but the fact is that they do not.


3. Bloat

Embedding annotation would increase the size of IFC files, if, and only if, vendors continue to export single monolithic IFC files. I have made repeated proposals to allow the linking of IFC files, which I believe solves this problem. Additionally, having worked with IFC files and other proprietary files (even in binary format), I continuously find that a BIM server for pure IFC files is a fraction of the storage, bandwidth, and requires less graphics hardware to render compared to those that have to handle proprietary ones like BIM360. Therefore, this is a non-issue.

Increasing the size of the IFC spec when it is already so big for implementers could be a concern, yes.

4. Make change management more difficult

As with any large repository of data, data transfers should be incremental and only deltas should be processed. Again, once you link multiple IFC files, this is a non-issue since only the annotation IFC needs to be reprocessed.

Already, in Blender, imports are only done on changes, and unit tests are only run on changed elements, leading to huge efficiencies.

Your argument is akin to saying that in a huge database warehouse for an enterprise, an additional table of useful data should not be added simply because it makes change management for difficult. For those with experience in running data warehouses, this is not a valid argument.

5. Drawings are dying

This is a rather controversial issue and more philosophical than a technical argument. In fact, out of your 5 points, this is the only point that could be said specifically for annotation. The first 4 are generic repeatable arguments that I could say about any IFC entity, such as the “IFC constraints / objective” entities. That said, I wish to stick to a few facts:

  1. “A lot of effort into features for documentation” roughly equated to about 3 days of me part-time poking around at code, half of which was me pondering the line thicknesses I liked the best :slight_smile: - this is hardly “a lot of effort” in the grand scheme of things.
  2. Yes, there are known initiatives to decrease drawing production. This is normal. However, statistically a large portion of the world still delivers drawings, and no-one would bet on it disappearing for the next five years at least, given the glacial pace of the world’s industries. After all, we have some firms still in pure CAD. This is 5 years of data which would be lost.
  3. Sometimes people forget that we are also archiving the past. An ISO standard data format to archive past drawings would allow us to rescue decades of real estate portfolio data.
  4. The “drawings are dying” statement is highly controversial for a reason: people take both sides. One must consider whether their actions preclude the other camp, and if there are solutions that allow both camps to operate.
  5. Nobody knows what a drawing-free future looks like. I am also parts of efforts and seen efforts to realise this, but the fact is that nobody knows yet exactly how a full pipe-line end-to-end building can be built without a single drawing. If we did know exactly what it looked like, then by all means, it should be incorporated as an ISO standard and annotation should be discarded in favour of it. But for the moment, we don’t. If you are able to point at a single large commercial project done without a single drawing, I (and others) would be very, very interested.

Personal stance

I don’t have any attachment to drawings, but I do see the fundamental need behind them. Drawings are produced for two reasons: 1. so others could see what the design is, and 2. as a guide to draw attention to portions of interest. The first is now obsolete with 3D BIM viewers, hence why many people think drawings are dying. However, I strongly believe that the second reason: a map to navigate, draw attention to, or see in sequence a series of important factors to consider when addressing a design still highly relevant and should not disappear.

This means that whereas drawings may reduce due to a reduced use-case, their use-case does not altogether disappear. The format of drawings may change shape - it may change from views on a paper-space sheet into locked 3D views in a virtual scene. I am not opposed to the “format” of a drawing changing.

For example, if the objective of a heritage design was that it looked a certain way from a certain angle, this is communicated not via the model itself, but a “meta-view” of the model. This is the function that is lost, but highly important. Similar analogies are raw data sets, and charts and data queries that help communicate insights from the raw data. The raw data is the BIM model, and the data queries are the annotation. Your proposal to remove the data queries is akin to asking scientists to publish raw data only, without their charts and graphs that analyse it in a human-meaningful way.

My personal proposal would be for some form of annotation support as a buildingSMART ISO standard. It may be part of the IFC schema, or it may be separate just as how BCFs are separate. Making them separate may make it easier for implementation and future deprecation. However, fundamentally, some form of annotation should exist.

Thoughts welcome. I hope my articulation has been clear.


"Could you please post a link to the Twitter discussion? "

I just did.

I personally find the ongoing lack of understanding of the meaning and FUNCTIONS of annotating (and DIMENSONING) very concerning. To be frank, the world of IFC is one of intellectual discussions and academic data science and to me we seem to have forgotten how data travels and becones solid steel and contrete from people at the side accurately making stuff often referred as Bim. Out of touch and complete different worlds we work in.

Why could annotations only be static? Why could 2d, doc and models not work together and is the majority so fixed on 3d with ‘hidden’ databases?

Just My $ for some more wood on this little fire :wink:

This idea should finally be retired, just like the idea that silent movies should remain silent, that movies should NOT have sound synchronized into them. That actually was an argument, made by none other than Jack Warner, the Jack Warner, of Warner Brothers, in 1926:
He was wrong and soon found out.

The "keep models and drawings separate" idea has dominated the last 20 years. But it’s game over now. The right answer, FUSION, is proven by Revizto definitively:

AU Revizto McCarthy presentation 2019

  • notice at 18:21 and
  • 1:19:12 through 1:20:53
  • along with the entire presentation

It’s a tidal wave. 2019 proved that drawing-model fusion IS a killer app, and is already very widely used in the industry in construction. Uptake is no longer in doubt, and now drawing-model fusion will just expand, everywhere. Tipping point has been reached.

Earlier fusion work:

Future fusion evolution:

Reports of drawing’s death are greatly exaggerated. Drawing is as compelling as ever, and as (or more) needed than ever. And the need is permanent. Drawing is one of two poles, the interplay between which IS thinking itself. The poles are:
[wide and narrow]
[environment and focus]
[peripheral and concentrating]
[model and “drawing”]

Drawing is: a highly evolved and effective technique for looking at, and helping you understand, both mental models and digital models.

  • drawing’s traditional form: drawing on media separated from models, with fusion (of drawings into models) carried out as a mental process only. Note that it is this fusion process, this interplay, this back and forth between model and drawing that literally IS thinking. In the interplay, thinking happens, understanding grows. Understanding of both, model and drawing.

  • drawing’s new form: drawing not only in a separated medium, but instead: drawing as an act of articulating a closer look in-situ within the space of digital models, such that understanding is better facilitated, by a more communicative and expressive digital medium, a more energetic and able companion to thought and understanding.

Drawing-model fusion gives immediate return on investment right now already in AEC. It also points ahead at further compelling innovation in digital media, as well as a renaissance (not death) of drawing.

Drawing is on the verge, now, of decades of forthcoming evolution in its form and expression. Now that drawing resides in-situ within digital models, it will EVOLVE.

Drawing’s role will remain valid for a very long time: for as long as human (or machine) thinking continues to function in approximately the way that actually-existing thinking functions (interplay between wide and narrow poles). Drawing’s evolution is inevitable.

1 Like

My 2¢ too:
It shouldn’t be the role of the format specification theoricians to tell people what they should or shouldn’t do. Some want to put annotations in an IFC file (I do)? Why should the format prohibit it? It doesn’t mean everybody is forced to do so. That’s maybe a good reason to have MVDs… One can choose to prohibit it in their case, others can allow it if they need…


Dear Yorik,

I think always in history they were few people who were said what is good and what’s not?
If some people don’t think out of the box and don’t force others to move ahead improvement won’t happen

All big changes in history, including Industrial Revolution, happened through “few” people who were “radical” and had their own “utopias”

I agree with you too, should people have their own freedom too and should provide solutions for both categories, people who want new things and people who want common things

While it is true that good things happen when people think out fo the box. The problem here is that there is no evidence that advocating for the demise of drawing and its replacement by modeling fits into that category. There is counter evidence that the idea is unfounded, and is directly counterproductive to thought.

1 Like

It has absolutely nothing to do with old versus new.

The short Twitter discussion in question:

Okay, I wasn’t very clear with this point. I completely agree from a technical point of view it isn’t a concern. It’s more that the whole of the IFC spec is about data for construction and facilities management projects, but arguably annotation isn’t really “data” in the same way that the rest of the schema is. I know that people who feel strongly about the importance of annotation may disagree with this.

To be fair, I’ve seen very few tools implement multiple representation contexts. I feel that the simplest model viewer should be able to open a model and all you see is the model.

I accept your point about file sizes. (and yes, monolithic IFCs are terrible!). But spec size is a definite worry.

I think we agree then that annotation should be seperate, but linked. My thoughts are that annotation shouldn’t directly be in IFC.

While not end to end yet, Hinkley Point C (winners of this year’s BSi large project award) in the UK is one of the largest construction projects in Europe and they’ve done trials to start doing well over £1bn of highly complex, nuclear grade, civil engineering work drawing-free.

And there’s a bridge project in Norway that is starting to do reinforcement installation drawing free:

Okay, while I stand by the point that in the future annotation won’t be needed as the tools for inquiring models improves, maybe that is too long term and unrealistic for the majority within the next few years or so.

I agree it should be standardised but, I don’t think that the IFC spec is the right the place for that for the reasons I’ve already mentioned.

I purposefully didn’t propose any solutions because its better to talk about the problem first, but yes, the short term solution is to absolutely use viewpoints (meta drawings) with annotation. Trimble Connect has probably the best implementation of this concept, have a look at it’s View API:

Technically, BCF already has viewpoint support and would just need to expand the type of markups that it can support from just lines to detailed dims and text.

Thank you for the detailed reply Moult, its given me lots of food for thought.

1 Like

Taking one of the example projects, the Norway bridge. I ask, if the bridge was designed and constructed “drawing-free”, then let’s ask, at some given point in time, given the need to see and show something specific at some specific region of the model, and discuss it among various people, who are then in contemplation of some set of issues, and may wish to record some of their remarks about the situation, how was that done?

There is no doubt that what was done is that some region in the model is designated and becomes the target of focused attention, discussion, and graphical interaction. And that, which no doubt happened, is the function of “drawing”. That’s what drawing is, functionally.

Therefore such a project is not done “drawing-free”. It’s done rather, through an evolution of drawing, an evolution of drawing’s form and expression, which begins after the prerequisite: drawing is instantiated in-situ within digital models.

Handicapping this evolution by stripping away the needed capabilities and material for evolution, will accomplish nothing but the opposite of the stated goal of “moving away from drawings”. Rather, disabling this evolution just ensures stasis, continued heavy reliance on drawing in its traditional form.

Unfortunately, you want we think out of the box, but you mention some outdated ideas

And all those bSI winners have the same conditions too, because all of them have worked based on what they have in hand, not what they should have

IFC today is infant,

so anytime bSI improved IFD/IFC,
anytime developed a good IfcDoc (and/or a good IDM/MVD toolkit) based on SysML/UML,
and anytime decoupled IFD/IFC schema and its file format (federation),

then we will do our bests

1 Like

interesting background here that should be revisited That was 5 years ago. Today, the idea that paperspace is to be kept always separate from modelspace is obsolete. Their mutual infusion, the display of “paper space” in-situ within modelspace, today is widespread and highly valued. The former enforced separation is now dismantled. Sticking to the idea of enforced separation is archaic. There is too much value in their mutual contextualization. Digital media reflects the innate conditions of thinking itself, now: interrelation/fusion. Revizto’s uptake in the industry is commercial “proof” that fusion is the way forward.


“Paper-free” could be a real goal. “Drawing-free” is bad practice and a race to the bottom. Models and that thing called bim cannot exist without explicit 2d dimensions and annotations (first). Who even comes with this goal, i don’t see that as someone that takes his or hers role as professional engineer or programming wise. It is marketing and management talk want to sell things. Either it is software or (Bim) consultancy

@rob Autocad in the early days was already foynede on the paperspace and modelspace combination. Too bad the initial founders made a big mess out of it, did not use Fushion and lost track altogether in numerous other software to stick it all together. But the concept are all there in dwg as well. Just someone needs to pick it and make lots of money pulling this to 'bim" or IFC. Making rhese thing work better together is a matter of time and some leader mentality. I have one word for you. ODA!