[Go-essp-tech] Extending the DRS syntax to observations

[Cinquini, Luca (3880)]

Hi Rob,
	thanks for your input... 
I can see the merit behind your reasoning... On the other hand, the proposal currently detailed on the wiki was motivated by two criteria:

a) Use for observations the same number of fields that are used for models. That is because clients will be written to query/retrieve model output automatically based on the DRS structure, and having the same exact syntax will allow these clients to work on observations too.

b) The DRS fields for models follow a hierarchical structure that points to more and more specific information about that data: model > experiment > ensemble. Similarly, a possible way to narrow down the specification of observations could be mission > instrument > (other specifiers including processing level).

I would argue that a) is important, while b) can be modified according to what the majority of observation providers feels are the best categories to describe and search for observations. If a consensus cannot be reached by email, maybe we should have a teleconference ?

thanks again,
Luca


On Jan 31, 2011, at 12:36 AM, Raskin, Rob (388M) wrote:

> I have just begun working on this task and will add my initial thoughts. There are two separate issues- (i) fulfilling the needs of the existing naming structures and tools as established by the modeling community; and (ii) fulfilling the needs of the observational community. We probably should focus on (i) initially (i.e., work within the existing environment), given the time constraints involved and the need for broad consensus for new standards.
> 
> Under this assumption, it seems that the "DRS experiment" should map to something under the direct control of the scientist such as Processing Version, as both involve a specific set of algorithms applied. Also, the "DRS Model" probably should map to the Instrument, as both are the direct source of the data. That leaves no mapping for "DRS Ensemble", as that has no analog in the observational world, and probably should be removed from the required set of parameters because it is model-specific. Also Mission is without a direct DRS variable to map to, but can be readily described elsewhere in metadata.
> 
> -Rob
> 
> ________________________________________
> From: Cinquini, Luca (3880) [Luca.Cinquini at jpl.nasa.gov]
> Sent: Wednesday, January 26, 2011 14:50
> To: climate-obs; go-essp-tech at ucar.edu
> Subject: Extending the DRS syntax to observations
> 
> Hi all,
> apologies for cross-posting...
> 
> I'd like to start a discussion on how the DRS specification for CMIP5 model output (http://cmip-pcmdi.llnl.gov/cmip5/docs/cmip5_data_reference_syntax.pdf)
> can be applied to observational datasets that will be made part of the same archive.  A proposal based on recent workshops with PCMDI is detailed on this wiki page:
> 
> http://oodt.jpl.nasa.gov/wiki/display/CLIMATE/Data+and+Metadata+Requirements+for+CMIP5+Observational+Datasets
> 
> As an example, the directory structure for the NASA AIRS dataset would look like this:
> 
> <root directory>/cmip5/observations/nasa/aqua/airs/mon/atmos/ta/l3/vYYYYMMDD/<files>
> 
> where:
> 
> "observations"=<product>, same as DRS "output1" or "output2"
> "nasa"=<agency>, same as DRS "institute"
> "aqua"=<mission>, replaces DRS "model"
> "airs"=<instrument>, replaces DRS "experiment"
> "l3"=<processing level>, replaces DRS "ensemble member"
> vYYYYMMDD=the dated version, same as specified by the DRS
> 
> The values for the various fields <agency>, <mission>, <instrument> and <processing level> would need to be selected from a controlled vocabulary similar to the one established for models.
> 
> Any comment or insight on the matter is appreciated.... The idea is to try to finalize the specification relatively quickly, let's say a couple of weeks, so that we can start preparing
> and publishing these observations into the CMIP5 archive.
> 
> thanks in advance,
> 
> Luca
> 
>