Menu
▾
▴
Re: [Gmod-schema] defining organism groups
|
From: David E. <em...@mo...> - 2009-09-24 16:12:18
|
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. >> 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. >> 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)? 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. 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. Best, -D >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® 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 >> > |
