[DAS] next "feature" for 1.6 spec

[bgel at lsi.upc.edu]

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
>