<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 6, 2014 at 10:10 AM, Tim Robertson [GBIF] <span dir="ltr">&lt;<a href="mailto:trobertson@gbif.org" target="_blank">trobertson@gbif.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>  a) client has a specimen record they wish to stamp with an identifier</div>
<div>  b) client requests DOI (or other format) from the issuing service and provides the minimum metadata in a DwC-esque profile, potentially with a preferred suffix  </div><div>  c) service provides identifier, and client stores this along with their digital record</div>
<div>  d) from this point on, the DOI identifies the record</div></div></blockquote><div><br></div><div>Pretty much, I think.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>If so, what would happen on resolution?  Does the client provide the target URL during minting which will be the redirection target on resolution?</div></div></blockquote><div><br></div>
<div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>  Does the service have to monitor the availability and return the cached copy on outage?<br>
</div></div></blockquote><div><br></div><div>No. This is why you sometimes get an error when resolving a DOI for an article.</div><div><br></div><div>The thing with CrossRef is that by agreeing to the terms of service publishers are obligated to maintain the DOI metadata record, including a properly resolving landing page. Repeat-offending publishers get dinged. DataCite also has a dashboard that shows which members have how many DOIs for which they fail resolution.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>What seems most important to me when I think this through is that the identifier needs to be minted as early on as possible in the record life - before it is shared with others.  Which leads us back to the question of whether we envisage people adopting a model where they effectively submit their record data in order to get an identifier.  If not, at least if we got stable IDs on records in whatever form, we can manage the resolvability bit later, and identify duplicates.<br>
</div></div></blockquote><div><br></div><div>Note that you can mint the DOI before registering it. It won&#39;t resolve until it&#39;s registered, but there is no requirement that publication must precede deciding on the DOI.</div>
<div><br></div><div>In other words, the client decides on what the DOI is to be, not the registration agency. </div><div><br></div><div>  -hilmar</div></div><div><br></div>-- <br><div dir="ltr"><div>Hilmar Lapp -:- <a href="http://informatics.nescent.org/wiki" target="_blank">informatics.nescent.org/wiki</a> -:- <a href="http://lappland.io" target="_blank">lappland.io</a><br>
</div><br></div>
</div></div>