Interaction type: direct interaction could be more specific

[noedelta]

This is mainly a BioPAX/pathway database compatility issue.

It is difficult to figure out if a binding event creates a complex in the current interaction type CV. "direct interaction" looks like it might be the correct term to signify this, but it seems to be too general. Maybe a term called "complex assembly" (to match the BioPAX complexAssembly class) could be added as a child of direct interaction (or mayb direct interaction means complex assembly, in which case 'complex assembly' could be added as a synonym.

This is not the case for enzymatic reactions and BioPAX, since there is a clear interaction type for this.

Thanks, Gary

Reported by: gbader

[noedelta]

Logged In: YES user_id=719654

uh... I'm afraid I don't understand what 'complex assembly' is supposed to mean. can you please elaborate ?

lukasz

Original comment by: lukasz99

[noedelta]

Logged In: YES user_id=28789

Complex assembly: A + B -> AB (where AB is a new object of type 'complex'). This is an event that results in a complex (the product).

In PSI-MI, there is no difference between event and product (which is the more convenient way to store things for proteomics data). So if you say interaction: A + B, it could mean many types of events e.g. a catalyzed biochemical reaction, a complex assembly event, some kind of generic control event, etc. BioPAX has specialized classes (subclasses of the physicalInteraction class) that handle these specific cases. If a user wants to map from PSI-MI, then they can map to the generic physicalInteraction class, but if they know the PSI-MI interaction type and some other information, they can map to more specific classes, like complexAssembly.

Original comment by: gbader

[noedelta]

Logged In: YES user_id=719654

i see.. but then it implies PSI-MI is to model kinetics whereas, at least at the moment, it only describes static situation 'A, B, C, .... form a complex'. Thus a notion of 'event' is an idea completely foreign to both MIF and related ontologies, don't you think ? The changes (pretty dramatic, I''d guess) would have to be made to both ontology but, most importantly, to MIF...

lukasz

Original comment by: lukasz99

[noedelta]

Logged In: YES user_id=28789

I don't think PSI-MI needs to change its model at all. It already describes one type of event, which is biochemical reaction - but not in the core of the model, just in the interaction type (and role CV). A PSI-MI interaction with interaction type=biochemical reaction and role=enzyme, enzyme target almost describes an event. Maybe I misunderstood the role CV. As an example use case, the complexAssembly interaction type could be used to annotate the DLRP interactions in DIP - it's not really an event, but it is extra annotation which states that ligand-receptor form a complex (so maybe event was the wrong thing to say in my previous post - it's almost an event). If you don't explicitly say this, then you can't differentiate between the DLRP case and another interaction in DIP - no?

Original comment by: gbader

[noedelta]

Logged In: YES user_id=653048

Understand the distinction need and that currently PSI is doing it partially. The trend in PSI group is to have at some point (on PSI 3) a 'interaction result' element, mostly to describe modified protein resulting from an interaction. However the description of complexes as interaction or results of an interaction is still an open issue.

Currently on PSI 2.5 the only case corresponding to your 'complex assembly' is hierarchical built up of complexes allowing to have previous interaction as 'participant' -interactor type. This is in theory what could be done but I don't know if it is really being used in such way.

luisa

Original comment by: luisa_montecchi

[noedelta]

Logged In: YES user_id=653048

Rejected at Geneva PSI meeting. Out of the scope of the current CV interaction type. For mapping with biopax, consider that all interactions that have interactor_type == 'interaction' are complexes.

Original comment by: luisa_montecchi

[noedelta]

• status: open --> closed

Original comment by: luisa_montecchi