<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hi Yan, Catherine, Semantics,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">just a really naive contribution.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">DOIs are based on <a href="http://handle.net">handle.net</a>.</div><div class="gmail_default" style="font-family:monospace">ePIC PIDs also are <a href="http://handle.net">handle.net</a> themselves.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">So are many others.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Most PIDs are URIs (handles included). </div><div class="gmail_default" style="font-family:monospace">IVOIDs, e.g., are URIs.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I'm thus wondering if adding new UCDs</div><div class="gmail_default" style="font-family:monospace">for handle.derived PIDs is a good choice</div><div class="gmail_default" style="font-family:monospace">(as of now I would lean towards "yes")</div><div class="gmail_default" style="font-family:monospace">or if something else will be needed in </div><div class="gmail_default" style="font-family:monospace">the future.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Could it work something like... ?</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">P meta.ref.uri (already there)</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">with</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">meta.ref.doi - meta.ref.epic - etc... </div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">as S words?</div><div class="gmail_default" style="font-family:monospace">(means moving towards meta.ref.uri;meta.ref.doi)</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">keeping meta.ref.ivoid as Q for </div><div class="gmail_default" style="font-family:monospace">"domain" reasons?</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Unfortunately meta.ref.doi, </div><div class="gmail_default" style="font-family:monospace">currently a P word, complicates </div><div class="gmail_default" style="font-family:monospace">things...</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Don't know, quite confusing.</div><div class="gmail_default" style="font-family:monospace">(I'm hearing a whispered "...bring the use cases...")</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Maybe adding meta.ref.pid (Q?, S?, P?)</div><div class="gmail_default" style="font-family:monospace">would suffice.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Cheers</div><div class="gmail_default" style="font-family:monospace"> Marco</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno lun 8 nov 2021 alle ore 22:23 Anne Catherine Raugh <<a href="mailto:araugh@umd.edu">araugh@umd.edu</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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!<div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Perhaps I worry too much...</div><div><div><br><div><div><div dir="ltr"><div dir="ltr">-Anne.</div></div></div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 8, 2021 at 3:23 PM Yan Grange <<a href="mailto:grange@astron.nl" target="_blank">grange@astron.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Anne,<br>
<br>
That is a good catch. That was a remainder from the first version where <br>
I didn't realise the broadness of the PIDs. Also because the concrete <br>
application I had to want to request this was because my data has EPIC <br>
PIDs, which obviously are not DOIs. I think my realisation of the broad <br>
application of PIDs was not even complete, but this seems to me more <br>
like an argument to not only have one specific implementation of PIDs in <br>
the UCDs, and not at least a general one.<br>
<br>
So I thank you for pointing that out, ask the working group to ignore <br>
that sentence, and apologise for the confusion I caused :).<br>
<br>
Cheers,<br>
<br>
Yan<br>
<br>
On 08/11/2021 21:07, Anne Catherine Raugh wrote:<br>
> I am confused by the comment "all PIDs can in principle be resolved by <br>
> all resolvers". As far as I can see this is not true. <br>
> <a href="https://orcid.org/" rel="noreferrer" target="_blank">https://orcid.org/</a> <br>
> <<a href="http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjM4OTE5ZGE5OTEzYzA4Yj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZvcmNpZCUyRW9yZyUyRg==" rel="noreferrer" target="_blank">http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjM4OTE5ZGE5OTEzYzA4Yj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZvcmNpZCUyRW9yZyUyRg==</a>> <br>
> cannot resolve a DOI; <a href="https://ror.org" rel="noreferrer" target="_blank">https://ror.org</a> <br>
> <<a href="http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMj02MTg5ODM5Nl85NDMwM18zNDAzXzEmJmU5NDA4OWQ5MjRmYzg5MT0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyb3IlMkVvcmc=" rel="noreferrer" target="_blank">http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMj02MTg5ODM5Nl85NDMwM18zNDAzXzEmJmU5NDA4OWQ5MjRmYzg5MT0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyb3IlMkVvcmc=</a>> <br>
> cannot resolve an ORCID; I can't find any general resolver for ISBNs <br>
> at all; and so on. Each type of PID has its own resolving scheme, and <br>
> the resolver is distinct from the PID (because, of course, the <br>
> resolver URLs and protocols may change, but the PID itself must not).<br>
><br>
> Those resolvers are starting to talk to each (see the DataCite Commons <br>
> < <br>
> <a href="http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyOTRiMDg5N2YyNTc5NmIwMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjU4ZjFmOWQ5MjRmYzhkNj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZjb21tb25zJTJFZGF0YWNpdGUlMkVvcmclMkY=" rel="noreferrer" target="_blank">http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyOTRiMDg5N2YyNTc5NmIwMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjU4ZjFmOWQ5MjRmYzhkNj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZjb21tb25zJTJFZGF0YWNpdGUlMkVvcmclMkY=</a>> project <br>
> for an example that ties DOIs to ORCIDs and RORs by following PIDs in <br>
> metadata and querying the respective databases - and experience the <br>
> non-trivial wait time for even a simple query response to compile), <br>
> but they cannot replace each other. This is why the DataCite metadata <br>
> schema requires a user to specify the PID type for each PID in the <br>
> metadata.<br>
><br>
> -Anne.<br>
><br>
><br>
> On Mon, Nov 8, 2021 at 1:45 PM Yan Grange <<a href="mailto:grange@astron.nl" target="_blank">grange@astron.nl</a>> wrote:<br>
><br>
> Hi Semantics people,<br>
><br>
> What do you think of the following concept for a UCD? Looking<br>
> forward to<br>
> your feedback!<br>
><br>
> ==============8<==============<br>
><br>
> Vocabulary:<br>
> <a href="https://raw.githubusercontent.com/ivoa-std/UCDList/v1.4-EN/ucd-list.txt" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/ivoa-std/UCDList/v1.4-EN/ucd-list.txt</a><br>
> <<a href="http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZTRjNGU4NmYxNTY4NGI2Mj02MTg5ODM5Nl85NDMwM18zNDAzXzEmJmU5ODE1ZGQ4OTU4YzE4ZD0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyYXclMkVnaXRodWJ1c2VyY29udGVudCUyRWNvbSUyRml2b2Etc3RkJTJGVUNETGlzdCUyRnYxJTJFNC1FTiUyRnVjZC1saXN0JTJFdHh0" rel="noreferrer" target="_blank">http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZTRjNGU4NmYxNTY4NGI2Mj02MTg5ODM5Nl85NDMwM18zNDAzXzEmJmU5ODE1ZGQ4OTU4YzE4ZD0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyYXclMkVnaXRodWJ1c2VyY29udGVudCUyRWNvbSUyRml2b2Etc3RkJTJGVUNETGlzdCUyRnYxJTJFNC1FTiUyRnVjZC1saXN0JTJFdHh0</a>><br>
> Author: <a href="mailto:grange@astron.nl" target="_blank">grange@astron.nl</a><br>
> Date: 2021-11-08<br>
> New Term: meta.ref.pid<br>
> Action: Addition<br>
> Label: Persistent Identifier<br>
><br>
> Description: Persistent Identifier (dereferenceable)<br>
><br>
> Rationale: The current UCD list does contain a way to refer to<br>
> persistent identifiers of type DOI (meta.ref.doi). However other<br>
> persistent identifiers (e.g. EPIC PIDs, ORCIDs, etc) are not<br>
> covered by<br>
> this. Since all PIDs can in principle be resolved by all<br>
> resolvers, no<br>
> functional difference should exist between them and therefore I<br>
> propose<br>
> to inculde a general pid term in stead of having one entry per PID<br>
> type.<br>
> For backwards compatibility I propose not to change anything to<br>
> meta.ref.doi and keep it in place.<br>
><br>
> ==============8<==============<br>
><br>
> Cheers,<br>
><br>
> Yan Grange<br>
><br>
> -- <br>
> My working schedule likely differs from yours. Do not feel<br>
> compelled to read or reply to my email(s) outside your office hours.<br>
><br>
> Yan Grange<br>
> SDC software developer<br>
> ASTRON<br>
> het Nederlands instituut voor radioastronomie<br>
> the Netherlands Institute for Radio Astronomy<br>
> Oude Hogeveensedijk 4<br>
> Kamer/room 1.58<br>
> 7991 PD, Dwingeloo<br>
> Nederland/The Netherlands<br>
> Tel.: (+31) (0)521595796<br>
> Fax : (+31) (0)521595101<br>
> Skype: ygg-skypename<br>
><br>
-- <br>
My working schedule likely differs from yours. Do not feel compelled to read or reply to my email(s) outside your office hours.<br>
<br>
Yan Grange<br>
SDC software developer<br>
ASTRON<br>
het Nederlands instituut voor radioastronomie<br>
the Netherlands Institute for Radio Astronomy<br>
Oude Hogeveensedijk 4<br>
Kamer/room 1.58<br>
7991 PD, Dwingeloo<br>
Nederland/The Netherlands<br>
Tel.: (+31) (0)521595796<br>
Fax : (+31) (0)521595101<br>
Skype: ygg-skypename<br>
<br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><font face="monospace">Marco Molinaro</font></div><div><font face="monospace">INAF - Istituto Nazionale di AstroFisica</font></div><div><font face="monospace">Osservatorio Astronomico di Trieste</font></div><div><font face="monospace">email <a href="mailto:marco.molinaro@inaf.it" target="_blank">marco.molinaro@inaf.it</a></font></div><div><span style="font-family:monospace">tel. [+39] 333 33 20 564 / 040 3199 152</span><br></div></div></div></div></div></div></div>