[Go-essp-tech] Minutes: 2 June 2009 ESG Functionality Demonstration

[Sylvia Murphy]

Participants:

Sylvia Murphy, Luca Cinquini, Paolo Missier, Eric Guilyardi, Gerry  
Devine, Dean Williams,
Steve Hankin, Archer Batchellor, Phil Bentley, Ruport Ford, Bryan  
Lawrance, Sergii Nikovov,
Hans Ramthun, Spencer Rugaber, Karl Taylor, Allyn Treshansky, Ricky  
Rood,
Bob Drach, V. Balaji, Sophie Valcke, Paul Edwards, Marie-Pierre Moine,  
Martin Juckes,
Alex Sim, Tobias Weigel, Meili Chen, Sebastien Denvil, Cecelia DeLuca,  
Peter Bosler



Hi everyone,

Thank you all who attended and provided us with your feedback. I have  
grouped and bulletized the comments and suggestions by topic.  Please  
feel free to add to or correct what my notes below.

Definitions:  The highest priority requirement that came out of the  
demo is the need to have a mechanism so that users can find the  
definitions of each class of metadata (e.g. what is a mosaic? What is  
a spatial filter etc).  We plan to start work on this functionality  
right away.

Grids:  Sylvia showed a trackback page that contained hierarchically  
arranged grid metadata.  It is anticipated that grid metadata will   
come primarily from the harvesting of metadata from netCDF files  
produced by GFDL's gridspec program, although some additional pieces   
may come from Metafor's AR5 questionnaire.  A discussion ensued  about  
how the grid metadata is anticipated to be used.  We anticipate the  
metadata will be used for discovery and model documentation while the   
actual grid files will be used for regridding and post processing.

1) There were a lot of comments indicating that more information is  
needed on the grid tab to describe what a user is seeing.   Some  
specific suggestions include:

** A paragraph that would describe what grid mosaics and tiles ARE

** A link to GFDL's gridspec web page

** Links to metadata definitions mentioned previously

** Have profiles so that only some metadata will appear for the   
novice, more for an advanced user, and all for experts.

2) Include the bounding box of the grid.  This would need to be part   
of the gridspec program.  Balaji, whose team is writing the gridspec  
software, commented he had thought about this requirement, but did not  
know yet how to implement it.

3) Include links to the actual grid files.  Sylvia indicated that this  
is already planned.

4) Sylvia asked the group whether keeping all of the tiles in a multi-  
tiled display was useful.  The fact that the extent of the tiles would  
be different, and whether or not they are pole covered would vary led  
the group to recommend that all the tiles all be displayed.

Controlled Vocabulary:  Currently, ESG's controlled vocabulary exists  
within a Sesame Store and is modified via OWL.  It may be possible for  
ESG to use a non-local, common, controlled vocabulary server to avoid  
a separate, and continually diverging set of instances and  
definitions. Curator would like to explore the idea of a separate  
server but it's up to ESG to make the call on the implementation. A  
discussion ensued about who should create the definitions for the  
controlled vocabulary classes. It was suggested  that since Metafor is  
working on pieces of the controlled vocabulary, they should also  
provide definitions.  An issue was also raised about how these  
definitions would be controlled and if users could modify them through  
some interface.

A question was raised about whether the displayed metadata is  
constrained. Sylvia indicated that some metadata is fully constrained  
while others are simple strings with no constraint.  She also said  
that for the constrained portions, new instances are always appearing  
outside of the initial estimates and that these are added to the  
metadata instances as necessary.

Data to Metadata: Sylvia demonstrated browsing for an AR4 dataset and  
then navigating from that dataset to the simulation instance that  
created it.  She then navigated from the simulation back to the data.  
Everyone seemed to like the interface.  In a separate email after the  
demonstration, Steve Hankin indicated that he thought the use of "data  
collections" on the ESG data browse side of the connection and  
"outputs" on the Curator, model metadata side of the connection was  
confusing.  He suggested similar terminology be used.  The output  
section of the Curator metadata page is designed to contain data  
collections, under its own sub-divider, and also lists of output  
variables, so it covers more than just data collections.  Still,  
minimizing confusion for the user is important and this issue will be  
examined further.

Metadata Display:  In a separate email, Steve Hankin suggested adding  
an ability to view all of the metadata in a long alphabetical list.   
He thought users would get lost going from tab to tab to find the  
piece of metadata that interested them. He also suggested a print  
function.  These suggestions will be reviewed.

Comparison Table:  Steve Hankin noted off-line this is a very  
important capability.

General Comments and Questions:

* Someone asked why there are two separate mechanisms to find data  
collections from the ESG portal.  You can use the advanced search for  
datasets but you can also browse through a hierarchical tree. Luca  
responded that they had found users who wanted one or the other  
mechanism and so they had  decided to provide both

* Sophie wanted to know whether the plan was to conform ESG's ontology  
to Metafor's CIM.  Luca responded that there would need to be  
sufficient reason to, since any change to the current ESG structure  
requires work to propagate it through ESG's database, Java  objects,  
and RDF ontology.

* Several people asked who is the target audience for the Curator user  
interface.  This interface is now part of ESG, which already has a  
very large user base (~15,000 users).  In the short term, Curator's  
initial target audience is scientists participating in AR5/CMIP5 and  
using the data generated.  The highest priority is clearly and  
exhaustively documenting the simulations that are run.
* Karl Taylor noted that it was very important to accurately represent  
the way runs were related to each other - research is often conducted  
as variations off a base run.  This is a topic that arose recently in  
discussions with Metafor and we expect some examples to be shown for  
the next demo.

* Balaji commented that even though the group had been nitpicking the  
interface, it looked really great and that nothing like it has existed  
before.  Thanks to Balaji for this comment.  We are proud of the work  
to date.



Future Work:

In response to input from the call, Curator's next priority is to  
create a mechanism to allow terms in the user interface to be linked  
to their definitions. We will also address genealogy of simulations  
(how they are related to one another).  We expect to have another demo  
to show this work once it is completed.

After that, focus will shift to an XML upload capability so that ESG  
is prepared to ingest the XML that Metafor's questionnaire will  
produce.  After this, work will begin on a workspace where a user or   
group can save models, simulations, and datasets and compare them  
using a dynamic intercomparison capability like that which was  
developed for last summer's dynamical core intercomparison project.


Cheers,

Sylvia
-----------------------------------------------------
Sylvia Murphy
Project Manager

Earth System Modeling Project
http://www.esmf.ucar.edu
National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder, CO 80305
303-497-1882
murphys at ucar.edu