enrich-via-doi: Filtering for ORCIDs based on creator #8
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
An observation for @msz:
I wanted to reuse
process_orcidfrom enrich-via-doi.py.def process_orcid(person: dict) -> str | None:"""Return an ORCID from identifiers"""for identifier in person.get("identifiers", []):if pid_of(identifier.get("creator")) == "ror:04fa4r544":return identifier.get("notation")I realized when my script was generating a weirdly large amount of new person records (which it attempts when it does not find an author by their ORCID returned from this function) that the lookup's conditional
if pid_of(identifier.get("creator")) == "ror:04fa4r544":filters out the majority of ORCID records from the PsyInf pool (there are 7 people in the Psyinf pool where the identifier has this key, versus 30 when I filter usingif pid_of(identifier.get("schema_type")) == "xyzri:ORCID":instead.I don't know why, but my best guess is that some wizard / convenience feature of shacl-vue simply does not add such a creator anymore. I did not investigate the impact in the TRR Pool and on the script, but want to briefly ping you, in case this sounds like it could be relevant.
If on the other hand you know of a reason why my conditional is suboptimal or the
creatorconditional strictly needed, I'd appreciate insights. :)Thanks. A general comment without looking at any of the records is that checking the creator against a specific ror: compact URI indeed assumes that the creator property is present, but also that it uses ror (and not grid, isni, or wikidata which btw can be found in ror.org records). But checking schema type against a specific class xyzri:ORCID also assumes that the class uses a specific name, including prefix (which I guess could be configurable, I think TRR might be using a different one). Goes to show my enricher wasn't robust enough.
Perhaps there should be a function
is_orcid()which could perform several checks for better robustness and reusability.Also, one may wonder whether it's better to try and inline the creator for more information.