[ensembl-dev] Manual curation tools

[Michael Paulini]

Just to play devil's advocate:
what speaks against dumping it in GFF(3) and loading it into
Apollo/Artemis/JBrowse/GBrowse/...
... as kind of intermediate format or data layer?

M

On 23/04/13 12:52, Matthew Astley wrote:
> On Tue, Apr 23, 2013 at 09:22:45AM +0200, Marc Hoeppner wrote:
>
>> [...] one thing I am missing is a tool for inspecting the different
>> outputs and progress of the pipeline graphically. The documentation
>> suggests Apollo as a useful tool, but I had very mixed results
> I think some people do still use it for this purpose, possibly with
> locally modified source.
>
> I don't know how Apollo and its Ensembl interface are maintained, but
> they have recent activity on their websites.
>
>
>> [...] it seems to have some problems with some not-so-recent updates
>> in the database schema (like the gene_stable_id table, which I think
>> was deprecated?)
> (According to my notes, but not checking the version history) It was
> deprecated in 63 or 64, removed in 65 and the backwards compatibility
> views removed in 67.
>
>
>> Otterlace seems to be an attractive alternative, but I think that
>> one is designed to only work within EnsEMBL/Sanger?
> Otterlace includes ZMap, Blixem and Dotter.  Together these make the
> desktop client part of the application.  Otterlace needs an Otter
> Server with associated Ensembl-schema databases to supply the data for
> regions to edit.
>
> Both Otterlace and the Otter Server are _designed_ to work anywhere
> that can support the necessary databases and webserver back-end.
> However the server isn't currently installed anywhere else as far as
> we know.
>
> As with any unused software, the ability to work elsewhere is at risk
> of becoming vestigial.
>
>> Any way around that and adopt it to my local setup?
> With the current state of the Otter code, I suspect it would be more
> work to get Otterlace displaying your pipeline output than Apollo.
>
>
> However ZMap itself should be usable as a stand-alone viewer for gene
> builds.  It may not be in a state where you can do this conveniently
> now, but it is the direction we are taking it.
>
> If you are interested in this, we should perhaps continue off the
> dev at ensembl list.
>
>
>> I guess my questions is what other people are using - and if there
>> is nothing else out there that can talk to an EnsEMBL core DB, what
>> I could try to get either of the two options above to work properly.
> As developers of Otterlace we need to verify that it is displaying
> data correctly.  We tend to look at the ensembl data via SQL or the
> API, or the GFF and other underlying data.
>
> I think we may have used Apollo for the purpose, but not recently.
>