ivoa-std / VOResource

Creative Commons Attribution Share Alike 4.0 International
0 stars 1 forks source link

altIdentifier DOI form #9

Open BaptisteCecconi opened 2 months ago

BaptisteCecconi commented 2 months ago

The current version of the text is stating to use the doi:10.NNNN/abcd form instead of the full https URI. However, the DataCite and CrossRef display guidelines are both clearly stating that the https URI form should be used as much possible.

So, according to the paragraph at lines 540-543, we should update the text and recommend the use of the https://doi.org/... form.

I can propose a PR, if we want.

msdemlei commented 2 months ago

On Mon, May 20, 2024 at 05:04:45PM -0700, Baptiste Cecconi wrote:

The current version of the text is stating to use the doi:10.NNNN/abcd form instead of the full https URI. However, the DataCite and CrossRef display guidelines are both clearly stating that the https URI form should be used as much possible.

So, according to the paragraph at lines 540-543, we should update the text and recommend the use of the https://doi.org/... form.

No, let's not do it. Whatever reasons Datacite and Crossref have for their recommendation, I argue that for RegTAP it is much more important to have clear and simple rules on how to figure out the type of an identifier (and "it's always doi:" is a lot better than "startswith https://doi.org, but it could be doi:, too, and historically, http://dx.doi.org is conceivable, too"). What clients do to present these DOIs is then up to them, and it's trivial for them to return "https://doi.org/"+alt_identifier[4:].

I mention in passing that I think baked-in resolver URLs isn't a great recommendation anyway; in effect, they suggest there is and can only be one DOI resolver, and that's something I'm deeply skeptical about as a matter of principle.

So... can we close as WONTFIX?

BaptisteCecconi commented 2 months ago

Well then, there should be an update of the text. The reason of using the doi: prefix is internal, not related to external recommendation. The same should be applied to orcid, then I guess, if we want to be consistent.

We should also add a paragraph on how to resolve each prefix to http URI.

msdemlei commented 2 months ago

On Mon, May 20, 2024 at 07:55:12PM -0700, Baptiste Cecconi wrote:

Well then, there should be an update of the text. The reason of using the doi: prefix is internal, not related to external recommendation. The same should be applied to orcid, then I guess, if we want to be consistent.

The trouble is that orcid already had the odious requirement for having the resolver baked in, and I figured we cannot ignore a MUST in their spec, as much as I loathe it. But then nobody puts orcids into the VO anyway (which I'm actually happy about).

As to justifying what we do, there is this in current VOResource:

In order to not bind the Registry to any single resolver, we prefer non-http URI forms for such identifiers. Where the originators of the identifier scheme strongly urges the use http URIs directly pointing to a resolver, we adopt these conventions.

I may have to admit that these days DOI operators fall under the "strongly urge" category, but frankly I'm reluctant to have their desire for behavioural surplus (or for whatever other reason they're trying to force people onto their resolver) introduce (mildly) breaking changes into our specs.

Anyway: doesn't this text roughly convey what you'd like to see said? Saying something like "but show your users https://doi.org/10.5072/7273288 rather doi:10.5072/7273288" doesn't feel quite right to me, in particular because I think most publishers, like me, even now prefer the latter form.

We should also add a paragraph on how to resolve each prefix to http URI.

Hm... do you really believe that's appropriate material for a spec? After all, people might build alternative resolvers, for instance, and there may be very good reasons to prefer those. My instinct would be that if you're interested in some kind of persistent identifier you probably know what to do with it.