gbif-norway / helpdesk

Please submit your helpdesk request here (or send an email to helpdesk@gbif.no). We will also use this repo for documentation of node helpdesk cases.
GNU General Public License v3.0
3 stars 0 forks source link

PURL to DOI (or Handle) #80

Open dagendresen opened 2 years ago

dagendresen commented 2 years ago

The GBIF PID resolver hosted by GBIF Norway is based on PURL. An upgrade to DOI was planned for the 2017-2020 project period but was not completed.

The IPT manual described independent node DOI capabilities fra Canada, Colombia, and Spain. https://ipt.gbif.org/manual/en/ipt/2.5/data-hosting-centres

rukayaj commented 2 years ago

Possibility of using #s instead of 303 redirects: https://books.google.no/books?id=xFZsCQAAQBAJ&pg=PA525&lpg=PA525&dq=semantic+web+303+redirect&source=bl&ots=trsPakAuDu&sig=ACfU3U1qBk6X1ppA-3Os40pTLlbDcz-esg&hl=en&sa=X&ved=2ahUKEwjFzujBpOPpAhXjlosKHY_3C8cQ6AEwC3oECBAQAQ#v=onepage&q=semantic%20web%20303%20redirect&f=false (page 525)

dagendresen commented 2 years ago

Might be useful to check and discuss DOI/Handle services and best practice with the UiO Library (e.g. Mattew Good), BioMedData project partners (e.g. Korbinian Bösl), and with the Norwegian DataCite node (previously BibSys --> Unit --> ?)

See also DiSSCo DOI progress reported at https://doi.org/10.3897/rio.7.e67379

rukayaj commented 2 years ago

I have emailed Korbinian and Matthew about this.

I guess we also need to think about how we would go about adding these DOIs. If we made the annotation service would it be enough to store them as annotations, or do we need to publish them on GBIF? In which case they should probably get added to MUSIT.

dagendresen commented 2 years ago

NOTE that NBIC has established a DOI domain and is in progress to provide a DOI endpoint for data downloads from Artskart

NBIC DOI domain: https://doi.org/10.16907
Test DOI endpoint: https://doi.test.artsdatabanken.no/

doi org:10 16907:artskart-5mf2-t862

Example of a download dataset DOI: https://doi.org/10.16907/artskart-5mf2-t862

Test endpoint at: https://doi.test.artsdatabanken.no/#619da448-2107-ba8d-5ffa-a2cc8c36c4a8


I have asked Knut Hovstad if NBIC might help provide DOI domain (and host the technical endpoint) for the approx 8 million digitized Norwegian voucher specimens ... :-)


Useful to discuss further with Stein Hoem (@steinho)!! (including synchronization of download DOI solutions, see eg. GBIF Derived datasets blog post?)

rukayaj commented 2 years ago

We had a meeting with GBIF about this on 13 Jan, they suggested waiting to see what would happen with a possible consortium (dissco, gbif and some others) who would form a DOI registration agency, able to issue DOIs for specimens. And it sounds like there will be some kind of solution for differentiating between physical specimens + digital information about specimens. However, this is very much up in the air and in its preliminary stages, and may well change into something else entirely.

Note: the resolver + PURLs works for all records in GBIF (including field observations with no specimen collected), but we've been discussing a solution for resolvable IDs for physical specimens/material samples only.

Note 2: Datacite DOIs do a 302 redirect, not 303, so this is technically not compatible with the CETAF standard either.

rukayaj commented 2 years ago

This is also an interesting article from Crossref about choosing 302 over 303 redirects https://www.crossref.org/blog/redirecting-redirection/

dagendresen commented 2 years ago

I find the initial Crossref argument here of the chain of redirects to be spurious and rather irrelevant!! The important thing is that the URI which is in the rdf:about = URIhas a redirect preferably of type 303 see other! Whatever (chain of) redirects happen after this URI is irrelevant to the purpose!

What matter is that there is some way to distinguish the thing from a description of the thing ... :-)

I guess this does not at all have to be achieved through a 303...!

Sure we can find a pragmatical compromise versus full semantic rigor... ;-) Relying toooo much on the web ecosystem for persistent identification is itself problematic! For how long do we really expect http/https to remain the king-on-the-hill rock-star? :-D Which is why I prefer to at least keep the urn:uuid:UUID format in the loop somewhere (as the rdf:about = urn:uuid:UUID).

rukayaj commented 2 years ago

https://www.usit.uio.no/prosjekter/fair-uio/