Discussion om concept UCD: meta.ref.pid

[Markus Demleitner]

Hi Yan,

On Wed, Nov 10, 2021 at 10:03:27AM +0100, Yan Grange wrote:
> Based on the discussions (thanks Anne, Marco, Mireille). I wonder whether I
> should not alter my idea a bit:
> 
> Would it be useful to introcude meta.handle (basically for anything else
> than doi, but in the same ralm) and maybe at least meta.orcid (I need to
> have a look at the list of UCDs again to see if there is any person-prefix
> like thing). That seems to mitigate some of the worries that Anne has (and I
> agree with) that it may be a bit too broad for practical purposes

If we go that way, it probably should be meta.ref.handle and
meta.ref.orcid, respectively.

The advantage of those more special terms would be that clients could
figure out where to resolve these identifiers *from the UCD*, which
they couldn't (without further information or convention) with
meta.ref.pid.  The disadvantage is that we'll need a new UCD for each
kind of PID we'd like to support.

I can't say I have a strong leaning one way or the other.  In an
ideal world, I'd ask over at apps whether anyone would actually
produce the buttons for meta.ref.orcid...

> As I think I already said: the handles are probably more persistent than the
> URL of the handle resolver, so encoding the resolver in a URI may not be
> ideal (thoug

Oh, I've not talked about writing these identifiers as HTTP URIs,
which I can't say I'm a big fan of either, although everyone seems to
be doing it these days.  

No, the URI form is what's supposed to be in VOResource's
altIdentifier, where a PID scheme corresponds to a URI scheme, as in
doi:10.21938/AvlnaD4AvIeK9nIscpF.YA or orcid:0000-0002-1891-3794
(both of these ought to be valid URIs, as I think these schemes
actually exist).  With this, clients are free to use whatever
resolver they prefer without having to parse HTTP URIs, and it's
always a good thing to avoid forcing people onto specific machines.

But I digress...

           -- Markus