IfcOwnerHistory

@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:

We both clearly know where is the challenge point

COBie and IFC mapping Developers - General

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)

What do you think about this?

I like what I see in “Advanced (Level 3)” and for sure the industry is following this when bSI is thinking to develop OpenCDE which is API-based

However, I think bSI is improving IFC to be suitable for ISO 19650 which CDE is an important part of it

But till now I haven’t seen any evidence about IfcOwnerHistory improvement inside the IFC schema

CDE at the end needs support IFC and ISO 19650

Even maybe there would be a need to improve “time-series” too, I’m not sure yet

Could you please explain what you mean with "… haven’t seen any deviance about IfcOwnerHistory improvement … " ?

Thanks, I mean evidence

In IDM Tookit project I saw a lot of good improvements which I think are good for the start and during the time bSI can improve it

But I don’t know is it an open source project or not? It would be part of IfcDoc or OpenCDE or not?

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 :slight_smile:

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.

Theory versus pratice. (?)

1 Like

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

Ok. Good luck

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

I don’t think this handle works properly in software. I personally do not like the idea of logging changes inside ifc
Ditch it.

The way people work with bcf files and manage these as changes would probably be a better starting point

1 Like

OK :slightly_smiling_face:

Personally don’t see BCF as an efficient way.

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

Where i can i personally try to avoid any of these abbreviations. It creates many confusion.

Bim
Level x
Industry x

These abbreviations don’t cause confusion

The majority of them and their goals are clear, but do you know, “change is painful, so normally many try to avoid”

However, all big changes has happened through small groups who knew what they wanted and weren’t following norms

I won’t follow technologies and methodologies that are based on 30-10 years ago

What “norm” is it that you don’t follow, and i do?

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

Nothing personal. Just trying to understand your plans and struggles with ifc