Greg Thank you very much for your reply.
I will try to change our ProServer to support "entry_points" and "types". Also, we are in the process of setting up a second, public ProServer Thanks, Hans On 10/30/08 3:33 AM, "Gregg Helt" <[EMAIL PROTECTED]> wrote: > You're not seeing DAS/2 in IGB because the use of DAS/2 has become an > integral part of IGB, to the point that it's no longer advertised as such. > This was partly motivated by feedback at Affymetrix (internally and from > customers) that DAS1, DAS/2, any mention of these things in IGB was just > confusing to users who didn't know what those were and didnt' really care > what protocol was being used, they just wanted to see the data. > > So (unless you've tweaked some advanced prefs) when IGB first launches, goes > to a particular genome assembly, a particular chromosome, and pulls up the > chromosomal banding pattern and RefSeq annotations for that chromosome, all > that is happening via DAS/2. The "Pick Genome" button that's used to switch > to a different genome assembly uses DAS/2. The data access panel at the > bottom of IGB that allows you to select other annotation types to load is > using DAS/2. The tricky bits of ID-to-genome-coordinate resolution that > happen behind the scenes if you load an Affymetrix gene or exon chp file > uses DAS/2. > > Now there's a whole separate chunk of code in IGB that enables getting > annotations from DAS1 servers, which is accessed via the File-->"Access > DAS/1 Servers" menu item that you mention. This is a much older code base, > and for some DAS1 servers it works, but for many others it doesn't. For > your particular case I'm guessing that the IGB code is ignoring the > X-Das-Capabilities header and assuming that your server supports "types", > "features", and "entry_points" queries (or points to a MapMaster that > supports "entry_points" queries), and it's choking when it turns out the > server doesn't support either "types" or "entry_points". This is definitely > a bug in IGB, and it didn't get fixed back when the IGB DAS1 client was > being developed because the DAS1 servers that most IGB users were accessing > at the time didn't trigger this bug. > > Assuming the problem is with IGB's handling of DAS1 servers, there's several > possible solutions. > > 1) Configure your DAS server to support all three of the queries the IGB > DAS1 client needs: "types", "features", "entry_points". > > 2) Trellis/Ivy, the DAS1-->DAS2 proxy I've been developing, might work for > this situation. Currently it probably won't, as the IGB DAS/2 client also > requires that the DAS/2 data sources support the DAS/2 "types" query. But > this code base is evolving rapidly, and soon the proxy may be able to inject > type support for DAS1 servers that don't support "types" queries. It > already does this kind of injection of the DAS/2 "segments" query for many > DAS1 sources in the Sanger DAS1 registry that don't list a > "das1:entry_points" capability. One caveat to this approach is that > Trellis/Ivy supports the "sources" query but not the "dsn" query, and may > not ever since it looks like "dsn" may soon be deprecated. Does ProServer > support the 1.53E "sources" query as an alternative to "dsn"? > > 3) Modify IGB so it can deal with DAS1 servers that don't support "types" > and "entry_points" queries. But I'm reluctant to dive back into the old IGB > DAS1 code, and I doubt if anyone else wants to either. > > 4) Modify IGB so it can deal with DAS/2 servers that don't support "types" > and "segments" queries. This is going to happen eventually, it's just a > question of timing. Then Trellis/Ivy could be used as-is to proxy for the > DAS1 server and respons to IGB DAS/2 queries. > > If it's straightforward to configure the DAS1 server to support "types" and > "entry_points" queries, then that's probably the quickest route. > > One other caveat -- in order for IGB to overlay annotations from multiple > data sources, it needs to realize that they're using the same coordinate > system. If coordinate system IDs don't match exactly, IGB uses a synonym > resolution strategy which usually relies on the synonyms doc at > http://netaffxdas.affymetrix.com/quickload_data/synonyms.txt . If you can't > overlay annotations from multiple servers it's probably because their > coordinate IDs aren't listed as synonyms. Let me and/or Steve Trutane know > ([EMAIL PROTECTED]) and he can add them in. Hopefully increased > use of the DAS1 and DAS2 registries will lessen IGB's dependence on synonym > resolution. > > hope that helps, > Gregg > > On Mon, Oct 20, 2008 at 7:24 AM, Hotz, Hans-Rudolf > <[EMAIL PROTECTED]>wrote: > >> Hi >> >> Your e-mail was given to my by Andy Jenkinson one of the ProServer >> (http://www.sanger.ac.uk/Software/analysis/proserver/) developers at the >> EBI >> in Hinxton, UK). >> >> I am struggling to understand which DAS protocol is used in IGB. All the >> menu tabs are suggesting it is DAS/1 (eg File-> "Access DAS/1 Servers"). >> But >> the release notes suggest is DAS/2. And if I try to load data from my >> ProServer I get: >> >> Error parsing DAS Source >> org.xml.sax.SAXParseException: Content is not allowed in prolog. >> >> >> Is there a way to use ProServer with IGB? >> >> Thank you very much for your help >> >> Hans >> >> >> Friedrich Miescher Institute >> for Biomedical Research >> Maulbeerstrasse 66 >> 4058 Basel/Switzerland >> >> _______________________________________________ DAS mailing list [email protected] http://lists.open-bio.org/mailman/listinfo/das
