Version management

CBIS Version Management
Technical description

Inhoud

Introduction

Although many database systems support version management in one way or another there are good reasons to store version management data also in the information model itself. In this way one standard way of representing the history of the model can be preserved over various database implementations. Conservation of the history of model modifications is also core business for building information modeling. It is simply of utmost importance to keep track of which modifications were when introduced by whom operating in which role. Apart from that the native version management functions of the applied database system can still (and therefor should be) used for daily operation and where the COINS Building Information System (CBIS) version management data is handled in the same way as the actual content data.

The starting point for the CBIS Version Management design was the concept of preserving every model state. This means that the information model can in principle only grow because never an information object will be physically deleted. Of course the actual implementation of this principle could be quite an undertaking. Here we describe the design features to make such an implementation feasible, not the actual implementation itself. A reference implementation is available as part of the COINS Testing tool that can be downloaded from the COINS web site: http://www.coinsweb.nl/wiki/index.php/COINS_Testgereedschap.

Representing deleted and modified information objects

All information objects in a COINS Building Information Model (CBIM) are instances of a class that inherits directly or indirectly of the abstract super type CbimObject. CbimObject defines primarily a set of attributes for identification, meta data and management data. It also defines two attributes which serve the implementation of version management: expired and nextVersion. Version management is typically implemented as part of a CBIS, i.e. the shared project CBIM that is under control of a so-called building director (in Dutch: bouwwerkregisseur). A CBIM as part of a COINS Container (a cabinet file containing the CBIM and all referenced document files) will typically only contain an up-to-date model without any previous versions of information objects.

These different uses of CBIM (as the central shared project model or as part of a information transaction using COINS containers) also affects some basic handling of the model objects. In a CBIM without version management information objects can explicitly be modified or deleted. However, in a CBIS CBIM an information object will never be updated or deleted. A modification of an object will always result in a new object containing the new state of the original object. The deletion of an object is effected by simply setting the expired flag. Only the creation of a new object is handled the same.

Representing a deleted object

Figure 1: A CBIM representation of an object before and after its deletion.
Figure 1: A CBIM representation of an object before and after its deletion.
As stated before under version management control an information object is never physically deleted from the model. The state of the deleted object is unaffectedly preserved. The only difference in state before and after the deletion is the expired flag which is set to true after the deletion.

Representing a modified object

Figure 2: A CBIM representation of an object before and after the value of its attribute “a” is changed from “0” to “1”.
Figure 2: A CBIM representation of an object before and after the value of its attribute “a” is changed from “0” to “1”.
After an information object has been changed the original object instance points with its nextVersion property to the newly created object instance. The ID's of both objects will be the same. However, because two or more object instances cannot be represented with identical ID's in the same model the version number is added to the identical logical ID's to create different physical ID's. Logical ID and version number are separated by a dot character. Therefore the physical ID of a CBIM object is put together from the logical ID followed by a dot character followed by the version number: <physical ID> ::= <logical ID>.<version number>. By convention the first version (with version number = 0) may be skipped, so a physical ID without a “trailing dot plus integer number” shall be treated as <logical ID>.0.

Linking policy with deleted and modified information objects

Until here the discussion restricts itself to the implications for the data properties of an object, i.e. properties which refer to a literal value: a character string or a boolean, integer or real value. These values are unaffected (in case of deletion) or simply copied to the new object instance (in case of modification). In this section will be discussed how to handle the object properties or links, i.e. properties that refer to one or more other objects. Since object properties have a direction a distinction can be made between ingoing links and outgoing links.

Linking policy with deleted information objects

Figure 3: The incoming and outgoing links that existed before the deletion still exist after the deletion.
Figure 3: The incoming and outgoing links that existed before the deletion still exist after the deletion.
Deleting an information object, i.e. setting its expired flag, does not affect the ingoing and outgoing links.

However, there are implications in the semantics. In the example of figure 3 object A refers to object B through property linkA. After the deletion it still refers to object B, which is now expired. In a historical view the semantics are that up to a certain moment in time (the last modification date of the expired object) object A referred to object B. After that moment object B ceases to exist, which implicates that linkA from that instant effectively is reduced to a void link. As a result the actual view (which only displays existing or non-expired objects) should reveal that linkA is void or empty. In the same example object B refers through property linkB to object C. The historical view shows that once object B existed and referred to object C. In the actual view this historical fact has completely disappeared.

Linking policy with modified information objects

As discussed before modifying an information object results into a new object instance with identical logical ID and an incremented version number. Except for the expired flag all property values of the original object instance are cloned into the new instance. This holds for both data properties as well as object properties (outgoing links).

Figure 4: Cloning all data properties and object properties into the new object instance.
Figure 4: Cloning all data properties and object properties into the new object instance.
In the example of figure 4 object A is referring to object B through object property linkA. After the modification of object B this link still points to object B. But unlike the deleted object case now there is a non-void nextVersion link available which effectively points to the next version of object B. If this version should also be expired and again a non-void nextVersion link is available this procedure could be repeated until a real expired object B version is encountered or a non-expired i.e. the current version of object B.

The pre-modified version of object B refers to object C through object property linkB. The new version of object B also copies this link to object C so that there are now two link instances linkB to object C. The reason for copying the link is that the deletion of this link could be the trigger to create the new version. Copying the link shows that this is not the case here. Mark that simply deleting the new version instance (and implicitly the copied link) and resetting the expired flag in the previous version instance is sufficient to roll back to the original state.

Bi-directional linking (inverse relation) policy

Certain object property are defined bi-directional, i.e. there exists an inverse relationship. As a rule in a CBIM only one direction is explicitly specified (while for performance reasons the inverse direction could be inferred and temporarily added to the live model). The policy here is that adding a bi-directional link will always trigger the creation of a new object instance no matter which actual direction was chosen. So adding a bi-directional link between two existing objects will force both sides to create new versions.

Merging

The CBIS CBIM could be updated interactively by adding, deleting and updating objects one at a time. However, in a transaction based system (for instance using VISI) the updating takes place in a batch like manner. The building director will send out an assignment to a partner role in the project (specifier, designer, planner, etc.). The assignment is described in a formal message specified according to the VISI framework schema for that specific project. Part of this message is a COINS container which holds a relevant part of the actual CBIS CBIM including referenced documents. The person who fulfills the partner role at that moment will execute the assignment which results in an updated CBIM, i.e. some new objects are added, a few obsolete objects are removed and a number of existing objects are modified. This result is returned to the building director using again a COINS container. After acceptance this result must be added the the shared CBIS CBIM in a so called merge operation.

Merging could be interpreted as a sequence of separate modifications, however only the result is exchanged not the way this result has been achieved. In order to merge the CBIS CBIM and the received container CBIM must be compared to detect newly created objects, deleted objects and updated objects. To prevent the creation of superfluous new versions it is necessary to collect all changes on each object before the actual merging operation.

To realize an optimal control on the life cycle of each information object every affected object of the merge operation is attached a document reference to the VISI message that accompanied the container. This VISI message as a result of a specific transaction explains the changes in this version of the object.

Afkomstig van CoinsWiki NL, de Vrije Encyclopedie. "http://www.coinsweb.nl/wiki/index.php/Version_management"
Personal tools