The LINCKS system maintains a substantial amount of historical information. The motivation for this is partly that intelligent support or A.I. reasoning often requires information not only about the present state of affairs but also about past states. An additional motivation is that even apart from automated reasoning, users often wish to have access to historical information.
The LINCKS system maintains three main types of history information:
The temporal history in LINCKS could be described as a history based on logical transaction time. That is, it is based on transaction time but at a logical level rather than at the level of time stamps regarding when objects are saved. Thus if user 1 takes out an object, and edits it, then user 2 takes out the same object and edits it (prior to user 1 having done a save), then user 1 saves, and finally user 2 saves, then the two edits are regarded as being parallel in the temporal history. User 1's edit is not before that of user 2.
The temporal history is the only history that is currently shown by the system. It can be shown at the level of the composite object or at the level of individual components. One can mark and view previous versions and can also promote them to be current in order to continue development from that point.
Development history represents the information regarding where an object has come from in its development. It may often be natural to have an object in several versions, which develop in parallel, at least for a period of time. Two users may wish to develop their own versions of a document which they are working on together, rather than trying to combine them at every step.
Development history is constrained by the temporal history in
the sense that a version cannot be a predecessor in a
development history unless it is also a predecessor in the
temporal history (or from a separate object).
There is currently no graphical interface to the development history. It is carried in the SYSTEM:Parent link which can be seen in the node view.
The command history gives information regarding the (logical) temporal relation between commands that have been issued by various users of the system. It maintains the temporal relationships between database commands (store and retrieve) issued by different users - thus one can ask questions of the type, ``Was a given object retrieved by user 1 before another object was retrieved by user 2?'' This can be useful for providing assistance to users in reasoning about why things have happened as they have.
The command history also contains information about what objects have been affected by each command. Thus one can ask the question, ``What command (including person and time) caused this particular change in the data?''
There is currently no graphical interface to the command history, but we plan to include one soon. This is an area of active research for us, and we believe that the command history gives possibilities for more advanced reasoning about what has happened in a database than has previously been usual.