Re: [Gmod-schema] defining organism groups

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

hi David,

2009/9/24 David Emmert <em...@mo...>

> Hi Naama,
>
> >> For common names, in most cases the organism table will be enough,
> >> but I might want to use more than one common name, for example create a
> >> group of diploid potatoes , and tetraploid  potatoes.
>
> I suppose the suggestion to use organismprop would make most sense here,
> even if
> ploidy isn't properly an attribute of a whole organism.
>
> Yes, organismprop can be used for storing multiple common names, but will
it be easy to map another datatype to  a specific common name? In SGN we
have a locus database, in which loci are grouped by common name , i.e. there
is one set of loci for all tomato species, so any locus in any of the ~30
cultivated and wild tomato species points to one common name (currently
stored as a flat list in a separate table). We specify the taxon of origin
on the allele level, pointing to an accession (mapped to a single organism).

> >> Unigenes can be built from multiple species, for example Nicotiana
> >> sylvestris and  Nocotiana tabacum.
> >>
>
> The Unigene set is a set of features in chado, or?  If the set of features
> contains features from multiple species, can't you just query for the
> unique
> feature.organism_id across the set to get the species?   One could argue
> that
> species is (already) an attribute of the features, so that implementing
> species
> again as an attribute of the Unigene set is redundant.
>
> You are right- if you use the feature table for storing the unigene
members, then you could find the member organisms by selecting the unique
organism_ids

>> As for libraries, a group can be made of several accessions (stocks) ,
> which
> >> is why I'm now thinking of a 'group' table , instead of organismgroup,
> which
> >> will have store groups of different objects (organism, stocks, and maybe
> >> more? )
>
> I don't know so much about specifying libraries.  Do you have an example of
> a
> library made of several accessions (stocks)?
>
> We have several libraries of clones from different accessions
http://sgn.cornell.edu/content/library_info.pl?library=cccwc22w

but here again, if you link the clone to an accession, you could argue that
creating a group of accessions for the library is redundant.

> I don't think a "group" table would be consistent with the design patterns
> of
> the chado schema, but if you want to send around the DDL, lets have a look.
>
> CREATE TABLE group (
    group_is serial  NOT NULL PRIMARY KEY,
    name varchar (255),
    type integer REFERENCES cvterm(cvterm_id)
    );

CREATE TABLE groupmember (
    groupmember_id serial NOT NULL PRIMARY KEY,
    group_id integer REFERENCES group,
    member_id integer REFERENCES organism(organism_id)
    );

this will be good just for grouping organisms. If you want to group
accessions, then one option would be tp have similar tables in the stock
module (stockgroup and stockgroup_member)
or drop the FK to organism and have another field 'type' in groupmember for
defining if this is a group of organisms or stocks or anything else.

I tend to be very conservative about adding new tables to chado.  As a
> shared
> schema, I think we need to keep it lean and mean for GMOD.  The "generic"
> thing
> with chado is at least partially an attempt to keep churn in the schema to
> a
> minimum.  What this means in practice is that we should exhaust all
> possibility of
> expanding implementation conventions to handle novel data before we decide
> to
> modify the schema.  This is why I keep asking for specific examples,
> because
> specific cases are the only way I know to demonstrate without question
> whether
> the schema needs changing or a new implementation convention can solve the
> problem.
>

I think you are right, and for most  cases organismprop gives an answer,
maybe except for genetic loci which are not linked to a single organisms
(tomato loci). I'm not sure if the proposed tables are the best for Chado,
but this is something we use extensively in SGN.

>
> Best,
>
> -D
>
>
> Thanks,
-Naama

> From naa...@gm...  Thu Sep 24 11:18:31 2009
> >> Subject: Re: [Gmod-schema] defining organism groups
> >> To: David Emmert <em...@mo...>
> >> Cc: gmo...@li...
> >>
> >>
> >> For common names, in most cases the organism table will be enough,
> >> but I might want to use more than one common name, for example create a
> >> group of diploid potatoes , and tetraploid  potatoes.
> >>
> >> Unigenes can be built from multiple species, for example Nicotiana
> >> sylvestris and  Nocotiana tabacum.
> >>
> >>
> >> As for libraries, a group can be made of several accessions (stocks) ,
> which
> >> is why I'm now thinking of a 'group' table , instead of organismgroup,
> which
> >> will have store groups of different objects (organism, stocks, and maybe
> >> more? )
> >>
> >>
> >> -Naama
> >>
> >>
> >>
> >> On Thu, Sep 24, 2009 at 10:39 AM, David Emmert <
> em...@mo...>wrote:
> >>
> >> >
> >> > Hi Naama,
> >> >
> >> > >> I can think now of groups of organisms or accessions (stocks).
> >> > >> This means a more generic 'groups' table will be more suitable.
> >> >
> >> > I'm not sure I understand what you mean.  Maybe it would help if you
> gave a
> >> > few
> >> > examples of these groups.  That is, if we go back to your suggestion
> for an
> >> > organismgroup table, what would the types be?
> >> >
> >> > Re-reading this thread, I see two "grouping" use-cases at hand,
> namely,
> >> > creating a unigene set and setting the common name "potato" to a set
> of
> >> > Solanum species.  It seems to me like both of these things can be done
> >> > within
> >> > existing chado structures: using library module to define a unigene
> set,
> >> > and
> >> > using organism.common_name for "potato".   So what are specific
> use-cases
> >> > which
> >> > make organismgroup and organismgroup_member necessary?
> >> >
> >> > Best,
> >> >
> >> > -Dave
> >> >
> >> >
> >> > >From gmo...@li...  Thu Sep 24 10:06:51
> 2009
> >> > >> To: David Emmert <em...@mo...>
> >> > >> Cc: gmo...@li...
> >> > >> Subject: Re: [Gmod-schema] defining organism groups
> >> > >>
> >> > >> yes, if you have a library from multiple organisms or multiple
> >> > accessions
> >> > >> you would need wither a linking table
> >> > >> (library_organism, library_stock)
> >> > >> or a group_id.
> >> > >>
> >> > >> I can think now of groups of organisms or accessions (stocks).
> >> > >> This means a more generic 'groups' table will be more suitable.
> >> > >>
> >> > >> Storing the grouping info in organismprop or stockprop will give
> the
> >> > same
> >> > >> data about the group members, but wouldn't it be difficult to link
> other
> >> > >> objects (libraries, unigenes,) to the group?
> >> > >>
> >> > >> -Naama
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >> On Thu, Sep 24, 2009 at 9:47 AM, David Emmert <
> >> > em...@mo...>wrote:
> >> > >>
> >> > >> >
> >> > >> > Hi,
> >> > >> >
> >> > >> > >> Good point. A group can include accessions stored in the stock
> >> > table.
> >> > >> > >> If I have a library constructed from several strains, where
> would
> >> > this
> >> > >> > >> grouping info go?
> >> > >> >
> >> > >> >
> >> > >> > I hate to muddy the waters (yet more!?), but if what we're
> talking
> >> > about
> >> > >> > is libraries and collections, maybe it would make more sense to
> use
> >> > the
> >> > >> > library module?
> >> > >> >
> >> > >> > FlyBase currently is using the library module to manage the
> following
> >> > >> > collections of features:
> >> > >> >
> >> > >> > fb_2009_08_reporting_test=> select distinct(cvt.name)
> >> > >> >                            from cvterm cvt, library l
> >> > >> >                            where l.type_id = cvt.cvterm_id;
> >> > >> >            name
> >> > >> > -----------------------------
> >> > >> >  dsRNA construct collection
> >> > >> >  cDNA collection
> >> > >> >  dsRNA amplicon platform
> >> > >> >  expression microarray
> >> > >> >  RNA-Seq junction collection
> >> > >> >  cDNA library
> >> > >> > (6 rows)
> >> > >> >
> >> > >> > Everything but the RNA-Seq junctions are public in FlyBase now.
> This
> >> > link
> >> > >> > will give you a list of library/collection reports in FlyBase:
> >> > >> >
> >> > >> >
> >> > >> >
> >> >
> http://flybase.org/cgi-bin/quicksearch.cgi?species=all&field=ALLTEXT&db=fblc&addata=all&context=FBlc*&authors=&year=&alltext=&caller=quicksearch
> >> > >> >
> >> > >> > If I'm understanding your requirements, we'd probably need to
> move
> >> > >> > library.organism_id into a linking table (library_organism or
> >> > whatever)
> >> > >> > to support libraries from multiple organisms, but if it makes the
> >> > library
> >> > >> > module more generally useable, we should do it.
> >> > >> >
> >> > >> > Anyway, just a suggestion...
> >> > >> >
> >> > >> > -D
> >> > >> >
> >> > >> >
> >> > >> > From gmo...@li...  Thu Sep 24
> 00:20:18
> >> > 2009
> >> > >> > >> To: Isabelle Phan <isa...@sb...>
> >> > >> > >> Cc: "sc...@sc..." <sc...@sc...>,
> >> > >> > >>         gmod schema <gmo...@li...>
> >> > >> > >> Subject: Re: [Gmod-schema] defining organism groups
> >> > >> > >>
> >> > >> > >> Good point. A group can include accessions stored in the stock
> >> > table.
> >> > >> > >> If I have a library constructed from several strains, where
> would
> >> > this
> >> > >> > >> grouping info go?
> >> > >> > >>
> >> > >> > >> -Naama
> >> > >> > >>
> >> > >> > >>
> >> > >> > >>
> >> > >> > >> On Wed, Sep 23, 2009 at 8:36 PM, Isabelle Phan <
> >> > isa...@sb...
> >> > >> > >wrote:
> >> > >> > >>
> >> > >> > >> > Agreed. I think the correct module would be 'taxonomy', but
> >> > organism
> >> > >> > is
> >> > >> > >> > fine.
> >> > >> > >> > Note that the current table structure (genus, species,
> strain)
> >> > breaks
> >> > >> > down
> >> > >> > >> > for some bacteria (and also viruses, though I guess these
> are not
> >> > >> > included
> >> > >> > >> > in Model Organisms).
> >> > >> > >> >
> >> > >> > >> > Isabelle
> >> > >> > >> >
> >> > >> > >> > --
> >> > >> > >> > Isabelle Phan, DPhil
> >> > >> > >> > Seattle Biomedical Research Institute
> >> > >> > >> > +1(206)256 7113
> >> > >> > >> >
> >> > >> > >> >
> >> > >> > >> >
> >> > >> > >> > > -----Original Message-----
> >> > >> > >> > > From: Hilmar Lapp [mailto:hl...@du...]
> >> > >> > >> > > Sent: Wednesday, September 23, 2009 2:07 PM
> >> > >> > >> > > To: Robert Buels
> >> > >> > >> > > Cc: sc...@sc...; gmod schema
> >> > >> > >> > > Subject: Re: [Gmod-schema] defining organism groups
> >> > >> > >> > >
> >> > >> > >> > >
> >> > >> > >> > > On Sep 23, 2009, at 2:12 PM, Robert Buels wrote:
> >> > >> > >> > >
> >> > >> > >> > > > Question is, should they go into
> >> > >> > >> > > >
> >> > >> > >> > > > A.) the organism module
> >> > >> > >> > > > B.) the phylogeny module
> >> > >> > >> > >
> >> > >> > >> > >
> >> > >> > >> > > As stated so far the rationale behind it doesn't strike me
> as
> >> > >> > >> > > having much or anything to do with phylogeny, so I vote
> for A.
> >> > >> > >> > >
> >> > >> > >> > > Organismprop could be used too. If you wanted to attach
> >> > >> > >> > > semantics to the grouping, it'd probably be the better way
> of
> >> > >> > >> > > doing this. Or the group table should have a link to
> cvterm.
> >> > >> > >> > >
> >> > >> > >> > >         -hilmar
> >> > >> > >> > > --
> >> > >> > >> > >
> ===========================================================
> >> > >> > >> > > : Hilmar Lapp  -:-  Durham, NC  -:- hlapp at duke dot edu
> :
> >> > >> > >> > >
> ===========================================================
> >> > >> > >> > >
> >> > >> > >> > >
> >> > >> > >> > >
> >> > >> > >> > >
> >> > >> > >> > >
> >> > >> > >> > >
> --------------------------------------------------------------
> >> > >> > >> > > ----------------
> >> > >> > >> > > Come build with us! The BlackBerry&reg; Developer
> Conference
> >> > >> > >> > > in SF, CA is the only developer event you need to attend
> this
> >> > >> > >> > > year. Jumpstart your developing skills, take BlackBerry
> >> > >> > >> > > mobile applications to market and stay ahead of the curve.
> >> > >> > >> > > Join us from November 9&#45;12, 2009. Register now&#33;
> >> > >> > >> > > http://p.sf.net/sfu/devconf
> >> > >> > >> > > _______________________________________________
> >> > >> > >> > > Gmod-schema mailing list
> >> > >> > >> > > Gmo...@li...
> >> > >> > >> > > https://lists.sourceforge.net/lists/listinfo/gmod-schema
> >> > >> > >> > >
> >> > >> > >> >
> >> > >> > >> >
> >> > >> > >> >
> >> > >> >
> >> >
> ------------------------------------------------------------------------------
> >> > >> > >> > Come build with us! The BlackBerry&reg; Developer Conference
> in
> >> > SF, CA
> >> > >> > >> > is the only developer event you need to attend this year.
> >> > Jumpstart
> >> > >> > your
> >> > >> > >> > developing skills, take BlackBerry mobile applications to
> market
> >> > and
> >> > >> > stay
> >> > >> > >> > ahead of the curve. Join us from November 9&#45;12, 2009.
> >> > Register
> >> > >> > now&#33;
> >> > >> > >> > http://p.sf.net/sfu/devconf
> >> > >> > >> > _______________________________________________
> >> > >> > >> > Gmod-schema mailing list
> >> > >> > >> > Gmo...@li...
> >> > >> > >> > https://lists.sourceforge.net/lists/listinfo/gmod-schema
> >> > >> > >> >
> >> > >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> >> > is the only developer event you need to attend this year. Jumpstart
> your
> >> > developing skills, take BlackBerry mobile applications to market and
> stay
> >> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
> now&#33;
> >> > http://p.sf.net/sfu/devconf
> >> > _______________________________________________
> >> > Gmod-schema mailing list
> >> > Gmo...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/gmod-schema
> >> >
>