Re: [GMOD-devel] Re: [Gmod-chado-seq-ad] Re: shared or non-shared exon in the ricedatabase

[Chris M. <cj...@fr...>]

[limiting cc-list since my emails were getting blocked]

Hi Aaron

Thanks for your comments. Regarding users (ie programmers and not end
users) - your sanity is extremely important to us. An API would help, but
so would more extensive and less scattered documentation which Dave and I
have so far neglected to compile. I'm extremely pleased that everyone
involved has the patience and tolerance to have made it this far. We would
like to remedy the documentation situation... as soon as we have the time.

Regarding the common API - you suggest at the schema level to shift
responsibility towards the schema people. There may be other reasons to
avoid an object-oriented API (not that an OO API is inappropriate for
apollo - I'm talking beyond the apollo use case here).

One is the fact that a common API should be usable from at least java and
perl, and preferably other languages. I'm not a big fan of language
lock-in (especially if the language is java!).  A schema level API using
SQL functions would fit the bill.  However, this would have to be fairly
atomic if we are to avoid DBMS lock-in.

If we were all happy with postgresql lock-in (I'm sure there are a few
objecters out there!) then we would lose some of the constraints of SQL
functions, since we could pass around nested relations. I'm not sure this
would fly. People are already allergic enough to putting code in the DBMS
without forcing them to use nested relations...

We could have DBMS-neutral set of atomic calls (ie all arguments are basic
SQL types), but this would be fairly low-level. It would allow insulation
between the application and certain thorny issues such as exon identity
and what exactly happens when deleting a gene _model_. But then such an
API assumes things on the application's behalf, namely that the
application doesn't care about these things.

I do think this idea has merit, and should be fleshed out further, *if
there was a genuine need and people would definitely use it*

So what's left? an XML API.

Here's what I mean by XML API. The actual API function calls and the data
structures would be represented in XML; the calls would be executed using
something like XSLT

I think this is a nice way of doing things. So why not do this? Well, it's
kind of there already, in XORT and ChadoXML; see gmod/schema/XMLTools

For writeback (schema-seq-ad subscribers know this already) ChadoXML is
both a data representation language and a language for representing
force/lookup/update/insert/delete function calls (using xml elements and
xml attributes respectively). XORT processes those instructions. In fact
it could be used for any DBMS, not just chado. XORT happens to be written
in perl, but this is a completely language neutral approach.

For querying, XORT uses 'dumpspecs' which are XML representations of
both query constraints and instructions on how to stitch a series of SQL
queries into a piece of nested ChadoXML.

A naive user would not write their own dumpspec from scratch, they would
adopt an existing one, such as the one in
gmod/schema/XMLTools/XORT/Config/dumpspec_gene.xml

This isn't an ideal solution for a naive user-programmer, so I have a
suggestion below.

Another nice thing about an XML API is it distributes nicely, either via
SOAP or a simpler home-grown protocol. And it is of course both language
and dbms-neutral. Every language worth its salt has myriad ways of
accessing XML datastructures.

I think this is an excellent start. What is also needed to for the users
Aaron is championing is an extra layer that insulates the naive
user-programmer from some of the more abstruse details of the chado
schema. (although sometimes the user may not want to be insulated - in
which case they can simple use chadoxml as-is)

*use case 1: fetching a set of genes by id, stitching together the full
gene model - transcripts, exons etc

  <chado-api:fetch_gene_model>
    <uniquename><or>CG13339</or><or>CG3665</or><or>CG3497</or></uniquename>
  </chado-api:fetch_gene_model>

This could easily be transformed via XSLT into something like the existing
gene dumpspec; the advantage over the existing dumpspec is that the user
doesn't have to worry about getting the full feature graph

Note that unlike many database APIs, we do not end up re-inventing a query
language like SQL - we are using it.

*use case 2: fetching a set of genes by GO terms

  <chado-api:fetch_gene_model>
    <feature_cvterm>
      <cvterm>
        <name>wing development</name>
      </cvterm>
    </feature_cvterm>
  </chado-api:fetch_gene_model>

Again, this could easily be transformed to something like the existing
dumpspec.

*use case 3: updating an exon context without worrying about whether this
is the only context for that exon

  <chado-api:remove_feature_from_parent>
    <object_id>
      <uniquename>CG1234-RA</>
    </object_id>
    <nbeg>100</nbeg>
    <nend>200</nend>
  </>

This would be harder to transform directly to chado-xml with pure XSLT
since it requires some SQL interaction. It could be transformed to an SQL
function if XORT could be extended to allow function calls.

Obviously more use cases are required if we are to continue further with
API develpment beyond what is required for Apollo.

I *believe* the approach currently pursued by apollo is to write pure
chadoxml. I'm not sure if the logic for what to do about gene splits and
so on (see Mark G's excellent summary) will end up locked within Apollo,
and if that matters.

Note that I am no expert on XORT and ChadoXML - in fact I had nothing to
do with developing it; I'm not sure who to give credit to - Pinglei Stan
and Dave?

Cheers
Chris

On Wed, 20 Oct 2004, Aaron J. Mackey wrote:

>
> Let me just chime in that, after reading Chris and David's statements
> below, I completely agree that 1) chado (and SO) should have one, and
> only one definition for exons and that 2) shared exons is the way to do
> it.
>
> However, having recently had to deal with multiple transcripts with
> shared exons from a SO-compliant GFF3 data source, I will also agree
> that 3) sharing exons requires quite a bit more work on the
> programmers' part to keep sanity (so much so that I worry that I missed
> some things, and how can I really know?) and 4) a common API
> (preferably at the level of the schema, so that the continued
> responsibility for sanity was shifted back onto Chris and David's
> shoulders) would be a godsend to us poor users out here who are neither
> Apollo nor GMOD but are just struggling to keep up (remember us, we're
> the ones who review and fund your grants!)
>
> And, thanks to everyone for their hard work getting this figured out,
> it'll be worth it.
>
> -Aaron
>
> On Oct 20, 2004, at 2:29 PM, Scott Cain wrote:
>
> > Careful consideration, that is what this mailing list is all about :-)
> >
> > The main reason I would like to do this is that there are several
> > functions that multiple applications might like to do (like fetch genes
> > or other features, delete gene, add transcripts to a gene, add exons to
> > a gene, etc) and if we can provide SQL functions that would facillitate
> > that, it would be a big bonus to software developers.  I think they
> > should be functions and not triggers, so that if the developer needs to
> > work around them and use more primative SQL, he should be able to
> > (although at the risk of doing something bad to the database :-)
> >
> > Of course, I haven't fully fleshed it out in my head, let alone in
> > bytes, so there are no doubt problems with this approach that I haven't
> > considered yet.
> >
> > Scott
> >
> > On Wed, 2004-10-20 at 13:58, Allen Day wrote:
> >> scott,
> >>
> >> maybe.  this needs some careful thought.  my concern with this
> >> approach is
> >> that you'll be mixing application logic into the data model.  it may
> >> be
> >> that you can add some generic 'utility' functions to the schema as
> >> rules/triggers/views/temptables, but that you should store application
> >> specific functions outside the database.  however, this can lead to
> >> interdependent code scattered about multiple tiers of an application
> >> making for hard-to-kill bugs and reducing ease of adding new features
> >> too
> >> application and database.
> >>
> >> maybe the best thing to do is have an apollo logical module for chado.
> >> no other apps need to depend on it, so it doesn't try to be generic.
> >> so
> >> it can be optimized and as specialized as necessary.  at the expense
> >> of
> >> code duplication for other related apps.
> >>
> >> -allen
> >>
> >> On Wed, 20 Oct 2004, Scott Cain wrote:
> >>
> >>> Right, the reason I suggest SQL is that is the lowest common
> >>> denominator--writing wrappers in Perl or Java would be trivial, and
> >>> would give us a single place to fix things (I almost wrote a "single
> >>> point of failure", but I didn't want to sound to pessimistic :-)
> >>>
> >>>
> >>> On Wed, 2004-10-20 at 13:15, Guanming Wu wrote:
> >>>> It will be great if such API exists. It can be in SQL, Perl, Java,
> >>>> C/C++.
> >>>>
> >>>> Guanming
> >>>>
> >>>> Scott Cain wrote:
> >>>>
> >>>>> I've spent about a day mulling this over.  I completely sympathize
> >>>>> with
> >>>>> Chris' and Dave's concerns over implementing a 'non-shared' exon
> >>>>> schema.  Certainly, the schema was built to support it, so why
> >>>>> shouldn't
> >>>>> we?
> >>>>>
> >>>>> On thinking about it, what it really seems like we need is an API,
> >>>>> or
> >>>>> something like it.  At a GMOD developers meeting last year, a
> >>>>> group of
> >>>>> eight or ten of us sat in a room trying to hammer out a developer's
> >>>>> guide.  During that meeting, we decided that the point of common
> >>>>> interaction between applications would be the schema, so any API
> >>>>> like
> >>>>> thing needs to exist inside the schema, via triggers, functions and
> >>>>> possibly rules.  So what if there were functions like
> >>>>> 'delete_gene' and
> >>>>> 'add_exon_to_gene' that could be executed via SQL commands.  Would
> >>>>> this
> >>>>> help?  It certainly seems like it would facilitate the creation of
> >>>>> a
> >>>>> Apollo JDBC adaptor, as well as facilitate the creation of a DAS2
> >>>>> layer.
> >>>>>
> >>>>> Comments?
> >>>>>
> >>>>> Scott
> >>>>>
> >>>>> On Tue, 2004-10-19 at 11:45, David Emmert wrote:
> >>>>>
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I completely disagree with any proposal to institute "unshared"
> >>>>>> exons in
> >>>>>> chado, whether as an interim step or as standard practice.  The
> >>>>>> proposal
> >>>>>> to have "unshared" exons in the database is both bad biology and
> >>>>>> bad
> >>>>>> database practice.
> >>>>>>
> >>>>>> As Chris pointed out, the identity of an exon is defined by its
> >>>>>> genomic
> >>>>>> position.  Implementing multiple identical exons based on
> >>>>>> transcript
> >>>>>> context effectively denormalizes the database.
> >>>>>>
> >>>>>> It may be convenient for Apollo not to worry about normalizing
> >>>>>> data in
> >>>>>> its internal model, but that certainly doesn't mean that for the
> >>>>>> sake of
> >>>>>> Apollo's convenience, we should just forget about having a normal
> >>>>>> back-end database altogether.
> >>>>>>
> >>>>>> Chris is right that this makes the apollo fine-grained transaction
> >>>>>> adaptor approach gnarlier, but it was clear from the beginning
> >>>>>> that
> >>>>>> taking this approach was going to lead to some tough data issues
> >>>>>> which
> >>>>>> would have to be addressed.  It would be a terrible mistake to
> >>>>>> try to
> >>>>>> avoid dealing with a difficult, though completely solveable,
> >>>>>> apollo
> >>>>>> issue by compromising both SO and chado.
> >>>>>>
> >>>>>> -Dave
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 10/19/04 at 14:32 Scott Cain wrote:
> >>>>>>
> >>>>>>
> >>>>>>> I think we are talking about a database/book keeping point of
> >>>>>>> view,
> >>>>>>> versus the biologist point of view.  From a programming
> >>>>>>> perspective
> >>>>>>> (at
> >>>>>>> least mine), it makes life much easier if I can refer to an exon
> >>>>>>> that
> >>>>>>> is
> >>>>>>> shared among splice variants as separate entities, at least most
> >>>>>>> of
> >>>>>>> the
> >>>>>>> time.  From a biologist's perspective, this is ridiculous, but I
> >>>>>>> don't
> >>>>>>> see any reason why the biologist-user should ever see the data
> >>>>>>> presented
> >>>>>>> that way in an application, even if I do store them as separate
> >>>>>>> entities.
> >>>>>>>
> >>>>>>> For example, if I wanted to count the number of exons in a
> >>>>>>> genome or
> >>>>>>> the
> >>>>>>> average number of exons per gene, it requires remembering to do a
> >>>>>>> GROUP
> >>>>>>> BY when the type is exon and the genomic coordinates are equal
> >>>>>>> (which
> >>>>>>> could be done via a view and/or functions to do the common work).
> >>>>>>> What
> >>>>>>> I am trying to say is that I think it should be easier to
> >>>>>>> "collapse"
> >>>>>>> to
> >>>>>>> shared exons when you want to that to force the database and
> >>>>>>> applications that talk to it to require the sharing of exons.
> >>>>>>>
> >>>>>>> Scott
> >>>>>>>
> >>>>>>> On Tue, 2004-10-19 at 01:43, Shengqiang Shu wrote:
> >>>>>>>> are we really talking about practicality or sematics here?
> >>>>>>>>
> >>>>>>>> either way to store exons in db has its own implication on
> >>>>>>> application
> >>>>>>>> software.
> >>>>>>>>
> >>>>>>>> are exons component parts of a transcript (analog: arms are
> >>>>>>>> parts of
> >>>>>>>> human body)? if so, can an integral part of a thing be shared
> >>>>>>>> with
> >>>>>>>> another thing of the same kind?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Shu
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Sima Misra wrote:
> >>>>>>>>
> >>>>>>>>> I'm with Chris, here, Mark and Scott.
> >>>>>>>>>
> >>>>>>>>> An exon with the same genomic coordinates shared by multiple
> >>>>>>> transcripts
> >>>>>>>>> should be considered one exon.
> >>>>>>>>>
> >>>>>>>>> -sima
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Sorry Scott, I'm afraid I completely disagree
> >>>>>>>>>>
> >>>>>>>>>> Chado cares a lot about the definition of exon. If there is no
> >>>>>>> defined
> >>>>>>>>>> concept of exon then we lose interoperability. There's plenty
> >>>>>>>>>> of
> >>>>>>> software
> >>>>>>>>>> beyond gbrowse that uses chado, including things such as
> >>>>>>>>>> in-house
> >>>>>>>>>> reporting script that gives things such as exon counts and
> >>>>>>>>>> exon
> >>>>>>> context
> >>>>>>>>>> counts.
> >>>>>>>>>>
> >>>>>>>>>> Chado should use the SO definition of exon. Currently there
> >>>>>>>>>> is no
> >>>>>>> explicit
> >>>>>>>>>> account of identity in the SO definition, but it is strongly
> >>>>>>> hinted at.
> >>>>>>>>>> The identity of an exon is defined by it's 5' and 3' edges on
> >>>>>>>>>> the
> >>>>>>> genome
> >>>>>>>>>> -- not transcript. The SO definition essentially says this,
> >>>>>>>>>> but we
> >>>>>>> could
> >>>>>>>>>> make it more clear that different transcript contexts do not
> >>>>>>>>>> make
> >>>>>>> for
> >>>>>>>>>> different exons if the genomic coordinates are identical. I
> >>>>>>> believe that
> >>>>>>>>>> all biologists would agree on this definition, and it isn't
> >>>>>>>>>> up for
> >>>>>>> debate.
> >>>>>>>>>>
> >>>>>>>>>> Apollo can model exons internally however it likes. However,
> >>>>>>>>>> once
> >>>>>>> it
> >>>>>>>>>> exports to a SO-compliant model such as chado it has to
> >>>>>>>>>> conform to
> >>>>>>> SO.
> >>>>>>>>>>
> >>>>>>>>>> I think it would be very a bad idea to release a version of
> >>>>>>>>>> the
> >>>>>>> adapter
> >>>>>>>>>> which exported to a non-SO compliant chado database, and an
> >>>>>>> absolutely
> >>>>>>>>>> terrible idea to to release an exporter than exported chado
> >>>>>>>>>> that
> >>>>>>>>>> conflicted with SO.
> >>>>>>>>>>
> >>>>>>>>>> Databases being what they are, the initial release would
> >>>>>>>>>> quickly
> >>>>>>> ossify to
> >>>>>>>>>> become the de-facto standard, and we would lose
> >>>>>>>>>> interoperability.
> >>>>>>> If you
> >>>>>>>>>> must do this, then use a different feature type such as
> >>>>>>>>>> 'exon_transcript_context'. Even though this is not in SO (and
> >>>>>>> never should
> >>>>>>>>>> be) it is at least not inconsistent with SO.
> >>>>>>>>>>
> >>>>>>>>>> Sorry if this makes things a bit gnarlier as far as
> >>>>>>>>>> fine-grained
> >>>>>>>>>> transactions go - but we have known about this issue from the
> >>>>>>> beginning:
> >>>>>>>>>> http://sourceforge.net/mailarchive/message.php?msg_id=9580964
> >>>>>>>>>>
> >>>>>>>>>> Perhaps to make things easier you could make the first release
> >>>>>>> simply blow
> >>>>>>>>>> away all old exons and insert them as new. This is how the
> >>>>>>>>>> current
> >>>>>>> course
> >>>>>>>>>> grained transaction framework in place at FlyBase works. Of
> >>>>>>> course, you
> >>>>>>>>>> would lose exon tracking, I'm not sure how big a deal that is
> >>>>>>>>>> for
> >>>>>>> people.
> >>>>>>>>>>
> >>>>>>>>>> Cheers
> >>>>>>>>>> Chris
> >>>>>>>>>>
> >>>>>>>>>> On Mon, 18 Oct 2004, Scott Cain wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> I sent this out to the wider list, since the cc list was
> >>>>>>>>>>> getting
> >>>>>>> long
> >>>>>>>>>>> anyway...
> >>>>>>>>>>>
> >>>>>>>>>>> I don't have a problem mandating non-shared exons, because it
> >>>>>>> makes life
> >>>>>>>>>>> so much easier.  Hopefully the flybase people would agree,
> >>>>>>>>>>> even
> >>>>>>> if
> >>>>>>>>>>> that's not what they've got now.
> >>>>>>>>>>>
> >>>>>>>>>>> At the moment, I don't think chado cares whether exons are
> >>>>>>>>>>> shared
> >>>>>>> or
> >>>>>>>>>>> not.  Certainly, the GFF3 loader handles multiple Parent
> >>>>>>> annotations for
> >>>>>>>>>>> a single feature.  Also, the GBrowse adaptor shouldn't care
> >>>>>>> either,
> >>>>>>>>>>> though I can't say off hand if that is really true.  If it
> >>>>>>>>>>> isn't,
> >>>>>>> it is
> >>>>>>>>>>> a bug I'll need to fix.
> >>>>>>>>>>>
> >>>>>>>>>>> As to Doreen's question about supporting flybase, I believe,
> >>>>>>> (Mark or
> >>>>>>>>>>> Suzi, correct me if I am wrong) that the chado connectivity
> >>>>>>>>>>> that
> >>>>>>> is
> >>>>>>>>>>> being developed is essentially "from scratch" and flybase
> >>>>>>>>>>> won't
> >>>>>>> be using
> >>>>>>>>>>> it in the short term no matter what, so doing the easy thing
> >>>>>>> first
> >>>>>>>>>>> (non-shared exons) is the smart thing to do.
> >>>>>>>>>>>
> >>>>>>>>>>> Scott
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, 2004-10-18 at 14:25, Guanming Wu wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Scott,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Non-shared exon will make implementation in Apollo much
> >>>>>>>>>>>> easier
> >>>>>>> indeed.
> >>>>>>>>>>>> However, how about the chado database in general? Mark and
> >>>>>>>>>>>> I are
> >>>>>>>>>>>> worrying about locking ourselfves (or Apollo) to a specific
> >>>>>>>>>>>> case
> >>>>>>> in the
> >>>>>>>>>>>> rice if Chado is still using shared exons.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Another question is that changing from sharing (I guess
> >>>>>>>>>>>> default
> >>>>>>> in
> >>>>>>>>>>>> chado) to non-sharing will effect the downstream
> >>>>>>>>>>>> applications
> >>>>>>> (e.g.
> >>>>>>>>>>>> GBrowse)?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Guanming
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ware, Doreen wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi Scott,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We will be giving them Fgenesh models.  I do know if
> >>>>>>>>>>>>> Fgenesh
> >>>>>>> has shared
> >>>>>>>>>>>>> exons? (steve).  From the data we observed the students may
> >>>>>>> want to send
> >>>>>>>>>>>>> back shared exons based upon the experimental evidence.
> >>>>>>>>>>>>> Steve
> >>>>>>> will
> >>>>>>>>>>>>> comment also.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If Fly requires shared exons, and there is no extra
> >>>>>>>>>>>>> burden,  is
> >>>>>>> there a
> >>>>>>>>>>>>> problem with including this?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Doreen
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: Scott Cain [mailto:ca...@cs...]
> >>>>>>>>>>>>> Sent: Monday, October 18, 2004 2:02 PM
> >>>>>>>>>>>>> To: Guanming Wu
> >>>>>>>>>>>>> Cc: Mark Gibson; Doreen Ware
> >>>>>>>>>>>>> Subject: Re: shared or non-shared exon in the rice database
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi Guanming,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think this depends on what we have as starting material.
> >>>>>>>>>>>>>  If
> >>>>>>> we only
> >>>>>>>>>>>>> have similarity data to start with and will be creating
> >>>>>>>>>>>>> gene
> >>>>>>> models from
> >>>>>>>>>>>>> scratch, we could use nonshared exons, since it makes
> >>>>>>> development MUCH
> >>>>>>>>>>>>> easier, unless there is a good reason not to (Doreen?).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Scott
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, 2004-10-18 at 13:47, Guanming Wu wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Scott,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I wonder if exons in the rice database will be shared or
> >>>>>>> non-shared.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> The
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> decision somewhat effects our implementation of chado
> >>>>>>> transaction xml.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Guanming
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>> -------------------------------------------------------
> >>>>>>>>>> This SF.net email is sponsored by: IT Product Guide on
> >>>>>>> ITManagersJournal
> >>>>>>>>>> Use IT products in your business? Tell us what you think of
> >>>>>>>>>> them.
> >>>>>>> Give us
> >>>>>>>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to
> >>>>>>>>>> find
> >>>>>>> out more
> >>>>>>>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> Gmod-chado-seq-ad mailing list
> >>>>>>>>>> Gmo...@li...
> >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/gmod-chado-seq-ad
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -------------------------------------------------------
> >>>>>>>>> This SF.net email is sponsored by: IT Product Guide on
> >>>>>>> ITManagersJournal
> >>>>>>>>> Use IT products in your business? Tell us what you think of
> >>>>>>>>> them.
> >>>>>>> Give us
> >>>>>>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to
> >>>>>>>>> find
> >>>>>>> out more
> >>>>>>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Gmod-chado-seq-ad mailing list
> >>>>>>>>> Gmo...@li...
> >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/gmod-chado-seq-ad
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> --
> >>>>>>> -----------------------------------------------------------------
> >>>>>>> -------
> >>>>>>> Scott Cain, Ph. D.
> >>>>>>> ca...@cs...
> >>>>>>> GMOD Coordinator (http://www.gmod.org/)
> >>>>>>> 216-392-3087
> >>>>>>> Cold Spring Harbor Laboratory
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> -------------------------------------------------------
> >>>>>>> This SF.net email is sponsored by: IT Product Guide on
> >>>>>>> ITManagersJournal
> >>>>>>> Use IT products in your business? Tell us what you think of
> >>>>>>> them. Give
> >>>>>>> us
> >>>>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to
> >>>>>>> find out
> >>>>>>> more
> >>>>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >>>>>>> _______________________________________________
> >>>>>>> Gmod-chado-seq-ad mailing list
> >>>>>>> Gmo...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/gmod-chado-seq-ad
> >>>>>>>
> >>>>>>>
> >>>
> > --
> > -----------------------------------------------------------------------
> > -
> > Scott Cain, Ph. D.
> > ca...@cs...
> > GMOD Coordinator (http://www.gmod.org/)
> > 216-392-3087
> > Cold Spring Harbor Laboratory
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide on
> > ITManagersJournal
> > Use IT products in your business? Tell us what you think of them. Give
> > us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> > more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > _______________________________________________
> > Gmod-devel mailing list
> > Gmo...@li...
> > https://lists.sourceforge.net/lists/listinfo/gmod-devel
> >
> >
> --
> Aaron J. Mackey, Ph.D.
> Dept. of Biology, Goddard 212
> University of Pennsylvania       email:  am...@pc...
> 415 S. University Avenue         office: 215-898-1205
> Philadelphia, PA  19104-6017     fax:    215-746-6697
>
>