Phenotype Module

[spficklin]

This issue imported from the Chado v1.4 requested changes google doc:

http://gmod.827538.n3.nabble.com/proposal-for-changes-to-the-phenotype-module-tc4044535.html#a4044612

• Deprecate fields of the phenotype table: observable_id, attr_id, cvalue_id, assay_id
• New tables:
  • phenotype_cvtermrelationship
• Naama Menda says (3/11/2015): Inclined towards option #1 http://gmod.org/wiki/Chado_Post-Composed_Phenotypes#Option_1:_Group_Module_is_an_intrinsic_part_of_the_phenotype_cvterm_table
• Need a way to decouple phenotype description from its value, and to allow post-composing of phenotypes , e.g. EQ statements.
• Valentin Guignon says (3/11/2015): about names, I suggest phenotype_cvtermrelationship → phenotype_cvterm_composition and rank → composition_order (or keep rank and add a column composition_order and adjust constraints according to that)

[spficklin]

Sample code from the Google Doc

COMMENT ON TABLE phenotype IS 'Columns observable_id, attr_id, cvalue_id, assay_id are deprecated to break the connection between the phenotype value and the trait. The phenotype table should be used to store only the phenotype value. Use tables phenotype_cvterm and/or phenotype_cvtermrelationship to store the trait(s) associated with the phenotype. This allows a more abstract  way of post-composing cvterms and storing EQ statements.';
CREATE TABLE phenotype_cvtermrelationship (
      phenotype_cvtermrelationship_id serial PRIMARY KEY,
      phenotype_id integer NOT NULL REFERENCES phenotype(phenotype_id),
      cvterm_id integer NOT NULL REFERENCES cvterm(cvterm_id),
      type_id integer NOT NULL REFERENCES cvterm(cvterm_id),
      phenotypegroup integer DEFAULT NULL,
      rank integer DEFAULT 0 );
ALTER TABLE phenotype_cvtermrelationship ADD unique (phenotype_id,
cvterm_id, type_id, phenotypegroup,rank);

[laceysanderson]

I do not support this proposal...

We have to make sure that supporting EQ statements doesn't cause serious performance issues for those of us who don't use EQ statements! We currently use the attr_id to link our values to our "simple" traits. Forcing those of us with simple traits to join to another table to specify the trait of a value will double the number of records and cause a performance hit. This is a deal breaker for "big data".

Furthermore, I see no reason to deprecate the cvalue_id if your goal is to decouple the trait from the value. The cvalue_id field is critical for use of scales with phenotypic data!

[ekcannon]

I agree with Lacey. Expanding on my comment to https://github.com/GMOD/Chado/issues/35, , those of us dealing with germplasm traits do need cvalue and value, along with observable_id, attr_id, cvalue_id, assay_id.

[scottcain]

So does #35 do the same thing, or is it separate but related?

[ekcannon]

This issue is pretty much the same as #35.