[DAS] Adjacent feature extension

[Thomas Down]

On Mon, Mar 7, 2011 at 10:49 AM, Leyla Garcia <ljgarcia at ebi.ac.uk> wrote:

>
> So we can include or exclude the overlapping features. What about adding
> another filter? "adjacent" would retrieve only those around the feature
> requested and "overlapping" would returns the overlaps? Using both would be
> interpreted as OR.  Does is make sense?
> Would that be interesting for people using this type of filters?
>

How does the "overlapping" filter differ from the existing "segment" filter?

The proposal in its current form states that segment and adjacent filters
may be combined, and servers should return the union of features selected by
the individual filters (e.g. a logical OR, just as you suggest).


> In my opinion, absolutely yes.  Otherwise the "10 features in the genome"
>> case remains a massive pain (and potentially a disaster, for
>> inhomogeneous-dstributed data; won't someone think of the MHC tiling
>> arrays?
>> :-).  And even worse for the "10 features in UniProt" case (where I can
>> also
>> see this feature being quite interesting).
>>
> Mmm, I do not understand it, "10 features in UniProt" case? "10 features in
> the genome" case? Could you please some more information about it?
>

Yes, think of a track that is very sparsely, and potentially inhomogenously,
populated.  Things like "imprinted regions in the human genome" (okay, there
are more than 10 of those, but maybe no more than 100, and they're
clustered).  Or "my favorite rare protein domain".  Scanning through such
tracks by scrolling isn't going to be terribly helpful!

One of the use cases I always have in the back of my mind when discussing
stuff like this is the biologist who has done some kind of analysis, has 50
"interesting" regions of the genome (or proteome), and wants to flip through
them quickly to eyeball, sanity check, and see if they can see any
contextual patterns.  I work all the time with people who want this, and
sometimes do it myself.  Up until now, I've tended to solve it by creating
an HTML frameset with a list of regions in one frame and a visualization
tool (either Ensembl or Dalliance) on the other.  It's far from an optional
solution.  Allowing people to flick from region to region *within the
browser* is far smoother.

              Thomas.