History" tab¶
The "History" tab describes the context and method of creation of the data, and chronologically traces all the events that have occurred in the data (creation, update, publication, etc.). It also indicates the data's validity period and update frequency
Collection context¶
Definition | Purpose of the collection |
---|---|
Indications | Indicate why and in what context this data was produced |
Example | BD CARTO® is one of the major databases produced by the Institut Géographique National. It was born in the mid-80s, with the development of powerful IT tools that opened up new prospects for the computerized management and analysis of localized data. It is particularly well-suited to summary cartography and to applications in project studies, infrastructure management and regional planning, at departmental and regional level. |
INSPIRE requirement | Mandatory |
Batch editing | Yes, by crushing |
Scan | No |
Search engine | No |
Resource sheet | No |
Service sheet | No |
Collection method¶
Definition | Means and methodology used to create and update data |
---|---|
Indications | Indicate how the data was created, from which data (aerial orthophotography, CAD, etc.), with which technologies (GPS, LiDAR, digitization, etc.) and which tools. |
Example | The BD CARTO® was created from: - digitized 1:50,000 maps from the IGN, - SPOT space imagery. |
INSPIRE requirement | Mandatory |
Batch editing | Yes, by crushing |
Scan | No |
Search engine | No |
Resource sheet | No |
Service sheet | No |
Period of validity ¶
Definition | Time period covered by data content |
---|---|
Indications | This period can be interpreted in two ways: - technically: dates of the oldest and most recent object; - thematically: for example, the period of validity of a Local Urban Plan. |
Example | From 04/02/2012 to 08/09/2017 |
INSPIRE requirement | Mandatory, if no publication, update or creation dates entered |
Batch editing | Yes, by crushing |
Scan | No |
Search engine | No |
Resource sheet | No |
Service sheet | No |
Comment¶
Definition | Further details |
---|---|
Indications | Free field for further details on the temporal scope or any other information. |
Example | Data updates are carried out irregularly, according to requests for revision of the PLU |
INSPIRE requirement | Optional |
Batch editing | Yes, by crushing |
Scan | No |
Search engine | No |
Resource sheet | No |
Service sheet | No |
Update frequency ¶
Definition | Time interval between data updates |
---|---|
Indications | Data update rate. The aim is to provide information on the stability of data versions, whether they are vintage dated (regular deliveries) or continuously updated with an average or unknown interval. |
Example | Every 1 year(s) |
INSPIRE requirement | Mandatory |
Batch editing | Yes, by crushing |
Scan | No |
Search engine | No |
Resource sheet | No |
Service sheet | No |
Events ¶
Tip
To clearly differentiate between the different dates of data and metadata, consult appendix Dates in Isogeo.
Definition | Key dates in the life of data |
---|---|
Indications | These dates reflect the life of the data. They can be of 3 types (corresponding to 3 colors): - creation (green, single, manual): when the data was created for the very first time. This is not the reference date of the phenomenon described. Typically, if the data set is a photograph taken on May 15, 2000 of a historic monument dating from 1920, the resource creation date is May 15, 2000, not 1920; - modification (blue, multiple, auto and manual): indicates a revision of the data. The scan automatically creates the event if changes are detected in the geometry, attributes or projection; - publication (gray, multiple, manual): date on which the resource is available, or the effective date. |
Example | |
INSPIRE requirement | Mandatory if validity period not specified |
Batch editing | Yes by increments, for modification and publication dates |
Scan | Yes, for modification dates |
Search engine | Sorting |
Resource sheet | Yes |
Service sheet | Yes |
Tip
As each event is a sub-resource of the metadata, changes to each event must be saved before changes to the resource are saved, otherwise the changes will be lost!