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
|
From: Chris M. <cj...@fr...> - 2002-11-07 02:47:33
|
Not sure if this was answered, but you'll be glad to hear we are using interbase coordinates. Yes, people will neglect to read the docs and use this wrongly but what can you do... On Fri, 1 Nov 2002, Lincoln Stein wrote: > I like the pos5 and pos3 proposal very much indeed, and would also support > using "low" "high" nomenclature for the boundaries of features. > > Has there been a discussion yet of whether to use 1-based coordinates or > interbase coordinates? I for one am strongly in favor of interbase > coordinates as Gadfly does it now. > > Lincoln > > On Wednesday 30 October 2002 09:45 pm, Scott Cain wrote: > > I am sending this to the gmod-devel list to get the opinion of the > > larger audience. > > > > I am inclined to agree with Colin about nomenclature, though I do agree > > with you about bioperl's normal/incorrect use of boundaries. Before > > bioperl came along I did it the way you propose; it caused much > > confusion when I changed my schema to correspond to the bioperl way. > > Assuming we use Chris' proposed boundary coordinates, I think using > > check constraints is a good idea. > > > > Other opinions? > > > > Scott > > > > On Wed, 2002-10-30 at 20:54, Colin Wiel wrote: > > > I preferred your suggestion of pos5 and pos3, as well as my suggestion > > > of end5 and end3. I don't think a new chado user will figure out that > > > fnbeg stands for "feature natural begin" as easily as they would figure > > > out that pos5 (or end5) is the "position of the 5' end". > > > > > > Colin > > > > > > > -----Original Message----- > > > > From: gmo...@li... [mailto:gmod-schema- > > > > ad...@li...] On Behalf Of Chris Mungall > > > > Sent: Wednesday, October 30, 2002 4:46 PM > > > > To: gmo...@li... > > > > Subject: [Gmod-schema] cvs changes: companalysis module, sequence > > > > > > module > > > > > > > I have reworked the tables in the computational analysis module; they > > > > > > are > > > > > > > now a little less generic than before. there is some docs included in > > > > > > the > > > > > > > .sql - more needed though... > > > > > > > > the multiple alignment part (eg for clustal results) is still fluid > > > > > > > > I have also settled on > > > > > > > > fnbeg > > > > fnend > > > > > > > > for specifying coordinates - feature natural begin, feature natural > > > > > > end > > > > > > > ie this is the "real" begin and end > > > > > > > > we should also possibly include a check constraint to make this > > > > > > explicit > > > > > > > eg > > > > > > > > fstrand is null OR (fnend - fnbeg) * fstrand >= 0 > > > > > > > > > > > > this is opposed to the normal (erroneous in my opinion) use of > > > > > > start/begin > > > > > > > end/stop, as used in bioperl, where > > > > > > > > start <= end > > > > > > > > ie they actually mean (low, high) > > > > > > > > how do we feel about check constraints? > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by: Influence the future > > > > of Java(TM) technology. Join the Java Community > > > > Process(SM) (JCP(SM)) program now. > > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > > > > _______________________________________________ > > > > Gmod-schema mailing list > > > > Gmo...@li... > > > > https://lists.sourceforge.net/lists/listinfo/gmod-schema > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: Influence the future > > > of Java(TM) technology. Join the Java Community > > > Process(SM) (JCP(SM)) program now. > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > > > _______________________________________________ > > > Gmod-schema mailing list > > > Gmo...@li... > > > https://lists.sourceforge.net/lists/listinfo/gmod-schema > > |
From: Scott C. <ca...@cs...> - 2002-11-04 22:11:39
|
The test data is available on GMOD's download page, at http://sourceforge.net/project/showfiles.php?group_id=27707 under the schema project. I will create a link from the schema summary page tomorrow (which is the way most people would get to it) and put much warning text about the preliminaryness (is that a word?) of the files. Thanks, Scott On Mon, 2002-11-04 at 16:54, David Emmert wrote: > Hi Scott, > > I've put the postgres dump (chado_pf.gz), ddl (chado.ddl), and some comments > (gmod_readme) in the same place I put the dump last time. > > I hope to have some sample queries ready by tomorrow morning. > > Could you let me know when this will be publicly accessable (and how) so I > can let the TIGR people at it? > > Thanks, > > -Dave > > --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- > > >From ca...@cs... Mon Nov 4 16:12 EST 2002 > Subject: Re: [Gmod-schema] Re: GMOD Schema : Chlamy > From: Scott Cain <ca...@cs...> > To: David Emmert <em...@mo...> > Cc: ch...@du..., gmo...@li... > Content-Transfer-Encoding: 7bit > Date: 04 Nov 2002 16:13:26 -0500 > Mime-Version: 1.0 > > Sounds good. Let me know when the files are ready to go. If you want > to put them in the same place that is fine; I'll move them where they > need to go. > > Thanks, > Scott > > > On Mon, 2002-11-04 at 15:20, David Emmert wrote: > > >> Actually, I was thinking about releasing it on the gmod downloads page > > >> as the 0.01 "test data" release of chado. I think having a set of test > > >> data more generally available is a good idea. It will give people > > >> something to tinker with. Objections? > > > > None, Great idea. > > > > But I think it should be stated very clearly (all uppercase!) that it is both > > test date and test *implementation* of that data in chado. Also, we should > > provide ddl used (since ddl is fluxing), and documentation pointing to the > > source data. > > > > I'll be glad to provide these three for P.falciparum today. I'll also > > throw in my loader. > > > > Oh, and I'll probably want to update the dump once or twice as I find > > bugs... > > > > Agreed? > > > > -D > > > > --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- > > > > > > > > > > >From ca...@cs... Mon Nov 4 14:57 EST 2002 > > Subject: Re: GMOD Schema : Chlamy > > From: Scott Cain <ca...@cs...> > > To: David Emmert <em...@mo...> > > Cc: ch...@du..., gmo...@li... > > Content-Transfer-Encoding: 7bit > > Date: 04 Nov 2002 14:58:09 -0500 > > Mime-Version: 1.0 > > > > Dave, > > > > Actually, I was thinking about releasing it on the gmod downloads page > > as the 0.01 "test data" release of chado. I think having a set of test > > data more generally available is a good idea. It will give people > > something to tinker with. Objections? > > > > Scott > > > > > > On Mon, 2002-11-04 at 14:28, David Emmert wrote: > > > Hi Scott, > > > > > > I spent the weekend loading the schema w/ the genome of P.falciparum, > > > would that be ok? The implementation I think is closer to what we've > > > been thinking we'll do - using interbase locations, etc. > > > > > > Charles, I think you'd be better off looking at this data rather than > > > the D.melanogaster data (though I think the D.melanogaster annotations > > > are much better!), since its closer to how we'd expect to implement > > > the schema... > > > > > > If it wouldn't be too much trouble, Scott, could I have a colleague from > > > TIGR pick up the P.falciparum dump from sourceforge real quick too before > > > you delete it? > > > > > > Best, > > > > > > -Dave > > > > > > > > > >> From ca...@cs... Sat Nov 2 12:36 EST 2002 > > > >> Subject: Re: GMOD Schema : Chlamy > > > >> From: Scott Cain <ca...@cs...> > > > >> To: David Emmert <em...@mo...> > > > >> Content-Transfer-Encoding: 7bit > > > >> Date: 02 Nov 2002 12:37:24 -0500 > > > >> Mime-Version: 1.0 > > > >> > > > >> Dave, > > > >> > > > >> Silly me! I deleted that file, and now I could use it. I am going to > > > >> try to port GBrowse to chado/postgres. Could you put it back, and I > > > >> will put it in the sourceforge downloads area as test data for chado? > > > >> > > > >> Thanks, > > > >> Scott > > > >> > > > >> > > > >> On Wed, 2002-10-30 at 12:57, David Emmert wrote: > > > >> > >> % scp <filename> em...@ww...:/home/groups/g/gm/gmod/htdocs/ > > > >> > > > > >> > Worked like a charm! > > > >> > > > > >> > The file is named idb_gb_r3. > > > >> > > > > >> > -Dave > > > >> > > > > >> > --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- > > > >> > > > > >> > >From ca...@cs... Wed Oct 30 12:07 EST 2002 > > > >> > Subject: Re: GMOD Schema : Chlamy > > > >> > From: Scott Cain <ca...@cs...> > > > >> > To: David Emmert <em...@mo...> > > > >> > Content-Transfer-Encoding: 7bit > > > >> > Date: 30 Oct 2002 12:08:09 -0500 > > > >> > Mime-Version: 1.0 > > > >> > > > > >> > Ok, I am not positive this will work, but you may be able to scp > > > >> > directly to www.gmod.org's htdocs directory: > > > >> > > > > >> > % scp <filename> em...@ww...:/home/groups/g/gm/gmod/htdocs/ > > > >> > > > > >> > It is possible that you will have write permission problems though, > > > >> > especially since as I look at /home/users/e/em I don't see your user > > > >> > account. If you do run into file permission problems, first try to ssh > > > >> > to gmod.sourceforge.net using emmert as the login. Once you have done > > > >> > that, sourceforge will create a home directory for you, and you can scp > > > >> > the file to it, and I can mv it to the htdocs dir for gmod. > > > >> > > > > >> > Now I am crossing my fingers, > > > >> > Scott > > > >> > > > > >> > > > > > > -- > > ------------------------------------------------------------------------ > > Scott Cain, Ph. D. ca...@cs... > > GMOD Coordinator (http://www.gmod.org/) 216-392-3087 > > Cold Spring Harbor Laboratory > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: ApacheCon, November 18-21 in > > Las Vegas (supported by COMDEX), the only Apache event to be > > fully supported by the ASF. http://www.apachecon.com > > _______________________________________________ > > Gmod-schema mailing list > > Gmo...@li... > > https://lists.sourceforge.net/lists/listinfo/gmod-schema > > > -- > ------------------------------------------------------------------------ > Scott Cain, Ph. D. ca...@cs... > GMOD Coordinator (http://www.gmod.org/) 216-392-3087 > Cold Spring Harbor Laboratory > > > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. ca...@cs... GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory |
From: David E. <em...@mo...> - 2002-11-04 21:52:31
|
Hi Scott, I've put the postgres dump (chado_pf.gz), ddl (chado.ddl), and some comments (gmod_readme) in the same place I put the dump last time. I hope to have some sample queries ready by tomorrow morning. Could you let me know when this will be publicly accessable (and how) so I can let the TIGR people at it? Thanks, -Dave --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- >From ca...@cs... Mon Nov 4 16:12 EST 2002 Subject: Re: [Gmod-schema] Re: GMOD Schema : Chlamy From: Scott Cain <ca...@cs...> To: David Emmert <em...@mo...> Cc: ch...@du..., gmo...@li... Content-Transfer-Encoding: 7bit Date: 04 Nov 2002 16:13:26 -0500 Mime-Version: 1.0 Sounds good. Let me know when the files are ready to go. If you want to put them in the same place that is fine; I'll move them where they need to go. Thanks, Scott On Mon, 2002-11-04 at 15:20, David Emmert wrote: > >> Actually, I was thinking about releasing it on the gmod downloads page > >> as the 0.01 "test data" release of chado. I think having a set of test > >> data more generally available is a good idea. It will give people > >> something to tinker with. Objections? > > None, Great idea. > > But I think it should be stated very clearly (all uppercase!) that it is both > test date and test *implementation* of that data in chado. Also, we should > provide ddl used (since ddl is fluxing), and documentation pointing to the > source data. > > I'll be glad to provide these three for P.falciparum today. I'll also > throw in my loader. > > Oh, and I'll probably want to update the dump once or twice as I find > bugs... > > Agreed? > > -D > > --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- > > > > > >From ca...@cs... Mon Nov 4 14:57 EST 2002 > Subject: Re: GMOD Schema : Chlamy > From: Scott Cain <ca...@cs...> > To: David Emmert <em...@mo...> > Cc: ch...@du..., gmo...@li... > Content-Transfer-Encoding: 7bit > Date: 04 Nov 2002 14:58:09 -0500 > Mime-Version: 1.0 > > Dave, > > Actually, I was thinking about releasing it on the gmod downloads page > as the 0.01 "test data" release of chado. I think having a set of test > data more generally available is a good idea. It will give people > something to tinker with. Objections? > > Scott > > > On Mon, 2002-11-04 at 14:28, David Emmert wrote: > > Hi Scott, > > > > I spent the weekend loading the schema w/ the genome of P.falciparum, > > would that be ok? The implementation I think is closer to what we've > > been thinking we'll do - using interbase locations, etc. > > > > Charles, I think you'd be better off looking at this data rather than > > the D.melanogaster data (though I think the D.melanogaster annotations > > are much better!), since its closer to how we'd expect to implement > > the schema... > > > > If it wouldn't be too much trouble, Scott, could I have a colleague from > > TIGR pick up the P.falciparum dump from sourceforge real quick too before > > you delete it? > > > > Best, > > > > -Dave > > > > > > >> From ca...@cs... Sat Nov 2 12:36 EST 2002 > > >> Subject: Re: GMOD Schema : Chlamy > > >> From: Scott Cain <ca...@cs...> > > >> To: David Emmert <em...@mo...> > > >> Content-Transfer-Encoding: 7bit > > >> Date: 02 Nov 2002 12:37:24 -0500 > > >> Mime-Version: 1.0 > > >> > > >> Dave, > > >> > > >> Silly me! I deleted that file, and now I could use it. I am going to > > >> try to port GBrowse to chado/postgres. Could you put it back, and I > > >> will put it in the sourceforge downloads area as test data for chado? > > >> > > >> Thanks, > > >> Scott > > >> > > >> > > >> On Wed, 2002-10-30 at 12:57, David Emmert wrote: > > >> > >> % scp <filename> em...@ww...:/home/groups/g/gm/gmod/htdocs/ > > >> > > > >> > Worked like a charm! > > >> > > > >> > The file is named idb_gb_r3. > > >> > > > >> > -Dave > > >> > > > >> > --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- > > >> > > > >> > >From ca...@cs... Wed Oct 30 12:07 EST 2002 > > >> > Subject: Re: GMOD Schema : Chlamy > > >> > From: Scott Cain <ca...@cs...> > > >> > To: David Emmert <em...@mo...> > > >> > Content-Transfer-Encoding: 7bit > > >> > Date: 30 Oct 2002 12:08:09 -0500 > > >> > Mime-Version: 1.0 > > >> > > > >> > Ok, I am not positive this will work, but you may be able to scp > > >> > directly to www.gmod.org's htdocs directory: > > >> > > > >> > % scp <filename> em...@ww...:/home/groups/g/gm/gmod/htdocs/ > > >> > > > >> > It is possible that you will have write permission problems though, > > >> > especially since as I look at /home/users/e/em I don't see your user > > >> > account. If you do run into file permission problems, first try to ssh > > >> > to gmod.sourceforge.net using emmert as the login. Once you have done > > >> > that, sourceforge will create a home directory for you, and you can scp > > >> > the file to it, and I can mv it to the htdocs dir for gmod. > > >> > > > >> > Now I am crossing my fingers, > > >> > Scott > > >> > > > >> > > > > -- > ------------------------------------------------------------------------ > Scott Cain, Ph. D. ca...@cs... > GMOD Coordinator (http://www.gmod.org/) 216-392-3087 > Cold Spring Harbor Laboratory > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ApacheCon, November 18-21 in > Las Vegas (supported by COMDEX), the only Apache event to be > fully supported by the ASF. http://www.apachecon.com > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-schema > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. ca...@cs... GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory |
From: Scott C. <ca...@cs...> - 2002-11-04 21:13:35
|
Sounds good. Let me know when the files are ready to go. If you want to put them in the same place that is fine; I'll move them where they need to go. Thanks, Scott On Mon, 2002-11-04 at 15:20, David Emmert wrote: > >> Actually, I was thinking about releasing it on the gmod downloads page > >> as the 0.01 "test data" release of chado. I think having a set of test > >> data more generally available is a good idea. It will give people > >> something to tinker with. Objections? > > None, Great idea. > > But I think it should be stated very clearly (all uppercase!) that it is both > test date and test *implementation* of that data in chado. Also, we should > provide ddl used (since ddl is fluxing), and documentation pointing to the > source data. > > I'll be glad to provide these three for P.falciparum today. I'll also > throw in my loader. > > Oh, and I'll probably want to update the dump once or twice as I find > bugs... > > Agreed? > > -D > > --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- > > > > > >From ca...@cs... Mon Nov 4 14:57 EST 2002 > Subject: Re: GMOD Schema : Chlamy > From: Scott Cain <ca...@cs...> > To: David Emmert <em...@mo...> > Cc: ch...@du..., gmo...@li... > Content-Transfer-Encoding: 7bit > Date: 04 Nov 2002 14:58:09 -0500 > Mime-Version: 1.0 > > Dave, > > Actually, I was thinking about releasing it on the gmod downloads page > as the 0.01 "test data" release of chado. I think having a set of test > data more generally available is a good idea. It will give people > something to tinker with. Objections? > > Scott > > > On Mon, 2002-11-04 at 14:28, David Emmert wrote: > > Hi Scott, > > > > I spent the weekend loading the schema w/ the genome of P.falciparum, > > would that be ok? The implementation I think is closer to what we've > > been thinking we'll do - using interbase locations, etc. > > > > Charles, I think you'd be better off looking at this data rather than > > the D.melanogaster data (though I think the D.melanogaster annotations > > are much better!), since its closer to how we'd expect to implement > > the schema... > > > > If it wouldn't be too much trouble, Scott, could I have a colleague from > > TIGR pick up the P.falciparum dump from sourceforge real quick too before > > you delete it? > > > > Best, > > > > -Dave > > > > > > >> From ca...@cs... Sat Nov 2 12:36 EST 2002 > > >> Subject: Re: GMOD Schema : Chlamy > > >> From: Scott Cain <ca...@cs...> > > >> To: David Emmert <em...@mo...> > > >> Content-Transfer-Encoding: 7bit > > >> Date: 02 Nov 2002 12:37:24 -0500 > > >> Mime-Version: 1.0 > > >> > > >> Dave, > > >> > > >> Silly me! I deleted that file, and now I could use it. I am going to > > >> try to port GBrowse to chado/postgres. Could you put it back, and I > > >> will put it in the sourceforge downloads area as test data for chado? > > >> > > >> Thanks, > > >> Scott > > >> > > >> > > >> On Wed, 2002-10-30 at 12:57, David Emmert wrote: > > >> > >> % scp <filename> em...@ww...:/home/groups/g/gm/gmod/htdocs/ > > >> > > > >> > Worked like a charm! > > >> > > > >> > The file is named idb_gb_r3. > > >> > > > >> > -Dave > > >> > > > >> > --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- > > >> > > > >> > >From ca...@cs... Wed Oct 30 12:07 EST 2002 > > >> > Subject: Re: GMOD Schema : Chlamy > > >> > From: Scott Cain <ca...@cs...> > > >> > To: David Emmert <em...@mo...> > > >> > Content-Transfer-Encoding: 7bit > > >> > Date: 30 Oct 2002 12:08:09 -0500 > > >> > Mime-Version: 1.0 > > >> > > > >> > Ok, I am not positive this will work, but you may be able to scp > > >> > directly to www.gmod.org's htdocs directory: > > >> > > > >> > % scp <filename> em...@ww...:/home/groups/g/gm/gmod/htdocs/ > > >> > > > >> > It is possible that you will have write permission problems though, > > >> > especially since as I look at /home/users/e/em I don't see your user > > >> > account. If you do run into file permission problems, first try to ssh > > >> > to gmod.sourceforge.net using emmert as the login. Once you have done > > >> > that, sourceforge will create a home directory for you, and you can scp > > >> > the file to it, and I can mv it to the htdocs dir for gmod. > > >> > > > >> > Now I am crossing my fingers, > > >> > Scott > > >> > > > >> > > > > -- > ------------------------------------------------------------------------ > Scott Cain, Ph. D. ca...@cs... > GMOD Coordinator (http://www.gmod.org/) 216-392-3087 > Cold Spring Harbor Laboratory > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ApacheCon, November 18-21 in > Las Vegas (supported by COMDEX), the only Apache event to be > fully supported by the ASF. http://www.apachecon.com > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-schema > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. ca...@cs... GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory |
From: David E. <em...@mo...> - 2002-11-04 20:19:11
|
>> Actually, I was thinking about releasing it on the gmod downloads page >> as the 0.01 "test data" release of chado. I think having a set of test >> data more generally available is a good idea. It will give people >> something to tinker with. Objections? None, Great idea. But I think it should be stated very clearly (all uppercase!) that it is both test date and test *implementation* of that data in chado. Also, we should provide ddl used (since ddl is fluxing), and documentation pointing to the source data. I'll be glad to provide these three for P.falciparum today. I'll also throw in my loader. Oh, and I'll probably want to update the dump once or twice as I find bugs... Agreed? -D --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- >From ca...@cs... Mon Nov 4 14:57 EST 2002 Subject: Re: GMOD Schema : Chlamy From: Scott Cain <ca...@cs...> To: David Emmert <em...@mo...> Cc: ch...@du..., gmo...@li... Content-Transfer-Encoding: 7bit Date: 04 Nov 2002 14:58:09 -0500 Mime-Version: 1.0 Dave, Actually, I was thinking about releasing it on the gmod downloads page as the 0.01 "test data" release of chado. I think having a set of test data more generally available is a good idea. It will give people something to tinker with. Objections? Scott On Mon, 2002-11-04 at 14:28, David Emmert wrote: > Hi Scott, > > I spent the weekend loading the schema w/ the genome of P.falciparum, > would that be ok? The implementation I think is closer to what we've > been thinking we'll do - using interbase locations, etc. > > Charles, I think you'd be better off looking at this data rather than > the D.melanogaster data (though I think the D.melanogaster annotations > are much better!), since its closer to how we'd expect to implement > the schema... > > If it wouldn't be too much trouble, Scott, could I have a colleague from > TIGR pick up the P.falciparum dump from sourceforge real quick too before > you delete it? > > Best, > > -Dave > > > >> From ca...@cs... Sat Nov 2 12:36 EST 2002 > >> Subject: Re: GMOD Schema : Chlamy > >> From: Scott Cain <ca...@cs...> > >> To: David Emmert <em...@mo...> > >> Content-Transfer-Encoding: 7bit > >> Date: 02 Nov 2002 12:37:24 -0500 > >> Mime-Version: 1.0 > >> > >> Dave, > >> > >> Silly me! I deleted that file, and now I could use it. I am going to > >> try to port GBrowse to chado/postgres. Could you put it back, and I > >> will put it in the sourceforge downloads area as test data for chado? > >> > >> Thanks, > >> Scott > >> > >> > >> On Wed, 2002-10-30 at 12:57, David Emmert wrote: > >> > >> % scp <filename> em...@ww...:/home/groups/g/gm/gmod/htdocs/ > >> > > >> > Worked like a charm! > >> > > >> > The file is named idb_gb_r3. > >> > > >> > -Dave > >> > > >> > --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- > >> > > >> > >From ca...@cs... Wed Oct 30 12:07 EST 2002 > >> > Subject: Re: GMOD Schema : Chlamy > >> > From: Scott Cain <ca...@cs...> > >> > To: David Emmert <em...@mo...> > >> > Content-Transfer-Encoding: 7bit > >> > Date: 30 Oct 2002 12:08:09 -0500 > >> > Mime-Version: 1.0 > >> > > >> > Ok, I am not positive this will work, but you may be able to scp > >> > directly to www.gmod.org's htdocs directory: > >> > > >> > % scp <filename> em...@ww...:/home/groups/g/gm/gmod/htdocs/ > >> > > >> > It is possible that you will have write permission problems though, > >> > especially since as I look at /home/users/e/em I don't see your user > >> > account. If you do run into file permission problems, first try to ssh > >> > to gmod.sourceforge.net using emmert as the login. Once you have done > >> > that, sourceforge will create a home directory for you, and you can scp > >> > the file to it, and I can mv it to the htdocs dir for gmod. > >> > > >> > Now I am crossing my fingers, > >> > Scott > >> > > >> > > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. ca...@cs... GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory |
From: Scott C. <ca...@cs...> - 2002-11-04 19:58:18
|
Dave, Actually, I was thinking about releasing it on the gmod downloads page as the 0.01 "test data" release of chado. I think having a set of test data more generally available is a good idea. It will give people something to tinker with. Objections? Scott On Mon, 2002-11-04 at 14:28, David Emmert wrote: > Hi Scott, > > I spent the weekend loading the schema w/ the genome of P.falciparum, > would that be ok? The implementation I think is closer to what we've > been thinking we'll do - using interbase locations, etc. > > Charles, I think you'd be better off looking at this data rather than > the D.melanogaster data (though I think the D.melanogaster annotations > are much better!), since its closer to how we'd expect to implement > the schema... > > If it wouldn't be too much trouble, Scott, could I have a colleague from > TIGR pick up the P.falciparum dump from sourceforge real quick too before > you delete it? > > Best, > > -Dave > > > >> From ca...@cs... Sat Nov 2 12:36 EST 2002 > >> Subject: Re: GMOD Schema : Chlamy > >> From: Scott Cain <ca...@cs...> > >> To: David Emmert <em...@mo...> > >> Content-Transfer-Encoding: 7bit > >> Date: 02 Nov 2002 12:37:24 -0500 > >> Mime-Version: 1.0 > >> > >> Dave, > >> > >> Silly me! I deleted that file, and now I could use it. I am going to > >> try to port GBrowse to chado/postgres. Could you put it back, and I > >> will put it in the sourceforge downloads area as test data for chado? > >> > >> Thanks, > >> Scott > >> > >> > >> On Wed, 2002-10-30 at 12:57, David Emmert wrote: > >> > >> % scp <filename> em...@ww...:/home/groups/g/gm/gmod/htdocs/ > >> > > >> > Worked like a charm! > >> > > >> > The file is named idb_gb_r3. > >> > > >> > -Dave > >> > > >> > --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- --*-- > >> > > >> > >From ca...@cs... Wed Oct 30 12:07 EST 2002 > >> > Subject: Re: GMOD Schema : Chlamy > >> > From: Scott Cain <ca...@cs...> > >> > To: David Emmert <em...@mo...> > >> > Content-Transfer-Encoding: 7bit > >> > Date: 30 Oct 2002 12:08:09 -0500 > >> > Mime-Version: 1.0 > >> > > >> > Ok, I am not positive this will work, but you may be able to scp > >> > directly to www.gmod.org's htdocs directory: > >> > > >> > % scp <filename> em...@ww...:/home/groups/g/gm/gmod/htdocs/ > >> > > >> > It is possible that you will have write permission problems though, > >> > especially since as I look at /home/users/e/em I don't see your user > >> > account. If you do run into file permission problems, first try to ssh > >> > to gmod.sourceforge.net using emmert as the login. Once you have done > >> > that, sourceforge will create a home directory for you, and you can scp > >> > the file to it, and I can mv it to the htdocs dir for gmod. > >> > > >> > Now I am crossing my fingers, > >> > Scott > >> > > >> > > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. ca...@cs... GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory |
From: Lincoln S. <ls...@cs...> - 2002-11-01 18:09:37
|
I like the pos5 and pos3 proposal very much indeed, and would also suppor= t=20 using "low" "high" nomenclature for the boundaries of features. Has there been a discussion yet of whether to use 1-based coordinates or=20 interbase coordinates? I for one am strongly in favor of interbase=20 coordinates as Gadfly does it now. Lincoln On Wednesday 30 October 2002 09:45 pm, Scott Cain wrote: > I am sending this to the gmod-devel list to get the opinion of the > larger audience. > > I am inclined to agree with Colin about nomenclature, though I do agree > with you about bioperl's normal/incorrect use of boundaries. Before > bioperl came along I did it the way you propose; it caused much > confusion when I changed my schema to correspond to the bioperl way. > Assuming we use Chris' proposed boundary coordinates, I think using > check constraints is a good idea. > > Other opinions? > > Scott > > On Wed, 2002-10-30 at 20:54, Colin Wiel wrote: > > I preferred your suggestion of pos5 and pos3, as well as my suggestio= n > > of end5 and end3. I don't think a new chado user will figure out tha= t > > fnbeg stands for "feature natural begin" as easily as they would figu= re > > out that pos5 (or end5) is the "position of the 5' end". > > > > Colin > > > > > -----Original Message----- > > > From: gmo...@li... [mailto:gmod-schema- > > > ad...@li...] On Behalf Of Chris Mungall > > > Sent: Wednesday, October 30, 2002 4:46 PM > > > To: gmo...@li... > > > Subject: [Gmod-schema] cvs changes: companalysis module, sequence > > > > module > > > > > I have reworked the tables in the computational analysis module; th= ey > > > > are > > > > > now a little less generic than before. there is some docs included = in > > > > the > > > > > .sql - more needed though... > > > > > > the multiple alignment part (eg for clustal results) is still fluid > > > > > > I have also settled on > > > > > > fnbeg > > > fnend > > > > > > for specifying coordinates - feature natural begin, feature natural > > > > end > > > > > ie this is the "real" begin and end > > > > > > we should also possibly include a check constraint to make this > > > > explicit > > > > > eg > > > > > > fstrand is null OR (fnend - fnbeg) * fstrand >=3D 0 > > > > > > > > > this is opposed to the normal (erroneous in my opinion) use of > > > > start/begin > > > > > end/stop, as used in bioperl, where > > > > > > start <=3D end > > > > > > ie they actually mean (low, high) > > > > > > how do we feel about check constraints? > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: Influence the future > > > of Java(TM) technology. Join the Java Community > > > Process(SM) (JCP(SM)) program now. > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > > > _______________________________________________ > > > Gmod-schema mailing list > > > Gmo...@li... > > > https://lists.sourceforge.net/lists/listinfo/gmod-schema > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: Influence the future > > of Java(TM) technology. Join the Java Community > > Process(SM) (JCP(SM)) program now. > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > > _______________________________________________ > > Gmod-schema mailing list > > Gmo...@li... > > https://lists.sourceforge.net/lists/listinfo/gmod-schema --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Lincoln D. Stein Cold Spring Harbor Laboratory ls...@cs...=09=09=09 Cold Spring Harbor, NY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
From: Lincoln S. <ls...@cs...> - 2002-11-01 16:57:05
|
Ignore me. I didn't realize how old this conversation was. Go ahead wit= h=20 whatever organization you decided on. Lincoln On Tuesday 22 October 2002 12:26 pm, Chris Mungall wrote: > Ok, what about this minor change: > > gmod-schema > =09chado/ > =09=09modules/ > =09=09=09sequence/ > =09=09=09=09sequence.sql > =09=09=09genetics/ > =09=09=09=09genetics.sql > =09=09docs/ > =09=09src/ > > this allows us schema-level documentation, and more specific documentat= ion > that lives at the module level; we can also include anything else at th= e > module level if we decide to - eg dtds or xml-schema that map directly > onto the relational schema > > On 22 Oct 2002, Scott Cain wrote: > > Chris, > > > > Just to be sure before I do it, here is the file structure I am going= to > > import: > > > > gmod-schema/ > > chado/ > > sql/ > > sequence/ > > genetics/ > > expression/ > > etc.. > > doc/ > > diagrams/ > > > > BTW, why chado ("the way of tea"?)? > > > > Scott > > > > On Mon, 2002-10-21 at 15:19, Chris Mungall wrote: > > > Have we decided on the directory organisation yet? > > > > > > As I see it we have a collection of files categorised along the > > > following axes: > > > > > > module (sequence, genetics, etc) > > > > > > schema instance ("chado" is I think the name we have finalised on).= I > > > am still thinking in terms of gmod-schema being a collection of > > > complementary but possibly redundant schemas; perhaps others would > > > prefer to think in terms of one single gmod-schema? > > > > > > file-type; eg DDL as SQL statements, documentation (html, text, > > > images, other), xml schema translation of the relational schema, > > > adapter code, etc > > > > > > These could be arranged in a directory structure in the following w= ays: > > > > > > (1) (SCHEMA-TYPE-MODULE) > > > > > > gmod-schema/ > > > =09chado/ > > > =09=09sql/ > > > =09=09=09sequence/ > > > =09=09=09genetics/ > > > =09=09=09expression/ > > > > > > this way doesn't force chado's modular divisions on the rest of > > > gmod-schema > > > > > > (2) (MODULE-SCHEMA-TYPE) > > > > > > gmod-schema/ > > > =09sequence/ > > > =09=09chado/ > > > =09=09=09sql/ > > > =09=09=09=09sequence.sql > > > =09=09bio-db-gff/ > > > =09=09=09bio-db-gff.sql > > > =09genetics/ > > > =09=09chado/ > > > =09=09=09genetics.sql > > > > > > this enforces the divisions Dave and I decided upon on the rest of > > > gmod-schema; maybe not ideal, for instance, there is an argument fo= r > > > further subdividing what Dave and I call 'genetics' into 'phenotype= '. > > > on the other hand, it is properly modularised > > > > > > (3) (MODULE-TYPE) > > > > > > gmod-schema/ > > > =09sequence/ > > > =09=09sql/ > > > =09=09=09sequence.sql > > > =09=09docs/ > > > =09=09=09sequence.txt > > > =09=09=09coordinate-system.txt > > > > > > this is if we decide there is only one core gmod-schema (obviously > > > still allowing databases such as bio-db-gff in project specific > > > repositories). > > > > > > I'm happy with any, just making sure we're all on the same page. If > > > pressed I'd vote for > > > SCHEMA/MODULE/TYPE or SCHEMA/TYPE/MODULE > > > > > > but then if nothing else other than 'chado' is going to live here t= hen > > > we have an extra annoying pointless directory. > > > > > > On 21 Oct 2002, Scott Cain wrote: > > > > Chris, > > > > > > > > While I was preparing to create a sourceforge GMOD cvs repository= for > > > > the modular schema, I came across this page: > > > > > > > > http://sourceforge.net/docman/display_doc.php?docid=3D768&group_i= d=3D1 > > > > > > > > About half way down the page is a section "Import of Existing CVS > > > > Repositories," which details how to get files that are under curr= ent > > > > CVS control into the sourceforge CVS control. Since you already = have > > > > these files under CVS control, do you want to move them directly = to > > > > sourceforge (and thus maintain their revision history), or just > > > > import what have and lose the history? If you make the tarball as > > > > directed, you can send it to me and I will deal with sourceforge > > > > support. > > > > > > > > Thanks, > > > > Scott > > > > > > > > On Fri, 2002-10-18 at 15:25, Chris Mungall wrote: > > > > > On 18 Oct 2002, Scott Cain wrote: > > > > > > Dave, > > > > > > > > > > > > We should definitely get this stuff under cvs control. I was > > > > > > thinking of a module named schema with doc, src and image > > > > > > subdirectories to hold the information that is in the three t= ar > > > > > > balls that are currently on the website. If nobody has any > > > > > > objections, that's what I'll do. > > > > > > > > > > That would be great, thanks. > > > > > > > > > > (it is under cvs at the moment, but just in a flat scratch spac= e, > > > > > the sooner we get it a real home the better) > > > > > > > > > > just to be pernickity - > > > > > > > > > > i expect code to live under src/ - i'd make it sql/ > > > > > > > > > > shall we just stick the images under doc/ > > > > > > > > > > should we have the doc directory mirror the modular structure o= f > > > > > the sql directory, or should we just have module-specific docs > > > > > > > > > > the way we have it now is > > > > > > > > > > /sql > > > > > sequence/ > > > > > sequence.sql > > > > > use-cases/ > > > > > > > > > > and so on > > > > > > > > > > sorry to be a bore about these things but it's important to get= a > > > > > cvs dir set up right as it's a pain to change the structure onc= e > > > > > it's underway! > > > > > > > > > > > About the phone meeting, I'll answer for Lincoln, so that you= can > > > > > > get an answer before you go home today. Lincoln is teaching = a > > > > > > course this week and next, so his time during the day is rath= er > > > > > > limited. I don't know about is plans for the week after, but > > > > > > perhaps that is when we should shoot for. > > > > > > > > > > > > Scott > > > > > > > > > > > > On Fri, 2002-10-18 at 11:34, David Emmert wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > First of all, Scott, I had a look at the Modular Schema inf= o > > > > > > > you put on http://www.gmod.org, and it looks great - many > > > > > > > thanks. I wonder if you have any ideas as to how we can go > > > > > > > about improving whats there and making sure it is current.= =20 > > > > > > > Should we be thinking about putting the Modular Schema into= the > > > > > > > sourceforge CVS now, and if so, how organized? > > > > > > > > > > > > > > Thanks also for setting up the schema mailing list. > > > > > > > > > > > > > > I wanted to let you all know that I've successfully loaded = all > > > > > > > of the D.melanogaster "release 3" genome annotation GenBank > > > > > > > records into the schema, and the sequence module seems to h= ave > > > > > > > worked beautifully. I finished the loader just last night = so I > > > > > > > havn't completely evaluated the results, but the annotation= s > > > > > > > I've looked at look good. > > > > > > > > > > > > > > There's at least one gene model annotation which *didn't* l= oad > > > > > > > properly, mod(mdg4), which is a nasty case of trans splicin= g > > > > > > > who's "join" locations my location parser definitely did no= t > > > > > > > appreciate. Here's what one of the mod(mdg4) GB mRNA featu= res > > > > > > > looks like: > > > > > > > > > > > > > > mRNA join(138523..138735,138795..139263, > > > > > > > =20 > > > > > > > complement(154413..154524),complement(153944..154201), > > > > > > > complement(153727..153866),complement(152185..153037)) > > > > > > > /product=3D"CG32491-PZ" > > > > > > > /note=3D"trans splicing" > > > > > > > > > > > > > > Parser go bung! > > > > > > > > > > > > > > I'm sure this case is workable in the schema, and I'll work= on > > > > > > > parsing locations of this ilk as soon as I get a chance. > > > > > > > > > > > > > > Lincoln, I focused on this instead of the WormBase data bec= ause > > > > > > > in the context of our local (FlyBase) development, and lear= ning > > > > > > > how to layer-on the genetic/phenotypic data, we really need= ed > > > > > > > to get a test-bed to work with, and it looks like a proper = port > > > > > > > of Berkeley's gadfly data is going to take some time coming= =2E > > > > > > > > > > > > > > I'll take a look at the WormBase GFF and .ace data now. > > > > > > > > > > > > > > In the meantime, if any of you would like a postgres dump o= f > > > > > > > this data to play with, please let me know. Please, every= one, > > > > > > > be aware that the current D.melanogaster "release 3" genome > > > > > > > annotation data in GenBank imperfect, and these imperfectio= ns > > > > > > > (only, I hope) are obviously going to be in this test data. > > > > > > > > > > > > > > Once I've convinced myself I've implemented this properly, = I > > > > > > > want to start writing some practical documents on implement= ing > > > > > > > data in the sequence module. Scott, others, if you have a= ny > > > > > > > opinions on format or content this should have, please let = me > > > > > > > know. > > > > > > > > > > > > > > If I get a chance, I'm going to try to get Gbrowse up and > > > > > > > running on this data, as I'm very anxious to know how the > > > > > > > Modular Schema and Gbrowse play together. I have no idea = how > > > > > > > easy or difficult this will be, being totally unfamiliar wi= th > > > > > > > Gbrowse; if anybody wants to give advice or lend a hand, > > > > > > > please do! > > > > > > > > > > > > > > Finally, Lincoln mentioned we set up further conference cal= ls, > > > > > > > and I'd like to suggest we shoot for next Wednesday, 22 Oct= , > > > > > > > 3pm EST - same time as last time. Would that work for > > > > > > > everybody? > > > > > > > > > > > > > > I'll be out of town on Monday or Tuesday, but checking mail= off > > > > > > > and on, so apologies in advance if my replies are slow in > > > > > > > coming. > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > -Dave > > > > > > > > > > > > > > >> From ls...@pe... Thu Oct 10 12:56 EDT 2002 > > > > > > > >> From: Lincoln Stein <ls...@cs...> > > > > > > > >> To: wa...@cs..., kc...@cs... > > > > > > > >> Subject: Action points from yesterday's conversation on = the > > > > > > > >> modular schema Date: Thu, 10 Oct 2002 12:57:32 -0400 > > > > > > > >> User-Agent: KMail/1.4.3 > > > > > > > >> Cc: Chris Mungall <cj...@fr...>, David Emmert > > > > > > > >> <em...@mo...>, Scott Cain <ca...@cs...> > > > > > > > >> MIME-Version: 1.0 > > > > > > > >> Content-Transfer-Encoding: 8bit > > > > > > > >> X-MIME-Autoconverted: from quoted-printable to 8bit by > > > > > > > >> morgan.harvard.edu id MAA10948 > > > > > > > >> > > > > > > > >> Hi All, > > > > > > > >> > > > > > > > >> I thought our conversation yesterday about the modular > > > > > > > >> schema was very productive, and I look forward to David > > > > > > > >> setting up a schedule for further talks. Just a summary= of > > > > > > > >> the action points that we ended on: > > > > > > > >> > > > > > > > >> Because ideally the modular schema should support the > > > > > > > >> application modules that we've already contributed to gm= od, > > > > > > > >> we're going to put together test sets for David and Chri= s to > > > > > > > >> work with. > > > > > > > >> > > > > > > > >> 1) Lincoln to provide sequence feature data from WormBas= e in > > > > > > > >> GFF and .ace format > > > > > > > >> 2) Ken & Doreen to provide genetic map and correspondenc= e > > > > > > > >> data in the form of relational database table dumps > > > > > > > >> 3) Doreen to provide curated mutants/phenotypes/alleles = in > > > > > > > >> some form (to be determined) > > > > > > > >> 4) Scott to set up mailing list on gmod site to help > > > > > > > >> coordinate this. > > > > > > > >> > > > > > > > >> The data sets will be submitted via e-mail to David. I = will > > > > > > > >> do this by putting a data set on an FTP site and sending= the > > > > > > > >> URL to David. > > > > > > > >> > > > > > > > >> Lincoln > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > This sf.net email is sponsored by:ThinkGeek > > > > > > > Welcome to geek heaven. > > > > > > > http://thinkgeek.com/sf > > > > > > > _______________________________________________ > > > > > > > Gmod-schema mailing list > > > > > > > Gmo...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/gmod-schema --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Lincoln D. Stein Cold Spring Harbor Laboratory ls...@cs...=09=09=09 Cold Spring Harbor, NY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
From: Lincoln S. <ls...@cs...> - 2002-11-01 16:55:56
|
I kinda' like (2), but it splits each schema up. Can we guarantee that a= ll=20 schemas will play nicely with each other? Should there be a meta-schema = that=20 we use to integrate them? Lincoln On Monday 21 October 2002 03:19 pm, Chris Mungall wrote: > Have we decided on the directory organisation yet? > > As I see it we have a collection of files categorised along the followi= ng > axes: > > module (sequence, genetics, etc) > > schema instance ("chado" is I think the name we have finalised on). I a= m > still thinking in terms of gmod-schema being a collection of complement= ary > but possibly redundant schemas; perhaps others would prefer to think in > terms of one single gmod-schema? > > file-type; eg DDL as SQL statements, documentation (html, text, > images, other), xml schema translation of the relational schema, adapte= r > code, etc > > These could be arranged in a directory structure in the following ways: > > (1) (SCHEMA-TYPE-MODULE) > > gmod-schema/ > =09chado/ > =09=09sql/ > =09=09=09sequence/ > =09=09=09genetics/ > =09=09=09expression/ > > this way doesn't force chado's modular divisions on the rest of > gmod-schema > > (2) (MODULE-SCHEMA-TYPE) > > gmod-schema/ > =09sequence/ > =09=09chado/ > =09=09=09sql/ > =09=09=09=09sequence.sql > =09=09bio-db-gff/ > =09=09=09bio-db-gff.sql > =09genetics/ > =09=09chado/ > =09=09=09genetics.sql > > this enforces the divisions Dave and I decided upon on the rest of > gmod-schema; maybe not ideal, for instance, there is an argument for > further subdividing what Dave and I call 'genetics' into 'phenotype'. o= n > the other hand, it is properly modularised > > (3) (MODULE-TYPE) > > gmod-schema/ > =09sequence/ > =09=09sql/ > =09=09=09sequence.sql > =09=09docs/ > =09=09=09sequence.txt > =09=09=09coordinate-system.txt > > this is if we decide there is only one core gmod-schema (obviously stil= l > allowing databases such as bio-db-gff in project specific repositories)= =2E > > I'm happy with any, just making sure we're all on the same page. If > pressed I'd vote for > SCHEMA/MODULE/TYPE or SCHEMA/TYPE/MODULE > > but then if nothing else other than 'chado' is going to live here then = we > have an extra annoying pointless directory. > > On 21 Oct 2002, Scott Cain wrote: > > Chris, > > > > While I was preparing to create a sourceforge GMOD cvs repository for > > the modular schema, I came across this page: > > > > http://sourceforge.net/docman/display_doc.php?docid=3D768&group_id=3D= 1 > > > > About half way down the page is a section "Import of Existing CVS > > Repositories," which details how to get files that are under current = CVS > > control into the sourceforge CVS control. Since you already have the= se > > files under CVS control, do you want to move them directly to > > sourceforge (and thus maintain their revision history), or just impor= t > > what have and lose the history? If you make the tarball as directed, = you > > can send it to me and I will deal with sourceforge support. > > > > Thanks, > > Scott > > > > On Fri, 2002-10-18 at 15:25, Chris Mungall wrote: > > > On 18 Oct 2002, Scott Cain wrote: > > > > Dave, > > > > > > > > We should definitely get this stuff under cvs control. I was > > > > thinking of a module named schema with doc, src and image > > > > subdirectories to hold the information that is in the three tar b= alls > > > > that are currently on the website. If nobody has any objections, > > > > that's what I'll do. > > > > > > That would be great, thanks. > > > > > > (it is under cvs at the moment, but just in a flat scratch space, t= he > > > sooner we get it a real home the better) > > > > > > just to be pernickity - > > > > > > i expect code to live under src/ - i'd make it sql/ > > > > > > shall we just stick the images under doc/ > > > > > > should we have the doc directory mirror the modular structure of th= e > > > sql directory, or should we just have module-specific docs > > > > > > the way we have it now is > > > > > > /sql > > > sequence/ > > > sequence.sql > > > use-cases/ > > > > > > and so on > > > > > > sorry to be a bore about these things but it's important to get a c= vs > > > dir set up right as it's a pain to change the structure once it's > > > underway! > > > > > > > About the phone meeting, I'll answer for Lincoln, so that you can= get > > > > an answer before you go home today. Lincoln is teaching a course > > > > this week and next, so his time during the day is rather limited.= I > > > > don't know about is plans for the week after, but perhaps that is > > > > when we should shoot for. > > > > > > > > Scott > > > > > > > > On Fri, 2002-10-18 at 11:34, David Emmert wrote: > > > > > Hi all, > > > > > > > > > > First of all, Scott, I had a look at the Modular Schema info yo= u > > > > > put on http://www.gmod.org, and it looks great - many thanks. = I > > > > > wonder if you have any ideas as to how we can go about improvin= g > > > > > whats there and making sure it is current. Should we be think= ing > > > > > about putting the Modular Schema into the sourceforge CVS now, = and > > > > > if so, how organized? > > > > > > > > > > Thanks also for setting up the schema mailing list. > > > > > > > > > > I wanted to let you all know that I've successfully loaded all = of > > > > > the D.melanogaster "release 3" genome annotation GenBank record= s > > > > > into the schema, and the sequence module seems to have worked > > > > > beautifully. I finished the loader just last night so I havn't > > > > > completely evaluated the results, but the annotations I've look= ed > > > > > at look good. > > > > > > > > > > There's at least one gene model annotation which *didn't* load > > > > > properly, mod(mdg4), which is a nasty case of trans splicing wh= o's > > > > > "join" locations my location parser definitely did not apprecia= te.=20 > > > > > Here's what one of the mod(mdg4) GB mRNA features looks like: > > > > > > > > > > mRNA join(138523..138735,138795..139263, > > > > > =20 > > > > > complement(154413..154524),complement(153944..154201), > > > > > complement(153727..153866),complement(152185..153037)) > > > > > /product=3D"CG32491-PZ" > > > > > /note=3D"trans splicing" > > > > > > > > > > Parser go bung! > > > > > > > > > > I'm sure this case is workable in the schema, and I'll work on > > > > > parsing locations of this ilk as soon as I get a chance. > > > > > > > > > > Lincoln, I focused on this instead of the WormBase data because= in > > > > > the context of our local (FlyBase) development, and learning ho= w to > > > > > layer-on the genetic/phenotypic data, we really needed to get a > > > > > test-bed to work with, and it looks like a proper port of > > > > > Berkeley's gadfly data is going to take some time coming. > > > > > > > > > > I'll take a look at the WormBase GFF and .ace data now. > > > > > > > > > > In the meantime, if any of you would like a postgres dump of th= is > > > > > data to play with, please let me know. Please, everyone, be a= ware > > > > > that the current D.melanogaster "release 3" genome annotation d= ata > > > > > in GenBank imperfect, and these imperfections (only, I hope) ar= e > > > > > obviously going to be in this test data. > > > > > > > > > > Once I've convinced myself I've implemented this properly, I wa= nt > > > > > to start writing some practical documents on implementing data = in > > > > > the sequence module. Scott, others, if you have any opinions = on > > > > > format or content this should have, please let me know. > > > > > > > > > > If I get a chance, I'm going to try to get Gbrowse up and runni= ng > > > > > on this data, as I'm very anxious to know how the Modular Schem= a > > > > > and Gbrowse play together. I have no idea how easy or difficu= lt > > > > > this will be, being totally unfamiliar with Gbrowse; if anybod= y > > > > > wants to give advice or lend a hand, please do! > > > > > > > > > > Finally, Lincoln mentioned we set up further conference calls, = and > > > > > I'd like to suggest we shoot for next Wednesday, 22 Oct, 3pm ES= T - > > > > > same time as last time. Would that work for everybody? > > > > > > > > > > I'll be out of town on Monday or Tuesday, but checking mail off= and > > > > > on, so apologies in advance if my replies are slow in coming. > > > > > > > > > > Best, > > > > > > > > > > -Dave > > > > > > > > > > >> From ls...@pe... Thu Oct 10 12:56 EDT 2002 > > > > > >> From: Lincoln Stein <ls...@cs...> > > > > > >> To: wa...@cs..., kc...@cs... > > > > > >> Subject: Action points from yesterday's conversation on the > > > > > >> modular schema Date: Thu, 10 Oct 2002 12:57:32 -0400 > > > > > >> User-Agent: KMail/1.4.3 > > > > > >> Cc: Chris Mungall <cj...@fr...>, David Emmert > > > > > >> <em...@mo...>, Scott Cain <ca...@cs...> > > > > > >> MIME-Version: 1.0 > > > > > >> Content-Transfer-Encoding: 8bit > > > > > >> X-MIME-Autoconverted: from quoted-printable to 8bit by > > > > > >> morgan.harvard.edu id MAA10948 > > > > > >> > > > > > >> Hi All, > > > > > >> > > > > > >> I thought our conversation yesterday about the modular schem= a > > > > > >> was very productive, and I look forward to David setting up = a > > > > > >> schedule for further talks. Just a summary of the action po= ints > > > > > >> that we ended on: > > > > > >> > > > > > >> Because ideally the modular schema should support the > > > > > >> application modules that we've already contributed to gmod, > > > > > >> we're going to put together test sets for David and Chris to > > > > > >> work with. > > > > > >> > > > > > >> 1) Lincoln to provide sequence feature data from WormBase in= GFF > > > > > >> and .ace format > > > > > >> 2) Ken & Doreen to provide genetic map and correspondence da= ta > > > > > >> in the form of relational database table dumps > > > > > >> 3) Doreen to provide curated mutants/phenotypes/alleles in s= ome > > > > > >> form (to be determined) > > > > > >> 4) Scott to set up mailing list on gmod site to help coordin= ate > > > > > >> this. > > > > > >> > > > > > >> The data sets will be submitted via e-mail to David. I will= do > > > > > >> this by putting a data set on an FTP site and sending the UR= L to > > > > > >> David. > > > > > >> > > > > > >> Lincoln > > > > > > > > > > ------------------------------------------------------- > > > > > This sf.net email is sponsored by:ThinkGeek > > > > > Welcome to geek heaven. > > > > > http://thinkgeek.com/sf > > > > > _______________________________________________ > > > > > Gmod-schema mailing list > > > > > Gmo...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/gmod-schema --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Lincoln D. Stein Cold Spring Harbor Laboratory ls...@cs...=09=09=09 Cold Spring Harbor, NY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
From: Lincoln S. <ls...@cs...> - 2002-11-01 16:53:57
|
If you are using interbase coordinates, then there is no reason to have a= =20 Bioperl-style strand field, is there? This is because interbase coordina= tes=20 unambiguously specify the strand even when there's only one base pair in=20 question: =090 1 2 3 =09 g a t If we're speaking of the "a" on the forward strand, the interbase=20 representation is [1,2], whereas if we're speaking of its complement on t= he=20 reverse strand, the representation is [2,1] Strand can be calculated as: pos5 > pos3 ? 1 : -1; You will, however, need a boolean field that indicates whether the featur= e is=20 single-stranded (strand -1 or +1) or double-stranded (strand 0). Lincoln =09 On Thursday 31 October 2002 01:53 pm, Chris Mungall wrote: > On Wed, 30 Oct 2002, Hilmar Lapp wrote: > > My $0.02 on this is that I have seen unintuitive and cryptic column > > names causing as much grief as unintuitive and cryptic API method > > names. Intuitive and consistent naming is IMHO a much neglected art, > > but its lack is one of the most annoying (because avoidable) > > barriers to any piece of API or schema. > > > > At first glance, neither pos5 nor fnbeg mean much to me. If you mean > > 5' position, why not say pos_5prime and pos_3prime? > > > > As for start/end being right or wrong in bioperl, my take on this is > > that it depends on your viewpoint and there's no silver bullet that > > kills every bird. If your viewpoint is biological, then a feature > > starts at its 5' end. If your viewpoint is a 1-dimensional axis, > > then it is useful to define that end cannot be smaller than start, > > and strand is the tool to map to the biological viewpoint. Bioperl > > takes the latter viewpoint, which may be good for some and bad for > > others. There's Bio::Coordinate that lets you potentially map > > between any two systems. I have to say that some people here have > > discovered the bioperl way of defining feature boundaries > > independently of bioperl as the most useful one for storing and > > searching genome mappings. To me it seems they've all got their > > downsides and upsides, and one just needs to settle on one and be > > consistent throughout. > > i meant the naming is wrong, not necessarily the semantics > > there is two choices of semantics for the two columns > > either > > [1] X <=3D Y > > or > > [2] (Y - X) * strand >=3D 0 > > (both assuming interbase coordintes) > > there is no absolute correct choice of what semantics to use - like you > say, both have their up and downsides. (there is actually another choic= e, > using offset+length, but i personally don't like this) > > however, start/end are obviously terrible, awful, confusing choices of > attribute *name* for semantics [1], whether you speak biology or vector > math or english. there is no debate on this one, sorry. > > we had already made the choice to go with semantics [2] for chado (so > fmin/fmax as column names is not an option). my opinion is this is > generally a more useful semantics. eg getting upstream regions. a lot m= ore > is expressible as simple arithmetic statements without restorting to ug= ly > if/then/case constructs. > > given semantics 2 we were deciding on the names for X and Y. I think as > Dave says having 5 and 3 in the column name is out. I do think it's ok = to > indicate a mathematical notation of directionality - even though protei= n > features have strands, protein locations are still equivalent to 1-d > vectors with directionality. > > you make a good point about cryptic names. i guess i tend towards short= er > names. however, if you come across the name "fnbeg" and say "what's tha= t?" > and are forced to the read the documentation then this is a very good > thing, as you then learn the semantics - both that these are interbase = and > directional. whereas a cosy familiar name will most likely lead people = to > assume they know the semantics and then mess up. this is what happens t= o > people learning bioperl all the time. i'm being disingenuous, i know. i > guess at the end of the day longer names are better. but then we have t= o > be consistent within chado.... > > i'm glad i'm not the only one this pedantic about the naming of these > things. (I don;t think the sementics issue is at all pedantinc - where > possible these things should have a precise computational definition) > > > =09-hilmar > > > > On Wednesday, October 30, 2002, at 06:45 PM, Scott Cain wrote: > > > I am sending this to the gmod-devel list to get the opinion of the > > > larger audience. > > > > > > I am inclined to agree with Colin about nomenclature, though I do a= gree > > > with you about bioperl's normal/incorrect use of boundaries. Befor= e > > > bioperl came along I did it the way you propose; it caused much > > > confusion when I changed my schema to correspond to the bioperl way= =2E > > > Assuming we use Chris' proposed boundary coordinates, I think using > > > check constraints is a good idea. > > > > > > Other opinions? > > > > > > Scott > > > > > > On Wed, 2002-10-30 at 20:54, Colin Wiel wrote: > > >> I preferred your suggestion of pos5 and pos3, as well as my sugges= tion > > >> of end5 and end3. I don't think a new chado user will figure out = that > > >> fnbeg stands for "feature natural begin" as easily as they would > > >> figure > > >> out that pos5 (or end5) is the "position of the 5' end". > > >> > > >> Colin > > >> > > >>> -----Original Message----- > > >>> From: gmo...@li... [mailto:gmod-schema= - > > >>> ad...@li...] On Behalf Of Chris Mungall > > >>> Sent: Wednesday, October 30, 2002 4:46 PM > > >>> To: gmo...@li... > > >>> Subject: [Gmod-schema] cvs changes: companalysis module, sequence > > >> > > >> module > > >> > > >>> I have reworked the tables in the computational analysis module; = they > > >> > > >> are > > >> > > >>> now a little less generic than before. there is some docs include= d in > > >> > > >> the > > >> > > >>> .sql - more needed though... > > >>> > > >>> the multiple alignment part (eg for clustal results) is still flu= id > > >>> > > >>> I have also settled on > > >>> > > >>> fnbeg > > >>> fnend > > >>> > > >>> for specifying coordinates - feature natural begin, feature natur= al > > >> > > >> end > > >> > > >>> ie this is the "real" begin and end > > >>> > > >>> we should also possibly include a check constraint to make this > > >> > > >> explicit > > >> > > >>> eg > > >>> > > >>> fstrand is null OR (fnend - fnbeg) * fstrand >=3D 0 > > >>> > > >>> > > >>> this is opposed to the normal (erroneous in my opinion) use of > > >> > > >> start/begin > > >> > > >>> end/stop, as used in bioperl, where > > >>> > > >>> start <=3D end > > >>> > > >>> ie they actually mean (low, high) > > >>> > > >>> how do we feel about check constraints? > > >>> > > >>> > > >>> > > >>> ------------------------------------------------------- > > >>> This sf.net email is sponsored by: Influence the future > > >>> of Java(TM) technology. Join the Java Community > > >>> Process(SM) (JCP(SM)) program now. > > >>> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > > >>> _______________________________________________ > > >>> Gmod-schema mailing list > > >>> Gmo...@li... > > >>> https://lists.sourceforge.net/lists/listinfo/gmod-schema > > >> > > >> ------------------------------------------------------- > > >> This sf.net email is sponsored by: Influence the future > > >> of Java(TM) technology. Join the Java Community > > >> Process(SM) (JCP(SM)) program now. > > >> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > > >> _______________________________________________ > > >> Gmod-schema mailing list > > >> Gmo...@li... > > >> https://lists.sourceforge.net/lists/listinfo/gmod-schema > > > > > > -- > > > -------------------------------------------------------------------= ---- > > >- Scott Cain, Ph. D. > > > ca...@cs... > > > GMOD Coordinator (http://www.gmod.org/) > > > 216-392-3087 > > > Cold Spring Harbor Laboratory > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: Influence the future > > > of Java(TM) technology. Join the Java Community > > > Process(SM) (JCP(SM)) program now. > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > > > _______________________________________________ > > > Gmod-schema mailing list > > > Gmo...@li... > > > https://lists.sourceforge.net/lists/listinfo/gmod-schema > > > > -- > > ------------------------------------------------------------- > > Hilmar Lapp email: lapp at gnf.org > > GNF, San Diego, Ca. 92121 phone: +1-858-812-1757 > > ------------------------------------------------------------- > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > _______________________________________________ > Gmod-devel mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-devel --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Lincoln D. Stein Cold Spring Harbor Laboratory ls...@cs...=09=09=09 Cold Spring Harbor, NY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
From: Lincoln S. <ls...@cs...> - 2002-11-01 16:48:12
|
pos_5prime and pos_3prime is OK with me too. =20 I have no dispute with Bioperl's representation of coordinates as two=20 positions and a strand, but the words "start" and "end" have always annoy= ed=20 me because they imply a temporal ordering when what is meant is a physica= l=20 ordering. "low" and "high" would have been better choices. Possibly eve= n=20 "left" and "right", but some people might read that as implying time. Lincoln On Wednesday 30 October 2002 10:25 pm, Hilmar Lapp wrote: > My $0.02 on this is that I have seen unintuitive and cryptic column > names causing as much grief as unintuitive and cryptic API method > names. Intuitive and consistent naming is IMHO a much neglected art, > but its lack is one of the most annoying (because avoidable) > barriers to any piece of API or schema. > > At first glance, neither pos5 nor fnbeg mean much to me. If you mean > 5' position, why not say pos_5prime and pos_3prime? > > As for start/end being right or wrong in bioperl, my take on this is > that it depends on your viewpoint and there's no silver bullet that > kills every bird. If your viewpoint is biological, then a feature > starts at its 5' end. If your viewpoint is a 1-dimensional axis, > then it is useful to define that end cannot be smaller than start, > and strand is the tool to map to the biological viewpoint. Bioperl > takes the latter viewpoint, which may be good for some and bad for > others. There's Bio::Coordinate that lets you potentially map > between any two systems. I have to say that some people here have > discovered the bioperl way of defining feature boundaries > independently of bioperl as the most useful one for storing and > searching genome mappings. To me it seems they've all got their > downsides and upsides, and one just needs to settle on one and be > consistent throughout. > > =09-hilmar > > On Wednesday, October 30, 2002, at 06:45 PM, Scott Cain wrote: > > I am sending this to the gmod-devel list to get the opinion of the > > larger audience. > > > > I am inclined to agree with Colin about nomenclature, though I do agr= ee > > with you about bioperl's normal/incorrect use of boundaries. Before > > bioperl came along I did it the way you propose; it caused much > > confusion when I changed my schema to correspond to the bioperl way. > > Assuming we use Chris' proposed boundary coordinates, I think using > > check constraints is a good idea. > > > > Other opinions? > > > > Scott > > > > On Wed, 2002-10-30 at 20:54, Colin Wiel wrote: > >> I preferred your suggestion of pos5 and pos3, as well as my suggesti= on > >> of end5 and end3. I don't think a new chado user will figure out th= at > >> fnbeg stands for "feature natural begin" as easily as they would > >> figure > >> out that pos5 (or end5) is the "position of the 5' end". > >> > >> Colin > >> > >>> -----Original Message----- > >>> From: gmo...@li... [mailto:gmod-schema- > >>> ad...@li...] On Behalf Of Chris Mungall > >>> Sent: Wednesday, October 30, 2002 4:46 PM > >>> To: gmo...@li... > >>> Subject: [Gmod-schema] cvs changes: companalysis module, sequence > >> > >> module > >> > >>> I have reworked the tables in the computational analysis module; th= ey > >> > >> are > >> > >>> now a little less generic than before. there is some docs included = in > >> > >> the > >> > >>> .sql - more needed though... > >>> > >>> the multiple alignment part (eg for clustal results) is still fluid > >>> > >>> I have also settled on > >>> > >>> fnbeg > >>> fnend > >>> > >>> for specifying coordinates - feature natural begin, feature natural > >> > >> end > >> > >>> ie this is the "real" begin and end > >>> > >>> we should also possibly include a check constraint to make this > >> > >> explicit > >> > >>> eg > >>> > >>> fstrand is null OR (fnend - fnbeg) * fstrand >=3D 0 > >>> > >>> > >>> this is opposed to the normal (erroneous in my opinion) use of > >> > >> start/begin > >> > >>> end/stop, as used in bioperl, where > >>> > >>> start <=3D end > >>> > >>> ie they actually mean (low, high) > >>> > >>> how do we feel about check constraints? > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> This sf.net email is sponsored by: Influence the future > >>> of Java(TM) technology. Join the Java Community > >>> Process(SM) (JCP(SM)) program now. > >>> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > >>> _______________________________________________ > >>> Gmod-schema mailing list > >>> Gmo...@li... > >>> https://lists.sourceforge.net/lists/listinfo/gmod-schema > >> > >> ------------------------------------------------------- > >> This sf.net email is sponsored by: Influence the future > >> of Java(TM) technology. Join the Java Community > >> Process(SM) (JCP(SM)) program now. > >> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > >> _______________________________________________ > >> Gmod-schema mailing list > >> Gmo...@li... > >> https://lists.sourceforge.net/lists/listinfo/gmod-schema > > > > -- > > ---------------------------------------------------------------------= --- > > Scott Cain, Ph. D. > > ca...@cs... > > GMOD Coordinator (http://www.gmod.org/) > > 216-392-3087 > > Cold Spring Harbor Laboratory > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: Influence the future > > of Java(TM) technology. Join the Java Community > > Process(SM) (JCP(SM)) program now. > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > > _______________________________________________ > > Gmod-schema mailing list > > Gmo...@li... > > https://lists.sourceforge.net/lists/listinfo/gmod-schema --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Lincoln D. Stein Cold Spring Harbor Laboratory ls...@cs...=09=09=09 Cold Spring Harbor, NY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
From: Chris M. <cj...@fr...> - 2002-10-31 18:54:01
|
On Wed, 30 Oct 2002, Hilmar Lapp wrote: > My $0.02 on this is that I have seen unintuitive and cryptic column > names causing as much grief as unintuitive and cryptic API method > names. Intuitive and consistent naming is IMHO a much neglected art, > but its lack is one of the most annoying (because avoidable) > barriers to any piece of API or schema. > > At first glance, neither pos5 nor fnbeg mean much to me. If you mean > 5' position, why not say pos_5prime and pos_3prime? > > As for start/end being right or wrong in bioperl, my take on this is > that it depends on your viewpoint and there's no silver bullet that > kills every bird. If your viewpoint is biological, then a feature > starts at its 5' end. If your viewpoint is a 1-dimensional axis, > then it is useful to define that end cannot be smaller than start, > and strand is the tool to map to the biological viewpoint. Bioperl > takes the latter viewpoint, which may be good for some and bad for > others. There's Bio::Coordinate that lets you potentially map > between any two systems. I have to say that some people here have > discovered the bioperl way of defining feature boundaries > independently of bioperl as the most useful one for storing and > searching genome mappings. To me it seems they've all got their > downsides and upsides, and one just needs to settle on one and be > consistent throughout. i meant the naming is wrong, not necessarily the semantics there is two choices of semantics for the two columns either [1] X <= Y or [2] (Y - X) * strand >= 0 (both assuming interbase coordintes) there is no absolute correct choice of what semantics to use - like you say, both have their up and downsides. (there is actually another choice, using offset+length, but i personally don't like this) however, start/end are obviously terrible, awful, confusing choices of attribute *name* for semantics [1], whether you speak biology or vector math or english. there is no debate on this one, sorry. we had already made the choice to go with semantics [2] for chado (so fmin/fmax as column names is not an option). my opinion is this is generally a more useful semantics. eg getting upstream regions. a lot more is expressible as simple arithmetic statements without restorting to ugly if/then/case constructs. given semantics 2 we were deciding on the names for X and Y. I think as Dave says having 5 and 3 in the column name is out. I do think it's ok to indicate a mathematical notation of directionality - even though protein features have strands, protein locations are still equivalent to 1-d vectors with directionality. you make a good point about cryptic names. i guess i tend towards shorter names. however, if you come across the name "fnbeg" and say "what's that?" and are forced to the read the documentation then this is a very good thing, as you then learn the semantics - both that these are interbase and directional. whereas a cosy familiar name will most likely lead people to assume they know the semantics and then mess up. this is what happens to people learning bioperl all the time. i'm being disingenuous, i know. i guess at the end of the day longer names are better. but then we have to be consistent within chado.... i'm glad i'm not the only one this pedantic about the naming of these things. (I don;t think the sementics issue is at all pedantinc - where possible these things should have a precise computational definition) > > -hilmar > > On Wednesday, October 30, 2002, at 06:45 PM, Scott Cain wrote: > > > I am sending this to the gmod-devel list to get the opinion of the > > larger audience. > > > > I am inclined to agree with Colin about nomenclature, though I do agree > > with you about bioperl's normal/incorrect use of boundaries. Before > > bioperl came along I did it the way you propose; it caused much > > confusion when I changed my schema to correspond to the bioperl way. > > Assuming we use Chris' proposed boundary coordinates, I think using > > check constraints is a good idea. > > > > Other opinions? > > > > Scott > > > > On Wed, 2002-10-30 at 20:54, Colin Wiel wrote: > >> I preferred your suggestion of pos5 and pos3, as well as my suggestion > >> of end5 and end3. I don't think a new chado user will figure out that > >> fnbeg stands for "feature natural begin" as easily as they would > >> figure > >> out that pos5 (or end5) is the "position of the 5' end". > >> > >> Colin > >> > >>> -----Original Message----- > >>> From: gmo...@li... [mailto:gmod-schema- > >>> ad...@li...] On Behalf Of Chris Mungall > >>> Sent: Wednesday, October 30, 2002 4:46 PM > >>> To: gmo...@li... > >>> Subject: [Gmod-schema] cvs changes: companalysis module, sequence > >> module > >>> > >>> > >>> I have reworked the tables in the computational analysis module; they > >> are > >>> now a little less generic than before. there is some docs included in > >> the > >>> .sql - more needed though... > >>> > >>> the multiple alignment part (eg for clustal results) is still fluid > >>> > >>> I have also settled on > >>> > >>> fnbeg > >>> fnend > >>> > >>> for specifying coordinates - feature natural begin, feature natural > >> end > >>> > >>> ie this is the "real" begin and end > >>> > >>> we should also possibly include a check constraint to make this > >> explicit > >>> eg > >>> > >>> fstrand is null OR (fnend - fnbeg) * fstrand >= 0 > >>> > >>> > >>> this is opposed to the normal (erroneous in my opinion) use of > >> start/begin > >>> end/stop, as used in bioperl, where > >>> > >>> start <= end > >>> > >>> ie they actually mean (low, high) > >>> > >>> how do we feel about check constraints? > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> This sf.net email is sponsored by: Influence the future > >>> of Java(TM) technology. Join the Java Community > >>> Process(SM) (JCP(SM)) program now. > >>> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > >>> _______________________________________________ > >>> Gmod-schema mailing list > >>> Gmo...@li... > >>> https://lists.sourceforge.net/lists/listinfo/gmod-schema > >> > >> > >> > >> ------------------------------------------------------- > >> This sf.net email is sponsored by: Influence the future > >> of Java(TM) technology. Join the Java Community > >> Process(SM) (JCP(SM)) program now. > >> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > >> _______________________________________________ > >> Gmod-schema mailing list > >> Gmo...@li... > >> https://lists.sourceforge.net/lists/listinfo/gmod-schema > >> > > -- > > ------------------------------------------------------------------------ > > Scott Cain, Ph. D. > > ca...@cs... > > GMOD Coordinator (http://www.gmod.org/) > > 216-392-3087 > > Cold Spring Harbor Laboratory > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: Influence the future > > of Java(TM) technology. Join the Java Community > > Process(SM) (JCP(SM)) program now. > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > > _______________________________________________ > > Gmod-schema mailing list > > Gmo...@li... > > https://lists.sourceforge.net/lists/listinfo/gmod-schema > > > -- > ------------------------------------------------------------- > Hilmar Lapp email: lapp at gnf.org > GNF, San Diego, Ca. 92121 phone: +1-858-812-1757 > ------------------------------------------------------------- > > |
From: Hilmar L. <hl...@gn...> - 2002-10-31 18:01:08
|
> -----Original Message----- > From: David Emmert [mailto:em...@mo...] > Sent: Thursday, October 31, 2002 6:34 AM > To: ca...@cs...; Hilmar Lapp > Cc: cj...@fr...; cw...@lb...; gmo...@li...; > gmo...@li... > Subject: Re: [Gmod-schema] cvs changes: companalysis module, sequence > module >=20 >=20 > Hilmar is correct that this is a matter of convention. I=20 > suggest we go=20 > with the bioperl method simply because it is broadly used. >=20 > One thing we must not do is use "5' or "3'" in coordinate=20 > column names. It > wouldn't make any sense with respect to some nucleotide=20 > sequence features,=20 > for example chromosomal mutations, and it wouldn't make any sense with > respect to *any* protein sequence features. >=20 Very good point, very true. > Our original "fmin" and "fmax" seem perfectly sensible to me. To me too (I'd still spell it out...). -hilmar |
From: David E. <em...@mo...> - 2002-10-31 14:32:37
|
Hilmar is correct that this is a matter of convention. I suggest we go with the bioperl method simply because it is broadly used. One thing we must not do is use "5' or "3'" in coordinate column names. It wouldn't make any sense with respect to some nucleotide sequence features, for example chromosomal mutations, and it wouldn't make any sense with respect to *any* protein sequence features. Our original "fmin" and "fmax" seem perfectly sensible to me. -Dave On Wednesday, October 30, 2002, at 22:24 PM, Hilmar Lapp wrote: >> From gmo...@li... Wed Oct 30 22:24 EST 2002 >> Subject: Re: [Gmod-schema] cvs changes: companalysis module, sequence module >> Cc: Colin Wiel <cw...@lb...>, gmod list <gmo...@li...>, >> "'Chris Mungall'" <cj...@fr...>, >> gmo...@li... >> To: Scott Cain <ca...@cs...> >> From: Hilmar Lapp <hl...@gn...> >> Date: Wed, 30 Oct 2002 19:25:24 -0800 >> >> My $0.02 on this is that I have seen unintuitive and cryptic column >> names causing as much grief as unintuitive and cryptic API method >> names. Intuitive and consistent naming is IMHO a much neglected art, >> but its lack is one of the most annoying (because avoidable) >> barriers to any piece of API or schema. >> >> At first glance, neither pos5 nor fnbeg mean much to me. If you mean >> 5' position, why not say pos_5prime and pos_3prime? >> >> As for start/end being right or wrong in bioperl, my take on this is >> that it depends on your viewpoint and there's no silver bullet that >> kills every bird. If your viewpoint is biological, then a feature >> starts at its 5' end. If your viewpoint is a 1-dimensional axis, >> then it is useful to define that end cannot be smaller than start, >> and strand is the tool to map to the biological viewpoint. Bioperl >> takes the latter viewpoint, which may be good for some and bad for >> others. There's Bio::Coordinate that lets you potentially map >> between any two systems. I have to say that some people here have >> discovered the bioperl way of defining feature boundaries >> independently of bioperl as the most useful one for storing and >> searching genome mappings. To me it seems they've all got their >> downsides and upsides, and one just needs to settle on one and be >> consistent throughout. >> >> -hilmar >> >> On Wednesday, October 30, 2002, at 06:45 PM, Scott Cain wrote: >> >> > I am sending this to the gmod-devel list to get the opinion of the >> > larger audience. >> > >> > I am inclined to agree with Colin about nomenclature, though I do agree >> > with you about bioperl's normal/incorrect use of boundaries. Before >> > bioperl came along I did it the way you propose; it caused much >> > confusion when I changed my schema to correspond to the bioperl way. >> > Assuming we use Chris' proposed boundary coordinates, I think using >> > check constraints is a good idea. >> > >> > Other opinions? >> > >> > Scott >> > >> > On Wed, 2002-10-30 at 20:54, Colin Wiel wrote: >> >> I preferred your suggestion of pos5 and pos3, as well as my suggestion >> >> of end5 and end3. I don't think a new chado user will figure out that >> >> fnbeg stands for "feature natural begin" as easily as they would >> >> figure >> >> out that pos5 (or end5) is the "position of the 5' end". >> >> >> >> Colin >> >> >> >>> -----Original Message----- >> >>> From: gmo...@li... [mailto:gmod-schema- >> >>> ad...@li...] On Behalf Of Chris Mungall >> >>> Sent: Wednesday, October 30, 2002 4:46 PM >> >>> To: gmo...@li... >> >>> Subject: [Gmod-schema] cvs changes: companalysis module, sequence >> >> module >> >>> >> >>> >> >>> I have reworked the tables in the computational analysis module; they >> >> are >> >>> now a little less generic than before. there is some docs included in >> >> the >> >>> .sql - more needed though... >> >>> >> >>> the multiple alignment part (eg for clustal results) is still fluid >> >>> >> >>> I have also settled on >> >>> >> >>> fnbeg >> >>> fnend >> >>> >> >>> for specifying coordinates - feature natural begin, feature natural >> >> end >> >>> >> >>> ie this is the "real" begin and end >> >>> >> >>> we should also possibly include a check constraint to make this >> >> explicit >> >>> eg >> >>> >> >>> fstrand is null OR (fnend - fnbeg) * fstrand >= 0 >> >>> >> >>> >> >>> this is opposed to the normal (erroneous in my opinion) use of >> >> start/begin >> >>> end/stop, as used in bioperl, where >> >>> >> >>> start <= end >> >>> >> >>> ie they actually mean (low, high) >> >>> >> >>> how do we feel about check constraints? >> >>> >> >>> >> >>> >> >>> ------------------------------------------------------- >> >>> This sf.net email is sponsored by: Influence the future >> >>> of Java(TM) technology. Join the Java Community >> >>> Process(SM) (JCP(SM)) program now. >> >>> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en >> >>> _______________________________________________ >> >>> Gmod-schema mailing list >> >>> Gmo...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/gmod-schema >> >> >> >> >> >> >> >> ------------------------------------------------------- >> >> This sf.net email is sponsored by: Influence the future >> >> of Java(TM) technology. Join the Java Community >> >> Process(SM) (JCP(SM)) program now. >> >> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en >> >> _______________________________________________ >> >> Gmod-schema mailing list >> >> Gmo...@li... >> >> https://lists.sourceforge.net/lists/listinfo/gmod-schema >> >> >> > -- >> > ------------------------------------------------------------------------ >> > Scott Cain, Ph. D. >> > ca...@cs... >> > GMOD Coordinator (http://www.gmod.org/) >> > 216-392-3087 >> > Cold Spring Harbor Laboratory >> > >> > >> > >> > ------------------------------------------------------- >> > This sf.net email is sponsored by: Influence the future >> > of Java(TM) technology. Join the Java Community >> > Process(SM) (JCP(SM)) program now. >> > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en >> > _______________________________________________ >> > Gmod-schema mailing list >> > Gmo...@li... >> > https://lists.sourceforge.net/lists/listinfo/gmod-schema >> > >> -- >> ------------------------------------------------------------- >> Hilmar Lapp email: lapp at gnf.org >> GNF, San Diego, Ca. 92121 phone: +1-858-812-1757 >> ------------------------------------------------------------- >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: Influence the future >> of Java(TM) technology. Join the Java Community >> Process(SM) (JCP(SM)) program now. >> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en >> _______________________________________________ >> Gmod-schema mailing list >> Gmo...@li... >> https://lists.sourceforge.net/lists/listinfo/gmod-schema >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - David Emmert FlyBase - Harvard Biological Laboratories em...@mo... 16 Divinity Avenue (617) 496-5667 [office] Cambridge, Massachusetts 02138, USA (617) 496-1354 [fax] http://flybase.bio.indiana.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
From: Suzanna L. <su...@fr...> - 2002-10-31 06:03:45
|
I find fnbeg and fnend completely uninterpretable. fn could stand for anything and would inevitably be confused and misused. Use either of the more intuitive names. My preference is for pos5 and pos3 because position is more neutral than end which may be construed as always being a terminal end rather than just a location. On Wednesday, October 30, 2002, at 06:45 PM, Scott Cain wrote: > I am sending this to the gmod-devel list to get the opinion of the > larger audience. > > I am inclined to agree with Colin about nomenclature, though I do agree > with you about bioperl's normal/incorrect use of boundaries. Before > bioperl came along I did it the way you propose; it caused much > confusion when I changed my schema to correspond to the bioperl way. > Assuming we use Chris' proposed boundary coordinates, I think using > check constraints is a good idea. > > Other opinions? > > Scott > > On Wed, 2002-10-30 at 20:54, Colin Wiel wrote: >> I preferred your suggestion of pos5 and pos3, as well as my suggestion >> of end5 and end3. I don't think a new chado user will figure out that >> fnbeg stands for "feature natural begin" as easily as they would >> figure >> out that pos5 (or end5) is the "position of the 5' end". >> >> Colin >> >>> -----Original Message----- >>> From: gmo...@li... [mailto:gmod-schema- >>> ad...@li...] On Behalf Of Chris Mungall >>> Sent: Wednesday, October 30, 2002 4:46 PM >>> To: gmo...@li... >>> Subject: [Gmod-schema] cvs changes: companalysis module, sequence >> module >>> >>> >>> I have reworked the tables in the computational analysis module; they >> are >>> now a little less generic than before. there is some docs included in >> the >>> .sql - more needed though... >>> >>> the multiple alignment part (eg for clustal results) is still fluid >>> >>> I have also settled on >>> >>> fnbeg >>> fnend >>> >>> for specifying coordinates - feature natural begin, feature natural >> end >>> >>> ie this is the "real" begin and end >>> >>> we should also possibly include a check constraint to make this >> explicit >>> eg >>> >>> fstrand is null OR (fnend - fnbeg) * fstrand >= 0 >>> >>> >>> this is opposed to the normal (erroneous in my opinion) use of >> start/begin >>> end/stop, as used in bioperl, where >>> >>> start <= end >>> >>> ie they actually mean (low, high) >>> >>> how do we feel about check constraints? >>> >>> >>> >>> ------------------------------------------------------- >>> This sf.net email is sponsored by: Influence the future >>> of Java(TM) technology. Join the Java Community >>> Process(SM) (JCP(SM)) program now. >>> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en >>> _______________________________________________ >>> Gmod-schema mailing list >>> Gmo...@li... >>> https://lists.sourceforge.net/lists/listinfo/gmod-schema >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: Influence the future >> of Java(TM) technology. Join the Java Community >> Process(SM) (JCP(SM)) program now. >> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en >> _______________________________________________ >> Gmod-schema mailing list >> Gmo...@li... >> https://lists.sourceforge.net/lists/listinfo/gmod-schema >> > -- > ----------------------------------------------------------------------- > - > Scott Cain, Ph. D. > ca...@cs... > GMOD Coordinator (http://www.gmod.org/) > 216-392-3087 > Cold Spring Harbor Laboratory > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > _______________________________________________ > Gmod-devel mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-devel |
From: Hilmar L. <hl...@gn...> - 2002-10-31 03:25:19
|
My $0.02 on this is that I have seen unintuitive and cryptic column names causing as much grief as unintuitive and cryptic API method names. Intuitive and consistent naming is IMHO a much neglected art, but its lack is one of the most annoying (because avoidable) barriers to any piece of API or schema. At first glance, neither pos5 nor fnbeg mean much to me. If you mean 5' position, why not say pos_5prime and pos_3prime? As for start/end being right or wrong in bioperl, my take on this is that it depends on your viewpoint and there's no silver bullet that kills every bird. If your viewpoint is biological, then a feature starts at its 5' end. If your viewpoint is a 1-dimensional axis, then it is useful to define that end cannot be smaller than start, and strand is the tool to map to the biological viewpoint. Bioperl takes the latter viewpoint, which may be good for some and bad for others. There's Bio::Coordinate that lets you potentially map between any two systems. I have to say that some people here have discovered the bioperl way of defining feature boundaries independently of bioperl as the most useful one for storing and searching genome mappings. To me it seems they've all got their downsides and upsides, and one just needs to settle on one and be consistent throughout. -hilmar On Wednesday, October 30, 2002, at 06:45 PM, Scott Cain wrote: > I am sending this to the gmod-devel list to get the opinion of the > larger audience. > > I am inclined to agree with Colin about nomenclature, though I do agree > with you about bioperl's normal/incorrect use of boundaries. Before > bioperl came along I did it the way you propose; it caused much > confusion when I changed my schema to correspond to the bioperl way. > Assuming we use Chris' proposed boundary coordinates, I think using > check constraints is a good idea. > > Other opinions? > > Scott > > On Wed, 2002-10-30 at 20:54, Colin Wiel wrote: >> I preferred your suggestion of pos5 and pos3, as well as my suggestion >> of end5 and end3. I don't think a new chado user will figure out that >> fnbeg stands for "feature natural begin" as easily as they would >> figure >> out that pos5 (or end5) is the "position of the 5' end". >> >> Colin >> >>> -----Original Message----- >>> From: gmo...@li... [mailto:gmod-schema- >>> ad...@li...] On Behalf Of Chris Mungall >>> Sent: Wednesday, October 30, 2002 4:46 PM >>> To: gmo...@li... >>> Subject: [Gmod-schema] cvs changes: companalysis module, sequence >> module >>> >>> >>> I have reworked the tables in the computational analysis module; they >> are >>> now a little less generic than before. there is some docs included in >> the >>> .sql - more needed though... >>> >>> the multiple alignment part (eg for clustal results) is still fluid >>> >>> I have also settled on >>> >>> fnbeg >>> fnend >>> >>> for specifying coordinates - feature natural begin, feature natural >> end >>> >>> ie this is the "real" begin and end >>> >>> we should also possibly include a check constraint to make this >> explicit >>> eg >>> >>> fstrand is null OR (fnend - fnbeg) * fstrand >= 0 >>> >>> >>> this is opposed to the normal (erroneous in my opinion) use of >> start/begin >>> end/stop, as used in bioperl, where >>> >>> start <= end >>> >>> ie they actually mean (low, high) >>> >>> how do we feel about check constraints? >>> >>> >>> >>> ------------------------------------------------------- >>> This sf.net email is sponsored by: Influence the future >>> of Java(TM) technology. Join the Java Community >>> Process(SM) (JCP(SM)) program now. >>> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en >>> _______________________________________________ >>> Gmod-schema mailing list >>> Gmo...@li... >>> https://lists.sourceforge.net/lists/listinfo/gmod-schema >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: Influence the future >> of Java(TM) technology. Join the Java Community >> Process(SM) (JCP(SM)) program now. >> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en >> _______________________________________________ >> Gmod-schema mailing list >> Gmo...@li... >> https://lists.sourceforge.net/lists/listinfo/gmod-schema >> > -- > ------------------------------------------------------------------------ > Scott Cain, Ph. D. > ca...@cs... > GMOD Coordinator (http://www.gmod.org/) > 216-392-3087 > Cold Spring Harbor Laboratory > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-schema > -- ------------------------------------------------------------- Hilmar Lapp email: lapp at gnf.org GNF, San Diego, Ca. 92121 phone: +1-858-812-1757 ------------------------------------------------------------- |
From: Scott C. <ca...@cs...> - 2002-10-31 02:45:34
|
I am sending this to the gmod-devel list to get the opinion of the larger audience. I am inclined to agree with Colin about nomenclature, though I do agree with you about bioperl's normal/incorrect use of boundaries. Before bioperl came along I did it the way you propose; it caused much confusion when I changed my schema to correspond to the bioperl way. Assuming we use Chris' proposed boundary coordinates, I think using check constraints is a good idea. Other opinions? Scott On Wed, 2002-10-30 at 20:54, Colin Wiel wrote: > I preferred your suggestion of pos5 and pos3, as well as my suggestion > of end5 and end3. I don't think a new chado user will figure out that > fnbeg stands for "feature natural begin" as easily as they would figure > out that pos5 (or end5) is the "position of the 5' end". > > Colin > > > -----Original Message----- > > From: gmo...@li... [mailto:gmod-schema- > > ad...@li...] On Behalf Of Chris Mungall > > Sent: Wednesday, October 30, 2002 4:46 PM > > To: gmo...@li... > > Subject: [Gmod-schema] cvs changes: companalysis module, sequence > module > > > > > > I have reworked the tables in the computational analysis module; they > are > > now a little less generic than before. there is some docs included in > the > > .sql - more needed though... > > > > the multiple alignment part (eg for clustal results) is still fluid > > > > I have also settled on > > > > fnbeg > > fnend > > > > for specifying coordinates - feature natural begin, feature natural > end > > > > ie this is the "real" begin and end > > > > we should also possibly include a check constraint to make this > explicit > > eg > > > > fstrand is null OR (fnend - fnbeg) * fstrand >= 0 > > > > > > this is opposed to the normal (erroneous in my opinion) use of > start/begin > > end/stop, as used in bioperl, where > > > > start <= end > > > > ie they actually mean (low, high) > > > > how do we feel about check constraints? > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: Influence the future > > of Java(TM) technology. Join the Java Community > > Process(SM) (JCP(SM)) program now. > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > > _______________________________________________ > > Gmod-schema mailing list > > Gmo...@li... > > https://lists.sourceforge.net/lists/listinfo/gmod-schema > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-schema > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. ca...@cs... GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory |
From: Colin W. <cw...@lb...> - 2002-10-31 01:54:18
|
I preferred your suggestion of pos5 and pos3, as well as my suggestion of end5 and end3. I don't think a new chado user will figure out that fnbeg stands for "feature natural begin" as easily as they would figure out that pos5 (or end5) is the "position of the 5' end". Colin > -----Original Message----- > From: gmo...@li... [mailto:gmod-schema- > ad...@li...] On Behalf Of Chris Mungall > Sent: Wednesday, October 30, 2002 4:46 PM > To: gmo...@li... > Subject: [Gmod-schema] cvs changes: companalysis module, sequence module > > > I have reworked the tables in the computational analysis module; they are > now a little less generic than before. there is some docs included in the > .sql - more needed though... > > the multiple alignment part (eg for clustal results) is still fluid > > I have also settled on > > fnbeg > fnend > > for specifying coordinates - feature natural begin, feature natural end > > ie this is the "real" begin and end > > we should also possibly include a check constraint to make this explicit > eg > > fstrand is null OR (fnend - fnbeg) * fstrand >= 0 > > > this is opposed to the normal (erroneous in my opinion) use of start/begin > end/stop, as used in bioperl, where > > start <= end > > ie they actually mean (low, high) > > how do we feel about check constraints? > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-schema |
From: Chris M. <cj...@fr...> - 2002-10-31 01:08:35
|
even though we aren't ready for 'releases' per se, people are writing code to the schema and we aren't necessarily stable yet. i have a few more changes i'd like to make to the sequence module; before i do that, i have given the current schema/chado directory the cvs symbolic tag "chado-0_01". this way code can target a specific release; the code should probably be cvs tagged in sync we could also have module based symbolic tagging too cvs also keeps revision numbers, but these will increase faster |
From: Chris M. <cj...@fr...> - 2002-10-31 00:46:12
|
I have reworked the tables in the computational analysis module; they are now a little less generic than before. there is some docs included in the .sql - more needed though... the multiple alignment part (eg for clustal results) is still fluid I have also settled on fnbeg fnend for specifying coordinates - feature natural begin, feature natural end ie this is the "real" begin and end we should also possibly include a check constraint to make this explicit eg fstrand is null OR (fnend - fnbeg) * fstrand >= 0 this is opposed to the normal (erroneous in my opinion) use of start/begin end/stop, as used in bioperl, where start <= end ie they actually mean (low, high) how do we feel about check constraints? |
From: Scott C. <ca...@cs...> - 2002-10-25 15:17:20
|
Hi Charles, Unfortunately, I can't tell you anything about the specifics of wormbase, as I am not directly involved in its development and maintenance. Perhaps Lincoln could give you some advice. As for the systems, yes they are very fresh. It is currently designed to contain more than one schema in parallel, though right now there is only one, the chado schema. It is under sourceforge cvs control, available through www.gmod.org. Scott On Fri, 2002-10-25 at 10:53, Charles Hauser wrote: > Hi Scott & Dave, > > I am pretty excited about trying to use the schema for the Chlamy > project. > > Not being involved in the development, I don't have a good feel for > where in the development phase you are with the schema - can you fill me > in? From the discussions on the gmod schema list it appears the > 'systems' are just getting set in place, and some of the modules (pub > for instance) will need revisions. > > We have just ordered a box to use for developing GMOD / postgres and I > would like to focus on getting that set up and begin the process of > moving data from our acedb (strains, pub...) and postgres (est ) into > tables before we receive the genomic data at which point I will be > totally swamped. > > If either of you have suggestions on how to proceed, pitfalls to avoid I > would appreciate hearing. At wormbase, did you migrate data from acedb > and into relational tables? > > Dave, at some point when you have time I would like to follow up on > your offer and get a postgres dump of the Drosophila data, for > exploration & to see how it is implemented. > > > best regards, > > Charles > > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. ca...@cs... GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory |
From: Simon T. <si...@mc...> - 2002-10-23 15:18:16
|
It would seem one choice for a logo for the project might look something like this: |
From: David E. <em...@mo...> - 2002-10-23 14:20:07
|
By the way, >> > > On 22 Oct 2002, Scott Cain wrote: >> > > BTW, why chado ("the way of tea"?)? Chris and I had been drinking whipped tea in Santa Fe the day we cracked a difficult issue with the schema. -Dave http://www.nobleharbor.com/tea/chado/psychaspectofchado.html Insight into why one might be motivated to choose this discipline over others comes from five related statements of its purpose given by the present Grand Master of the Urasenke lineage of tea. First is to "realize tranquility in relation with others within the environment" (Sen Soshitsu, 1979). In regard to tranquility, it is like a moving meditation, having been compared to T'ai Chi Ch'uan (Cohen, 1976), and thus more appealing to some than sitting still meditation. Secondly, it is usually practiced in relatedness with others rather than in solitude, and, thirdly, in an environmental context of both nature (divine creation) and art (human creation), rather than withdrawing the senses as in some forms of meditation. Fourth, this Grand Master, who has spread chado internationally, also speaks of its purpose in terms of bringing peace to the world through a bowl of tea prepared and received with all the heart, which certainly is another appeal to many. Fifth, he has also said its goal is "to build one's personality and character" (Sen Soshitsu XV, 1970, p. 6), and the most revered tea master of past history Sen Rikyu is quoted as saying, "The most important purpose of tea... is...to arrive at spiritual enlightenment" (Tanigawa, 1976, p. 37) or, in another translation, "Chanoyu is above all a matter of practicing and realizing the way in accord with the Buddha's teaching" (Okakura, 1991, pp. 153-154). |
From: David E. <em...@mo...> - 2002-10-23 14:03:34
|
Hi, >> Makes sense to me. David? Looks good! >> > > BTW, why chado ("the way of tea"?)? -D >> From ca...@cs... Tue Oct 22 12:37 EDT 2002 >> Subject: Re: [Gmod-schema] Re: Action points from yesterday's conversation >> on the modular schema >> From: Scott Cain <ca...@cs...> >> To: Chris Mungall <cj...@fr...> >> Cc: David Emmert <em...@mo...>, Lincoln Stein <ls...@cs...>, >> co...@mo..., gmo...@li... >> Content-Transfer-Encoding: 7bit >> Date: 22 Oct 2002 12:38:15 -0400 >> Mime-Version: 1.0 >> >> Makes sense to me. David? >> >> On Tue, 2002-10-22 at 12:26, Chris Mungall wrote: >> > >> > Ok, what about this minor change: >> > >> > gmod-schema >> > chado/ >> > modules/ >> > sequence/ >> > sequence.sql >> > genetics/ >> > genetics.sql >> > docs/ >> > src/ >> > >> > this allows us schema-level documentation, and more specific documentation >> > that lives at the module level; we can also include anything else at the >> > module level if we decide to - eg dtds or xml-schema that map directly >> > onto the relational schema >> > >> > On 22 Oct 2002, Scott Cain wrote: >> > >> > > Chris, >> > > >> > > Just to be sure before I do it, here is the file structure I am going to >> > > import: >> > > >> > > gmod-schema/ >> > > chado/ >> > > sql/ >> > > sequence/ >> > > genetics/ >> > > expression/ >> > > etc.. >> > > doc/ >> > > diagrams/ >> > > >> > > BTW, why chado ("the way of tea"?)? >> > > >> > > Scott >> > > |
From: Scott C. <ca...@cs...> - 2002-10-22 16:38:23
|
Makes sense to me. David? On Tue, 2002-10-22 at 12:26, Chris Mungall wrote: > > Ok, what about this minor change: > > gmod-schema > chado/ > modules/ > sequence/ > sequence.sql > genetics/ > genetics.sql > docs/ > src/ > > this allows us schema-level documentation, and more specific documentation > that lives at the module level; we can also include anything else at the > module level if we decide to - eg dtds or xml-schema that map directly > onto the relational schema > > On 22 Oct 2002, Scott Cain wrote: > > > Chris, > > > > Just to be sure before I do it, here is the file structure I am going to > > import: > > > > gmod-schema/ > > chado/ > > sql/ > > sequence/ > > genetics/ > > expression/ > > etc.. > > doc/ > > diagrams/ > > > > BTW, why chado ("the way of tea"?)? > > > > Scott > > > > On Mon, 2002-10-21 at 15:19, Chris Mungall wrote: > > > > > > Have we decided on the directory organisation yet? > > > > > > As I see it we have a collection of files categorised along the following > > > axes: > > > > > > module (sequence, genetics, etc) > > > > > > schema instance ("chado" is I think the name we have finalised on). I am > > > still thinking in terms of gmod-schema being a collection of complementary > > > but possibly redundant schemas; perhaps others would prefer to think in > > > terms of one single gmod-schema? > > > > > > file-type; eg DDL as SQL statements, documentation (html, text, > > > images, other), xml schema translation of the relational schema, adapter > > > code, etc > > > > > > These could be arranged in a directory structure in the following ways: > > > > > > (1) (SCHEMA-TYPE-MODULE) > > > > > > gmod-schema/ > > > chado/ > > > sql/ > > > sequence/ > > > genetics/ > > > expression/ > > > > > > this way doesn't force chado's modular divisions on the rest of > > > gmod-schema > > > > > > (2) (MODULE-SCHEMA-TYPE) > > > > > > gmod-schema/ > > > sequence/ > > > chado/ > > > sql/ > > > sequence.sql > > > bio-db-gff/ > > > bio-db-gff.sql > > > genetics/ > > > chado/ > > > genetics.sql > > > > > > this enforces the divisions Dave and I decided upon on the rest of > > > gmod-schema; maybe not ideal, for instance, there is an argument for > > > further subdividing what Dave and I call 'genetics' into 'phenotype'. on > > > the other hand, it is properly modularised > > > > > > (3) (MODULE-TYPE) > > > > > > gmod-schema/ > > > sequence/ > > > sql/ > > > sequence.sql > > > docs/ > > > sequence.txt > > > coordinate-system.txt > > > > > > this is if we decide there is only one core gmod-schema (obviously still > > > allowing databases such as bio-db-gff in project specific repositories). > > > > > > I'm happy with any, just making sure we're all on the same page. If > > > pressed I'd vote for > > > SCHEMA/MODULE/TYPE or SCHEMA/TYPE/MODULE > > > > > > but then if nothing else other than 'chado' is going to live here then we > > > have an extra annoying pointless directory. > > > > > > > > > On 21 Oct 2002, Scott Cain wrote: > > > > > > > Chris, > > > > > > > > While I was preparing to create a sourceforge GMOD cvs repository for > > > > the modular schema, I came across this page: > > > > > > > > http://sourceforge.net/docman/display_doc.php?docid=768&group_id=1 > > > > > > > > About half way down the page is a section "Import of Existing CVS > > > > Repositories," which details how to get files that are under current CVS > > > > control into the sourceforge CVS control. Since you already have these > > > > files under CVS control, do you want to move them directly to > > > > sourceforge (and thus maintain their revision history), or just import > > > > what have and lose the history? If you make the tarball as directed, you > > > > can send it to me and I will deal with sourceforge support. > > > > > > > > Thanks, > > > > Scott > > > > > > > > On Fri, 2002-10-18 at 15:25, Chris Mungall wrote: > > > > > > > > > > > > > > > On 18 Oct 2002, Scott Cain wrote: > > > > > > > > > > > Dave, > > > > > > > > > > > > We should definitely get this stuff under cvs control. I was thinking > > > > > > of a module named schema with doc, src and image subdirectories to hold > > > > > > the information that is in the three tar balls that are currently on the > > > > > > website. If nobody has any objections, that's what I'll do. > > > > > > > > > > That would be great, thanks. > > > > > > > > > > (it is under cvs at the moment, but just in a flat scratch space, the > > > > > sooner we get it a real home the better) > > > > > > > > > > just to be pernickity - > > > > > > > > > > i expect code to live under src/ - i'd make it sql/ > > > > > > > > > > shall we just stick the images under doc/ > > > > > > > > > > should we have the doc directory mirror the modular structure of the sql > > > > > directory, or should we just have module-specific docs > > > > > > > > > > the way we have it now is > > > > > > > > > > /sql > > > > > sequence/ > > > > > sequence.sql > > > > > use-cases/ > > > > > > > > > > and so on > > > > > > > > > > sorry to be a bore about these things but it's important to get a cvs dir > > > > > set up right as it's a pain to change the structure once it's underway! > > > > > > > > > > > About the phone meeting, I'll answer for Lincoln, so that you can get an > > > > > > answer before you go home today. Lincoln is teaching a course this week > > > > > > and next, so his time during the day is rather limited. I don't know > > > > > > about is plans for the week after, but perhaps that is when we should > > > > > > shoot for. > > > > > > > > > > > > Scott > > > > > > > > > > > > > > > > > > On Fri, 2002-10-18 at 11:34, David Emmert wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > First of all, Scott, I had a look at the Modular Schema info you put on > > > > > > > http://www.gmod.org, and it looks great - many thanks. I wonder if you > > > > > > > have any ideas as to how we can go about improving whats there and making > > > > > > > sure it is current. Should we be thinking about putting the Modular > > > > > > > Schema into the sourceforge CVS now, and if so, how organized? > > > > > > > > > > > > > > Thanks also for setting up the schema mailing list. > > > > > > > > > > > > > > I wanted to let you all know that I've successfully loaded all of the > > > > > > > D.melanogaster "release 3" genome annotation GenBank records into the > > > > > > > schema, and the sequence module seems to have worked beautifully. I > > > > > > > finished the loader just last night so I havn't completely evaluated > > > > > > > the results, but the annotations I've looked at look good. > > > > > > > > > > > > > > There's at least one gene model annotation which *didn't* load properly, > > > > > > > mod(mdg4), which is a nasty case of trans splicing who's "join" locations > > > > > > > my location parser definitely did not appreciate. Here's what one of the > > > > > > > mod(mdg4) GB mRNA features looks like: > > > > > > > > > > > > > > mRNA join(138523..138735,138795..139263, > > > > > > > complement(154413..154524),complement(153944..154201), > > > > > > > complement(153727..153866),complement(152185..153037)) > > > > > > > /product="CG32491-PZ" > > > > > > > /note="trans splicing" > > > > > > > > > > > > > > Parser go bung! > > > > > > > > > > > > > > I'm sure this case is workable in the schema, and I'll work on parsing > > > > > > > locations of this ilk as soon as I get a chance. > > > > > > > > > > > > > > Lincoln, I focused on this instead of the WormBase data because in > > > > > > > the context of our local (FlyBase) development, and learning how to > > > > > > > layer-on the genetic/phenotypic data, we really needed to get a test-bed > > > > > > > to work with, and it looks like a proper port of Berkeley's gadfly data > > > > > > > is going to take some time coming. > > > > > > > > > > > > > > I'll take a look at the WormBase GFF and .ace data now. > > > > > > > > > > > > > > In the meantime, if any of you would like a postgres dump of this > > > > > > > data to play with, please let me know. Please, everyone, be aware > > > > > > > that the current D.melanogaster "release 3" genome annotation data > > > > > > > in GenBank imperfect, and these imperfections (only, I hope) are > > > > > > > obviously going to be in this test data. > > > > > > > > > > > > > > Once I've convinced myself I've implemented this properly, I want to > > > > > > > start writing some practical documents on implementing data in the > > > > > > > sequence module. Scott, others, if you have any opinions on format > > > > > > > or content this should have, please let me know. > > > > > > > > > > > > > > If I get a chance, I'm going to try to get Gbrowse up and running on > > > > > > > this data, as I'm very anxious to know how the Modular Schema and > > > > > > > Gbrowse play together. I have no idea how easy or difficult this > > > > > > > will be, being totally unfamiliar with Gbrowse; if anybody wants to > > > > > > > give advice or lend a hand, please do! > > > > > > > > > > > > > > Finally, Lincoln mentioned we set up further conference calls, and > > > > > > > I'd like to suggest we shoot for next Wednesday, 22 Oct, 3pm EST - > > > > > > > same time as last time. Would that work for everybody? > > > > > > > > > > > > > > I'll be out of town on Monday or Tuesday, but checking mail off and > > > > > > > on, so apologies in advance if my replies are slow in coming. > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > -Dave > > > > > > > > > > > > > > > > > > > > > >> From ls...@pe... Thu Oct 10 12:56 EDT 2002 > > > > > > > >> From: Lincoln Stein <ls...@cs...> > > > > > > > >> To: wa...@cs..., kc...@cs... > > > > > > > >> Subject: Action points from yesterday's conversation on the modular schema > > > > > > > >> Date: Thu, 10 Oct 2002 12:57:32 -0400 > > > > > > > >> User-Agent: KMail/1.4.3 > > > > > > > >> Cc: Chris Mungall <cj...@fr...>, David Emmert <em...@mo...>, > > > > > > > >> Scott Cain <ca...@cs...> > > > > > > > >> MIME-Version: 1.0 > > > > > > > >> Content-Transfer-Encoding: 8bit > > > > > > > >> X-MIME-Autoconverted: from quoted-printable to 8bit by morgan.harvard.edu id MAA10948 > > > > > > > >> > > > > > > > >> Hi All, > > > > > > > >> > > > > > > > >> I thought our conversation yesterday about the modular schema was very > > > > > > > >> productive, and I look forward to David setting up a schedule for further > > > > > > > >> talks. Just a summary of the action points that we ended on: > > > > > > > >> > > > > > > > >> Because ideally the modular schema should support the application modules that > > > > > > > >> we've already contributed to gmod, we're going to put together test sets for > > > > > > > >> David and Chris to work with. > > > > > > > >> > > > > > > > >> 1) Lincoln to provide sequence feature data from WormBase in GFF and .ace > > > > > > > >> format > > > > > > > >> 2) Ken & Doreen to provide genetic map and correspondence data in the form of > > > > > > > >> relational database table dumps > > > > > > > >> 3) Doreen to provide curated mutants/phenotypes/alleles in some form (to be > > > > > > > >> determined) > > > > > > > >> 4) Scott to set up mailing list on gmod site to help coordinate this. > > > > > > > >> > > > > > > > >> The data sets will be submitted via e-mail to David. I will do this by > > > > > > > >> putting a data set on an FTP site and sending the URL to David. > > > > > > > >> > > > > > > > >> Lincoln > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > This sf.net email is sponsored by:ThinkGeek > > > > > > > Welcome to geek heaven. > > > > > > > http://thinkgeek.com/sf > > > > > > > _______________________________________________ > > > > > > > Gmod-schema mailing list > > > > > > > Gmo...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/gmod-schema > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. ca...@cs... GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory |