buildingSMART Forums


Hi all,

IfcOwnerHistory defines all history and identification related information. In order to provide fast access it is directly attached to all independent objects, relationships and properties.

IfcOwnerHistory is used to identify the creating and owning application and user for the associated object, as well as capture the last modifying application and user.

I think IfcOwnerHistory supports CreationDate as the start point of a time period, and LastModifiedDate as the end point, so what about changes happened between start and end?

Is there a way to support all changes? I know that it causes the size of the files increase until IFC supports federated feature, but I think it’s needed to record all changes

What do you think?

IFC does not support change history, and I see no big reason know time of unknown chages

The changes between start and end are tracked by CDE respectively “model server”.
IFC files represent only a snapshot at a certain point in time but not the whole history.

IfcOwnerHistory provides support for CDE/“model server” interaction with applications.
See attributes “State” and “ChangeAction”:
“… for partial model exchange and is intended for use primarily by a model server so that an application can identify the state of the object”
“… required in a partial model exchange scenario so that an application or model server will know how an object might have been affected by the previous application.”

Intended workflow (Level 2):

  1. checkout IFC file from CDE
  2. import IFC file to application (e.g. authoring software)
  3. operate on model within application
    Application gets modify permission state for each object from attribute “IfcState”
  4. export changed model from application as new version of IFC file
  5. checkin new version of IFC file to CDE
    CDE gets change information from attribute “IfcChangeAction”

Unfortunately the IfcOwnerHistory is not properly implemented in many applications.

@Moult: I expect blenderbim to have this feature implemented properly, isn’t it. :smile:

Intended workflow (Level 3):

  1. NO checkout of an IFC file any more
  2. NO import of IFC file to application (e.g. authoring software)
  3. All applications operate on an IFC model by using open IFC API (basic model manipulation operations)
  4. NO export
  5. NO checkin

Advantage of Level 3:
“Planning transactions” with interlocking of different authors (on building-level, storey-level, object-level, or attribute-level) possible (like database ACID features).

1 Like

@Herb and @igor.sokolov are correct

I am sorry to say that revision control is still not yet implemented in BlenderBIM. It does support actors and organisations, and it does support partial imports (but via a JSON diff, not based on the change action), but it does not support the revision abilities of IFC the way it seems to be capable of in the schema …

… yet :slight_smile:

It’s on the to-do list :slight_smile:

Thanks @igor.sokolov, @Herb and @Moult but you have forgotten a big part

Yes, CDE can have a mechanism to record changes and save them inside the CDE and just provide start and finish inside the .ifc file

Claim Management: But what if someday contractors have issues about design or implementation and go to the court? So, they have to provide change evidences from CDE? Then CDE should archive anything for years

I say what if you can archive all changes, including revisions, inside the ifc file?

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