[DAS] Adjacent feature extension

[Andy Jenkinson]

Hi Thomas,

Thanks for this. Regarding the option of whether to return just one feature per side or all overlapping features, the only other advantage that immediately springs to mind for the latter (in addition to some measure of consistency, as you mention) is that it allows the client to immediately render the exact region of that feature without triggering another request. It would generally mean changing zoom level. I'm can't say if clients are likely to follow this mechanism as opposed to, say, pan and centre on the feature, but if they wanted to it would be more efficient (and possibly a little bit more efficient anyway depending on how your client does its requests).

Disadvantages I can think of:
 - "adjacent" request takes marginally longer
 - not quite as obvious what clients should put in their UI controls - need to pick a feature to be able to do "jump to BRCA1"
 - risk of servers not implementing it correctly and only returning one feature anyway (although I don't think this is likely as the concept is different to "feature-by-id")

Some things to further define:
 - servers can't return a fake feature
 - should servers return features on different reference sequences if there are none one the current one?
 - how should servers treat features that overlap the adjacent range? Treat them as the adjacent feature to return, or only include features completely outside the query range? What if the next feature completely outside the query range is part of the same feature hierarchy (e.g. an exon outside the current window).

Any thoughts from anyone on these?

Cheers,
Andy


On 5 Mar 2011, at 15:01, Thomas Down wrote:

> Following on from a discussion at the DAS Workshop:
> 
> DAS doesn't have offer any specific support for clients that provide
> mechanisms for skipping from the current position to the "next" or
> "previous" feature.  I'd like to propose a small extension (one extra filter
> option on the existing "features" command) to facilitate this.  Full details
> are here:
> 
>                 https://github.com/dasmoth/dalliance/wiki/AdjacentFeatures
> 
> ...but briefly, a request like:
> 
>               /das/features?adjacent=chr21:30000000
> 
> ...would be expected to return a standard DASGFF document containing the two
> features either side of the specified point.
> 
> All comments are welcome!  One open question is whether the query should *
> just* return the adjacent features, or should also return other features
> overlapping the adjacent feature.  My preference is for them former, but the
> latter does have the merit of being quirk-wards compatible with the existing
> feature_id filter.  Does anyone else have strong feelings one way or
> another.
> 
> There isn't currently a full implementation of this, but if nobody comes up
> with major objections, I'm hoping to try implementations in Dazzle (server)
> and Dalliance (client) within the next couple of weeks.
> 
>                         Thomas.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das