Discussion om concept UCD: meta.ref.pid

[Anne Catherine Raugh]

No worries, Yan! For a moment I thought, "Oh, cool! Someone has done
that?", but the excitement quickly dissipated. Still, it was fun while it
lasted!

The next question I would have is "How is 'PID' defined?". For example,
every PDS product has a unique URI created by PDS, and if you type it into
a PDS search you can, theoretically at least, get straight to the
associated product. But although our archive will persist for generations,
I still wouldn't consider our PDS product URIs to be PIDs. There's a level
of broad acceptance and independence from the individual publisher or
curator that things I think of as PIDs have, that the PDS URIs do not.

Which is a very long-winded way of saying I would be concerned that too
broad a definition of "PID" would invite poor usage and complicate the
process of locating those things I do think of as PIDs.

Perhaps I worry too much...

-Anne.


On Mon, Nov 8, 2021 at 3:23 PM Yan Grange <grange at astron.nl> wrote:

> Dear Anne,
>
> That is a good catch. That was a remainder from the first version where
> I didn't realise the broadness of the PIDs. Also because the concrete
> application I had to want to request this was because my data has EPIC
> PIDs, which obviously are not DOIs. I think my realisation of the broad
> application of PIDs was not even complete, but this seems to me more
> like an argument to not only have one specific implementation of PIDs in
> the UCDs, and not at least a general one.
>
> So I thank you for pointing that out, ask the working group to ignore
> that sentence, and apologise for the confusion I caused :).
>
> Cheers,
>
> Yan
>
> On 08/11/2021 21:07, Anne Catherine Raugh wrote:
> > I am confused by the comment "all PIDs can in principle be resolved by
> > all resolvers". As far as I can see this is not true.
> > https://orcid.org/
> > <
> http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjM4OTE5ZGE5OTEzYzA4Yj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZvcmNpZCUyRW9yZyUyRg==>
>
> > cannot resolve a DOI; https://ror.org
> > <
> http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMj02MTg5ODM5Nl85NDMwM18zNDAzXzEmJmU5NDA4OWQ5MjRmYzg5MT0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyb3IlMkVvcmc=>
>
> > cannot resolve an ORCID; I can't find any general resolver for ISBNs
> > at all; and so on. Each type of PID has its own resolving scheme, and
> > the resolver is distinct from the PID (because, of course, the
> > resolver URLs and protocols may change, but the PID itself must not).
> >
> > Those resolvers are starting to talk to each (see the DataCite Commons
> > <
> >
> http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyOTRiMDg5N2YyNTc5NmIwMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjU4ZjFmOWQ5MjRmYzhkNj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZjb21tb25zJTJFZGF0YWNpdGUlMkVvcmclMkY=> project
>
> > for an example that ties DOIs to ORCIDs and RORs by following PIDs in
> > metadata and querying the respective databases - and experience the
> > non-trivial wait time for even a simple query response to compile),
> > but they cannot replace each other. This is why the DataCite metadata
> > schema requires a user to specify the PID type for each PID in the
> > metadata.
> >
> > -Anne.
> >
> >
> > On Mon, Nov 8, 2021 at 1:45 PM Yan Grange <grange at astron.nl> wrote:
> >
> >     Hi Semantics people,
> >
> >     What do you think of the following concept for a UCD? Looking
> >     forward to
> >     your feedback!
> >
> >     ==============8<==============
> >
> >     Vocabulary:
> >
> https://raw.githubusercontent.com/ivoa-std/UCDList/v1.4-EN/ucd-list.txt
> >     <
> http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZTRjNGU4NmYxNTY4NGI2Mj02MTg5ODM5Nl85NDMwM18zNDAzXzEmJmU5ODE1ZGQ4OTU4YzE4ZD0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyYXclMkVnaXRodWJ1c2VyY29udGVudCUyRWNvbSUyRml2b2Etc3RkJTJGVUNETGlzdCUyRnYxJTJFNC1FTiUyRnVjZC1saXN0JTJFdHh0
> >
> >     Author: grange at astron.nl
> >     Date: 2021-11-08
> >     New Term: meta.ref.pid
> >     Action: Addition
> >     Label: Persistent Identifier
> >
> >     Description: Persistent Identifier (dereferenceable)
> >
> >     Rationale: The current UCD list does contain a way to refer to
> >     persistent identifiers of type DOI (meta.ref.doi). However other
> >     persistent identifiers (e.g. EPIC PIDs, ORCIDs, etc) are not
> >     covered by
> >     this. Since all PIDs can in principle be resolved by all
> >     resolvers, no
> >     functional difference should exist between them and therefore I
> >     propose
> >     to inculde a general pid term in stead of having one entry per PID
> >     type.
> >     For backwards compatibility I propose not to change anything to
> >     meta.ref.doi and keep it in place.
> >
> >     ==============8<==============
> >
> >     Cheers,
> >
> >     Yan Grange
> >
> >     --
> >     My working schedule likely differs from yours. Do not feel
> >     compelled to read or reply to my email(s) outside your office hours.
> >
> >     Yan Grange
> >     SDC software developer
> >     ASTRON
> >     het Nederlands instituut voor radioastronomie
> >     the Netherlands Institute for Radio Astronomy
> >     Oude Hogeveensedijk 4
> >     Kamer/room 1.58
> >     7991 PD, Dwingeloo
> >     Nederland/The Netherlands
> >     Tel.: (+31) (0)521595796
> >     Fax : (+31) (0)521595101
> >     Skype: ygg-skypename
> >
> --
> My working schedule likely differs from yours. Do not feel compelled to
> read or reply to my email(s) outside your office hours.
>
> Yan Grange
> SDC software developer
> ASTRON
> het Nederlands instituut voor radioastronomie
> the Netherlands Institute for Radio Astronomy
> Oude Hogeveensedijk 4
> Kamer/room 1.58
> 7991 PD, Dwingeloo
> Nederland/The Netherlands
> Tel.: (+31) (0)521595796
> Fax : (+31) (0)521595101
> Skype: ygg-skypename
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20211108/a4e80dc5/attachment-0001.html>