[maker-devel] How to preserve human-friendly IDs when reannotating

[Jeremy Semeiks]

Hi all,

I have sequenced some novel fungal genomes, and I am annotating them with
maker-2.26-beta. The entire project is pretty iterative, in the sense that
I first get some seemingly-sane annotation sets, then analyze and compare
the proteomes biologically, then reannotate when new data comes in or as I
learn more about how maker works. Because I have already attached
biological meaning to some of my proteins, I would like to retain the same
human-friendly IDs across annotations. Eg, if maker suddenly finds 1,000
new proteins on a reannotation run because I turned on keep_preds, then I
don't want the transcript formerly known as mymold_09652T0 to become
mymold_10698T0 when I run maker_map_ids; I want to keep it named
mymold_09652T0.

So, is there any built-in way to preserve human-friendly IDs, or do I need
to write my own script for this? I have tried setting map_forward=1 and
maker_gff=<the GFF file output by the previous run of maker_map_ids>, but
setting these seems to preserve neither the human-friendly IDs nor even the
original IDs. (Eg, protein "genemark-scaffold353-processed-gene-0.9-mRNA-1"
changed its name to "genemark-scaffold353-processed-gene-0.6-mRNA-1" when
reannotated.) I haven't turned on any of the *_pass options, eg
protein_pass; would this be relevant?

Extra credit question: I am making some mate-pair libraries for these
fungi; when I re-assemble, that will completely change my scaffold names.
Is there any easy way to preserve human-friendly transcript names in this
case? As with the above simpler case, I think it would be pretty easy to
transfer 90% of the names just by doing an all-vs-all blastp between two
annotation sets and fishing out the best hits, but the remaining 10% might
be a headache.

Thanks,
Jeremy
Grad student, Grishin lab
UT Southwestern, Dallas TX
510.385.8959
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20120909/37bed64f/attachment-0002.html>