[DAS] System requirements

Tony Cox avc@sanger.ac.uk
Tue, 4 Dec 2001 22:56:31 -0000

> Hello,
> Given the following use case:
> A small academic lab has discovered, for example, a new way of
> determining human alternate splicing, and has a great deal of data that
> they want to publish to the world, they decide on trying das.  The local
> software person decides that the easiest install given the documentation
> and assumed information in the install documentation, given both Dazzle
> and Ldas is Ldas.  He uses the ensembl version of Kent's goldenPath to
> determine where everything is and puts all of the data on the Ldas
> server in ensembl coordinates.  He installs and begins serving data on
> Ldas and views it with geodesic or omnigene.  His PI wants to see as
> served in its context on the ensembl website, he opens up
> (http://www.ensembl.org/), and goes to manage sources, he adds his Ldas
> server, and assuming it works as described in the Ldas documentation,
> what happens?
> A: Ldas and the ensembl contigview are incompatible, PI gets mad,
> software person restarts process with Dazzle
> B: Das protocol is implementation independent and the data is shown in
> contigview; he and his PI are happy.
> Which is the likely scenario?  A or B.
> Has anyone had this experience?

Given that Ensembl has successfully shown that it can layer external data
via DAS on contigview displays (in this case using dazzle) using both contig
and assembly (chromosomal) coordinates, I believe that the results will be

Although we have no test LDAS server to try it out on I see no reason why it
should be any problem. Let me assure you that if it was not "B" we would
have the problem fixed in very short order. Ensembl views DAS as a key
technology for delivering precisely this sort of user-configurable, layered
data, and so we are comitted to making it work at all levels.