Owner History - functionality in scope about ifc4-cv HOT 7 CLOSED

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;

from ifc4-cv.

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.

from ifc4-cv.

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.

from ifc4-cv.

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).

from ifc4-cv.

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.

from ifc4-cv.

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: [email protected]
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: [email protected]

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á [email protected] 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.

from ifc4-cv.

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.

from ifc4-cv.