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