[Bioperl-l] AnnotationCollectionI and SeqFeatureI changes

[Allen Day]

On Sun, 28 Nov 2004, Hilmar Lapp wrote:

> 
> On Sunday, November 28, 2004, at 08:28  AM, Aaron J. Mackey wrote:
> 
> >> E.g., get_all_tags() will now return all annotation keys ever added, 
> >> regardless of whether through $feat->primary_tag, $feat->source_tag, 
> >> $feat->annotation->add_Annotation, or $feat->add_tag_value, unless 
> >> any of these methods is overridden.
> >
> > Thanks for taking a deeper look into things, Hilmar.  Is this true for 
> > all SeqFeatureI-implementing classes, or just 
> > Bio::SeqFeature::Annotated?
> 
> Including primary_tag and source_tag in the annotation collection is 
> what SeqFeature::Annotated does. Lumping together tags and annotation 
> is the default decorating implementation on the AnnotatableI interface 
> for the *_tag_* methods, and  hence will be used for all SeqFeatureI 
> implementing classes that don't override it. SeqFeature::Generic, for 
> instance, doesn't override it (anymore), but it does keep primary_tag 
> and source_tag separate from the annotation bundle.

primary_tag() and source_tag() being separate from the AC was an oversight
on my part.  the intention was to move all of the feature's tag attributes
into the collection.

> So, evidently there are subtle aspects about the various tags and the 
> annotation that have not been spelled out when documenting the contract.

that's right.  it's still not well defined.

> Specifically, this is whether an implementation may or must keep the 
> different tags and annotations in sets that at least behave as 
> semantically distinct sets. E.g., if you set a primary_tag, may an 
> implementation treat it as annotation and still be SeqFeatureI 
> compliant (meaning, as a SeqFeatureI consumer, you'd have to be 
> prepared for that). Or, if you add a tag 'blah' via 
> add_tag_value('blah',$whatever), may an implementation or may it not 
> enforce the same class on $whatever that it enforces for annotations 
> added to the collection under the same key 'blah'.
> 
> In the absence of this having been spelled out beforehand, I would 
> argue that the most frequently used implementations' behavior will 
> probably constitute what other programmers took as an answer. In this 
> case, that'd be SeqFeature::Generic ...

i agree with this for the 1.5 release.  however, i also feel that
SeqFeatureI is due for some heavy revision.

> >> This is very different from what it used to be, namely only return 
> >> those keys added through $feat->add_tag_value. Anybody who made any 
> >> assumption that what you didn't add through add_tag_value you'll not 
> >> get back through get_all_tags will be hosed.
> >
> > I could see an argument that "all_tag_values" should really retrieve 
> > just that: all tags, not just any extra tags from add_tag_value.  But 
> > I agree that it's potentially a significant change.
> 
> Yes, and yes. It's a drastic change in behavior, but would be sensible 
> if the target is to eventually obsolete the concepts of tags and 
> annotations being different animals.

which it is.

but for the 1.5 release in the interest of stability i think the best
thing to do will be to put the SeqFeature::Generic *_tag_* implementation
back into that class (i.e. override the SeqFeatureI default dependence on
AnnotatableI) so get_all_annotation_keys() and friends will continue to
return results as previously expected.

> >> I.e., anybody who assumed that $feat->get_all_tags and 
> >> $feat->annotation->get_all_annotation_keys hold distinct sets of 
> >> values will be hosed. This includes bioperl-db, for those who care.
> >
> > But surely bioperl-db could be fixed to no longer make this assumption?
> 
> It certainly could, and I certainly will once this is the direction 
> that bioperl 'officially' adopts. Right now, the change is two weeks 
> old and I'm not sure anyone, including Allen, is ready to vouch that 
> this is a real good way of doing things. [And as aside, fixing 
> bioperl-db to work with the new API may make bioperl-db backwardly 
> incompatible as well.]

right, it's still not fully clear.  i will continue to advocate the
merging of the two feature annotation systems (hash based and object
based) into some common form.  the SeqI annotation mechanisms should
follow suit, but i'm not ready to touch them yet.

> I'm not saying this change of direction may be a show-stopper for any 
> dependent package like bioperl-db. All I'm suggesting is let's be clear 
> that this *is* a change of direction for a core interface, and let's 
> give it some time to phase it in and to iron out wrinkles, both on the 
> end of bioperl itself as well as the end of people who write software 
> against bioperl. Let's give it some time to see how it works, and how 
> it works under stress, before letting it lose on the general public who 
> just wanted to get some bugfixes on the 1.4.0 release or some 
> additional parsers.
> 
> >
> >> It is also not what SeqFeature::Generic will do now, namely not 
> >> return the primary_tag and source_tag keys.
> >
> > Ahh, so we are talking only about Bio::SeqFeature::Annotated?
> 
> Well, no, see above. SeqFeature::Generic does override primary_tag and 
> source_tag, which is why here those tags won't make it into the 
> annotation bundle. It doesn't override the *_tag_* methods, so for 
> those you get the behavior from AnnotatableI.

again this wasn't my intention, i missed something in the code shuffle.  
all the tags, including primary_tag() and source_tag() should have been 
moved into the AC.

-Allen

> 
> 	-hilmar
> 
> >
> > -Aaron
> >
> >
>