[Biococoa-dev] more ramblings

Alexander Griekspoor mek at mekentosj.com
Thu Nov 18 17:06:45 EST 2004


That's a very nice idea as well! We discussed storage a few times 
before as well, and one of the things I still see a future for is a 
biococoa native file format (to preserve all our "added value") which 
is represented as a bundle as well. Anyway, that will come later...
Alex


Op 18-nov-04 om 22:01 heeft John Timmer het volgende geschreven:

> Alex – was this supposed to go to the list at large?
>
>  I agree about your thoughts on the bundle use.  Another way I was 
> thinking -  the bundle could contain a large genomic sequence, an 
> mRNA, sequences of each exon, the ORF, and the protein sequence.  Each 
> of these sequences can be features of the other.  IE – an feature of 
> the genomic sequence could have a pointer to the exon sequence in the 
> same bundle.  A feature of the mRNA could point to the same exon.  The 
> mRNA could have an ORF feature, which points to the protein sequence 
> that it encodes.  Basically, we can define features in such a way that 
> they point to another sequence in the same bundle.
>
>  Cheers,
>
>  Jay
>
>
>
>   Anyway, to stir up more controversy around here, I had always 
> envisioned something along the following structure:
>
>   Sequence bundle
>   (groups related sequences)
>       |
>   Sequence wrapper
>   (holds features, notes, etc.)
>       |
>   Sequence
>
>
>
>  Yes, my idea exactly! Imagine a multi-fasta file, wouldn't it be 
> fantastic to initialize such a sequence bundle directly from it? Or 
> write one out to disk in fasta format.... Also, alignments could be a 
> perfect subclass of a sequence bundle object (one that only in 
> addition has to store the interrelated positions... Awesome!
>
>
>  The reason being that I see features as being abstractions, not 
> inherent to any type of sequence.  
>
> Yep, absolutely agree. We have feared to approach this problem a bit 
> in the past, but this should be the underlying idea to keep in mind.
>
>
>  They’re mostly a bit of information and a range it’s relevant to. 
>  There are some exceptions to this – for example, a phosphorylation 
> site changes the MW of a protein – but they are largely exceptions.  
>
> I see some discussions already on the horizons rapidly popping up (you 
> should have stopped with the previous sentence when everything was 
> still perfect ;-)
>
>
>  These exceptions are going to be difficult to handle regardless – how 
> to tell if a site is or isn’t glycosylated is going to be very context 
> dependent.  The majority of features (ORFs, kinase domains, 
> restriction sites, etc.) don’t require that sort of heavy lifting.
>
> I guess, I'm gonna read some emails in which we discussed this 
> previously, we have been talking about this.
>
>
>  Alex
>  *********************************************************  
>                      ** 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
>    
>        Microsoft is not the answer,
>        Microsoft is the question,
>        NO is the answer
>
>  *********************************************************
>
>
>
>
>  _______________________________________________
>  This mind intentionally left blank
>
*********************************************************
                     ** 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
                   E-mail: a.griekspoor at nki.nl
	        AIM: mekentosj at mac.com
               Web: http://www.mekentosj.com

                  EnzymeX - To cut or not to cut
              http://www.mekentosj.com/enzymex

*********************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5950 bytes
Desc: not available
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20041118/0b6a917e/attachment.bin>


More information about the Biococoa-dev mailing list