Saving QTL data in Chado

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

Saving QTL data in Chado

Cannon, Ethalinda K [COM S]
Hello,

We are working on a new database for a set of crop plants, using Chado and Tripal, particularly focusing on QTL data with its associated maps, mapping populations, mapping analysis, markers, publications, and traits. How to load QTL data into Chado is proving to be far from obvious so we have been communicating with people from SGN, Knowpulse, CacaoGenomedb, and CottonGen and are trying to arrive at a "consensus" solution so that our data can look as much like other plant QTL data as possible.

Are there any other groups out there (plant or otherwise) who have loaded QTL data into Chado? If so, would you be willing to share your road map?

Alternatively, has there been any talk of creating a QTL module? The existing tables can certainly be fitted together to handle QTL data, but it could be more straight-forward.

Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.

Ethy Cannon
Nathan Weeks
Steven Cannon


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Mccormick, Ryan F
Hi all,

I'm also very interested in how others have stored QTL data in Chado; a QTL module would be great if there isn't an elegant solution already.

Sincerely,
Ryan McCormick

----- Original Message -----
From: "Ethalinda K Cannon [GDCBA]" <[hidden email]>
To: "GMOD Schema/Chado List" <[hidden email]>
Cc: "Nathan T Weeks [ITACD]" <[hidden email]>, "Steven Cannon" <[hidden email]>
Sent: Thursday, 25 April, 2013 8:43:03 AM
Subject: [Gmod-schema] Saving QTL data in Chado

Hello,

We are working on a new database for a set of crop plants, using Chado and Tripal, particularly focusing on QTL data with its associated maps, mapping populations, mapping analysis, markers, publications, and traits. How to load QTL data into Chado is proving to be far from obvious so we have been communicating with people from SGN, Knowpulse, CacaoGenomedb, and CottonGen and are trying to arrive at a "consensus" solution so that our data can look as much like other plant QTL data as possible.

Are there any other groups out there (plant or otherwise) who have loaded QTL data into Chado? If so, would you be willing to share your road map?

Alternatively, has there been any talk of creating a QTL module? The existing tables can certainly be fitted together to handle QTL data, but it could be more straight-forward.

Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.

Ethy Cannon
Nathan Weeks
Steven Cannon


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Nicolas Joannin
Hi all,

I also think feature_stock and feature_project tables are missing.

Best regards,
Nicolas



Nicolas Joannin, Ph.D.
Bioinformatics Center
Kyoto University, Uji campus, Japan



On Thu, Apr 25, 2013 at 11:05 PM, Mccormick, Ryan F <[hidden email]> wrote:
Hi all,

I'm also very interested in how others have stored QTL data in Chado; a QTL module would be great if there isn't an elegant solution already.

Sincerely,
Ryan McCormick

----- Original Message -----
From: "Ethalinda K Cannon [GDCBA]" <[hidden email]>
To: "GMOD Schema/Chado List" <[hidden email]>
Cc: "Nathan T Weeks [ITACD]" <[hidden email]>, "Steven Cannon" <[hidden email]>
Sent: Thursday, 25 April, 2013 8:43:03 AM
Subject: [Gmod-schema] Saving QTL data in Chado

Hello,

We are working on a new database for a set of crop plants, using Chado and Tripal, particularly focusing on QTL data with its associated maps, mapping populations, mapping analysis, markers, publications, and traits. How to load QTL data into Chado is proving to be far from obvious so we have been communicating with people from SGN, Knowpulse, CacaoGenomedb, and CottonGen and are trying to arrive at a "consensus" solution so that our data can look as much like other plant QTL data as possible.

Are there any other groups out there (plant or otherwise) who have loaded QTL data into Chado? If so, would you be willing to share your road map?

Alternatively, has there been any talk of creating a QTL module? The existing tables can certainly be fitted together to handle QTL data, but it could be more straight-forward.

Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.

Ethy Cannon
Nathan Weeks
Steven Cannon


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Naama Menda-3

Since QTLs can be handled just like markers, I don't think there is a need to add a QTL module.

Linking stocks to features by traversing through nd_experiment all the way to genotype and feature_genotype may be somewhat cumbersome, but I'm not sure if it's a good idea to link stocks directly with features.
Most users will probably want to record some information on how and why the feature is linked with the stock, and that can be done already using Natural Diversity.

-Naama 


Naama Menda
Boyce Thompson Institute for Plant Research
Tower Rd
Ithaca NY 14853
USA

(607) 254 3569
Sol Genomics Network
http://solgenomics.net/
[hidden email]

On Thu, Apr 25, 2013 at 10:14 AM, Nicolas Joannin <[hidden email]> wrote:
Hi all,

I also think feature_stock and feature_project tables are missing.

Best regards,
Nicolas



Nicolas Joannin, Ph.D.
Bioinformatics Center
Kyoto University, Uji campus, Japan



On Thu, Apr 25, 2013 at 11:05 PM, Mccormick, Ryan F <[hidden email]> wrote:
Hi all,

I'm also very interested in how others have stored QTL data in Chado; a QTL module would be great if there isn't an elegant solution already.

Sincerely,
Ryan McCormick

----- Original Message -----
From: "Ethalinda K Cannon [GDCBA]" <[hidden email]>
To: "GMOD Schema/Chado List" <[hidden email]>
Cc: "Nathan T Weeks [ITACD]" <[hidden email]>, "Steven Cannon" <[hidden email]>
Sent: Thursday, 25 April, 2013 8:43:03 AM
Subject: [Gmod-schema] Saving QTL data in Chado

Hello,

We are working on a new database for a set of crop plants, using Chado and Tripal, particularly focusing on QTL data with its associated maps, mapping populations, mapping analysis, markers, publications, and traits. How to load QTL data into Chado is proving to be far from obvious so we have been communicating with people from SGN, Knowpulse, CacaoGenomedb, and CottonGen and are trying to arrive at a "consensus" solution so that our data can look as much like other plant QTL data as possible.

Are there any other groups out there (plant or otherwise) who have loaded QTL data into Chado? If so, would you be willing to share your road map?

Alternatively, has there been any talk of creating a QTL module? The existing tables can certainly be fitted together to handle QTL data, but it could be more straight-forward.

Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.

Ethy Cannon
Nathan Weeks
Steven Cannon


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Cannon, Ethalinda K [COM S]
Thanks, that makes sense, Naama.

If we use the following chain to link stock (mapping population) and feature (QTL) records ...

nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature

... what is an nd_experiment and what is a genotype with regards to a QTL?

What about a feature_project table? Is there a similar argument for not having such a table? If so, do you have any suggestions for linking features to projects using existing tables? Or perhaps the project table is not the way to group features by studies within publications.

Ethy

________________________________________
From: Naama Menda [[hidden email]]
Sent: Thursday, April 25, 2013 11:41 AM
To: Nicolas Joannin
Cc: Weeks, Nathan T [ITACD]; GMOD Schema/Chado List; Steven Cannon
Subject: Re: [Gmod-schema] Saving QTL data in Chado

Since QTLs can be handled just like markers, I don't think there is a need to add a QTL module.

Linking stocks to features by traversing through nd_experiment all the way to genotype and feature_genotype may be somewhat cumbersome, but I'm not sure if it's a good idea to link stocks directly with features.
Most users will probably want to record some information on how and why the feature is linked with the stock, and that can be done already using Natural Diversity.

-Naama


Naama Menda
Boyce Thompson Institute for Plant Research
Tower Rd
Ithaca NY 14853
USA

(607) 254 3569
Sol Genomics Network
http://solgenomics.net/
[hidden email]<mailto:[hidden email]>

On Thu, Apr 25, 2013 at 10:14 AM, Nicolas Joannin <[hidden email]<mailto:[hidden email]>> wrote:
Hi all,

I also think feature_stock and feature_project tables are missing.

Best regards,
Nicolas



Nicolas Joannin, Ph.D.
Bioinformatics Center
Kyoto University, Uji campus, Japan



On Thu, Apr 25, 2013 at 11:05 PM, Mccormick, Ryan F <[hidden email]<mailto:[hidden email]>> wrote:
Hi all,

I'm also very interested in how others have stored QTL data in Chado; a QTL module would be great if there isn't an elegant solution already.

Sincerely,
Ryan McCormick

----- Original Message -----
From: "Ethalinda K Cannon [GDCBA]" <[hidden email]<mailto:[hidden email]>>
To: "GMOD Schema/Chado List" <[hidden email]<mailto:[hidden email]>>
Cc: "Nathan T Weeks [ITACD]" <[hidden email]<mailto:[hidden email]>>, "Steven Cannon" <[hidden email]<mailto:[hidden email]>>
Sent: Thursday, 25 April, 2013 8:43:03 AM
Subject: [Gmod-schema] Saving QTL data in Chado

Hello,

We are working on a new database for a set of crop plants, using Chado and Tripal, particularly focusing on QTL data with its associated maps, mapping populations, mapping analysis, markers, publications, and traits. How to load QTL data into Chado is proving to be far from obvious so we have been communicating with people from SGN, Knowpulse, CacaoGenomedb, and CottonGen and are trying to arrive at a "consensus" solution so that our data can look as much like other plant QTL data as possible.

Are there any other groups out there (plant or otherwise) who have loaded QTL data into Chado? If so, would you be willing to share your road map?

Alternatively, has there been any talk of creating a QTL module? The existing tables can certainly be fitted together to handle QTL data, but it could be more straight-forward.

Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.

Ethy Cannon
Nathan Weeks
Steven Cannon


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]<mailto:[hidden email]>
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]<mailto:[hidden email]>
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]<mailto:[hidden email]>
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Naama Menda-3
nd_experiment is there just for linking the stock with the genotype. It has a type_id (a cvterm , e.g. 'QTL experiment' ) 
and a geolocation_id ( we store in nd_geolocation the location of fields, greenhouses, and sequencing facilities) .

'genotype' is just a namespace holder, where you would give it a unique name , and a type (again, a cvterm) for specifying what type of genotype this is. I think the idea is that a genotype can be a collection of features.

I forgot there is a table stock_genotype, so if you don't need the whole deal of linking stocks to experiments, locations, and projects ,
you could do  stock->stock_genotype->genotype->genotype_feature.

I'd also like to hear from others if they have a concept of 'project'. When we designed the ND module , project was there and linked to 'contact' and microarray 'assay' (MAGE module), so it was decided to be used for linking experiments with projects. 
If your features are linked via a publication, then feature_pub will do the work of grouping . 


-Naama


On Thu, Apr 25, 2013 at 1:11 PM, Cannon, Ethalinda K [GDCBA] <[hidden email]> wrote:
Thanks, that makes sense, Naama.

If we use the following chain to link stock (mapping population) and feature (QTL) records ...

nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature

... what is an nd_experiment and what is a genotype with regards to a QTL?

What about a feature_project table? Is there a similar argument for not having such a table? If so, do you have any suggestions for linking features to projects using existing tables? Or perhaps the project table is not the way to group features by studies within publications.

Ethy

________________________________________
From: Naama Menda [[hidden email]]
Sent: Thursday, April 25, 2013 11:41 AM
To: Nicolas Joannin
Cc: Weeks, Nathan T [ITACD]; GMOD Schema/Chado List; Steven Cannon
Subject: Re: [Gmod-schema] Saving QTL data in Chado

Since QTLs can be handled just like markers, I don't think there is a need to add a QTL module.

Linking stocks to features by traversing through nd_experiment all the way to genotype and feature_genotype may be somewhat cumbersome, but I'm not sure if it's a good idea to link stocks directly with features.
Most users will probably want to record some information on how and why the feature is linked with the stock, and that can be done already using Natural Diversity.

-Naama


Naama Menda
Boyce Thompson Institute for Plant Research
Tower Rd
Ithaca NY 14853
USA

<a href="tel:%28607%29%20254%203569" value="+16072543569">(607) 254 3569
Sol Genomics Network
http://solgenomics.net/
[hidden email]<mailto:[hidden email]>

On Thu, Apr 25, 2013 at 10:14 AM, Nicolas Joannin <[hidden email]<mailto:[hidden email]>> wrote:
Hi all,

I also think feature_stock and feature_project tables are missing.

Best regards,
Nicolas



Nicolas Joannin, Ph.D.
Bioinformatics Center
Kyoto University, Uji campus, Japan



On Thu, Apr 25, 2013 at 11:05 PM, Mccormick, Ryan F <[hidden email]<mailto:[hidden email]>> wrote:
Hi all,

I'm also very interested in how others have stored QTL data in Chado; a QTL module would be great if there isn't an elegant solution already.

Sincerely,
Ryan McCormick

----- Original Message -----
From: "Ethalinda K Cannon [GDCBA]" <[hidden email]<mailto:[hidden email]>>
To: "GMOD Schema/Chado List" <[hidden email]<mailto:[hidden email]>>
Cc: "Nathan T Weeks [ITACD]" <[hidden email]<mailto:[hidden email]>>, "Steven Cannon" <[hidden email]<mailto:[hidden email]>>
Sent: Thursday, 25 April, 2013 8:43:03 AM
Subject: [Gmod-schema] Saving QTL data in Chado

Hello,

We are working on a new database for a set of crop plants, using Chado and Tripal, particularly focusing on QTL data with its associated maps, mapping populations, mapping analysis, markers, publications, and traits. How to load QTL data into Chado is proving to be far from obvious so we have been communicating with people from SGN, Knowpulse, CacaoGenomedb, and CottonGen and are trying to arrive at a "consensus" solution so that our data can look as much like other plant QTL data as possible.

Are there any other groups out there (plant or otherwise) who have loaded QTL data into Chado? If so, would you be willing to share your road map?

Alternatively, has there been any talk of creating a QTL module? The existing tables can certainly be fitted together to handle QTL data, but it could be more straight-forward.

Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.

Ethy Cannon
Nathan Weeks
Steven Cannon


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]<mailto:[hidden email]>
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]<mailto:[hidden email]>
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]<mailto:[hidden email]>
https://lists.sourceforge.net/lists/listinfo/gmod-schema



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Sook Jung
In reply to this post by Cannon, Ethalinda K [COM S]
Hello,
 
We have configured all of our data (genetic, genomic and breeding data) in GDR and CottonGen in Chado and below are some specific comments based on how we store data.
 
I agree with Naama that we can treat QTL the same as markers and store those in feature table. The advanged of Chado is that it's so flexible that we can store anything (almost) in there (the disadvantage is that different people can store things in totally different way). We made some custom tables though but all of them are linker tables like those you mentioned (feature_stock, feature_project, featuremap_stock. etc).
 
 
 
Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.
Locations of QTL in genetic maps are stored through the map module (featuremap, etc) just like locations of molecular markers. If we anchor QTLs on the genome we will store those in featureloc.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.
We link related QTLs into a project and all the detailed information on the project is stored in project/projectprop tables (linked by feature_project). 

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.
Again map information in map module 

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

We do it this way 
 
6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

The mapping populations are linked to maps through featuremap_stock and the QTL and maps are linked through map module (no need to go through ND module)
 
7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.
We do it this way.. 
 
Above is the way we store in GDR, but in CottonGen we also store population means, standard deviation, etc. The same QTL can have different values since publications report those values based on different places and time. In ths case we utilize ND module..
 
 
Thanks
 
Sook

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Sook Jung
Forgot to say that we do have feature_stock table. We use it to store the source germplasm for sequences (downloaded from NCBI) and molecular markers. We will also use, however, to store the source of 'good' allele for the QTL. The mapping population of the QTL is like I said earlier stored through the map module..
Sook


On Thu, Apr 25, 2013 at 3:42 PM, Sook Jung <[hidden email]> wrote:
Hello,
 
We have configured all of our data (genetic, genomic and breeding data) in GDR and CottonGen in Chado and below are some specific comments based on how we store data.
 
I agree with Naama that we can treat QTL the same as markers and store those in feature table. The advanged of Chado is that it's so flexible that we can store anything (almost) in there (the disadvantage is that different people can store things in totally different way). We made some custom tables though but all of them are linker tables like those you mentioned (feature_stock, feature_project, featuremap_stock. etc).
 
 
 
Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.
Locations of QTL in genetic maps are stored through the map module (featuremap, etc) just like locations of molecular markers. If we anchor QTLs on the genome we will store those in featureloc.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.
We link related QTLs into a project and all the detailed information on the project is stored in project/projectprop tables (linked by feature_project). 

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.
Again map information in map module 

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

We do it this way 
 
6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

The mapping populations are linked to maps through featuremap_stock and the QTL and maps are linked through map module (no need to go through ND module)
 
7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.
We do it this way.. 
 
Above is the way we store in GDR, but in CottonGen we also store population means, standard deviation, etc. The same QTL can have different values since publications report those values based on different places and time. In ths case we utilize ND module..
 
 
Thanks
 
Sook


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Cannon, Ethalinda K [COM S]
Thanks Sook!

I realized I was planning to store cM values in featureloc, which holds integers, not floats. How then should one handle locations that are a range of cMs? (I'd prefer to not just multiple by 100.) This applies to both the linkage group maps and the QTL positions. The featurepos table records only one position where the featurerange takes feature ids (two for each end of the range), not cM values.

Looking more closely at featuremap and the map module I noted that featurepos appears to refer to a map represented by both featurepos.featuremap_id (a featuremap record) and featurepos.map_feature_id (a feature record). It seems that this means having records in two different tables that both define the same linkage group map ... which is considered to represent the actual linkage group map and which is adding information (or a hook to attach it to additional tables)?

Ethy


________________________________________
From: Sook Jung [[hidden email]]
Sent: Thursday, April 25, 2013 2:48 PM
To: Cannon, Ethalinda K [GDCBA]
Cc: GMOD Schema/Chado List; Weeks, Nathan T [ITACD]; [hidden email]
Subject: Re: [Gmod-schema] Saving QTL data in Chado

Forgot to say that we do have feature_stock table. We use it to store the source germplasm for sequences (downloaded from NCBI) and molecular markers. We will also use, however, to store the source of 'good' allele for the QTL. The mapping population of the QTL is like I said earlier stored through the map module..
Sook


On Thu, Apr 25, 2013 at 3:42 PM, Sook Jung <[hidden email]<mailto:[hidden email]>> wrote:
Hello,

We have configured all of our data (genetic, genomic and breeding data) in GDR and CottonGen in Chado and below are some specific comments based on how we store data.

I agree with Naama that we can treat QTL the same as markers and store those in feature table. The advanged of Chado is that it's so flexible that we can store anything (almost) in there (the disadvantage is that different people can store things in totally different way). We made some custom tables though but all of them are linker tables like those you mentioned (feature_stock, feature_project, featuremap_stock. etc).



Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.
Locations of QTL in genetic maps are stored through the map module (featuremap, etc) just like locations of molecular markers. If we anchor QTLs on the genome we will store those in featureloc.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.
We link related QTLs into a project and all the detailed information on the project is stored in project/projectprop tables (linked by feature_project).

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.
Again map information in map module

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

We do it this way

6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

The mapping populations are linked to maps through featuremap_stock and the QTL and maps are linked through map module (no need to go through ND module)

7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.
We do it this way..

Above is the way we store in GDR, but in CottonGen we also store population means, standard deviation, etc. The same QTL can have different values since publications report those values based on different places and time. In ths case we utilize ND module..


Thanks

Sook

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Sook Jung
Hi,
We store the start/stop position in our custom table featureposprop.
The map_feature_id is for linkage group (map in CMap) and featuremap_id is for the map (map set as in CMap).
Cheers
Sook


On Wed, May 1, 2013 at 2:47 PM, Cannon, Ethalinda K [GDCBA] <[hidden email]> wrote:
Thanks Sook!

I realized I was planning to store cM values in featureloc, which holds integers, not floats. How then should one handle locations that are a range of cMs? (I'd prefer to not just multiple by 100.) This applies to both the linkage group maps and the QTL positions. The featurepos table records only one position where the featurerange takes feature ids (two for each end of the range), not cM values.

Looking more closely at featuremap and the map module I noted that featurepos appears to refer to a map represented by both featurepos.featuremap_id (a featuremap record) and featurepos.map_feature_id (a feature record). It seems that this means having records in two different tables that both define the same linkage group map ... which is considered to represent the actual linkage group map and which is adding information (or a hook to attach it to additional tables)?

Ethy


________________________________________
From: Sook Jung [[hidden email]]
Sent: Thursday, April 25, 2013 2:48 PM
To: Cannon, Ethalinda K [GDCBA]
Cc: GMOD Schema/Chado List; Weeks, Nathan T [ITACD]; [hidden email]
Subject: Re: [Gmod-schema] Saving QTL data in Chado

Forgot to say that we do have feature_stock table. We use it to store the source germplasm for sequences (downloaded from NCBI) and molecular markers. We will also use, however, to store the source of 'good' allele for the QTL. The mapping population of the QTL is like I said earlier stored through the map module..
Sook


On Thu, Apr 25, 2013 at 3:42 PM, Sook Jung <[hidden email]<mailto:[hidden email]>> wrote:
Hello,

We have configured all of our data (genetic, genomic and breeding data) in GDR and CottonGen in Chado and below are some specific comments based on how we store data.

I agree with Naama that we can treat QTL the same as markers and store those in feature table. The advanged of Chado is that it's so flexible that we can store anything (almost) in there (the disadvantage is that different people can store things in totally different way). We made some custom tables though but all of them are linker tables like those you mentioned (feature_stock, feature_project, featuremap_stock. etc).



Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.
Locations of QTL in genetic maps are stored through the map module (featuremap, etc) just like locations of molecular markers. If we anchor QTLs on the genome we will store those in featureloc.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.
We link related QTLs into a project and all the detailed information on the project is stored in project/projectprop tables (linked by feature_project).

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.
Again map information in map module

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

We do it this way

6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

The mapping populations are linked to maps through featuremap_stock and the QTL and maps are linked through map module (no need to go through ND module)

7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.
We do it this way..

Above is the way we store in GDR, but in CottonGen we also store population means, standard deviation, etc. The same QTL can have different values since publications report those values based on different places and time. In ths case we utilize ND module..


Thanks

Sook

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Cannon, Steven
Hi all,

Naama is visiting here. Her suggestion is to change the constraint in featureloc to allow floats. That seems pretty straightforward, since markers really do seem like "features." Would this break things in Chado or Tripal?

Steven


From: Sook Jung <[hidden email]>
Date: Wednesday, May 1, 2013 3:05 PM
To: Ethalinda Cannon <[hidden email]>
Cc: GMOD Schema/Chado List <[hidden email]>
Subject: Re: [Gmod-schema] Saving QTL data in Chado

Hi,
We store the start/stop position in our custom table featureposprop.
The map_feature_id is for linkage group (map in CMap) and featuremap_id is for the map (map set as in CMap).
Cheers
Sook


On Wed, May 1, 2013 at 2:47 PM, Cannon, Ethalinda K [GDCBA] <[hidden email]> wrote:
Thanks Sook!

I realized I was planning to store cM values in featureloc, which holds integers, not floats. How then should one handle locations that are a range of cMs? (I'd prefer to not just multiple by 100.) This applies to both the linkage group maps and the QTL positions. The featurepos table records only one position where the featurerange takes feature ids (two for each end of the range), not cM values.

Looking more closely at featuremap and the map module I noted that featurepos appears to refer to a map represented by both featurepos.featuremap_id (a featuremap record) and featurepos.map_feature_id (a feature record). It seems that this means having records in two different tables that both define the same linkage group map ... which is considered to represent the actual linkage group map and which is adding information (or a hook to attach it to additional tables)?

Ethy


________________________________________
From: Sook Jung [[hidden email]]
Sent: Thursday, April 25, 2013 2:48 PM
To: Cannon, Ethalinda K [GDCBA]
Cc: GMOD Schema/Chado List; Weeks, Nathan T [ITACD]; [hidden email]
Subject: Re: [Gmod-schema] Saving QTL data in Chado

Forgot to say that we do have feature_stock table. We use it to store the source germplasm for sequences (downloaded from NCBI) and molecular markers. We will also use, however, to store the source of 'good' allele for the QTL. The mapping population of the QTL is like I said earlier stored through the map module..
Sook


On Thu, Apr 25, 2013 at 3:42 PM, Sook Jung <[hidden email]<mailto:[hidden email]>> wrote:
Hello,

We have configured all of our data (genetic, genomic and breeding data) in GDR and CottonGen in Chado and below are some specific comments based on how we store data.

I agree with Naama that we can treat QTL the same as markers and store those in feature table. The advanged of Chado is that it's so flexible that we can store anything (almost) in there (the disadvantage is that different people can store things in totally different way). We made some custom tables though but all of them are linker tables like those you mentioned (feature_stock, feature_project, featuremap_stock. etc).



Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.
Locations of QTL in genetic maps are stored through the map module (featuremap, etc) just like locations of molecular markers. If we anchor QTLs on the genome we will store those in featureloc.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.
We link related QTLs into a project and all the detailed information on the project is stored in project/projectprop tables (linked by feature_project).

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.
Again map information in map module

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

We do it this way

6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

The mapping populations are linked to maps through featuremap_stock and the QTL and maps are linked through map module (no need to go through ND module)

7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.
We do it this way..

Above is the way we store in GDR, but in CottonGen we also store population means, standard deviation, etc. The same QTL can have different values since publications report those values based on different places and time. In ths case we utilize ND module..


Thanks

Sook

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema





This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Stephen Ficklin-2
Hi Steven,

As far as Tripal is concerned, it knows about each table in Chado as well as their fields and types.  Right now I don't think you would have problems with Tripal if you changed featureloc.fmin and featureloc.fmax to floats,  except if you want to use any of the Chado tables in Drupal Views.   Then you would also need to manually change the handlers for that field.   However,  I would not recommend changing any of the Chado tables because Tripal is programmed to handle each field by it's data type which may cause problems in the future.   Tripal supports creating of custom tables in Chado, through a web form (it's quite easy to do), and then treats these custom tables as if they are Chado tables with all the same functionality that Tripal gives to the Chado tables (support in Drupal Views, access to data in templates, interaction with API functions, etc.).   So, my suggestion would be to keep Chado as it is and if you need customizations  you can add custom tables specific to your needs.  For custom tables, the rule I try to follow is to fit as much of your data as possible into Chado as is and limit custom tables to just linker tables (e.g. feature_stock) or property tables (e.g. featurposprop as Sook suggests). 

Stephen


On 5/1/2013 5:30 PM, Cannon, Steven wrote:
Hi all,

Naama is visiting here. Her suggestion is to change the constraint in featureloc to allow floats. That seems pretty straightforward, since markers really do seem like "features." Would this break things in Chado or Tripal?

Steven


From: Sook Jung <[hidden email]>
Date: Wednesday, May 1, 2013 3:05 PM
To: Ethalinda Cannon <[hidden email]>
Cc: GMOD Schema/Chado List <[hidden email]>
Subject: Re: [Gmod-schema] Saving QTL data in Chado

Hi,
We store the start/stop position in our custom table featureposprop.
The map_feature_id is for linkage group (map in CMap) and featuremap_id is for the map (map set as in CMap).
Cheers
Sook


On Wed, May 1, 2013 at 2:47 PM, Cannon, Ethalinda K [GDCBA] <[hidden email]> wrote:
Thanks Sook!

I realized I was planning to store cM values in featureloc, which holds integers, not floats. How then should one handle locations that are a range of cMs? (I'd prefer to not just multiple by 100.) This applies to both the linkage group maps and the QTL positions. The featurepos table records only one position where the featurerange takes feature ids (two for each end of the range), not cM values.

Looking more closely at featuremap and the map module I noted that featurepos appears to refer to a map represented by both featurepos.featuremap_id (a featuremap record) and featurepos.map_feature_id (a feature record). It seems that this means having records in two different tables that both define the same linkage group map ... which is considered to represent the actual linkage group map and which is adding information (or a hook to attach it to additional tables)?

Ethy


________________________________________
From: Sook Jung [[hidden email]]
Sent: Thursday, April 25, 2013 2:48 PM
To: Cannon, Ethalinda K [GDCBA]
Cc: GMOD Schema/Chado List; Weeks, Nathan T [ITACD]; [hidden email]
Subject: Re: [Gmod-schema] Saving QTL data in Chado

Forgot to say that we do have feature_stock table. We use it to store the source germplasm for sequences (downloaded from NCBI) and molecular markers. We will also use, however, to store the source of 'good' allele for the QTL. The mapping population of the QTL is like I said earlier stored through the map module..
Sook


On Thu, Apr 25, 2013 at 3:42 PM, Sook Jung <[hidden email]<mailto:[hidden email]>> wrote:
Hello,

We have configured all of our data (genetic, genomic and breeding data) in GDR and CottonGen in Chado and below are some specific comments based on how we store data.

I agree with Naama that we can treat QTL the same as markers and store those in feature table. The advanged of Chado is that it's so flexible that we can store anything (almost) in there (the disadvantage is that different people can store things in totally different way). We made some custom tables though but all of them are linker tables like those you mentioned (feature_stock, feature_project, featuremap_stock. etc).



Below is our current road map, subject to change:

1. Data is mined from publications and entered into a human-readable spreadsheet.

2. QTLs are represented by feature records and associated with publications (feature_pub), markers (feature_relationship where markers are also features), locations (featureloc), with all additional information through the featureprop table.
Locations of QTL in genetic maps are stored through the map module (featuremap, etc) just like locations of molecular markers. If we anchor QTLs on the genome we will store those in featureloc.

3. The analysis method and associated values are attached to QTLs via the analysis and analysisfeature tables.
We link related QTLs into a project and all the detailed information on the project is stored in project/projectprop tables (linked by feature_project).

4. The maps the QTLs are placed on are represented by feature records, one per linkage group.
Again map information in map module

5. Mapping population (parents and the population itself) are represented via the stock and stock_relationship tables.

We do it this way

6. We would like to associate QTLs with their mapping population through a feature_stock table, which doesn't exist in the core Chado schema. Alternatively we could use existing tables, including the Natural Diversity module, to create a chain to connect stock records (mapping population) to feature records for the QTL through: nd_experiment_stock, nd_experiment, nd_experiment_genotype, genotype, genotype_feature.

The mapping populations are linked to maps through featuremap_stock and the QTL and maps are linked through map module (no need to go through ND module)

7. We would also like to associate a set of QTLs with their associated study (one publication may report on multiple QTL studies) via the project table, though this appears to also need a new association table, feature_project, or another long chain of connecting tables that we haven’t worked out yet.
We do it this way..

Above is the way we store in GDR, but in CottonGen we also store population means, standard deviation, etc. The same QTL can have different values since publications report those values based on different places and time. In ths case we utilize ND module..


Thanks

Sook

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema





This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1


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


------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Saving QTL data in Chado

Siddhartha Basu
In reply to this post by Cannon, Steven
Hi,

On Wed, 01 May 2013, Cannon, Steven wrote:

>    Hi all,
>    Naama is visiting here. Her suggestion is to change the constraint
>    in featureloc to allow floats. That seems pretty straightforward, since
>    markers really do seem like "features." Would this break things in Chado
>    or Tripal?
It might break but i am not aware of any systematic or uniform way to get a
report/breakage of chado database triggers/functions/application code(other than
tripal). If its there somewhere then we need to run it or if its not
there we might need to have it to test all table modification/table
addition suggestions that comes up frequently.
Anyway, I would recommend to add any core changes as a contrib module or as
plugin that could be added on demand and should be available with core
chado release. And may be add a note to featureloc wiki page saying when
and why these changes could be applied.


thanks,
-siddhartha



>    Steven
>    From: Sook Jung <[hidden email]>
>    Date: Wednesday, May 1, 2013 3:05 PM
>    To: Ethalinda Cannon <[hidden email]>
>    Cc: GMOD Schema/Chado List <[hidden email]>
>    Subject: Re: [Gmod-schema] Saving QTL data in Chado
>    Hi,
>    We store the start/stop position in our custom table featureposprop.
>    The map_feature_id is for linkage group (map in CMap) and featuremap_id is
>    for the map (map set as in CMap).
>    Cheers
>    Sook
>
>    On Wed, May 1, 2013 at 2:47 PM, Cannon, Ethalinda K [GDCBA]
>    <[hidden email]> wrote:
>
>      Thanks Sook!
>
>      I realized I was planning to store cM values in featureloc, which holds
>      integers, not floats. How then should one handle locations that are a
>      range of cMs? (I'd prefer to not just multiple by 100.) This applies to
>      both the linkage group maps and the QTL positions. The featurepos table
>      records only one position where the featurerange takes feature ids (two
>      for each end of the range), not cM values.
>
>      Looking more closely at featuremap and the map module I noted that
>      featurepos appears to refer to a map represented by both
>      featurepos.featuremap_id (a featuremap record) and
>      featurepos.map_feature_id (a feature record). It seems that this means
>      having records in two different tables that both define the same linkage
>      group map ... which is considered to represent the actual linkage group
>      map and which is adding information (or a hook to attach it to
>      additional tables)?
>
>      Ethy
>
>      ________________________________________
>      From: Sook Jung [[hidden email]]
>      Sent: Thursday, April 25, 2013 2:48 PM
>      To: Cannon, Ethalinda K [GDCBA]
>      Cc: GMOD Schema/Chado List; Weeks, Nathan T [ITACD];
>      [hidden email]
>      Subject: Re: [Gmod-schema] Saving QTL data in Chado
>
>      Forgot to say that we do have feature_stock table. We use it to store
>      the source germplasm for sequences (downloaded from NCBI) and molecular
>      markers. We will also use, however, to store the source of 'good' allele
>      for the QTL. The mapping population of the QTL is like I said earlier
>      stored through the map module..
>      Sook
>
>      On Thu, Apr 25, 2013 at 3:42 PM, Sook Jung
>      <[hidden email]<mailto:[hidden email]>> wrote:
>      Hello,
>
>      We have configured all of our data (genetic, genomic and breeding data)
>      in GDR and CottonGen in Chado and below are some specific comments based
>      on how we store data.
>
>      I agree with Naama that we can treat QTL the same as markers and store
>      those in feature table. The advanged of Chado is that it's so flexible
>      that we can store anything (almost) in there (the disadvantage is that
>      different people can store things in totally different way). We made
>      some custom tables though but all of them are linker tables like those
>      you mentioned (feature_stock, feature_project, featuremap_stock. etc).
>
>      Below is our current road map, subject to change:
>
>      1. Data is mined from publications and entered into a human-readable
>      spreadsheet.
>
>      2. QTLs are represented by feature records and associated with
>      publications (feature_pub), markers (feature_relationship where markers
>      are also features), locations (featureloc), with all additional
>      information through the featureprop table.
>      Locations of QTL in genetic maps are stored through the map module
>      (featuremap, etc) just like locations of molecular markers. If we anchor
>      QTLs on the genome we will store those in featureloc.
>
>      3. The analysis method and associated values are attached to QTLs via
>      the analysis and analysisfeature tables.
>      We link related QTLs into a project and all the detailed information on
>      the project is stored in project/projectprop tables (linked by
>      feature_project).
>
>      4. The maps the QTLs are placed on are represented by feature records,
>      one per linkage group.
>      Again map information in map module
>
>      5. Mapping population (parents and the population itself) are
>      represented via the stock and stock_relationship tables.
>
>      We do it this way
>
>      6. We would like to associate QTLs with their mapping population through
>      a feature_stock table, which doesn't exist in the core Chado schema.
>      Alternatively we could use existing tables, including the Natural
>      Diversity module, to create a chain to connect stock records (mapping
>      population) to feature records for the QTL through: nd_experiment_stock,
>      nd_experiment, nd_experiment_genotype, genotype, genotype_feature.
>
>      The mapping populations are linked to maps through featuremap_stock and
>      the QTL and maps are linked through map module (no need to go through ND
>      module)
>
>      7. We would also like to associate a set of QTLs with their associated
>      study (one publication may report on multiple QTL studies) via the
>      project table, though this appears to also need a new association table,
>      feature_project, or another long chain of connecting tables that we
>      haven't worked out yet.
>      We do it this way..
>
>      Above is the way we store in GDR, but in CottonGen we also store
>      population means, standard deviation, etc. The same QTL can have
>      different values since publications report those values based on
>      different places and time. In ths case we utilize ND module..
>
>      Thanks
>
>      Sook
>
>      ------------------------------------------------------------------------------
>      Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>      Get 100% visibility into your production application - at no cost.
>      Code-level diagnostics for performance bottlenecks with <2% overhead
>      Download for free and get started troubleshooting in minutes.
>      http://p.sf.net/sfu/appdyn_d2d_ap1
>      _______________________________________________
>      Gmod-schema mailing list
>      [hidden email]
>      https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>    This electronic message contains information generated by the USDA solely
>    for the intended recipients. Any unauthorized interception of this message
>    or the use or disclosure of the information it contains may violate the
>    law and subject the violator to civil or criminal penalties. If you
>    believe you have received this message in error, please notify the sender
>    and delete the email immediately.

> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1

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


------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema