[Go-essp-tech] DOI target page CMIP5

Fri Nov 19 06:18:44 MST 2010

Hi Luca,

Here is one from WDCC: http://dx.doi.org/10.1594/WDCC/EH4_OPYC_SRES_A2

I'm expect there will be significant modifications for the CMIP5 pages.

A question for Bryan: is it the case that a DOI will only be flagged as
"superceded" if there is a DOI for data superceding it? E.g. if a
modelling group discovers an error with some data, the DOI page would
presumably have a "deprecated" flag set until replacement data is
available. If the issuing of a DOI for replacement data is held up for
some reason, there is no obvious way for the DOI page of the superceded
version to point to it without becoming a reference for it.

Cheers,
Martin

> -----Original Message-----
> From: go-essp-tech-bounces at ucar.edu [mailto:go-essp-tech-
> bounces at ucar.edu] On Behalf Of Cinquini, Luca (3880)
> Sent: 19 November 2010 13:05
> To: Lawrence, Bryan (STFC,RAL,SSTD)
> Cc: go-essp-tech at ucar.edu
> Subject: Re: [Go-essp-tech] DOI target page CMIP5
> 
> Hi Bryan,
> 	excuse me if I should know this already, but are there DOI
> examples somewhere, at least what their form should look like ?
> One thing to consider is that we will want to assign DOIs to
> observational datasets, and it would be great if the format could
> somehow be compatible with models...
> thanks a lot, Luca
> 
> On Nov 19, 2010, at 1:35 AM, Bryan Lawrence wrote:
> 
> >
> > hi Karl
> >
> > Most of these issues were discussed in the doi paper or in the
> > discussion around it.
> >
> > 1) DOIs are to be granted per simulation (in metafor terms), that is
> to
> > aggregations of realm publication units, themselves aggregations of
> > atomic datasets. (Hence, o(1000) DOIs for CMIP5)
> > - the URLS and identifiers we have for those smaller units are then
> > analogous to chapters and pages.
> >
> > 2) The issue of "replacement etc" is why we have a comprehensive
> > procedure to minimise the necessity for replacing things, but the
> entire
> > machinery is predicated on the fact that indeed there will be
> versions.
> >
> > 3) DOIs will always point to pages which point at the actual
> aggregation
> > at the time of DOI allocation, but the page can be marked as
> superceded.
> >
> > Cheers
> > Bryan
> >
> >> Hi all,
> >>
> >> Has it been decided how large a chunk of data is going to be
> assigned
> >> a DOI.  Will they be assigned at the DRS atomic dataset level?  Or
> >> the DRS "publication-level dataset" level? or what?   I guess the
> >> tradeoff is:
> >>
> >> Larger chunks require fewer DOI's
> >> Larger chunks mean that some files will be associated with multiple
> >> DOI's (when a single file in the chunk gets replaced, the chunk
will
> >> have to be assigned a new DOI, so all the other files will now be
> >> associated with 2 DOI's).
> >>
> >> We will have to provide a service so a user knows what data is
> >> associated with each DOI.  If a given subset of a chunk of data is
> >> associated with multiple DOI's, a reference to either DOI should
> >> point to the same (identical) subset of the data.
> >>
> >> Is this confusing?
> >>
> >> best regards,
> >> Karl
> >>
> >> On 11/16/10 5:22 AM, Martina Stockhause wrote:
> >>>   Hallo Bryan, dear all,
> >>>
> >>> we started to set up the mirror pages of your DOI target page. It
> >>> is very rough, since we plan to use your stylesheet and the
> >>> link(s) to the data at the three ESGF locations are not
> >>> implemented, yet. We filled the page with our CERA test data.
> >>>
> >>> We suggest to put the summary on the page, because otherwise there
> >>> is no immediate information available. The summary uses sentences
> >>> from the CMIP5 page and the experiment description of the
> >>> questionnaire (atomfeed experiment).
> >>>
> >>> What is missing:
> >>> - construction of the link into the CIM repository to the
> >>> simulationRun document to replace the cirrus-link.
> >>> - datanode TDS root catalogue and file server root access for the
> >>> data access link.
> >>> - style sheet of your primary DOI target page.
> >>>
> >>> To construct a link to the data at BADC and PCMDI we need the TDS
> >>> root and the file server root addresses. We plan to provide lists
> >>> of chunks for the given DOI and a list of ESG dataset links.
> >>>
> >>> E.g. DKRZ:
> >>> tds root (replicated data):
> >>> http://BLOCKEDbmbf-ipcc-ar5.dkrz.de/thredds/esgcet/1/ fileserver
> >>> root: http://BLOCKEDbmbf-ipcc-ar5.dkrz.de/thredds/fileServer/new/
> >>>
> >>> Please add your information for BADC and PCMDI at
> >>> http://BLOCKEDesgf.org/wiki/Cmip5Status .
> >>> Just to make sure: You will use one root for all replicated data?
> >>> If not, we cannot provide the link list but only the DRS names
> >>> (TDS file_id + version + variable in case of chunks and TDS
> >>> dataset_id in case of ESG datasets).
> >>>
> >>> What do you think? Any suggestions for improvements?
> >>> Any suggestions what the DOI service should provide for the users
/
> >>> the portals? The chunk list for a DRS experiment will include
> >>> hundreds of links, which is not very convenient for the user.
> >>>
> >>> Best wishes,
> >>> Martina
> >
> > --
> > Bryan Lawrence
> > Director of Environmental Archival and Associated Research
> > (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
> > STFC, Rutherford Appleton Laboratory
> > Phone +44 1235 445012; Fax ... 5848;
> > Web: home.badc.rl.ac.uk/lawrence
> > _______________________________________________
> > GO-ESSP-TECH mailing list
> > GO-ESSP-TECH at ucar.edu
> > http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
> 
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
-- 
Scanned by iCritical.