[DAS] Adjacent feature extension

[Jonathan Warren]

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.
>
>> If you take the intention of this as finding features where data is  
>> sparse then I don't think there are big issues.
>
> These aren't big issues (taken in that context), but I absolutely  
> want to make sure we don't make the mistakes of the past by leaving  
> ambiguity in the spec - whether it's an extension or otherwise. It's  
> all very well us knowing what we designed it for, but if it isn't  
> written down then it's going to cause problems. For the avoidance of  
> doubt, I am very keen to get this done, but I see no sense in doing  
> it in a way that we're not going to regret later (of which there are  
> already countless examples).
>
>> Part of the point of the extensions phase is to try these things  
>> out with examples and refine the specs. To leave acceptance of this  
>> will be a big mistake in my view.
>
> I'm not sure what you mean by "leave acceptance". I'm trying to work  
> through these things, not put blocks in the way. I am trying right  
> now to implement it and these are the things I have immediately come  
> up against so I need to get input right now on how to do it.
Cool! I'll shut up then.

> Or to put another way, I can't create my example without refining  
> the specs.


Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314









-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.