The NHMO example occurrenceID at the CETAF PID page does not resolve

[dagendresen]

The NHMO example PID at the CETAF Stable Identifiers (CSI) page no longer resolves?

http://purl.org/nhmuio/id/41d9cbb4-4590-4265-8079-ca44d46d27c3 Redirects to https://data.gbif.no/resolver/O:L:14 --> "404 Not Found" After first giving a warning that the page is not safe!

Fixed now redirecting to https://data.gbif.no/resolver/urn:catalog:O:L:14

[rukayaj]

Thanks for checking this! It should not be redirecting to data.gbif.no/resolver/x, but to resolver.gbif.no/x. I think that redirect is associated with your account though, as the data-manager@gbif.no account does not have access to it. So if you delete it there I can remake it with data-manager@gbif.no.

Here is the gbif.org record it should be resolving: https://www.gbif.org/occurrence/919264528

I see on gbif.org it has a prefix, so it is urn:catalog:O:L:14 now, and that is in the resolver: https://resolver.gbif.no/urn:catalog:O:L:14/ .

We also have purl.org/gbifnorway/id/x style purls, but interestingly I found even if you put in https://purl.org/gbifnorway/id/urn:catalog:O:L:14, which should work, it does not and instead stays stuck on purl.org and gives a 500 error! So I made an experiment:

https://purl.org/nhmuio/id/a:b:c => no redirect, 500 internal server error (on purl.org, not the resolver) https://purl.org/nhmuio/id/a:b => redirects as expected to https://resolver.gbif.no/a:b, 404 not found (as it does not exist)

Another test: https://purl.org/nhmuio/id/urn:uuid:6984f74c-64b2-40c6-8c43-9c47d5f88923/ => 500 internal server error on purl.org, whereas it should go to https://resolver.gbif.no/urn:uuid:6984f74c-64b2-40c6-8c43-9c47d5f88923/ (Which gives 200)

So it looks like 2 colons in the url causes purl.org to break. I think we actually came across this problem before and it was one of the reasons we wanted to swap to the handle system.

[dagendresen]

Many thanks for checking up on a Saturday! It can surely wait till next week, or later... :-) +1 for further exploring the Handle system maybe even moving on to DOI type handles :-)

When I log in at PURL I see for nhmuio the following PURL redirects

name	type	target	created
/nhmuio/id/	partial	https://resolver.gbif.no/	2012-11-27 10:45:53
/nhmuio/pid/	partial	http://gbif.no/resolver/	2013-04-11 05:50:05
/nhmuio/lid/	partial	http://nhm2.uio.no/resolver/	2013-04-11 05:51:27
/nhmuio/id/urn:uuid:	partial	https://data.gbif.no/resolver/	2017-06-20 15:58:16

Should I delete all - or maybe only the /nhmuio/id/?

I mean to recall the /nhmuio/lid/ was used when packing the collections in the Geological museum when moving them to the (then) new storage at Økern. And used to identify and resolve the IDs for the blue boxes containing material from one entire shelf. Used to check the box onto the truck and off the truck when it arrived at Økern. Unsure if these still are in use to identify and resolve these blue boxes in the Økern storage today. I suspect that the http://nhm2.uio.no/resolver/ server is no longer operational? I get an error message "403 Forbidden" but that might be because of calling it without a UUID? Because when I do I get "404 Not Found".

The /nhmuio/pid/ I believe is only an experiment.

The /nhmuio/id/urn:uuid: likewise... (but maybe causing harm?)

I also see the following experiments, including the PID used as the example for the CETAF (CSI) page. Maybe these also cause harm? Maybe we want to create a DUMMY test UUID for such pure fictional experiments?

name	type	target	created
/nhmuio/id/41d9cbb4-4590-4265-8079-ca44d46d27c3	303 See Other	https://data.gbif.no/resolver/O:L:14	2017-06-20 17:32:48
/nhmuio/id/urn:uuid:41d9cbb4-4590-4265-8079-ca44d46d27c3	303 See Other	https://data.gbif.no/resolver/O:L:14	2017-06-20 17:34:15
/nhmuio/id/c1a8b878-a4f9-448b-be00-26cbad58b11c	303 See Other	http://nhm2.uio.no/typephotos/lichens/typephotoS.php?f=O-L-000500k_s.jpg	2017-10-15 11:22:58

[dagendresen]

Apropos --> how the DOI system approaches URN representations of the DOI names (identifiers) --> including with two colons in the URL form

2.6.3 URN presentation To enable the use of DOIs in workflows that have already standardized on URNs, the DOI proxy servers understand the substitution of a colon in place of the initial slash in a DOI name. DOI names may therefore be expressed as URNs in the doi.org domain by writing, for example, the DOI name 10.123/456 in the form https://doi.org/urn:doi:10.123:456. Note, however, that a DOI suffix is allowed to contain other slashes, and where these occur they must be percent-encoded rather than replaced with a colon: for example, the DOI name 10.123/456ABC/zyz would become https://doi.org/urn:doi:10.123:456ABC%2Fzyz, with the final slash character encoded as %2F.

Following the same approach, we might desire to support both:

https://purl.org/gbifnorway/id/urn:catalog:O:L:14 and https://purl.org/gbifnorway/id/O:L:14

https://purl.org/gbifnorway/id/urn:uuid:41d9cbb4-4590-4265-8079-ca44d46d27c3 and http://purl.org/nhmuio/id/41d9cbb4-4590-4265-8079-ca44d46d27c3

However, as you discovered, this might not be possible with PURLs...

[dagendresen]

Fixed - closing