Discussion on concept UCD: meta.ref.pid/ Persistend IDs and their various flavours

[Yan Grange]

Hi Mireille,

On 15/11/2021 22:09, Mireille LOUYS wrote:
> Hello Yan , hello Semantics members,
>
> Thanks for bringing this use-case .
>
> I understand you need a ucd to tag your ePIC pid column .
> In terms of content descriptor , I understand you manipulate a 
> http://meta.id 
> <http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiZlNmQ1ZTlhOWQ1YWQ5NzM3Mz02MTkyQ0NDMV85NDMwM18xNzQzOF8xJiY3MTI2YTViNjU0OTkyZmE9MTIzMyYmdXJsPWh0dHAlM0ElMkYlMkZtZXRhJTJFaWQ=> 
> .
> but it's a persistent one , defined by ePIC .
> So a general UCD for this could be
> P http://meta.pid 
> <http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiZlNmQ1ZTlhOWQ1YWQ5NzM3Mz02MTkyQ0NDMV85NDMwM18xNzQzOF8xJiY3MTI2YTViN2M0NDllZTY9MTIzMyYmdXJsPWh0dHAlM0ElMkYlMkZtZXRhJTJFcGlk> 
>     a general persistent identifier
Yes I think that is about the use case. Probably we may want to go for 
meta.ref.pid (or meta.ref.handle as I propose a bit later) to make it 
match what DOIs do. I have to admit I haven't thought through what the 
UCD is that I will use for the time being but meta.id seems appropriate 
indeed.
>
> Vizier also uses PIDs , but resolved following the doi standard. The 
> UCD here is the existing /meta.ref.doi/
> which implies this ref can be resolved according to this standard .
>
Yes. Thing is of course that the DOI resolver also resolves ePIC PIDs 
(and the other way around). So I guess if I would be using doi, that 
would functionally work even though being plain wrong :).
> The same would apply to ORCID , and we could define a new ucd :
> P    meta.ref.orcid      An pid resolved by ORCID compliant tools
Yeah, the main reason I have mentioned ORCID is because someone else 
mentioned it and I figured that data ownership is a thing and coupling 
data to an actual person makes sense. To be fair I do not have  a use 
case for this and I would look at peopele like you or Markus who 
actually have a habit of sharing data from different sources. On the 
other hand I thought: if we add pid-like entries and we think that 
meta.ref.pid is too broad, we may actually prefer a few targetted ones 
and why not put the most popular person identifier in there.
>
> It is definitely interesting to know more  about your data release and 
> what you do with these PIDs in terms of
> definition , attribution, resolver, maintenance .

So we use ePIC PIDs. Our survey will get both an ePIC PID and a DOI, 
then also there will be a data release paper (which will gets its own 
DOI). Each pointing and each file will get its own ePIC PID. The primary 
data product will then be exposed through the VO, and the ePIC PID is 
one of the columns in the table (there the UCD comes in :) ). Then each 
related dataproducts is linked through a datalink document (we have 
about a dozen datalinks per primary product). So from an attribution 
perspective we'd expect at least people using the primary data product 
to be able to also refer to the product itself by its ePIC PID. This is 
not a huge survey (at least not in terms of numbers of files) so we have 
around 10k PIDs minted for it.

Maintainance: well, we don't have much to maintain in this respect 
because our PIDs are actually aliases to PIDs from our infra provider. 
That gives them the freedom to in principle change the storage back end, 
put up warning pages in case of calamities, etc. So this is a pretty 
low-maintainance thing for us :) .

I will probably not have too much time to turn this into an official 
thing the coming week anyway so if you have more questions let me know :)

Cheers,

Yan

> Cheers, Mireille
>
> Le 09/11/2021 à 09:54, Yan Grange a écrit :
>> Hi Mireille (and semantics working group),
>>
>> I could immagine that for ORCID it should not be too hard to find a 
>> use case (maybe Markus has ideas). For me the apparant use case is 
>> simple: I've got an upcoming data release and we minted EPIC PIDs for 
>> each of our data products. I've got those in a table and I am looking 
>> for a UCD to map them. Based on what Marco says I could use a 
>> http://handle.net 
>> <http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiZmYWQ1ZWRlM2MwYWRkMDNiMz02MTkyQ0NDMV85NDMwM18xNzQzOF8xJiZjMDI2NzEwMjI0MzlmZmE9MTIzMyYmdXJsPWh0dHAlM0ElMkYlMkZoYW5kbGUlMkVuZXQ=> 
>> URL, but I think the http://handle.net 
>> <http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiZmYWQ1ZWRlM2MwYWRkMDNiMz02MTkyQ0NDMV85NDMwM18xNzQzOF8xJiZjMDI2NzEwMjI0MzlmZmE9MTIzMyYmdXJsPWh0dHAlM0ElMkYlMkZoYW5kbGUlMkVuZXQ=> 
>> part is not necessarily guaranteed to be persistent so that may 
>> actually break the idea of a PID. If you think that is useful I can 
>> give a few details on my data relase :)
>>
>> Cheers
>>
>> Yan
>>
>> On 09/11/2021 09:18, Mireille LOUYS wrote:
>>> Hi Yan , hi Semantics ,
>>>
>>> That sounds useful and reasonable to add this UCD term in the UCD 
>>> tree .
>>>
>>> I agree.
>>> Is there a use case /example that we could describe together to 
>>> include this in a VEP-UCD?
>>>
>>> many thanks,
>>> Mireille
>>>
>>> Le 08/11/2021 à 19:24, Yan Grange a écrit :
>>>> 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 
>>>>
>>>> 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
>>>>
>>>
>
> -- 
> --
> Mireille Louys,  MCF (Associate Professor)
> Centre de données CDS		IPSEO, Images, Laboratoire Icube
> Observatoire de Strasbourg	Telecom Physique Strasbourg
> 11 rue de l'Université		300, Bd Sebastien Brandt CS 10413
> F- 67000-STRASBOURG		F-67412 ILLKIRCH Cedex
> Tel: +33 3 68 85 24 34

-- 
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 --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20211119/9f1a04d7/attachment.sig>