Back (for now)

Steve A. Chervitz
Tue, 1 Jul 1997 19:54:47 -0700 (PDT)

Apologies for the delayed response. I had no internet access while in 
Greece at the ISMB.

GeorgF wrote:

> SteveB wrote,
> > > >   Congratulations on the great job with the OiB electronic poster.  I
> > > > think you guys did a great job of putting that together.
> > > 
> > > thanks -- SteveC and Chris deserve most of the credit !! 
> > > How about basing a Perl Journal article on it ??
> > 
> > Great idea! How should we arrange this?  Maybe SteveC and I could
> > coordinate this once I get to Stanford, with more input from you guys?  I
> That would be good.
> > contacted Jon Orwant some time ago, and he indicated a willingness to 
> > have a bioperl article at pretty much any time.  I think this should 
> > be published after the CPAN release. 

Sounds like a fine idea. Go ahead and link to the outline from 
the Bioperl homepage (where you currently have a link to _Poster_ and 
don't forget to change the verb tense of this sentence!). I haven't made 
any changes to it since the meeting. I think we can convert the poster 
into an article for TPJ with a little re-working.

> > > My interest will probably remain limited to sequences, at most I expect to deal
> > > w/ RNA structures in my PhD thesis work, and I'm not sure generic code 
> > > concerned w/ both RNA _and_ protein structures is a useful thing to have, or? 
> > > I'm mentioning this b/c as soon as you guys start working on modules for
> > > structures, you may shortly consider RNA structures, too, and maybe find
> > > out that I'm too pessimistic ?!
> > 
> > I think that the protein 3D structure module might reasonably include RNA
> > (and DNA)  tertiary structures.  However, I think RNA secondary structure
> > is very different from protein 3D or secondary structure.  Moreover, I
> > don't see any real advantage of conflating RNA secondary structure with
> > proteins.
> ok - agreed.

I've thought a little about this issue, too. There are many features or 
both protein and RNA structures that can be abstracted into a common 
Bio::Struct module (domains, predicted vs. experimental, 2D vs. 3D, 
active sites, PDB entry, et al.). Thus, I've been planning to have all 
biological structures (RNA and protein, 2D and 3D) conform to a common 
interface. In this way, the client wouldn't have to know much about the 
specifics of the type of structure; the object would be smart enough to 
know what to do. I haven't started implementing a general Bio::Struct 
module and I haven't worked much with RNA structures so this idea has 
yet to be tested.

> > > I suggest that as soon as you're at Stanford, you bundle things together,
> > > incl. makefiles. Maybe SteveC will help, etc. Just today I realized that
> > > I'll probably soon need to replace some functions by C code, so I'd be happy
> > > if the make process would be designed w/ this in mind - if that's possible 
> > > at all. 
> > 
> > I am tentatively happy with this, but am concerned that it could be a
> > major delay. I am just at Stanford for 1 month before I disappear again

I could help out if need be. Steve, if you need any help getting 
settled at Stanford, let me know.  

ChrisD wrote:
> Also- inside GI we have finally gotten around to replacing our numerous scripts that have been 
> lying around for Blast/Fasta search result parsing. We now have a really nice object oriented 
> module and the will be done shortly. Both of these modules are quite 
> standalone, capable of firing up a local or networked search and returning all kinds of 
> different info raw or in various sorted ways. I was thinking that although these modules do not 
> quite fit into our schema, they might be quite useful to the individual researcher.

SteveB replied:
> Sounds interesting, and I think that we should release them under the 
> Bio hierarchy if GI is willing.  I'm not sure if we should have a 
> Bio::Misc, to lump all such things under, of it is better just to put them 
> all at the root under Bio::.  What do people think?  (I have an opinion, 
> but I'd like to hear other thoughts.) 

I've put my module into Bio::Util, which is my grab-bag 
location. I'm envisioning a general module as a base class 
for all sequence analysis modules:
All sequence analysis modules should probably go into a SeqAnal directory 
(,, et al.) The POD for my module isn't up yet, but I'll try to get something up soon. 
Basically, its just a parser for pre-existing BLAST reports. 

Chris's package sounds quite good, however it seems like nearly everyone 
has their own module. Before releasing an official 
module we should consider the design of these different modules.

> > > > 4)  A bioperl meeting
> > > First of all, let's hear Chris on the issue -- any news on G.I.'s side ?
> > > Perl for G.I.'s "2nd generation" code ?? - would be great !!
> > > 
> > > I cannot travel to the US without the additional justification of an
> > > International bioinformatics conference where I can present my PhD research
> > > stuff -- I've heard that there's gonna be another OiB meeting next year 
> > > in the US, coupled w/ ISMB 1998, it may be good to meet berore/during/after.
> > 
> > When/Where is ISMB 1998?  I have been scouring the web for this, without
> > any luck whatsoever. 
> ISMB 1998 is in Montreal, approx in June. There's also RECOMB '98,
> which may be scheduled on a rather short notice for early 1998 --
> I'm currently trying to find out.

I talked to Alex Whittaker from SmithKline Beecham (UK) who expressed alot 
of interest in the Bioperl effort. He indicated that SKB may be able to 
offer some support for additional Bioperl work, possibly including 
sponsoring a meeting. He himself has an AI background and does a fair amount 
of work in Perl (but not much OO work yet). We should stay in touch with 

> > > Should we have clone() or copy() for the function
> > > that returns a clone/copy of the object ?
> > > Maybe one is non-recursive (shallow), but the other is ``deep''?!
> > 
> > I liked your (Georg's) idea:  clone() is deep, copy() is shallow.  
> copy() is deep right now (in Bio::UnivAln), and I think that's more 
> intuitive... ?!

I'm using clone() to duplicate of an object in my module. I'm 
not clear on exactly what is meant by 'deep' vs. 'shallow' duplication.

All for now,


P.S. to ChrisD: 
My modified version of can be found at:
The main change is in the revcom() method to permit slicing. Note that it 
would be nice to modify reverse() and complement() similarly.