Menu
▾
▴
Re: [Gmod-schema] defining organism groups
|
From: naama.menda <naa...@gm...> - 2009-09-24 15:18:30
|
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® 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-12, 2009. Register now! > >> > >> > > 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® 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-12, 2009. > Register > >> > now! > >> > >> > 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® 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-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-schema > |
