OiB abstract

[Steven E. Brenner]

Sorry for not getting back to you sooner.  (Unfortunately, I had an
unexpected outage of all computer/fax/phone access for several days.)

Some notes:

* Overall, it looks good.

* I would suggest using the names of the modules as we plan to release
them (i.e., Bio::PreSeq and Bio::UnivAln).  Because there is text
descrbing what the modules do, I don't think it is a problem that the
names are not optimally intuitive.  But if we list one thing in the
abstract and release something else, people may be confused

* I think Richard Resnick should be an author of the abstract, as he did
contribute a lot of effort and time.

* I have two serious "content" concerns, which are actually interrelated

  1)  The text doesn't emphasize the value of Bio:: objects as being a
"currency" for doing various algorithmic operations.  Instead, it focuses
just on Perl as a data management language.  I think that Perl is a much
better for most of the algorithmic operations than C or Java (because of
the relatively complex nature of the data).  The only cases where it
looses out are where the operation needs (1) speed, (2) security, or (3)
GUI.  In practice, all of these turn out to be comparatively rare.

  2)  Everything seems to be geared towards Perl as a backend for GUIs,
including Java Applets.  In fact, I suspect only a tiny fraction of
Bio::Perl code will support such application.  Most will be used for very
algorithmic operations which are just easy to progam in Perl.  For
example, in the past two days, I have written programs to:

* Build a database of sequences, all of which have less than N% identity
* Find all the ORFs in a sequence and produce many reports of this
* Retrieve sequences from a database and do a Smith-Waterman search
* Use those results to produce a structural alignment
* Parse FASTA output and produce a novel sort of similarity measure

  None of these were really back-ends to a GUI, and none took more than
about an hour to write because of Perl's data-munging capabilities and the
fact that the algorithms could take advantage of Perl's convenient data
types.  In pure C or Java, I hesitate to even think how much time I might
have spent on them. 


>A Bioperl application is expected to primarily provide behind-the-scenes
>data manipulation for front-end GUI applications. For example, Bioperl
>modules can be used to support Java applets and some working examples of
>this will be presented.

^^^ These are the comments which I disagree with.  I would restrict the
linkage of Perl to GUIs to a single paragraph.   Instead, I would focus
more on the fact that many many groups already write little "tidbits" of
Perl, and having standardized object would provide a trivial way to link
together these mini-routines.