What exactly are the 'annotation' and 'gene' feature types? On 2 Aug 2010, at 17:47, Jonathan Warren wrote:
> 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 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
