[Biojava-l] JPAT API

[Matthew Pocock]

"Jones, Mike" wrote:

> > -----Original Message-----
> > From: Matthew Pocock [mailto:mrp@sanger.ac.uk]
> > Sent: Wednesday, February 02, 2000 6:20 AM
> > To: Jones, Mike
> > Cc: 'biojava-l@biojava.org'
> > Subject: Re: [Biojava-l] JPAT API
> >
> >
> > Mike,
> >
> > This looks like fun code. It would be great if we could make
> > the biojava
> > code a good starting point for this type of project. Do you
> > have any views
> > about our code base and what makes it attractive or unattractive for
> > developing something like jpat?
>
> I really haven't spent that much time looking at it, but I will. I just
> found out about the Biojava-l list yesterday. What is the best way to find
> your code base? The CVS repository?

The CVS repository is probably the best way to go. Follow the instructions at

http://cvs.biojava.org/

to get an anonymous read-only cvs version of the source code. At the moment, we
have been relying on the java1.3 javadoc to inherit documentation from
interfaces to implementations, so not all methods have documentation in the
source code. The org.biojava.bio.seq package is the best place to start looking
arround.

I have built full docs for the packages as they stand today at:

http://www.sanger.ac.uk/Users/mrp/java/biojava/

We should get these docs building on the biojava web site...

> <snip>

> > You seem to be passing arround proteins as Strings. Was there
> > a reason for
> > this, given that you use a concept of Residue within the package?
>
> It just seemed easier. Didn't think I needed a protein object.
> Essentially the fields of a residue are based on the input given
> to it by the user and then the characteristics of the protein are defined
> by the residues defined in the PepTools. I suppose it could be useful to
> have
> all of that type of info encapsulated in a protein object.
>
>
> > Your residue objects encapsulate the information about a
> > single ammino acid.
> > This is analogus to our Residue objects. I think we would
> > store some of the
> > information like masses in an annotation bundle or in a residue-lookup
> > table, but that is implementation detail.
>
> That is probably better but since these tools were originally designed
> for one specific purpose (A fairly limited scope) it seems more efficient
> to keep them in the residue.

>
> <snip>
> > PepTools seems to be living multiple lives. It supplys realy useful
> > constants, and formatting. It is the analogue of our Alphabet objects,
> > complete with an exception throwing function.  It also is the
> > base class for
> > things that process proteins, either into arrays of peptides, or just
> > returning summary statistics. I guess the peptide makers are like the
> > Annotator interface which adds features to a sequence using
> > some algorithm.
>
> In hind site, now that I know a little more about OO design, I might
> have chosen delegation rather then inheritance.
>
> >
> > The Protease and Digest classes confuse me a bit. Is there
> > some table of all
> > known proteases loaded somewhere in memory?
>
> Protease just has static methods and fields. I have static properties that
> represent the names of some common proteases. You can use those
> to call static methods on the Protease class to get the residues that cleave
> and whether it's an endo-protease or not. I suppose I could create a
> Protease
> class and pass that to digest. Right now I just use the Protease class as a
> way of organizing the parameters of a protease.
>
> Ex. This example was taken out of the Example code which is
>     distributed in the Demo.
>
>          Digest digest = new Digest();
>        digest.setSequence(mSequence);
>        String protease = Protease.TRYPSIN;
>        digest.setProtease(Protease.getCleavageResidues(protease));
>        digest.setEndoProtease(Protease.isEndoProtease(protease));
>        digest.setNotCleave(Protease.getNotCleave(protease));
>        digestDisplayPanel1.setPeptides(digest.getPeptides());
>
> >I guess these are
> > the static
> > final String fields in Protease. Why did you go for protease
> > labels rather
> > than protease objects? I am assuming that Digest.getPeptides behaves
> > differently depending on what protease you use, in which case
> > a Protease
> > object with methods that parameterise the search algorithm in
> > Digest would
> > seem logical.
> >
> Maybe so. I will think about that. It seems like their was some reason
> why I didn't go that rout but I don't remember why now.
>
> >
> > Thanks again for posting the URL. It is great to look at
> > somebody elses
> > ideas. Could you just tell us a bit about the license for use
> > of the library
> > and for the source code?
>
> Any one can access the library by going to my site. All I ask is that
> you register so I can know how many people are using it and I can send
> updates. You can get the info on the API here
> http://www.pixelgate.net/mjones/Java/jpat/jpat2/README.html.
>
> As far as source code I haven't distributed it but I might be willing. Is
> their some standard way of distributing source code?
>

We tend to put code under the perl artisitic license, or LGPL. As far as
distributing it, tar balls or .jar files that can be picked up from a web site
seem to work fine, or annonymous CVS.

>
> Also did you want me to send this back to the list?
>

just done it for you ;->

>
> Mike
>
> >
> > Matthew
> >
> > "Jones, Mike" wrote:
> >
> > > jpat - Contains utilities for performing protein digestion,
> > fragment-ion
> > > prediction, mass calculations and mass or sequence searching.
> > > Some of you might find it interesting and I would love to get some
> > > feedback on it. You can find it at http://www.pixelgate.net/mjones/
> > > Mike
> > >
> > > _______________________________________________
> > > Biojava-l mailing list  -  Biojava-l@biojava.org
> > > http://biojava.org/mailman/listinfo/biojava-l
> >