## 3 Time in WikiGIS
### Updating a Temporal Database  
The integration of the temporal reference increases the complexity of the updating process. This is why versioning techniques were developed [14, 15, 16]. Temporality can be assigned to different components of a database. It might be assigned to entire tables (table versioning), to each record of a table (tuple versioning) or to each value taken by descriptive attributes (attribute versioning and even geometric attributes in some systems). Each technique has advantages and disadvantages. * Table versioning (by object classes) is very useful if all occurrences change simultaneously. The full table is then copied when changes in content are detected at a given time. This kind of versioning requires more disk space, but has the advantage of being very simple to perform;  
Figure 3: WikiGIS positioning with GIS (Geographic Information System) and CADD (Computer Aided Design and Drafting) [4]. Versioning by occurrence (tuple versioning) is the most common versioning technique: it is used when a record (an occurrence) is copied fully in the same table; then this copy is used to store the update and the old record remains valid in the DB. This is an interesting technique when several attributes of a given occurrence change at the same time. It is simple to implement and query, but it introduces redundancy; unchanged attributes are copied also;
* Attribute versioning (versioning by field) method operates with fields. When a field's value is changed, only the value of this field is updated. This method saves disk space but requires the use of records with variable length and results in a rather complex structure. Often, it requires building new tables to manage the history of attribute value changes. Choosing one of these techniques is often based on data redundancy and query optimization concerns. In our case, and in the WikGIS concept context, \"versioning by occurrence\" appears to be the most relevant choice because it is the simplest. In fact, every proposition to change a scenario or to propose a new one can be considered a different and unique action (rather than the evolution of a previous action). The relationship with previous actions can be dealt with proper relations built into the database. The page is reloaded instantly and current versions are displayed in a \"thread of versioning\". By versioning by occurrence, the disaggregation is manageable. For example, user A decides to disaggregate one polygon into two so that later on, user B can edit only one of the two polygons. Indeed, the different changes are considered as unique action and they are handled in a new record. The WikGIS database is built as mentioned in Table 2.  
Each version is considered as an occurrence. The fields of ID_current primitive and ID_previous primitive help in making the request in both directions: up and down. They indirectly help draw the evolution of the entity. The ID machine of the entity and ID_previous primitive are reordered automatically, but the ID_current primitive must be indexed. Creating an index supports the temporal structure [16]. The index offers quick access to values in a column. By adding a new record to a table, the index is reordered automatically.