Quantcast

Re: [Gmod-phendiver] questions about the Medicago ND use case

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Gmod-phendiver] questions about the Medicago ND use case

Naama Menda
I guess the question here should be whether it's a good idea to re-use phenotypes, what is the gain Vs. cost, etc.

Is anyone else re-using phenotype descriptors only (without the values) ?

-Naama


On Mon, Apr 25, 2011 at 4:41 PM, Sook Jung <[hidden email]> wrote:
Didn't we agree to store phenotypic values in phenotype.value, the description of the phenotype in cvterm, any code definition for the phenotype descriptors in cvtermprop?
 
I've included Seth in CC so that we can include him in any further correspondence.
 
Sook

On Mon, Apr 25, 2011 at 1:24 PM, Yuri Bendana <[hidden email]> wrote:
This is because I treat the phenotype description stored in the phenotype/phenotypeprop tables  separate from the phenotype values in the property table.  This way I'm not repeating the phenotype description for each observation.  I can reuse the same phenotype description across experiments and projects.  In essence I try to follow the principle of DRY (Do not Repeat Yourself) as much as is practical.  Currently I'm saving one row per observation but if the phenotype has a complex description it could be more.  Since we are storing thousands of observations, this has the benefit of making our tables smaller.

yuri

On Apr 25, 2011, at 12:52 PM, Naama Menda wrote:

hi Yuri,
I have another question about the paragraph you wrote in the ND draft.
Why do you store phenotype values in the prop tables (phenotypeprop and nd_experimentcollectionprop) and not in the value field of the phenotype table?

-Naama


On Mon, Apr 18, 2011 at 10:36 PM, Yuri Bendana <[hidden email]> wrote:

On Apr 18, 2011, at 4:27 PM, Robert Buels wrote:

>
> You guys removed the unique constraints from stock.uniquename and phenotype.uniquename?  That doesn't make sense.  If the column is called 'uniquename', it should be a unique. name.
>
> Maybe those columns should be eliminated.  Or at least renamed.  I've never thought any of the uniquename columns made that much sense.
>

At the hackathon, we agreed to remove the unique constraint from phenotype.uniquename because the phenotype table can be used to store phenotype observations (value, units_id, cvalue_id) as well as phenotype descriptions (uniquename, observable_id). I argued for a separate table for observations but was overruled (since then I decided to store those in nd_experiment_phenotypeprop).  But it was agreed that phenotype.uniquename would be left as is to not impact current users (mainly Flybase), I believe.  I think it's confusing as well to have a field called uniquename that's not unique.  In any case, those changes to the Phenotype module didn't make it into the Chado trunk from the NatDiv branch, I don't know why.

So, when Sook and I were discussing the project.name and stock.uniquename, I thought about what we proposed doing to the phenotype.uniquename. I support removal of stock.uniquename, removal of the unique constraint on project.name, and changing phenotype.uniquename to phenotype.name with removal of its unique constraint.

yuri

Yuri Bendaña
Research Programmer
Nuzhdin Lab, MCB Section, Dept of BISC
University of Southern California
<a href="tel:213-740-2398" value="+12137402398" target="_blank">213-740-2398





Yuri Bendaña
Research Programmer
Nuzhdin Lab, MCB Section, Dept of BISC
University of Southern California
<a href="tel:213-740-2398" value="+12137402398" target="_blank">213-740-2398






--
Sook Jung, PhD
Assistant Research Professor of Bioinformatics
Dept of Horticulture and Landscape Architecture
Washington State University
45 Johnson Hall, Pullman, WA 99164-6414
[hidden email]


------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Gmod-phendiver] questions about the Medicago ND use case

Hilmar Lapp-3
Perhaps it's not the most appropriate example because the implementation isn't using GMOD (it is using OBD instead, which in some ways pushes the weak-typing paradigm of Chado to the subject-predicate-object triple extreme). In Phenoscape (http://kb.phenoscape.org) we are re-using phenotype descriptions (in the form of ontology-based logic expressions) all the time.

-hilmar

On Apr 25, 2011, at 4:48 PM, Naama Menda wrote:

I guess the question here should be whether it's a good idea to re-use phenotypes, what is the gain Vs. cost, etc.

Is anyone else re-using phenotype descriptors only (without the values) ?

-Naama


On Mon, Apr 25, 2011 at 4:41 PM, Sook Jung <[hidden email]> wrote:
Didn't we agree to store phenotypic values in phenotype.value, the description of the phenotype in cvterm, any code definition for the phenotype descriptors in cvtermprop?
 
I've included Seth in CC so that we can include him in any further correspondence.
 
Sook

On Mon, Apr 25, 2011 at 1:24 PM, Yuri Bendana <[hidden email]> wrote:
This is because I treat the phenotype description stored in the phenotype/phenotypeprop tables  separate from the phenotype values in the property table.  This way I'm not repeating the phenotype description for each observation.  I can reuse the same phenotype description across experiments and projects.  In essence I try to follow the principle of DRY (Do not Repeat Yourself) as much as is practical.  Currently I'm saving one row per observation but if the phenotype has a complex description it could be more.  Since we are storing thousands of observations, this has the benefit of making our tables smaller.

yuri

On Apr 25, 2011, at 12:52 PM, Naama Menda wrote:

hi Yuri,
I have another question about the paragraph you wrote in the ND draft.
Why do you store phenotype values in the prop tables (phenotypeprop and nd_experimentcollectionprop) and not in the value field of the phenotype table?

-Naama


On Mon, Apr 18, 2011 at 10:36 PM, Yuri Bendana <[hidden email]> wrote:

On Apr 18, 2011, at 4:27 PM, Robert Buels wrote:

>
> You guys removed the unique constraints from stock.uniquename and phenotype.uniquename?  That doesn't make sense.  If the column is called 'uniquename', it should be a unique. name.
>
> Maybe those columns should be eliminated.  Or at least renamed.  I've never thought any of the uniquename columns made that much sense.
>

At the hackathon, we agreed to remove the unique constraint from phenotype.uniquename because the phenotype table can be used to store phenotype observations (value, units_id, cvalue_id) as well as phenotype descriptions (uniquename, observable_id). I argued for a separate table for observations but was overruled (since then I decided to store those in nd_experiment_phenotypeprop).  But it was agreed that phenotype.uniquename would be left as is to not impact current users (mainly Flybase), I believe.  I think it's confusing as well to have a field called uniquename that's not unique.  In any case, those changes to the Phenotype module didn't make it into the Chado trunk from the NatDiv branch, I don't know why.

So, when Sook and I were discussing the project.name and stock.uniquename, I thought about what we proposed doing to the phenotype.uniquename. I support removal of stock.uniquename, removal of the unique constraint on project.name, and changing phenotype.uniquename to phenotype.name with removal of its unique constraint.

yuri

Yuri Bendaña
Research Programmer
Nuzhdin Lab, MCB Section, Dept of BISC
University of Southern California
<a href="tel:213-740-2398" value="+12137402398" target="_blank">213-740-2398





Yuri Bendaña
Research Programmer
Nuzhdin Lab, MCB Section, Dept of BISC
University of Southern California
<a href="tel:213-740-2398" value="+12137402398" target="_blank">213-740-2398






--
Sook Jung, PhD
Assistant Research Professor of Bioinformatics
Dept of Horticulture and Landscape Architecture
Washington State University
45 Johnson Hall, Pullman, WA 99164-6414
[hidden email]

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver

-- 
===========================================================
: Hilmar Lapp -:- Durham, NC -:- hlapp at drycafe dot net :
===========================================================





------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Loading...