Genetic codes and other repeated ACD
gbottu at ben.vub.ac.be
Wed Apr 13 13:22:12 UTC 2005
Dear Peter, dear all,
Allow me to add something to the recent discussion about geneticcodes. I
talked about it with Marc Colet, developer of wEMBOSS, and he considers,
for the sake of GUI maintenance, that it is better to avoid making the ACD
syntax too complicated and certainly to avoid making too often a change.
A few ideas :
- Currently emboss.defaults does not contain items that are absolutely
needed. We think it is better not to change that philosophy by putting
e.g. the geneticcodes in it. It could however be an idea to put in
emboss.defaults a list of databanks in BLAST format, for the sake of BLAST
- For items like reading frames and maybe geneticcodes, that appear over
and over again in several ACD files, yet are not user or installation
customizable, the best proposal among those made in this discussion list
seems to me to have it defined in one central file, for the purpose of the
software developement, but to "acdpretty" it into the ACD files before
they are distributed, for the sake of GUI functioning.
- There is the case of items where users can choose to use their own data
instead of the EMBOSS distribution data, like symbol comparison matrices
and codon usage tables (would genetic codes fall into this catagory ?).
Till now there was each time a new ACD object type defined, like matrix
and cfile. Is shifting to the use of "knowntype" a good idea ? I do not
know, but, let's keep consistent.
- There is the issue of the program embossdata, useful for the advanced
user and a possible tool for displaying choice lists in GUI's. Currently,
when we run it at the BEN site with just the parameter -showall it produces a
monstruous long list, because all the databanks (including CUTG) have been
downloaded and "extracted". Maybe let it by default display only the data
files in the main data directory ? Note that e.g. the list of PRINTS files
is anyway not very interesting, since you cannot do anything with them as
such. Could it be modified so that you can easily get a list of the
alternative data files used by a particular program (or could a library
routine called by the program itself do that) ?
More information about the emboss-dev