[DAS] next "feature" for 1.6 spec

[Jonathan Warren]

Hi Bernat

Thanks for the feedback!

Yes I agree (and Andy just wrote to me with the same suggestion). An  
additional capability stated in the sources response would be useful.  
Also setting up the registry to test for these capabilities, whether  
specified in the sources response by the provider or not, is on my  
todo list ;)

On 29 Jun 2009, at 14:31, bgel at lsi.upc.edu wrote:

>
>
>
> Hi ,
> I think it would be a very nice feature, at least from
> the client point of view. Since it would be optional, I think it would
> be interesting to have some indication wheter it is supported by a
> server or not. I know a single features query for a single base would
> suffuc for these, but maybe a flag on the registry and a note on the
> capabilities header would be interesting. Expanding the server
> metainformation is good for clients.
>
> Bernat
>
>
>> Another feature we would like to add to the current 1.6 spec is
> the
>> ability for a server to return the next feature both left
> and right of
>> the current region if they exist but are out the
> currently selected
>> range.
>> This would not need a new
> command, but will be specified in the spec
>> as a valid response
> to the features cmd.
>>
>> so if a user specifies
> chr1:1000,2000 the server can return something
>> like this:
>> <SEGMENT id="id" start="start"
> stop="stop" version="X.XX"
> label="label">
>> //minimal information about the next
> feature in a minimal feature
>> element to include location so the
> client knows where the next region
>> of interest for this das
> source is.
>> //if the current region has no features showing then
> these features
>> can be returned, but as they are outside the
> asked for range of the
>> client they will not be displayed (but
> can be used to have a next left
>> or next right button on the
> client.
>> <FEATURE id="id">
>> //NEXTLEFT
> as the type id rather than what the type id would be if in
>> the
> normal region.
>>          <TYPE id="NEXTLEFT"
>> type label</TYPE>
>>          <START> 20
> </START>
>>          <END> 30</END>
>>
>    </FEATURE>
>> <FEATURE id="id">
>>
>          <TYPE id="NEXTRIGHT" >type label</TYPE>
>>          <START> 3000</START>
>>
> <END> 3050 </END>
>>       </FEATURE>
>>
> //the rest of the response as normal if features for this region exist
>>       <FEATURE id="id" label="label">
>>          <TYPE id="id" category="category"
> reference="yes|no"
>> cvId="SO:1234">type
> label</TYPE>
>>          <METHOD id="id"
> cvId="ECO:5678"> method label </METHOD>
>>
>    <START> start </START>
>>          <END> end
> </END>
>>          <SCORE> [X.XX|-] </SCORE>
>>          <ORIENTATION> [0|-|+] </ORIENTATION>
>>          <PHASE> [0|1|2|-]</PHASE>
>>
> <NOTE> note text </NOTE>
>>          <LINK
> href="url"> link text </LINK>
>>
> <TARGET id="id" start="x" stop="y">
> target name </TARGET>
>>          <PART id="child
> id1" />
>>          <PART id="child id2"
> />
>>       </FEATURE>
>>       <FEATURE
> id="child id1" label="child label">
>>
>    ...
>>       </FEATURE>
>>       <FEATURE
> id="child id2" label="child label">
>>
>    ...
>>       </FEATURE>
>>       ...
>>
> </SEGMENT>
>>
>>
>>
>> This ability
> would be an optional one, but we at the sanger, EBI  and
>> Lincoln
> are very keen on this and see a great need and demand for it.
>>
> It's especially useful for when there are no features returned for a
>> region, for sparse data sources and for testing DAS sources in
>> clients. There maybe a performance hit to implement this by the
> server
>> and this is another reason why this response would be
> optional.
>>
>> What do other people think?
>>
>> Cheers
>>
>> Jonathan.
>>
>>
>> Jonathan Warren
>> Senior
> Developer and DAS coordinator
> for the Sanger
>> jw12 at sanger.ac.uk
>>
>>
>>
>
>>
>>
>>
>>
>>
>> --
>> 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
>> DAS at lists.open-bio.org
>>
> http://lists.open-bio.org/mailman/listinfo/das
>>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das

Jonathan Warren
Senior Developer and DAS coordinator
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.