Back (for now)

[Steven E. Brenner]

Hi Steve,

  Thanks for the comments.

On Tue, 1 Jul 1997, Steve A. Chervitz wrote:

[lots deleted]

Ok: we'll do a TPJ article once I get to Stanford.  I'll confirm this with
Orwant now.

> 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.


  This is interesting.  Could you be a little more specific about where
you think the overlap between 2D and 3D protein structure is, for module
design?  (Let's leave 2D RNA aside for now, as that will be even harder,
though if it can be included -- that's great!)  I have a hard time seeing
how we could abstract any but the most incidental features.  For example,
domains usually are not known in 2D structure any more than they are in
sequence.  'Predicted v. experimental' seems like a characteristic of the
whole item; just a flag and a pretty incidental one at that.  Active sites
would be probably defined in quite different ways for 2D structure (which
would be more like sequence) and 3D structure. 

  Indeed, I would probably see more overlap between 2D structure and
sequence than 2D structure and 3D.  But, I'm interested that you see
otherwise and would like to hear more details. 

  As an aside, what is 'scop_dict.cf' in Bio::Struct::Scop_data ?

  I had no idea you had coded up so much which uses scop!


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

  Thanks for the offer of help!  Regardless, we should get together
shortly after my arrival. 


> I've put my Blast.pm module into Bio::Util, which is my grab-bag 
> location. I'm envisioning a general SeqAnal.pm module as a base class 
> for all sequence analysis modules:
> http://genome-www.stanford.edu/~sac/perlOOP/bioperl/schema/blast.html
> All sequence analysis modules should probably go into a SeqAnal directory 
> (Bio::SeqAnal::Blast.pm, Bio::SeqAnal::Fasta.pm, et al.) The POD for my 
> Blast.pm 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 Blast.pm module. Before releasing an official Bio::Blast.pm 
> module we should consider the design of these different modules.

  I would tend to favor allowing everyone to release their own module, AND
also choosing a 'standard' one for the distribution.


> 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 
> him. 


  As a note, I think that we probably shouldn't work too hard to get money
for a Bioperl meeting.  What we need much more, at this point, are more
designers and coders.  If the companies could encourage their employees to
help, that would be far more valuable.  (I'd much prefer Chris's
contributions to a meeting!) 


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

If a Bio::SeqBag has many Bio::Seq's, then bag->copydeep() would duplicate
both the bag and its enclosed sequences, while bag->copyshallow() would
just duplicate the bag.

In C++, objects are, well, the objects.  So, a copyshallow would require
having pointers; copydeep is what would happen if you just made an
assignment.  By contrast, in Perl, the objects are always references
(effectively, pointers), so copyshallow could be what happened if you did
an assignment


> My modified version of PreSeq.pm can be found at:
> http://genome-www.stanford.edu/~sac/perlOOP/lib/Bio/PreSeq.pm
> The main change is in the revcom() method to permit slicing. Note that it 
> would be nice to modify reverse() and complement() similarly.

I have no objection to this, but curious to know why you want to
be able to do slices for revcom, etc.


Steve