Change the representation of regulatory reactions to use 'has_small_molecule_regulator' activity

[ukemi]

Currently when we import a regulatory reaction from Reactome, we create a construct where the entity that enables the regulated reaction (RMF) binds the regulator and the binding MF regulates the RMF. We also create a process that the binding is part of to infer the regulatory process. A simple example of this can be seen in the 'Fructose catabolism' pathway.
http://noctua.geneontology.org/editor/graph/gomodel:R-HSA-70350
https://reactome.org/PathwayBrowser/#/R-HSA-70350

In this pathway, the KHK enzyme enables ketohexokinase activity that is activated by K+ and is inhibited by ADP.

• To be consistent with the latest GO_CAM modeling procedure. The binding construct can be replaced by the new has_small_molecule_regulator relations. In this case the ketohexokinase activity would has_small_molecule_activator K+ and has_small_molecule_inhibitor ADP. See the modified copy of the model here:
  http://noctua.geneontology.org/editor/graph/gomodel:62f58d8800006682
• Since the relation is restricted to small molecules, we should only allow this if the regulator has a ChEBI identifier and is not a protein (UniProt) or complex (?). For example in this reaction, R-HSA-168935, the negative regulators are a protein (DHX58) and a complex (ISG15:DDX58 conjugate). We would not want to allow these as small molecule regulators.
• We should also not allow nucleic acids as regulators. I can't put my finger on one, but they would be children of: CHEBI:33696.
• • "Pre-NOTCH Transcription and translation" looks like it has diverse polynucleotides involved in various forms of regulation. Here are two standout reactions: "Notch gene transcription" R-HSA-1912416 and "NOTCH gene translation controlled ..." R-HSA-1912412.
• • Adding to the problem, while Reactome uses ChEBI terms for various polynucleotide instances as identifiers to make these instances compliant with the REACTO ontology, we do not use CHEBI:33696 anywhere, because we were aiming for more fine-grained terms, e.g., mRNA, microRNA, dsDNA, etc.

[deustp01]

Defer from action in connection with GO-CAM build from Reactome ver 82 - do it later

[ukemi]

Checked:

• glycolysis pfk and pk- look good
• gluconeogenesis pc and fbp- look good
• RMP biosynthesis adenylosuccinate synthetase- looks good IMP dehydrogenase looks good
• Pyruvate metabolism- pyruvate kinase activity and [pyruvate dehydrogenase (lipoamide)] phosphatase activity look good
• Regulation of pyruvate dehydrogenase (PDH) complex looks good for small molecules. But see below.

[ukemi]

Shex failures, at least some of them are due to this:
geneontology/go-shapes#299

[ukemi]

@dustine32 was this only done for the import or for all the existing models? I notice that the ticket seems to include a retrofit.

[ukemi]

In this pathway, R-HSA-204174 the controller RXRA:PPARD:atRA (R-HSA-5634107_R-HSA-203946_controller) is now missing any relation to R-HSA-203946. It positively regulates it. It doesn't get the relation because it is not a small molecule. Is there a way that when a controller is a protein complex (has part some protein or set of proteins) we could infer 'enzyme activator/inhibitor activity' enabled by the complex or protein?

[dustine32]

Orphan glutathione should not even be in model R-HSA-204174. It was part of a drug rxn that was filtered out.

[ukemi]

On the June 19, 2023 'weeds' call, we made the decision to go ahead and allow the drug identifiers that are sneaking in in this load. In the future, the drugs will be tagged explicitly in the BioPax file and will be filtered in that manner rather than by identifier space. ping @deustp01 @dustine32

[ukemi]

On the June 19, 2023 'weeds' call, we decided to allow the reactions that are upstream or downstream of the main pathway to maintain the 'old'/incomplete representation of regulators. Even though this is not ideal, it puts more of the model in alignment with GO-CAM standard practice. In the future we will get feedback from the larger community about whether linking models will be done in a timely manner and if so, we will not need to represent these in the models the way they are currently represented. If the larger community does not solve this problem in a timely manner, then we will solve this problem specifically for the imports. ping @deustp01 @dustine32