Menu
▾
▴
gmod-schema
|
From: Naama M. <nm...@co...> - 2016-05-26 17:44:23
|
There are some proposed changes for allowing to post-compose cvterms linked to one phenotype http://gmod.org/wiki/Chado_Post-Composed_Phenotypes The detailed chnages are in the doc for proposed changes in Chado https://docs.google.com/document/d/1IZ3VMpIoG1hhpbHYi6rbChImLgrlmbyy7Ewms-EpaeU/edit This schema has minimal changes (only 1 new table and 2 new columns in phenotype_cvterm) and works well for simple EAV and complex EQ statements, as well as with post and pre-composed cvterms. We'd like to use some of these new features in our breeders databases, so if you are using the phenotype module please read those pages and send your input Thanks! Naama Menda Boyce Thompson Institute for Plant Research Tower Rd Ithaca NY 14853 USA (607) 254 3569 Sol Genomics Network http://solgenomics.net/ nm...@co... |
|
From: Chris M. <cjm...@lb...> - 2016-05-26 19:52:58
|
Thanks Naama Do you intend to make a pull request for the schema changes? I'm not sure what the current GMOD policy is but this works well on other standards projects, with stakeholders giving +1s etc, and having the discussion linked to the commit trail If I could attempt a brief summary, sorry if this doesn't fully capture it: you are moving from the old schema where phenotypes have a fixed number of slots were available to a flexible number of slots. Standardization of the slot fields (what you have as PE1, PE2, etc) is key to successful interoperability. There are a few options here. One way is to use RO relations. Another way is to treat these as a different layer from the biological object graph, and to treat them as slots that may have different meanings in different contexts. This is actually quite well aligned with the Dead Simple OWL Design patterns approach that a number of ontologies are switching to. See https://github.com/dosumis/dead_simple_owl_design_patterns For some example trait patterns, see https://github.com/obophenotype/bio-attribute-ontology/tree/master/src/ontology/patterns I think it would be a good idea to align the cvterms you use with the ones we are using here. Sorry if this sounds a little opaque, I'll try and provide more details later. On Thu, May 26, 2016 at 10:44 AM, Naama Menda <nm...@co...> wrote: > There are some proposed changes for allowing to post-compose cvterms > linked to one phenotype > > http://gmod.org/wiki/Chado_Post-Composed_Phenotypes > > The detailed chnages are in the doc for proposed changes in Chado > > https://docs.google.com/document/d/1IZ3VMpIoG1hhpbHYi6rbChImLgrlmbyy7Ewms-EpaeU/edit > > This schema has minimal changes (only 1 new table and 2 new columns in > phenotype_cvterm) and works well for simple EAV and complex EQ > statements, as well as with post and pre-composed cvterms. > > We'd like to use some of these new features in our breeders databases, so > if you are using the phenotype module please read those pages and send your > input > > > Thanks! > > > Naama Menda > Boyce Thompson Institute for Plant Research > Tower Rd > Ithaca NY 14853 > USA > > (607) 254 3569 > Sol Genomics Network > http://solgenomics.net/ > nm...@co... > > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data > untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-schema > > |
|
From: Naama M. <nm...@co...> - 2016-05-26 20:28:21
|
hi Chris, I can make the changes in git and send a pull request. These changes have been in the works for a couple of years now, but no one really wanted to touch the phenotype module until now. The idea is to separate phenotype values from the cvterms, as it is structured no in the phenotype table, allowing to store any number of cvterms linked with one phenotype value (using phenotype_cvterm) + adding the ability to group those cvterms if needed (phenotype_clause) The suggested schema is vary abstract, and the examples with EQ statements is just a use-case . It would work well for any post-composition of cvterms that describe a phenotype , quantitative or qualitative. So yes, we'd like to have flexible 'slots' for phnoetypes, and the type_id field in phenotype_cvterm is optional in cases such as making an EQ statement that requires indicating if the cvterm is PE1, PE2, etc. as shown in the example, or any other semantics that may be needed -Naama Naama Menda Boyce Thompson Institute for Plant Research Tower Rd Ithaca NY 14853 USA (607) 254 3569 Sol Genomics Network http://solgenomics.net/ nm...@co... On Thu, May 26, 2016 at 3:52 PM Chris Mungall <cjm...@lb...> wrote: > Thanks Naama > > Do you intend to make a pull request for the schema changes? I'm not sure > what the current GMOD policy is but this works well on other standards > projects, with stakeholders giving +1s etc, and having the discussion > linked to the commit trail > > If I could attempt a brief summary, sorry if this doesn't fully capture > it: you are moving from the old schema where phenotypes have a fixed number > of slots were available to a flexible number of slots. > > Standardization of the slot fields (what you have as PE1, PE2, etc) is key > to successful interoperability. There are a few options here. One way is to > use RO relations. Another way is to treat these as a different layer from > the biological object graph, and to treat them as slots that may have > different meanings in different contexts. > > This is actually quite well aligned with the Dead Simple OWL Design > patterns approach that a number of ontologies are switching to. See > https://github.com/dosumis/dead_simple_owl_design_patterns > > For some example trait patterns, see > > https://github.com/obophenotype/bio-attribute-ontology/tree/master/src/ontology/patterns > > I think it would be a good idea to align the cvterms you use with the ones > we are using here. Sorry if this sounds a little opaque, I'll try and > provide more details later. > > > > On Thu, May 26, 2016 at 10:44 AM, Naama Menda <nm...@co...> wrote: > >> There are some proposed changes for allowing to post-compose cvterms >> linked to one phenotype >> >> http://gmod.org/wiki/Chado_Post-Composed_Phenotypes >> >> The detailed chnages are in the doc for proposed changes in Chado >> >> https://docs.google.com/document/d/1IZ3VMpIoG1hhpbHYi6rbChImLgrlmbyy7Ewms-EpaeU/edit >> >> This schema has minimal changes (only 1 new table and 2 new columns in >> phenotype_cvterm) and works well for simple EAV and complex EQ >> statements, as well as with post and pre-composed cvterms. >> >> We'd like to use some of these new features in our breeders databases, so >> if you are using the phenotype module please read those pages and send your >> input >> >> >> Thanks! >> >> >> Naama Menda >> Boyce Thompson Institute for Plant Research >> Tower Rd >> Ithaca NY 14853 >> USA >> >> (607) 254 3569 >> Sol Genomics Network >> http://solgenomics.net/ >> nm...@co... >> >> >> ------------------------------------------------------------------------------ >> Mobile security can be enabling, not merely restricting. Employees who >> bring their own devices (BYOD) to work are irked by the imposition of MDM >> restrictions. Mobile Device Manager Plus allows you to control only the >> apps on BYO-devices by containerizing them, leaving personal data >> untouched! >> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j >> _______________________________________________ >> Gmod-schema mailing list >> Gmo...@li... >> https://lists.sourceforge.net/lists/listinfo/gmod-schema >> >> > |
Thanks for helping keep SourceForge clean.
X