Discussion om concept UCD: meta.ref.pid

Tue Nov 9 09:38:26 CET 2021

Hi Yan, Catherine, Semantics,

just a really naive contribution.

DOIs are based on handle.net.
ePIC PIDs also are handle.net themselves.

So are many others.

Most PIDs are URIs (handles included).
IVOIDs, e.g., are URIs.

I'm thus wondering if adding new UCDs
for handle.derived PIDs is a good choice
(as of now I would lean towards "yes")
or if something else will be needed in
the future.

Could it work something like... ?

P meta.ref.uri (already there)

with

meta.ref.doi - meta.ref.epic - etc...

as S words?
(means moving towards meta.ref.uri;meta.ref.doi)

keeping meta.ref.ivoid as Q for
"domain" reasons?

Unfortunately meta.ref.doi,
currently a P word, complicates
things...

Don't know, quite confusing.
(I'm hearing a whispered "...bring the use cases...")

Maybe adding meta.ref.pid (Q?, S?, P?)
would suffice.

Cheers
    Marco

Il giorno lun 8 nov 2021 alle ore 22:23 Anne Catherine Raugh <araugh at umd.edu>
ha scritto:

> 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
>>
>>

-- 
Marco Molinaro
INAF - Istituto Nazionale di AstroFisica
Osservatorio Astronomico di Trieste
email marco.molinaro at inaf.it
tel. [+39] 333 33 20 564 / 040 3199 152
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20211109/29d36ea9/attachment.html>