Request for obs4MIPs data specification modification

The following requests are exception requests from the REF delivery team. They have been reviewed by obs4MIPs Steering Panel member Birgit Hassler, who supports this set of requests. Please can obs4MIPs co-chairs alert us if any of these requests would not be feasible. If no response is given during the hackathon we will proceed with our testing, on the basis the below will be possible, subject to formal approval of these exception requests at the next Steering Panel Meeting.
1. Obs4mips to insert a DOI into the file header in preparation for ingest for complex citation compatible with IPCC TG-Data specifications.
2. Inclusion of a standardised format following CF conventions for uncertainty information. In accordance with [Example 3.3. Ancillary instrument data](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.12/cf-conventions.html#ancillary-data) and [Table C.1. Standard Name Modifiers](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.12/cf-conventions.html#standard-name-modifiers), obs4MIPs should have a single netcdf file with the ancillary information on uncertainty (number of observations, standard error) for each variable as a minimum. This enables the REF and the metrics packages to ingest the uncertainty information alongside the observations.
3. Additional metadata field such as "has_auxdata", with boolean type. If set to True, then the REF knows to look for the uncertainty information within the file. If not present, the REF will be able to handle that.
4. Qualitative description of what is included in the uncertainty estimate provided in the description or long_name attribute of the variable for standard_error. This comes from the observational community who want to make sure they communicate clearly what is included in their uncertainty calculation.
5. Further guidance on discussing and including the impact of diurnal cycle on the observations, which would usually not be represented in the uncertainty information.
6. Some metadata fields specified as "always" required in Table 1: obs4MIPs global attribute description of [ODS2.5](https://zenodo.org/records/11500474) do not seem to be included in the recently published ERA5 dataset (for example "processing_code_location", "source_label". This is not an issue for the REF, the REF only requires the following attributes: activity_id, frequency, grid, grid_label, institution_id, long_name, nominal_resolution, realm, product, source_id, source_type, units, variable_id, variant_label, vertical_levels, source_version_number. However, it raises the question whether the priority level of including metadata fields not required by the REF could be changed from "always" to "usually".
7. Allow station/point source timeseries datasets according to CF conventions for [H.2.1. Orthogonal multidimensional array representation of time series](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.12/cf-conventions.html#_orthogonal_multidimensional_array_representation_of_time_series).

Iniziate confrontando le sette eccezioni richieste con i requisiti dei metadati di ODS2.5 e le CF conventions collegate per i dati ancillari e le serie temporali delle stazioni. Verificate come sono rappresentate le specifiche obs4MIPs in questo repository, se vengono identificate, e considerate l’issue completa solo quando siano documentate la fattibilità, le modifiche necessarie alle specifiche e l’approvazione formale.

Scritto dal modello di indicizzazione a partire dal testo della issue.