How about if the server is simply allowed to return features that
don't overlap the queried segment range, if they declare the
appropriate capability? They would then carry the correct type etc.
The only question is whether a client is significantly helped by an
explicit marking of some sort. My personal view is that it's OK
without it.
Andy
On 29 Jun 2009, at 15:34, Jonathan Warren wrote:
Yes that was the intent. I guess if a client is filtering on feature
type then the way we have suggested is not going to be very useful -
the client would have to walk along the source until it found a
feature of the type it wants ( using the nextleft every time and
looking at the region).
Perhaps a better way is not have any "next" flag at all as the
segments location will show it's out of range and to the left so
this should be obvious. This way a client can filter on type of
feature in the normal features command and the server can return a
type appropriate to that filter?
On 29 Jun 2009, at 14:44, Lincoln Stein wrote:
The NEXTLEFT and NEXTRIGHT pseudo-features should appear even if
there are no conventional features in the <SEGMENT>.
There is an ambiguity here. It is completely possible for a DAS
server to return multiple distinct feature types per segment.
However, a type "NEXTLEFT" does not distinguish which feature type
can be found to the left. Is the intent here to say that "any"
feature can be found to the left or the right?
Lincoln
On Mon, Jun 29, 2009 at 5:31 AM, Jonathan Warren
<[email protected]> wrote:
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
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
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
--
Lincoln D. Stein
Director, Informatics and Biocomputing Platform
Ontario Institute for Cancer Research
101 College St., Suite 800
Toronto, ON, Canada M5G0A3
416 673-8514
Assistant: Renata Musa <[email protected]>
Jonathan Warren
Senior Developer and DAS coordinator
[email protected]
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
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
