Gellish Wiki

Gellish supports the management of change process on the lowest level of atomic facts. Each atomic fact is denoted by a unique identifier (UID). A fact is only known in the Gellish environment if its fact UID is allocated. If there is no fact UID then we cannot say anything about it. A UID may not change and there may not be two UID’s that denote the same fact. A fact UID may also not be reused to denote another fact.

A fact is something that is the case. If it is no longer the case, then it should get the status ‘deleted’, although it does not need to be physically removed from the database, because usually it is valuable to retain the historical knowledge about its earlier existence. So the status ‘deleted’ means that its validity is terminated.

A fact can also be replaced by another fact. This may be used to indicate that a situation has been changed into another situation. Then the fact get the status ‘replaced’, whereas in a separate column in the Database it is recorded what the UID is of the successor fact by which it is replaced.

Although a fact cannot change, the expression of a fact may change and the auxiliary facts about the fact may also change. For example, names may be improved, a textual description may be improved, the status may change (e.g. from ‘proposed’ to ‘accepted’). The change of an auxiliary fact shall be accompanied by a registration of the author of the latest change and the data of the latest change. A particular implementation of Gellish may decide to archive also the old state of the fact to trace its improvement history.

When a fact is created it should be accompanied by a registration of its creation date and of the person who is responsible for the creation of the fact. The name of the originator and the creation date shall never be changed. It is also recommended to record a reference to a source or another reference document, person or organization that can be consulted for additional information.

Measured data, such as measured temperatures, usually have a very limited validity period. Their creation ‘date’ is the ‘moment in time’ at which their validity period starts and the ‘date of latest change’ is the ‘moment in time’ at which the validity period terminates (the two moments in time may be equal). The status of a measured value should be ‘history’. This method also supports the registration of average values over periods in time. Note that the moment in time is recorded as a real number according to the ‘1900 date system’ (see http://support.microsoft.com/kb/q180162/). This enables to register a moment in time to an accuracy that is above any current measurement accuracy.

Another mechanism to manage change is through ordinary Gellish relations between objects. Especially the <is a next version of> relation, the <is a successor of> relation and their inverse expressions (previous and predecessor).

The existence (the ‘life’) of an object terminates when its definition fact is deleted (gets the status ‘deleted’ or is physically removed). Such a deletion implies that all the facts about the object should also be deleted. Special attention should be given to various kinds of relation types. For example, occurrences in which the object is involved, because depending on the kind of involvement in the occurrence the occurrence itself might continue to exist or not. Some deletions should normally be propagated, such as the deletion of parts when an assembly is deleted. The deletion of parts should be confirmed before actually being executed. If a collection is deleted it should be verified whether the elements in the collection should also be deleted or not.

Return to Start