[Bioperl-l] Proposal: SemanticMapping and call for info on GeneObjects

[David Block]

> -----Original Message-----
> From: Ewan Birney [mailto:birney@ebi.ac.uk]
> Sent: Wednesday, May 15, 2002 1:10 AM
> To: Lincoln Stein
> Cc: Jason Stajich; dblock@gnf.org; lapp@gnf.org; Bioperl
> Subject: Re: [Bioperl-l] Proposal: SemanticMapping and call 
> for info on
> GeneObjects
> 
> 
> On Tue, 14 May 2002, Lincoln Stein wrote:
> 
> > I would prefer the ability to pipeline a series of FeatureBuilder
> > modules in which the output of one FeatureBuilder is pipelined into
> > the input of the next one.  This keeps each step of the 
> transformation
> > clean and lets us do cool things like build
> > exons->transcripts->genes->gene interaction networks.
> 
> 
> I view this a master aggregator having little aggregators, 
> not a chain of
> aggregators (ie, I think this pipeline is sensible, but SeqIO 
> should have
> a heirarchy of aggregators, not a chain).
> 

A chain would be great if we could return to some predictable state after each aggregator does its thing.  What would that state look like?  It would force all of our aggregators to be able to start from an arbitrary set of Bio::SeqI compliant objects, so that we could mix'n'match aggregators at will.

The alternative is to have an ordered list of possible aggregators, with some way of enforcing that Yaggregator only be run after Xaggregator.  The easiest way to do that would be to have a master aggregator, which knows the input requirements of each little aggregator, for a particular pipeline.  Then each pipeline would have to be set up so that the requirements are met.  So each aggregator needs to publicize its input requirements and its output commitments somehow - through interface classes, I expect.

So Ewan, I completely agree with you here, and I thought I'd let the rest of you know that I am following this thread.

Lincoln - to make your vision a reality (this is related to the pipeline code being developed for runnables, no?)  a utility needs to be written that provides some feedback as to whether a certain aggregator can follow another one.  If the interfaces match, the pipeline Master aggregator can be generated.

I suggest a gui (Tk?) for the utility, and I nominate Someon E. Else to do all this hypothetical coding. :)

Have fun, Jason!!

Dave