[Biococoa-dev] Annotation

Alexander Griekspoor mek at mekentosj.com
Tue Feb 22 18:41:28 EST 2005


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. Of course you could have to methods, 
annotationWithName: and annotationArrayWithName:, the first returning 
the first instance found, the other returning all of them (which is 
undoubtfully slower). And yes, it would be wise for me as a developer 
to nest all these in a BCFeatureSet called com.mekentosj.enzymex for 
instance.

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

>
> 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
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>
>
*********************************************************
                     ** Alexander Griekspoor **
*********************************************************
               The Netherlands Cancer Institute
               Department of Tumorbiology (H4)
          Plesmanlaan 121, 1066 CX, Amsterdam
                   Tel:  + 31 20 - 512 2023
                   Fax:  + 31 20 - 512 2029
                   AIM: mekentosj at mac.com
                   E-mail: a.griekspoor at nki.nl
               Web: http://www.mekentosj.com

                           Windows vs Mac
	65 million years ago, there were more
                      dinosaurs than humans.
	     Where are the dinosaurs now?

*********************************************************




More information about the Biococoa-dev mailing list