[Esip-preserve] Need for recommended best practice for DOI minting?

[Matt Mayernik]

Ruth,
We've had a number of discussions about this within our NCAR data 
citation working group. Ultimately, our decision was to use completely 
randomly generated DOIs for the reasons that 1) any 
organizational-specific components would become out of date if data are 
moved between archives or organizations and 2) any intelligence built 
into a DOI is another thing that needs to be managed and maintained over 
the long term. But it's been a series of discussions to get to this 
point, and there are some specific use cases that still argue in the 
other direction,  human-readability, consolidation with internal ID 
schemes, and easier google searching for groups of IDs.

In short, I think ESIP guidelines for this issue would be very helpful.

Matt

On 9/7/2012 11:50 AM, Conover, Helen wrote:
> In general I agree that DOIs should be opaque.
>
> One aspect of the emerging DOI conventions from ESDIS is to include "DATA" in the DOI, to distinguish it from a journal article or other kind of digital object.  What does the group think about that practice, separate from any other information people may want to encode?
>
> - Helen
>
> -- Helen Conover hconover at itsc.uah.edu Information Technology and 
> Systems Center University of Alabama in Huntsville Huntsville, AL 
> 35899 Voice: 256-961-7807 FAX: 256-824-5149 On Sep 7, 2012, at 12:26 
> PM, Ruth Duerr wrote:
>> >Dear ESIP'ers;
>> >
>> >It looks like DOI's are well on the road to implementation by the data community.  While the ESIP citation guidelines do talk briefly about best practices in minting DOI's - specifically
>> >
>> >"Best practice is that the suffix of the identifier does not include a reference to the archive in case the data are moved from the original location where the persistent identifier was assigned initially."
>> >
>> >there is no other guidance provided.  As a result a variety of implementations are being proposed by organizations like NASA, research groups, etc.  The question is whether ESIP should promote more uniform implementation by providing more detailed best practices?
>> >
>> >I note that many of the proposed implementations encode information in the DOI string itself - information which may change over time (e.g., mission or program name, instrument identifier, product name, etc.) leading one to expect that many data sets will end up with multiple DOI's over time.
>> >
>> >The EZID folks actually mint DOI's using an opaque identifier and recommend this as a best practice.  A quote from their documentation follows:
>> >
>> >"Opacity
>> >
>> >Many of the terms in this document serve semantic opacity, which is useful in creating identifiers that age and travel well ...  Perfect opacity in identifiers is not as important as identifiers' having semantics that are not widely recognizable, even if those semantics may support administrative activity by specialists (cf. ISBNs).  ...  For the purposes of longevity, however, it is critical that attachments to authority and sub-authority names ... be avoided; it is common for political pressures to require sacrificing identifiers created out of short-sighted administrative or branding convenience."
>> >
>> >I also note that the DOI's generated by publishers are generally opaque in the sense described by EZID.  The first 5 DOI's from a query of Google Scholar for the phrase "Digital object identifier" were:
>> >
>> >doi:10.1215/S0012-7094-90-06119-8
>> >http://dx.doi.org/10.2481/dsj.4.12
>> >doi:10.1214/07-AIHP146
>> >doi:10.2307/2373173
>> >http://dx.doi.org/10.3998/3336451.0003.204
>> >
>> >These were from articles from 5 different journals!
>> >
>> >What does the community think?  Is a more comprehensive best practices warranted?  If so, what should it say?
>> >
>> >Ruth
>> >_______________________________________________
>> >Esip-preserve mailing list
>> >Esip-preserve at lists.esipfed.org
>> >http://www.lists.esipfed.org/mailman/listinfo/esip-preserve
> _______________________________________________
> Esip-preserve mailing list
> Esip-preserve at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-preserve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-preserve/attachments/20120907/3dd0eee1/attachment.html>