Open durack1 opened 7 months ago
We need to separate the consortiums from the institutions. Consortiums will not have an ROR number.
Having separate tables for consortiums and institutions may make some QC checks more complicated. If, for example, we impose a directory structure that includes "institution", but a consortium is responsible, we want the consortium to appear instead of the institution as part of the directory structure. If we maintain separate CVs for consortiums and institutions, software checking that all the elements of a directory structure are included in a CV would have to check both the institution CV and the consortium CV.
Could we include the consortia in the institutions CV with the following changes?
These can now be added via an issue template as of https://github.com/PCMDI/mip-cmor-tables/pull/49
Just as an idea for discussion:
Two Institution consortiums are actually a partnership - of which we have many. Does it make sense to allow multiple institutions to be submitted per entry instead?
What are the funding implications of doing so?
Similarly would we want to differentiate datasets submitted before and after a new entity joins a consortium?
@wolfiex @taylor13 This is starting to get complicated; I suggest we intentionally try to simplify things as much as we can. I had been thinking that we need an "institution" (bricks and mortar, with a postal address) that would then be eligible for an ROR, and rather than have consortium "institutions," we'd catch these consortiums as part of the source_id
- my thinking with https://github.com/PCMDI/input4MIPs_CVs/issues/9, UExeter
is the lead (Thomas' host) institution, but the dataset is a team/consortium effort which is identified by a source_id
that may have multiple institutions listed, with the first entry the dataset institution_id
Is this what you are proposing?
I don't see any problems with this, but it will decrease visibility of the consortium name, which will appear nowhere. Will EC-Earth be o.k. with this?
@taylor13 I think I need to calibrate with @wolfiex and better understand how information is partitioned between the MIP_consortiums.json and MIP_institutions.json files - airplane wifi is too spotty.
For the CMIP6 EC-Earth3*
examples, everyone of these had a listed institution_id = EC-Earth-Consortium
which includes ~30 institutions identified by a name/acronym and country with a mailing address of SMHI, one of the 30 listed centres (see CMIP6_institution_id.html). This is a particularly good example of why my simplified system would not work well - whereas it could work in the case of the volcanic forcing.. It might be useful to defer this issue to a discussion, as there is much to calibrate on it seems, and working through all existing examples is the only way to definitively come up with a path that maps across all existing (and hopefully future) configs
A consortium is a collection of individual institutions presenting as one. An institution is just that.
A consortium is not a physical entity but behaves like one.
The work, submission, data, modelling is still done by a single person at an institution but commissioned or funded as part of something greater. It is therefore recorded from a consortium.
The same way we can have ESPRI-IPSL INCO?-NEO-IPSL and direct submissions by IPSL
(To be corrected later)
Just linking across repos following https://github.com/PCMDI/input4MIPs_CVs/issues/8.
We need to register
DLR-BIRA
,ESPRI-IPSL
,GloH2O
,INCOIS-NIO-IPSL
,NOAA-ESRL-PSD
,UCI-CHRS
, andUCSD-SIO
.This is a matched issue with https://github.com/PCMDI/obs4MIPs_CVs/issues/1