[Esip-preserve] [EXTERNAL] Re: Assigning DOIs to data set versions?

Tue May 26 16:49:37 EDT 2020

Matt,

My answer is similar to Mark’s. 

In NASA EOSDIS (DAACs), most of the data we deal with are dynamic – i.e., growing time series because data are being collected daily (or by the minute or second) and strictly speaking they are constantly changing.  We cannot wait until all the data acquisition form a given instrument has been completed before assigning a DOI since data are used for science and publications come out much before the data acquisition stops. So, the version (and DOI) assignment for a given data product depends on whether the processing algorithm(s) have changed significantly. When such changes do occur, we have reprocessing events that result in new versions of data products, going all the way to the beginning of the missions. There are also minor versions that are generated when small corrections are made that don’t necessarily apply to the entire mission dataset to date. In those cases, DOIs do not change.

Hope this helps.

Rama.

From: Esip-preserve [mailto:esip-preserve-bounces at lists.esipfed.org] On Behalf Of Danie Kinkade via Esip-preserve
Sent: Tuesday, May 26, 2020 12:34 PM
To: esip-preserve at lists.esipfed.org
Subject: [EXTERNAL] Re: [Esip-preserve] Assigning DOIs to data set versions?

Hi Matt - BCO-DMO follows a very similar strategy as EarthChem, and use version number in our DOI suffix (e.g., XXXXX.1; tracking major reversions here). 

But, we consider it published as soon as data files are linked to metadata and the DOI has been requested (aka "validated" in our local parlance); any changes after that point (to data content vs metadata) warrant a new DOI version.

Best of luck as you navigate your strategy!

-Danie

On 5/26/20 1:23 PM, Kerstin Lehnert via Esip-preserve wrote:

At the EarthChem Library, we generate a new version & DOI only if the actual data in the data file have changed as such change will have an impact on the outcomes of the data use i.e. reproducibility of the scientific interpretation. If changes are made to metadata, especially if it's just a correction of a method or sample location, we do record that change in an annotation, but do not issue a new version.

If a correction of the data (fixing typos) is made shortly after publication and before a published dataset has ever been downloaded, we usually allow the corrected version to replace the old one without issuing a new DOI.

Kerstin

On 5/26/20 13:06, Parsons, Mark via Esip-preserve wrote:

Hi Matt, 

When I was at NSIDC, we assigned major versions to things that “might change the science”. A very crude rule of thumb, but helpful.

The Arctic Data Center at NCEAS, on the other hand, assigns a new DOI for any little change to the data or metadata. 

Much depends on the nature of the data: how dynamic it is, what expected use patterns are… 

Of course, the RDA dynamic data citation rec. addresses the issue to a large degree. This might be a good time to try and implement. I know Reyna Jenkins at Ocean Networks Canada is grappling with this with similar types of data.

cheers,

-m. 

On 26 May 2020, at 10:32, Matthew Mayernik via Esip-preserve <esip-preserve at lists.esipfed.org> wrote:

Hi all,

I have a question about how you all are dealing with version tracking and DOIs. I am familiar with the ESIP data citation recommendation that talks about "major" vs "minor" versions, but I am curious about how this is actually being implemented. 

Does your repository assign DOIs for each denoted version, e.g. version 1, version 2, etc? Do you assign DOIs for incremental version changes, e.g. version 1.2 or version 2.3? What constitutes a version change in these cases? Does anybody assign DOIs to any change at all regardless of how large (e.g. a wording update in metadata)? Does anybody not assign new DOIs regardless of any versioning or dataset changes?

I'm asking because we are bringing in a fairly complex group of datasets into one of our NCAR repositories, and tracking versions is not at all straightforward. Since we intend to assign DOIs to the data, we're working through the above scenarios with no clear optimal outcome yet.

Any input on how you are actually implementing the ESIP recommendations (or others) on this would be much appreciated,

Best,

Matt

Matthew Mayernik, Ph.D.

NCAR Library

National Center for Atmospheric Research (NCAR)

University Corporation for Atmospheric Research (UCAR)

Boulder, CO

mayernik at ucar.edu

_______________________________________________
Esip-preserve mailing list
Esip-preserve at lists.esipfed.org
https://lists.esipfed.org/mailman/listinfo/% <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.esipfed.org%2fmailman%2flistinfo%2f%25&c=E,1,KyEzAFqCC0rMDCw7U_0ExGTHo4LQKOqlD9iS3VTaw_5bnXG7URrYvgYdkzhkvlrnOUAMur0cgeeJDSmAjR9ak2twHN4Y4tlPwCewa9KHdh5Mk28,&typo=1> 
(_internal_name)s

_______________________________________________
Esip-preserve mailing list
Esip-preserve at lists.esipfed.org
https://lists.esipfed.org/mailman/listinfo/% <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.esipfed.org%2fmailman%2flistinfo%2f%25&c=E,1,HL9MIF9WyHmP1Ld3TTq14pP3L09TNLFjIeJdsy4_4JdHkfllrF7haaEUlTAL_iVHxvzf0nBAZMfQrr2G9EA5w_CCxi8s11M4eeNCtEgVIRh76Q,,&typo=1> 
(_internal_name)s

-- 
Dr. Kerstin A. Lehnert
Doherty Senior Research Scientist
Director, Geoinformatics Research Group
Director, Interdisciplinary Earth Data Alliance
Lamont-Doherty Earth Observatory of Columbia University
61 Route 9W, Palisades, NY, 10964, USA
+1 (845) 365-8506

_______________________________________________
Esip-preserve mailing list
Esip-preserve at lists.esipfed.org
https://lists.esipfed.org/mailman/listinfo/% <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.esipfed.org%2fmailman%2flistinfo%2f%25&c=E,1,XFdB9N_lFRXb3oAjyqRxVPrVkkg0mNDQ_J-D2oIj822072hxPJade5ISZ_LHQt3lucl6yS_TKjd9CMDbzqr4SPCrCHMVkicQ1ozJwSloM1zg&typo=1> 
(_internal_name)s

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.esipfed.org/pipermail/esip-preserve/attachments/20200526/d57dc4f9/attachment.htm>