first version of goals for gemma

doc/Project_notes/Goals.shtml

+<!--#set var="banner" value="Goals for Annotation Tool development"-->
+<!--#include virtual="/perl/header"-->
+
+<!--#set var="author" value="edgrif@sanger.ac.uk" -->
+
+
+<style>
+pre{ width: 95%; background-color: #DDDDDD; border-style: solid; border-width: 1px; padding: 10px }
+.example{ border-color: #000000 }
+</style>
+
+
+
+<h2>Overview of work within ZMap/Acedb</h2>
+
+<p>There are three major software components maintained and developed by the ZMap/Acedb group:</p>
+
+<ul>
+  <li>ZMap
+  <li>Acedb
+  <li>Associated Tools (belvu, blixem, dotter etc)
+</ul>
+
+<p>Acedb is a large and reasonably complex database specification and associated programs, ZMap is
+a new sequence viewer program and the tools are separate executables that are normally called from
+either an acedb program or from ZMap. This document covers planned work on the associated
+tools, in particular blixem which is an alignment display program.</p>
+
+<p>The work falls into four sections:</p>
+
+<ul>
+  <li>Partial rewrite of blixem to remove the acedb "graph" package layer.
+  <li>Major enhancement of blixem to meet annotators requests for new features.
+  <li>Design and implementation of a protocol for communication between sequence annotation
+      tools.
+  <li>Enhancement of other annotation tools, especially dotter.
+</ul>
+
+<p>These sections are now decribed in more detail.</p>
+
+
+<br/>
+<fieldset>
+<legend id="Graph_removal"><b>Removal of Graph layer in Blixem</b></legend>
+
+
+<h4>Motivation:</h4>
+
+<p>The acedb graph package provides good portability and a simple programming model but has some
+serious flaws and in addition would be impossible to extend to match current toolkits in any
+reasonable amount of time. In particular these flaws and lack of support for more complex
+interfaces may make it impossible to provide the enhancements that annotators would like.</p>
+
+
+<h4>Assessment:</h4>
+
+<p>Removing the graph package will be non-trivial and require several months of effort
+therefore careful assessment of the benefit of doing this is required. This assessment
+should be in two parts:</p>
+
+<ol>
+  <li>Assess requirements for enhancements and decide whether they can be met with existing
+      code.
+  <li>Analyse blixem code and decide how much effort/rewrite is required.
+</ol>
+
+<p>It may be have to be accepted that it is not worth removing the graph layer and therefore only
+some enhancements can be made. It is not feasible to rewrite blixem completely as the current code
+does much of what annotators require and such a rewrite would take up much of the 2 years of this
+post.</p>
+
+</fieldset>
+
+
+
+<br/>
+<fieldset>
+<legend id="blixem_enhance"><b>Major Enhancement of Blixem</b></legend>
+
+
+<h4>Motivation:</h4>
+
+<p>Blixem is the major tool used by Havana annotators for assessing alignments that may
+indicate a transcript in the reference sequence. Currently it has a number of inadequacies
+that mean that it is not nearly as it could be. Some of these are actually quite minor but
+others will require more extensive coding to recitfy.</p>
+
+<p>In assessing the below list it is important to remember that annotators usually just have
+one screen and that screen space is at a premium !</p>
+
+
+<h4>Assessment:</h4>
+
+<p>The following general requirements have been identified by annotators:</p>
+
+<ul>
+  <li><b>Common Short Cut Keys:</b> for zooming, printing etc.
+  <li><b>Tools Launching:</b> Some of the tools call/launch each other, some are called directly by
+      other Zmap and in general the way the programs do this is not well specified or implemented.
+  <li><b>Tools Interactivity:</b>Currently the tools do not interact with each other or with ZMap which
+      results in them being very much less easy to use.
+</ul>
+
+
+<p>Blixem requirements:</p>
+
+<ul>
+  <li><b>Alignment filtering:</b> blixem can end up displaying large numbers of alignments, to make
+      this workable requires some more sophisticated filtering than just by name, score etc., this may
+      include allowing the annotator to make a choice of the types of alignment shown.
+  <li><b>ZMap-blixem navigation:</b> annotators would like to be able to move from alignments in blixem
+      to the same one in zmap more easily.
+  <li><b>Display of exonerate matches:</b> exonerate matches will require blixem to be altered to sort
+      alignments <b>across</b> several connected HSP's and maintain that sorting as the user scrolls
+      across the alignments.
+  <li><b>Splice site viewing:</b> currently blixem does not display any existing leading/trailing extra
+      bases for each alignment, the alignment sequence is clipped to the alignment. This makes it hard
+      to examine the splice site where the match is inexact.
+  <li><b>Feature Colouring:</b> Probably partly because the acedb graph package can only display up to
+      16 colours the use of colours to indicate different features is poor and could be extended to show
+      insertions/deletions/mismatches in a more informative way.
+  <li><b>Feature annotation:</b> annotators can often see features in blixem (e.g. SNP's, PolyA tails etc)
+      that they wish to transfer to another program (e.g. otterlace) and need to be able to transfer this
+      data to that other program. The existing way of doing this is via data to the cut buffer and blixem
+      should be enhanced to do this using an agreed format, e.g. "SNP coord", "POLYA start_coord,end_coord"
+      and so on.
+  <li><b>Zooming of alignment sequence:</b> currently blixem can zoom it's "big picture" overview of
+      all the alignments but the actual alignment sequences are a fixed length. Annotators are happy
+      with the current font size as a maximum but would like to have preferably two increasingly smaller
+      fonts to allow zooming of the alignment sequences to show more sequence. <p>
+
+      <b>Note</b> that this may also require a change in the way the alignment sequences are displayed
+      because while this may enable them to see the whole of an "exon" match they also would like to
+      be able to see more than on exon.
+  <li><b>Transcript view enhancements:</b> Currently the transcript section of the blixem window is
+      rudimentary, the names of the transcripts need to be displayed and where several trascripts overlap
+      the annotator should be able to bump them so as to see them all.
+  <li><b>Big picture dynamic sizing:</b> Alignments all have a score and the big picture draws an overview
+      placing each alignment vertically using it's score value. The big picture could be compressed
+      vertically by about 50% in most cases if blixem calculated the max/min score of all
+      alignments and then only used the space required for that range rather than always
+      allocating space for scores from 0 to 100%.
+</ul>
+
+
+
+</fieldset>
+
+
+
+<br/>
+<fieldset>
+<legend id="client_comms"><b>Annotation Client Communication</b></legend>
+
+
+<h4>Motivation:</h4>
+
+<p> There is a general move to produce tools and data formats that are not tied to any one Lab or
+organisation's data formats. In particular there is a move to produce annotation tools that can be
+used independently and interchangeably. However for these tools to cooperate there must be agreed
+protocols which allow the tools to communicate together.</p>
+
+<p>ZMap was designed exactly for this purpose and has peer-to-peer communication with Otterlace
+(or any other program) allowing both programs to send each other requests for actions/data. The
+blixem/dotter/belvu tools present an opportunity to refine the zmap communication protocol and
+generalise it to other tools.</p>
+
+<p>The work will include</p>
+
+<ol>
+  <li>Design a set of extensible xml tags with attributes specifying the protocol requests/responses.
+      This should include actions such as:
+      <ul>
+	<li>Highlight a named feature
+	<li>scroll/zoom to a named feature
+      </ul>
+  <li>Design the protocal itself, specifying in particular:
+      <ul>
+	<li>How communication is initiated
+	<li>The request-reply cycle
+	<li>How errors are communicated
+	<li>How communication is terminated
+      </ul>
+</ol>
+
+<p>blixem/dotter/belvu so not currently support any inter-client communication but users would
+benefit greatly if they did. 
+
+
+</fieldset>
+
+
+
+<br/>
+<fieldset>
+<legend id="dotter_enhance"><b>Dotter Enhancements</b></legend>
+
+
+<h4>Motivation:</h4>
+
+
+<h4>Assessment:</h4>
+
+
+</fieldset>
+
+
+
+
+
+
+<!--#include virtual="/perl/footer"-->