From cruckert at uni-muenster.de Fri Sep 11 11:46:22 2009 From: cruckert at uni-muenster.de (Christian Ruckert) Date: Fri, 11 Sep 2009 17:46:22 +0200 Subject: [DAS] Scaling of DAS tracks Message-ID: <4AAA70CE.1040504@uni-muenster.de> I have provided a histogram stylesheet for my DAS tracks, as described at http://www.dasregistry.org/extension_stylesheet_histogram.jsp. Now when viewing my tracks in ensembl I have problems with the correct scaling. One track is displayed twice as high as the other, despite the score values are only half as high. Is there some documentation which stylesheet commands are supported by ensembl. The link to the ensembl stylesheet convention at http://www.dasregistry.org/spec_1.53E.jsp returns a 404 error. Thanks, Christian From andy.jenkinson at ebi.ac.uk Mon Sep 14 04:49:39 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Mon, 14 Sep 2009 09:49:39 +0100 Subject: [DAS] Scaling of DAS tracks In-Reply-To: <4AAA70CE.1040504@uni-muenster.de> References: <4AAA70CE.1040504@uni-muenster.de> Message-ID: <7664BC1E-53AE-43F6-AEF5-10F7B7DDBA00@ebi.ac.uk> Hi Christian, Did you use the 'max' and 'min' properties? These tell the client how to scale the data, otherwise it can only use the values it receives for any one region to guess what they are. Ensembl makes no assumptions that the scale for one track is the same for another, and in the absence of explicit min/max values assumes that the maximum is the highest score it received, and the minimum is the lowest. If however the maximum height of the track itself is different (i.e. the height in pixels of the label region) this must be something else. If you show me the stylesheet and features response I can take a look for you. The documentation link you posted works for me, is it still giving a 404? In any case, I believe Ensembl supports all of the stylesheet functions in the specification. Cheers, Andy On 11 Sep 2009, at 16:46, Christian Ruckert wrote: > I have provided a histogram stylesheet for my DAS tracks, as > described at http://www.dasregistry.org/extension_stylesheet_histogram.jsp > . > > Now when viewing my tracks in ensembl I have problems with the > correct scaling. One track is displayed twice as high as the other, > despite the score values are only half as high. > > Is there some documentation which stylesheet commands are supported > by ensembl. The link to the ensembl stylesheet convention at http://www.dasregistry.org/spec_1.53E.jsp > returns a 404 error. > > Thanks, > Christian > _______________________________________________ > DAS mailing list > DAS at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/das From andy.jenkinson at ebi.ac.uk Mon Sep 14 05:27:31 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Mon, 14 Sep 2009 10:27:31 +0100 Subject: [DAS] Scaling of DAS tracks In-Reply-To: <4348E052-028B-4497-804F-F00EC398ACB6@sanger.ac.uk> References: <4AAA70CE.1040504@uni-muenster.de> <7664BC1E-53AE-43F6-AEF5-10F7B7DDBA00@ebi.ac.uk> <4348E052-028B-4497-804F-F00EC398ACB6@sanger.ac.uk> Message-ID: That's odd, is the registry having any problems? I'm assuming the URL is correct since it works for me! (still working) On 14 Sep 2009, at 10:18, Jonathan Warren wrote: > Hi Andy > > Gives a 404 for me as well.. > > On 14 Sep 2009, at 09:49, Andy Jenkinson wrote: > >> Hi Christian, >> >> Did you use the 'max' and 'min' properties? These tell the client >> how to scale the data, otherwise it can only use the values it >> receives for any one region to guess what they are. Ensembl makes >> no assumptions that the scale for one track is the same for >> another, and in the absence of explicit min/max values assumes that >> the maximum is the highest score it received, and the minimum is >> the lowest. >> >> If however the maximum height of the track itself is different >> (i.e. the height in pixels of the label region) this must be >> something else. If you show me the stylesheet and features response >> I can take a look for you. >> >> The documentation link you posted works for me, is it still giving >> a 404? In any case, I believe Ensembl supports all of the >> stylesheet functions in the specification. >> >> Cheers, >> Andy >> >> On 11 Sep 2009, at 16:46, Christian Ruckert wrote: >> >>> I have provided a histogram stylesheet for my DAS tracks, as >>> described at http://www.dasregistry.org/extension_stylesheet_histogram.jsp >>> . >>> >>> Now when viewing my tracks in ensembl I have problems with the >>> correct scaling. One track is displayed twice as high as the >>> other, despite the score values are only half as high. >>> >>> Is there some documentation which stylesheet commands are >>> supported by ensembl. The link to the ensembl stylesheet >>> convention at http://www.dasregistry.org/spec_1.53E.jsp returns a >>> 404 error. >>> >>> Thanks, >>> Christian >>> _______________________________________________ >>> 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. From andy.jenkinson at ebi.ac.uk Mon Sep 14 05:38:37 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Mon, 14 Sep 2009 10:38:37 +0100 Subject: [DAS] Scaling of DAS tracks In-Reply-To: References: <4AAA70CE.1040504@uni-muenster.de> <7664BC1E-53AE-43F6-AEF5-10F7B7DDBA00@ebi.ac.uk> <4348E052-028B-4497-804F-F00EC398ACB6@sanger.ac.uk> Message-ID: <5265D873-497D-4AD2-A0F0-514AB9AE35D4@ebi.ac.uk> Ah I misunderstood the problem. Now I understand! The link to Ensembl - on- the http://www.dasregistry.org/spec_1.53E.jsp page... That link is no longer valid, as the information is in the 1.53E documentation. On 14 Sep 2009, at 10:27, Andy Jenkinson wrote: > That's odd, is the registry having any problems? I'm assuming the > URL is correct since it works for me! (still working) > > On 14 Sep 2009, at 10:18, Jonathan Warren wrote: > >> Hi Andy >> >> Gives a 404 for me as well.. >> >> On 14 Sep 2009, at 09:49, Andy Jenkinson wrote: >> >>> Hi Christian, >>> >>> Did you use the 'max' and 'min' properties? These tell the client >>> how to scale the data, otherwise it can only use the values it >>> receives for any one region to guess what they are. Ensembl makes >>> no assumptions that the scale for one track is the same for >>> another, and in the absence of explicit min/max values assumes >>> that the maximum is the highest score it received, and the minimum >>> is the lowest. >>> >>> If however the maximum height of the track itself is different >>> (i.e. the height in pixels of the label region) this must be >>> something else. If you show me the stylesheet and features >>> response I can take a look for you. >>> >>> The documentation link you posted works for me, is it still giving >>> a 404? In any case, I believe Ensembl supports all of the >>> stylesheet functions in the specification. >>> >>> Cheers, >>> Andy >>> >>> On 11 Sep 2009, at 16:46, Christian Ruckert wrote: >>> >>>> I have provided a histogram stylesheet for my DAS tracks, as >>>> described at http://www.dasregistry.org/extension_stylesheet_histogram.jsp >>>> . >>>> >>>> Now when viewing my tracks in ensembl I have problems with the >>>> correct scaling. One track is displayed twice as high as the >>>> other, despite the score values are only half as high. >>>> >>>> Is there some documentation which stylesheet commands are >>>> supported by ensembl. The link to the ensembl stylesheet >>>> convention at http://www.dasregistry.org/spec_1.53E.jsp returns a >>>> 404 error. >>>> >>>> Thanks, >>>> Christian >>>> _______________________________________________ >>>> 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 From jw12 at sanger.ac.uk Mon Sep 14 05:18:00 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Mon, 14 Sep 2009 10:18:00 +0100 Subject: [DAS] Scaling of DAS tracks In-Reply-To: <7664BC1E-53AE-43F6-AEF5-10F7B7DDBA00@ebi.ac.uk> References: <4AAA70CE.1040504@uni-muenster.de> <7664BC1E-53AE-43F6-AEF5-10F7B7DDBA00@ebi.ac.uk> Message-ID: <4348E052-028B-4497-804F-F00EC398ACB6@sanger.ac.uk> Hi Andy Gives a 404 for me as well.. On 14 Sep 2009, at 09:49, Andy Jenkinson wrote: > Hi Christian, > > Did you use the 'max' and 'min' properties? These tell the client > how to scale the data, otherwise it can only use the values it > receives for any one region to guess what they are. Ensembl makes no > assumptions that the scale for one track is the same for another, > and in the absence of explicit min/max values assumes that the > maximum is the highest score it received, and the minimum is the > lowest. > > If however the maximum height of the track itself is different (i.e. > the height in pixels of the label region) this must be something > else. If you show me the stylesheet and features response I can take > a look for you. > > The documentation link you posted works for me, is it still giving a > 404? In any case, I believe Ensembl supports all of the stylesheet > functions in the specification. > > Cheers, > Andy > > On 11 Sep 2009, at 16:46, Christian Ruckert wrote: > >> I have provided a histogram stylesheet for my DAS tracks, as >> described at http://www.dasregistry.org/extension_stylesheet_histogram.jsp >> . >> >> Now when viewing my tracks in ensembl I have problems with the >> correct scaling. One track is displayed twice as high as the other, >> despite the score values are only half as high. >> >> Is there some documentation which stylesheet commands are supported >> by ensembl. The link to the ensembl stylesheet convention at http://www.dasregistry.org/spec_1.53E.jsp >> returns a 404 error. >> >> Thanks, >> Christian >> _______________________________________________ >> 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 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. From cruckert at uni-muenster.de Mon Sep 14 05:54:23 2009 From: cruckert at uni-muenster.de (Christian Ruckert) Date: Mon, 14 Sep 2009 11:54:23 +0200 Subject: [DAS] Scaling of DAS tracks In-Reply-To: References: <4AAA70CE.1040504@uni-muenster.de> <7664BC1E-53AE-43F6-AEF5-10F7B7DDBA00@ebi.ac.uk> <4348E052-028B-4497-804F-F00EC398ACB6@sanger.ac.uk> Message-ID: <4AAE12CF.4060409@uni-muenster.de> The problem is not http://www.dasregistry.org/spec_1.53E.jsp itself, but the Ensembl stylesheet convention link on that page http://www.ensembl.org/info/data/external_data/das/CSS_support.pdf Christian Andy Jenkinson schrieb: > That's odd, is the registry having any problems? I'm assuming the URL is > correct since it works for me! (still working) > > On 14 Sep 2009, at 10:18, Jonathan Warren wrote: > >> Hi Andy >> >> Gives a 404 for me as well.. >> >> On 14 Sep 2009, at 09:49, Andy Jenkinson wrote: >> >>> Hi Christian, >>> >>> Did you use the 'max' and 'min' properties? These tell the client how >>> to scale the data, otherwise it can only use the values it receives >>> for any one region to guess what they are. Ensembl makes no >>> assumptions that the scale for one track is the same for another, and >>> in the absence of explicit min/max values assumes that the maximum is >>> the highest score it received, and the minimum is the lowest. >>> >>> If however the maximum height of the track itself is different (i.e. >>> the height in pixels of the label region) this must be something >>> else. If you show me the stylesheet and features response I can take >>> a look for you. >>> >>> The documentation link you posted works for me, is it still giving a >>> 404? In any case, I believe Ensembl supports all of the stylesheet >>> functions in the specification. >>> >>> Cheers, >>> Andy >>> >>> On 11 Sep 2009, at 16:46, Christian Ruckert wrote: >>> >>>> I have provided a histogram stylesheet for my DAS tracks, as >>>> described at >>>> http://www.dasregistry.org/extension_stylesheet_histogram.jsp. >>>> >>>> Now when viewing my tracks in ensembl I have problems with the >>>> correct scaling. One track is displayed twice as high as the other, >>>> despite the score values are only half as high. >>>> >>>> Is there some documentation which stylesheet commands are supported >>>> by ensembl. The link to the ensembl stylesheet convention at >>>> http://www.dasregistry.org/spec_1.53E.jsp returns a 404 error. >>>> >>>> Thanks, >>>> Christian >>>> _______________________________________________ >>>> 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 -- Christian Ruckert Department of Medical Informatics and Biomathematics University of M?nster Domagkstrasse 9 48149 M?nster, Germany Tel.: +49 (0)251 83-58368 From thomas.a.down at googlemail.com Tue Sep 15 06:52:54 2009 From: thomas.a.down at googlemail.com (Thomas Down) Date: Tue, 15 Sep 2009 11:52:54 +0100 Subject: [DAS] maxbins in DAS1.6? Message-ID: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> As an enthusiastic user of the maxbins extension: http://www.dasregistry.org/extension_maxbins.jsp I note that this isn't currently mentioned in the DAS1.6 spec. Is the extension likely to be rolled into the revised spec? Left as an extension? Or is there some other plan out there now for handling high-density data? Thomas. From jw12 at sanger.ac.uk Tue Sep 15 07:14:17 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Tue, 15 Sep 2009 12:14:17 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> Message-ID: <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> Hi Thomas It's definitely going to be in 1.6 if it's not mentioned already. There is also testing and support now in the registry for maxbins with both the 1.5 and 1.6 specs. On 15 Sep 2009, at 11:52, Thomas Down wrote: > As an enthusiastic user of the maxbins extension: > > http://www.dasregistry.org/extension_maxbins.jsp > > I note that this isn't currently mentioned in the DAS1.6 spec. Is the > extension likely to be rolled into the revised spec? Left as an > extension? > Or is there some other plan out there now for handling high-density > data? > > Thomas. > _______________________________________________ > 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. From andy.jenkinson at ebi.ac.uk Tue Sep 15 07:26:05 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Tue, 15 Sep 2009 12:26:05 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> Message-ID: Hi Thomas, It is mentioned in the 1.6 spec (not sure which draft you are looking at). It is fully integrated into the spec as an optional capability that should be declared if supported (like feature-by-id etc) and is described in the features command section. http://www.ebi.ac.uk/~aj/1.6_draft3/documents/spec.html#features Cheers, Andy On 15 Sep 2009, at 12:14, Jonathan Warren wrote: > Hi Thomas > > It's definitely going to be in 1.6 if it's not mentioned already. > There is also testing and support now in the registry for maxbins > with both the 1.5 and 1.6 specs. > > > On 15 Sep 2009, at 11:52, Thomas Down wrote: > >> As an enthusiastic user of the maxbins extension: >> >> http://www.dasregistry.org/extension_maxbins.jsp >> >> I note that this isn't currently mentioned in the DAS1.6 spec. Is >> the >> extension likely to be rolled into the revised spec? Left as an >> extension? >> Or is there some other plan out there now for handling high-density >> data? >> >> Thomas. >> _______________________________________________ >> 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 From thomas.a.down at googlemail.com Tue Sep 15 07:27:15 2009 From: thomas.a.down at googlemail.com (Thomas Down) Date: Tue, 15 Sep 2009 12:27:15 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> Message-ID: <6a132cea0909150427x326d541pa694ae42fac77b37@mail.gmail.com> Out of curiosity, how are you testing the maxbins support (except, I guess, checking that servers don't blow up when sent the maxbins query parameter)? Also, is there any way for individual datasources to advertise whether or not they're implementing maxbins? In the past, clients have been able to re-use cached data when the user zooms in, but maxbins breaks that assumption. But it would be nice to be able to just re-fetch data for tiers which are actually likely to change when you zoom. Thomas. On Tue, Sep 15, 2009 at 12:14 PM, Jonathan Warren wrote: > Hi Thomas > > It's definitely going to be in 1.6 if it's not mentioned already. There is > also testing and support now in the registry for maxbins with both the 1.5 > and 1.6 specs. > > > > On 15 Sep 2009, at 11:52, Thomas Down wrote: > > As an enthusiastic user of the maxbins extension: >> >> http://www.dasregistry.org/extension_maxbins.jsp >> >> I note that this isn't currently mentioned in the DAS1.6 spec. Is the >> extension likely to be rolled into the revised spec? Left as an >> extension? >> Or is there some other plan out there now for handling high-density data? >> >> Thomas. >> _______________________________________________ >> 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. > From thomas.a.down at googlemail.com Tue Sep 15 07:30:44 2009 From: thomas.a.down at googlemail.com (Thomas Down) Date: Tue, 15 Sep 2009 12:30:44 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> Message-ID: <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> Ah, sorry, I was looking at: http://www.biodas.org/wiki/DAS1.6 But that's obviously out of date now, so I'll update my bookmarks. Also, I note that maxbins is now in the capabilities header, which I guess offers a possible solution to my question about which datasources need to be re-queried after zooming. Thomas. On Tue, Sep 15, 2009 at 12:26 PM, Andy Jenkinson wrote: > Hi Thomas, > > It is mentioned in the 1.6 spec (not sure which draft you are looking at). > It is fully integrated into the spec as an optional capability that should > be declared if supported (like feature-by-id etc) and is described in the > features command section. > http://www.ebi.ac.uk/~aj/1.6_draft3/documents/spec.html#features > > Cheers, > Andy > > > On 15 Sep 2009, at 12:14, Jonathan Warren wrote: > > Hi Thomas >> >> It's definitely going to be in 1.6 if it's not mentioned already. There is >> also testing and support now in the registry for maxbins with both the 1.5 >> and 1.6 specs. >> >> >> On 15 Sep 2009, at 11:52, Thomas Down wrote: >> >> As an enthusiastic user of the maxbins extension: >>> >>> http://www.dasregistry.org/extension_maxbins.jsp >>> >>> I note that this isn't currently mentioned in the DAS1.6 spec. Is the >>> extension likely to be rolled into the revised spec? Left as an >>> extension? >>> Or is there some other plan out there now for handling high-density data? >>> >>> Thomas. >>> _______________________________________________ >>> 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 >> > > From andy.jenkinson at ebi.ac.uk Tue Sep 15 07:40:50 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Tue, 15 Sep 2009 12:40:50 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> Message-ID: <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> 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. Regarding the question of how the registry checks maxbins, Jonathan will have to answer that one. Cheers, Andy On 15 Sep 2009, at 12:30, Thomas Down wrote: > Ah, sorry, I was looking at: > > http://www.biodas.org/wiki/DAS1.6 > > But that's obviously out of date now, so I'll update my bookmarks. > Also, I note that maxbins is now in the capabilities header, which I > guess offers a possible solution to my question about which > datasources need to be re-queried after zooming. > > Thomas. > > On Tue, Sep 15, 2009 at 12:26 PM, Andy Jenkinson > wrote: > Hi Thomas, > > It is mentioned in the 1.6 spec (not sure which draft you are > looking at). It is fully integrated into the spec as an optional > capability that should be declared if supported (like feature-by-id > etc) and is described in the features command section. > http://www.ebi.ac.uk/~aj/1.6_draft3/documents/spec.html#features > > Cheers, > Andy > > > On 15 Sep 2009, at 12:14, Jonathan Warren wrote: > > Hi Thomas > > It's definitely going to be in 1.6 if it's not mentioned already. > There is also testing and support now in the registry for maxbins > with both the 1.5 and 1.6 specs. > > > On 15 Sep 2009, at 11:52, Thomas Down wrote: > > As an enthusiastic user of the maxbins extension: > > http://www.dasregistry.org/extension_maxbins.jsp > > I note that this isn't currently mentioned in the DAS1.6 spec. Is the > extension likely to be rolled into the revised spec? Left as an > extension? > Or is there some other plan out there now for handling high-density > data? > > Thomas. > _______________________________________________ > 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 > > From thomas.a.down at googlemail.com Tue Sep 15 07:46:24 2009 From: thomas.a.down at googlemail.com (Thomas Down) Date: Tue, 15 Sep 2009 12:46:24 +0100 Subject: [DAS] Cross-origin resource sharing and DAS Message-ID: <6a132cea0909150446h2e8ea33lc91eaf9c035e1e45@mail.gmail.com> DAS server developers might be interested to take a look at the W3C/WHATWG cross-origin resource sharing stuff here: http://dev.w3.org/2006/waf/access-control/ There's also a rather more practical description of what this is good for here: https://developer.mozilla.org/En/HTTP_access_control My reading of all this is that if you're running a DAS server on a publically-accessible HTTP endpoint, you probably want to send a header along the lines of: Access-Control-Allow-Origin: * This is the now the default behaviour in SVN-latest versions of Dazzle. Note that this doesn't prevent you from securing your DAS servers (for instance by authenticating clients by password or IP address). It does, however, make life an awful lot easier for anyone who might be interested in fetching DAS data using Javascript code running in a browser. Thomas. From jw12 at sanger.ac.uk Tue Sep 15 07:54:15 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Tue, 15 Sep 2009 12:54:15 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <6a132cea0909150427x326d541pa694ae42fac77b37@mail.gmail.com> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150427x326d541pa694ae42fac77b37@mail.gmail.com> Message-ID: <3EC62B3A-BBE6-4C95-A379-123B1E37C776@sanger.ac.uk> At the moment the test is with a small maxbins parameter and a very large one and if the number of features returned is different then it is specified as a valid maxbins server. I think I found one server that supported maxbins and this crude test worked. If you have servers that use maxbins I'd be interested in using them for testing as I wouldn't be surprised if there are issues with this. The registry has recently changed so that it tests most capabilities irrespective of stated capabilities and shows a yellow light to indicate that a capability is possibly_valid. The registry sources cmd also has this information as a property. http://www.dasregistry.org/das/sources As you have just stated in your email - you can use capabilities in the headers for maxbins. The registry is being developed to look at headers now as well to give feedback and gather statistics on servers. Any feedback and suggestions obviously welcomed. Jonathan. On 15 Sep 2009, at 12:27, Thomas Down wrote: > Out of curiosity, how are you testing the maxbins support (except, I > guess, checking that servers don't blow up when sent the maxbins > query parameter)? > > Also, is there any way for individual datasources to advertise > whether or not they're implementing maxbins? In the past, clients > have been able to re-use cached data when the user zooms in, but > maxbins breaks that assumption. But it would be nice to be able to > just re-fetch data for tiers which are actually likely to change > when you zoom. > > Thomas. > > > > On Tue, Sep 15, 2009 at 12:14 PM, Jonathan Warren > wrote: > Hi Thomas > > It's definitely going to be in 1.6 if it's not mentioned already. > There is also testing and support now in the registry for maxbins > with both the 1.5 and 1.6 specs. > > > > On 15 Sep 2009, at 11:52, Thomas Down wrote: > > As an enthusiastic user of the maxbins extension: > > http://www.dasregistry.org/extension_maxbins.jsp > > I note that this isn't currently mentioned in the DAS1.6 spec. Is the > extension likely to be rolled into the revised spec? Left as an > extension? > Or is there some other plan out there now for handling high-density > data? > > Thomas. > _______________________________________________ > 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. > 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. From thomas.a.down at googlemail.com Tue Sep 15 08:43:24 2009 From: thomas.a.down at googlemail.com (Thomas Down) Date: Tue, 15 Sep 2009 13:43:24 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> Message-ID: <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> On Tue, Sep 15, 2009 at 12:40 PM, Andy Jenkinson 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? 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? Thomas. From jw12 at sanger.ac.uk Tue Sep 15 09:30:09 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Tue, 15 Sep 2009 14:30:09 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> Message-ID: <5F5C9142-8759-4DDC-B890-51E093FCD25D@sanger.ac.uk> This information should be provided in the sources response from a server and is also provided in the registry sources response. If I was writing a client I would make use of the registry as many sources do not implement the sources command. This is one reason why we often consider making a souces response compulsory for registration. However as the registry provides this info it is almost overkill to have it twice. On 15 Sep 2009, at 13:43, Thomas Down wrote: > On Tue, Sep 15, 2009 at 12:40 PM, Andy Jenkinson > 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? > > 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? > > Thomas. > _______________________________________________ > 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. From andy.jenkinson at ebi.ac.uk Tue Sep 15 09:34:01 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Tue, 15 Sep 2009 14:34:01 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> Message-ID: On 15 Sep 2009, at 13:43, Thomas Down wrote: > On Tue, Sep 15, 2009 at 12:40 PM, Andy Jenkinson > 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: 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. From andy.jenkinson at ebi.ac.uk Tue Sep 15 09:35:24 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Tue, 15 Sep 2009 14:35:24 +0100 Subject: [DAS] Cross-origin resource sharing and DAS In-Reply-To: <6a132cea0909150446h2e8ea33lc91eaf9c035e1e45@mail.gmail.com> References: <6a132cea0909150446h2e8ea33lc91eaf9c035e1e45@mail.gmail.com> Message-ID: Just to add, the latest trunk version of ProServer also does this. On 15 Sep 2009, at 12:46, Thomas Down wrote: > DAS server developers might be interested to take a look at the W3C/ > WHATWG > cross-origin resource sharing stuff here: > > http://dev.w3.org/2006/waf/access-control/ > > There's also a rather more practical description of what this is > good for > here: > > https://developer.mozilla.org/En/HTTP_access_control > > My reading of all this is that if you're running a DAS server on a > publically-accessible HTTP endpoint, you probably want to send a > header > along the lines of: > > Access-Control-Allow-Origin: * > > This is the now the default behaviour in SVN-latest versions of > Dazzle. > Note that this doesn't prevent you from securing your DAS servers (for > instance by authenticating clients by password or IP address). It > does, > however, make life an awful lot easier for anyone who might be > interested in > fetching DAS data using Javascript code running in a browser. > > Thomas. > _______________________________________________ > DAS mailing list > DAS at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/das From jw12 at sanger.ac.uk Tue Sep 15 09:54:27 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Tue, 15 Sep 2009 14:54:27 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> Message-ID: <94A21C9F-C141-4789-952E-9CC21EEA537A@sanger.ac.uk> 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 > > 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: > > > 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. From thomas.a.down at googlemail.com Tue Sep 15 10:19:52 2009 From: thomas.a.down at googlemail.com (Thomas Down) Date: Tue, 15 Sep 2009 15:19:52 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> Message-ID: <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> On Tue, Sep 15, 2009 at 2:34 PM, Andy Jenkinson wrote: > > 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: > > 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.: Assume any missing version attributes are "1.0" and everything should be backwards compatible. > 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. Thomas. From andy.jenkinson at ebi.ac.uk Tue Sep 15 10:47:04 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Tue, 15 Sep 2009 15:47:04 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> Message-ID: <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> On 15 Sep 2009, at 15:19, Thomas Down wrote: > Capabilities are stated in the sources document: > > > 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.: > > > > > 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. From andy.jenkinson at ebi.ac.uk Tue Sep 15 10:57:42 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Tue, 15 Sep 2009 15:57:42 +0100 Subject: [DAS] Cross-origin resource sharing and DAS In-Reply-To: References: <6a132cea0909150446h2e8ea33lc91eaf9c035e1e45@mail.gmail.com> Message-ID: <481247C7-2A74-4470-BC22-F83A0F0C4279@ebi.ac.uk> Thinking ahead a little bit, the potential benefit of formally adopting this in DAS is huge - beyond the current set of simple GET requests, it actually makes authenticated cross site requests such as for writeback work, which at the moment will be very difficult to make work. I was wondering if we should just add a requirement to handle this to the DAS spec, with an example of course. It's very simple to implement and we could potentially dodge a big bullet by making all 1.6+ servers do it now. By the time it's supported in all browsers we could have a large proportion of DAS servers supporting it. Cheers, Andy > Just to add, the latest trunk version of ProServer also does this. > > On 15 Sep 2009, at 12:46, Thomas Down wrote: > >> DAS server developers might be interested to take a look at the W3C/ >> WHATWG >> cross-origin resource sharing stuff here: >> >> http://dev.w3.org/2006/waf/access-control/ >> >> There's also a rather more practical description of what this is >> good for >> here: >> >> https://developer.mozilla.org/En/HTTP_access_control >> >> My reading of all this is that if you're running a DAS server on a >> publically-accessible HTTP endpoint, you probably want to send a >> header >> along the lines of: >> >> Access-Control-Allow-Origin: * >> >> This is the now the default behaviour in SVN-latest versions of >> Dazzle. >> Note that this doesn't prevent you from securing your DAS servers >> (for >> instance by authenticating clients by password or IP address). It >> does, >> however, make life an awful lot easier for anyone who might be >> interested in >> fetching DAS data using Javascript code running in a browser. >> >> Thomas. >> _______________________________________________ >> 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 From jw12 at sanger.ac.uk Tue Sep 15 11:35:25 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Tue, 15 Sep 2009 16:35:25 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> Message-ID: 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: >> >> >> 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.: >> >> >> >> >> 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. From thomas.a.down at googlemail.com Tue Sep 15 12:28:29 2009 From: thomas.a.down at googlemail.com (Thomas Down) Date: Tue, 15 Sep 2009 17:28:29 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> Message-ID: <6a132cea0909150928i4a5f5cf1t591405a6ea22d78a@mail.gmail.com> On Tue, Sep 15, 2009 at 4:35 PM, Jonathan Warren wrote: > > 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. > What would you put there? HTML "welcome" information (which seems to be ProServer's current behaviour)? DAS XML? (in which case... the relevant SOURCE element, or something else)? DAS XML with some strong encouragement for servers to attach a stylesheet to turn it into something readable if you hit it with a browser? Currently, Dazzle just returns an error, because it interacts rather nastily with the way Dazzle supports hierarchical datasource namespaces. Having said that, the original use case for these hasn't really materialized, so it wouldn't be a big deal to strip this out. Thomas. From andy.jenkinson at ebi.ac.uk Tue Sep 15 12:42:48 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Tue, 15 Sep 2009 17:42:48 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <6a132cea0909150928i4a5f5cf1t591405a6ea22d78a@mail.gmail.com> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <6a132cea0909150928i4a5f5cf1t591405a6ea22d78a@mail.gmail.com> Message-ID: <0D609878-B3B5-48BF-8295-FEE666D346EF@ebi.ac.uk> On 15 Sep 2009, at 17:28, Thomas Down wrote: > > > On Tue, Sep 15, 2009 at 4:35 PM, Jonathan Warren > wrote: > > 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. > > What would you put there? HTML "welcome" information (which seems > to be ProServer's current behaviour)? DAS XML? (in which case... > the relevant SOURCE element, or something else)? DAS XML with some > strong encouragement for servers to attach a stylesheet to turn it > into something readable if you hit it with a browser? DAS sources XML seems the obvious choice, and existing sources XSL stylesheets should parse it anyway. From jw12 at sanger.ac.uk Tue Sep 15 12:56:38 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Tue, 15 Sep 2009 17:56:38 +0100 Subject: [DAS] pinging source In-Reply-To: <6a132cea0909150928i4a5f5cf1t591405a6ea22d78a@mail.gmail.com> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <6a132cea0909150928i4a5f5cf1t591405a6ea22d78a@mail.gmail.com> Message-ID: <2DCCF817-8D25-4745-9951-65BA2FEA78AD@sanger.ac.uk> My vote at the moment would be to have the source element. On a side note: My vote would also be to not have nice human readable stylesheets at all ;) Though I accept I may be a lone voice on this one. Mainly because I want DAS to be as powerful as possible while being easy for new users to get into ( some people who have provided das sources for years have not known they could just right click and select "show source" to get the xml and see that their new elements are shown in the xml but are not in the stylesheet!!). It justs adds a layer of complexity and confusion for little gain in my opinion. The alternative would be to have raw xml as default and stylesheet as an option - presumably that could be done? Maybe I missed the whole point about putting them in? Surely people use das in a browser for discovery and testing not actually viewing data on a day to day basis? On 15 Sep 2009, at 17:28, Thomas Down wrote: > > > On Tue, Sep 15, 2009 at 4:35 PM, Jonathan Warren > wrote: > > 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. > > What would you put there? HTML "welcome" information (which seems > to be ProServer's current behaviour)? DAS XML? (in which case... > the relevant SOURCE element, or something else)? DAS XML with some > strong encouragement for servers to attach a stylesheet to turn it > into something readable if you hit it with a browser? > > Currently, Dazzle just returns an error, because it interacts rather > nastily with the way Dazzle supports hierarchical datasource > namespaces. Having said that, the original use case for these > hasn't really materialized, so it wouldn't be a big deal to strip > this out. > > Thomas. 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. From andy.jenkinson at ebi.ac.uk Tue Sep 15 12:56:16 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Tue, 15 Sep 2009 17:56:16 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> Message-ID: On 15 Sep 2009, at 16:35, Jonathan Warren wrote: > 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!!! My take on this is that the root URI identifies the source. In a conceptual sense the definition of a source is merely a combination of commands acting on a common set of data. It is not really important where that information comes from (a registry, a server, a flat file...) because a server by itself does not really mean anything. So the URI http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat is not actually meaningful, even less so given it is not even a resolvable URL. The query URI system inherited from DAS/2 has the potential to allow the commands to be served from different locations on the web. It is not something we have needed up to now (all query URIs start with the same path), and does add confusion but I can see it being used for stylesheets. For example a "sequence ontology stylesheet" served from a single location. But the biggest reason to have it is because of the registry. The registry assigns its own root URIs for a DAS source (e.g. DS_1234), which means it is necessary to provide another URI used to actually query it. Since we already have a way of doing it in the sources document, I don't really want to change it now. It seems we might as well just embrace the extra flexibility and merely describe it better. > 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: >>> >>> >>> 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.: >>> >>> >>> >>> >>> 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 > 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. From andy.jenkinson at ebi.ac.uk Tue Sep 15 13:04:03 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Tue, 15 Sep 2009 18:04:03 +0100 Subject: [DAS] pinging source In-Reply-To: <2DCCF817-8D25-4745-9951-65BA2FEA78AD@sanger.ac.uk> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <6a132cea0909150928i4a5f5cf1t591405a6ea22d78a@mail.gmail.com> <2DCCF817-8D25-4745-9951-65BA2FEA78AD@sanger.ac.uk> Message-ID: <65B5FB4F-D234-4B31-B278-C1B7DF786069@ebi.ac.uk> I'm not sure if you meant the sources schema exactly as it is or to make the element the root element. I would vote for the former (i.e. a sources document containing one source). It makes things much easier for the client and spec not to have a separate schema. Regarding the XSL stylesheets, I can see where you're coming from. I have some prototype stylesheets which have an option to show the XML (prettied up), which I think is the best compromise. On 15 Sep 2009, at 17:56, Jonathan Warren wrote: > My vote at the moment would be to have the source element. > > On a side note: My vote would also be to not have nice human > readable stylesheets at all ;) Though I accept I may be a lone voice > on this one. Mainly because I want DAS to be as powerful as possible > while being easy for new users to get into ( some people who have > provided das sources for years have not known they could just right > click and select "show source" to get the xml and see that their new > elements are shown in the xml but are not in the stylesheet!!). It > justs adds a layer of complexity and confusion for little gain in my > opinion. The alternative would be to have raw xml as default and > stylesheet as an option - presumably that could be done? Maybe I > missed the whole point about putting them in? Surely people use das > in a browser for discovery and testing not actually viewing data on > a day to day basis? > > > > > > On 15 Sep 2009, at 17:28, Thomas Down wrote: > >> >> >> On Tue, Sep 15, 2009 at 4:35 PM, Jonathan Warren >> wrote: >> >> 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. >> >> What would you put there? HTML "welcome" information (which seems >> to be ProServer's current behaviour)? DAS XML? (in which case... >> the relevant SOURCE element, or something else)? DAS XML with some >> strong encouragement for servers to attach a stylesheet to turn it >> into something readable if you hit it with a browser? >> >> Currently, Dazzle just returns an error, because it interacts >> rather nastily with the way Dazzle supports hierarchical datasource >> namespaces. Having said that, the original use case for these >> hasn't really materialized, so it wouldn't be a big deal to strip >> this out. >> >> Thomas. > > 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. From jw12 at sanger.ac.uk Tue Sep 15 13:11:45 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Tue, 15 Sep 2009 18:11:45 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> Message-ID: <340E3FD0-D7BF-4C5E-A010-5A5CAF2E6670@sanger.ac.uk> Andy I wasn't suggesting we get rid of query_uri - quite the opposite in fact. just that the single source uri would have to be specified with a uri as conceptually all other commands may not contain the root uri. This also seems to me means we will have to update das1 code to cope with multiple query uris. On 15 Sep 2009, at 17:56, Andy Jenkinson wrote: > On 15 Sep 2009, at 16:35, Jonathan Warren wrote: > >> 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!!! > > My take on this is that the root URI identifies the source. In a > conceptual sense the definition of a source is merely a combination > of commands acting on a common set of data. It is not really > important where that information comes from (a registry, a server, a > flat file...) because a server by itself does not really mean > anything. So the URI http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat > is not actually meaningful, even less so given it is not even a > resolvable URL. > > The query URI system inherited from DAS/2 has the potential to allow > the commands to be served from different locations on the web. It is > not something we have needed up to now (all query URIs start with > the same path), and does add confusion but I can see it being used > for stylesheets. For example a "sequence ontology stylesheet" served > from a single location. > > But the biggest reason to have it is because of the registry. The > registry assigns its own root URIs for a DAS source (e.g. DS_1234), > which means it is necessary to provide another URI used to actually > query it. Since we already have a way of doing it in the sources > document, I don't really want to change it now. It seems we might as > well just embrace the extra flexibility and merely describe it better. > >> 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: >>>> >>>> >>>> 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.: >>>> >>>> >>>> >>>> >>>> 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 >> 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. > 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. From jw12 at sanger.ac.uk Tue Sep 15 13:13:01 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Tue, 15 Sep 2009 18:13:01 +0100 Subject: [DAS] pinging source In-Reply-To: <65B5FB4F-D234-4B31-B278-C1B7DF786069@ebi.ac.uk> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <6a132cea0909150928i4a5f5cf1t591405a6ea22d78a@mail.gmail.com> <2DCCF817-8D25-4745-9951-65BA2FEA78AD@sanger.ac.uk> <65B5FB4F-D234-4B31-B278-C1B7DF786069@ebi.ac.uk> Message-ID: <23A26EA2-B5AE-4F26-AD28-EB6BC5943207@sanger.ac.uk> yes - sources as it normally is but without all the other sources ;) On 15 Sep 2009, at 18:04, Andy Jenkinson wrote: > I'm not sure if you meant the sources schema exactly as it is or to > make the element the root element. I would vote for the > former (i.e. a sources document containing one source). It makes > things much easier for the client and spec not to have a separate > schema. > > Regarding the XSL stylesheets, I can see where you're coming from. I > have some prototype stylesheets which have an option to show the XML > (prettied up), which I think is the best compromise. > > On 15 Sep 2009, at 17:56, Jonathan Warren wrote: > >> My vote at the moment would be to have the source element. >> >> On a side note: My vote would also be to not have nice human >> readable stylesheets at all ;) Though I accept I may be a lone >> voice on this one. Mainly because I want DAS to be as powerful as >> possible while being easy for new users to get into ( some people >> who have provided das sources for years have not known they could >> just right click and select "show source" to get the xml and see >> that their new elements are shown in the xml but are not in the >> stylesheet!!). It justs adds a layer of complexity and confusion >> for little gain in my opinion. The alternative would be to have raw >> xml as default and stylesheet as an option - presumably that could >> be done? Maybe I missed the whole point about putting them in? >> Surely people use das in a browser for discovery and testing not >> actually viewing data on a day to day basis? >> >> >> >> >> >> On 15 Sep 2009, at 17:28, Thomas Down wrote: >> >>> >>> >>> On Tue, Sep 15, 2009 at 4:35 PM, Jonathan Warren >>> wrote: >>> >>> 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. >>> >>> What would you put there? HTML "welcome" information (which seems >>> to be ProServer's current behaviour)? DAS XML? (in which case... >>> the relevant SOURCE element, or something else)? DAS XML with >>> some strong encouragement for servers to attach a stylesheet to >>> turn it into something readable if you hit it with a browser? >>> >>> Currently, Dazzle just returns an error, because it interacts >>> rather nastily with the way Dazzle supports hierarchical >>> datasource namespaces. Having said that, the original use case >>> for these hasn't really materialized, so it wouldn't be a big deal >>> to strip this out. >>> >>> Thomas. >> >> 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. > 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. From Steve_Chervitz at affymetrix.com Tue Sep 15 14:20:16 2009 From: Steve_Chervitz at affymetrix.com (Chervitz, Steve) Date: Tue, 15 Sep 2009 11:20:16 -0700 Subject: [DAS] pinging source In-Reply-To: <65B5FB4F-D234-4B31-B278-C1B7DF786069@ebi.ac.uk> Message-ID: Andy Jenkinson wrote on 15 Sep 2009 10:04:03 -0700: > > I'm not sure if you meant the sources schema exactly as it is or to > make the element the root element. I would vote for the > former (i.e. a sources document containing one source). It makes > things much easier for the client and spec not to have a separate > schema. > > Regarding the XSL stylesheets, I can see where you're coming from. I > have some prototype stylesheets which have an option to show the XML > (prettied up), which I think is the best compromise. Optional stylesheets for web browsing sounds fine. On a related note re XSL: Stylesheets can also be used to communicate information to DAS clients, to control browser behavior with certain tracks. For example, we are doing this with the Genoviz DAS2 server to provide auto-load hints to IGB to indicate whether all features of a particular data type should be loaded for a given genomic sequence (chromosome) or if it should be loaded on-demand. Do any of the DAS 1.5/1.6-based servers and clients do something like this? Steve On 15 Sep 2009, at 17:56, Jonathan Warren wrote: > My vote at the moment would be to have the source element. > > On a side note: My vote would also be to not have nice human > readable stylesheets at all ;) Though I accept I may be a lone voice > on this one. Mainly because I want DAS to be as powerful as possible > while being easy for new users to get into ( some people who have > provided das sources for years have not known they could just right > click and select "show source" to get the xml and see that their new > elements are shown in the xml but are not in the stylesheet!!). It > justs adds a layer of complexity and confusion for little gain in my > opinion. The alternative would be to have raw xml as default and > stylesheet as an option - presumably that could be done? Maybe I > missed the whole point about putting them in? Surely people use das > in a browser for discovery and testing not actually viewing data on > a day to day basis? > > > > > > On 15 Sep 2009, at 17:28, Thomas Down wrote: > >> >> >> On Tue, Sep 15, 2009 at 4:35 PM, Jonathan Warren >> wrote: >> >> 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. >> >> What would you put there? HTML "welcome" information (which seems >> to be ProServer's current behaviour)? DAS XML? (in which case... >> the relevant SOURCE element, or something else)? DAS XML with some >> strong encouragement for servers to attach a stylesheet to turn it >> into something readable if you hit it with a browser? >> >> Currently, Dazzle just returns an error, because it interacts >> rather nastily with the way Dazzle supports hierarchical datasource >> namespaces. Having said that, the original use case for these >> hasn't really materialized, so it wouldn't be a big deal to strip >> this out. >> >> Thomas. > > 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. _______________________________________________ DAS mailing list DAS at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/das ------------------------------------------------------------ This transmission is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. You are hereby notified that any use, dissemination, distribution or duplication of this transmission by someone other than the intended addressee or its designated agent is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by reply to this transmission and delete it from your computer. From thomas.a.down at googlemail.com Tue Sep 15 15:24:18 2009 From: thomas.a.down at googlemail.com (Thomas Down) Date: Tue, 15 Sep 2009 20:24:18 +0100 Subject: [DAS] pinging source In-Reply-To: References: <65B5FB4F-D234-4B31-B278-C1B7DF786069@ebi.ac.uk> Message-ID: <6a132cea0909151224je810cdbja4e5b9560936e272@mail.gmail.com> On Tue, Sep 15, 2009 at 7:20 PM, Chervitz, Steve < Steve_Chervitz at affymetrix.com> wrote: > Andy Jenkinson wrote on 15 Sep 2009 10:04:03 -0700: > > > > I'm not sure if you meant the sources schema exactly as it is or to > > make the element the root element. I would vote for the > > former (i.e. a sources document containing one source). It makes > > things much easier for the client and spec not to have a separate > > schema. > > > > Regarding the XSL stylesheets, I can see where you're coming from. I > > have some prototype stylesheets which have an option to show the XML > > (prettied up), which I think is the best compromise. > > Optional stylesheets for web browsing sounds fine. > > On a related note re XSL: Stylesheets can also be used to communicate > information to DAS clients, to control browser behavior with certain tracks. > For example, we are doing this with the Genoviz DAS2 server to provide > auto-load hints to IGB to indicate whether all features of a particular data > type should be loaded for a given genomic sequence (chromosome) or if it > should be loaded on-demand. > Do you have a small example of how this works? I can see how this kind of information is useful, but it's not obvious to me how you can encode it as XSL rather than something DAS-specific? > Do any of the DAS 1.5/1.6-based servers and clients do something like this? > At one point, the old biojava DAS client code (which was used in an early demonstration heavy-client DAS application, but may have bit-rotted by now) would use the feature-counts in the 'types' response to estimate feature density, and => sensible sizes of tiles to use when fetching features. I seem to remember that this worked fairly well against some servers, but was a bit tempremental because: 1) the feature counts are optional. 2) Even when they are implemented, some servers (at the time, anyway) could be pretty slow about returning them. ...so it's not a silver bullet. I could certainly imagine some kind of "density hint" attribute in a stylesheet being helpful. Thomas. From andy.jenkinson at ebi.ac.uk Wed Sep 16 04:25:00 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Wed, 16 Sep 2009 09:25:00 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <340E3FD0-D7BF-4C5E-A010-5A5CAF2E6670@sanger.ac.uk> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <340E3FD0-D7BF-4C5E-A010-5A5CAF2E6670@sanger.ac.uk> Message-ID: What I meant was that the root URI isn't actually used for anything, at best it's just the location of the description you're already reading. That would mean that adding another field to capture it wouldn't be of particular benefit. Whether we can easily remove the 'paradigm' of server/das/source/ command without confusing people is something else! On 15 Sep 2009, at 18:11, Jonathan Warren wrote: > Andy I wasn't suggesting we get rid of query_uri - quite the > opposite in fact. just that the single source uri would have to be > specified with a uri as conceptually all other commands may not > contain the root uri. This also seems to me means we will have to > update das1 code to cope with multiple query uris. > > On 15 Sep 2009, at 17:56, Andy Jenkinson wrote: > >> On 15 Sep 2009, at 16:35, Jonathan Warren wrote: >> >>> 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!!! >> >> My take on this is that the root URI identifies the source. In a >> conceptual sense the definition of a source is merely a combination >> of commands acting on a common set of data. It is not really >> important where that information comes from (a registry, a server, >> a flat file...) because a server by itself does not really mean >> anything. So the URI http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat >> is not actually meaningful, even less so given it is not even a >> resolvable URL. >> >> The query URI system inherited from DAS/2 has the potential to >> allow the commands to be served from different locations on the >> web. It is not something we have needed up to now (all query URIs >> start with the same path), and does add confusion but I can see it >> being used for stylesheets. For example a "sequence ontology >> stylesheet" served from a single location. >> >> But the biggest reason to have it is because of the registry. The >> registry assigns its own root URIs for a DAS source (e.g. DS_1234), >> which means it is necessary to provide another URI used to actually >> query it. Since we already have a way of doing it in the sources >> document, I don't really want to change it now. It seems we might >> as well just embrace the extra flexibility and merely describe it >> better. >> >>> 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: >>>>> >>>>> >>>>> 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.: >>>>> >>>>> >>>>> >>>>> >>>>> 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 >>> 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. >> > > 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. From thomas.a.down at googlemail.com Wed Sep 16 04:31:28 2009 From: thomas.a.down at googlemail.com (Thomas Down) Date: Wed, 16 Sep 2009 09:31:28 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <340E3FD0-D7BF-4C5E-A010-5A5CAF2E6670@sanger.ac.uk> Message-ID: <6a132cea0909160131g43b885cfq8a4601f82f872a0c@mail.gmail.com> On Wed, Sep 16, 2009 at 9:25 AM, Andy Jenkinson wrote: > > Whether we can easily remove the 'paradigm' of server/das/source/command > without confusing people is something else! I'd be pretty cautious about this -- it would break many (I'd guess nearly all, actually) clients that are currently building their queries by URL concatenation. Thomas. From jw12 at sanger.ac.uk Wed Sep 16 05:28:13 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Wed, 16 Sep 2009 10:28:13 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <340E3FD0-D7BF-4C5E-A010-5A5CAF2E6670@sanger.ac.uk> Message-ID: I think Thomas is right in that we can't change the das1 base url principle at least for 1.6 anyway, as it is supposed to be a consolidation. As there have been no objections to using for example http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat as a single source request we can put that into 1.6. The only real change would need to be in the registry. See explanation below. But we can get around that. > What I meant was that the root URI isn't actually used for anything, > at best it's just the location of the description you're already > reading. Except for the registry sources command where there is then no link back to where the server you are talking about is (as you are not at the server) apart from the query_uri's (example 1 below). das2 has "xml:base", but that is then for all sources so wouldn't work for the registry see example 2 below. We could always add another prop to the registry I guess ;) example1 registry sources: UniParc,Protein Sequence IPI,Protein Sequence UniProt,Protein Sequence das2 has xml:base, but that is then for all sources so wouldn't work for the registry: xml:base="http://bioserver.hci.utah.edu:8080/DAS2/das2/" > On 16 Sep 2009, at 09:25, Andy Jenkinson wrote: > What I meant was that the root URI isn't actually used for anything, > at best it's just the location of the description you're already > reading. That would mean that adding another field to capture it > wouldn't be of particular benefit. > > Whether we can easily remove the 'paradigm' of server/das/source/ > command without confusing people is something else! > > On 15 Sep 2009, at 18:11, Jonathan Warren wrote: > >> Andy I wasn't suggesting we get rid of query_uri - quite the >> opposite in fact. just that the single source uri would have to be >> specified with a uri as conceptually all other commands may not >> contain the root uri. This also seems to me means we will have to >> update das1 code to cope with multiple query uris. >> >> On 15 Sep 2009, at 17:56, Andy Jenkinson wrote: >> >>> On 15 Sep 2009, at 16:35, Jonathan Warren wrote: >>> >>>> 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!!! >>> >>> My take on this is that the root URI identifies the source. In a >>> conceptual sense the definition of a source is merely a >>> combination of commands acting on a common set of data. It is not >>> really important where that information comes from (a registry, a >>> server, a flat file...) because a server by itself does not really >>> mean anything. So the URI http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat >>> is not actually meaningful, even less so given it is not even a >>> resolvable URL. >>> >>> The query URI system inherited from DAS/2 has the potential to >>> allow the commands to be served from different locations on the >>> web. It is not something we have needed up to now (all query URIs >>> start with the same path), and does add confusion but I can see it >>> being used for stylesheets. For example a "sequence ontology >>> stylesheet" served from a single location. >>> >>> But the biggest reason to have it is because of the registry. The >>> registry assigns its own root URIs for a DAS source (e.g. >>> DS_1234), which means it is necessary to provide another URI used >>> to actually query it. Since we already have a way of doing it in >>> the sources document, I don't really want to change it now. It >>> seems we might as well just embrace the extra flexibility and >>> merely describe it better. >>> >>>> 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: >>>>>> >>>>>> >>>>>> 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.: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 >>>> 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. >>> >> >> 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. > 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. From thomas.a.down at googlemail.com Wed Sep 16 05:53:07 2009 From: thomas.a.down at googlemail.com (Thomas Down) Date: Wed, 16 Sep 2009 10:53:07 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <340E3FD0-D7BF-4C5E-A010-5A5CAF2E6670@sanger.ac.uk> Message-ID: <6a132cea0909160253p456cb57s8cbd6a882643210c@mail.gmail.com> On Wed, Sep 16, 2009 at 10:28 AM, Jonathan Warren wrote: > > das2 has "xml:base", but that is then for all sources so wouldn't work for > the registry see example 2 below. We could always add another prop to the > registry I guess ;) > Actually, I think it would. Since xml:base can be applied to any element, there's nothing to stop you doing: However, I don't think it's quite in the spirit of xml:base to assign semantics to the presence (or absence) of xml:base attributes -- it's just mean to control the handling of relative URIs. Thomas. From andy.jenkinson at ebi.ac.uk Wed Sep 16 06:28:14 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Wed, 16 Sep 2009 11:28:14 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <340E3FD0-D7BF-4C5E-A010-5A5CAF2E6670@sanger.ac.uk> Message-ID: Taking aside the issue surrounding the paradigm I mentioned and Thomas expanded on, why do you actually need to have a URL for the "server" itself? Given you already have all the metadata and command URLs you can't learn anything more from it. On 16 Sep 2009, at 10:28, Jonathan Warren wrote: > I think Thomas is right in that we can't change the das1 base url > principle at least for 1.6 anyway, as it is supposed to be a > consolidation. > > As there have been no objections to using for example http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat > as a single source request we can put that into 1.6. The only real > change would need to be in the registry. See explanation below. But > we can get around that. > >> What I meant was that the root URI isn't actually used for >> anything, at best it's just the location of the description you're >> already reading. > Except for the registry sources command where there is then no link > back to where the server you are talking about is (as you are not at > the server) apart from the query_uri's (example 1 below). > > das2 has "xml:base", but that is then for all sources so wouldn't > work for the registry see example 2 below. We could always add > another prop to the registry I guess ;) > > > example1 registry sources: > > > > > test_range="UPI00000017EA">UniParc,Protein Sequence > test_range="IPI00000021">IPI,Protein Sequence > test_range="P00280">UniProt,Protein Sequence > > > > > > > > > > > > > > > > > > > > > > > > > > > > > das2 has xml:base, but that is then for all sources so wouldn't work > for the registry: > > xml:base="http://bioserver.hci.utah.edu:8080/DAS2/das2/" > > > > created="2008-01-03 14:39:44" > > > > > > > > > On 16 Sep 2009, at 09:25, Andy Jenkinson wrote: > >> What I meant was that the root URI isn't actually used for >> anything, at best it's just the location of the description you're >> already reading. That would mean that adding another field to >> capture it wouldn't be of particular benefit. >> >> Whether we can easily remove the 'paradigm' of server/das/source/ >> command without confusing people is something else! >> >> On 15 Sep 2009, at 18:11, Jonathan Warren wrote: >> >>> Andy I wasn't suggesting we get rid of query_uri - quite the >>> opposite in fact. just that the single source uri would have to be >>> specified with a uri as conceptually all other commands may not >>> contain the root uri. This also seems to me means we will have to >>> update das1 code to cope with multiple query uris. >>> >>> On 15 Sep 2009, at 17:56, Andy Jenkinson wrote: >>> >>>> On 15 Sep 2009, at 16:35, Jonathan Warren wrote: >>>> >>>>> 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!!! >>>> >>>> My take on this is that the root URI identifies the source. In a >>>> conceptual sense the definition of a source is merely a >>>> combination of commands acting on a common set of data. It is not >>>> really important where that information comes from (a registry, a >>>> server, a flat file...) because a server by itself does not >>>> really mean anything. So the URI http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat >>>> is not actually meaningful, even less so given it is not even a >>>> resolvable URL. >>>> >>>> The query URI system inherited from DAS/2 has the potential to >>>> allow the commands to be served from different locations on the >>>> web. It is not something we have needed up to now (all query URIs >>>> start with the same path), and does add confusion but I can see >>>> it being used for stylesheets. For example a "sequence ontology >>>> stylesheet" served from a single location. >>>> >>>> But the biggest reason to have it is because of the registry. The >>>> registry assigns its own root URIs for a DAS source (e.g. >>>> DS_1234), which means it is necessary to provide another URI used >>>> to actually query it. Since we already have a way of doing it in >>>> the sources document, I don't really want to change it now. It >>>> seems we might as well just embrace the extra flexibility and >>>> merely describe it better. >>>> >>>>> 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: >>>>>>> >>>>>>> >>>>>>> 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.: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>> 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. >>>> >>> >>> 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. >> > > 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. From jw12 at sanger.ac.uk Wed Sep 16 06:46:20 2009 From: jw12 at sanger.ac.uk (Jonathan Warren) Date: Wed, 16 Sep 2009 11:46:20 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <340E3FD0-D7BF-4C5E-A010-5A5CAF2E6670@sanger.ac.uk> Message-ID: <02696626-5424-4089-A177-3AF8D776067A@sanger.ac.uk> which takes us back to my very first point that it would need to be a command url in itself and specified otherwise how do you get the info for a single source. On 16 Sep 2009, at 11:28, Andy Jenkinson wrote: > Taking aside the issue surrounding the paradigm I mentioned and > Thomas expanded on, why do you actually need to have a URL for the > "server" itself? Given you already have all the metadata and command > URLs you can't learn anything more from it. > > On 16 Sep 2009, at 10:28, Jonathan Warren wrote: > >> I think Thomas is right in that we can't change the das1 base url >> principle at least for 1.6 anyway, as it is supposed to be a >> consolidation. >> >> As there have been no objections to using for example http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat >> as a single source request we can put that into 1.6. The only real >> change would need to be in the registry. See explanation below. But >> we can get around that. >> >>> What I meant was that the root URI isn't actually used for >>> anything, at best it's just the location of the description you're >>> already reading. >> Except for the registry sources command where there is then no link >> back to where the server you are talking about is (as you are not >> at the server) apart from the query_uri's (example 1 below). >> >> das2 has "xml:base", but that is then for all sources so wouldn't >> work for the registry see example 2 below. We could always add >> another prop to the registry I guess ;) >> >> >> example1 registry sources: >> >> >> >> >> > test_range="UPI00000017EA">UniParc,Protein Sequence >> > test_range="IPI00000021">IPI,Protein Sequence >> > test_range="P00280">UniProt,Protein Sequence >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> das2 has xml:base, but that is then for all sources so wouldn't >> work for the registry: >> >> xml:base="http://bioserver.hci.utah.edu:8080/DAS2/das2/" > >> >> >> > created="2008-01-03 14:39:44" > >> >> >> >> >> >> >> >> On 16 Sep 2009, at 09:25, Andy Jenkinson wrote: >> >>> What I meant was that the root URI isn't actually used for >>> anything, at best it's just the location of the description you're >>> already reading. That would mean that adding another field to >>> capture it wouldn't be of particular benefit. >>> >>> Whether we can easily remove the 'paradigm' of server/das/source/ >>> command without confusing people is something else! >>> >>> On 15 Sep 2009, at 18:11, Jonathan Warren wrote: >>> >>>> Andy I wasn't suggesting we get rid of query_uri - quite the >>>> opposite in fact. just that the single source uri would have to >>>> be specified with a uri as conceptually all other commands may >>>> not contain the root uri. This also seems to me means we will >>>> have to update das1 code to cope with multiple query uris. >>>> >>>> On 15 Sep 2009, at 17:56, Andy Jenkinson wrote: >>>> >>>>> On 15 Sep 2009, at 16:35, Jonathan Warren wrote: >>>>> >>>>>> 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!!! >>>>> >>>>> My take on this is that the root URI identifies the source. In a >>>>> conceptual sense the definition of a source is merely a >>>>> combination of commands acting on a common set of data. It is >>>>> not really important where that information comes from (a >>>>> registry, a server, a flat file...) because a server by itself >>>>> does not really mean anything. So the URI http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat >>>>> is not actually meaningful, even less so given it is not even a >>>>> resolvable URL. >>>>> >>>>> The query URI system inherited from DAS/2 has the potential to >>>>> allow the commands to be served from different locations on the >>>>> web. It is not something we have needed up to now (all query >>>>> URIs start with the same path), and does add confusion but I can >>>>> see it being used for stylesheets. For example a "sequence >>>>> ontology stylesheet" served from a single location. >>>>> >>>>> But the biggest reason to have it is because of the registry. >>>>> The registry assigns its own root URIs for a DAS source (e.g. >>>>> DS_1234), which means it is necessary to provide another URI >>>>> used to actually query it. Since we already have a way of doing >>>>> it in the sources document, I don't really want to change it >>>>> now. It seems we might as well just embrace the extra >>>>> flexibility and merely describe it better. >>>>> >>>>>> 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: >>>>>>>> >>>>>>>> >>>>>>>> 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.: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>> 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. >>>>> >>>> >>>> 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. >>> >> >> 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. > 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. From andy.jenkinson at ebi.ac.uk Wed Sep 16 07:07:55 2009 From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson) Date: Wed, 16 Sep 2009 12:07:55 +0100 Subject: [DAS] maxbins in DAS1.6? In-Reply-To: <02696626-5424-4089-A177-3AF8D776067A@sanger.ac.uk> References: <6a132cea0909150352v9223531h119475768b6798a7@mail.gmail.com> <9DF5141E-41EF-4AB8-9016-53C0DC89AD76@sanger.ac.uk> <6a132cea0909150430m4f60ac95w111ec6661ded52c5@mail.gmail.com> <81934C8A-5AED-4F63-A3EE-96CA640F3ECE@ebi.ac.uk> <6a132cea0909150543n20bdc186tf21cad1d46793599@mail.gmail.com> <6a132cea0909150719u6a408307k9447b16b99b0a87f@mail.gmail.com> <66BFD80A-E060-4FF7-83F6-8A4E63A74AE1@ebi.ac.uk> <340E3FD0-D7BF-4C5E-A010-5A5CAF2E6670@sanger.ac.uk> <02696626-5424-4089-A177-3AF8D776067A@sanger.ac.uk> Message-ID: <50984973-7542-4020-BC6F-093E4EA52ED0@ebi.ac.uk> But once you're reading the sources document (which is where you would be adding the "root URI") you don't need it... knowing the root URI is only useful to formulate the query URI (which you already know) and to find a place to go to get the metadata (which you already know). The sources document you are parsing can be obtained from a registry - whether that is the public DAS registry or individual "servers", there is no problem for them to support 'single source' access. That is a separate issue from having an explicit extra URI in the sources document. I don't think I'm explaining it very well :/ And to be honest it's academic for the moment since, as you rightly say, we are only 'consolidating' in 1.6. On 16 Sep 2009, at 11:46, Jonathan Warren wrote: > which takes us back to my very first point that it would need to be > a command url in itself and specified otherwise how do you get the > info for a single source. > > On 16 Sep 2009, at 11:28, Andy Jenkinson wrote: > >> Taking aside the issue surrounding the paradigm I mentioned and >> Thomas expanded on, why do you actually need to have a URL for the >> "server" itself? Given you already have all the metadata and >> command URLs you can't learn anything more from it. >> >> On 16 Sep 2009, at 10:28, Jonathan Warren wrote: >> >>> I think Thomas is right in that we can't change the das1 base url >>> principle at least for 1.6 anyway, as it is supposed to be a >>> consolidation. >>> >>> As there have been no objections to using for example http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat >>> as a single source request we can put that into 1.6. The only >>> real change would need to be in the registry. See explanation >>> below. But we can get around that. >>> >>>> What I meant was that the root URI isn't actually used for >>>> anything, at best it's just the location of the description >>>> you're already reading. >>> Except for the registry sources command where there is then no >>> link back to where the server you are talking about is (as you are >>> not at the server) apart from the query_uri's (example 1 below). >>> >>> das2 has "xml:base", but that is then for all sources so wouldn't >>> work for the registry see example 2 below. We could always add >>> another prop to the registry I guess ;) >>> >>> >>> example1 registry sources: >>> >>> >>> >>> >>> >> test_range="UPI00000017EA">UniParc,Protein Sequence >>> >> test_range="IPI00000021">IPI,Protein Sequence >>> >> test_range="P00280">UniProt,Protein Sequence >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> das2 has xml:base, but that is then for all sources so wouldn't >>> work for the registry: >>> >>> xml:base="http://bioserver.hci.utah.edu:8080/DAS2/das2/" > >>> >>> >>> >> created="2008-01-03 14:39:44" > >>> >>> >>> >>> >>> >>> >>> >>> On 16 Sep 2009, at 09:25, Andy Jenkinson wrote: >>> >>>> What I meant was that the root URI isn't actually used for >>>> anything, at best it's just the location of the description >>>> you're already reading. That would mean that adding another field >>>> to capture it wouldn't be of particular benefit. >>>> >>>> Whether we can easily remove the 'paradigm' of server/das/source/ >>>> command without confusing people is something else! >>>> >>>> On 15 Sep 2009, at 18:11, Jonathan Warren wrote: >>>> >>>>> Andy I wasn't suggesting we get rid of query_uri - quite the >>>>> opposite in fact. just that the single source uri would have to >>>>> be specified with a uri as conceptually all other commands may >>>>> not contain the root uri. This also seems to me means we will >>>>> have to update das1 code to cope with multiple query uris. >>>>> >>>>> On 15 Sep 2009, at 17:56, Andy Jenkinson wrote: >>>>> >>>>>> On 15 Sep 2009, at 16:35, Jonathan Warren wrote: >>>>>> >>>>>>> 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!!! >>>>>> >>>>>> My take on this is that the root URI identifies the source. In >>>>>> a conceptual sense the definition of a source is merely a >>>>>> combination of commands acting on a common set of data. It is >>>>>> not really important where that information comes from (a >>>>>> registry, a server, a flat file...) because a server by itself >>>>>> does not really mean anything. So the URI http://www.ebi.ac.uk/das-srv/genomicdas/das/eqtl_rat_cis_fat >>>>>> is not actually meaningful, even less so given it is not even >>>>>> a resolvable URL. >>>>>> >>>>>> The query URI system inherited from DAS/2 has the potential to >>>>>> allow the commands to be served from different locations on the >>>>>> web. It is not something we have needed up to now (all query >>>>>> URIs start with the same path), and does add confusion but I >>>>>> can see it being used for stylesheets. For example a "sequence >>>>>> ontology stylesheet" served from a single location. >>>>>> >>>>>> But the biggest reason to have it is because of the registry. >>>>>> The registry assigns its own root URIs for a DAS source (e.g. >>>>>> DS_1234), which means it is necessary to provide another URI >>>>>> used to actually query it. Since we already have a way of doing >>>>>> it in the sources document, I don't really want to change it >>>>>> now. It seems we might as well just embrace the extra >>>>>> flexibility and merely describe it better. >>>>>> >>>>>>> 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: >>>>>>>>> >>>>>>>>> >>>>>>>>> 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.: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 >>>>>>> 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. >>>>>> >>>>> >>>>> 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. >>>> >>> >>> 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. >> > > 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. From dan.bolser at gmail.com Fri Sep 25 03:42:20 2009 From: dan.bolser at gmail.com (Dan Bolser) Date: Fri, 25 Sep 2009 08:42:20 +0100 Subject: [DAS] [Bioperl-l] Getting all annotations In-Reply-To: <2ac05d0f0909241452m238c10b0t57f9e709d2a40673@mail.gmail.com> References: <2ac05d0f0909181533u1e5d5d89l5c2c468950a9cef@mail.gmail.com> <2c8757af0909200809g1f6c41eeyabfc8bdaac1fc19f@mail.gmail.com> <2ac05d0f0909241452m238c10b0t57f9e709d2a40673@mail.gmail.com> Message-ID: <2c8757af0909250042w6d29937w565b6f004e21fd03@mail.gmail.com> 2009/9/24 Emanuele Osimo : > Dear Dan, > DAS is really interesting. Tomorrow I'll have a close look at it with a > bioinformatician. > Do you have any answer to this? > http://www.biodas.org/wiki/Talk:Everything_DAS Hi Emanuele, Glad I could help! Indeed the Perl script on the above page looks very problematic (clear layout errors). However, I don't know the details of the script, so I can't advise on the specific problem that you see after getting it to run. I'd suggest that you ask your questions on the DAS mailing list (CC'ed in this email). Cheers, Dan. > Thanks > Emanuele > > > On Sun, Sep 20, 2009 at 17:09, Dan Bolser wrote: >> >> Hi Emanuele, >> >> I guess you were Emos in irc://irc.freenode.net/#bioperl ? >> >> >> I think the answer to your question can be found here: >> >> http://www.biodas.org >> >> >> All the best, >> Dan. >> >> 2009/9/18 Emanuele Osimo : >> > Hello, >> > I was trying to figure out how to get from the Entrez database all the >> > reference annotation for a given genomic zone. >> > For example: I want to know which genes, transcripts, microRNAs etc are >> > present in chr 6 from 100kbp to 200kbp. >> > Is there a database that is arranged as a continuum (by sequence) >> > instead of >> > by feature (gene, transcript etc)? >> > >> > Thanks >> > Emanuele >> > _______________________________________________ >> > Bioperl-l mailing list >> > Bioperl-l at lists.open-bio.org >> > http://lists.open-bio.org/mailman/listinfo/bioperl-l >> > > > From dan.bolser at gmail.com Fri Sep 25 03:58:09 2009 From: dan.bolser at gmail.com (Dan Bolser) Date: Fri, 25 Sep 2009 08:58:09 +0100 Subject: [DAS] The DAS wiki Message-ID: <2c8757af0909250058j70ac0c8em882bce3babc70361@mail.gmail.com> Please can you install a syntax highlighting extension on the wiki? * http://www.mediawiki.org/wiki/Category:Syntax_highlighting_extensions ** http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi This should help maintain snippets of code on the wiki. Cheers, Dan.