SwissProt EC code has wild-card

[edkerk]

trafficstars

getEnzymeCodes preferably queries SwissProt for EC code annotation and only when no match is found, it will look for EC codes annotation in KEGG. However, it is possible that the EC code annotated in SwissProt has a wild-card, but because this is still a hit the function will stop looking for alternative EC annotations elsewhere.

Example: compare this annotation of EC2.5.1.- on UniProt, while the same is annotated with EC2.5.1.31 on KEGG.

Would it make sense to let getEnzymeCodes query KEGG to find better EC codes if the SwissProt search only give a wild-carded EC code? Also I don't think the model.eccodes (or .ECNumbers for COBRA models) is queried, could this be an alternative way to provide EC codes (not sure why those aren't queried from the beginning anyway?).

[BenjaSanchez]

wrt wildcards, I agree that e.g. EC2.5.1.31 in KEGG is preferable over EC2.5.1.- in UniProt, and the pipeline should be modified accordingly :)

wrt model.eccodes or model.ECNumbers, purely historical reasons: GECKO was developed for yeast7.6, which had no EC numbers available, that is why we never implementing reading the model data. But what you suggest could be perfectly implemented as a flag readModelECnumbers=FALSE as default.

[edkerk]

Use of model-specified EC numbers is now implemented in GECKO3.