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.
Non-issue.
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:
- â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
- this is hardly âa lot of effortâ in the grand scheme of things.
- 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.
- 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.
- 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.
- 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.
