yes thats what my current thinking was and what I interpreted Eugenes
email as suggesting.
But what I would like to work is this : /das/source/features?
segment=P99999:1,150;type=gene;type=annotation but this won't work if
you have already specified a range - or at least it's not that clear
as to whether it should work.
I guess i'd like it to be a "I want non-positional annotations" rather
than "give me everything and I'll filter out non-positional
annotations by choosing all the other types except positional
annotations".
But this is only my current opinion - we are debating this right?
On 2 Aug 2010, at 17:17, Andy Jenkinson wrote:
So just to clarify, is this what you mean?
/das/source/features?segment=P99999 [returns all positional and
all nonpositional]
/das/source/features?segment=P99999:1,150 [returns only
positional in the query range]
/das/source/features?segment=P99999;type=somenonpositionaltype
[returns any feature of the given type, which might be nonpositional]
This is different to what the spec says, but is close to what
UniProt does. It does the above, except it also allows this:
/das/source/features?segment=P99999:0,0 [returns only
nonpositional]
I think you're saying we should remove the 0,0 capability from MyDas/
uniprot, and change the spec wording to reflect that nonpositional
features will not be returned if the client specifies a start/end
position. Right? :) Sorry for being dumb, am just a bit confused
about what you're saying is illogical, etc.
On 2 Aug 2010, at 16:17, Jonathan Warren wrote:
Currently having read all points and thought about it properly I
agree with Eugenes summary of what the behavior should be.
I was thinking that types filtering is not implemented and
understood well by many casual users of DAS. But as the types
command and filtering is something we want to encourage using the
non-positional type should encourage this and as long as it's
documented well and splattered everywhere I think it should be
fine. But using the logic below as far as I can see this means you
have to do 2 requests if you want features and non-positional
annotations for a range /das/source/features?segment=P99999:1,150
and /das/source/features?segment=P99999;type=annotation
But presumably doing /das/source/features?
segment=P99999:1,150;type=gene;type=annotation would actually
return genes if in region but no non-positional results which isn't
really logical on its own?
On 2 Aug 2010, at 13:33, Andy Jenkinson wrote:
On 2 Aug 2010, at 10:45, Jonathan Warren wrote:
I'm not sure I agree with returning all annotations for every
tiny part of a sequence requested.
If you consider DAS to be used for visual display mainly - then
it seems a bit ridiculous to return all publications related to a
segment (take a case where you have many publications related to
a protein sequence). If publications aren't asked for i.e. non-
positional annotations then I don't think they should be given.
So I guess I'm agreeing with Jim here.
Given the history of DAS I would propose a non-positional
parameter as apposed to "positional".
I think we have to remember that the 1.6 spec is supposed to
mainly be a consolidation of the way DAS is being used and DAS is
supposed to be simple (or not overly technical and difficult to
pick up anyway). However- obviously we don't want to propagate
practices that really don't make sense. The 0,0 thing is a hack
like we had hacks for ontologies which now for 1.6 we have cvIds
(I think are a big improvement). So we need something that is
simple and obvious for a big all encompassing thing like
positional vs non-positional.
I'm not quite sure what you're suggesting we do in 1.6?
On 2 Aug 2010, at 09:50, Leyla Garcia wrote:
*Hi list,
*>No magic numbers.
*According to discussions on this matter, I will change MyDas
behaviour so 0 will be no
"magic number" any more,
*>Types can be used for filtering, and actually you get more
fine-grained control than simply positional or non-positional.
(I use this technique now in DASher.) *
In my opinion, the current spec as written is correct. That is,
non-positional features don't just apply to the whole sequence,
they apply to any part of the sequence.
As an example, consider a journal reference --- a particular
protein was isolated by a lab, they wrote a paper about it, and
deposited the protein sequence in a database. If you look at a
subsequence of the protein sequence, that subsequence still
derives from the paper, right? So therefore the feature
containing that journal reference should still be attached to
the subsequence.
On that basis, I think the uniprot server is technically doing
it wrong and should be changed, although I have to say that in
practice it hasn't been an issue for me.
*and non-positional features will be always returned.
Since UniProt is built upon MyDas, its behaviour will change as
well.
Thanks,
Leyla
*
Dave
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
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
ResearchLimited, a charity registered in England with number
1021457 and acompany registered in England with number 2742969,
whose registeredoffice is 215 Euston Road, London, NW1
2BE._______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
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
ResearchLimited, a charity registered in England with number
1021457 and acompany registered in England with number 2742969,
whose registeredoffice is 215 Euston Road, London, NW1 2BE.
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
