[DAS] querying for nonpositional annotations

[Leyla Garcia]

On 02/08/2010 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

I think I am confused about the annotation type filter.
Why do you need type=annotation to retrieve non-positional features when 
no range is specified? -->  
/das/source/features?segment=P99999;type=annotation
If I am not mistaken, no range will retrieve both positional and 
non-positional features.

>
> 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?

So far, non-positional features will be always retrieve, with or without 
range. The idea behind using a type filter (type=annotation) is to 
specify whether or not non-positional features should be retrieve (or 
any other type). So the last query should actually retrieve the 
"annotation" type features, or not?

Leyla

>
>
> 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
>
>
>
>
>
>
>
>
>