[DAS] next "feature" for 1.6 spec

[Andy Jenkinson]

Sorry, I meant to send it to the list.

On this topic, I would love to see clients use the capabilities  
headers/entities more, and I think this requires the registry to be  
more "aggressive" in its validation and clients to rely on the  
validation more - e.g. a fail if capabilities are supported but not  
reported by the server (and vice versa of course).

Andy

On 29 Jun 2009, at 15:41, Jonathan Warren wrote:

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