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