On the common protocol to train snap is through MAKER annotation pipeline.
They provide a script called maker2zff. Looking at their script I realise that they use only the CDS coordinates to create Esngl, Einit, Eterm, Exon, zff features.
What would be your recommendation to better train snap?
Using CDS only is enough? Can we use exons only?
I checked zoeFeature.h, what about the other features?
Would I get a better training if I provide a zff file with Intron, UTR5, UTR3, Acceptor, Donor, Start, Stop, etc features?
Maybe most of them are compute automatically while training (i.e. start, stop, Acceptor, Donor can be deduced by exon coordinates... )
maker2zff defines Esngl, Einit, Eterm, Exon zff features based on CDS gff features, would I get a better training if I define Esngl, Einit, Eterm, Exon based on Exon gff feature and add Coding zff feature to specify which part of the exon is coding?
On the common protocol to train snap is through MAKER annotation pipeline.
They provide a script called
maker2zff. Looking at their script I realise that they use only the CDS coordinates to create Esngl, Einit, Eterm, Exon, zff features.What would be your recommendation to better train snap?
Using CDS only is enough? Can we use exons only?
I checked
zoeFeature.h, what about the other features?Would I get a better training if I provide a zff file with Intron, UTR5, UTR3, Acceptor, Donor, Start, Stop, etc features?
Maybe most of them are compute automatically while training (i.e. start, stop, Acceptor, Donor can be deduced by exon coordinates... )
maker2zffdefines Esngl, Einit, Eterm, Exon zff features based on CDS gff features, would I get a better training if I define Esngl, Einit, Eterm, Exon based on Exon gff feature and addCodingzff feature to specify which part of the exon is coding?