Menu
▾
▴
Re: [Gmod-schema] defining organism groups
|
From: Naama M. <naa...@gm...> - 2009-09-24 14:03:56
|
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 > >> > > |
