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/
[email protected]
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.
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
