Feature Request: locus_tag parameter

[nbisweden]

Feature Request: locus_tag parameter

[Juke34]

Thank you.

It could be easily implemented but I'm not sure to well understand or get the point of this option.
Currently we have the option -i SP1 and we get as result for each level1 (i.e gene) feature a locus tag like that: /locus_tag="SP1_LOCUS1" the next one will be/locus_tag="SP1_LOCUS2", then /locus_tag="SP1_LOCUS3", etc...

Let say you have in your gff3 features with ID attribute: e.g ID=MYIDX, ID=MYIDY,ID=MYIDZ.

If we introduce the parameter --use_tag_value_as_locus_tag ID you would like to end up with something like that in the EMBL file:
/locus_tag="SP1_MYIDX_1" the next one will be/locus_tag="SP1_MYIDY_2", then /locus_tag="SP1_MYIDZ_3", etc...

or like that ?
/locus_tag="MYIDX_LOCUS1" the next one will be/locus_tag="MYIDY_LOCUS2", then /locus_tag="MYIDZ_LOCUS3", etc...

The second possibility is not possible, we need a uniq prefix shared by the /locus_tag of all the features.
For the first case, we have the prefix (the most of time given by EBI and here SP1 for the example) and an incremented number that will be necessary to be sure that the /locus_tag value is uniq. The ID information will be in between, but I don't see the gain to have this information here instead of a separate field i.e: /note="ID:MYIDX"

Maybe you have think to something else ?

[Rhinogradentia]

Thank you for your fast answer.
Maybe I should explain my "problem" a bit better. I already have valid and registered unique locus_tag for each feature and just want to create an embl file based on a self created gff with new/changed annotation, which already contains those locus_tags. I don't need new IDs.

[Juke34]

Interesting case. I'm not sure it is something that will be often encountered but it can be implemented.

[Rhinogradentia]

Thank you very much!

[loraine-gueguen]

FYI: I also had self created locus_tags for each features, which I wanted to keep in the EMBL file. I formated my GFF3 file so as to have the locus_tag number (suffix) of each feature in the "locus_tag" attribute. It has worked well this way. But sure it will be more flexible with the new option --use_attribute_value_as_locus_tag parameter.