[Biococoa-dev] Annotation

[Alexander Griekspoor]

> Oh, two additions of why a set of pre-defined keys would be neat for
> describing sequence type:
> Consistent display:  an app using this could let the user set a 
> preference
> something like "show all introns in green".  This would make it easy to
> propagate the preference across all documents.
Yep!

> Spotlight:  we'd have a better sense of what to export and how to 
> export it.
> Something like:  if ( theFeature == @"S/T Kinase  domain") export 
> "kinase".
Again, yep! Metadata extraction can also be unified...

> The question this raises for me:  should we effectively provide access 
> to
> the underlying dictionary so that people could add any 
> feature/annotation
> they wanted?
Ok, I've added the base BCAnnotation class to the CVS, not connected to 
anything, not build once ;-) But, it does give you an idea of the 
methods, and also I've headerdoc-ed the header with some ideas. Take a 
look and let me know what you think, any addition, comments and 
critiques are welcome of course.
The question below is now answered. Absolutely! One of the things I 
liked to see from the start was the flexibility to add custom 
annotations of any form. The just added annotation class takes ANY 
object as content, thus including your own program specific ones 
(though we have to define some coding protocols in order to be able to 
write those out to a file). This way developers can store their own 
preferences, metadata etc in the sequence file as annotations. Of 
course, by defining predefined sets following your excellent plist 
proposal, we can standardize things where ever possible, without giving 
up flexibility.
An example, say my EnzymeX program wants to store enzyme cut positions 
in the sequence file. Now I can simply add a BCFeature with my 
previously mentioned custom enzyme object as content, and the cut 
position as its range.
Two more ideas:

For the key (a.k.a name), it might be a good idea to use the same 
approach as the preferences model, so a predefined tag would be 
according to BSML wherever suitable. Developer custom names should be 
composed according to the rules Apple proposed for preferences (the 
inverted url approach):

I could store my enzyme objects using the following name:
com.mekentosj.enzymex.enzyme(.ecori)

similar, one we define but is not present in BSML would become:
org.bioinformatic.biococoa.ournewpredefinedname

Another idea:
how do we write out these things? simple, only accept custom objects 
that adhere to the <NSCoding> protocol. All objects that aren't 
natively supported by plist encoding, can be archived into NSData and 
written as such in the xml. The nice thing is that the datatype (= 
className) is written in the xml as well, so that makes it easy to 
unarchive the thing. It needs some logic to control/check but its 
powerful I think. I can even add a simple - (NSData *)encodedContent; 
method to the BCAnnotation class which does the work, and can be used 
by the BSML writer. It can even check whether coding is supported by 
the custom class and return nil if it does not (in case the object is 
lost during a write.
This actually leads me to another question right at the spot, is it a 
good idea to add a boolean "archive" or something to an annotation? 
This way you can actively decide whether the annotation should be 
written out to disk or not (think of temporary attributes, like the one 
in NSAttributedStrings). For instance, during the life of my program it 
might be nice to add custom (non-writable) objects to your sequence, 
but you might not want those be saved with the file (or you're not able 
to). This way you can specify which are to be saved and which not....
>
> Either way, we're going to have to define a set of keys that we will
> support, but this seems like a major design decision that should be 
> thought
> about for a bit.
Absolutely! I'll think a bit more about the plist approach...
Cheers,
Alex


> _______________________________________________
> 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
                   AIM: mekentosj at mac.com
                   E-mail: a.griekspoor at nki.nl
               Web: http://www.mekentosj.com

                             iRNAi, do you?
              http://www.mekentosj.com/irnai

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