[ensembl-dev] Manual curation tools

[Marc Hoeppner]

That would be an option, of course. But you lose the ability to 
curate/modify annotations in place or just flip/browse through multiple 
databases without having to dump flat files and load them into a software.

> 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.
>>
>
> _______________________________________________
> Dev mailing list    Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/