Owner History - functionality in scope

[timchipman]

IfcRoot.OwnerHistory provides several capabilities:

1. Merge partial models by indicating particular objects to be added, changed, or deleted. This allows checking in IFC/IFCXML files (either full or partial updates) to servers using simple HTTP POST without any special API, and retrieval of "DIFF"s between versions using the IFC format itself.
2. Restrict editing of particular objects by marking as read/write/read-only/hidden, and locked by a particular user and application
3. Informational attributes describing who/when created or last modified an object, and the application they used.

All of these seem critical in any editing workflow that makes use of coordinating changes from multiple users, though in practice many [most?] applications don't support this, and often provide placeholder values to conform to the schema but don't add anything useful, taking up 10+ superfluous entities in a file (IfcApplication, IfcPersonAndOrganization, etc.). General file-level information such as the user and application last modifying the file are provided in the header (either SPF or XML).

Here's a potential approach:

For Reference View, no owner history is provided at all, for any object (the relevant entities are not in the schema). The rationale here is that since the Reference View is not intended to be editable (containing mostly generated info but not the original parameters), then there would be no scenario of merging or locking objects, and the header would provide sufficient information to see who created the file using what application and when.

For Design Handover View, owner history may be indicated on any object or not at all, supporting all attributes for merging/locking/tracking. However, if it is provided, then the information should be meaningful and not just a placeholder. The rationale here is that since the Design Handover View is used for editing, then such capability may be needed, however supporting the notion that "no data is better than wrong data", the information should only be provided if it is real.

Comments?

[theoryshaw]

Yes, would agree that it could/should be left out of Reference View, but think it should be mandated for DHV.

In that case, it would seem that the following attributes _should not_ be 'optional' in the DHV.

• State : OPTIONAL IfcStateEnum;
• ChangeAction : OPTIONAL IfcChangeActionEnum;
• LastModifiedDate : OPTIONAL IfcTimeStamp;
• LastModifyingUser : OPTIONAL IfcPersonAndOrganization;
• LastModifyingApplication : OPTIONAL IfcApplication;

[AngelVelezSosa]

Using OwnerHistory is a powerful, but incomplete, tool. Since there is no reference to a previous model, how do you know what a "changed" item is referring to? Many applications don't keep track of entities once they are deleted (except perhaps temporarily in undo buffers). How do you specify that an entity has deleted as its owner history? If it is deleted, how do you specify it in the file? Does it have geometry? Does a deleted building storey have an elevaton?

It seems to me that if we want to use IfcOwnerHistory, even in the DHV, we'd need agreements on how vendors would set the right values.

[timchipman]

The reference to the previous "baseline" model may be specified using IfcLibraryInformation associated to the IfcProject using IfcRelAssociatesLibrary, where the Location attribute provides the URL of the baseline file, and the Version attribute identifies the specific version (which may be used with the HTTP ETag header to download particular version for servers where the URL alone isn't version-specific).

To know what a changed item refers to, IfcRoot.GlobalId identifies the object, and the specific change may be determined by comparing the object in the file with the same object in the baseline file (according to IfcRoot.GlobalId).

To specify that an entity has been deleted, set IfcRoot.OwnerHistory.ChangeAction = DELETED. The attribute values of a deleted object represent the state of the object at the time it was deleted (i.e. attributes may have changed since the baseline but before it was deleted). However, such attributes for deleted objects could be null or use placeholders (conforming to schema), as deleted objects could be graphically displayed according to the attributes of the baseline model.

If anything has changed on the object (direct or inverse attribute traversing object/collection graphs to non-IfcRoot instances), then the ChangeAction is set to MODIFIED. This flag provides an overall indicator of the change, and also serves as an optimization to skip comparing objects where no change has occurred. The specific modification(s) may be deduced by comparing the graph of object attributes on anything marked MODIFIED.

For newly created objects, ChangeAction=ADDED; for objects that haven't changed (either included as complete file, or referred to as a reference from some other object that changed), use ChangeAction=NOCHANGE (as opposed to NULL which means the change action is unknown).

Stepping back, as an overall goal of the CV is to improve information sharing between applications by capturing information that already exists, but not impose additional functionality that doesn't already exist, here's a possible "opt-in" approach:

A. Applications that don't support change tracking: Export: IfcRoot.OwnerHistory must be set to NULL. Import: If IfcRoot.OwnerHistory.ChangeAction is set to DELETED, then the application should ignore the object (as if it doesn't exist).

B. Applications that do support change tracking Export: Identify baseline file using IfcProject.HasAssociations\IfcRelAssociatesLibrary.RelatingLibrary\IfcLibraryInformation, and set IfcRoot.OwnerHistory.ChangeAction for each object accordingly. Import: Same as (A) for general usage, however if application provides a mode for displaying changes, then it may display such changes as fit (could just be overall added/modified/deleted indication or in fine detail comparing with baseline file).

So for allowing this capability, the minimum effort would be for applications to ignore deleted objects if change tracking isn't supported.

[timchipman]

One more thing to add -- if an object has been deleted, then it will no longer be referenced by any collection or reference of an active object, so there's really nothing extra any application would need to do. (And the IfcProject singleton can never be deleted).

[MarieHermanova]

In my opinion it makes a sense for BIM servers or viewers to log the history as describe above but not for applications which convert imported data into their native one. I do not think that users really care about what was changed, removed or deleted when they import the file as a new project. Even if the application allow an update of previously imported project (as ours does) then is more easier to make a comparison of objects by GUIDs in the application itself.

[NickNisbet]

As we move bim into the semantic web, it becomes critically important that all the stuff we disparage as metadata should instead become integral with the model. If models are merged, or appear to be merged , each object must have its author associated. Also its suitability (fit for construction?) and its licence ( ok to use for construction?).

Just like our email disclaimers!

Sent whilst away from my desk.

Regards,

Nick.

Nicholas Nisbet MA(Cantab) DipArch(UNL)
Director: AEC3 UK Ltd Web: http://www.aec3.com E-mail: nn@aec3.com Direct: +44 (0) 1494 714 933
Mobile: +44 (0) 781 616 8554
Skype: nicholasnisbet Registered Address: 46 St Margaret's Grove, Great Kingshill, High Wycombe, Bucks, HP15 6HP, UK Registered in the UK: 03484881

Technical Coordinator: buildingSMART UK Chapter ifcXML Coordinator: buildingSMART Model Support Group Web: http://www.buildingsmart.org.uk/ E-mail: nn@buildingSMART.org.uk

Visiting Professor: University of Northumbria, School of the Built Environment Visiting Professor: University of Cardiff, School of Engineering

\ Confidentiality Notice **. This e-mail and any file(s) transmitted with it, is intended for the exclusive use by the person(s) mentioned above as recipient(s). This e-mail may contain confidential information and/or information protected by intellectual property rights or other rights. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender and delete the original and any copies of this e-mail and any printouts immediately from your system and destroy all copies of it.

On 5 May 2014, at 10:26, Marie Heřmanová notifications@github.com wrote:

In my opinion it makes a sense for BIM servers or viewers to log the history as describe above but not for applications which convert imported data into their native one. I do not think that users really care about what was changed, removed or deleted when they import the file as a new project. Even if the application allow an update of previously imported project (as ours does) then is more easier to make a comparison of objects by GUIDs in the application itself.

The information contained in this message and its attachments is intended only for the use of the addressee, you may not use, copy or disclose to anyone any information contained in the message and its attachments. If you received the message in error, please advise the sender immediately and destroy or delete the message. E-mail transmission cannot be guaranteed to be secure or without errors as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions . — Reply to this email directly or view it on GitHub.

[timchipman]

OwnerHistory is now entirely optional in Design Transfer View and out of scope of the Reference View.

However, if it is provided, then values must reflect reality (no app-generated placeholder information). In practice, many existing applications generate placeholder information, which provides no value and adds unnecessary complexity.