[Bioperl-l] Bio::FeatureIO::gff

[Chris Fields]

On Jun 19, 2008, at 2:38 PM, Mark Johnson wrote:

> I recently had to do some gff3 generation/munging, so I took a look at
> Bio::FeatureIO::gff.  I ran into a few issues:
>
> - The _handle_feature method (called by next_feature) attaches Dbxref
> attributes using 'Dbxref' as the key.  However, _write_feature_3 uses
> 'dblink' for the key when looking for Dbxref attributes.  I changed
> _handle_feature to use 'dblink' also, but I'm not sure that's any more
> (or less) correct than changing _write_feature_3 to use 'Dbxref'.
> Anybody have any strong opinions one way or the other?
>
> - Sendu made some changes to _write_feature_25 and _write_feature_3,
> but missed a line in _write_feature_3.  I think line 890 should be
>
>  my $phase  = defined($feature->phase) ? (ref($feature->phase) ?
> $feature->phase->value : $feature->phase) : '.';
>
> instead of
>
>  my $phase  = $feature->phase->value;
>
> to be consistent.
>
> - Also in _write_feature_3, the Dbxref attributes are wrapped in a
> call to uri_escape().  This generates a mangled gff3 that Apollo, at
> least, does not like.  Also, looking at the gff3 spec, I do not
> believe this is correct behaviour.  Quoting
> http://www.sequenceontology.org/gff3.shtml:
>
> The value of both Ontology_term and Dbxref is the ID of the cross
> referenced object in the form "DBTAG:ID".  The DBTAG indicates which
> database the referenced object can be found in, and ID indicates the
> identifier of the object within that database.  IDs can contain
> unescaped colons but DBTAGs cannot, so parsing code should split on
> the first colon encountered in the attribute value.
>
> So the key (DBTAG) should be escaped, but not the value (ID).  The
> code presently escapes both:
>
>  my $vstring = join ',', map {uri_escape($_->database .':'.
> $_->primary_id)} @v;
>
> which should probably be something like
>
>  my $vstring = join ',', map {uri_escape($_->database) .':'.
> $_->primary_id} @v;
>
>
> So, what are the plans for Bio::FeatureIO?  I find it kind of handy,
> so unless it's going to be scrapped in favor of something else, any
> objection to lobbing a ticket and patch at Bugzilla?

I think the general idea of Bio::FeatureIO will remain (read/write  
feature data) but it will definitely undergo significant  
reimplementation.  The typed SeqFeatureI class  
(Bio::SeqFeature::Annotated) would be deprecated in favor of something  
more lightweight.

However, I don't see that happening until after 1.6 is released unless  
someone wants to take it on.

chris