[Gmod-schema] updating the phenotype module

Discussion:

Naama Menda

9 years ago

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/
***@cornell.edu

Chris Mungall

9 years ago

Permalink

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.

...

Naama Menda

9 years ago

Permalink

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/

Post by Chris Mungall
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.

Post by Naama Menda
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/
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/gmod-schema

...