Menu
▾
▴
gmod-schema — For discussion of GMOD schema development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(28) |
Nov
(87) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(109) |
Feb
(107) |
Mar
(117) |
Apr
(5) |
May
(156) |
Jun
(83) |
Jul
(86) |
Aug
(25) |
Sep
(17) |
Oct
(14) |
Nov
(82) |
Dec
(50) |
| 2004 |
Jan
(14) |
Feb
(75) |
Mar
(110) |
Apr
(83) |
May
(20) |
Jun
(36) |
Jul
(12) |
Aug
(37) |
Sep
(9) |
Oct
(11) |
Nov
(52) |
Dec
(68) |
| 2005 |
Jan
(46) |
Feb
(94) |
Mar
(68) |
Apr
(55) |
May
(67) |
Jun
(65) |
Jul
(67) |
Aug
(96) |
Sep
(79) |
Oct
(46) |
Nov
(24) |
Dec
(64) |
| 2006 |
Jan
(39) |
Feb
(31) |
Mar
(48) |
Apr
(58) |
May
(31) |
Jun
(57) |
Jul
(29) |
Aug
(40) |
Sep
(22) |
Oct
(31) |
Nov
(44) |
Dec
(51) |
| 2007 |
Jan
(103) |
Feb
(172) |
Mar
(59) |
Apr
(41) |
May
(33) |
Jun
(50) |
Jul
(60) |
Aug
(51) |
Sep
(21) |
Oct
(40) |
Nov
(89) |
Dec
(39) |
| 2008 |
Jan
(28) |
Feb
(20) |
Mar
(19) |
Apr
(29) |
May
(29) |
Jun
(24) |
Jul
(32) |
Aug
(16) |
Sep
(35) |
Oct
(23) |
Nov
(17) |
Dec
(19) |
| 2009 |
Jan
(4) |
Feb
(23) |
Mar
(16) |
Apr
(16) |
May
(38) |
Jun
(54) |
Jul
(18) |
Aug
(40) |
Sep
(58) |
Oct
(6) |
Nov
(8) |
Dec
(29) |
| 2010 |
Jan
(40) |
Feb
(40) |
Mar
(63) |
Apr
(95) |
May
(136) |
Jun
(58) |
Jul
(91) |
Aug
(55) |
Sep
(77) |
Oct
(52) |
Nov
(85) |
Dec
(37) |
| 2011 |
Jan
(22) |
Feb
(46) |
Mar
(73) |
Apr
(138) |
May
(75) |
Jun
(35) |
Jul
(41) |
Aug
(13) |
Sep
(13) |
Oct
(11) |
Nov
(21) |
Dec
(5) |
| 2012 |
Jan
(13) |
Feb
(34) |
Mar
(59) |
Apr
(4) |
May
(13) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(1) |
| 2013 |
Jan
(18) |
Feb
(28) |
Mar
(19) |
Apr
(42) |
May
(43) |
Jun
(41) |
Jul
(41) |
Aug
(31) |
Sep
(6) |
Oct
(2) |
Nov
(2) |
Dec
(70) |
| 2014 |
Jan
(55) |
Feb
(98) |
Mar
(44) |
Apr
(40) |
May
(15) |
Jun
(18) |
Jul
(20) |
Aug
(1) |
Sep
(13) |
Oct
(3) |
Nov
(37) |
Dec
(85) |
| 2015 |
Jan
(16) |
Feb
(12) |
Mar
(16) |
Apr
(13) |
May
(16) |
Jun
(3) |
Jul
(23) |
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(2) |
| 2016 |
Jan
(12) |
Feb
(1) |
Mar
(9) |
Apr
(13) |
May
(4) |
Jun
(5) |
Jul
|
Aug
|
Sep
(10) |
Oct
(11) |
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
(11) |
Apr
(8) |
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2018 |
Jan
(6) |
Feb
(6) |
Mar
(3) |
Apr
(9) |
May
(3) |
Jun
|
Jul
|
Aug
(3) |
Sep
(8) |
Oct
(1) |
Nov
(1) |
Dec
(4) |
| 2019 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2020 |
Jan
(22) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(7) |
2
(6) |
3
(1) |
4
(1) |
5
|
|
6
|
7
|
8
|
9
|
10
|
11
(1) |
12
|
|
13
|
14
(1) |
15
(5) |
16
(7) |
17
(3) |
18
|
19
|
|
20
|
21
(1) |
22
|
23
(8) |
24
(14) |
25
(1) |
26
|
|
27
|
28
(1) |
29
(1) |
30
|
|
|
|
|
From: Sook J. <so...@gm...> - 2009-09-29 20:07:00
|
Hello, I have a question about map module. The description of featurerange table below mentions leftendf and rightstartf but there are no fields in the actual table. Are there supposed to be more fields such as leftendf, rightstartf, (even leftstartf and rightendf)? http://gmod.org/wiki/Chado_Map_Module "In cases where the start and end of a mapped feature is a range, leftendf and rightstartf are populated. leftstartf_id, leftendf_id, rightstartf_id, rightendf_id are the ids of features with respect to which the feature is being mapped." I'm trying to model QTL with a linkage group, start and end. How can this be modeled in featurerange - featuremap_id for the map, feature_id for the QTL, leftstartf_id for the linkage group and rightendf_id for the same linkage group (since this field is NOT NULL)? Then where does the actual position (start and end) go? To the leftendf and rightstartf if those fields do exist? If this table (featurerange) is designed for specific data such as cytological bands, wouldn't it be nice to have start and end instead of mappos in featurepos table? Thanks! Sook |
|
From: Dave C. G. H. D. <he...@gm...> - 2009-09-28 17:44:13
|
Hello all, I am pleased to announce that DIYA and Tripal are now a part of the GMOD project. DIYA: The Do It Yourself Annotator DIYA is a modular and configurable open source pipeline framework, written in Perl, used (initially) for the rapid annotation of microbial genome sequences. The software is currently used to take nucleotide sequence contigs as input, either in the form of complete genomes or the result of shotgun sequencing, and produce an annotated sequence in GFF format. Current development seeks to integrate DIYA with the AMOS collection of assembly tools. See http://gmod.org/wiki/DIYA Tripal: A new Web Front End for Chado Tripal is a collection of Drupal modules that is already powering several web sites, including the Marine Genomics Project and Fagaceae Genomics Web. Tripal supports Drupal themes, page content and look and feel customization, materialized views, searching, and job management out of the box. Tripal can be downloaded from the GMOD SVN repository. Tripal (already!) has an extensive User's Guide and a tutorial to help users install, configure and extend Tripal. See http://gmod.org/wiki/Tripal Please welcome these projects, and their developers, to the GMOD community. Thanks, Dave C. -- * Please keep responses on the list! * http://gmod.org/wiki/GMOD_News * Was this helpful? Let us know at http://gmod.org/wiki/Help_Desk_Feedback |
|
From: Naama M. <naa...@gm...> - 2009-09-25 02:03:29
|
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® 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 > >> > > |
|
From: Stephen F. <FI...@ex...> - 2009-09-24 16:32:14
|
We have the same problem of how to map multiple organisms to a single unigene. The way pull out this information, which is probably not ideal, but the only way we could think to do so in chado is by way of the analysisfeature table. We correlate the features that are used in an analysis using the analysisfeature table. An inner join between this table, the feature table and the organism table gives you the the list of organisms with features in your unigene builds. It may not be fast enough for a quick query on a web page, but can give you the information you want. -----Original Message----- From: naama.menda [mailto:naa...@gm...] Sent: Thu 9/24/2009 12:19 PM To: fa...@mo... Cc: Chris Mungall; gmo...@li...; Don Gilbert; sc...@sc... Subject: Re: [Gmod-schema] defining organism groups The issue we have is not only how to distinguish different organisms by taxonomy, but rather how to link to these groups. If you have a unigene build of 10 drosophilids, where would you make the link between the unigene build and the member organisms? -Naama On Thu, Sep 24, 2009 at 11:46 AM, kathleen.flybase < kat...@gm...> wrote: > Hi, > Just a quick note. Very timely discussion. > Flybase is considering adding to the organism module, organism_cvterm as > well as an organism_cvtermprop. We've ruffed out some use cases but I'm out > of the office until next week so they are not readily available. Basically > the organism_cvterm table would hold more detailed info on how to build the > taxonomic name. We are considering using organismprop to distinguish > drosophilids vs non-drosophilids. > > Cheers, > Kathleen Falls > > > On Wed, Sep 23, 2009 at 7:14 PM, Chris Mungall <cj...@be...>wrote: > >> >> I agree the cv module makes most sense here. >> >> I think ideally a new organism_cvterm relationship would be preferable >> to organismprop. >> >> On Sep 23, 2009, at 7:27 PM, Don Gilbert wrote: >> >> > What about using the organismprop table, and creating a CV term to >> > handle this? Much of chado's biological logic has been pushed into >> > CV terms for various reasons. It seems to me that adding organism >> > grouping >> > CV terms would let you classify and group the species you want, much >> > like having CV terms for the other bits (feature types, etc.) do. >> > - Don >> > >> > >> ------------------------------------------------------------------------------ >> > 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 >> >> > > > -- > Kathleen Falls > FlyBase > Department of Molecular and Cellular Biology > Harvard University > BL 4053 > 16 Divinity Ave > Cambridge, MA 02138 > > http://www.flybase.org/ > > > > ------------------------------------------------------------------------------ > 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 > > |
|
From: naama.menda <naa...@gm...> - 2009-09-24 16:20:27
|
The issue we have is not only how to distinguish different organisms by taxonomy, but rather how to link to these groups. If you have a unigene build of 10 drosophilids, where would you make the link between the unigene build and the member organisms? -Naama On Thu, Sep 24, 2009 at 11:46 AM, kathleen.flybase < kat...@gm...> wrote: > Hi, > Just a quick note. Very timely discussion. > Flybase is considering adding to the organism module, organism_cvterm as > well as an organism_cvtermprop. We've ruffed out some use cases but I'm out > of the office until next week so they are not readily available. Basically > the organism_cvterm table would hold more detailed info on how to build the > taxonomic name. We are considering using organismprop to distinguish > drosophilids vs non-drosophilids. > > Cheers, > Kathleen Falls > > > On Wed, Sep 23, 2009 at 7:14 PM, Chris Mungall <cj...@be...>wrote: > >> >> I agree the cv module makes most sense here. >> >> I think ideally a new organism_cvterm relationship would be preferable >> to organismprop. >> >> On Sep 23, 2009, at 7:27 PM, Don Gilbert wrote: >> >> > What about using the organismprop table, and creating a CV term to >> > handle this? Much of chado's biological logic has been pushed into >> > CV terms for various reasons. It seems to me that adding organism >> > grouping >> > CV terms would let you classify and group the species you want, much >> > like having CV terms for the other bits (feature types, etc.) do. >> > - Don >> > >> > >> ------------------------------------------------------------------------------ >> > 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 >> >> > > > -- > Kathleen Falls > FlyBase > Department of Molecular and Cellular Biology > Harvard University > BL 4053 > 16 Divinity Ave > Cambridge, MA 02138 > > http://www.flybase.org/ > > > > ------------------------------------------------------------------------------ > 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 > > |
|
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 >> > |
|
From: kathleen.flybase <kat...@gm...> - 2009-09-24 15:46:14
|
Hi, Just a quick note. Very timely discussion. Flybase is considering adding to the organism module, organism_cvterm as well as an organism_cvtermprop. We've ruffed out some use cases but I'm out of the office until next week so they are not readily available. Basically the organism_cvterm table would hold more detailed info on how to build the taxonomic name. We are considering using organismprop to distinguish drosophilids vs non-drosophilids. Cheers, Kathleen Falls On Wed, Sep 23, 2009 at 7:14 PM, Chris Mungall <cj...@be...> wrote: > > I agree the cv module makes most sense here. > > I think ideally a new organism_cvterm relationship would be preferable > to organismprop. > > On Sep 23, 2009, at 7:27 PM, Don Gilbert wrote: > > > What about using the organismprop table, and creating a CV term to > > handle this? Much of chado's biological logic has been pushed into > > CV terms for various reasons. It seems to me that adding organism > > grouping > > CV terms would let you classify and group the species you want, much > > like having CV terms for the other bits (feature types, etc.) do. > > - Don > > > > > ------------------------------------------------------------------------------ > > 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 > > -- Kathleen Falls FlyBase Department of Molecular and Cellular Biology Harvard University BL 4053 16 Divinity Ave Cambridge, MA 02138 http://www.flybase.org/ |
|
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 > |
|
From: Chris M. <cj...@be...> - 2009-09-24 15:07:26
|
On Sep 23, 2009, at 7:12 PM, Robert Buels wrote: > Naama Menda wrote: >> I think it should be in the organism module since it has FK to >> organism. > Well lots of other things have FKs into organism that aren't in the > organism module. That just means whatever module it goes into has to > have a dependency there. > > However, Naama's proposal seems more general than just taxonomy or > phylogeny, since this could be used to keep track of groups of > organisms > that, for example, have red fruits. ;-) > > BUT, what about keeping taxonomy/phylogeny data (I don't really know > the > difference between these two, but there probably is one). I'm sure you will get many different answers from evolutionary biologists. One practical distinction is that the edges in a phylogenetic tree are labeled with branch lengths whereas this would not be done in a taxonomy (or cv / ontology) > It looks to > me like the Phylogeny module is primarily concerned with storing trees > (i.e. directed acyclic graphs) of organism relationships, while > Naama's > proposal would store arbitrary graphs. > > Seems to me like these are good tables to add (do people agree with > this?) > > Question is, should they go into > > A.) the organism module > B.) the phylogeny module > or > C.) a new module? > > I would vote for A. Thoughts from others on this? > > Rob > > > ------------------------------------------------------------------------------ > 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 > |
|
From: David E. <em...@mo...> - 2009-09-24 14:40:37
|
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
>> > >> >
>> >
|
|
From: David E. <em...@mo...> - 2009-09-24 14:26:25
|
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
>> >
|
|
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 > >> > > |
|
From: Hilmar L. <hl...@du...> - 2009-09-24 13:08:42
|
On Sep 24, 2009, at 12:03 AM, Naama Menda wrote: > If the group name is stored as a cvterm , it will require adding a > cv for each group type (e.g. 'unigene build' , 'common name' ..) I don't think so. If you wanted to use semantics to a group name (such as that a particular group is_a or belongs_to or part_of a unigene build, then you would put that in the cvterm and cvterm relationship tables, not into the name of the cv. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : =========================================================== |
|
From: Stephen F. <FI...@ex...> - 2009-09-24 04:47:16
|
Hi Scott, Thanks for the response. The primary reason for asking for a rank column is to remove the 'value' column from the index since we're trying to store some analysis results that can be rather large in the analysisprop table. We would like to separate some of these into "chunks" but even some of those might be larger than the column width for an index. Another benefit would make this table more consistent with other prop tables like the featureprop, libraryprop, cvtermprop etc. For the analysisfeatureprop table we're essentially storing analysis outputs for InterProScan (e.g. HTML output), KEGG mappings (HTML output), and detailed blast results (XML output) for each feature. On the webpage for a feature, we pull that data out of the analysisfeatureprop table and quickly parse and display. Originally we had these items stored on the file system, but we wanted to simplify data management by storing everything in the database. This doesn't substitute for placing of CVterms mappings, etc, derived from these analysis into the CVterm table. We do that as well. We just wanted to show more information. Thanks! Stephen -----Original Message----- From: cai...@gm... [mailto:cai...@gm...] On Behalf Of Scott Cain Sent: Wednesday, September 16, 2009 12:20 PM To: Stephen Ficklin Cc: gmo...@li... Subject: Re: [Gmod-schema] Chado question/request Hi Stephen, So for the analysisprop table, the point in adding a rank column is so that you could break whatever information you're inserting up into chucks that can then be ordered with the rank? Seems like a reasonable idea. The alternative you mentioned is getting rid of the index, but I agree, I'd rather not do that. Given that this will put an implicit limit on the size of the value column, should we also change value from a text field to a long varchar? I think postgres supports an 8k varchar. Presumably, no one else has exceeded this size, as they would have run into the same problem. As for the analysisfeatureprop table, I'm a little surprised no one has formally suggested it before now. I believe other people have at least thought about it, particularly for better typing of scores associated with particular results, but this design is sufficiently flexible that other things could be stored there as well. What sorts of things do you envision storing in this table? Thanks, Scott On Mon, Sep 14, 2009 at 3:02 PM, Stephen Ficklin <FI...@ex...> wrote: > Hello, > > > > We're trying to get some KEGG/KAAS results into the analysisprop table and > the table has a unique constraint named analysisprop_c1 that includes the > analysis_id, type_id and value fields. When inserting a record we're > getting maximum size limit exceeded errors when inserting a record larger > than 8Kb on the index. If we remove the index there's no problem inserting, > but we'd prefer not to remove the index. Other "property" tables have a > "rank" column that is used in the unique index. Can we request that the > table be altered to add a rank column with an appropriate unique constraint? > > > > Also, I would like to propose the addition of a new table: > analysisfeatureprop. The schema would be: > > > > CREATE TABLE analysisfeatureprop ( > > analysisfeatureprop_id SERIAL PRIMARY KEY, > > analysisfeature_id INTEGER NOT NULL REFERENCES > analysisfeature(analysisfeature_id), > > type_id INTEGER NOT NULL REFERENCES cvterm(cvterm_id), > > value TEXT, > > rank INTEGER NOT NULL, > > CONSTRAINT analysisfeature_id_type_id_rank UNIQUE(analysisfeature_id, > type_id, rank) > > ); > > > > We would like to use this table for storing results from an analysis by > feature. We cannot currently store this in the featureprop table when we > have more than one analysis on the same feature with the same type. In > development of Tripal we've had to manually create this table. > > > > Thanks, > > Stephen > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-schema > > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Coordinator (http://gmod.org/) 216-392-3087 Ontario Institute for Cancer Research |
|
From: Naama M. <naa...@gm...> - 2009-09-24 04:17:43
|
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 > |
|
From: Naama M. <nm...@co...> - 2009-09-24 04:04:14
|
Yes, If using an organismgroup table, the 'type' field should really be a
cvterm_id.
I'm not sure if organismprop is the best table for this .
How do you think group names and types should be stored?
If I have a unigene build or a library from sequences of 100 species,
storing this information in organism prop will require
inserting the group name in the value field for each organism and type_id =
a cvterm for the group type ('unigene build' and a cv with name = 'organism
groups' ).
If the group name is stored as a cvterm , it will require adding a cv for
each group type (e.g. 'unigene build' , 'common name' ..)
-Naama
On Wed, Sep 23, 2009 at 5:07 PM, Hilmar Lapp <hl...@du...> wrote:
>
>
> 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 :
> ===========================================================
>
>
>
>
>
|
|
From: Isabelle P. <isa...@sb...> - 2009-09-24 00:37:42
|
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 > |
|
From: Chris M. <cj...@be...> - 2009-09-23 23:15:59
|
I agree the cv module makes most sense here. I think ideally a new organism_cvterm relationship would be preferable to organismprop. On Sep 23, 2009, at 7:27 PM, Don Gilbert wrote: > What about using the organismprop table, and creating a CV term to > handle this? Much of chado's biological logic has been pushed into > CV terms for various reasons. It seems to me that adding organism > grouping > CV terms would let you classify and group the species you want, much > like having CV terms for the other bits (feature types, etc.) do. > - Don > > ------------------------------------------------------------------------------ > 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 > |
|
From: Hilmar L. <hl...@du...> - 2009-09-23 21:07:28
|
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 : =========================================================== |
|
From: Don G. <gil...@cr...> - 2009-09-23 18:27:12
|
What about using the organismprop table, and creating a CV term to handle this? Much of chado's biological logic has been pushed into CV terms for various reasons. It seems to me that adding organism grouping CV terms would let you classify and group the species you want, much like having CV terms for the other bits (feature types, etc.) do. - Don |
|
From: David E. <em...@mo...> - 2009-09-23 18:24:43
|
Hi, If it isn't too much trouble, could I ask that you wait till next week before making the changes in the organism module? One of our developers here at FlyBase, Kathleen Falls, has been focusing on reorganizing organism/species data in FlyBase recently, and I'm wondering whether she has some schema changes in mind. Unfortunately, she's on holiday till Monday. If you can wait, I'll make sure we get back to this thread first thing next week. Best, -Dave >From gmo...@li... Wed Sep 23 14:13:14 2009 >> To: Naama Menda <nm...@co...> >> Cc: sc...@sc..., gmod schema <gmo...@li...> >> Subject: Re: [Gmod-schema] defining organism groups >> >> Naama Menda wrote: >> > I think it should be in the organism module since it has FK to organism. >> Well lots of other things have FKs into organism that aren't in the >> organism module. That just means whatever module it goes into has to >> have a dependency there. >> >> However, Naama's proposal seems more general than just taxonomy or >> phylogeny, since this could be used to keep track of groups of organisms >> that, for example, have red fruits. ;-) >> >> BUT, what about keeping taxonomy/phylogeny data (I don't really know the >> difference between these two, but there probably is one). It looks to >> me like the Phylogeny module is primarily concerned with storing trees >> (i.e. directed acyclic graphs) of organism relationships, while Naama's >> proposal would store arbitrary graphs. >> >> Seems to me like these are good tables to add (do people agree with this?) >> >> Question is, should they go into >> >> A.) the organism module >> B.) the phylogeny module >> or >> C.) a new module? >> >> I would vote for A. Thoughts from others on this? >> >> Rob >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> |
|
From: Robert B. <rm...@co...> - 2009-09-23 18:12:33
|
Naama Menda wrote: > I think it should be in the organism module since it has FK to organism. Well lots of other things have FKs into organism that aren't in the organism module. That just means whatever module it goes into has to have a dependency there. However, Naama's proposal seems more general than just taxonomy or phylogeny, since this could be used to keep track of groups of organisms that, for example, have red fruits. ;-) BUT, what about keeping taxonomy/phylogeny data (I don't really know the difference between these two, but there probably is one). It looks to me like the Phylogeny module is primarily concerned with storing trees (i.e. directed acyclic graphs) of organism relationships, while Naama's proposal would store arbitrary graphs. Seems to me like these are good tables to add (do people agree with this?) Question is, should they go into A.) the organism module B.) the phylogeny module or C.) a new module? I would vote for A. Thoughts from others on this? Rob |
|
From: Naama M. <nm...@co...> - 2009-09-23 16:41:53
|
I think it should be in the organism module since it has FK to organism.
so OrganismgroupMember.pm will have
__PACKAGE__->belongs_to(
"organism",
"Bio::Chado::Schema::Organism::Organism",
{ organism_id => "organism_id" },
);
and in Organismgroup.pm
__PACKAGE__->has_many(
"organismgroup_members",
"Bio::Chado::Schema::Organism::OrganismgroupMember",
{ "foreign.organismgroup_id" => "self.organismgroup_id" },
);
Naama Menda
Boyce Thompson Institute for Plant Research
Tower Rd
Ithaca NY 14853
USA
(607) 254 3569
Sol Genomics Network
http://www.sgn.cornell.edu
nm...@co...
On Wed, Sep 23, 2009 at 12:33 PM, Scott Cain <cai...@gm...> wrote:
> Hi Naama,
>
> To to be too much of a pain, but would this make more sense as a
> taxonomy/phylogeny module?
>
> Scott
>
>
>
> On Sep 23, 2009, at 12:21 PM, Naama Menda wrote:
>
> If nobody objects, I'm going to add these 2 tables to the Chado schema.
>> This means we'll have DBIC objects for the 2 tables in
>> Bio::Chado::Schema::Organism
>>
>>
>> CREATE TABLE organismgroup (
>> organismgroup_id serial NOT NULL PRIMARY KEY,
>> name varchar (255),
>> type varchar (32)
>> );
>>
>> CREATE TABLE organismgroup_member (
>> organismgroup_member_id serial NOT NULL PRIMARY KEY,
>> organismgroup_id integer REFERENCES organismgroup,
>> organism_id integer REFERENCES organism
>> );
>>
>>
>> thanks!
>> -Naama
>>
>>
>> On Sun, Sep 20, 2009 at 9:28 PM, Naama Menda <nm...@co...> wrote:
>>
>> How can Chado handle defining several organisms as members of a group?
>> For example creating a unigene build from several tobacco species, or
>> defining which Solanum species share the common name 'potato' (this is not
>> intuitive from the taxonomy tree) .
>>
>> I thought of adding an organismgroup table defining the group name and
>> type, and organismgroup_member linking table (organismgroup and organism)
>> Is this something other Chado users might be interested in?
>>
>> Any ideas?
>>
>> thanks,
>> -Naama
>>
>>
>> Naama Menda
>> Boyce Thompson Institute for Plant Research
>> Tower Rd
>> Ithaca NY 14853
>> USA
>>
>> (607) 254 3569
>> Sol Genomics Network
>> http://www.sgn.cornell.edu
>> nm...@co...
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
> -----------------------------------------------------------------------
> Scott Cain, Ph. D. scott at scottcain dot net
> GMOD Coordinator (http://gmod.org/) 216-392-3087
> Ontario Institute for Cancer Research
>
>
>
>
>
|
|
From: Scott C. <cai...@gm...> - 2009-09-23 16:33:17
|
Hi Naama, To to be too much of a pain, but would this make more sense as a taxonomy/phylogeny module? Scott On Sep 23, 2009, at 12:21 PM, Naama Menda wrote: > If nobody objects, I'm going to add these 2 tables to the Chado > schema. > This means we'll have DBIC objects for the 2 tables in > Bio::Chado::Schema::Organism > > > CREATE TABLE organismgroup ( > organismgroup_id serial NOT NULL PRIMARY KEY, > name varchar (255), > type varchar (32) > ); > > CREATE TABLE organismgroup_member ( > organismgroup_member_id serial NOT NULL PRIMARY KEY, > organismgroup_id integer REFERENCES organismgroup, > organism_id integer REFERENCES organism > ); > > > thanks! > -Naama > > > On Sun, Sep 20, 2009 at 9:28 PM, Naama Menda <nm...@co...> > wrote: > > How can Chado handle defining several organisms as members of a group? > For example creating a unigene build from several tobacco species, > or defining which Solanum species share the common name > 'potato' (this is not intuitive from the taxonomy tree) . > > I thought of adding an organismgroup table defining the group name > and type, and organismgroup_member linking table (organismgroup and > organism) > Is this something other Chado users might be interested in? > > Any ideas? > > thanks, > -Naama > > > Naama Menda > Boyce Thompson Institute for Plant Research > Tower Rd > Ithaca NY 14853 > USA > > (607) 254 3569 > Sol Genomics Network > http://www.sgn.cornell.edu > nm...@co... > > ------------------------------------------------------------------------------ > 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 ----------------------------------------------------------------------- Scott Cain, Ph. D. scott at scottcain dot net GMOD Coordinator (http://gmod.org/) 216-392-3087 Ontario Institute for Cancer Research |
|
From: Naama M. <nm...@co...> - 2009-09-23 16:22:17
|
If nobody objects, I'm going to add these 2 tables to the Chado schema. This means we'll have DBIC objects for the 2 tables in Bio::Chado::Schema::Organism CREATE TABLE organismgroup ( organismgroup_id serial NOT NULL PRIMARY KEY, name varchar (255), type varchar (32) ); CREATE TABLE organismgroup_member ( organismgroup_member_id serial NOT NULL PRIMARY KEY, organismgroup_id integer REFERENCES organismgroup, organism_id integer REFERENCES organism ); thanks! -Naama On Sun, Sep 20, 2009 at 9:28 PM, Naama Menda <nm...@co...> wrote: > > How can Chado handle defining several organisms as members of a group? > For example creating a unigene build from several tobacco species, or > defining which Solanum species share the common name 'potato' (this is not > intuitive from the taxonomy tree) . > > I thought of adding an organismgroup table defining the group name and > type, and organismgroup_member linking table (organismgroup and organism) > Is this something other Chado users might be interested in? > > Any ideas? > > thanks, > -Naama > > > Naama Menda > Boyce Thompson Institute for Plant Research > Tower Rd > Ithaca NY 14853 > USA > > (607) 254 3569 > Sol Genomics Network > http://www.sgn.cornell.edu > nm...@co... > |
