[DAS] maxbins in DAS1.6?

Tue Sep 15 13:54:27 UTC 2009

As Andy says, you can restrict the sources coming back from the  
registry as below (This is taken from http://www.dasregistry.org/help_scripting.jsp#sources) 
:

The sources command so far accepts several (optional) arguments. It is  
also possible to combine these.

label - This allows to get a listing of all DAS sources with the  
requested label. e.g http://www.dasregistry.org/das1/sources?label=BioSapiens
organism - This allows to get a listing of all DAS sources for an  
organism (or it's NCBI taxonomy id). e.g. http://www.dasregistry.org/das1/sources?organism=Homo%20Sapiens
http://www.dasregistry.org/das1/sources?organism=9606
authority - Filter by the authority of coordinate systems e.g. http://www.dasregistry.org/das1/sources?authority=UniProt
capability - Only show servers that support particular DAS commands  
e.g. http://www.dasregistry.org/das1/sources?capability=sequence
type - Display servers with particular types of coordinate systems  
e.g. http://www.dasregistry.org/das1/sources?type=Chromosome
It is possible to access information for a single DAS source, if its  
unique ID is known. e.g. http://www.dasregistry.org/das1/sources/DS_109

On 15 Sep 2009, at 14:34, Andy Jenkinson wrote:

> On 15 Sep 2009, at 13:43, Thomas Down wrote:
>
>> On Tue, Sep 15, 2009 at 12:40 PM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk 
>> > wrote:
>> Yep, it should now be a little easier to tell. Also, the 1.6- 
>> compliant version of ProServer will only pass the parameter through  
>> to a SourceAdaptor if the adaptor declares support for it. This is  
>> one of the ways I hope to encourage compliance with the parts of  
>> the spec that usually get neglected - i.e. metadata. Ideally  
>> clients would work on the same principle, i.e. if maxbins is not  
>> declared as a capability, it won't be sent in the request. More  
>> tolerant clients tend to result in inconsistent implementations in  
>> servers. Another way is that the registry will check for  
>> capabilities that are supported but not declared. Hopefully we can  
>> establish both incentive and necessity to describe sources  
>> accurately.
>>
>> Thanks.  I've just patched svn-latest Dazzle so it sends X-DAS- 
>> Capabilities: maxbins/1.0 iff the datasource is advertising support  
>> (specifically, if it implements the TilingFeatureSource interface),  
>> so I guess that's now fairly comparable to how ProServer is behaving?
>>
>> A couple of issues which come to mind, though:
>>
>>          1. This is all dependent on multiple-datasource servers  
>> being able to return differernt cap-sets for different  
>> datasources.  Dazzle already has the plumbing for this (and, in  
>> fact, has returned different cap-sets for reference and annotation  
>> sources for a long time now), but I don't actually see anything in  
>> the spec. which explicitly allows this.  Might be worth stating  
>> that capabilities are per-datasource?
>
> ProServer also does this, I think this is probably one of those  
> areas that when you're immersed in using it on a daily basis like I  
> am seems obvious but actually is not! The 1.6 spec has slightly more  
> explanation of the server/source paradigm, and I will add some  
> examples to the 'capabilities' section to illustrate that the  
> capabilities in the header will depend on the request. I can already  
> think of one possible area of ambiguity - it is not stated that data  
> sources shouldn't report support server-level commands (i.e. the  
> sources and dsn commands).
>
>>           2. For some DAS clients (including the one that currently  
>> interests me), it's quite likely that a "features" request might  
>> well be the first contact the client has with a given server.  But  
>> until that first request comes back, how does the client know  
>> whether maxbins is appropriate or not?  Right now, I'm probably  
>> going to just go ahead, stick maxbins on the first request, then  
>> leave it off subsequent requests if the capability is missing from  
>> the first response, but that isn't really a good fit to your  
>> "strict client" principle.  I suppose the ideal would be some kind  
>> of fast "pre-flight" request that can be issued to check a  
>> datasource's cap-set, but it's not totally obvious what to use.  A  
>> dsn/sources request is definitely no use here, if capabilites are  
>> per-datasource.  'types' might not be a bad idea, but I'm a bit  
>> reluctant to depend on it because, at least in the past, it's not  
>> been widely used (and can be a bit slow if servers want to return  
>> type-counts but don't have an efficient way of calculating these).   
>> I suppose 'stylesheet' might be to logical choice.  Or just  
>> 'features' on a 1-base segment.  Or am I missing something?
>
> Capabilities are stated in the sources document:
> <CAPABILITY type="das1:maxbins" />
>
> The only snag is that right now you have to parse all sources.  
> Technically both the registry and proserver allow you do do:
> http://www.ebi.ac.uk/das-srv/genomicdas/das/sources/eqtl_rat_cis_fat
>
> But IIRC I didn't include this in the spec to keep things simple.
> _______________________________________________
> 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. 