Opening up comments on changes to Chado

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

Opening up comments on changes to Chado

Scott Cain
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

chado_1.2_1.3.diff (36K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

David Emmert
Hi Scott,

Thanks for the heads-up, Scott, and apologies for the sparse documentation.  We'll get to work to improve this and plan to get back to you by the end of next week.   Does that work for you?

Best,

-Dave


On Thu, Aug 29, 2013 at 4:28 PM, Scott Cain <[hidden email]> wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Scott Cain
Hi Dave,

That's fine; I just wanted to get the conversation rolling.

Scott



On Fri, Aug 30, 2013 at 9:21 AM, David Emmert <[hidden email]> wrote:
Hi Scott,

Thanks for the heads-up, Scott, and apologies for the sparse documentation.  We'll get to work to improve this and plan to get back to you by the end of next week.   Does that work for you?

Best,

-Dave


On Thu, Aug 29, 2013 at 4:28 PM, Scott Cain <[hidden email]> wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Stephen Ficklin-2
In reply to this post by Scott Cain
Hi Scott,

We have a list of linker and property tables that we have had to create for some of our sites and we've had to create them as custom tables, but they simply link two chado tables (e.g. library_stock) or are property tables.  Would you be open to including them in the v1.3 release of Chado if we can get you a list of them (including SQL)?

Thanks,
Stephen

On 8/29/2013 4:28 PM, Scott Cain wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     216-392-3087
Ontario Institute for Cancer Research


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk


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


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Scott Cain
Hi Stephen,

Yes, please post the DDL for the tables and some documentation on how they are used.  It's interesting that you mentioned library_stock, since FlyBase committed a library_strain table and I'm worried about how those two might overlap.

Scott




On Wed, Sep 4, 2013 at 10:17 AM, Stephen Ficklin <[hidden email]> wrote:
Hi Scott,

We have a list of linker and property tables that we have had to create for some of our sites and we've had to create them as custom tables, but they simply link two chado tables (e.g. library_stock) or are property tables.  Would you be open to including them in the v1.3 release of Chado if we can get you a list of them (including SQL)?

Thanks,
Stephen


On 8/29/2013 4:28 PM, Scott Cain wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk


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


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

David Emmert
In reply to this post by Scott Cain
Hi Scott,

I"ve just now committed documentation for the chado tables FlyBase has added lately.   These are all in the form of comments on tables, consistent with how we've done elsewhere in the schema.  If what I added is still insufficient, let me know and we'll try to improve it. 

One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.


I'm not entirely sure I understand what you mean here.   We haven't ever stored normalized strain data in the stock module, so I'm not even clear how it would be done.   Do you have an example or two?  If there is duplication between the stock and organism modules in handling strain data we should at least understand exactly whats going on, even if (imo) it may not necessarily be something we have to eliminate.

In general, for FlyBase at least, we couldn't assume that every strain we might want to collect data on would be in one of the stock repositories, so it probably wouldn't be appropriate to limit ourselves that way by using the stock module for strains.   But lets see what the other implementation pattern looks like and go from there...

Best,

-D



On Fri, Aug 30, 2013 at 11:10 AM, Scott Cain <[hidden email]> wrote:
Hi Dave,

That's fine; I just wanted to get the conversation rolling.

Scott



On Fri, Aug 30, 2013 at 9:21 AM, David Emmert <[hidden email]> wrote:
Hi Scott,

Thanks for the heads-up, Scott, and apologies for the sparse documentation.  We'll get to work to improve this and plan to get back to you by the end of next week.   Does that work for you?

Best,

-Dave


On Thu, Aug 29, 2013 at 4:28 PM, Scott Cain <[hidden email]> wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Cannon, Steven
In reply to this post by Scott Cain
The Ames group (Legume Information System / SoyBase) would also like to mention changes that we have needed to make — also for use with Tripal. 
Scott – do you have a time frame for accepting comments?

Steven


From: Scott Cain <[hidden email]>
Date: Wednesday, September 4, 2013 9:39 AM
To: Stephen Ficklin <[hidden email]>
Cc: GMOD Schema/Chado List <[hidden email]>
Subject: Re: [Gmod-schema] Opening up comments on changes to Chado

Hi Stephen,

Yes, please post the DDL for the tables and some documentation on how they are used.  It's interesting that you mentioned library_stock, since FlyBase committed a library_strain table and I'm worried about how those two might overlap.

Scott




On Wed, Sep 4, 2013 at 10:17 AM, Stephen Ficklin <[hidden email]> wrote:
Hi Scott,

We have a list of linker and property tables that we have had to create for some of our sites and we've had to create them as custom tables, but they simply link two chado tables (e.g. library_stock) or are property tables.  Would you be open to including them in the v1.3 release of Chado if we can get you a list of them (including SQL)?

Thanks,
Stephen


On 8/29/2013 4:28 PM, Scott Cain wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="&#43;12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk


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


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     216-392-3087
Ontario Institute for Cancer Research




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.
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Stephen Ficklin-2
In reply to this post by Scott Cain
Hi Scott,

Sorry for the slowness on this.   Attached are three files of proposed linker and property tables we'd would like to suggest for Chado v1.3.  These tables just link existing tables or add a 'prop' table to existing tables.  The only exception is the 'organism_relationship' table which would allow relationships between organisms that are not taxonomic (e.g. such as breeding relationships).  I'm sure there are a ton more linking/prop tables that could be defined but these are tables we've had to add in our instances of Chado.

I've tested loading these files into a Chado 1.2 instance and they load fine.  I've double checked them to make sure they look right, but it you think you can include these in the v1.3 release let me know and I can double check again to make sure I haven't missed anything.

Also, when do you think you'll release v1.3?  We're working to get a Drupal 7 version of Tripal released and it would be nice to include support for Chado v1.3 at the same time if possible.

Thanks,
Stephen


On Wed, Sep 4, 2013 at 10:39 AM, Scott Cain <[hidden email]> wrote:
Hi Stephen,

Yes, please post the DDL for the tables and some documentation on how they are used.  It's interesting that you mentioned library_stock, since FlyBase committed a library_strain table and I'm worried about how those two might overlap.

Scott




On Wed, Sep 4, 2013 at 10:17 AM, Stephen Ficklin <[hidden email]> wrote:
Hi Scott,

We have a list of linker and property tables that we have had to create for some of our sites and we've had to create them as custom tables, but they simply link two chado tables (e.g. library_stock) or are property tables.  Would you be open to including them in the v1.3 release of Chado if we can get you a list of them (including SQL)?

Thanks,
Stephen


On 8/29/2013 4:28 PM, Scott Cain wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk


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


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research


------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

Proposed_linker_tables_Chado_V1.3.sql (18K) Download Attachment
Proposed_prop_tables_Chado_V1.3.sql (4K) Download Attachment
Proposed_relationship_tables_Chado_V1.3.sql (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Stephen Ficklin-2
Oh, one other request....

The 'db' and 'dbxref' tables are part of the 'General' Chado module.  In Tripal we have a 'db' module that manages the support for those tables.   We are considering renaming some of our Tripal modules to match the Chado module names to help prevent confusion, but we don't want to rename our 'db' module to 'general'.   Would it be possible to reclassify the 'db' and 'dbxref' tables into a new Chado 'DB' module?  

Also, we have a 'Project' module in Tripal that manages support for the 'project' table, but that is also in the 'General' Chado module.  Would it be unreasonable to have create a new 'Project' Chado module even though it currently only has one table?  ... although we could add a projectprop table to the schema.  

I think these would just be classification changes to the online documentation.

Thanks,
Stephen

On 12/9/2013 7:43 PM, Stephen Ficklin wrote:
Hi Scott,

Sorry for the slowness on this.   Attached are three files of proposed linker and property tables we'd would like to suggest for Chado v1.3.  These tables just link existing tables or add a 'prop' table to existing tables.  The only exception is the 'organism_relationship' table which would allow relationships between organisms that are not taxonomic (e.g. such as breeding relationships).  I'm sure there are a ton more linking/prop tables that could be defined but these are tables we've had to add in our instances of Chado.

I've tested loading these files into a Chado 1.2 instance and they load fine.  I've double checked them to make sure they look right, but it you think you can include these in the v1.3 release let me know and I can double check again to make sure I haven't missed anything.

Also, when do you think you'll release v1.3?  We're working to get a Drupal 7 version of Tripal released and it would be nice to include support for Chado v1.3 at the same time if possible.

Thanks,
Stephen


On Wed, Sep 4, 2013 at 10:39 AM, Scott Cain <[hidden email]> wrote:
Hi Stephen,

Yes, please post the DDL for the tables and some documentation on how they are used.  It's interesting that you mentioned library_stock, since FlyBase committed a library_strain table and I'm worried about how those two might overlap.

Scott




On Wed, Sep 4, 2013 at 10:17 AM, Stephen Ficklin <[hidden email]> wrote:
Hi Scott,

We have a list of linker and property tables that we have had to create for some of our sites and we've had to create them as custom tables, but they simply link two chado tables (e.g. library_stock) or are property tables.  Would you be open to including them in the v1.3 release of Chado if we can get you a list of them (including SQL)?

Thanks,
Stephen


On 8/29/2013 4:28 PM, Scott Cain wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a moz-do-not-send="true" href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk


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


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a moz-do-not-send="true" href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research



------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Hilmar Lapp-3
I can see how 'general' is a bad module name. How about renaming it to 'core', or 'common'?

-hilmar

On Dec 9, 2013, at 7:50 PM, Stephen Ficklin wrote:

Oh, one other request....

The 'db' and 'dbxref' tables are part of the 'General' Chado module.  In Tripal we have a 'db' module that manages the support for those tables.   We are considering renaming some of our Tripal modules to match the Chado module names to help prevent confusion, but we don't want to rename our 'db' module to 'general'.   Would it be possible to reclassify the 'db' and 'dbxref' tables into a new Chado 'DB' module?  

Also, we have a 'Project' module in Tripal that manages support for the 'project' table, but that is also in the 'General' Chado module.  Would it be unreasonable to have create a new 'Project' Chado module even though it currently only has one table?  ... although we could add a projectprop table to the schema.  

I think these would just be classification changes to the online documentation.

Thanks,
Stephen

On 12/9/2013 7:43 PM, Stephen Ficklin wrote:
Hi Scott,

Sorry for the slowness on this.   Attached are three files of proposed linker and property tables we'd would like to suggest for Chado v1.3.  These tables just link existing tables or add a 'prop' table to existing tables.  The only exception is the 'organism_relationship' table which would allow relationships between organisms that are not taxonomic (e.g. such as breeding relationships).  I'm sure there are a ton more linking/prop tables that could be defined but these are tables we've had to add in our instances of Chado.

I've tested loading these files into a Chado 1.2 instance and they load fine.  I've double checked them to make sure they look right, but it you think you can include these in the v1.3 release let me know and I can double check again to make sure I haven't missed anything.

Also, when do you think you'll release v1.3?  We're working to get a Drupal 7 version of Tripal released and it would be nice to include support for Chado v1.3 at the same time if possible.

Thanks,
Stephen


On Wed, Sep 4, 2013 at 10:39 AM, Scott Cain <[hidden email]> wrote:
Hi Stephen,

Yes, please post the DDL for the tables and some documentation on how they are used.  It's interesting that you mentioned library_stock, since FlyBase committed a library_strain table and I'm worried about how those two might overlap.

Scott




On Wed, Sep 4, 2013 at 10:17 AM, Stephen Ficklin <[hidden email]> wrote:
Hi Scott,

We have a list of linker and property tables that we have had to create for some of our sites and we've had to create them as custom tables, but they simply link two chado tables (e.g. library_stock) or are property tables.  Would you be open to including them in the v1.3 release of Chado if we can get you a list of them (including SQL)?

Thanks,
Stephen


On 8/29/2013 4:28 PM, Scott Cain wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a moz-do-not-send="true" href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk


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


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a moz-do-not-send="true" href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research


------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

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





------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Karl O. Pinc
On 12/10/2013 09:00:02 AM, Hilmar Lapp wrote:
> I can see how 'general' is a bad module name. How about renaming it
> to
> 'core', or 'common'?

I am new to chado, but under the impression that chado
modules install as PG schemas.  If so, then as long as
you're renaming, it'd be nice to stick a prefix
on all the chado modules to avoid most conflicts
with other schemas.  So, something like chado_core,
and likewise for all the rest of the chado modules.

Just a thought.

Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Sook Jung
In reply to this post by Scott Cain
Hi Scott,

Sorry I just read your email now..
As you mentioned, stock module can store strain information.
When we added natural diversity module, we discussed extensively how to deal with strain/line/cultivar. We agreed to store all hierarchical stocks (from population to cultivar/strain to clones to sample) in stock table. Their relationship can be stored in stock_relationship. That is exactly how we store chromosome, chromosomal regions, genes,mRNAs, UTRs, etc in feature table. I think adding 'strain' table at this point will bring confusion..

Naama,  other people who worked on ND module, could you comment on this?

Thanks

Sook


On Thu, Aug 29, 2013 at 4:28 PM, Scott Cain <[hidden email]> wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema



------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Scott Cain
Hi Sook,

Thanks for seeing this--looking back through this thread I realized I left Dave hanging when he asked for examples relating to the use of the stock module.  Basically, what it boils down to is any individual or group below species can be represented in the stock module, which is to say, it isn't limited to just representing what you have in the freezer

Scott


Sent from my iPad

On Dec 10, 2013, at 10:44 AM, Sook Jung <[hidden email]> wrote:

Hi Scott,

Sorry I just read your email now..
As you mentioned, stock module can store strain information.
When we added natural diversity module, we discussed extensively how to deal with strain/line/cultivar. We agreed to store all hierarchical stocks (from population to cultivar/strain to clones to sample) in stock table. Their relationship can be stored in stock_relationship. That is exactly how we store chromosome, chromosomal regions, genes,mRNAs, UTRs, etc in feature table. I think adding 'strain' table at this point will bring confusion..

Naama,  other people who worked on ND module, could you comment on this?

Thanks

Sook


On Thu, Aug 29, 2013 at 4:28 PM, Scott Cain <[hidden email]> wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema



------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Siddhartha Basu
In reply to this post by Sook Jung
Hi Scott,
I tend to agree with Sook here. The stock module(with associated tables)
seems to be good enough to strain information. We are using the stock
module extensively to migrate our strain data from our legacy oracle
database. So far we were able to model dicty strains, plasmids,
annotations by our curators, genotypes and phenotypes using most of the
tables in stock module. In that respect the proposed strain table looks a little
bit redundant IMHO.
So, is there any separate use cases for strain table(and rest of the
proposed additions) that could not be served by existing stock module.
Would be really interesting to see that.

thanks,
-siddhartha



On Tue, 10 Dec 2013, Sook Jung wrote:

>    Hi Scott,
>    Sorry I just read your email now..
>    As you mentioned, stock module can store strain information.
>    When we added natural diversity module, we discussed extensively how to
>    deal with strain/line/cultivar. We agreed to store all hierarchical stocks
>    (from population to cultivar/strain to clones to sample) in stock table.
>    Their relationship can be stored in stock_relationship. That is exactly
>    how we store chromosome, chromosomal regions, genes,mRNAs, UTRs, etc in
>    feature table. I think adding 'strain' table at this point will bring
>    confusion..
>    Naama,  other people who worked on ND module, could you comment on this?
>    Thanks
>    Sook
>
>    On Thu, Aug 29, 2013 at 4:28 PM, Scott Cain <[hidden email]> wrote:
>
>      Hello,
>      I'm thinking about changes to Chado and creating a new release (which
>      would be numbered 1.3 since it involves schema changes since the 1.23
>      release).  Before I move too far down this road, I wanted to highlight
>      changes that have been committed to the Chado schema since the 1.23
>      release and open them up to public comment.
>      The main additions to the Chado schema come from FlyBase, particularly
>      an addtional "submodule" for organism for dealing with strains as well
>      as a few additional tables for organism, like organism_pub and
>      organism_cvterm.  There are several tables added called strain,
>      strainprop, and others that as you might predict.  There are relatively
>      few comments included with the DDL, so perhaps someone at FlyBase can
>      give us the run down on how these tables are used.  One potential
>      concern I have with these tables is that it is already possible to
>      represent strains in Chado using the stock module, so how would we
>      handle that conflict if the strain tables were incorporated.
>      There are also a few other additions like library_expression,
>      library_featureprop and library_interaction which are similarly
>      uncommented so more background on how they are used would be great as
>      well.
>      I've attached a diff of the two schemas as they stand now for everyone's
>      reference.
>      Thanks,
>      Scott
>      --
>      ------------------------------------------------------------------------
>      Scott Cain, Ph. D.                                   scott at scottcain
>      dot net
>      GMOD Coordinator (http://gmod.org/)                     216-392-3087
>      Ontario Institute for Cancer Research
>      ------------------------------------------------------------------------------
>      Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>      Discover the easy way to master current and previous Microsoft
>      technologies
>      and advance your career. Get an incredible 1,500+ hours of step-by-step
>      tutorial videos with LearnDevNow. Subscribe today and save!
>      http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>      _______________________________________________
>      Gmod-schema mailing list
>      [hidden email]
>      https://lists.sourceforge.net/lists/listinfo/gmod-schema

> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk

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


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Siddhartha Basu
In reply to this post by Stephen Ficklin-2
Hi Stephen,
The analysis_organism table looks interesting, in what context it could
be used, would you mind to give a brief example.

thanks,
-siddhartha

On Mon, 09 Dec 2013, Stephen Ficklin wrote:

>    Hi Scott,
>
>    Sorry for the slowness on this.   Attached are three files of proposed
>    linker and property tables we'd would like to suggest for Chado v1.3.
>    These tables just link existing tables or add a 'prop' table to existing
>    tables.  The only exception is the 'organism_relationship' table which
>    would allow relationships between organisms that are not taxonomic (e.g.
>    such as breeding relationships).  I'm sure there are a ton more
>    linking/prop tables that could be defined but these are tables we've had
>    to add in our instances of Chado.
>
>    I've tested loading these files into a Chado 1.2 instance and they load
>    fine.  I've double checked them to make sure they look right, but it you
>    think you can include these in the v1.3 release let me know and I can
>    double check again to make sure I haven't missed anything.
>
>    Also, when do you think you'll release v1.3?  We're working to get a
>    Drupal 7 version of Tripal released and it would be nice to include
>    support for Chado v1.3 at the same time if possible.
>    Thanks,
>    Stephen
>
>    On Wed, Sep 4, 2013 at 10:39 AM, Scott Cain <[hidden email]> wrote:
>
>      Hi Stephen,
>      Yes, please post the DDL for the tables and some documentation on how
>      they are used.  It's interesting that you mentioned library_stock, since
>      FlyBase committed a library_strain table and I'm worried about how those
>      two might overlap.
>      Scott
>
>      On Wed, Sep 4, 2013 at 10:17 AM, Stephen Ficklin <[hidden email]>
>      wrote:
>
>        Hi Scott,
>
>        We have a list of linker and property tables that we have had to
>        create for some of our sites and we've had to create them as custom
>        tables, but they simply link two chado tables (e.g. library_stock) or
>        are property tables.  Would you be open to including them in the v1.3
>        release of Chado if we can get you a list of them (including SQL)?
>
>        Thanks,
>        Stephen
>
>        On 8/29/2013 4:28 PM, Scott Cain wrote:
>
>          Hello,
>          I'm thinking about changes to Chado and creating a new release
>          (which would be numbered 1.3 since it involves schema changes since
>          the 1.23 release).  Before I move too far down this road, I wanted
>          to highlight changes that have been committed to the Chado schema
>          since the 1.23 release and open them up to public comment.
>          The main additions to the Chado schema come from FlyBase,
>          particularly an addtional "submodule" for organism for dealing with
>          strains as well as a few additional tables for organism, like
>          organism_pub and organism_cvterm.  There are several tables added
>          called strain, strainprop, and others that as you might predict.
>           There are relatively few comments included with the DDL, so perhaps
>          someone at FlyBase can give us the run down on how these tables are
>          used.  One potential concern I have with these tables is that it is
>          already possible to represent strains in Chado using the stock
>          module, so how would we handle that conflict if the strain tables
>          were incorporated.
>          There are also a few other additions like library_expression,
>          library_featureprop and library_interaction which are similarly
>          uncommented so more background on how they are used would be great
>          as well.
>          I've attached a diff of the two schemas as they stand now for
>          everyone's reference.
>          Thanks,
>          Scott
>          --
>          ------------------------------------------------------------------------
>          Scott Cain, Ph. D.                                   scott at
>          scottcain dot net
>          GMOD Coordinator (http://gmod.org/)                     216-392-3087
>          Ontario Institute for Cancer Research
>
>  ------------------------------------------------------------------------------
>  Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>  Discover the easy way to master current and previous Microsoft technologies
>  and advance your career. Get an incredible 1,500+ hours of step-by-step
>  tutorial videos with LearnDevNow. Subscribe today and save!
>  http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>
>  _______________________________________________
>  Gmod-schema mailing list
>  [hidden email]
>  https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>        ------------------------------------------------------------------------------
>        Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>        Discover the easy way to master current and previous Microsoft
>        technologies
>        and advance your career. Get an incredible 1,500+ hours of
>        step-by-step
>        tutorial videos with LearnDevNow. Subscribe today and save!
>        http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>        _______________________________________________
>        Gmod-schema mailing list
>        [hidden email]
>        https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>      --
>      ------------------------------------------------------------------------
>      Scott Cain, Ph. D.                                   scott at scottcain
>      dot net
>      GMOD Coordinator (http://gmod.org/)                     216-392-3087
>      Ontario Institute for Cancer Research

> -- ================================================
> -- TABLE: analysis_organism
> -- ================================================
>
> CREATE TABLE analysis_organism (
>     analysis_organism_id serial primary key not null,
>     analysis_id integer NOT NULL,
>     organism_id integer NOT NULL,
>     CONSTRAINT analysis_organism_c1 unique (analysis_id, organism_id),
>     FOREIGN KEY (analysis_id) REFERENCES analysis(analysis_id) ON DELETE CASCADE,
>     FOREIGN KEY (organism_id) REFERENCES organism(organism_id) ON DELETE CASCADE  
> );
>
> CREATE INDEX analysis_organism_idx1 ON analysis_organism USING btree (analysis_id);
> CREATE INDEX analysis_organism_idx2 ON analysis_organism USING btree (organism_id);
>
> COMMENT ON TABLE db IS 'Links one or more analyses to organism(s)';
>
>    
> -- ================================================
> -- TABLE: feature_contact
> -- ================================================
>
> CREATE TABLE feature_contact (
>     feature_contact_id serial primary key NOT NULL,
>     feature_id integer NOT NULL,
>     contact_id integer NOT NULL,
>     CONSTRAINT feature_contact_c1 UNIQUE (feature_id, contact_id),
>     FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE,
>     FOREIGN KEY (feature_id) REFERENCES feature(feature_id) ON DELETE CASCADE
> );
>
> CREATE INDEX feature_contact_idx1 ON feature_contact USING btree (feature_id);
> CREATE INDEX feature_contact_idx2 ON feature_contact USING btree (contact_id);
>
> COMMENT ON TABLE feature_contact IS 'Links contact(s) with a feature.  Used to indicate a particular person or organization responsible for discovery or that can provide more information on a particular feature.';
>
> -- ================================================
> -- TABLE: featuremap_contact
> -- ================================================
> CREATE TABLE featuremap_contact (
>     featuremap_contact_id serial primary key NOT NULL,
>     featuremap_id integer NOT NULL,
>     contact_id integer NOT NULL,
>     CONSTRAINT featuremap_contact_c1 UNIQUE (featuremap_id, contact_id),
>     FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE,
>     FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE
> );
>
> CREATE INDEX featuremap_contact_idx1 ON featuremap_contact USING btree (featuremap_id);
> CREATE INDEX featuremap_contact_idx2 ON featuremap_contact USING btree (contact_id);
>
> COMMENT ON TABLE featuremap_contact IS 'Links contact(s) with a featuremap.  Used to indicate a particular person or organization responsible for constrution of or that can provide more information on a particular featuremap.';
>
> -- ================================================
> -- TABLE: featuremap_dbxref
> -- ================================================
>
> CREATE TABLE featuremap_dbxref (
>     featuremap_dbxref_id serial primary key NOT NULL,
>     featuremap_id integer NOT NULL,
>     dbxref_id integer NOT NULL,
>     is_current boolean DEFAULT true NOT NULL,
>     FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE,
>     FOREIGN KEY (dbxref_id) REFERENCES dbxref(dbxref_id) ON DELETE CASCADE
> );
>
> CREATE INDEX featuremap_dbxref_idx1 ON featuremap_dbxref USING btree (featuremap_id);
> CREATE INDEX featuremap_dbxref_idx2 ON featuremap_dbxref USING btree (dbxref_id);
>
> COMMENT ON TABLE feature_dbxref IS 'Links a feature to dbxrefs.';
>
> COMMENT ON COLUMN feature_dbxref.is_current IS 'True if this secondary dbxref is the most up to date accession in the corresponding db. Retired accessions should set this field to false';
>
>  
> -- ================================================
> -- TABLE: featuremap_organism
> -- ================================================
>
> CREATE TABLE featuremap_organism (
>     featuremap_organism_id serial primary key NOT NULL,
>     featuremap_id integer NOT NULL,
>     organism_id integer NOT NULL,
>     CONSTRAINT featuremap_organism_c1 UNIQUE (featuremap_id, organism_id),
>     FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE,
>     FOREIGN KEY (organism_id) REFERENCES organism(organism_id) ON DELETE CASCADE
> );
>
> CREATE INDEX featuremap_organism_idx1 ON featuremap_organism USING btree (featuremap_id);
> CREATE INDEX featuremap_organism_idx2 ON featuremap_organism USING btree (organism_id);
>
> COMMENT ON TABLE featuremap_organism IS 'Links a featuremap to the organism(s) with which it is associated.';
>
> -- ================================================
> -- TABLE: featuremap_stock
> -- ================================================
> CREATE TABLE featuremap_stock (
>     featuremap_stock_id serial primary key NOT NULL,
>     featuremap_id integer NOT NULL,
>     stock_id integer NOT NULL,
>     CONSTRAINT featuremap_stock_c1 UNIQUE (featuremap_id, stock_id),
>     FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE,
>     FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE,
>     FOREIGN KEY (stock_id) REFERENCES stock(stock_id) ON DELETE CASCADE        
> );
>
> CREATE INDEX featuremap_stock_idx1 ON featuremap_stock USING btree (featuremap_id);
> CREATE INDEX featuremap_stock_idx2 ON featuremap_stock USING btree (stock_id);
>
> COMMENT ON TABLE featuremap_stock  IS 'Links a featuremap to stock(s) with which it is associated.';
>
>
> -- ================================================
> -- TABLE: feature_stock
> -- ================================================
>
> CREATE TABLE feature_stock (
>     feature_stock_id serial primary key NOT NULL,
>     feature_id integer NOT NULL,
>     stock_id integer NOT NULL,
>     CONSTRAINT feature_stock_c1 UNIQUE (feature_id, stock_id),
>     FOREIGN KEY (feature_id) REFERENCES feature(feature_id) ON DELETE CASCADE,
>     FOREIGN KEY (stock_id) REFERENCES stock(stock_id) ON DELETE CASCADE
> );
>
> CREATE INDEX feature_stock_idx1 ON feature_stock USING btree (feature_id);
> CREATE INDEX feature_stock_idx2 ON feature_stock USING btree (stock_id);
>
> COMMENT ON TABLE feature_stock IS 'Links feature(s) to stock(s).';
>
> -- ================================================
> -- TABLE: library_contact
> -- ================================================
>
> CREATE TABLE library_contact (
>     library_contact_id serial primary key NOT NULL,
>     library_id integer NOT NULL,
>     contact_id integer NOT NULL,
>     CONSTRAINT library_contact_c1 UNIQUE (library_id, contact_id),
>     FOREIGN KEY (library_id) REFERENCES library(library_id) ON DELETE CASCADE,
>     FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE
> );
>
> CREATE INDEX library_contact_idx1 ON library USING btree (library_id);
> CREATE INDEX library_contact_idx2 ON contact USING btree (contact_id);
>
> COMMENT ON TABLE library_contact IS 'Links contact(s) with a library.  Used to indicate a particular person or organization responsible for creation of or that can provide more information on a particular library.';
>
> -- ================================================
> -- TABLE: library_stock
> -- ================================================
> CREATE TABLE library_stock (
>     library_stock_id serial primary key NOT NULL,
>     library_id integer NOT NULL,
>     stock_id integer NOT NULL,
>     CONSTRAINT library_stock_c1 UNIQUE (library_id, stock_id),
>     FOREIGN KEY (library_id) REFERENCES library(library_id) ON DELETE CASCADE,
>     FOREIGN KEY (stock_id) REFERENCES stock(stock_id) ON DELETE CASCADE
> );
>
> CREATE INDEX library_stock_idx1 ON library USING btree (library_id);
> CREATE INDEX library_stock_idx2 ON stock USING btree (stock_id);
>
> COMMENT ON TABLE library_stock IS 'Links stock(s) with a library.  Used to indicate a particular person or organization responsible for the association of or that can provide more information on a particular library''s stocks.';
>
> -- ================================================
> -- TABLE: pubauthor_contact
> -- ================================================
>
> CREATE TABLE pubauthor_contact (
>     pubauthor_contact_id serial primary key NOT NULL,
>     contact_id integer NOT NULL,
>     pubauthor_id integer NOT NULL,
>     CONSTRAINT pubauthor_contact_c1 UNIQUE (contact_id, pubauthor_id),
>     FOREIGN KEY (pubauthor_id) REFERENCES pubauthor(pubauthor_id) ON DELETE CASCADE,
>     FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE
> );
>
> CREATE INDEX pubauthor_contact_idx1 ON pubauthor USING btree (pubauthor_id);
> CREATE INDEX pubauthor_contact_idx2 ON contact USING btree (contact_id);
>
> COMMENT ON TABLE pubauthor_contact IS 'An author on a publication may have a corresponding entry in the contact table and this table can link the two.';
>
>
>
>
> -- ================================================
> -- TABLE: contact_image
> -- ================================================
> CREATE TABLE contact_image (
>     contact_image_id serial primary key NOT NULL,
>     contact_id integer NOT NULL,
>     eimage_id integer NOT NULL,
>     type_id integer,
>     CONSTRAINT contact_image_c1 UNIQUE (contact_id, eimage_id, type_id),
>     FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE,
>     FOREIGN KEY (eimage_id) REFERENCES eimage(eimage_id) ON DELETE CASCADE,
>     FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
> );
>
> CREATE INDEX contact_image_idx1 ON contact_image USING btree (contact_id);
> CREATE INDEX contact_image_idx2 ON contact_image USING btree (eimage_id);
> CREATE INDEX contact_image_idx3 ON contact_image USING btree (type_id);
>
> COMMENT ON TABLE contact_image IS 'This table is intended to link an image with an entry in the contact table. The intended purpose is to indicate the source for the image.  The type_id column can be used to indicate the relationship between the contact and the image such as the funding source, or photographer, etc.';
>  
> -- ================================================
> -- TABLE: feature_image
> -- ================================================
>
> CREATE TABLE feature_image (
>     feature_image_id serial primary key NOT NULL,
>     feature_id integer NOT NULL,
>     eimage_id integer NOT NULL,
>     FOREIGN KEY (feature_id) REFERENCES feature(feature_id) ON DELETE CASCADE,
>     FOREIGN KEY (eimage_id) REFERENCES eimage(eimage_id) ON DELETE CASCADE
> );
>
> CREATE INDEX feature_image_idx1 ON feature_image USING btree (feature_id);
> CREATE INDEX feature_image_idx2 ON feature_image USING btree (eimage_id);
>
> COMMENT ON TABLE feature_image IS 'This table is intended associate features with their respective images';
>
> -- ================================================
> -- TABLE: stock_image
> -- ================================================
>
> CREATE TABLE stock_image (
>     stock_image_id serial primary key NOT NULL,
>     stock_id integer NOT NULL,
>     eimage_id integer NOT NULL,
>     FOREIGN KEY (stock_id) REFERENCES stock(stock_id) ON DELETE CASCADE,
>     FOREIGN KEY (eimage_id) REFERENCES eimage(eimage_id) ON DELETE CASCADE
> );
>
>
> CREATE INDEX stock_image_idx1 ON stock_image USING btree (stock_id);
> CREATE INDEX stock_image_idx2 ON stock_image USING btree (eimage_id);
>
> COMMENT ON TABLE stock_image IS 'This table is intended associate stocks with their respective images.';
>
> -- ================================================
> -- TABLE: organism_image
> -- ================================================
>
> CREATE TABLE organism_image (
>     organism_image_id serial primary key NOT NULL,
>     organism_id integer NOT NULL,
>     eimage_id integer NOT NULL,
>     FOREIGN KEY (organism_id) REFERENCES organism(organism_id) ON DELETE CASCADE,
>     FOREIGN KEY (eimage_id) REFERENCES eimage(eimage_id) ON DELETE CASCADE
> );
>
> CREATE INDEX organism_image_idx1 ON organism_image USING btree (organism_id);
> CREATE INDEX organism_image_idx2 ON organism_image USING btree (eimage_id);
>
> COMMENT ON TABLE organism_image IS 'This table is intended associate organisms with their respective images.';
>
> -- ================================================
> -- TABLE: feature_project
> -- ================================================
>
> CREATE TABLE feature_project (
>     feature_project_id serial primary key NOT NULL,
>     feature_id integer NOT NULL,
>     project_id integer NOT NULL,
>     CONSTRAINT feature_project_c1 UNIQUE (feature_id, project_id),
>     FOREIGN KEY (feature_id) REFERENCES feature(feature_id) ON DELETE CASCADE,
>     FOREIGN KEY (project_id) REFERENCES project(project_id) ON DELETE CASCADE
> );
>
> CREATE INDEX feature_project_idx1 ON feature_project USING btree (feature_id);
> CREATE INDEX feature_project_idx2 ON feature_project USING btree (project_id);
>
>
> COMMENT ON TABLE feature_project IS 'This table is intended associate records in the feature table with a project.';
>  
> -- ================================================
> -- TABLE: stockcollection_db
> -- ================================================
>
> CREATE TABLE stockcollection_db (
>     stockcollection_db_id serial primary key NOT NULL,
>     stockcollection_id integer NOT NULL,
>     db_id integer NOT NULL,
>     CONSTRAINT stockcollection_db_c1 UNIQUE (stockcollection_id, db_id),
>     FOREIGN KEY (db_id) REFERENCES db(db_id) ON DELETE CASCADE,
>     FOREIGN KEY (stockcollection_id) REFERENCES stockcollection(stockcollection_id) ON DELETE CASCADE
> );
>
> CREATE INDEX stockcollection_db_idx1 ON stockcollection_db USING btree (stockcollection_id);
> CREATE INDEX stockcollection_db_idx2 ON stockcollection_db USING btree (db_id);
>
> COMMENT ON TABLE stockcollection_db IS 'Stock collections may be respresented by an external online database. This table associates a stock collection with a database where its member stocks can be found. Individual stock that are part of this collction should have entries in the stock_dbxref table with the same db_id record';
>
>

> -- ================================================
> -- TABLE: contactprop
> -- ================================================
> CREATE TABLE contactprop (
>     contactprop_id serial primary key not null,
>     contact_id integer NOT NULL,
>     type_id integer NOT NULL,
>     value text,
>     rank integer DEFAULT 0 NOT NULL,
>     CONSTRAINT contactprop_c1 UNIQUE (contact_id, type_id, rank),    
>     FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE,
>     FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
> );
>
> CREATE INDEX contactprop_idx1 ON contactprop USING btree (contact_id);
> CREATE INDEX contactprop_idx2 ON contactprop USING btree (type_id);
>
> COMMENT ON TABLE contactprop IS 'Property or attribute of a contact.';
>
>
> -- ================================================
> -- TABLE: featuremapprop
> -- ================================================
>
> CREATE TABLE featuremapprop (
>     featuremapprop_id serial primary key NOT NULL,
>     featuremap_id integer NOT NULL,
>     type_id integer NOT NULL,
>     value text,
>     rank integer DEFAULT 0 NOT NULL,
>     CONSTRAINT featuremapprop_c1 UNIQUE (featuremap_id, type_id, rank),
>     FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE,
>     FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
> );
>
> CREATE INDEX featuremapprop_idx1 ON featuremapprop USING btree (featuremap_id);
> CREATE INDEX featuremapprop_idx2 ON featuremapprop USING btree (type_id);
>
> COMMENT ON TABLE featuremapprop IS 'Property or attribute of a featuremap.';
>
> -- ================================================
> -- TABLE: featureposprop
> -- ================================================
>
> CREATE TABLE featureposprop (
>     featureposprop_id serial primary key NOT NULL,
>     featurepos_id integer NOT NULL,
>     type_id integer NOT NULL,
>     value text,
>     rank integer DEFAULT 0 NOT NULL,
>     CONSTRAINT featureposprop_c1 UNIQUE (featurepos_id, type_id, rank),
>     FOREIGN KEY (featurepos_id) REFERENCES featurepos(featurepos_id) ON DELETE CASCADE,
>     FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
> );
>
> CREATE INDEX featureposprop_idx1 ON featureposprop USING btree (featurepos_id);
> CREATE INDEX featureposprop_idx2 ON featureposprop USING btree (type_id);
>
> COMMENT ON TABLE featureposprop IS 'Property or attribute of a featurepos record.';
>
> -- ================================================
> -- TABLE: eimageprop
> -- ================================================
>
> CREATE TABLE eimageprop (
>     eimageprop_id serial primary key NOT NULL,
>     eimage_id integer NOT NULL,
>     type_id integer NOT NULL,
>     value text,
>     rank integer DEFAULT 0,
>     CONSTRAINT eimageprop_c1 UNIQUE (eimage_id, type_id, rank),
>     FOREIGN KEY (eimage_id) REFERENCES eimage(eimage_id) ON DELETE CASCADE,
>     FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
> );
>
> CREATE INDEX eimageprop_idx1 ON eimageprop USING btree (eimage_id);
> CREATE INDEX eimageprop_idx2 ON eimageprop USING btree (type_id);
>
> COMMENT ON TABLE eimageprop IS 'Property or attribute of an image.';

> -- ================================================
> -- TABLE: organism_relationship
> -- ================================================
>
> CREATE TABLE organism_relationship (
>     organism_relationship_id serial primary key NOT NULL,
>     subject_id integer NOT NULL,
>     object_id integer NOT NULL,
>     type_id integer NOT NULL,
>     rank integer DEFAULT 0 NOT NULL,
>     CONSTRAINT organism_relationship_c1 UNIQUE (subject_id, object_id, type_id, rank),
>     FOREIGN KEY (object_id) REFERENCES organism(organism_id) ON DELETE CASCADE,
>     FOREIGN KEY (subject_id) REFERENCES organism(organism_id) ON DELETE CASCADE,
>     FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE    
> );
>
> CREATE INDEX organism_relationship_idx1 ON organism_relationship USING btree (subject_id);
> CREATE INDEX organism_relationship_idx2 ON organism_relationship USING btree (object_id);
> CREATE INDEX organism_relationship_idx3 ON organism_relationship USING btree (type_id);
>
> COMMENT ON TABLE organism_relationship IS 'Stores relationships between organisms that are not taxonomic. For example, in breeding, relationships such as "sterile_with", "incompatible_with", or "fertile_with" would be approriate.';
>

> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk

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


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Scott Cain
In reply to this post by Karl O. Pinc
Hi Karl,

Actually, the individual modules don't get loaded as separate schemas in Postgres. There are a few specialty parts of chado that get loaded in separate schemas, but generally, it gets loaded into the public schema by default or another schema if specified during install.

So, renaming a module wouldn't have any effect on code already written, it would just change the way we talk about it. Accordingly, I don't have a strong opinion about it (if it affected existing code, I'd have a very strong opinion :-)

Scott


Sent from my iPad

On Dec 10, 2013, at 10:33 AM, "Karl O. Pinc" <[hidden email]> wrote:

> On 12/10/2013 09:00:02 AM, Hilmar Lapp wrote:
>> I can see how 'general' is a bad module name. How about renaming it
>> to
>> 'core', or 'common'?
>
> I am new to chado, but under the impression that chado
> modules install as PG schemas.  If so, then as long as
> you're renaming, it'd be nice to stick a prefix
> on all the chado modules to avoid most conflicts
> with other schemas.  So, something like chado_core,
> and likewise for all the rest of the chado modules.
>
> Just a thought.
>
> Karl <[hidden email]>
> Free Software:  "You don't pay back, you pay forward."
>                 -- Robert A. Heinlein
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Naama Menda-2
In reply to this post by Sook Jung
yes, the stock module should be used for any entity described here by Sook, whether it is an actual strain or clone, or an abstract concept, such as population.
It can also be used for storing more complex data , such as crosses , or samples collected in the field, etc. 
I think specimen table will be redundant. 

As for module name, changing one would cause problems for users of Bio::Chado::Schema. We'll have to change the code 'General::XXX' to 'NewName:XXX' 
We have at SGN a few dozen lines of code with this. Not too much of a big deal, but something to remember for other users too. 

Stephen - there is already a projectprop table , and a few others 




On Tue, Dec 10, 2013 at 10:44 AM, Sook Jung <[hidden email]> wrote:
Hi Scott,

Sorry I just read your email now..
As you mentioned, stock module can store strain information.
When we added natural diversity module, we discussed extensively how to deal with strain/line/cultivar. We agreed to store all hierarchical stocks (from population to cultivar/strain to clones to sample) in stock table. Their relationship can be stored in stock_relationship. That is exactly how we store chromosome, chromosomal regions, genes,mRNAs, UTRs, etc in feature table. I think adding 'strain' table at this point will bring confusion..

Naama,  other people who worked on ND module, could you comment on this?

Thanks

Sook


On Thu, Aug 29, 2013 at 4:28 PM, Scott Cain <[hidden email]> wrote:
Hello,

I'm thinking about changes to Chado and creating a new release (which would be numbered 1.3 since it involves schema changes since the 1.23 release).  Before I move too far down this road, I wanted to highlight changes that have been committed to the Chado schema since the 1.23 release and open them up to public comment.

The main additions to the Chado schema come from FlyBase, particularly an addtional "submodule" for organism for dealing with strains as well as a few additional tables for organism, like organism_pub and organism_cvterm.  There are several tables added called strain, strainprop, and others that as you might predict.  There are relatively few comments included with the DDL, so perhaps someone at FlyBase can give us the run down on how these tables are used.  One potential concern I have with these tables is that it is already possible to represent strains in Chado using the stock module, so how would we handle that conflict if the strain tables were incorporated.

There are also a few other additions like library_expression, library_featureprop and library_interaction which are similarly uncommented so more background on how they are used would be great as well.

I've attached a diff of the two schemas as they stand now for everyone's reference.

Thanks,
Scott




--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087" target="_blank">216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Stephen Ficklin-2
In reply to this post by Siddhartha Basu
Hi Siddhartha,

What we'd like to do is identify all of the analyses for an organism or
all of the organisms involved in an analysis.  Right now, the only way
to get that is to join the organism, feature, analysisfeature and
analysis tables (or at a minimum the feature & analysisfeature tables).  
If there are millions of features in the database that query takes a while.

As an example, say, you have a set of QTL experiments that have been
performed for a specific organism and you simply want to get a list of
them, it's not straight foward to get that list.  Or, if you have an
analysis where features from multiple species were combined (e.g.
family-specific unigene) and you want to find all of the organisms for
which that unigene represents that's not straightforward either.

Stephen

On 12/10/2013 11:45 AM, Siddhartha Basu wrote:

> Hi Stephen,
> The analysis_organism table looks interesting, in what context it could
> be used, would you mind to give a brief example.
>
> thanks,
> -siddhartha
>
> On Mon, 09 Dec 2013, Stephen Ficklin wrote:
>
>>     Hi Scott,
>>
>>     Sorry for the slowness on this.   Attached are three files of proposed
>>     linker and property tables we'd would like to suggest for Chado v1.3.
>>     These tables just link existing tables or add a 'prop' table to existing
>>     tables.  The only exception is the 'organism_relationship' table which
>>     would allow relationships between organisms that are not taxonomic (e.g.
>>     such as breeding relationships).  I'm sure there are a ton more
>>     linking/prop tables that could be defined but these are tables we've had
>>     to add in our instances of Chado.
>>
>>     I've tested loading these files into a Chado 1.2 instance and they load
>>     fine.  I've double checked them to make sure they look right, but it you
>>     think you can include these in the v1.3 release let me know and I can
>>     double check again to make sure I haven't missed anything.
>>
>>     Also, when do you think you'll release v1.3?  We're working to get a
>>     Drupal 7 version of Tripal released and it would be nice to include
>>     support for Chado v1.3 at the same time if possible.
>>     Thanks,
>>     Stephen
>>
>>     On Wed, Sep 4, 2013 at 10:39 AM, Scott Cain <[hidden email]> wrote:
>>
>>       Hi Stephen,
>>       Yes, please post the DDL for the tables and some documentation on how
>>       they are used.  It's interesting that you mentioned library_stock, since
>>       FlyBase committed a library_strain table and I'm worried about how those
>>       two might overlap.
>>       Scott
>>
>>       On Wed, Sep 4, 2013 at 10:17 AM, Stephen Ficklin <[hidden email]>
>>       wrote:
>>
>>         Hi Scott,
>>
>>         We have a list of linker and property tables that we have had to
>>         create for some of our sites and we've had to create them as custom
>>         tables, but they simply link two chado tables (e.g. library_stock) or
>>         are property tables.  Would you be open to including them in the v1.3
>>         release of Chado if we can get you a list of them (including SQL)?
>>
>>         Thanks,
>>         Stephen
>>
>>         On 8/29/2013 4:28 PM, Scott Cain wrote:
>>
>>           Hello,
>>           I'm thinking about changes to Chado and creating a new release
>>           (which would be numbered 1.3 since it involves schema changes since
>>           the 1.23 release).  Before I move too far down this road, I wanted
>>           to highlight changes that have been committed to the Chado schema
>>           since the 1.23 release and open them up to public comment.
>>           The main additions to the Chado schema come from FlyBase,
>>           particularly an addtional "submodule" for organism for dealing with
>>           strains as well as a few additional tables for organism, like
>>           organism_pub and organism_cvterm.  There are several tables added
>>           called strain, strainprop, and others that as you might predict.
>>            There are relatively few comments included with the DDL, so perhaps
>>           someone at FlyBase can give us the run down on how these tables are
>>           used.  One potential concern I have with these tables is that it is
>>           already possible to represent strains in Chado using the stock
>>           module, so how would we handle that conflict if the strain tables
>>           were incorporated.
>>           There are also a few other additions like library_expression,
>>           library_featureprop and library_interaction which are similarly
>>           uncommented so more background on how they are used would be great
>>           as well.
>>           I've attached a diff of the two schemas as they stand now for
>>           everyone's reference.
>>           Thanks,
>>           Scott
>>           --
>>           ------------------------------------------------------------------------
>>           Scott Cain, Ph. D.                                   scott at
>>           scottcain dot net
>>           GMOD Coordinator (http://gmod.org/)                     216-392-3087
>>           Ontario Institute for Cancer Research
>>
>>   ------------------------------------------------------------------------------
>>   Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>   Discover the easy way to master current and previous Microsoft technologies
>>   and advance your career. Get an incredible 1,500+ hours of step-by-step
>>   tutorial videos with LearnDevNow. Subscribe today and save!
>>   http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>
>>   _______________________________________________
>>   Gmod-schema mailing list
>>   [hidden email]
>>   https://lists.sourceforge.net/lists/listinfo/gmod-schema
>>
>>         ------------------------------------------------------------------------------
>>         Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>         Discover the easy way to master current and previous Microsoft
>>         technologies
>>         and advance your career. Get an incredible 1,500+ hours of
>>         step-by-step
>>         tutorial videos with LearnDevNow. Subscribe today and save!
>>         http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>         _______________________________________________
>>         Gmod-schema mailing list
>>         [hidden email]
>>         https://lists.sourceforge.net/lists/listinfo/gmod-schema
>>
>>       --
>>       ------------------------------------------------------------------------
>>       Scott Cain, Ph. D.                                   scott at scottcain
>>       dot net
>>       GMOD Coordinator (http://gmod.org/)                     216-392-3087
>>       Ontario Institute for Cancer Research
>> -- ================================================
>> -- TABLE: analysis_organism
>> -- ================================================
>>
>> CREATE TABLE analysis_organism (
>>      analysis_organism_id serial primary key not null,
>>      analysis_id integer NOT NULL,
>>      organism_id integer NOT NULL,
>>      CONSTRAINT analysis_organism_c1 unique (analysis_id, organism_id),
>>      FOREIGN KEY (analysis_id) REFERENCES analysis(analysis_id) ON DELETE CASCADE,
>>      FOREIGN KEY (organism_id) REFERENCES organism(organism_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX analysis_organism_idx1 ON analysis_organism USING btree (analysis_id);
>> CREATE INDEX analysis_organism_idx2 ON analysis_organism USING btree (organism_id);
>>
>> COMMENT ON TABLE db IS 'Links one or more analyses to organism(s)';
>>
>>      
>> -- ================================================
>> -- TABLE: feature_contact
>> -- ================================================
>>
>> CREATE TABLE feature_contact (
>>      feature_contact_id serial primary key NOT NULL,
>>      feature_id integer NOT NULL,
>>      contact_id integer NOT NULL,
>>      CONSTRAINT feature_contact_c1 UNIQUE (feature_id, contact_id),
>>      FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE,
>>      FOREIGN KEY (feature_id) REFERENCES feature(feature_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX feature_contact_idx1 ON feature_contact USING btree (feature_id);
>> CREATE INDEX feature_contact_idx2 ON feature_contact USING btree (contact_id);
>>
>> COMMENT ON TABLE feature_contact IS 'Links contact(s) with a feature.  Used to indicate a particular person or organization responsible for discovery or that can provide more information on a particular feature.';
>>
>> -- ================================================
>> -- TABLE: featuremap_contact
>> -- ================================================
>> CREATE TABLE featuremap_contact (
>>      featuremap_contact_id serial primary key NOT NULL,
>>      featuremap_id integer NOT NULL,
>>      contact_id integer NOT NULL,
>>      CONSTRAINT featuremap_contact_c1 UNIQUE (featuremap_id, contact_id),
>>      FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE,
>>      FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX featuremap_contact_idx1 ON featuremap_contact USING btree (featuremap_id);
>> CREATE INDEX featuremap_contact_idx2 ON featuremap_contact USING btree (contact_id);
>>
>> COMMENT ON TABLE featuremap_contact IS 'Links contact(s) with a featuremap.  Used to indicate a particular person or organization responsible for constrution of or that can provide more information on a particular featuremap.';
>>
>> -- ================================================
>> -- TABLE: featuremap_dbxref
>> -- ================================================
>>
>> CREATE TABLE featuremap_dbxref (
>>      featuremap_dbxref_id serial primary key NOT NULL,
>>      featuremap_id integer NOT NULL,
>>      dbxref_id integer NOT NULL,
>>      is_current boolean DEFAULT true NOT NULL,
>>      FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE,
>>      FOREIGN KEY (dbxref_id) REFERENCES dbxref(dbxref_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX featuremap_dbxref_idx1 ON featuremap_dbxref USING btree (featuremap_id);
>> CREATE INDEX featuremap_dbxref_idx2 ON featuremap_dbxref USING btree (dbxref_id);
>>
>> COMMENT ON TABLE feature_dbxref IS 'Links a feature to dbxrefs.';
>>
>> COMMENT ON COLUMN feature_dbxref.is_current IS 'True if this secondary dbxref is the most up to date accession in the corresponding db. Retired accessions should set this field to false';
>>
>>    
>> -- ================================================
>> -- TABLE: featuremap_organism
>> -- ================================================
>>
>> CREATE TABLE featuremap_organism (
>>      featuremap_organism_id serial primary key NOT NULL,
>>      featuremap_id integer NOT NULL,
>>      organism_id integer NOT NULL,
>>      CONSTRAINT featuremap_organism_c1 UNIQUE (featuremap_id, organism_id),
>>      FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE,
>>      FOREIGN KEY (organism_id) REFERENCES organism(organism_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX featuremap_organism_idx1 ON featuremap_organism USING btree (featuremap_id);
>> CREATE INDEX featuremap_organism_idx2 ON featuremap_organism USING btree (organism_id);
>>
>> COMMENT ON TABLE featuremap_organism IS 'Links a featuremap to the organism(s) with which it is associated.';
>>
>> -- ================================================
>> -- TABLE: featuremap_stock
>> -- ================================================
>> CREATE TABLE featuremap_stock (
>>      featuremap_stock_id serial primary key NOT NULL,
>>      featuremap_id integer NOT NULL,
>>      stock_id integer NOT NULL,
>>      CONSTRAINT featuremap_stock_c1 UNIQUE (featuremap_id, stock_id),
>>      FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE,
>>      FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE,
>>      FOREIGN KEY (stock_id) REFERENCES stock(stock_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX featuremap_stock_idx1 ON featuremap_stock USING btree (featuremap_id);
>> CREATE INDEX featuremap_stock_idx2 ON featuremap_stock USING btree (stock_id);
>>
>> COMMENT ON TABLE featuremap_stock  IS 'Links a featuremap to stock(s) with which it is associated.';
>>
>>
>> -- ================================================
>> -- TABLE: feature_stock
>> -- ================================================
>>
>> CREATE TABLE feature_stock (
>>      feature_stock_id serial primary key NOT NULL,
>>      feature_id integer NOT NULL,
>>      stock_id integer NOT NULL,
>>      CONSTRAINT feature_stock_c1 UNIQUE (feature_id, stock_id),
>>      FOREIGN KEY (feature_id) REFERENCES feature(feature_id) ON DELETE CASCADE,
>>      FOREIGN KEY (stock_id) REFERENCES stock(stock_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX feature_stock_idx1 ON feature_stock USING btree (feature_id);
>> CREATE INDEX feature_stock_idx2 ON feature_stock USING btree (stock_id);
>>
>> COMMENT ON TABLE feature_stock IS 'Links feature(s) to stock(s).';
>>
>> -- ================================================
>> -- TABLE: library_contact
>> -- ================================================
>>
>> CREATE TABLE library_contact (
>>      library_contact_id serial primary key NOT NULL,
>>      library_id integer NOT NULL,
>>      contact_id integer NOT NULL,
>>      CONSTRAINT library_contact_c1 UNIQUE (library_id, contact_id),
>>      FOREIGN KEY (library_id) REFERENCES library(library_id) ON DELETE CASCADE,
>>      FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX library_contact_idx1 ON library USING btree (library_id);
>> CREATE INDEX library_contact_idx2 ON contact USING btree (contact_id);
>>
>> COMMENT ON TABLE library_contact IS 'Links contact(s) with a library.  Used to indicate a particular person or organization responsible for creation of or that can provide more information on a particular library.';
>>
>> -- ================================================
>> -- TABLE: library_stock
>> -- ================================================
>> CREATE TABLE library_stock (
>>      library_stock_id serial primary key NOT NULL,
>>      library_id integer NOT NULL,
>>      stock_id integer NOT NULL,
>>      CONSTRAINT library_stock_c1 UNIQUE (library_id, stock_id),
>>      FOREIGN KEY (library_id) REFERENCES library(library_id) ON DELETE CASCADE,
>>      FOREIGN KEY (stock_id) REFERENCES stock(stock_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX library_stock_idx1 ON library USING btree (library_id);
>> CREATE INDEX library_stock_idx2 ON stock USING btree (stock_id);
>>
>> COMMENT ON TABLE library_stock IS 'Links stock(s) with a library.  Used to indicate a particular person or organization responsible for the association of or that can provide more information on a particular library''s stocks.';
>>
>> -- ================================================
>> -- TABLE: pubauthor_contact
>> -- ================================================
>>
>> CREATE TABLE pubauthor_contact (
>>      pubauthor_contact_id serial primary key NOT NULL,
>>      contact_id integer NOT NULL,
>>      pubauthor_id integer NOT NULL,
>>      CONSTRAINT pubauthor_contact_c1 UNIQUE (contact_id, pubauthor_id),
>>      FOREIGN KEY (pubauthor_id) REFERENCES pubauthor(pubauthor_id) ON DELETE CASCADE,
>>      FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX pubauthor_contact_idx1 ON pubauthor USING btree (pubauthor_id);
>> CREATE INDEX pubauthor_contact_idx2 ON contact USING btree (contact_id);
>>
>> COMMENT ON TABLE pubauthor_contact IS 'An author on a publication may have a corresponding entry in the contact table and this table can link the two.';
>>
>>
>>
>>
>> -- ================================================
>> -- TABLE: contact_image
>> -- ================================================
>> CREATE TABLE contact_image (
>>      contact_image_id serial primary key NOT NULL,
>>      contact_id integer NOT NULL,
>>      eimage_id integer NOT NULL,
>>      type_id integer,
>>      CONSTRAINT contact_image_c1 UNIQUE (contact_id, eimage_id, type_id),
>>      FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE,
>>      FOREIGN KEY (eimage_id) REFERENCES eimage(eimage_id) ON DELETE CASCADE,
>>      FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX contact_image_idx1 ON contact_image USING btree (contact_id);
>> CREATE INDEX contact_image_idx2 ON contact_image USING btree (eimage_id);
>> CREATE INDEX contact_image_idx3 ON contact_image USING btree (type_id);
>>
>> COMMENT ON TABLE contact_image IS 'This table is intended to link an image with an entry in the contact table. The intended purpose is to indicate the source for the image.  The type_id column can be used to indicate the relationship between the contact and the image such as the funding source, or photographer, etc.';
>>  
>> -- ================================================
>> -- TABLE: feature_image
>> -- ================================================
>>
>> CREATE TABLE feature_image (
>>      feature_image_id serial primary key NOT NULL,
>>      feature_id integer NOT NULL,
>>      eimage_id integer NOT NULL,
>>      FOREIGN KEY (feature_id) REFERENCES feature(feature_id) ON DELETE CASCADE,
>>      FOREIGN KEY (eimage_id) REFERENCES eimage(eimage_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX feature_image_idx1 ON feature_image USING btree (feature_id);
>> CREATE INDEX feature_image_idx2 ON feature_image USING btree (eimage_id);
>>
>> COMMENT ON TABLE feature_image IS 'This table is intended associate features with their respective images';
>>
>> -- ================================================
>> -- TABLE: stock_image
>> -- ================================================
>>
>> CREATE TABLE stock_image (
>>      stock_image_id serial primary key NOT NULL,
>>      stock_id integer NOT NULL,
>>      eimage_id integer NOT NULL,
>>      FOREIGN KEY (stock_id) REFERENCES stock(stock_id) ON DELETE CASCADE,
>>      FOREIGN KEY (eimage_id) REFERENCES eimage(eimage_id) ON DELETE CASCADE
>> );
>>
>>
>> CREATE INDEX stock_image_idx1 ON stock_image USING btree (stock_id);
>> CREATE INDEX stock_image_idx2 ON stock_image USING btree (eimage_id);
>>
>> COMMENT ON TABLE stock_image IS 'This table is intended associate stocks with their respective images.';
>>
>> -- ================================================
>> -- TABLE: organism_image
>> -- ================================================
>>
>> CREATE TABLE organism_image (
>>      organism_image_id serial primary key NOT NULL,
>>      organism_id integer NOT NULL,
>>      eimage_id integer NOT NULL,
>>      FOREIGN KEY (organism_id) REFERENCES organism(organism_id) ON DELETE CASCADE,
>>      FOREIGN KEY (eimage_id) REFERENCES eimage(eimage_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX organism_image_idx1 ON organism_image USING btree (organism_id);
>> CREATE INDEX organism_image_idx2 ON organism_image USING btree (eimage_id);
>>
>> COMMENT ON TABLE organism_image IS 'This table is intended associate organisms with their respective images.';
>>
>> -- ================================================
>> -- TABLE: feature_project
>> -- ================================================
>>
>> CREATE TABLE feature_project (
>>      feature_project_id serial primary key NOT NULL,
>>      feature_id integer NOT NULL,
>>      project_id integer NOT NULL,
>>      CONSTRAINT feature_project_c1 UNIQUE (feature_id, project_id),
>>      FOREIGN KEY (feature_id) REFERENCES feature(feature_id) ON DELETE CASCADE,
>>      FOREIGN KEY (project_id) REFERENCES project(project_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX feature_project_idx1 ON feature_project USING btree (feature_id);
>> CREATE INDEX feature_project_idx2 ON feature_project USING btree (project_id);
>>
>>
>> COMMENT ON TABLE feature_project IS 'This table is intended associate records in the feature table with a project.';
>>    
>> -- ================================================
>> -- TABLE: stockcollection_db
>> -- ================================================
>>
>> CREATE TABLE stockcollection_db (
>>      stockcollection_db_id serial primary key NOT NULL,
>>      stockcollection_id integer NOT NULL,
>>      db_id integer NOT NULL,
>>      CONSTRAINT stockcollection_db_c1 UNIQUE (stockcollection_id, db_id),
>>      FOREIGN KEY (db_id) REFERENCES db(db_id) ON DELETE CASCADE,
>>      FOREIGN KEY (stockcollection_id) REFERENCES stockcollection(stockcollection_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX stockcollection_db_idx1 ON stockcollection_db USING btree (stockcollection_id);
>> CREATE INDEX stockcollection_db_idx2 ON stockcollection_db USING btree (db_id);
>>
>> COMMENT ON TABLE stockcollection_db IS 'Stock collections may be respresented by an external online database. This table associates a stock collection with a database where its member stocks can be found. Individual stock that are part of this collction should have entries in the stock_dbxref table with the same db_id record';
>>
>>
>> -- ================================================
>> -- TABLE: contactprop
>> -- ================================================
>> CREATE TABLE contactprop (
>>      contactprop_id serial primary key not null,
>>      contact_id integer NOT NULL,
>>      type_id integer NOT NULL,
>>      value text,
>>      rank integer DEFAULT 0 NOT NULL,
>>      CONSTRAINT contactprop_c1 UNIQUE (contact_id, type_id, rank),
>>      FOREIGN KEY (contact_id) REFERENCES contact(contact_id) ON DELETE CASCADE,
>>      FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX contactprop_idx1 ON contactprop USING btree (contact_id);
>> CREATE INDEX contactprop_idx2 ON contactprop USING btree (type_id);
>>
>> COMMENT ON TABLE contactprop IS 'Property or attribute of a contact.';
>>
>>
>> -- ================================================
>> -- TABLE: featuremapprop
>> -- ================================================
>>
>> CREATE TABLE featuremapprop (
>>      featuremapprop_id serial primary key NOT NULL,
>>      featuremap_id integer NOT NULL,
>>      type_id integer NOT NULL,
>>      value text,
>>      rank integer DEFAULT 0 NOT NULL,
>>      CONSTRAINT featuremapprop_c1 UNIQUE (featuremap_id, type_id, rank),
>>      FOREIGN KEY (featuremap_id) REFERENCES featuremap(featuremap_id) ON DELETE CASCADE,
>>      FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX featuremapprop_idx1 ON featuremapprop USING btree (featuremap_id);
>> CREATE INDEX featuremapprop_idx2 ON featuremapprop USING btree (type_id);
>>
>> COMMENT ON TABLE featuremapprop IS 'Property or attribute of a featuremap.';
>>
>> -- ================================================
>> -- TABLE: featureposprop
>> -- ================================================
>>
>> CREATE TABLE featureposprop (
>>      featureposprop_id serial primary key NOT NULL,
>>      featurepos_id integer NOT NULL,
>>      type_id integer NOT NULL,
>>      value text,
>>      rank integer DEFAULT 0 NOT NULL,
>>      CONSTRAINT featureposprop_c1 UNIQUE (featurepos_id, type_id, rank),
>>      FOREIGN KEY (featurepos_id) REFERENCES featurepos(featurepos_id) ON DELETE CASCADE,
>>      FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX featureposprop_idx1 ON featureposprop USING btree (featurepos_id);
>> CREATE INDEX featureposprop_idx2 ON featureposprop USING btree (type_id);
>>
>> COMMENT ON TABLE featureposprop IS 'Property or attribute of a featurepos record.';
>>
>> -- ================================================
>> -- TABLE: eimageprop
>> -- ================================================
>>
>> CREATE TABLE eimageprop (
>>      eimageprop_id serial primary key NOT NULL,
>>      eimage_id integer NOT NULL,
>>      type_id integer NOT NULL,
>>      value text,
>>      rank integer DEFAULT 0,
>>      CONSTRAINT eimageprop_c1 UNIQUE (eimage_id, type_id, rank),
>>      FOREIGN KEY (eimage_id) REFERENCES eimage(eimage_id) ON DELETE CASCADE,
>>      FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX eimageprop_idx1 ON eimageprop USING btree (eimage_id);
>> CREATE INDEX eimageprop_idx2 ON eimageprop USING btree (type_id);
>>
>> COMMENT ON TABLE eimageprop IS 'Property or attribute of an image.';
>> -- ================================================
>> -- TABLE: organism_relationship
>> -- ================================================
>>
>> CREATE TABLE organism_relationship (
>>      organism_relationship_id serial primary key NOT NULL,
>>      subject_id integer NOT NULL,
>>      object_id integer NOT NULL,
>>      type_id integer NOT NULL,
>>      rank integer DEFAULT 0 NOT NULL,
>>      CONSTRAINT organism_relationship_c1 UNIQUE (subject_id, object_id, type_id, rank),
>>      FOREIGN KEY (object_id) REFERENCES organism(organism_id) ON DELETE CASCADE,
>>      FOREIGN KEY (subject_id) REFERENCES organism(organism_id) ON DELETE CASCADE,
>>      FOREIGN KEY (type_id) REFERENCES cvterm(cvterm_id) ON DELETE CASCADE
>> );
>>
>> CREATE INDEX organism_relationship_idx1 ON organism_relationship USING btree (subject_id);
>> CREATE INDEX organism_relationship_idx2 ON organism_relationship USING btree (object_id);
>> CREATE INDEX organism_relationship_idx3 ON organism_relationship USING btree (type_id);
>>
>> COMMENT ON TABLE organism_relationship IS 'Stores relationships between organisms that are not taxonomic. For example, in breeding, relationships such as "sterile_with", "incompatible_with", or "fertile_with" would be approriate.';
>>
>> ------------------------------------------------------------------------------
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Gmod-schema mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Stephen Ficklin-2
In reply to this post by Naama Menda-2
Hi Naama,

>
> Stephen - there is already a projectprop table , and a few others
> https://github.com/solgenomics/bio-chado-schema/tree/master/lib/Bio/Chado/Schema/Result/Project
>

Oh right :-)  I didn't look closely... Thanks for the clarification.

Stephen

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Opening up comments on changes to Chado

Karl O. Pinc
In reply to this post by Scott Cain
On 12/10/2013 10:46:13 AM, Scott Cain wrote:
> Hi Karl,
>
> Actually, the individual modules don't get loaded as separate schemas
> in Postgres.

Oops.  Sorry to add noise.




Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
123