[DAS] using ProServer as a DAS source for IGB

[Hotz, Hans-Rudolf]

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" <gregghelt at gmail.com> 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
> (steve_chervitz at affymetrix.com) 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
> <hans-rudolf.hotz at fmi.ch>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
>> 
>>