Annotation sets (was: [Biococoa-dev] Annotation)

[Charles PARNOT]

At 12:41 AM +0100 2/23/05, Alexander Griekspoor wrote:
>Hmm, perhaps in a (not too distant future) yes, we might need the set objects. Right now, I first like to setup the system without. For instance, would you like EVERY annotation and feature to be at least part of set? Or do you like to see sets and individual annotations be mixed?
>The way I see it, an annotation-/featureset could be a subclass of BCAnnotation/BCFeature that is identical except that it has as content an array of annotations/features plus some logic to do things like testing, sorting and managing the set. A relatively simple extension. The reason why is that a set of annotations/features is basically an annotation/feature itself (including range specificity). An examples on the benefit from this implementation:
>Suppose a featureset has 10 features with there own ranges, than we can override the range method of the featureset subclass to calculate and return a union range of the ranges of all its members. Note that in contrast to the general BCFeature class, the content of the BCFeatureSet subclass can only be a mutable dictionary which is limited to contain BCFeature objects only, but that's easy to control of course.
>
>>I don't know what the plan is, but should not we have a BCFeatureSet or BCAnnotationSet class to manage sets of annotations and perform smart queries.
>Do you have an example in mind?
>
>> For example, to resolve conflicts and inconsistencies, (e.g. multiple features with the same name,...).
>I don't think that this is a problem, in fact why not allow multiple features with the same name? For instance the example with the enzymes I mentioned, what I would do is just add 20 features of type com.mekentosj.enzymex.EcoRI with only the ranges different between the objects. We simply have to let the sequence class return an array of all occurences of this name....

I should not have used the word 'inconsistent' ;-)

I am thinking more complicated queries like featureWithName:inRange:,...
Everything could fit in the current BCAbstractSequence, but a class of its own might make sense, with all these combinations to handle. Also, the BCFeatureSet could be used in other classes of the framework at some point, maybe? (hint: alignments!)

But you are right. Let's just see first where that gets us with the sequences, and then we can add another layer. It seems funny to have a set a subclass of the items, but I understand the logic, and I kind of like it the way you present it!


>What do you think, let's add these set subclasses immediately, or build it as an intermediate layer later? If you prefer the first option, I'll see what I can do... and think a bit in the mean time how we would write these away in a file ;-)
>Cheers,
>Alex

OK, I answered that...

now, have a good day! Time to get up, it is ~4 in the morning in Europe...

charles

-- 
Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Charles Parnot
charles.parnot at stanford.edu

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021