[Go-essp-tech] CMIP5 Version directory structure update

[Martina Stockhause]

Good Morning, Bryan,

I'd like to try a summary:

For the DOIs on experiments (metafor simulations) the mechanism is as
follows:
- QC L2 is reached.
- The information about the QC checks is sent to the CIM repository. The
right version of the simulation metadata is identified by the list of
tracking ids or DRS names of the checked data. A file with the brief QC
L2 result is added. The Quality Flag is increased.
- During the DOI process in the author approval step some metadata may
be altered or added. An update is send to the CIM repository simulation
metadata.
- A DOI is assigned. The information about the assignment of the DOI is
sent to the CIM repository simulation metadata. The Quality Flag is
increased.
- On the DOI page appears a link to this version of the simulation metadata.

The two steps of adding metadata to the simulation is necessary for the
update of the Quality Flag as long as the different quality levels are
connected with different access permissions. Otherwise we could do the
metadata update in one step.

How do a user get to the data from this simulation metadata page? My
idea was a link into the catalog or a list of links to the associated
versions of model_realms.

The other use case is a user of CMIP5 data who is looking for the DOI to
cite in his publication. You mentioned the need for a user to identify
the version of his data in a telco on the versioning. This use case is
one step further from data via version to DOI.

You raised a problem about differences in the metafor metadata and the
data: The model used was not the model described in the questionnaire. I
put that on the list of subjective data and metadata controls: check the
names of the models between data (DRS model name) and model name in the
questionnaire. Since we cannot identify all of such possible
inconsistencies, we the approval of the simulation metadata has to be
one part in author approval step of the DOI process.

If an error in the data is found after the DOI was assigned, we can use
the same steps for the assignment of a new DOI.

An open question seem to be the assignment of DOIs on a higher/coarser
level of DRS model or DRS institute. As I understood metafor doesn't
support such an aggregation at the moment. Will that be the case? If
not, I think we should rather find another solution for the DOI
versioning than to have two different solutions for the two levels of
DOIs: one in metafor and one outside of metafor.

A small clarification of the DOI assignment: If we find errors during
the QC process, no DOI is assigned. We assign one DOI for all data
belonging to a DRS experiment or metafor simulation (finer granularity)
or produced by one model of a modelling center or by one modelling
center (coarser granularity). So the DOI points to a collection or
aggregation of data. Resolving a DOI leads the user to a list of data
belonging to the DOI.

Cheers,
Martina


Bryan Lawrence wrote:
> On Thursday 10 Jun 2010 16:21:51 Pascoe, Stephen (STFC,RAL,SSTD) wrote:
>   
>> So you are going to version simulation metadata.  Are you going to
>> independently version all the other bits of CIM too?  What happens if
>> there is a qc failure at the experiment requirements level -- does
>>  that imply generating a whole new set of DOIs?
>>     
>
> I should have said that the infrastructure (will) support it, it then 
> becomes an enterprise level issue as to how you use it ... 
>
> What Martina's question did was expose a wee flaw in our thinking wrt to 
> technical support for those associations ... but as I say, little to do 
> to fix that. Deciding on how much of it to use is a different issue.
>
> So, to address the specific question. We should write down those rules, 
> but in the case of an experiment, i would argue that the doi points ot a 
> simulation. If the experiment requirements were screwed, then the 
> conformances would be screwed, so the simulation description would be 
> screwed. All change!
>
> Cheers
> Bryan
>