Closed Chris-Evelo closed 4 months ago
Not if the main database did not do this themselves (and I know from experience that identifiers.org is outdated on this matter). So, that would mean we would need to check each database manually for now (which is not what we should be putting our time into I think).
Is it worth contacting identifiers.org? Maybe we can at least share the workload?
Is it worth contacting identifiers.org? Maybe we can at least share the workload?
I did do that before (through Nick Juty for example), but I was told that databases themselves should ask for updates. I also don't think it's our responsibility to keep identifiers.org up to date, especially since they only have a webpage contact point, not a GitHub repo for example. If we could make PRs against their data, we could also get some recognition for our work (that's at least how @egonw is now providing ChEBI with updates).
Nick no longer works for indentifiers.org. I don't understand their comment about "the databases themselves" the databases are not their users.
As far as I know, Henning Hermjakob leads the project and he is a collaborator in several other projects, including Reactome. We are kind of expected to keep the different interoperability resources connected and it isn't too effective is BridgeDb support mappings for which identifiers.org does not support the resolution. I agree about the credit argument. We could also make that in the interoperability platform. I think it would be good for RIRs in general if they were n Github. But I was, first of all, aiming a sharing the workload.
@Chris-Evelo are you aware of the Bioregistry project? We're trying to solve some of the long-standing issues with the closed/unresponsive/incomplete registries and resolvers (https://github.com/biopragmatics/bioregistry, https://bioregistry.io)
I am going to close this one. I fixed a few today. Please file pull requests for updates. If you replace http://
with https://
, please make sure the links work. In the updates today, I found two data sources to longer work (see commits).
I browsed the new tsv files and saw that there are many non-https addresses in there. Probably quite a few of these can be replaced.