[DAS] maxbins in DAS1.6?

Jonathan Warren jw12 at sanger.ac.uk
Tue Sep 15 15:35:25 UTC 2009


I agree with Andy on both these (we talked about versioning before).
The version numbers really have no meaning at the moment (no web pages  
anywhere actually explain what a different version means) and don't  
seem to be used at all in data sources ( I'm guessing people end up  
just copying the version numbers from examples given.

I've always had an issue with the commands like this http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat 
  not being a valid das command as it's the most natural request for a  
person new to das to make. So giving it a specific purpose and  
response is a good idea.

My only concern is how to handle these if we start using the power of  
multiple query_uri s per das source (inherited from DAS2, which we  
have started to talk about, rather than the das1 style where all urls  
have a root) as currently there is no "root" url specified in the DAS2  
spec in the sources document...?? So this would have to be specified  
as another capability? or you could infer it from the features  
command, but obviously not the sources cmd!!!

On 15 Sep 2009, at 15:47, Andy Jenkinson wrote:

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