EC should be the primary prefix for EC, not eccode

[cmungall]

Everyone used EC until id.org unilaterally decided it was eccode, which nobody used. Unfortunately bioregistry inherited this from id.org and did not use the GO registry which reflected actual use

We should reverse this decision, specifically

1. Make EC primary
2. Make the preferred casing be EC not ec
3. Keep eccode as a deprecated synonym

Evidence for EC being more widespread:

• https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=%22eccode%3A3.1.1.1%22&btnG=. 0 results
• https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=%22EC%3A3.1.1.1%22&btnG= 8k results albeit most without an explicit :

The following databases all use EC

• PubChem: https://pubchem.ncbi.nlm.nih.gov/protein/EC:3.1.1.1
• GO
• Alliance of Genome Resources
• Expasy https://enzyme.expasy.org/EC/3.1.1.1
• KEGG https://www.genome.jp/dbget-bin/www_bget?ec:3.1.1.1
• RHEA https://www.rhea-db.org/rhea/?query=EC:2.2.1.6
• biolink
• any everyone else

(I am not sure I have time to do make tickets for all instances of this but EC is one of the more egregious ones. I could make a mega-ticket if it helps)

[cthoyt]

I have no opinion on this either way. Compared to the dashes discussion, I don’t think there is a ton of community disagreement on this, and there’s a lower impact on anyone who is using Bioregistry code to keep their data standardized. I’d give it a plus 1

[bgyori]

I think this is a good idea, at least in principle. If we proceed with this, a few tests, benchmarks and documentation sections will also have to be updated where EC/eccode is referenced: https://github.com/search?q=repo%3Abiopragmatics%2Fbioregistry%20eccode&type=code. It also appears in various ways in other repos like https://github.com/search?q=eccode%20repo%3Abiopragmatics%2Fpyobo%20&type=code where the current Bioregistry standard prefix is assumed.