<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&#39;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 &quot;yes&quot;)</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">&quot;domain&quot; 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&#39;t know, quite confusing.</div><div class="gmail_default" style="font-family:monospace">(I&#39;m hearing a whispered &quot;...bring the use cases...&quot;)</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 &lt;<a href="mailto:araugh@umd.edu">araugh@umd.edu</a>&gt; 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, &quot;Oh, cool! Someone has done that?&quot;, but the excitement quickly dissipated. Still, it was fun while it lasted!<div><br></div><div>The next question I would have is &quot;How is &#39;PID&#39; defined?&quot;. 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&#39;t consider our PDS product URIs to be PIDs. There&#39;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 &quot;PID&quot; 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 &lt;<a href="mailto:grange@astron.nl" target="_blank">grange@astron.nl</a>&gt; 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&#39;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>
&gt; I am confused by the comment &quot;all PIDs can in principle be resolved by <br>
&gt; all resolvers&quot;. As far as I can see this is not true. <br>
&gt; <a href="https://orcid.org/" rel="noreferrer" target="_blank">https://orcid.org/</a> <br>
&gt; &lt;<a href="http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjM4OTE5ZGE5OTEzYzA4Yj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZvcmNpZCUyRW9yZyUyRg==" rel="noreferrer" target="_blank">http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjM4OTE5ZGE5OTEzYzA4Yj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZvcmNpZCUyRW9yZyUyRg==</a>&gt; <br>
&gt; cannot resolve a DOI; <a href="https://ror.org" rel="noreferrer" target="_blank">https://ror.org</a> <br>
&gt; &lt;<a href="http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMj02MTg5ODM5Nl85NDMwM18zNDAzXzEmJmU5NDA4OWQ5MjRmYzg5MT0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyb3IlMkVvcmc=" rel="noreferrer" target="_blank">http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMj02MTg5ODM5Nl85NDMwM18zNDAzXzEmJmU5NDA4OWQ5MjRmYzg5MT0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyb3IlMkVvcmc=</a>&gt; <br>
&gt; cannot resolve an ORCID; I can&#39;t find any general resolver for ISBNs <br>
&gt; at all; and so on. Each type of PID has its own resolving scheme, and <br>
&gt; the resolver is distinct from the PID (because, of course, the <br>
&gt; resolver URLs and protocols may change, but the PID itself must not).<br>
&gt;<br>
&gt; Those resolvers are starting to talk to each (see the DataCite Commons <br>
&gt; &lt; <br>
&gt; <a href="http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyOTRiMDg5N2YyNTc5NmIwMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjU4ZjFmOWQ5MjRmYzhkNj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZjb21tb25zJTJFZGF0YWNpdGUlMkVvcmclMkY=" rel="noreferrer" target="_blank">http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyOTRiMDg5N2YyNTc5NmIwMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjU4ZjFmOWQ5MjRmYzhkNj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZjb21tb25zJTJFZGF0YWNpdGUlMkVvcmclMkY=</a>&gt; project <br>
&gt; for an example that ties DOIs to ORCIDs and RORs by following PIDs in <br>
&gt; metadata and querying the respective databases - and experience the <br>
&gt; non-trivial wait time for even a simple query response to compile), <br>
&gt; but they cannot replace each other. This is why the DataCite metadata <br>
&gt; schema requires a user to specify the PID type for each PID in the <br>
&gt; metadata.<br>
&gt;<br>
&gt; -Anne.<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Nov 8, 2021 at 1:45 PM Yan Grange &lt;<a href="mailto:grange@astron.nl" target="_blank">grange@astron.nl</a>&gt; wrote:<br>
&gt;<br>
&gt;     Hi Semantics people,<br>
&gt;<br>
&gt;     What do you think of the following concept for a UCD? Looking<br>
&gt;     forward to<br>
&gt;     your feedback!<br>
&gt;<br>
&gt;     ==============8&lt;==============<br>
&gt;<br>
&gt;     Vocabulary:<br>
&gt;     <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>
&gt;     &lt;<a href="http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZTRjNGU4NmYxNTY4NGI2Mj02MTg5ODM5Nl85NDMwM18zNDAzXzEmJmU5ODE1ZGQ4OTU4YzE4ZD0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyYXclMkVnaXRodWJ1c2VyY29udGVudCUyRWNvbSUyRml2b2Etc3RkJTJGVUNETGlzdCUyRnYxJTJFNC1FTiUyRnVjZC1saXN0JTJFdHh0" rel="noreferrer" target="_blank">http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZTRjNGU4NmYxNTY4NGI2Mj02MTg5ODM5Nl85NDMwM18zNDAzXzEmJmU5ODE1ZGQ4OTU4YzE4ZD0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyYXclMkVnaXRodWJ1c2VyY29udGVudCUyRWNvbSUyRml2b2Etc3RkJTJGVUNETGlzdCUyRnYxJTJFNC1FTiUyRnVjZC1saXN0JTJFdHh0</a>&gt;<br>
&gt;     Author: <a href="mailto:grange@astron.nl" target="_blank">grange@astron.nl</a><br>
&gt;     Date: 2021-11-08<br>
&gt;     New Term: meta.ref.pid<br>
&gt;     Action: Addition<br>
&gt;     Label: Persistent Identifier<br>
&gt;<br>
&gt;     Description: Persistent Identifier (dereferenceable)<br>
&gt;<br>
&gt;     Rationale: The current UCD list does contain a way to refer to<br>
&gt;     persistent identifiers of type DOI (meta.ref.doi). However other<br>
&gt;     persistent identifiers (e.g. EPIC PIDs, ORCIDs, etc) are not<br>
&gt;     covered by<br>
&gt;     this. Since all PIDs can in principle be resolved by all<br>
&gt;     resolvers, no<br>
&gt;     functional difference should exist between them and therefore I<br>
&gt;     propose<br>
&gt;     to inculde a general pid term in stead of having one entry per PID<br>
&gt;     type.<br>
&gt;     For backwards compatibility I propose not to change anything to<br>
&gt;     meta.ref.doi and keep it in place.<br>
&gt;<br>
&gt;     ==============8&lt;==============<br>
&gt;<br>
&gt;     Cheers,<br>
&gt;<br>
&gt;     Yan Grange<br>
&gt;<br>
&gt;     -- <br>
&gt;     My working schedule likely differs from yours. Do not feel<br>
&gt;     compelled to read or reply to my email(s) outside your office hours.<br>
&gt;<br>
&gt;     Yan Grange<br>
&gt;     SDC software developer<br>
&gt;     ASTRON<br>
&gt;     het Nederlands instituut voor radioastronomie<br>
&gt;     the Netherlands Institute for Radio Astronomy<br>
&gt;     Oude Hogeveensedijk 4<br>
&gt;     Kamer/room 1.58<br>
&gt;     7991 PD, Dwingeloo<br>
&gt;     Nederland/The Netherlands<br>
&gt;     Tel.: (+31) (0)521595796<br>
&gt;     Fax : (+31) (0)521595101<br>
&gt;     Skype: ygg-skypename<br>
&gt;<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>