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
[email protected]
--
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
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
