[Bioperl-l] Re: UniGene modules and Bio::Cluster

Allen Day allenday@ucla.edu
Sun, 5 May 2002 18:55:38 -0700 (PDT)


> 1. rename UniGeneIO.pm --> IO.pm

By convention of SeqIO, I think it should be called unigene (note
lowercase), and should be under ClusterIO.  Have a look at how the
SeqIO::game classes are laid out.  So I think it should go something like:

Bio/

	Cluster/
		...
	ClusterIO.pm
	ClusterIO/
		unigene.pm
		ungene/
			...

> The only thing is what to do with next in the end. What's the general
> consensus? I have to say I like the sound of Hilmar's next_cluster() but if
> there is a move to standardise this across bioperl I am not too worried what
> it is called :) Sound like a good plan?

I like next_cluster().  I'd like a next_component() method that can be
called on each cluster to iterate over its parts as well.

> > Is there a plan to make general Bio::Cluster and Bio::ClusterIO classes?
> > I see that UnigeneIO is using Bio::SeqIO to do it's reading/writing, and
> > isn't inheriting from the (non-existant) Bio::Cluster class.
>
> So the steps above would make a more generic ClusterIO class. The only thing
> there is that it currently reads only as I can't see why you would want to
> write UniGene files. This might not be true for other clusters though?
> Should it be able to write?

Maybe you would want to write a GFF.  I can see myself wanting to read a
CEL file and write GFF.

> What I can't see I'm afraid is how you would code Bio::Cluster::ClusterI
> that was sufficiently generic that UniGene.pm and other clusters could
> inherit from it. Wouldn't the methods I need for a UniGene object be
> completely different for some other cluster. Wouldn't the overlap only come
> on the next_cluster method? And hence ClusterI wouldn't have much in it?
> Sorry if this sounds dumb, I just can't quite get my head around what would
> be in there. Perhaps there is something similar elsewhere in bioperl that
> someone could point me towards.

You're right, there isn't going to be much that clusters have in common.
Maybe a components() method...

Maybe there is something here in common with the Bio::Tree classes that we
can borrow.  I haven't really looked at them.

-Allen