Re: [Gmod-schema] Use Cases on the simplified natural diversity module

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

Re: [Gmod-schema] Use Cases on the simplified natural diversity module

Yuri Bendana-3
Another option is to store just the distinct phenotypes in the phenotype table and the attributes associated with each phenotype measurement in ndassayprop.

yuri

On Wed, May 12, 2010 at 8:08 PM, Sook Jung <[hidden email]> wrote:
Thanks Naama, it helps.

I still have comments for two of the questions.

nd_assay_phenotype

  • Question: The SQL document says that there is one to one relationship between assay_id and phenotype_id but multiple samples can have the same phenotypic value so it would be many to one relationship. For example, the phenotypic value of firmness (eg. apple) varies from 1 to 5 (1 being very soft and 5 being very firm). Multiple assay_ids, therefore, can be linked to phenotype_id with the attr_id 'firmness' and value 1.

- [Naama] From my understanding every time you measure a phenotype you store it it the phenotype table with the relevant attributes. I don't think you are supposed to 'reuse' these records, even if you get a similar measurement.


- [Sook] Perhaps chado users could choose either way? If we check 1000 flies and 500 of them had white eyes and the rest of them had red eyes, we can only have two rows in phenotype table - red or white. Otherwise we'll have 1000 rows each connected with individual assay.. I think ParameciumDB stores distinct phenotypes in phenotype table and links to multiple stocks. http://paramecium.cgm.cnrs-gif.fr/db/Phenotype/5

Sook

------------------------------------------------------------------------------


_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema



------------------------------------------------------------------------------


_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Use Cases on the simplified natural diversity module

seth redmond
We've added a couple more use cases from the mosquito-centric viewpoint (one population sampling, one RNAi knockdown). However we seem to have come across a potential omission from the schema. 

Although there's a wealth of ways we can link a publication to a stock, it seems far more likely we will want to link this directly to the project. Similarly contact is linked to sample via a number of tables, but as far as I can see we cannot link this contact table to a project in order to record the submitting lab. 

Have I missed a way we can do this? or do we need to add a couple of link tables?

Oh, and one minor bug - the last SQL's include header pulls in the Project table from General.sql, but not the ancillary projectrelationship/projectprop tables. I believe it was I who moved these to General, so my bad. Unless anyone objects I'll commit a fix for this in the morning. 

-s




On 13 May 2010, at 19:34, Yuri Bendana wrote:

Another option is to store just the distinct phenotypes in the phenotype table and the attributes associated with each phenotype measurement in ndassayprop.

yuri

On Wed, May 12, 2010 at 8:08 PM, Sook Jung <[hidden email]> wrote:
Thanks Naama, it helps.

I still have comments for two of the questions.

nd_assay_phenotype

  • Question: The SQL document says that there is one to one relationship between assay_id and phenotype_id but multiple samples can have the same phenotypic value so it would be many to one relationship. For example, the phenotypic value of firmness (eg. apple) varies from 1 to 5 (1 being very soft and 5 being very firm). Multiple assay_ids, therefore, can be linked to phenotype_id with the attr_id 'firmness' and value 1.

- [Naama] From my understanding every time you measure a phenotype you store it it the phenotype table with the relevant attributes. I don't think you are supposed to 'reuse' these records, even if you get a similar measurement.


- [Sook] Perhaps chado users could choose either way? If we check 1000 flies and 500 of them had white eyes and the rest of them had red eyes, we can only have two rows in phenotype table - red or white. Otherwise we'll have 1000 rows each connected with individual assay.. I think ParameciumDB stores distinct phenotypes in phenotype table and links to multiple stocks. http://paramecium.cgm.cnrs-gif.fr/db/Phenotype/5

Sook

------------------------------------------------------------------------------


_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


<ATT00003..txt><ATT00004..txt>


------------------------------------------------------------------------------


_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Use Cases on the simplified natural diversity module

Sook Jung
Hi Seth,

I also thought we needed a place to add contact info and below is what I suggested to the gmod-schema list. What do you think?
-----------
I think we better have both nd_assay_contact and project_contact since we may need to record the contact person for the project and the researchers who actually performed assays.
------------
Sook

On Mon, May 24, 2010 at 6:59 PM, seth redmond <[hidden email]> wrote:
We've added a couple more use cases from the mosquito-centric viewpoint (one population sampling, one RNAi knockdown). However we seem to have come across a potential omission from the schema. 

Although there's a wealth of ways we can link a publication to a stock, it seems far more likely we will want to link this directly to the project. Similarly contact is linked to sample via a number of tables, but as far as I can see we cannot link this contact table to a project in order to record the submitting lab. 

Have I missed a way we can do this? or do we need to add a couple of link tables?

Oh, and one minor bug - the last SQL's include header pulls in the Project table from General.sql, but not the ancillary projectrelationship/projectprop tables. I believe it was I who moved these to General, so my bad. Unless anyone objects I'll commit a fix for this in the morning. 

-s




On 13 May 2010, at 19:34, Yuri Bendana wrote:

Another option is to store just the distinct phenotypes in the phenotype table and the attributes associated with each phenotype measurement in ndassayprop.

yuri

On Wed, May 12, 2010 at 8:08 PM, Sook Jung <[hidden email]> wrote:
Thanks Naama, it helps.

I still have comments for two of the questions.

nd_assay_phenotype

  • Question: The SQL document says that there is one to one relationship between assay_id and phenotype_id but multiple samples can have the same phenotypic value so it would be many to one relationship. For example, the phenotypic value of firmness (eg. apple) varies from 1 to 5 (1 being very soft and 5 being very firm). Multiple assay_ids, therefore, can be linked to phenotype_id with the attr_id 'firmness' and value 1.

- [Naama] From my understanding every time you measure a phenotype you store it it the phenotype table with the relevant attributes. I don't think you are supposed to 'reuse' these records, even if you get a similar measurement.


- [Sook] Perhaps chado users could choose either way? If we check 1000 flies and 500 of them had white eyes and the rest of them had red eyes, we can only have two rows in phenotype table - red or white. Otherwise we'll have 1000 rows each connected with individual assay.. I think ParameciumDB stores distinct phenotypes in phenotype table and links to multiple stocks. http://paramecium.cgm.cnrs-gif.fr/db/Phenotype/5

Sook

------------------------------------------------------------------------------


_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


<ATT00003..txt><ATT00004..txt>




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

------------------------------------------------------------------------------


_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Use Cases on the simplified natural diversity module

seth redmond
Yeah, this is what I was thinking.

As to the project_publication table, since we have now added  
projectprop and project_relationship to the general SQL, and I would  
suggest we add project_publication, it might be best to put these in a  
separate general/project.sql file to help with integrating this into  
the main GMOD branch.

-s


On 25 May 2010, at 00:24, Sook Jung wrote:

> Hi Seth,
>
> I also thought we needed a place to add contact info and below is  
> what I suggested to the gmod-schema list. What do you think?
> -----------
> I think we better have both nd_assay_contact and project_contact  
> since we may need to record the contact person for the project and  
> the researchers who actually performed assays.
> ------------
> Sook
>
> On Mon, May 24, 2010 at 6:59 PM, seth redmond <[hidden email]
> > wrote:
> We've added a couple more use cases from the mosquito-centric  
> viewpoint (one population sampling, one RNAi knockdown). However we  
> seem to have come across a potential omission from the schema.
>
> Although there's a wealth of ways we can link a publication to a  
> stock, it seems far more likely we will want to link this directly  
> to the project. Similarly contact is linked to sample via a number  
> of tables, but as far as I can see we cannot link this contact table  
> to a project in order to record the submitting lab.
>
> Have I missed a way we can do this? or do we need to add a couple of  
> link tables?
>
> Oh, and one minor bug - the last SQL's include header pulls in the  
> Project table from General.sql, but not the ancillary  
> projectrelationship/projectprop tables. I believe it was I who moved  
> these to General, so my bad. Unless anyone objects I'll commit a fix  
> for this in the morning.
>
> -s
>
>
>
>
> On 13 May 2010, at 19:34, Yuri Bendana wrote:
>
>> Another option is to store just the distinct phenotypes in the  
>> phenotype table and the attributes associated with each phenotype  
>> measurement in ndassayprop.
>>
>> yuri
>>
>> On Wed, May 12, 2010 at 8:08 PM, Sook Jung <[hidden email]> wrote:
>> Thanks Naama, it helps.
>>
>> I still have comments for two of the questions.
>>
>> nd_assay_phenotype
>>
>> • Question: The SQL document says that there is one to one  
>> relationship between assay_id and phenotype_id but multiple samples  
>> can have the same phenotypic value so it would be many to one  
>> relationship. For example, the phenotypic value of firmness (eg.  
>> apple) varies from 1 to 5 (1 being very soft and 5 being very  
>> firm). Multiple assay_ids, therefore, can be linked to phenotype_id  
>> with the attr_id 'firmness' and value 1.
>> - [Naama] From my understanding every time you measure a phenotype  
>> you store it it the phenotype table with the relevant attributes. I  
>> don't think you are supposed to 'reuse' these records, even if you  
>> get a similar measurement.
>>
>>
>> - [Sook] Perhaps chado users could choose either way? If we check  
>> 1000 flies and 500 of them had white eyes and the rest of them had  
>> red eyes, we can only have two rows in phenotype table - red or  
>> white. Otherwise we'll have 1000 rows each connected with  
>> individual assay.. I think ParameciumDB stores distinct phenotypes  
>> in phenotype table and links to multiple stocks. http://paramecium.cgm.cnrs-gif.fr/db/Phenotype/5
>>
>> Sook
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Gmod-schema mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>>
>>
>> <ATT00003..txt><ATT00004..txt>
>
>
>
>
> --
> 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]


------------------------------------------------------------------------------

_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema