[Go-essp-tech] grids in metafor, and the esg catalog

[V. Balaji]

I've attached an example of an XML file, with some "discovery"-type
fields that will not come from gridspec, e.g documentID, creationDate,
esmModelGrid/shortname,longname,description,reference,referenceList.

In addition Bryan and I felt there were some resolution-related info
which is implicit in gridSpec but the semantics needed to extract it
are rather obscure. While this might introduce some new consistency
issues, that is probably less error-prone than trying to interpret
gridSpec for this information. This may introduce a new field in ESG (I
don't think so) but as far as I can tell (especially since I'm typing as
Don is presenting exactly this at GIP at this second...!) ESG's grid
metadata looks complete.

Sylvia Murphy writes:

> Balaji,
>
> I will answer a couple of your questions below with a list of new questions 
> :)
> On Nov 5, 2009, at 9:21 AM, V. Balaji wrote:
>
>> Sylvia Murphy writes:
>> 
>>> One thing I would request is that we stick with the grid metadata
>>> structure that was agreed upon by Balaji, Phil, et al.  It could be
>>> very confusing to have grid metadata that looks totally different from
>>> this when the gridspec metadata is available.  I see a "join" and a
>>> join of sources vice a join of totally different metadata constructs.
>> 
>> The specific issue is that the XML document in the CIM contains
>> discovery/description metadata fields that cannot be recruited
>> from gridspec netCDF headers. Bryan and I felt that most of them
>> could come from the CMIP5 questionnaire: we went over the questionnaire
>> yesterday and only minor tweaks were needed.
>> 
>> The additional information in the grid CIM can be harvested from
>> gridspec files and that is a fine solution for Metafor. I will be
>> able to answer whether it is also a good solution for CMIP5 when I get
>> all the results back from the grid survey that Karl and I have begun.
>> 
>> If the "discovery" use case requirements are fulfilled by the
>> questionnaire and the regridding use case by gridspec files,
>> is the "join" needed in the short term (CMIP5) or can it be deferred?
>> 
>> Is the join an absolute requirement for the ESG representation of grids?
>> Could it be the "discovery" fields plus a pointer to the gridspec data
>> location?
>
> To answer your questions I need to know the following:
>
> a) Will this discovery metadata be used in the search interface of ESG?  If 
> so, what are we searching on?  Models with that grid configuration?  Gridspec 
> files?  Data files on that grid?
>
> b) Do you want this discovery metadata displayed on the ESG model trackback 
> page?  If so we'll have to talk about how they would integrate with the 
> metata constructs that currently exist.  (e.g. where you want it, how it 
> compares to the mosaic/tile concept, and what you want things to be called).
>
> Thanks,
>
> Sylvia
>
>
>
>
>
>> -- 
>> 
>> V. Balaji                               Office:  +1-609-452-6516
>> Head, Modeling Systems Group, GFDL      Home:    +1-212-253-6662
>> Princeton University                    Email: v.balaji at noaa.gov
>
> -----------------------------------------------------
> Sylvia Murphy
>
> NESII Project Manager
> NOAA/OAR/ESRL
> sylvia.murphy at noaa.gov
> 303-497-7753
>
>
>
>
>

-- 

V. Balaji                               Office:  +1-609-452-6516
Head, Modeling Systems Group, GFDL      Home:    +1-212-253-6662
Princeton University                    Email: v.balaji at noaa.gov