Archiving annotations (was: [Biococoa-dev] Annotation)

Alexander Griekspoor mek at mekentosj.com
Thu Feb 24 06:09:38 EST 2005


I see where you're head at, but I don't see exactly HOW you would like 
to see this implement.
Do you mean that each annotation instead of a simple shouldArchive 
boolean should have a variable which you can set to one of the three 
levels you describe? Could you describe a bit more in detail how to 
implement this all? If I understand you right, you want this system be 
functional in the read/write classes or not? So one can define what he 
wants to save/load to/from a file? Or/And do you want to have these 
options in the sequence creation methods? How do we check what the app 
supports? Delegates?
It's rather vague to me although I agree that we need to have a system 
to discriminate between different levels of annotation datatype 
support.
Alex


On 24-feb-05, at 6:35, Charles PARNOT wrote:

> At 8:39 AM -0500 2/23/05, John Timmer wrote:
> I had a thought on handling the attributes last night.  One of the 
> dangers of allowing everything into an attribute is that cruft can 
> build up and the file size balloon, especially if a single sequence is 
> shuffled between applications.  It would be nice to have a formalized 
> way of ensuring that a minimal, informative sequence object can be 
> created.  So, I suggest that we code for three levels of information:
>
>  Base level:  minimum necessary to hold an attribute:  name, type, 
> range, notes.  Everything else is removed.  Guaranteed to work in any 
> BC-based app.
>  App level: All objects are tested to determine whether the current 
> application has the class to work with is kept; everything else is 
> removed.
>  Verbose level:  everything's there, whether it can be used or not.
>
>  This way, information that's been copied, dragged and dropped, etc. 
> can easily be streamlined in a way that's more appropriate for the 
> receiving app.
>
> JT
>
>
> At 5:43 PM +0100 2/23/05, Alexander Griekspoor wrote:
> This scheme to save objects to disk is perfect. I like the additional 
> BOOL 'shouldArchive'.
> This should perhaps be integrated with John's proposal on the three 
> archiving options, more on this later...
>
> John's idea is indeed excellent!
> One thing to keep in mind is if a file is used in 2 different apps, 
> back and forth, then the user would probably not want to lose 
> everything every time she switches from one app to the other and save.
>
> 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

       Microsoft is not the answer,
       Microsoft is the question,
       NO is the answer

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


More information about the Biococoa-dev mailing list