[emboss-dev] Problems with EMBOSS seqret GenBank to GFF3
pmr at ebi.ac.uk
Tue Aug 30 15:48:25 UTC 2011
On 08/26/2011 03:27 AM, Peter Cock wrote:
> On Thu, Aug 25, 2011 at 2:52 PM, Peter Rice<pmr at ebi.ac.uk> wrote:
>> On 25/08/2011 01:44, Peter Cock wrote:
> It would make sense to propose that the first line has all the annotation,
> and the subsequence lines from the same feature just need the ID,
> and if it is adopted the part tag recently discussed on the song-devel
> list to make the order of the sub-parts explicit.
The part tag is interesting and would map to the internal "exon"
attribute in EMBOSS which we reserve for sorting.
>> I think we'll go with the annotation of the "biological_region" parent and
>> wait for anyone with a use case that actually requires massively replicated
> Have you looked at the BioPerl GenBank to GFF3 conversion?
> I understand GBrowse recommends this as a way to get
> GenBank format data into GBrowse. I'm also pretty sure that
> this is being used inside TogoWS for GenBank/EMBL to GFF3:
> http://togows.dbcls.jp/entry/embl/V00508<-- original EMBL
> http://togows.dbcls.jp/entry/embl/V00508.gff<-- as GFF3
Hmmm .... the GFF3 has Parent references to the protein_id, but it
doesn't appear as an ID.
I do not like using a second region to put the description line in.
Using the organism as the ID for the source line also looks odd.
> Interestingly their GFF3 output is pretty close to your proposed
> EMBOSS output, only they've got a "region" rather than
> "biological_region" for the parent meta-feature.
I don't see a parent meta-feature there.
> However, I think introducing extra biological_region features to
> act as the parent of multi-location features would run counter to
> the canonical gene model given in the GFF3 specification (which
> appears to be just a suggestion rather than a requirement).
> Also, introducing this meta-feature would complicate any
> future wish to try to express explicit parent/child relationships
> between operon, gene, mRNA and CDS features. Of course, as
> we've discussed, these biological relationships are only implicit
> in the GenBank/EMBL feature table.
I tried the canonical gene example:
##sequence-region ctg123 1 9000
ctg123 . gene 1000 9000 . + . ID=gene00001;Name=EDEN
ctg123 . TF_binding_site 1000 1012 . + . ID=tfbs00001;Parent=gene00001
ctg123 . mRNA 1050 9000 . + . ID=mRNA00001;Parent=gene00001;Name=EDEN.1
ctg123 . five_prime_UTR 1050 1200 . + . Parent=mRNA00001
ctg123 . CDS 1201 1500 . + 0 ID=cds00001;Parent=mRNA00001
ctg123 . CDS 3000 3902 . + 0 ID=cds00001;Parent=mRNA00001
ctg123 . CDS 5000 5500 . + 0 ID=cds00001;Parent=mRNA00001
ctg123 . CDS 7000 7600 . + 0 ID=cds00001;Parent=mRNA00001
ctg123 . three_prime_UTR 7601 9000 . + . Parent=mRNA00001
ctg123 . cDNA_match 1050 1500 5.8e-42 + .
ctg123 . cDNA_match 5000 5500 8.1e-43 + .
ctg123 . cDNA_match 7000 9000 1.4e-40 + .
I can not (code not yet checked in) reproduce this, subject to the
sequence being too short.
Internally, EMBOSS generates parent features for CDS and cDNA_match
(where several features share an ID), and the parent structure is preserved.
On output, the generated features are not reported so GFF3 input is
If we read EMBL/GenBank entries then we will generate a parent feature
with type "biological region" to attach the annotation from the join.
Reproducing the "parent" relationships is a separate exercise that could
be a separate application. In terms of reading one format and writing
another I prefer to not generate any GFF3-specific extras.
> This is probably a good example to discuss on the GFF3
> song-devel mailing list - small and apparently very simple
> except for how to represent the (forward strand) join location.
We could propose something for the
to describe how to represent EMBL/GenBank entries in GFF3 (after due
discussion on the SONG-devel list)
More information about the emboss-dev