Model for DataGeneration needs to be improved #48
Description
Motivation
The current FeatureType 'DataGeneration' defines a DataType 'Schedule' without specifying whether this schedule actually describes the 'Sampling' or the 'Reporting', both of which can reasonably be assumed to be implied. This leads to ambiguities and makes it difficult to correctly describe the procedures involved in generating and distributing data. An example are manual observations of total ozone using the Dobson instrument. Typically, such observations are made a few times per day, the data are aggregated to a daily value, and they are reported to a data centre on more or less regular basis, but potentially only every (few) year(s) in the worst case. Other examples are presumably observations from the polar regions that may not be possible during polar night, but may be fairly frequently made during polar day; or observations from mobile marine platforms. The original intention of 'schedule' was thus more to describe the sampling (the actual generation of data), but the UML model is ambiguous. Also, if 'schedule' is used for the sampling, it is not available to describe the reporting (distribution) aspects.
Stakeholder
WOUDC (@tomkralidis ), WDCA/WDCRG (@markusfiebig), OceanObs (@anthoninlize ), others
Proposal
Review the model of DataGeneration. Presumably, remove DataType 'Schedule' from 'DataGeneration' and include it both as an element of 'Sampling' and 'Reporting'. Test any proposed solution specifically with examples from typical application areas (regular meteorological observations from land-based stations; radar; ocean; GCW; GAW; polar observations; on demand observations)