Re-visit Identifiers.org registration

[amoeba]

@mbjones and I were looking at our Identifiers.org registration for the d1id prefix. This is a great thing to have. A couple of questions came up:

• Could the prefix be dataone instead or is there a good reason to use d1ids?
• The URL Pattern set for the namespace is https://cn.dataone.org/cn/v2/resolve/{{$id}}. Considering the PIRI Service, would changing this to https://dataone.org/datasets/{{$id}} make any sense? The /resolve/ API endpoint has specific and narrow HTTP request semantics and we could probably better serve identifier resolution semantics within the PIRI service.

Thoughts or other ideas? ping @datadavev @mbjones, all dev team folks

[amoeba]

@mbjones pointed out that our ROR ID is https://ror.org/00hr5y405 so we should probably use that in our Identifiers.org registration

[mbjones]

Here's what I propose we should register as a new resource:

[datadavev]

IIRC this registration was created very early in the life of identifiers.org and never utilized beyond a few test cases. Considering identifiers.org is really a registration of identifier types, I'm not sure it's a good fit for DataONE since we don't have an identifier scheme, but rather run a resolution service. Do we really want to promote a "d1id" identifier type? Otherwise, this change makes sense if the overall goal is to eventually deprecate the existing service interfaces. - Dave

…

On Wed, Feb 17, 2021 at 8:47 PM Bryce Mecum ***@***.***> wrote: @mbjones <https://github.com/mbjones> and I were looking at our Identifiers.org <https://registry.identifiers.org/> registration for the d1id prefix <https://registry.identifiers.org/registry/d1id>. This is a great thing to have. A couple of questions came up: - Could the prefix be dataone instead or is there a good reason to use d1ids? - The URL Pattern set for the namespace is https://cn.dataone.org/cn/v2/resolve/{{$id}}. Considering the PIRI Service <https://dataoneorg.github.io/api-documentation/services/piri_service.html>, would changing this to https://dataone.org/datasets/{{$id}} make any sense? The /resolve/ API endpoint has specific and narrow HTTP request semantics and we could probably better serve identifier resolution semantics within the PIRI service. Thoughts or other ideas? ping @datadavev <https://github.com/datadavev> @mbjones <https://github.com/mbjones>, all dev team folks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAETZYPYLFLUCKRBMN6IVSTS7RWTFANCNFSM4XZNJBTQ> .

[amoeba]

Hrm, not sure I totally follow you, @datadavev.

since we don't have an identifier scheme, but rather run a resolution service

We established an identifier scheme under https://dataone.org/datasets/ last year. Do we still like that direction? One of the big limitations of how we do identifiers in DataONE is that our bare identifiers are not HTTP-resolveable. The PIRI space fixes that but does mean we have two identifiers for every object.

this change makes sense if the overall goal is to eventually deprecate the existing service interfaces.

I see our identifier scheme as being a mostly separate thing from the service endpoints and I'm not sure how that relates to deprecating existing endpoints. Could you elaborate?

[datadavev]

Is DataONE generating the identifier value or using an identifier provided by the content creator? My impression of the PIRI service was as an alternative endpoint to the resolve endpoint.

…

On Wed, Feb 17, 2021 at 9:18 PM Bryce Mecum ***@***.***> wrote: Hrm, not sure I totally follow you, @datadavev <https://github.com/datadavev>. since we don't have an identifier scheme, but rather run a resolution service We established an identifier scheme under https://dataone.org/datasets/ last year. Do we still like that direction? One of the big limitations of how we do identifiers in DataONE is that our bare identifiers are not HTTP-resolveable. The PIRI space fixes that but does mean we have two identifiers for every object. this change makes sense if the overall goal is to eventually deprecate the existing service interfaces. I see our identifier scheme as being a mostly separate thing from the service endpoints and I'm not sure how that relates to deprecating existing endpoints. Could you elaborate? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAETZYMJFVBUII6P3Q5BLATS7R2GTANCNFSM4XZNJBTQ> .

[mbjones]

The reason I am pursuing this is that I think we need a location-independent resolution scheme for DataONE identifiers that don't have another resolution scheme. If dataone:{pid} were to resolve to https://dataone.org/datasets/{pid}, it would provide a nice, compact way for citing non-DOI identifiers that has a stable resolution URL. So I view this as a way to formalize our resolver and tie it into the well-established identifiers.org system of resolvers.

I think the d1id was a strategically poor choice -- its difficult to remember or identify. So I thought that adding another 'Resource' at the dataone prefix was a chance to update our resolution URL as well. But I also think we should update the d1id endpoint URL in the off chance that people have used it somewhere in a publication.

This would also make resolution independent of the partocular service API version that is installed, which would improve resolution stability.

[datadavev]

I agree that d1id was a poor choice for an identifier scheme label, at the time there was encouragement for brevity. In anycase, I don't doubt the benefit of a DataONE specific scheme. It is necessary for practical recognition of the many identifiers that can't be resolved except through the DataONE service. Just not sure how it's going to work, particularly with existing identifiers in DataONE. Will they all be prefixed with "dataone:"? Perhaps only some? What about a DataONE PID that looks like a DOI but doesn't resolve using the DOI infrastructure? Do we check to see if an identifier resolves according to its apparent scheme and apply a dataone: prefix if not? Perhaps the PIRI service should delegate to known resolvers, or at least advertise their availability for known identifier schemes (the http link headers are good for this)?

…

On Wed, Feb 17, 2021 at 9:39 PM Matt Jones ***@***.***> wrote: The reason I am pursuing this is that I think we need a location-independent resolution scheme for DataONE identifiers that don't have another resolution scheme. If dataone:{pid} were to resolve to https://dataone.org/datasets/{pid}, it would provide a nice, compact way for citing non-DOI identifiers that has a stable resolution URL. So I view this as a way to formalize our resolver and tie it into the well-established identifiers.org system of resolvers. I think the d1id was a strategically poor choice -- its difficult to remember or identify. So I thought that adding another 'Resource' at the dataone prefix was a chance to update our resolution URL as well. But I also think we should update the d1id endpoint URL in the off chance that people have used it somewhere in a publication. This would also make resolution independent of the partocular service API version that is installed, which would improve resolution stability. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAETZYM632CESI4WNC7YYWLS7R4WDANCNFSM4XZNJBTQ> .

[mbjones]

For DOI PIDs, we currently link the citation to the DOI resolver, but for everything else we link to the /cn/v2/view service. I was proposing that any PID in dataone would be resolvable as https://identifiers.org/dataone:{pid}, and that our citation display would switch to using that link instead of our view service URI which is currently used for non-DOI PIDs. This does raise the issue of where our resolver redirects to -- for non-DOIs, people are redirected to the view service, which is the DataONE-hosted landing page for the dataset, whereas for DOIs they are redirected to the repository-provided dataset landing page, which is typically not on DataONE. So this is an issue we should discuss for various resolvable identifier types like ARKs and handles in addition to DOIs.

[mbjones]

Oh, and as a side comment: we could switch to linking to the identifiers.org resolver for all PIDs, including DOIs and ARKs, because identifiers.org does know how to resolve those identifier types as well. So our citations might link out to:

• UUID: https://identifiers.org/dataone:urn:uuid:824df428-c711-4766-87a3-4c3b0e166941
• DOI: https://identifiers.org/doi:10.18739/A21J97859 or https://doi.org/10.18739/A21J97859
  • Not sure what we do with DOIs encoded as URLs or as just DOI names. We have many formats of DOIs in DataONE, should they all be detected and redirected consistently?
• ARK: https://identifiers.org/ark:/90135/q1416v1p/2/mrt-eml.xml
• String: https://identifiers.org/dataone:R6-x815-000-0029-0001
• URL: not sure what we should do here:
  • link to the URL itself (possibly unreliable over time)
  • link to the dataone resolver at identifiers.org, which would resolve to the DataONE landing page
• ...