[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