[DAS] maxbins in DAS1.6?
Jonathan Warren
jw12 at sanger.ac.uk
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.
More information about the DAS
mailing list