[Biojava-dev] Contributing chromatogram support to BioJava

[Schreiber, Mark]

Hi -

Is there a plan to update the ABITraceViewer to work with the new
Chromatogram API? It would be cool if it could work with all supported
Chromatograms.

- Mark


> -----Original Message-----
> From: Rhett Sutphin [mailto:rhett-sutphin at uiowa.edu] 
> Sent: Tuesday, 11 March 2003 12:20 p.m.
> To: Matthew Pocock
> Cc: biojava-dev at biojava.org
> Subject: Re: [Biojava-dev] Contributing chromatogram support 
> to BioJava
> 
> 
> Hi Matthew,
> 
> I thought about this some, and decided that your alignment suggestion 
> was the right way to go.  (I was particularly persuaded by the memory 
> footprint argument.)  I've posted a revised version of the API in the 
> same place as the previous one:  
> http://www.detailedbalance.net/~rhett/dev/biojava/chromat-cont
rib/doc/ 
> .  The main difference is that getBaseCalls now returns an 
> alignment of 
> at least two SymbolLists -- one for the calls and one for the offsets 
> -- and the BaseCall class has been dropped.  I've extensively 
> modified 
> SimpleChromatogram to support this  -- in particular I added factory 
> methods for creating the Alignments and SymbolLists so that 
> subclasses 
> can optimize those as they see fit.
> 
> I also introduced a ChromatogramTools class to permit various 
> forms of 
> access to the offsets as primitive ints and some shortcuts 
> for commonly 
> used accesses.
> 
> I look forward to comments from potential users before I finalize the 
> interface.
> 
> Thanks,
> Rhett
> 
> --
> Rhett Sutphin
> Research Assistant (Software)
> Coordinated Laboratory for Computational Genomics
>    and the Center for Macular Degeneration
> University of Iowa - Iowa City, IA 52242 - USA
> 4111 MEBRF - email: rhett-sutphin at uiowa.edu
> 
> On Monday, March 10, 2003, at 09:27  AM, Matthew Pocock wrote:
> 
> > Hi Rhett,
> >
> > I totaly see your point. Perhaps the simples should be made more
> > visible. Darn, I guess we should have had a .symbols.spi package :) 
> > This sort of issue hits up hard against one of the limitations of 
> > java-like o o programming languages - it's hard to come up with a 
> > single right way to represent things, but it's also hard to 
> > dynamically map different interfaces and stoorage paradigms between 
> > one another without writing loads of adaptors.
> >
> >
> > The other way to do this named properties milarkie is to treat each
> > property as an entry in an alignment. So, you could publish some 
> > well-known labels (say on a *Tools class, or an extention of the 
> > Alignment interface) called things like DNA, OFFSET etc., and then 
> > when you parse the scf file, spit out one of these 
> alignments with all 
> > the bits labeled up. Then the access API would look something like:
> >
> >   Alignment scf = // get an scf object from some source
> >   Symbol dna = scf.getSymbolAt(ScfTools.DNA, 7);
> >   Symbol offset = scf.getSymbolAt(ScfTools.OFFSET, 10);
> >
> > and if someone wanted just one of the quality values (which I don't
> > know the names of, but let's call it Q4)...
> >
> >   SymbolList q4Vals = scf.symbolListForLabel(ScfTools.Q4);
> >
> > This isn't perfect, but it may be better on the applications memory
> > footprint (when looking at loads of traces) and will play 
> nicer with 
> > the ..gui.sequence package. Any way, see what you think. You're in 
> > charge of the package :)
> >
> > Matthew
> >
> > --
> > BioJava Consulting LTD - Support and training for BioJava
> > http://www.biojava.co.uk
> >
> >
> 
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at biojava.org 
> http://biojava.org/mailman/listinfo/biojava-dev
> 
=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================