search

buildingSMART / NextGen-IFC

61 stars 4 forks source link

Deprecate IfcOwnerHistory #16

Open janbrouwer opened 4 years ago

janbrouwer commented 4 years ago

Most other file formats define things like "created by" in a header. I have never seen anyone use it for more than this purpose.

The history of a project (and who created what, when) seems like something that could better be stored in a CDE than something that must be part of every data exchange.

pipauwel commented 4 years ago

Fully in favor. I would even actively discourage the use of IfcOwnerHistory. Provenance of data should not be stored within a format that is used for data exchange. A CDE or any other internal management system needs to track this.

jwouellette commented 4 years ago

How about making it optional at the file header level for supporting (legacy) file-based workflows and deprecating it for class/object-based level, which can be handled by a CDE when we have transactional exchanges via JSON, etc?

jwouellette commented 4 years ago

Maybe this leads to rules of usage based on serialization type? And these rules are related to, but not ensconced in, the schema.

SergejMuhic commented 4 years ago

I have seen the opposite also. People requesting to exchange entire owner histories.

"Provenance of data should not be stored within a format that is used for data exchange." - I would agree with this. But does it not make sense in civil engineering projects to have the "data ownership" with time stamp somewhere in the IFC file at least (not necessarily on every object).

HerbertDobernig commented 4 years ago

IfcOwnerHistory provides support for transactions between CDE (“model server”) and applications.

See attributes “State” and “ChangeAction”:

https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2/HTML/schema/ifcutilityresource/lexical/ifcstateenum.html “… 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”

https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2/HTML/schema/ifcutilityresource/lexical/ifcchangeactionenum.htm “… 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.”

I propose to make use of this feature to support insert/delete/update transactions with interlocking between authoring-software and CDE.

HerbertDobernig commented 4 years ago

as well see discussion https://forums.buildingsmart.org/t/ifcownerhistory/2246

janbrouwer commented 4 years ago

In theory this sounds really good, but is there any system that trusts the changes done by another system without checking every parameter against it's own truth? And in the process creating it's own internal ownerhistory, not relying on the exchanged data?

Why exchange the entire model database with all these change actions? Is that a practical way to keep multiple model servers in sync?

Why not just let the owner of an object publish only his owned objects, without including objects owned by someone else in the same file. As is done in practice.

Revision history and permissions are better left to the CDE backend if you ask me. And communicated using HTTP PUT/PATCH/DELETE.

janbrouwer commented 4 years ago

What do we win:

What do we loose

Schema impact:

Instance model impact:

Backwards compatible:

Automatic migration possible:

HerbertDobernig commented 4 years ago

Answers to comments from @janbrouwer "... is there any system that trusts the changes done by another system without checking every parameter against it's own truth?"

Will systems in future provide ChangeAction information? Will systems in future trust the ChangeAction information that is provided by antoher system? Yes, if

  1. partial model exchange scenarios are well defined and standardized
  2. the support of this standardized partial model exchange scenarios is mandatory
  3. the proper handling of the attributes “State” and “ChangeAction” according to the standardized partial model exchange scenario is mandatory then receiving systems (CDEs, "model servers") can trust ChangeAction information.

"... checking every parameter against it's own truth?" This is very inefficient and only needed if there is no reliable ChangeAction information provided by the sending system.

"Why exchange the entire model database with all these change actions? Is that a practical way to keep multiple model servers in sync?"

To prolong the current practice of exchanging entire models is definitely NOT a good way for future. There is no need to send unchanged elements (ChangeAction=NOCHANGE) from authoring software back to the (decentralised) CDE.

It is sufficient to send elements from authoring software back to the (decentralised) CDE for

"Why not just let the owner of an object publish only his owned objects, without including objects owned by someone else in the same file. As is done in practice."

Yes, this is OK, it is current practice in BIM Level 2. For the future shift towards BIM Level 3 the "partial model exchange scenario" becomes relevant. The revitalization of the OwnerHistory attributes "ChangeAction" and "State" is very useful in this context. I find the denomination "OwnerHistory" somehow misleading in this context and stepped into this trap by myself. "OwnerHistroy" suggests that a whole audit trail will be maintained within an IFC file. Maintaining audit trails is definitely the task of CDEs ("model servers")

"Revision history and permissions are better left to the CDE backend if you ask me. YES, Maintaining audit trails is definitely the task of CDEs ("model servers") OwnerHistory with attributes "ChangeAction" and "State" is only for partial model exchange scenarios (CDE checkout -> authoring steps -> CDE checkin) during the lifetime of a transaction between authoring software and CDE. Support of

"And communicated using HTTP PUT/PATCH/DELETE."

Although alluring, I disagree because to rely on HTTP is in contrast to "Towards a technology independent IFC".

HerbertDobernig commented 4 years ago

What do we loose if we deprecate IfcOwnerHistory: Technology independent IFC support of partial model exchange scenarios (for BIM Level 3)

pipauwel commented 4 years ago

This question also came about in the W3C LBD Community Group, in the OPM discussion. Properties can be modelled there as Level 1, 2, and 3. Users can pick what they like depending on the use case.

As you can see, a huge amount of objectification happens as a result, especially if you want to track changes on attribute values AND properties (all properties would have to be modelled as many-to-many properties - destroys #12 efforts). I think that this is too much of an impact. This becomes even worse when people want to exchange the ChangeAction information on geometry data.

Including ownerHistory for tracking ownership and changes (above level three) makes sense in an internal system and a CDE system. It does not make sense in an exchange scenario. People do not want exchanges to include such extensive amount of ChangeAction information - they need the data.

So I think we need to remove IfcOwnerHistory from the schema, at least in its current form. Too high impact on the data model.

In a transactional scenario, would it not be possible to include change information in a separate header? So that the payload of the transaction is the IFC data; and the header of the transaction includes the change data? This may be a bit similar to BCF?

Note that I have not ever seen any IFC file so far including proper use of the IfcOwnerHistory entity, namely to track ownerhistory and changes of individual objects.

HerbertDobernig commented 4 years ago

I propose to postpone the decision on IfcOwnerHistory until we have a consensus how to handle the "partial model exchange scenario" between authoring software and CDE.

HerbertDobernig commented 4 years ago

@janbrouwer Thx for providing the reference to the OPM discussion.

For efficient change tracking ("audit trail") by L3-CDEs there is the need "to track changes on attribute values AND properties" (and relations) instead of storing subsequent model revisions as a whole like currently done in L2 CDEs. Hence, Unique Id's for properties and relationships are needed to store each change event to the L3-CDEs change log. Unfortunately, this seems to be in opposition to #12.

"... even worse when people want to exchange the ChangeAction information on geometry data." I agree that change tracking of geometry data has to be considered carefully. Geometric attributes can only be referenced indirectly by using the GUID of a referencing element as starting point and specifying the path down to the geometric attribute. If we remove Unique Id's from relationsships we create a similar problem. But this is again only relevant in preparation for L3 "partial model exchange scenarios". In current container-based L2 "full model exchange scenarios" this is not that relevant.

"Including ownerHistory for tracking ownership and changes (above level three) makes sense in an internal system and a CDE system." CDE systems will use other mechanisms to maintain their internal change logs to track ownership and changes. OwnerHistory against its unfavorable denotation is NOT for tracking ownership and change history. It only provides machanisms to ease the transactions between authoring software and CDEs in "partial model exchange scenarios", e.g.:

  1. Without IfcOwnerHistory.State the CDE is NOT able to tag some elements as "READONLY". If the consequently uninformed user modifies the elements his (unauthorized) modifications will be discarded by the CDE during checkin.

  2. With IfcOwnerHistory.State the CDE is able to tag some elements as "READONLY" thereby enabling the authoring-software to prevent modifications by the user on this elements immediately.

IfcOwnerHistory.ChangeAction is useful too. Without ChangeAction the authoring-software is not able to indicate the removal of an element in an "partial model exchange scenario". Even in an "full model exchange scenario" the attribute ChangeAction is useful: There is no need for the CDE to compare the whole model updated revision (coming from authoring software) against the CDEs baseline revision to identify the changed elements. Elements referencing IfcOwnerHistory.ChangeAction="NOCHANGE" may be skipped at checkin processing thereby considerably reducing the computational effort.

"People do not want exchanges to include such extensive amount of ChangeAction information - they need the data." I do not see extensive amount of ChangeAction information because we only exchange ChangeAction information for changes that have been done between last model checkout (from CDE to the authoring-software) and updated model checkin (from authoring-software to the CDE). There is only the need for a few instances of OwnerHistory

Should not be dificult to implement. I don't see impact on the data model.

"In a transactional scenario, would it not be possible to include change information in a separate header?" Yes, there are many different ways to handle the change information (e.g. we could transmit separate files containing the "READWRITE", "READONLY", "MODIFIED", ADDED", "DELETED",... parts of the model in the "partial model exchange scenario"). But we have an existing solution in IFC and I propose to awaken IfcOwnerHistory instead of inventing something new.

"Note that I have not ever seen any IFC file so far including proper use of the IfcOwnerHistory entity, namely to track ownerhistory and changes of individual objects." Me too, never seen such an IFC file. Perhaps this is the result of a common misunderstanding of IfcOwnerHistory as a full history log instead of a transaction support only.

pipauwel commented 4 years ago

@HerbertDobernig: can you post an example IFC snippet for, say, a door that gets added to a wall or something?

HerbertDobernig commented 4 years ago

From CDE to authoring-software (checkout):

101= IFCOWNERHISTORY(#22,#7,.READWRITE,$,$,$,$,1574162571);

102= IFCOWNERHISTORY(#22,#7,.READONLY,$,$,$,$,1574162571);

All elements referencing #101 are editable in authoring-software All elements referencing #102 are NOT editable in authoring-software (e.g. indicated by color or partial transparency)

HerbertDobernig commented 4 years ago

From authoring-software to CDE (at checkin):

101= IFCOWNERHISTORY(#22,#7,$,.MODIFIED,'2020-05-01','user1234','authSwXy',1574162571);

102= IFCOWNERHISTORY(#22,#7,$,.ADDED,$,$,$,1574162571);

103= IFCOWNERHISTORY(#22,#7,$,.DELETED,$,$,$,1574162571);

All elements referencing #101 have been modified in authoring-software since last checkout from CDE All elements referencing #102 have been added in authoring-software since last checkout from CDE All elements referencing #103 have been deleted in authoring-software since last checkout from CDE Unchanged elements are not transferred to CDE in a "partial model exchange scenario".

In "full model exchange scenario" (current L2 practice)

104= IFCOWNERHISTORY(#22,#7,$,.NOCHANGE,$,$,$,1574162571)

would be referenced by unchanged elements that are transferred to CDE for no tangible reason.

Moult commented 4 years ago

Is anybody aware of any implementation that supports parsing the IfcOwnerHistory? If nobody has implemented it yet, then I encourage deprecating it because the responsibility should lie with the CDE. No functionality lost, since nobody has built anything yet.

HerbertDobernig commented 4 years ago

@Moult: Tracking changes (maintaining history) is the responsibility of CDE. IfcOwnerHistory (misleading name) provides attributes to ease transactional exchange between CDE and authoring software as described above. If we deprecate IfcOwnerHistory, how will partial model exchange scenario be supported in an technology independent way? E.g. deletion of an element indicated by IfcChangeHistory.ChangeAction=DELETED

REST (GET, POST, PUT, DELETE) does not fulfill the requirement of technology independance.

Or we stick to füll model exchange scenarios where deletion of an element is indicated to the CDE by the absence of that element at checkin of the actual füll model.

Delete one wall in a hospital model and checkin the whole model with the absent wall to indicate the deletion of the wall to the CDE? Not really efficient because CDE needs to compare checkin model against checkout model to reconstruct changes for the change log.

Moult commented 4 years ago

The partial model exchange would be implemented by exchanging two files. One being the IFC data, and another being a diff, I think.

Moult commented 3 years ago

One point that wasn't discussed much was the legal requirements. For example, COBie links to people and organisations. If this is legally required, then if IfcOwnerHistory is removed, there should still be some way to associate people and organisations (council approval submission contact details, legal liability of design, building maintenance / product warranty contacts, etc).

NickNisbet commented 3 years ago

Can I speak up for IfcOwnerHistory? It is needed if

a. If IFC is a record. (We cant rely on the hosting container/application to do all the history for us - there may no be an owning container/application ) b. If IFC is to respect and receive updateograms c. If IFC is semantically linked to other (possibly conflicting) IFC data, either formally or via federation.

I'd suggest some enhancements instead

a. Give it a name, description and guid b. Make a rule that any IFC or updateogram (typically a UoF) must have at least one owner history.

Alternatives?

a. We give up on IFC having any long term role - as a single model, hub or federation. b. We include the IFC Process Domain in all Views so that we can document the design, construction and use transactions.

From: Dion Moult notifications@github.com Sent: 11 August 2020 23:42 To: buildingSMART/NextGen-IFC NextGen-IFC@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [buildingSMART/NextGen-IFC] Deprecate IfcOwnerHistory (#16)

One point that wasn't discussed much was the legal requirements. For example, COBie links to people and organisations. If this is legally required, then if IfcOwnerHistory is removed, there should still be some way to associate people and organisations (council approval submission contact details, legal liability of design, building maintenance / product warranty contacts, etc).

- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/buildingSMART/NextGen-IFC/issues/16#issuecomment-6723321 77 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYIIJMYK7H6E4GJHMMQOTTSA HCMRANCNFSM4LBSAN7Q . https://github.com/notifications/beacon/ABYIIJPK2I43NNX57PM73DLSAHCMRA5CNFS M4LBSAN72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFAJPTEI .gif

Moult commented 3 years ago

Just a bump that the BlenderBIM Add-on now supports owner histories, and this will be used for multi-user partial data exchange to an IFC server, as was the intention of the owner history. Therefore, until a solid alternative exists (i.e. a standardised agreement of how an exchange would take place), I now would recommend against deprecating ownership histories.