gusdev-gusdev

[Gusdev-gusdev] Phenotype tables

[Arnaud K. <ax...@sa...>]

  Hi everyone

I've attached SQL statements and doc for draft tables and views for 
holding genetic data.

You'll find statements for:

Allele tables:

 * Allele table,
 * AlleleInstance table,
 * AlleleFeature view,

 * A Complementation table which stores complementation data. It works 
as a reference table to another allele. It can be an internal or an 
external reference. There are three types of complementation references 
: "complements", "complemented_by", "fails_to_complement".

Controlled vocabulary tables:
 * PhenotypeClass - controlled vocabulary to classify the allele effects 
- recessif/dominant - lethal,
 * Mutagen - controlled vocabulary of chemical products used to generate 
mutants,

 and
 * AllelePhenotypeClass,
 * AlleleMutagen,
 * AllelePhenotype,
 * AlleleComplementation,

 * RNAi table to store RNAi constructs data,
 * RNAiPhenotype table.

Please let me know if you have any questions or comments.
cheers
Arnaud

Re: [Gusdev-gusdev] Phenotype tables

[Chris S. <sto...@pc...>]

Hi Arnaud,
These look fine to me and represent what we've discussed. Thanks for 
putting this together!
Cheers,
Chris

On Monday, November 11, 2002, at 06:53  AM, Arnaud Kerhornou wrote:

>  Hi everyone
>
> I've attached SQL statements and doc for draft tables and views for 
> holding genetic data.
>
> You'll find statements for:
>
> Allele tables:
>
> * Allele table,
> * AlleleInstance table,
> * AlleleFeature view,
>
> * A Complementation table which stores complementation data. It works 
> as a reference table to another allele. It can be an internal or an 
> external reference. There are three types of complementation 
> references : "complements", "complemented_by", "fails_to_complement".
>
> Controlled vocabulary tables:
> * PhenotypeClass - controlled vocabulary to classify the allele 
> effects - recessif/dominant - lethal,
> * Mutagen - controlled vocabulary of chemical products used to 
> generate mutants,
>
> and
> * AllelePhenotypeClass,
> * AlleleMutagen,
> * AllelePhenotype,
> * AlleleComplementation,
>
> * RNAi table to store RNAi constructs data,
> * RNAiPhenotype table.
>
> Please let me know if you have any questions or comments.
> cheers
> Arnaud
> <phenotype.tar.gz>

[Gusdev-gusdev] Re: Phenotype tables - Interactions

[Arnaud K. <ax...@sa...>]

Hi Chris

I didn't include anything about genetic interactions even if in the 
future we will want to store them. I've reviewed the interaction table 
and I've got some thoughts about this table.

Genetic interactions may involve more than one effector/target. If we 
want to make the Interaction table generic, we need to store more than 
one effector and more than one target. I don't have any use cases yet, 
but I can ask around one if needed.
An extra controlled vocabulary is needed. This controlled vocabulary 
will be used to classify the behaviour of the effector for a given 
interaction.
e.g. Allele1 "inhibits" the expression of Allele2.

Regarding physical interactions, there are two cases in which it will be 
useful to annotate them:
    * Transient interactions associated with a function, e.g. a protein 
regulating the transcription will be interacting with DNA.
    * Structural interactions involved in the formation of a complex. In 
that case, we can associate component interactions with the complex they 
are involved in. Some of these interactions are experimentally 
characterized, others are hypothetical.

Currently in GUS, a complex is a set of components. Would it be possible 
to associate a complex with a set of interactions as well ?

The other point I didn't mention in my previous email was the review of 
the phenotype table. Would it be possible to associate phenotypic data 
with GO terms ?

cheers
Arnaud

Chris Stoeckert wrote:

> Hi Arnaud,
> These look fine to me and represent what we've discussed. Thanks for 
> putting this together!
> Cheers,
> Chris
>
> On Monday, November 11, 2002, at 06:53  AM, Arnaud Kerhornou wrote:
>
>>  Hi everyone
>>
>> I've attached SQL statements and doc for draft tables and views for 
>> holding genetic data.
>>
>> You'll find statements for:
>>
>> Allele tables:
>>
>> * Allele table,
>> * AlleleInstance table,
>> * AlleleFeature view,
>>
>> * A Complementation table which stores complementation data. It works 
>> as a reference table to another allele. It can be an internal or an 
>> external reference. There are three types of complementation 
>> references : "complements", "complemented_by", "fails_to_complement".
>>
>> Controlled vocabulary tables:
>> * PhenotypeClass - controlled vocabulary to classify the allele 
>> effects - recessif/dominant - lethal,
>> * Mutagen - controlled vocabulary of chemical products used to 
>> generate mutants,
>>
>> and
>> * AllelePhenotypeClass,
>> * AlleleMutagen,
>> * AllelePhenotype,
>> * AlleleComplementation,
>>
>> * RNAi table to store RNAi constructs data,
>> * RNAiPhenotype table.
>>
>> Please let me know if you have any questions or comments.
>> cheers
>> Arnaud
>> <phenotype.tar.gz>
>
>

Re: [Gusdev-gusdev] Re: Phenotype tables - Interactions

[<cra...@pc...>]

Arnaud-

> I didn't include anything about genetic interactions even if in the
> future we will want to store them. I've reviewed the interaction table
> and I've got some thoughts about this table.
> 
> Genetic interactions may involve more than one effector/target. If we
> want to make the Interaction table generic, we need to store more than
> one effector and more than one target. I don't have any use cases yet,
> but I can ask around one if needed.

This makes sense to me, since not all groups of effectors or targets will 
necessarily be Complexes.

> An extra controlled vocabulary is needed. This controlled vocabulary
> will be used to classify the behaviour of the effector for a given
> interaction.
> e.g. Allele1 "inhibits" the expression of Allele2.

This also sounds like a good idea; I don't see anywhere that we represent
this currently.  

> Regarding physical interactions, there are two cases in which it will be
> useful to annotate them:
>     * Transient interactions associated with a function, e.g. a protein
> regulating the transcription will be interacting with DNA.
>     * Structural interactions involved in the formation of a complex. In
> that case, we can associate component interactions with the complex they
> are involved in. Some of these interactions are experimentally
> characterized, others are hypothetical.

I don't think we have to make any changes to the Interaction table in order
to use it for representing physical interactions, right?  Presumably the 
physical interactions will simply be a subset of the interactions enumerated
in the controlled vocabulary that we're going to create.  The only thing I
noticed when looking at the DoTS::Interaction table is that there's no way 
of representing interactions for which "direction" is not a meaningful 
concept.  (I assume there will be such interactions, particularly when we 
consider physical interactions.)  So maybe we could add a "has_direction" 
column, which would only be non-NULL in the case that direction_is_known > 0
(or which should indicate that the direction_is_known column should be 
ignored, if set to 1.)

> Currently in GUS, a complex is a set of components. Would it be possible
> to associate a complex with a set of interactions as well ?

It should be, since the DoTS::Interaction table can reference any other table
in the database (including Complex.)  Or are you asking about an explicit
representation for an "InteractionSet" (whatever that would mean)?   I'm not
sure I completely understand this question.

> The other point I didn't mention in my previous email was the review of
> the phenotype table. Would it be possible to associate phenotypic data
> with GO terms ?

I believe we should be able to use the DoTS::GOTermAssociation table to 
associate GO terms with the appropriate rows in the Phenotype table.  In
gusdev right now we're using a special-purpose table called ECGOFunctionMap
to represent the mapping between the enzyme classification numbers and the
GO Function terms, but I believe that the only reason we did this is because
we didn't have the GOTermAssociation table to work with in GUSdev.

Jonathan

-- 
Jonathan Crabtree
Center for Bioinformatics, University of Pennsylvania
1406 Blockley Hall, 423 Guardian Drive Philadelphia, PA 19104-6021
215-573-3115

Re: [Gusdev-gusdev] Re: Phenotype tables - Interactions

[Arnaud K. <ax...@sa...>]

cra...@pc... wrote:

>Arnaud-
>
>  
>
>>I didn't include anything about genetic interactions even if in the
>>future we will want to store them. I've reviewed the interaction table
>>and I've got some thoughts about this table.
>>
>>Genetic interactions may involve more than one effector/target. If we
>>want to make the Interaction table generic, we need to store more than
>>one effector and more than one target. I don't have any use cases yet,
>>but I can ask around one if needed.
>>
>
>This makes sense to me, since not all groups of effectors or targets will 
>necessarily be Complexes.
>
>  
>
>>An extra controlled vocabulary is needed. This controlled vocabulary
>>will be used to classify the behaviour of the effector for a given
>>interaction.
>>e.g. Allele1 "inhibits" the expression of Allele2.
>>    
>>
>
>This also sounds like a good idea; I don't see anywhere that we represent
>this currently. 
>
>  
>
>>Regarding physical interactions, there are two cases in which it will be
>>useful to annotate them:
>>    * Transient interactions associated with a function, e.g. a protein
>>regulating the transcription will be interacting with DNA.
>>    * Structural interactions involved in the formation of a complex. In
>>that case, we can associate component interactions with the complex they
>>are involved in. Some of these interactions are experimentally
>>characterized, others are hypothetical.
>>    
>>
>
>I don't think we have to make any changes to the Interaction table in order
>to use it for representing physical interactions, right? 
>
right!

> Presumably the 
>physical interactions will simply be a subset of the interactions enumerated
>in the controlled vocabulary that we're going to create. 
>
Do you mean an extra controlled vocabulary to specify the type of 
interactions ?

> The only thing I
>noticed when looking at the DoTS::Interaction table is that there's no way 
>of representing interactions for which "direction" is not a meaningful 
>concept.  (I assume there will be such interactions, particularly when we 
>consider physical interactions.)  So maybe we could add a "has_direction" 
>column, which would only be non-NULL in the case that direction_is_known > 0
>(or which should indicate that the direction_is_known column should be 
>ignored, if set to 1.)
>  
>
I agree, I don't think the direction information is useful for some 
interactions such as structural ones.

>  
>
>>Currently in GUS, a complex is a set of components. Would it be possible
>>to associate a complex with a set of interactions as well ?
>>    
>>
>
>It should be, since the DoTS::Interaction table can reference any other table
>in the database (including Complex.)  Or are you asking about an explicit
>representation for an "InteractionSet" (whatever that would mean)?   I'm not
>sure I completely understand this question.
>
Well, a use case could be:

Complex A is made of 4 proteins components:
Component1 interacts with component 2, component3 and component4 and 
these interactions are experimentally characterized.
Component2 may interact with component3.

A query would be : "give me all the interactions between components of 
Complex A"

I was thinking of adding a complex_id attribute to the interaction table 
to associate interactions between components with a given complex, but 
actually, as components are already associated with this given complex, 
an extra attribute may not be needed. So it should be fine like it is now.

>  
>
>>The other point I didn't mention in my previous email was the review of
>>the phenotype table. Would it be possible to associate phenotypic data
>>with GO terms ?
>>    
>>
>
>I believe we should be able to use the DoTS::GOTermAssociation table to 
>associate GO terms with the appropriate rows in the Phenotype table.  In
>gusdev right now we're using a special-purpose table called ECGOFunctionMap
>to represent the mapping between the enzyme classification numbers and the
>GO Function terms, but I believe that the only reason we did this is because
>we didn't have the GOTermAssociation table to work with in GUSdev.
>  
>
sounds fine

>Jonathan
>
>  
>
cheers
Arnaud