[DAS] maxbins in DAS1.6?

Andy Jenkinson andy.jenkinson at ebi.ac.uk
Tue Sep 15 14:47:04 UTC 2009


On 15 Sep 2009, at 15:19, Thomas Down wrote:
> Capabilities are stated in the sources document:
> <CAPABILITY type="das1:maxbins" />
>
> Ah, interesting.  I'd seen that, of course, but hadn't explicitly  
> linked this with the idea of capabilities as listed in the X-DAS- 
> Capabilities header (although of course it makes a lot more sense to  
> have one set of capability metadata, rather than two!). There are a  
> couple of issues here:
>
>             1. The SOURCES examples all say "das command" in the  
> type attribute of the CAPABILITY element, whereas many of the  
> capabilities don't actually map to commands.  I notice that the  
> latest DAS1.6 draft does give an example to clarify this.
>
>             2. X-DAS-Capabilities entries are versioned whereas  
> SOURCES capabilities aren't, which makes them look rather different.  
> (and I note that the 1.6 spec is bumping up the version numbers on  
> some of the existing capabilities...)
>
> How about versioning capabilities in SOURCES, e.g.:
>
>          <CAPABILITY type="features" version="1.1" query_uri="http://noranti.derkholm.net/das/mydata/features 
> " />
>          <CAPABILITY type="maxbins" version="1.0" />
>
> Assume any missing version attributes are "1.0" and everything  
> should be backwards compatible.

Indeed I did increment the version, just because it seemed the right  
thing to do. However as far as I am aware these per-capability  
versions are totally superfluous when taken in context with the X-DAS- 
Version header, i.e. we do NOT want to make it possible to implement  
DAS 1.6 and features 1.0, for example. This could create a whole world  
of pain!

IMO the per-capability version is unnecessary and confusing. ProServer  
does use it internally, but that can be easily changed. Getting rid of  
it would make the spec less confusing, but will of course break things  
that depend on the current format (if there are any).

What do others think?

> 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.
>
> If this isn't specified yet, how about allowing:
>
>              http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat/sources
>
> ?
>
> Then it's possible to stick with the model of passing a single URI  
> around to refer to a "DAS datasource", and stick a command on the  
> end of it to get the data you're after.

Well, the reason we didn't use this format is simply that it doesn't  
"read" well, if only because "sources" is plural. What would perhaps  
make sense, and which would allow for quickly 'pinging' a source for  
other similar uses, is to use this URL format:
http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat

Again, this is what seems most 'sensible' to me but I am happy to go  
with the consensus.



More information about the DAS mailing list