Discussion om concept UCD: meta.ref.pid
Yan Grange
grange at astron.nl
Wed Nov 10 10:03:27 CET 2021
Heya all,
Based on the discussions (thanks Anne, Marco, Mireille). I wonder
whether I should not alter my idea a bit:
Would it be useful to introcude meta.handle (basically for anything else
than doi, but in the same ralm) and maybe at least meta.orcid (I need to
have a look at the list of UCDs again to see if there is any
person-prefix like thing). That seems to mitigate some of the worries
that Anne has (and I agree with) that it may be a bit too broad for
practical purposes
As I think I already said: the handles are probably more persistent than
the URL of the handle resolver, so encoding the resolver in a URI may
not be ideal (thoug
Cheers,
Yan
On 09/11/2021 09:38, Molinaro, Marco wrote:
> Hi Yan, Catherine, Semantics,
>
> just a really naive contribution.
>
> DOIs are based on handle.net
> <http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiZiNWIxYjAzOTFkYzI0MTExZT02MThBMzM5Ml85NDMwM180MjgwXzEmJjFjMGY3OGQxYzBmN2EzMT0xMjMzJiZ1cmw9aHR0cCUzQSUyRiUyRmhhbmRsZSUyRW5ldA==>.
> ePIC PIDs also are handle.net <
> http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiZiNWIxYjAzOTFkYzI0MTExZT02MThBMzM5Ml85NDMwM180MjgwXzEmJjFjMGY3OGQxYzBmN2EzMT0xMjMzJiZ1cmw9aHR0cCUzQSUyRiUyRmhhbmRsZSUyRW5ldA==>
> 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 http://meta.ref.pid <
> http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiZiNWIxYjAzOTFkYzI0MTE0ZT02MThBMzM5Ml85NDMwM180MjgwXzEmJjVkYWYyY2YwYjQ0NzI3YT0xMjMzJiZ1cmw9aHR0cCUzQSUyRiUyRm1ldGElMkVyZWYlMkVwaWQ=>
> (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/?dmVyPTEuMDAxJiZiNWIxYjAzOTU0ZDc0MTU2ZT02MThBMzM5Ml85NDMwM180MjgwXzEmJmZkY2YwODgxZDBmN2IyNj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZvcmNpZCUyRW9yZyUyRg==>
>
> >
> <http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiYyZjRjNTI4M2UwMTlkOGZjMz02MTg5ODM5Nl85NDMwM18zNDAzXzEmJjM4OTE5ZGE5OTEzYzA4Yj0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZvcmNpZCUyRW9yZyUyRg==>
>
> > cannot resolve a DOI; https://ror.org
> <http://mailsweeper.astron.nl:32224/?dmVyPTEuMDAxJiZiNWIxYjAzOTU0ZDc0MTU2Zj02MThBMzM5Ml85NDMwM180MjgwXzEmJjJjMWUxY2YxNjUzNzMzYz0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyb3IlMkVvcmc=>
>
> >
> <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/?dmVyPTEuMDAxJiZhYWViYTMyMDUzODUxYjFiZj02MThBMzM5Ml85NDMwM180MjgwXzEmJjVkZGY2OTMxYTRlN2EyMD0xMjMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZyYXclMkVnaXRodWJ1c2VyY29udGVudCUyRWNvbSUyRml2b2Etc3RkJTJGVUNETGlzdCUyRnYxJTJFNC1FTiUyRnVjZC1saXN0JTJFdHh0>
> >
> <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
--
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/20211110/6c821fe3/attachment-0001.sig>
More information about the semantics
mailing list