How to better document deprecated met/rxn ids

[haowang-bioinfo]

The current workflow is becoming inadequate with the increasing curation amount, and an upgraded workflow with "merge queue" feature might be needed.

Ideas and suggestions are welcome.

[feiranl]

Should we introduce ChatGPT to help us to have a first check? I am not sure wether this will work, but basically just like the chatbot currently used in other websites. If the issue is well described and the ChatGPT can help us to first check wether the issue and proposed solution is ok? but then this required the person who raises the issue and solution very well. Then as for the merge of PR, we need to have more tasks such as organ-specific tasks. But I am not sure wether the server load can handle. @mihai-sysbio

[mihai-sysbio]

Should we introduce ChatGPT to help us to have a first check? I am not sure wether this will work, but basically just like the chatbot currently used in other websites. If the issue is well described and the ChatGPT can help us to first check wether the issue and proposed solution is ok?

I've done some investigation in #483 . In summary, so far ChatGTP tends to imagine too much for it to be considered accurate. So far I haven't managed to phrase questions so as to obtain concrete, reference-backed answers, that would be better than an API request from a specialised service.

[haowang-bioinfo]

sounds good, any specific plan do you have? @feiranl

[feiranl]

Besides this, should we also give one report for every major release? such as summaries all changes and reasons in one txt file. I am recently working on the organ-specific tasks, but found many reactions are deprecated, but the reason for them are dispersed in the many issues pages. So I want to propose a report file for each major release. So if we combine all reports, then we can clearly see all model changes.
I can give one example:

ELAIDCRNtr(rxn in Recon3D model) was identified as a metabolic essential Task, however, this one matched Human-GEM rxn MAR11269 which was removed in #344, since it is a duplicate with MAR10178. Without manual check, it is difficult for me to identify the ELAIDCRNtr should mapped to MAR10178.
@Devlin-Moyer the recent PR also removed many duplicates, so it is great to merge all annotations and cross references.

[haowang-bioinfo]

in fact, by a quick looking, it's found that most of the pending PRs are resolving duplicate mets and rxns, a scenario highly relevant to the topic here

actually, across the accumulated 300+ PRs, many are also resolving duplicate mets and rxns.

[haowang-bioinfo]

we are adding the retired Human-GEM IDs due to duplicates to the retireID, somehow to document this a little bit.

yes, this is straightforward solution, i.e. a natural selection. Because rxnRetired, metRetired for mets, is an existing column, one can just append duplicated ids to the end and delimted by ;. This probably can be implemented right away in the pending PRs? @feiranl @mihai-sysbio @Devlin-Moyer

[haowang-bioinfo]

one could add a column with the issue numbers where that line was last edited. This part can indeed be scripted with a GH action.

this could be a nice feature.

[Devlin-Moyer]

Oh yea that does make sense; I never touched that column because I wasn't 100% sure what it was for (my guess was that at some point you changed the general format of IDs and reassigned a bunch of metabolite/reaction IDs without changing anything about the metabolites or reactions themselves) but I can definitely start doing that
So far, I'd been trying to put the "removed _ for being a duplicate of _" in the commit or PR messages, but I agree that the retired columns would be a much nicer way to systematically record that

[haowang-bioinfo]

a tentative implementation was made in #666 as an example, any feedback is welcome

[mihai-sysbio]

Another slightly different idea when doing curation is to have a script that fetches all the commit hashes and timestamps for each reaction/metabolite in the model.

[haowang-bioinfo]

sounds good - go ahead please

[edkerk]

As a sort of blame?

[mihai-sysbio]

Yes. It can take a bit to blame Human-GEM.yml (314k lines), but anyways sifting through that output is really not that useful, since some edits can affect only formatting and not content.