[DAS] querying for nonpositional annotations
Jonathan Warren
jw12 at sanger.ac.uk
Mon Aug 2 16:47:37 UTC 2010
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
>>>>> DAS at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>
>>>> 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
>>>> 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
>>>> DAS at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>
>>
>> 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
>> 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/
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.
More information about the DAS
mailing list