jtimmer at bellatlantic.net
Tue Feb 22 14:23:25 EST 2005
>>> 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
>> 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
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.
This mind intentionally left blank
More information about the Biococoa-dev