[Biococoa-dev] Annotation

[John Timmer]

>>> I'll have a look at the methods Charles (or John?) was proposing with
>>> the plists and predefined keys...
>> 
>> That was John
> Yep, found the email...

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.
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".


>>> I have two questions already though:
>>> - if we request subsequences, do we add a boolean argument to include
>>> the annotations? It would mean that we have to include ALL position
>>> independent annotations, and all the ones that are within the range
>>> requested?
>> 
>> I think we can include that later, but yes, we would have to do that
>> to be consistent. We may even need to add a new annotation to the
>> subsequence to keep track of the history of that sequence, using one
>> of these 'segment' tag you cited in your initial Annotation email.
> Yep, I was thinking that perhaps we should add some method in the
> sequence class to have it return a unique id or serial number (the
> famous UUID) so that we can uniquely point to a certain sequence. The
> segment would be of class BCFeature I guess as it should have the
> positional properties to which it applies...
... 
> The question perhaps rises if we want each annotation to have a set of
> properties that identify the creator/date etc of the annotation, say
> the metadata of the annotation.

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?  Using my example above, would you allow the user to dive into
the feature and add a "display color" key with [NSColor greenColor] to the
feature dictionary?  If so, the best we can hope to code for is handling the
reading/saving/manipulating of a set of pre-defined keys, and framework
users would have to override these methods if they're going to do extensive
customization. 

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.

Cheers,

JT


_______________________________________________
This mind intentionally left blank