@ReD_CoDE
Yes Ehsan, you address a very important aspect that is often neglected.
Often the concepts and discussions only consider
technical aspects
academic view
“good case”, “fair weather situation”, free from disputes
In reality each projekt party needs guaranteed access to a complete, consistent and indisputable documentation of facts (“audit-trail”) to be prepared for possible claims and court procedures.
Detailed documentation helps all parties in dispute to clarify legal position and legitimat claims. This avoids lengthy and expensive court proceedings with uncertain outcome.
As this is a general topic I would like to relocate from “IfcOwnerHistory” to a new topic:
Both IFC and COBie spreadsheet are not “static” and most of the times, COBie spreadsheet doesn’t use just as an archive (which the input data just comes from IFC file) For this reason “you have to have a mechanism to archive changes inside the spreadsheet” IFC has IfcOwnerHistory yes, but as you mentioned nobody uses it and even bSI is thinking to drop it. But I think it’s useful, especially after ISO 19650 which mainly focuses on legal aspects, so owner and owner history becomes important Al…
And I just want this challenge solves, it doesn’t matter who first finds issues
Hope all of us help together solve issues and improve IFC
Still some see IFC as second choice, and a “medium” solution/schema/file format and prefer their solution(s) be the first and IFC be the second, but I want IFC be the first choice
I aggree, that IFC should further develop from “second choice” being used for “reference view” only to “first choice” being used as schema for persistent (common) data storage.
I think that Level 3 could go that direction:
“All applications operate on an IFC model by using open IFC API (basic model manipulation operations)”
Then there is no need for native persistent data storage any more.
Level 2:
APP1 (native data storage 1) -> IFC -> CDE (IFC data storage) -> IFC -> APP2 (native data storage 2)
Level 3:
CDE <- API -> APP1 (NO persistent native data storage)
CDE <- API -> APP2 (NO persistent native data storage)
First, as an owner a change log is definitely of interest. But from my perspective, it is the responsibility of the building owner to keep his own change log. For this purpose, the last change coming with an IFC file is sufficient to log into the owners system. That way, the owner can easily maintain the changes important to him in his own system.
That being said, I care about my exchanges, so I would prefer not to get the entire log of changes in models into my system. Only the ones I care about. The changes I care about are in the specific exchange that I have specified in scenarios where I get data from designers, contractors etc.
I have something in mind that needs all change logs
But yes, we can implement these change logs out of IFC and just share the start and the last log
Imagine you design and after a while you realize that you did wrong and your client wanted you did it in another way. What you do? You have to start from where? Start point? What if you be able to come back to the point that you want and start from that point?
It will reduce times and costs when you have the ability to come back in change logs or go ahead
“Imagine you design and after a while you realize that you did wrong and your client wanted you did it in another way.”
It is fairly common, facing the outcome of formal written demands and finally seeing the result as 3d model. The visual model or even drawing is a form of communication. ‘Seeing it with other eyes’ from an other perspective…
Good thing it happens. No accident happend. Good. Only then it will start a new ‘deeper thinking’ proces. Let the ping pong proces of making things better begin
I would consider change log for administration purposes. Like putting up the bill of manhours or gibr management an overvoew. BUT NOT for making the design better or definite.
Going on my own experiences as a designer i will say that change logs are not the first thing people would use for chaning things back. It not a logical way. Eventhing is in their heads anyway.
And…‘There is NOT one bim-model’ so neither is there 'one bimmable ifc file" (which is perfectly in line with the writing of leon van berlo once wrote for bsi) And neither is the 1 moment for changing of thoughts with your client.
What i am trying to say is that probably one (done right:1) step will be gone back in the proces and the model adjustments will simple be ‘undone’ and changed. Design teams will be prepared for this to happen. Commen practice. No difficult CDE changelogfilecoldcasestudy required really. Not saying change logs certainly have a important function. But not in favor of completing a model in the right way (right being: this is how my client whises!)
For the design proces a change log would not be be part of the ifc. It will make 3d modelling unnecessary complex. And personally i find it not logical to put it in any form of 3d model. Not during operation phase either.
I think 2-3 people know what am I want and what am I going to build which is not as same as what’s happening in the projects today
If I spend my time in something, I want it be more advanced than what’s “general” in the industry
I tried give a simple example to show a small part of a “Design System” that is not following a linear process and has a more flexibility as well as “accurate” aspect
When you provide just “start” point and “end” point, and drop between, it means that you drop some data/information that “maybe” be useful or useless and who knows we should drop them or not?
I mean when IfcOwnerHistory just provides start and end maybe cause “DATA/INFORMATION LOSS”
I don’t prefer minimum and also maximum, instead I prefer just enough data/information and knowledge
I would consider change log for administration purposes. Like putting up the bill of manhours or gibr management an overvoew. BUT NOT for making the design better or definite.
@Hans_Lammerts You mentioned change log for administration purposes, so let’s accept this which is true.
So, do you think IfcOwnerHistory would be better to improve or not?
Also, I mentioned maybe in short term it causes complexity and increases in file size, but in the near future when bSI or some individuals implemented “federated” IFC, it won’t increase file size because you can divide an ifc file to many small but integrated parts. Fore instance, some ifc files that just hold change logs, some hold materials, some hold products, some hold projects, some hold sites, …
So, it seems that all of us agree about improving IfcOwnerHistory but see it with different views, for instance @sergej wants protect his change logs and share just preferred ones which is good
And I have the same view too, but see a CDE as an “integrated distributed system(s)” which is what we see in new generation of platforms and is one step ahead of ISO 19650
But I should show you what’s efficient, then all of us have to wait
Some years ago Arup developed BCF 2.0 and after a while some from Solibri and other companies with a little bit change released that as BCF 2.0 and today BCF 2.1
It’s odd to me when we talk about BIM Level 3 but still minds have focused on BIM Level 2
It’s odd to me when today we talk about Industry 4.0 when it seems that some even didn’t experience Industry 3.0
Personally I’m happy I’m in the built environment industry, because the industry’s weakness opens a lot of opportunities
I don’t talk about you Hans, please don’t see this personal
I just say we need new methodologies and technologies, and IFC improvements
And I think I shared enough about everything
About SysML/UML about Modelica and what am I want today? Which I think some bSI friends realized
There’s almost 3-4 years I follow “System of Systems” goal and I think today technology gives us enough power to build platforms that support many things that were separated before
It’s the time for combine, not integrate, GIS, BIM (BLM), PLM, …
So, IFC “can” be the main choice if has improvements and be update