[Go-essp-tech] DOI target page CMIP5

Fri Nov 19 06:52:51 MST 2010

  Hi,

Luca, there are more examples available on the dataCite-Homepage:
http://datacite.org/examples.html

Explanation of "superceded" DOIs:  DOIs remain valid once they are 
assigned. But we can introduce references.
There are two cases for references:

1. the same atomic datasets are published again: Then the old DOI is 
added a reference isOldVersionOf pointing to the new DOI and the new DOI 
gets a reference isNewVersionOf. We could view that isOldVersionOf 
reference on the DOI target page to refer the user to the newer Version.

2. new ensemble members are published: Then we plan to add a reference 
isSupplementTo to this data pointing to the existing DOI for the first 
ensemble members. We could as well think about showing that on the DOI 
target page.

You can find more information on STD-DOI process in the Documents 
section on the http://www.std-doi.de and in the document: 
http://dc110dmz.gfz-potsdam.de/contenido/std-doi/upload/pdf/STD_metadata_kernel_v3.pdf

Karl,

>  We will have to provide a service so a user knows what data is
>  associated with each DOI.

We are aware of that at the WDCC. And we are the only place who keeps 
track of the chunks belonging to a DOI. Since the DOIs contain hundreds 
of chunks, the resulting file list for a DOI is rather long. It would be 
very helpful to know what we should respond to a request of data for a 
DOI: the DRS_ids, the TDS-fileserver links or the TDS dataset links 
(versions are always complete).

When we will have an example and a suggestion for such a file list, I 
will send the information around.

Best wishes and have a nice weekend,
Martina

On 11/19/2010 02:18 PM, martin.juckes at stfc.ac.uk wrote:
> 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

-- 
----------- DKRZ / Data Management -----------

Martina Stockhause
Deutsches Klimarechenzentrum
Bundesstr. 45a
D-20146 Hamburg
Germany

phone:	+49-40-460094-122
FAX:	+49-40-460094-106
e-mail:	martina.stockhause at zmaw.de

----------------------------------------------