[DAS] Adjacent feature extension

[Andy Jenkinson]

On 7 Mar 2011, at 16:31, Jonathan Warren wrote:

> 
> On 7 Mar 2011, at 16:19, Andy Jenkinson wrote:
> 
>> On 7 Mar 2011, at 15:49, Jonathan Warren wrote:
>> 
>>> 
>>> On 7 Mar 2011, at 15:04, Andy Jenkinson wrote:
>>> 
>>>> On 7 Mar 2011, at 12:16, Jonathan Warren wrote:
>>>> 
>>>>> I'd say if we don't have any more objections in the next couple of days then go with your proposal as is? I'll then put support into the registry this week if that is the case. If you could also then copy the proposal from here https://github.com/dasmoth/dalliance/wiki/AdjacentFeatures to the extensions page here:
>>>>> http://www.biodas.org/wiki/DAS1.6E#Adjacent_Feature_filter noting in large letters that it was agreed by the community on such a such a date?
>>>> 
>>>> I think there is a lot left to be clarified so adopting it "as is" is a no go for me. In particular, take a look at this diagram and see if you can work out what will be returned with "adjacent" queries for either side of the viewing area, and do they make sense for what the client is trying to achieve?
>>>> <DAS-Adjacent.png>
>>>> 
>>>> The client has "seen" gene 2 and all its parts.
>>>> 
>>>> If the client asks for features adjacent to the left/right sides of the viewing area, what should the server return?
>>> I don't think it makes sense to ask for a next right in this case as there are features here already. This is for sparse data sources so it's ok just to return whats there if someone specifically wants to hit the next feature button or a client can blank the next right button out. It's up to the client.
>> 
>> Agree. But what I don't want to see is clients implementing some weird hybrid where they offer a "next right" button that bypasses SNP 2. If we expect clients to behave in a certain way, we should say so.
>> 
>>> Next left should return SNP1 if asked for an adjacent request.... or genes and constituents if filtered on gene.
>> 
>> Why SNP 1, and not any of the others at the same position? How is the server supposed to decide? Does it matter? How would this be worded in the spec?
> It doesn't matter unless filtered.

OK. Unless there are any objections, Thomas can you add this to the wiki page? Something like "If there is a choice of features at the same position, the server may return any one of them."?

As for the overlap question, let's say that features overlapping the "adjacent" parameter can be included, as it's too complicated otherwise (I just thought of another edge case and it's not pretty!). We should also include a "design note" for client developers.

For returning parents/parts, let's explicitly limit it to one feature. It does make it behave unlike the "normal" segment-based request, but it makes lots of the other issues, like nonpositional parents, moot.

Everyone happy?