[Go-essp-tech] Meeting Notes 1/21/2014

[Cinquini, Luca (398J)]

GO-ESSP MEETING 1/21/2014

1) Stephen reported on Askbot recovery and future user support

- goal is to have shared ownership and maintenance among several ESGF institutions of user support system
- CEDA is installing VM to support shared applications starting with Askbot, will provide access to other ESGF administrators
- ESGF must identify a few admins with provileges to start/stop Askbot and other services on VM
- Stephen tried to recover DB system from previous instance at PCMDI but it looks like it is corrupted, will not be able to recover all information
- Should have VM and Askbot ready within a few weeks
- Will work on developing documentation for VM administrators

2) Phil reported on plans for upgrading the ESGF security infrastructure

- security task force met during F2F meeting, identified roadmap for the upcoming year(s)
- first priority items:
	- get rid of user certificates when running wget scripts, involves changes to IDP code
	- enable delegation of credentials - involves OAuth
	- support authentication with WAYF ("Where Are you From") feature, involves modifications to both ORP and IDP code
- new developer starting at CEDA tasked with working on above items
- In parallel will work on limiting number of CAs in the trust store - Phil will contact Rachana

3) Started discussion on Controlled Vocabularies. We reviewed all current facets used by ESGF and decided which ones should be controlled and which shouldn't (see list below).
Will continue discussion as a joint telco with ES-DOC, to discuss content and format of CVs. The general feeling in ESGF is that we should start working with simple lists of CVs to
speed up the process, and later switch to using more complex documents.

=============================================================================

LIST OF ESGF SEARCH FACETS

o Project
	- should be revisited, as the project value controls which vocabulary to use. There is some need to limit the values it can assume, but on the other hand we do not want to make it hard for users to register and create new projects, for example in CoG. Maybe we need to distinguish between projects that publish data, and projects that are created to support a scientific goal of some kind

o Model: should be regulated by CV

o Experiment: should follow CV

o Experiment Family: CV

o Ensemble: we should not try to completely control this facet as there are too many values, but rather upgrade the software to enforce a regular expression"rXiYpZ". There was general agreement that Ensemble is still useful as a facet

o Instutute: CV

o Product: CV. At a later time, this facet could be better defined or evolved.

o Realm: CV

o Cmor_table: to some extent, this facet overlaps with Realm. It was decided to keep it as a facet for now, but leave any decision of a CV for later on

o Time Frequency: CV

o Variable: after some discussion, it was decided that a project like CMIP5 should be able to enforce a CV to allow consistent naming and searching across files. Other projects, like ana4MIPs, should be able to decide to use the same CV as CMIP5, and perhaps expand it with additional terms, or use no CV at all. 
The ESGF publishing infrastructure already supports the use of different CVs for different projects.

o Variable Long Name: it was decided to NOT control this facet as a CV

o CF Standard Name: the possible values are already controlled by the CF specification. ESGF should be able to parse the official list and use it to enforce correct values.