Commands are naturally grouped together into sessions so that each command represents one point in time during the session it occurs in. If a session is an object (in the sense of the LINCKS database model), then each command occurring during the session can be seen as an object version. In this way the database command history has a natural partitioning into session objects whose versions are the commands, and the building of a command history can utilise the existing temporal version management.
The links between commands of different sessions are always links between database commands. The workspace commands are, as a consequence of the workspace-database separation, invisible for other workspaces. Therefore it makes little sense to allow temporal links between workspace commands of different sessions.
We have two time structures in the command history. The first is the user session history that is stored as versions in a session history object. The second is a partially ordered time relation between the database commands, i.e. the commands that applied to the database, see figure 10.