nd_assay_phenotype

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

nd_assay_phenotype

Sook Jung
Hi Seth and  Bob,

Could you and anybody remind me again the reasons why we wanted
nd_assay_phenotype.assay_id to be unique? In other words, we decided
to have a unique row in nd_assay table for each trait (phenotype)?


 I think I really need to group a unique sample (on which multiple
phenotype evaluations are done), so it would be easier if one assay_id
can be linked to multiple phenotype_id.. But I know that we had
reasons not to do this - just can't remember.

The other way around is to link a group of assay_ids into a project_id
or I can make a sample_id (nd_assayprop.type_id) in nd_assayprop
table..

Thanks

Sook

-

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Naama Menda
hi Sook,

nd_assay is now called nd_experiment (since there is already an assay table in the MAGE module)
I don't remember exactly the reasons for the 1-to-1 relationships between experiments and phenotypes or genotypes , but the idea is that each phenotyping /genotyping  event is an 'experiment'

in your case, just store a new stock, then store a new nd_experiment each time you have a phenotype, and link the 2 using nd_experiment_stock


-Naama



On Wed, Sep 29, 2010 at 2:21 PM, Sook Jung <[hidden email]> wrote:
Hi Seth and  Bob,

Could you and anybody remind me again the reasons why we wanted
nd_assay_phenotype.assay_id to be unique? In other words, we decided
to have a unique row in nd_assay table for each trait (phenotype)?


 I think I really need to group a unique sample (on which multiple
phenotype evaluations are done), so it would be easier if one assay_id
can be linked to multiple phenotype_id.. But I know that we had
reasons not to do this - just can't remember.

The other way around is to link a group of assay_ids into a project_id
or I can make a sample_id (nd_assayprop.type_id) in nd_assayprop
table..

Thanks

Sook

-

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Sook Jung
Thanks Naama,
I somehow wanted to avoid putting all the samples from different
dates/conditions in the stock table but I think I better do it that
way.
By the way I didn't know the name of the table has been changed . Is
that the only change or we better download chado again (from the site
below)?
https://gmod.svn.sourceforge.net/svnroot/gmod/schema/trunk/chado/
Sook

On Wed, Sep 29, 2010 at 11:32 AM, Naama Menda <[hidden email]> wrote:

> hi Sook,
>
> nd_assay is now called nd_experiment (since there is already an assay table
> in the MAGE module)
> I don't remember exactly the reasons for the 1-to-1 relationships between
> experiments and phenotypes or genotypes , but the idea is that each
> phenotyping /genotyping  event is an 'experiment'
>
> in your case, just store a new stock, then store a new nd_experiment each
> time you have a phenotype, and link the 2 using nd_experiment_stock
>
>
> -Naama
>
>
>
> On Wed, Sep 29, 2010 at 2:21 PM, Sook Jung <[hidden email]> wrote:
>>
>> Hi Seth and  Bob,
>>
>> Could you and anybody remind me again the reasons why we wanted
>> nd_assay_phenotype.assay_id to be unique? In other words, we decided
>> to have a unique row in nd_assay table for each trait (phenotype)?
>>
>>
>>  I think I really need to group a unique sample (on which multiple
>> phenotype evaluations are done), so it would be easier if one assay_id
>> can be linked to multiple phenotype_id.. But I know that we had
>> reasons not to do this - just can't remember.
>>
>> The other way around is to link a group of assay_ids into a project_id
>> or I can make a sample_id (nd_assayprop.type_id) in nd_assayprop
>> table..
>>
>> Thanks
>>
>> Sook
>>
>> -
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Gmod-schema mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>



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

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Naama Menda
hi Sook
if you have samples of the same stock you can either use the same stock id and add the metadata about the date/conditions in nd_experiment_stockprop

or store the samples in stock and define those as 'sample of' the parent stock accession in stock_relationship.

I think there have been several changes. If you have an svn checkout you can compare the 2 revisions and see the changes  (svn diff -r M:N)

-Naama


On Wed, Sep 29, 2010 at 4:25 PM, Sook Jung <[hidden email]> wrote:
Thanks Naama,
I somehow wanted to avoid putting all the samples from different
dates/conditions in the stock table but I think I better do it that
way.
By the way I didn't know the name of the table has been changed . Is
that the only change or we better download chado again (from the site
below)?
https://gmod.svn.sourceforge.net/svnroot/gmod/schema/trunk/chado/
Sook

On Wed, Sep 29, 2010 at 11:32 AM, Naama Menda <[hidden email]> wrote:
> hi Sook,
>
> nd_assay is now called nd_experiment (since there is already an assay table
> in the MAGE module)
> I don't remember exactly the reasons for the 1-to-1 relationships between
> experiments and phenotypes or genotypes , but the idea is that each
> phenotyping /genotyping  event is an 'experiment'
>
> in your case, just store a new stock, then store a new nd_experiment each
> time you have a phenotype, and link the 2 using nd_experiment_stock
>
>
> -Naama
>
>
>
> On Wed, Sep 29, 2010 at 2:21 PM, Sook Jung <[hidden email]> wrote:
>>
>> Hi Seth and  Bob,
>>
>> Could you and anybody remind me again the reasons why we wanted
>> nd_assay_phenotype.assay_id to be unique? In other words, we decided
>> to have a unique row in nd_assay table for each trait (phenotype)?
>>
>>
>>  I think I really need to group a unique sample (on which multiple
>> phenotype evaluations are done), so it would be easier if one assay_id
>> can be linked to multiple phenotype_id.. But I know that we had
>> reasons not to do this - just can't remember.
>>
>> The other way around is to link a group of assay_ids into a project_id
>> or I can make a sample_id (nd_assayprop.type_id) in nd_assayprop
>> table..
>>
>> Thanks
>>
>> Sook
>>
>> -
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Gmod-schema mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>



--
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]

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Sook Jung
> or store the samples in stock and define those as 'sample of' the parent
> stock accession in stock_relationship.
Yes this is the way I'm taking since each sample is linked with
distinct phenotypic values

Thanks

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Yuri Bendana-3
Hi Sook and Naama,

I was going to propose this modification because we model an experiment as several phenotype observations on one individual.  Would it be ok to remove the unique constraint on nd_experiment_phenotype.nd_experiment_id?  People could still model the relationship as 1:1 but the database would no longer require it.  Since Chado is a flexible design, I think this approach fits better.

I would also like to propose adding a phenotypeprop table.  This is useful for adding properties like measurement unit and date.

I decided to store the phenotype observation value in a nd_experiment_phenotypeprop table instead of the phenotype table.  This is similar to the nd_experiment_stockprop table.

Let me know if you would like me to check in any of the above changes.

yuri

On Wed, Sep 29, 2010 at 1:40 PM, Sook Jung <[hidden email]> wrote:
> or store the samples in stock and define those as 'sample of' the parent
> stock accession in stock_relationship.
Yes this is the way I'm taking since each sample is linked with
distinct phenotypic values

Thanks

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Naama Menda
hi Yuri,
 the name of the table is nd_experiment , but it does not mean you are storing there your entire experiment, but rather one observation (a phenotype or a genotype).
The entire 'experiment' design can be stored in the project table.

I can't find in the mailing archives the discussion about the 1-1 relationship, so maybe Bob and Seth could reply about this (or maybe Rob remembers? )

As for phenotypeprop, you can use the nd_experimentprop table for storing units and dates. A date is more a property of your measurement event ('nd_experiment' ) rather than property of the phenotype 

Why not use the phenotype table to store the phenotype value? This is exactly what he phenotype table was designed for.

-Naama


On Thu, Sep 30, 2010 at 2:38 AM, Yuri Bendana <[hidden email]> wrote:
Hi Sook and Naama,

I was going to propose this modification because we model an experiment as several phenotype observations on one individual.  Would it be ok to remove the unique constraint on nd_experiment_phenotype.nd_experiment_id?  People could still model the relationship as 1:1 but the database would no longer require it.  Since Chado is a flexible design, I think this approach fits better.

I would also like to propose adding a phenotypeprop table.  This is useful for adding properties like measurement unit and date.

I decided to store the phenotype observation value in a nd_experiment_phenotypeprop table instead of the phenotype table.  This is similar to the nd_experiment_stockprop table.

Let me know if you would like me to check in any of the above changes.

yuri

On Wed, Sep 29, 2010 at 1:40 PM, Sook Jung <[hidden email]> wrote:
> or store the samples in stock and define those as 'sample of' the parent
> stock accession in stock_relationship.
Yes this is the way I'm taking since each sample is linked with
distinct phenotypic values

Thanks

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Bob MacCallum
Hi everyone,

There was some discussion here on this issue, at least w.r.t. genotype:
http://generic-model-organism-system-database.450254.n5.nabble.com/Re-nd-assay-genotype-td1092916.html

It seems that from a strict viewpoint, one assay (nd_experiment)
produces one phenotype (e.g. "bites humans and rests indoors") and
this could be stored in the db in three ways:

1. one-to-many nd_experiment to phenotype, using two phenotype records
2. one-to-one nd_experiment to phenotype, one phenotype record, but
somehow having the two behaviours via phenotype_cvterm
3. as in 2. but with the not-yet-existing phenotypeprop table holding
the two behaviours more adequately
(4. nested phenotypes with a phenotype_relationship table??)

It looks to me like options 1 or 3 are the better ones.  Scott/Dave
there is no documentation for phenotype_cvterm - could this be
migrated to a new phenotypeprop table?

As discussed in the email thread linked above, we want to be able to
describe the constituent parts of a genotype "2LA/+ 2Rbc/bc" somehow.
It looks like this can be done with feature_genotype (it has useful
ordering columns), but we could live with a relaxation of the UNIQUE
constraint on nd_experiment_genotype.nd_experiment_id (or, better,
making it unique on both nd_experiment_id and genotype_id).

hope that helps!
cheers,
Bob/Seth


On Thu, Sep 30, 2010 at 3:58 PM, Naama Menda <[hidden email]> wrote:

> hi Yuri,
>  the name of the table is nd_experiment , but it does not mean you are
> storing there your entire experiment, but rather one observation (a
> phenotype or a genotype).
> The entire 'experiment' design can be stored in the project table.
>
> I can't find in the mailing archives the discussion about the 1-1
> relationship, so maybe Bob and Seth could reply about this (or maybe Rob
> remembers? )
>
> As for phenotypeprop, you can use the nd_experimentprop table for storing
> units and dates. A date is more a property of your measurement event
> ('nd_experiment' ) rather than property of the phenotype
>
> Why not use the phenotype table to store the phenotype value? This is
> exactly what he phenotype table was designed for.
>
> -Naama
>
>
> On Thu, Sep 30, 2010 at 2:38 AM, Yuri Bendana <[hidden email]> wrote:
>>
>> Hi Sook and Naama,
>> I was going to propose this modification because we model an experiment as
>> several phenotype observations on one individual.  Would it be ok to remove
>> the unique constraint on nd_experiment_phenotype.nd_experiment_id?  People
>> could still model the relationship as 1:1 but the database would no longer
>> require it.  Since Chado is a flexible design, I think this approach fits
>> better.
>> I would also like to propose adding a phenotypeprop table.  This is useful
>> for adding properties like measurement unit and date.
>> I decided to store the phenotype observation value in a
>> nd_experiment_phenotypeprop table instead of the phenotype table.  This is
>> similar to the nd_experiment_stockprop table.
>> Let me know if you would like me to check in any of the above changes.
>> yuri
>>
>> On Wed, Sep 29, 2010 at 1:40 PM, Sook Jung <[hidden email]> wrote:
>>>
>>> > or store the samples in stock and define those as 'sample of' the
>>> > parent
>>> > stock accession in stock_relationship.
>>> Yes this is the way I'm taking since each sample is linked with
>>> distinct phenotypic values
>>>
>>> Thanks
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing.
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>> _______________________________________________
>>> Gmod-schema mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>>
>
>

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Sook Jung
Hi All,

I think Bob raised more complex issues - when one experiment gives
rise to two phenotypes.

Yuri and I was talking about when one sample is used for multiple
phenotype evaluations - whether we could link all the phenotype_ids to
one nd_experiment_id or not.

Bu the way, I want to point out that we decided to be able to link
multiple nd_experiment to one phenotype to reduce redundancies in
phenotype table (multiple experiments can have the same results -
multiple apple samples can be 'very juicy'), so  we are talking about
M:1 or M:M.

I think if I store all the individual samples in stock table, I have
no problem with having M:1.
Either way, we may better have phenotypeprop table (though I don't
need it right now for my data). Experiment dates and experimenter are
properties of experiments but units are properties of phenotype..

What I want to suggest is to have stock_geolocation table to keep
track of where the samples are kept (where the trees are planted) - I
could store in nd_experiment.geolocation, but that's really for the
location where the experiment is done (which we do not store) and I'll
have to store the same location multiple times.

Thanks

Sook




On Thu, Sep 30, 2010 at 8:48 AM, Bob MacCallum
<[hidden email]> wrote:

> Hi everyone,
>
> There was some discussion here on this issue, at least w.r.t. genotype:
> http://generic-model-organism-system-database.450254.n5.nabble.com/Re-nd-assay-genotype-td1092916.html
>
> It seems that from a strict viewpoint, one assay (nd_experiment)
> produces one phenotype (e.g. "bites humans and rests indoors") and
> this could be stored in the db in three ways:
>
> 1. one-to-many nd_experiment to phenotype, using two phenotype records
> 2. one-to-one nd_experiment to phenotype, one phenotype record, but
> somehow having the two behaviours via phenotype_cvterm
> 3. as in 2. but with the not-yet-existing phenotypeprop table holding
> the two behaviours more adequately
> (4. nested phenotypes with a phenotype_relationship table??)
>
> It looks to me like options 1 or 3 are the better ones.  Scott/Dave
> there is no documentation for phenotype_cvterm - could this be
> migrated to a new phenotypeprop table?
>
> As discussed in the email thread linked above, we want to be able to
> describe the constituent parts of a genotype "2LA/+ 2Rbc/bc" somehow.
> It looks like this can be done with feature_genotype (it has useful
> ordering columns), but we could live with a relaxation of the UNIQUE
> constraint on nd_experiment_genotype.nd_experiment_id (or, better,
> making it unique on both nd_experiment_id and genotype_id).
>
> hope that helps!
> cheers,
> Bob/Seth
>
>
> On Thu, Sep 30, 2010 at 3:58 PM, Naama Menda <[hidden email]> wrote:
>> hi Yuri,
>>  the name of the table is nd_experiment , but it does not mean you are
>> storing there your entire experiment, but rather one observation (a
>> phenotype or a genotype).
>> The entire 'experiment' design can be stored in the project table.
>>
>> I can't find in the mailing archives the discussion about the 1-1
>> relationship, so maybe Bob and Seth could reply about this (or maybe Rob
>> remembers? )
>>
>> As for phenotypeprop, you can use the nd_experimentprop table for storing
>> units and dates. A date is more a property of your measurement event
>> ('nd_experiment' ) rather than property of the phenotype
>>
>> Why not use the phenotype table to store the phenotype value? This is
>> exactly what he phenotype table was designed for.
>>
>> -Naama
>>
>>
>> On Thu, Sep 30, 2010 at 2:38 AM, Yuri Bendana <[hidden email]> wrote:
>>>
>>> Hi Sook and Naama,
>>> I was going to propose this modification because we model an experiment as
>>> several phenotype observations on one individual.  Would it be ok to remove
>>> the unique constraint on nd_experiment_phenotype.nd_experiment_id?  People
>>> could still model the relationship as 1:1 but the database would no longer
>>> require it.  Since Chado is a flexible design, I think this approach fits
>>> better.
>>> I would also like to propose adding a phenotypeprop table.  This is useful
>>> for adding properties like measurement unit and date.
>>> I decided to store the phenotype observation value in a
>>> nd_experiment_phenotypeprop table instead of the phenotype table.  This is
>>> similar to the nd_experiment_stockprop table.
>>> Let me know if you would like me to check in any of the above changes.
>>> yuri
>>>
>>> On Wed, Sep 29, 2010 at 1:40 PM, Sook Jung <[hidden email]> wrote:
>>>>
>>>> > or store the samples in stock and define those as 'sample of' the
>>>> > parent
>>>> > stock accession in stock_relationship.
>>>> Yes this is the way I'm taking since each sample is linked with
>>>> distinct phenotypic values
>>>>
>>>> Thanks
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Start uncovering the many advantages of virtual appliances
>>>> and start using them to simplify application deployment and
>>>> accelerate your shift to cloud computing.
>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>> _______________________________________________
>>>> Gmod-schema mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>>>
>>
>>
>



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

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Naama Menda
Regarding unit, for most of our terms the unit of measurement is part of the cvterm, which is the only way you can compare phenotypes. If you measure fruit length in cm and then in mm in another experiment, you'll have to bring all measurements to the same unit, which requires another level of complexity in your software (but it is possible to do if necessary) .

Sook, regarding stock_geolocation this can be a problem. If your stock was assayed in 4 locations, how would you know which location refers to which experiment? Yes, there's redundancy in storing geolocation of each nd_experiment, (especially with trees... I guess you don't have many plots with the same tree accession across locations ), but it is the geolocation for your 'experiment' and not of the stock (a stock can be a bunch of seeds waiting for someone to plant somewhere in the future)

-Naama



On Thu, Sep 30, 2010 at 12:29 PM, Sook Jung <[hidden email]> wrote:
Hi All,

I think Bob raised more complex issues - when one experiment gives
rise to two phenotypes.

Yuri and I was talking about when one sample is used for multiple
phenotype evaluations - whether we could link all the phenotype_ids to
one nd_experiment_id or not.

Bu the way, I want to point out that we decided to be able to link
multiple nd_experiment to one phenotype to reduce redundancies in
phenotype table (multiple experiments can have the same results -
multiple apple samples can be 'very juicy'), so  we are talking about
M:1 or M:M.

I think if I store all the individual samples in stock table, I have
no problem with having M:1.
Either way, we may better have phenotypeprop table (though I don't
need it right now for my data). Experiment dates and experimenter are
properties of experiments but units are properties of phenotype..

What I want to suggest is to have stock_geolocation table to keep
track of where the samples are kept (where the trees are planted) - I
could store in nd_experiment.geolocation, but that's really for the
location where the experiment is done (which we do not store) and I'll
have to store the same location multiple times.

Thanks

Sook




On Thu, Sep 30, 2010 at 8:48 AM, Bob MacCallum
<[hidden email]> wrote:
> Hi everyone,
>
> There was some discussion here on this issue, at least w.r.t. genotype:
> http://generic-model-organism-system-database.450254.n5.nabble.com/Re-nd-assay-genotype-td1092916.html
>
> It seems that from a strict viewpoint, one assay (nd_experiment)
> produces one phenotype (e.g. "bites humans and rests indoors") and
> this could be stored in the db in three ways:
>
> 1. one-to-many nd_experiment to phenotype, using two phenotype records
> 2. one-to-one nd_experiment to phenotype, one phenotype record, but
> somehow having the two behaviours via phenotype_cvterm
> 3. as in 2. but with the not-yet-existing phenotypeprop table holding
> the two behaviours more adequately
> (4. nested phenotypes with a phenotype_relationship table??)
>
> It looks to me like options 1 or 3 are the better ones.  Scott/Dave
> there is no documentation for phenotype_cvterm - could this be
> migrated to a new phenotypeprop table?
>
> As discussed in the email thread linked above, we want to be able to
> describe the constituent parts of a genotype "2LA/+ 2Rbc/bc" somehow.
> It looks like this can be done with feature_genotype (it has useful
> ordering columns), but we could live with a relaxation of the UNIQUE
> constraint on nd_experiment_genotype.nd_experiment_id (or, better,
> making it unique on both nd_experiment_id and genotype_id).
>
> hope that helps!
> cheers,
> Bob/Seth
>
>
> On Thu, Sep 30, 2010 at 3:58 PM, Naama Menda <[hidden email]> wrote:
>> hi Yuri,
>>  the name of the table is nd_experiment , but it does not mean you are
>> storing there your entire experiment, but rather one observation (a
>> phenotype or a genotype).
>> The entire 'experiment' design can be stored in the project table.
>>
>> I can't find in the mailing archives the discussion about the 1-1
>> relationship, so maybe Bob and Seth could reply about this (or maybe Rob
>> remembers? )
>>
>> As for phenotypeprop, you can use the nd_experimentprop table for storing
>> units and dates. A date is more a property of your measurement event
>> ('nd_experiment' ) rather than property of the phenotype
>>
>> Why not use the phenotype table to store the phenotype value? This is
>> exactly what he phenotype table was designed for.
>>
>> -Naama
>>
>>
>> On Thu, Sep 30, 2010 at 2:38 AM, Yuri Bendana <[hidden email]> wrote:
>>>
>>> Hi Sook and Naama,
>>> I was going to propose this modification because we model an experiment as
>>> several phenotype observations on one individual.  Would it be ok to remove
>>> the unique constraint on nd_experiment_phenotype.nd_experiment_id?  People
>>> could still model the relationship as 1:1 but the database would no longer
>>> require it.  Since Chado is a flexible design, I think this approach fits
>>> better.
>>> I would also like to propose adding a phenotypeprop table.  This is useful
>>> for adding properties like measurement unit and date.
>>> I decided to store the phenotype observation value in a
>>> nd_experiment_phenotypeprop table instead of the phenotype table.  This is
>>> similar to the nd_experiment_stockprop table.
>>> Let me know if you would like me to check in any of the above changes.
>>> yuri
>>>
>>> On Wed, Sep 29, 2010 at 1:40 PM, Sook Jung <[hidden email]> wrote:
>>>>
>>>> > or store the samples in stock and define those as 'sample of' the
>>>> > parent
>>>> > stock accession in stock_relationship.
>>>> Yes this is the way I'm taking since each sample is linked with
>>>> distinct phenotypic values
>>>>
>>>> Thanks
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Start uncovering the many advantages of virtual appliances
>>>> and start using them to simplify application deployment and
>>>> accelerate your shift to cloud computing.
>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>> _______________________________________________
>>>> Gmod-schema mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>>>
>>
>>
>



--
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]


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Sook Jung
Hi Naama,

I wouldn't store geolocation for a stock with a distinct genotype. We
need to stock_geolocation since we now store 'samples' in the stock
table. So for the trees that are rooted in one spot, and for the seeds
that are planted in one spot - for those we have a single location.

Remember now the stock table can store from population down to single
sample for phenotypic experiments.


Sook


On Thu, Sep 30, 2010 at 9:48 AM, Naama Menda <[hidden email]> wrote:

> Regarding unit, for most of our terms the unit of measurement is part of the
> cvterm, which is the only way you can compare phenotypes. If you measure
> fruit length in cm and then in mm in another experiment, you'll have to
> bring all measurements to the same unit, which requires another level of
> complexity in your software (but it is possible to do if necessary) .
>
> Sook, regarding stock_geolocation this can be a problem. If your stock was
> assayed in 4 locations, how would you know which location refers to which
> experiment? Yes, there's redundancy in storing geolocation of each
> nd_experiment, (especially with trees... I guess you don't have many plots
> with the same tree accession across locations ), but it is the geolocation
> for your 'experiment' and not of the stock (a stock can be a bunch of seeds
> waiting for someone to plant somewhere in the future)
>
> -Naama
>
>
>
> On Thu, Sep 30, 2010 at 12:29 PM, Sook Jung <[hidden email]> wrote:
>>
>> Hi All,
>>
>> I think Bob raised more complex issues - when one experiment gives
>> rise to two phenotypes.
>>
>> Yuri and I was talking about when one sample is used for multiple
>> phenotype evaluations - whether we could link all the phenotype_ids to
>> one nd_experiment_id or not.
>>
>> Bu the way, I want to point out that we decided to be able to link
>> multiple nd_experiment to one phenotype to reduce redundancies in
>> phenotype table (multiple experiments can have the same results -
>> multiple apple samples can be 'very juicy'), so  we are talking about
>> M:1 or M:M.
>>
>> I think if I store all the individual samples in stock table, I have
>> no problem with having M:1.
>> Either way, we may better have phenotypeprop table (though I don't
>> need it right now for my data). Experiment dates and experimenter are
>> properties of experiments but units are properties of phenotype..
>>
>> What I want to suggest is to have stock_geolocation table to keep
>> track of where the samples are kept (where the trees are planted) - I
>> could store in nd_experiment.geolocation, but that's really for the
>> location where the experiment is done (which we do not store) and I'll
>> have to store the same location multiple times.
>>
>> Thanks
>>
>> Sook
>>
>>
>>
>>
>> On Thu, Sep 30, 2010 at 8:48 AM, Bob MacCallum
>> <[hidden email]> wrote:
>> > Hi everyone,
>> >
>> > There was some discussion here on this issue, at least w.r.t. genotype:
>> >
>> > http://generic-model-organism-system-database.450254.n5.nabble.com/Re-nd-assay-genotype-td1092916.html
>> >
>> > It seems that from a strict viewpoint, one assay (nd_experiment)
>> > produces one phenotype (e.g. "bites humans and rests indoors") and
>> > this could be stored in the db in three ways:
>> >
>> > 1. one-to-many nd_experiment to phenotype, using two phenotype records
>> > 2. one-to-one nd_experiment to phenotype, one phenotype record, but
>> > somehow having the two behaviours via phenotype_cvterm
>> > 3. as in 2. but with the not-yet-existing phenotypeprop table holding
>> > the two behaviours more adequately
>> > (4. nested phenotypes with a phenotype_relationship table??)
>> >
>> > It looks to me like options 1 or 3 are the better ones.  Scott/Dave
>> > there is no documentation for phenotype_cvterm - could this be
>> > migrated to a new phenotypeprop table?
>> >
>> > As discussed in the email thread linked above, we want to be able to
>> > describe the constituent parts of a genotype "2LA/+ 2Rbc/bc" somehow.
>> > It looks like this can be done with feature_genotype (it has useful
>> > ordering columns), but we could live with a relaxation of the UNIQUE
>> > constraint on nd_experiment_genotype.nd_experiment_id (or, better,
>> > making it unique on both nd_experiment_id and genotype_id).
>> >
>> > hope that helps!
>> > cheers,
>> > Bob/Seth
>> >
>> >
>> > On Thu, Sep 30, 2010 at 3:58 PM, Naama Menda <[hidden email]> wrote:
>> >> hi Yuri,
>> >>  the name of the table is nd_experiment , but it does not mean you are
>> >> storing there your entire experiment, but rather one observation (a
>> >> phenotype or a genotype).
>> >> The entire 'experiment' design can be stored in the project table.
>> >>
>> >> I can't find in the mailing archives the discussion about the 1-1
>> >> relationship, so maybe Bob and Seth could reply about this (or maybe
>> >> Rob
>> >> remembers? )
>> >>
>> >> As for phenotypeprop, you can use the nd_experimentprop table for
>> >> storing
>> >> units and dates. A date is more a property of your measurement event
>> >> ('nd_experiment' ) rather than property of the phenotype
>> >>
>> >> Why not use the phenotype table to store the phenotype value? This is
>> >> exactly what he phenotype table was designed for.
>> >>
>> >> -Naama
>> >>
>> >>
>> >> On Thu, Sep 30, 2010 at 2:38 AM, Yuri Bendana <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Hi Sook and Naama,
>> >>> I was going to propose this modification because we model an
>> >>> experiment as
>> >>> several phenotype observations on one individual.  Would it be ok to
>> >>> remove
>> >>> the unique constraint on nd_experiment_phenotype.nd_experiment_id?
>> >>>  People
>> >>> could still model the relationship as 1:1 but the database would no
>> >>> longer
>> >>> require it.  Since Chado is a flexible design, I think this approach
>> >>> fits
>> >>> better.
>> >>> I would also like to propose adding a phenotypeprop table.  This is
>> >>> useful
>> >>> for adding properties like measurement unit and date.
>> >>> I decided to store the phenotype observation value in a
>> >>> nd_experiment_phenotypeprop table instead of the phenotype table.
>> >>>  This is
>> >>> similar to the nd_experiment_stockprop table.
>> >>> Let me know if you would like me to check in any of the above changes.
>> >>> yuri
>> >>>
>> >>> On Wed, Sep 29, 2010 at 1:40 PM, Sook Jung <[hidden email]> wrote:
>> >>>>
>> >>>> > or store the samples in stock and define those as 'sample of' the
>> >>>> > parent
>> >>>> > stock accession in stock_relationship.
>> >>>> Yes this is the way I'm taking since each sample is linked with
>> >>>> distinct phenotypic values
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> Start uncovering the many advantages of virtual appliances
>> >>>> and start using them to simplify application deployment and
>> >>>> accelerate your shift to cloud computing.
>> >>>> http://p.sf.net/sfu/novell-sfdev2dev
>> >>>> _______________________________________________
>> >>>> Gmod-schema mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>> >>>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Sook Jung, PhD
>> Assistant Research Professor of Bioinformatics
>> Dept of Horticulture and Landscape Architecture
>> Washington State University
>> 45 Johnson Hall, Pullman, WA 99164-6414
>> Email:[hidden email]
>
>



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

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Naama Menda
hi Sook,
that's fine, but remember you have a geolocation_id in nd_experiment too.
I guess it's ok to store geolocation id for a stock of type = 'sample' or 'field plot number' which are unique per field experiment, but how would you enforce storing stock_goelocation only for the single-used stocks ?
In terms of database space , it won't save much , since you have the geolocation_id column in nd_experiment.

-Naama


On Thu, Sep 30, 2010 at 1:03 PM, Sook Jung <[hidden email]> wrote:
Hi Naama,

I wouldn't store geolocation for a stock with a distinct genotype. We
need to stock_geolocation since we now store 'samples' in the stock
table. So for the trees that are rooted in one spot, and for the seeds
that are planted in one spot - for those we have a single location.

Remember now the stock table can store from population down to single
sample for phenotypic experiments.


Sook


On Thu, Sep 30, 2010 at 9:48 AM, Naama Menda <[hidden email]> wrote:
> Regarding unit, for most of our terms the unit of measurement is part of the
> cvterm, which is the only way you can compare phenotypes. If you measure
> fruit length in cm and then in mm in another experiment, you'll have to
> bring all measurements to the same unit, which requires another level of
> complexity in your software (but it is possible to do if necessary) .
>
> Sook, regarding stock_geolocation this can be a problem. If your stock was
> assayed in 4 locations, how would you know which location refers to which
> experiment? Yes, there's redundancy in storing geolocation of each
> nd_experiment, (especially with trees... I guess you don't have many plots
> with the same tree accession across locations ), but it is the geolocation
> for your 'experiment' and not of the stock (a stock can be a bunch of seeds
> waiting for someone to plant somewhere in the future)
>
> -Naama
>
>
>
> On Thu, Sep 30, 2010 at 12:29 PM, Sook Jung <[hidden email]> wrote:
>>
>> Hi All,
>>
>> I think Bob raised more complex issues - when one experiment gives
>> rise to two phenotypes.
>>
>> Yuri and I was talking about when one sample is used for multiple
>> phenotype evaluations - whether we could link all the phenotype_ids to
>> one nd_experiment_id or not.
>>
>> Bu the way, I want to point out that we decided to be able to link
>> multiple nd_experiment to one phenotype to reduce redundancies in
>> phenotype table (multiple experiments can have the same results -
>> multiple apple samples can be 'very juicy'), so  we are talking about
>> M:1 or M:M.
>>
>> I think if I store all the individual samples in stock table, I have
>> no problem with having M:1.
>> Either way, we may better have phenotypeprop table (though I don't
>> need it right now for my data). Experiment dates and experimenter are
>> properties of experiments but units are properties of phenotype..
>>
>> What I want to suggest is to have stock_geolocation table to keep
>> track of where the samples are kept (where the trees are planted) - I
>> could store in nd_experiment.geolocation, but that's really for the
>> location where the experiment is done (which we do not store) and I'll
>> have to store the same location multiple times.
>>
>> Thanks
>>
>> Sook
>>
>>
>>
>>
>> On Thu, Sep 30, 2010 at 8:48 AM, Bob MacCallum
>> <[hidden email]> wrote:
>> > Hi everyone,
>> >
>> > There was some discussion here on this issue, at least w.r.t. genotype:
>> >
>> > http://generic-model-organism-system-database.450254.n5.nabble.com/Re-nd-assay-genotype-td1092916.html
>> >
>> > It seems that from a strict viewpoint, one assay (nd_experiment)
>> > produces one phenotype (e.g. "bites humans and rests indoors") and
>> > this could be stored in the db in three ways:
>> >
>> > 1. one-to-many nd_experiment to phenotype, using two phenotype records
>> > 2. one-to-one nd_experiment to phenotype, one phenotype record, but
>> > somehow having the two behaviours via phenotype_cvterm
>> > 3. as in 2. but with the not-yet-existing phenotypeprop table holding
>> > the two behaviours more adequately
>> > (4. nested phenotypes with a phenotype_relationship table??)
>> >
>> > It looks to me like options 1 or 3 are the better ones.  Scott/Dave
>> > there is no documentation for phenotype_cvterm - could this be
>> > migrated to a new phenotypeprop table?
>> >
>> > As discussed in the email thread linked above, we want to be able to
>> > describe the constituent parts of a genotype "2LA/+ 2Rbc/bc" somehow.
>> > It looks like this can be done with feature_genotype (it has useful
>> > ordering columns), but we could live with a relaxation of the UNIQUE
>> > constraint on nd_experiment_genotype.nd_experiment_id (or, better,
>> > making it unique on both nd_experiment_id and genotype_id).
>> >
>> > hope that helps!
>> > cheers,
>> > Bob/Seth
>> >
>> >
>> > On Thu, Sep 30, 2010 at 3:58 PM, Naama Menda <[hidden email]> wrote:
>> >> hi Yuri,
>> >>  the name of the table is nd_experiment , but it does not mean you are
>> >> storing there your entire experiment, but rather one observation (a
>> >> phenotype or a genotype).
>> >> The entire 'experiment' design can be stored in the project table.
>> >>
>> >> I can't find in the mailing archives the discussion about the 1-1
>> >> relationship, so maybe Bob and Seth could reply about this (or maybe
>> >> Rob
>> >> remembers? )
>> >>
>> >> As for phenotypeprop, you can use the nd_experimentprop table for
>> >> storing
>> >> units and dates. A date is more a property of your measurement event
>> >> ('nd_experiment' ) rather than property of the phenotype
>> >>
>> >> Why not use the phenotype table to store the phenotype value? This is
>> >> exactly what he phenotype table was designed for.
>> >>
>> >> -Naama
>> >>
>> >>
>> >> On Thu, Sep 30, 2010 at 2:38 AM, Yuri Bendana <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Hi Sook and Naama,
>> >>> I was going to propose this modification because we model an
>> >>> experiment as
>> >>> several phenotype observations on one individual.  Would it be ok to
>> >>> remove
>> >>> the unique constraint on nd_experiment_phenotype.nd_experiment_id?
>> >>>  People
>> >>> could still model the relationship as 1:1 but the database would no
>> >>> longer
>> >>> require it.  Since Chado is a flexible design, I think this approach
>> >>> fits
>> >>> better.
>> >>> I would also like to propose adding a phenotypeprop table.  This is
>> >>> useful
>> >>> for adding properties like measurement unit and date.
>> >>> I decided to store the phenotype observation value in a
>> >>> nd_experiment_phenotypeprop table instead of the phenotype table.
>> >>>  This is
>> >>> similar to the nd_experiment_stockprop table.
>> >>> Let me know if you would like me to check in any of the above changes.
>> >>> yuri
>> >>>
>> >>> On Wed, Sep 29, 2010 at 1:40 PM, Sook Jung <[hidden email]> wrote:
>> >>>>
>> >>>> > or store the samples in stock and define those as 'sample of' the
>> >>>> > parent
>> >>>> > stock accession in stock_relationship.
>> >>>> Yes this is the way I'm taking since each sample is linked with
>> >>>> distinct phenotypic values
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> Start uncovering the many advantages of virtual appliances
>> >>>> and start using them to simplify application deployment and
>> >>>> accelerate your shift to cloud computing.
>> >>>> http://p.sf.net/sfu/novell-sfdev2dev
>> >>>> _______________________________________________
>> >>>> Gmod-schema mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>> >>>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> 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]
>
>



--
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]

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Sook Jung
In reply to this post by Sook Jung
If it's not a good practice of chado (?) to have a linking table when
it doesn't apply to all the rows of the table, I think we can just add
site_id in stockprop table and link to nd_geolocation.
Sook

On Thu, Sep 30, 2010 at 10:03 AM, Sook Jung <[hidden email]> wrote:

> Hi Naama,
>
> I wouldn't store geolocation for a stock with a distinct genotype. We
> need to stock_geolocation since we now store 'samples' in the stock
> table. So for the trees that are rooted in one spot, and for the seeds
> that are planted in one spot - for those we have a single location.
>
> Remember now the stock table can store from population down to single
> sample for phenotypic experiments.
>
>
> Sook
>
>
> On Thu, Sep 30, 2010 at 9:48 AM, Naama Menda <[hidden email]> wrote:
>> Regarding unit, for most of our terms the unit of measurement is part of the
>> cvterm, which is the only way you can compare phenotypes. If you measure
>> fruit length in cm and then in mm in another experiment, you'll have to
>> bring all measurements to the same unit, which requires another level of
>> complexity in your software (but it is possible to do if necessary) .
>>
>> Sook, regarding stock_geolocation this can be a problem. If your stock was
>> assayed in 4 locations, how would you know which location refers to which
>> experiment? Yes, there's redundancy in storing geolocation of each
>> nd_experiment, (especially with trees... I guess you don't have many plots
>> with the same tree accession across locations ), but it is the geolocation
>> for your 'experiment' and not of the stock (a stock can be a bunch of seeds
>> waiting for someone to plant somewhere in the future)
>>
>> -Naama
>>
>>
>>
>> On Thu, Sep 30, 2010 at 12:29 PM, Sook Jung <[hidden email]> wrote:
>>>
>>> Hi All,
>>>
>>> I think Bob raised more complex issues - when one experiment gives
>>> rise to two phenotypes.
>>>
>>> Yuri and I was talking about when one sample is used for multiple
>>> phenotype evaluations - whether we could link all the phenotype_ids to
>>> one nd_experiment_id or not.
>>>
>>> Bu the way, I want to point out that we decided to be able to link
>>> multiple nd_experiment to one phenotype to reduce redundancies in
>>> phenotype table (multiple experiments can have the same results -
>>> multiple apple samples can be 'very juicy'), so  we are talking about
>>> M:1 or M:M.
>>>
>>> I think if I store all the individual samples in stock table, I have
>>> no problem with having M:1.
>>> Either way, we may better have phenotypeprop table (though I don't
>>> need it right now for my data). Experiment dates and experimenter are
>>> properties of experiments but units are properties of phenotype..
>>>
>>> What I want to suggest is to have stock_geolocation table to keep
>>> track of where the samples are kept (where the trees are planted) - I
>>> could store in nd_experiment.geolocation, but that's really for the
>>> location where the experiment is done (which we do not store) and I'll
>>> have to store the same location multiple times.
>>>
>>> Thanks
>>>
>>> Sook
>>>
>>>
>>>
>>>
>>> On Thu, Sep 30, 2010 at 8:48 AM, Bob MacCallum
>>> <[hidden email]> wrote:
>>> > Hi everyone,
>>> >
>>> > There was some discussion here on this issue, at least w.r.t. genotype:
>>> >
>>> > http://generic-model-organism-system-database.450254.n5.nabble.com/Re-nd-assay-genotype-td1092916.html
>>> >
>>> > It seems that from a strict viewpoint, one assay (nd_experiment)
>>> > produces one phenotype (e.g. "bites humans and rests indoors") and
>>> > this could be stored in the db in three ways:
>>> >
>>> > 1. one-to-many nd_experiment to phenotype, using two phenotype records
>>> > 2. one-to-one nd_experiment to phenotype, one phenotype record, but
>>> > somehow having the two behaviours via phenotype_cvterm
>>> > 3. as in 2. but with the not-yet-existing phenotypeprop table holding
>>> > the two behaviours more adequately
>>> > (4. nested phenotypes with a phenotype_relationship table??)
>>> >
>>> > It looks to me like options 1 or 3 are the better ones.  Scott/Dave
>>> > there is no documentation for phenotype_cvterm - could this be
>>> > migrated to a new phenotypeprop table?
>>> >
>>> > As discussed in the email thread linked above, we want to be able to
>>> > describe the constituent parts of a genotype "2LA/+ 2Rbc/bc" somehow.
>>> > It looks like this can be done with feature_genotype (it has useful
>>> > ordering columns), but we could live with a relaxation of the UNIQUE
>>> > constraint on nd_experiment_genotype.nd_experiment_id (or, better,
>>> > making it unique on both nd_experiment_id and genotype_id).
>>> >
>>> > hope that helps!
>>> > cheers,
>>> > Bob/Seth
>>> >
>>> >
>>> > On Thu, Sep 30, 2010 at 3:58 PM, Naama Menda <[hidden email]> wrote:
>>> >> hi Yuri,
>>> >>  the name of the table is nd_experiment , but it does not mean you are
>>> >> storing there your entire experiment, but rather one observation (a
>>> >> phenotype or a genotype).
>>> >> The entire 'experiment' design can be stored in the project table.
>>> >>
>>> >> I can't find in the mailing archives the discussion about the 1-1
>>> >> relationship, so maybe Bob and Seth could reply about this (or maybe
>>> >> Rob
>>> >> remembers? )
>>> >>
>>> >> As for phenotypeprop, you can use the nd_experimentprop table for
>>> >> storing
>>> >> units and dates. A date is more a property of your measurement event
>>> >> ('nd_experiment' ) rather than property of the phenotype
>>> >>
>>> >> Why not use the phenotype table to store the phenotype value? This is
>>> >> exactly what he phenotype table was designed for.
>>> >>
>>> >> -Naama
>>> >>
>>> >>
>>> >> On Thu, Sep 30, 2010 at 2:38 AM, Yuri Bendana <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> Hi Sook and Naama,
>>> >>> I was going to propose this modification because we model an
>>> >>> experiment as
>>> >>> several phenotype observations on one individual.  Would it be ok to
>>> >>> remove
>>> >>> the unique constraint on nd_experiment_phenotype.nd_experiment_id?
>>> >>>  People
>>> >>> could still model the relationship as 1:1 but the database would no
>>> >>> longer
>>> >>> require it.  Since Chado is a flexible design, I think this approach
>>> >>> fits
>>> >>> better.
>>> >>> I would also like to propose adding a phenotypeprop table.  This is
>>> >>> useful
>>> >>> for adding properties like measurement unit and date.
>>> >>> I decided to store the phenotype observation value in a
>>> >>> nd_experiment_phenotypeprop table instead of the phenotype table.
>>> >>>  This is
>>> >>> similar to the nd_experiment_stockprop table.
>>> >>> Let me know if you would like me to check in any of the above changes.
>>> >>> yuri
>>> >>>
>>> >>> On Wed, Sep 29, 2010 at 1:40 PM, Sook Jung <[hidden email]> wrote:
>>> >>>>
>>> >>>> > or store the samples in stock and define those as 'sample of' the
>>> >>>> > parent
>>> >>>> > stock accession in stock_relationship.
>>> >>>> Yes this is the way I'm taking since each sample is linked with
>>> >>>> distinct phenotypic values
>>> >>>>
>>> >>>> Thanks
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> ------------------------------------------------------------------------------
>>> >>>> Start uncovering the many advantages of virtual appliances
>>> >>>> and start using them to simplify application deployment and
>>> >>>> accelerate your shift to cloud computing.
>>> >>>> http://p.sf.net/sfu/novell-sfdev2dev
>>> >>>> _______________________________________________
>>> >>>> Gmod-schema mailing list
>>> >>>> [hidden email]
>>> >>>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Sook Jung, PhD
>>> Assistant Research Professor of Bioinformatics
>>> Dept of Horticulture and Landscape Architecture
>>> Washington State University
>>> 45 Johnson Hall, Pullman, WA 99164-6414
>>> Email:[hidden email]
>>
>>
>
>
>
> --
> Sook Jung, PhD
> Assistant Research Professor of Bioinformatics
> Dept of Horticulture and Landscape Architecture
> Washington State University
> 45 Johnson Hall, Pullman, WA 99164-6414
> Email:[hidden email]
>



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

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Yuri Bendana-3
In reply to this post by Naama Menda
Hi Naama,

Yes, I know that an 'experiment' has been defined in the NatDiv module as 1:1 for a phenotype but for us it made more sense to model it as 1:M.  Removing the UNIQUE constraint on nd_experiment_phenotype.nd_experiment_id allowed us to do this and it's a relatively minor change.  In any case, it sounds like Bob agrees that removing the UNIQUE constraint also covers cases where an experiment as defined by NatDiv is linked to 2 phenotypes.

We also use the project table to group experiments done on a collection of individuals under similar environmental conditions.  The relationship between experiment and individual is still 1:1.  But by having the experiment:phenotype relationship be 1:M we reduce some data duplication.

On Thu, Sep 30, 2010 at 7:58 AM, Naama Menda <[hidden email]> wrote:
hi Yuri,
 the name of the table is nd_experiment , but it does not mean you are storing there your entire experiment, but rather one observation (a phenotype or a genotype).
The entire 'experiment' design can be stored in the project table.

 
At first I was using nd_experimentprop for measurement units and dates.  But as I learned more about the phenotype EQ model as described in Chris Mungall's article cited on the Phenote home page (http://genomebiology.com/2010/11/1/R2/), I came to see the measurement unit and date as 'modifiers' or 'qualities' of the phenotypic statement.  This is touched on briefly in that article and is also described on the 'pheno-syntax' page (which was at http://www.fruitfly.org/~cjm/obd/pheno-syntax.html but recently is not accessible). The pheno-syntax is used by Phenote for describing phenotypic statements.  One of Phenote's templates has input entries for the temporal modifier and unit modifier as well as other modifiers or qualities.

So, I'm using the phenotype and phenotypeprop tables to store the complete phenotypic statement (eg, "flower length at harvest date in_units_of mm").  Rather than duplicate the same phenotype information for each observation I decided to put the observation in a nd_experiment_phenotypeprop table.  I thought about creating a phenotypeobservation or phenotypemeasurement table but the nd_experiment_phenotypeprop table is more generic and may be useful for other phenotype properties that are specific to an experiment.

yuri


As for phenotypeprop, you can use the nd_experimentprop table for storing units and dates. A date is more a property of your measurement event ('nd_experiment' ) rather than property of the phenotype 

Why not use the phenotype table to store the phenotype value? This is exactly what he phenotype table was designed for.

-Naama



On Thu, Sep 30, 2010 at 2:38 AM, Yuri Bendana <[hidden email]> wrote:
Hi Sook and Naama,

I was going to propose this modification because we model an experiment as several phenotype observations on one individual.  Would it be ok to remove the unique constraint on nd_experiment_phenotype.nd_experiment_id?  People could still model the relationship as 1:1 but the database would no longer require it.  Since Chado is a flexible design, I think this approach fits better.

I would also like to propose adding a phenotypeprop table.  This is useful for adding properties like measurement unit and date.

I decided to store the phenotype observation value in a nd_experiment_phenotypeprop table instead of the phenotype table.  This is similar to the nd_experiment_stockprop table.

Let me know if you would like me to check in any of the above changes.

yuri

On Wed, Sep 29, 2010 at 1:40 PM, Sook Jung <[hidden email]> wrote:
> or store the samples in stock and define those as 'sample of' the parent
> stock accession in stock_relationship.
Yes this is the way I'm taking since each sample is linked with
distinct phenotypic values

Thanks

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: nd_assay_phenotype

Naama Menda
ok, does anyone have an objection for removing the 1:1 unique constraint from nd_experiment_phenotype and nd_experiment_genotype?
I really don't remember the reason for this.

Not sure if phenptypeprop should be in the phenotype module or in the ND module. It may be better to have it in the phenotype module, to make it useful for other modules linking to phenotype. Hope does Flybase store the phenotype modifiers ?

-Naama



On Thu, Sep 30, 2010 at 7:40 PM, Yuri Bendana <[hidden email]> wrote:
Hi Naama,

Yes, I know that an 'experiment' has been defined in the NatDiv module as 1:1 for a phenotype but for us it made more sense to model it as 1:M.  Removing the UNIQUE constraint on nd_experiment_phenotype.nd_experiment_id allowed us to do this and it's a relatively minor change.  In any case, it sounds like Bob agrees that removing the UNIQUE constraint also covers cases where an experiment as defined by NatDiv is linked to 2 phenotypes.

We also use the project table to group experiments done on a collection of individuals under similar environmental conditions.  The relationship between experiment and individual is still 1:1.  But by having the experiment:phenotype relationship be 1:M we reduce some data duplication.

On Thu, Sep 30, 2010 at 7:58 AM, Naama Menda <[hidden email]> wrote:
hi Yuri,
 the name of the table is nd_experiment , but it does not mean you are storing there your entire experiment, but rather one observation (a phenotype or a genotype).
The entire 'experiment' design can be stored in the project table.

 
At first I was using nd_experimentprop for measurement units and dates.  But as I learned more about the phenotype EQ model as described in Chris Mungall's article cited on the Phenote home page (http://genomebiology.com/2010/11/1/R2/), I came to see the measurement unit and date as 'modifiers' or 'qualities' of the phenotypic statement.  This is touched on briefly in that article and is also described on the 'pheno-syntax' page (which was at http://www.fruitfly.org/~cjm/obd/pheno-syntax.html but recently is not accessible). The pheno-syntax is used by Phenote for describing phenotypic statements.  One of Phenote's templates has input entries for the temporal modifier and unit modifier as well as other modifiers or qualities.

So, I'm using the phenotype and phenotypeprop tables to store the complete phenotypic statement (eg, "flower length at harvest date in_units_of mm").  Rather than duplicate the same phenotype information for each observation I decided to put the observation in a nd_experiment_phenotypeprop table.  I thought about creating a phenotypeobservation or phenotypemeasurement table but the nd_experiment_phenotypeprop table is more generic and may be useful for other phenotype properties that are specific to an experiment.

yuri


As for phenotypeprop, you can use the nd_experimentprop table for storing units and dates. A date is more a property of your measurement event ('nd_experiment' ) rather than property of the phenotype 

Why not use the phenotype table to store the phenotype value? This is exactly what he phenotype table was designed for.

-Naama



On Thu, Sep 30, 2010 at 2:38 AM, Yuri Bendana <[hidden email]> wrote:
Hi Sook and Naama,

I was going to propose this modification because we model an experiment as several phenotype observations on one individual.  Would it be ok to remove the unique constraint on nd_experiment_phenotype.nd_experiment_id?  People could still model the relationship as 1:1 but the database would no longer require it.  Since Chado is a flexible design, I think this approach fits better.

I would also like to propose adding a phenotypeprop table.  This is useful for adding properties like measurement unit and date.

I decided to store the phenotype observation value in a nd_experiment_phenotypeprop table instead of the phenotype table.  This is similar to the nd_experiment_stockprop table.

Let me know if you would like me to check in any of the above changes.

yuri

On Wed, Sep 29, 2010 at 1:40 PM, Sook Jung <[hidden email]> wrote:
> or store the samples in stock and define those as 'sample of' the parent
> stock accession in stock_relationship.
Yes this is the way I'm taking since each sample is linked with
distinct phenotypic values

Thanks

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema





------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema