You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 22, 2023. It is now read-only.
Hey @gorkang 👋 Thanks for taking the time to report this issue and welcome to the repo!
These kind of DOIs are horrible - I am glad they standardized them at some point. There's a bit more information on it in this CrossRef blog from 2015.
We could add the handling of fallback regular expressions to increase coverage, specifically in this order (taken from the CrossRef blog)
I know we're still looking for some funds to upgrade the OpenRetractions database behind this, so this isn't high priority on my end right now (funding remains an issue with these things...). Had a few attempts but nothing stuck just yet.
Yes, the DOIs are as horrible as they come... thanks for the CrossRef blog post.
No urgent need at all. I am using find_doi() in a package to help automatically download all the references from papers ({downloadReferences}) and stumbled upon these weird DOI's.
Good luck finding funding.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi there,
Pretty sure this is because the journal is using non-standard DOI's, but wanted to let you know, in case there is a "simple fix" for these.
So, in some instances,
find_doi()
does not extract the full DOI. For example:https://onlinelibrary.wiley.com/doi/10.1002/(SICI)1097-0258(19970515)16:9%3C981::AID-SIM510%3E3.0.CO;2-N
retractcheck::find_doi("10.1002/(sici)1097-0258(19970515)16:9<981::aid-sim510>3.0.co;2-n")
Some other cases:
Thanks for the awesome package.
The text was updated successfully, but these errors were encountered: