Add several missing ORCiD identifiers#2909
Conversation
matentzn
left a comment
matentzn
left a comment
There was a problem hiding this comment.
Almost looks good, one ORCID to remove please.
|
precedent for adding ORCiDs to inactive records without any fuss: #2321 |
|
To my knowledge, we don't have an official procedure to cover this situation (meaning: however it was handled before was never codified). However, in February of 2022, the Operations Committee did make it a point to send a message to all ontology contact people about adding their ORCID, and each person could opt out. On that basis, I would say that's as close as we have to procedural precedent: We ask. That being said, if these ontologies were part of the Foundry in early 2022 and there is no ORCID, then it likely means they've already opted out and they should NOT be added. The question I'd have is "do we have any indication that the responsible people already opted out?" If we do, then definitely don't add. If we don't, then ask. Do we have a date for admittance to the Foundry for these ontologies? |
@nataled did we receive any "opt-outs"? these need to be documented I think. I dont think we can assume they opted out - I myself have not heard of anyone opting out, and I would not even know through which channel that would be communicated. All of these ontologies are much older, many inactive. |
|
Okay, good, we at least know that they were around back in 2022 and COULD have opted out if they wished. By the rule established in that email, failure to opt out means that the ORCID would have been added. That's the basis for the assumption they likely opted out, but there are other possibilities (see below). I could not find any opt out cases, but the only search I did was to see if anyone responded to that particular email. People might have opted out via Slack if an announcement was made that way, or some other way. I would hope we have the opt out evidence. The email was sent by @nicolevasilevsky so maybe she has a list somewhere. The fact that there is no ORCID for these can be due to multiple possibilities:
In the case of (1), hopefully we have a log of it and can put it to rest with a 'do not add'. If we don't have a log, we then have two paths. The first is to still assume they opted out and put it to rest with a 'do not add'. The second is to ask. The only downside to asking is them saying "I already answered this" and getting annoyed that we are asking again. I don't think that's such a terrible thing. In the case of (2), we have to consider that they didn't opt out because it simply didn't apply to them when asked. Now that it would apply, we would need to ask. So, overall, I think the default path forward is to ask. Only if we have concrete evidence they opted out already do we not bother because we already have the answer. |
|
Its also so annoying to elicit permissions from this precise group because they dont even have a github handled registered. Sorry @cthoyt - your call but we have a clear rule here: https://obofoundry.org/docs/SOP.html#META
and then:
|
|
Am I correct in assuming we dont have github handles for these people @cthoyt? |
|
@cthoyt just making sure you saw the last question! |
|
I went through all additions to look up their GitHub accounts. Some weren't possible to find / don't exist. The rest are annotated now. |
|
I updated the main comment of the PR to elicit reviews from everyone affected. I think we should put a timer on it though. @nataled can you help me figure out if and how we can do this according to our current SOPs? |
|
@matentzn I think the email you sent (asking people to approve) is sufficient, as is the time period indicated. However, note that the responses will be opt-IN instead of opt out, which means that an unchecked box could mean either "I don't approve" or "I haven't seen this". Given that, the safest path forward would be to add the ones that opted in, and leave out those that didn't respond. I know that's not satisfying, but consider as well that the "I haven't seen this" case could mean that the contact information we have on record is no longer monitored/accessible by the person indicated. |
|
Thanks @nataled - hmmmmkaaaaaay! I guess if I wanted to challenge this I would have to come to an OFOC meeting and argue for changing the rules. You are clearly write on the interpretation. Lets see how it goes. |
|
@matentzn you were definitely in the discussions back then, so I assume that you were okay with the process (or got outvoted). What part would you wish to challenge? |
Yes I remember, and remember to also endorse the current SOP. Sorry what I meant to say: If I know changed my mind and wanted to exempt contact information that can be obtained from the public record from opt-in (just opt-out), I'd have to request and SOP change. |
|
I did my best to represent Nico's new viewpoint (which I take to be that ORCIDs should be added by default without needed explicit consent) during today's Ops meeting. Pointed out:
The vote was to require them (there were no objections). As for adding them without verification, there was just one concern: There are cases where multiple people have the same name, so we need to do our best to ensure that the ORCID we add is actually the correct one; that would be the main reason to reach out to the person, to confirm that it’s the right ORCID. Thus, for cases where we CAN'T VERIFY using other information (for example, the ORCID entry shows the same email as the contact, or associated publications make it clear), we should still ask the person just to make sure. If that fails, we just take our chances (the sense was that it might not be such a big deal). |
Wow I did not expect that, THANKS @nataled, that is super cool! In this case, we will do this:
Next time, we dont do that - we just go with the "orcid is required" line; do due dilligence; tag the authors for the record and merge. @nataled will this be reflected in verbatim in the SOP text? |
|
I'm presuming that this is a one-time retrofit. Is that correct? The ORCID is already required for new ontologies (as reflected in the NOR form), so this shouldn't be an issue in the future. |
I think to some extent yes, but there might be a point where we need to record another item for identification which is required. So a sentence like: OBO Foundry reserves the right to populate required data elements from public sources without consent (OPT-OUT). |
Based on OBOFoundry/OBOFoundry.github.io#2909 OBO Foundry is currently going through procedural discussions on if/when to incorporate this information, but Bioregistry's governance is much more aggressive towards curating information that can be publicly found by searching GitHub or in the author lists of papers
4 participants
Reviews:
The following only via email: