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
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â:
import IFC file to application (e.g. authoring software)
operate on model within application
Application gets modify permission state for each object from attribute âIfcStateâ
export changed model from application as new version of IFC file
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.
Intended workflow (Level 3):
NO checkout of an IFC file any more
NO import of IFC file to application (e.g. authoring software)
All applications operate on an IFC model by using open IFC API (basic model manipulation operations)
NO export
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).
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 âŠ
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?
@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
