If a DOI system is adopted, then there is a contractual obligation for the
issuing party to maintain a landing page for the DOI and, if the DOI links
to some digital object such as a data set, to maintain access to that
digital object. I don't know if there are obligations to maintain physical
objects for which DOIs have been registered (i.e. plant material), but I am
sure that the registration agency such as EZID can answer that question.
The registration agency, for their part, is required to maintain to actual
identifier. I don't think anyone is going to legally commit to maintain
anything for ever, and that is an unrealistic expectation.

I know this is getting into last week's topic, but I still think it is
important. Combining institution code and accession number as Axel
suggested is unlikely to work as a PUID solution, because it is unlikely to
be universally unique. Although this is an expedient solution for
genebanks, given their limited personnel, my understanding is that the
genebanks are not to be the ones registering and maintaining DOIs, but
rather the GLIS (although I am not exactly sure what that is or will be).

Ramona

------------------------------------------------------
Ramona L. Walls, Ph.D.
Scientific Analyst, The iPlant Collaborative, University of Arizona
Research Associate, Bio5 Institute, University of Arizona
Laboratory Research Associate, New York Botanical Garden

On Fri, Mar 13, 2015 at 6:35 AM, Diederichsen, Axel <
[log in to unmask]> wrote:

> Dear Colleagues,
>
> The valid points made by Matija are of concern. From a/our genebank's
> perspective I must say that the human resources available to invest much
> into PUIs from our end are extremely limited. Perhaps the best is still to
> return to the simple solution to combine the Institute code (INSTCODE) and
> Accession number (ACCENUMB). For genebank accessions that should make for
> an PUI for such material. So far, genebank clients have mostly not reported
> genebank accessions numbers in publications, not to talk about cultivar
> descriptions or pedigrees, if available at all. If we could get people to
> do that, we had achieved a lot. The long DOIs will be even less popular in
> that context, I suppose.
>
> Greetings,
>
> Axel
>
> -----Original Message-----
> From: Global Information System on PGRFA [mailto:
> [log in to unmask]] On Behalf Of Matija Obreza
> Sent: March-12-15 7:13 PM
> To: [log in to unmask]
> Subject: Re: Week 3 - MCPD to DWC mapping - the DwC germplasm extension
>
> No, Marco, you haven't scratched the surface of my question.
>
> > as there is no unique party "responsible of maintaining the generated
> PUID forever", but rather a group of organisations and systems that,
> together, work to maintain the association between the PUID and the PGRFA
> entity valid "forever". In this view, and I agree, some even define the
> PUID as such association between the entity and the identifier string.
>
> You say there is no party responsible [for] maintaining the generated PUID
> forever.
> What then is the purpose of generating one in the first place if it's not
> permanent and nobody maintains it?
> Where is the "permanency" of the identifier? Who takes care that it is
> permanent?
>
> > According to our view of GLIS and what we have discussed in the past
> weeks, the involved systems and organisations are:
> >
> > 1) the DOI system, responsible of maintaining the DOI resolver
> infrastructure. This is a highly redundant infrastructure (17 sites
> worldwide) that has proved to be very reliable so far. The International
> DOI Foundation (IDF) has a sound business model, is backed by international
> standards and contractual arrangements have been established to preserve
> the DOI resolver system even in case the IDF should evaporate in the
> future. Please note that, even if the DOI resolver should cease to exist,
> the fact on GLISusers would be the impossibility of resolving the DOI using
> a third-party website. In other words, the users would have to know to go
> to GLIS to resolve that DOI, something that is considered normal in other
> PUID types such as LSID or UUID where the presence of a central registry is
> optional;
>
> That was a very long text that literally did not address any issues I
> raised.
> Let's just call that the convention to use another resolver and move on.
>
> > 2) GLIS, the authority that originally assigned the DOI to the PGRFA,
> would be responsible of maintaining its own functions of (i) resolving the
> DOI to a landing page on the PGRFA with available metadata and the list of
> associated destinations that have been accumulated over time. Of course,
> maintaining GLIS "forever" is quite a challenge, but the entire ITPGRFA is
> designed to last "forever" and Easy-SMTA has already accepted such
> challenge for its own role;
>
> ITPGRFA is a legally binding agreement. What we are discussing here is not.
> Self-serving purposes don't solve the problem we are addressing here.
> We want the Permanent Identifiers to be introduced and stay here until the
> end of the World so that we can all refer to our PGR material in an agreed
> way. Forever. And a bit longer.
>
> > 3) the genebank or other user who originally registered the PGRFA in
> GLIS (receiving the newly minted DOI in return) will be responsible of
> maintaining the detail page to which the initial destination provided
> during the PGRFA registration would point to (using a URL or maybe a PURL).
> If any change occurs to the genebank or user's organisation that would
> invalidate such destination, that genebank or organisation would have to
> take responsibility to update the destination accordingly.
>
> What if the gene bank "forgets" what the original PUID was? Will the GLIS
> generate a new PUID on demand? Can I have 1,000,000 entries for my
> collection of 10 banana clones? But since I forgot about original PUIDs, I
> cannot make redirects, so the old ones are all void, but valid?
>
> Is the gene bank (or whoever has the material) responsible to maintain the
> PUID, or not?
>
> > As you will immediately see, points 2) and 3) apply regardless of the
> adopted PUID type.
>
> I agree: It is all about the convention.
>
> > Point 1), i.e. the function of a central registry that is able to route
> the user request to the appropriate system is so useful that hoping to do
> without is, in my opinon, not a very smart idea.
>
> No. That is done by convention and agreement of all parties.
>
> > Beside, the presence of a central registry guarantees that the PUID is
> truly "globally unique", something that other identifier types may not
> claim with the same certainty.
>
> Yes, but same can be achieved with use of random UUIDs, which would not
> require any central agency to handle germ plasm registration.
>
> > Surely, any central registry is a potential point of weakness, but I
> think that credit must be given to the IDF for having designed a very
> reliable and durable system.
>
> No. As long as it suits us as users, we will use the system. Once we find
> an alternative that does not tie us to the authoritative concepts, we - as
> users - will move to the next thing.
>
>
> Matija Obreza
> Global Crop Diversity Trust
> Platz der Vereinten Nationen 7
> 53113 Bonn, Germany
> Office: +49 228 85427 128
> www.croptrust.org
>
> Conserving Crop Diversity, Forever
>
>
> ########################################################################
>
> To unsubscribe from the GLIS-PGRFA-L list, click the following link:
> https://listserv.fao.org/cgi-bin/wa?SUBED1=GLIS-PGRFA-L&A=1
>
> ########################################################################
>
> To unsubscribe from the GLIS-PGRFA-L list, click the following link:
> https://listserv.fao.org/cgi-bin/wa?SUBED1=GLIS-PGRFA-L&A=1
>

########################################################################

To unsubscribe from the GLIS-PGRFA-L list, click the following link:
https://listserv.fao.org/cgi-bin/wa?SUBED1=GLIS-PGRFA-L&A=1