In order to help the automatic cataloguing of data files, to ensure the consistency of the data archive, and to extend the usability of the data archive it is important to adopt certain metadata standards. This means that names of institutes, names of compounds, time labels etc. are applied consistently both within files of similar type and across the data archive as a whole. By adopting the NASA-Ames format for Data Exchange as the format for field observation data certain metadata standards are imposed on UTLS-OZONE. On top of these imposed standards other standards can be chosen. For instance in ACSOE the use of KEYWORDS introduced consistent metadata into the files. This document makes explicit the metadata standards that are part of the NASA-Ames file format and suggests other standards that could be adopted for UTLS-OZONE.
This document is separate to the description of the file format: the meta data standards can be applied to file formats other than NASA Ames. This document has been written with NASA Ames Format for Data Exchange in mind however, and so makes most sense if the reader is already familiar with the NASA Ames format. A short introduction to the NASA Ames format can be found here.
The definition of the NASA-Ames Format, and in particular the header, automatically defines some of the metadata content, and in some cases the metadata format. The table outlines the content, and where defined, the format for metadata that is part of the NASA-Ames format Standard.
| Metadata | NASA-Ames imposed Format | UTLS-OZONE Format | Example |
|---|---|---|---|
| Originator of file | Surname, Other names. One line less than 132 characters | Surname, Initials | Bloggs, J. |
| Originators Address | One line less than 132 characters | Agreed Postal Address | |
| Source Name | One line less than 132 characters | Platform / Instrument | c-130 / UV meter |
| Mission Name | One line less than 132 characters | Project / UTLS-OZONE | ACTO / UTLS-OZONE |
| Start date of observations | yyyy mm dd | yyyy mm dd | 1999 01 01 |
| Date of data reduction | yyyy mm dd | yyyy mm dd | 1999 01 01 |
| Variable Names | Name (units) | UV Flux (W/m2) | |
| Missing values | Larger than any good value | Larger than any good value | 999.999 |
There are no conventions placed on variable names by the standard. For UTLS-OZONE it is suggested that an agreed set of variable names will be used, to ensure consistency across data files, and in particular files from different instruments which measure the same quantity.
Many of the instruments have time as the independent variable. Where possible it is suggested that this time is measured in seconds from 0UTC on the start date and labelled Seconds from 0UTC on start date. Other time units may be used if necessary, but please check with the BADC to get a name that is consistent with usage across the archive.
Where data has been averaged or collected over a time interval then the centre of the averaging or collection time should be given in the file. If this is not possible then this should be made clear in the normal comments section of the file.
| Flag | Meaning |
|---|---|
| 0 | Valid |
| 1 | Reduced quality |
| 2 | Present, but likely to be wrong or instrument not in measurement mode |
| 3 | Completely invalid or missing data |
It is suggested that a description of these flags be included as part of the normal comments in the NASA-Ames file. The description can be expanded upon where necessary, for instance, give the reason for thinking the data is of reduced quality, or the algorithm by which the quality of the data has been determined.
| Keyword | example | Use |
|---|---|---|
| E-MAIL-CONTACT | j.bloggs@rl.ac.uk | compulsary |
| THIS-FILE-NAME | optional (omit) | |
| THIS-FILE-VERSION | 1 | compulsary |
| THIS-FILE-ENDS | 1999 01 02 | use if different from start date |
At some time the BADC may take over the implementation of version number recording and updating. Until they do you should try and keep track of your own version numbers.
The extra information can be included in a keyword like way, for instance using the keyword FLIGHT-NUMBER, but there are no plans as yet to use these for cataloguing the data and so their format is much less constrained.