Re: [Gusdev-gusdev] GUS 3.0 schema changes

[Jonathan C. <cra...@sn...>]

Joan-

> So with the way the tables complex and interaction are set up now, if a complex
> participates in an interaction
> to find this then you have to see if the row_id in complexComponent is also a
> row_id in row set member of interaction.

Not quite; if the complex is itself the effector or target of the
interaction then you'd want to join ComplexComponent.complex_id (not row_id)
with RowSetMember.row_id (and you'd also constrain RowSetMember.table_id with
the table_id for Complex.)  You'd only use the row_id of ComplexComponent
if your Complex of interest was itself a component of another Complex that
acted as the effector or target.

> With the interaction table two things are interacting (why is row set needed)?

No; as discussed previously, we decided to extend the Interaction table
to represent the interaction of two *sets* of things (where those sets of
things cannot be represented as Complexes.)  Given that, we had to add
something like the RowSet table.

> I am confused about why it is not possible to build up sequential interactions
> using just single interacting components (see below).

I believe that it *is* possible to build up sequential interactions using
single interacting components; this is what the Pathway and PathwayInteraction
tables allow you to do.  Having to create a new RowSet object--even when
you have only a single effector/target--does require some extra work, but
it's by no means impossible.  This is what I was talking about last week
when I said that I could have left the Interaction table as it was
originally (i.e., with a table_id & row_id for both effector and target.)
However, we decided that we might as well replace these with references to
RowSet, so that the joins would always be consistent regardless of the
number of objects acting as the target/effector of the Interaction.

> Then maybe use pathwayinteraction and pathway (even if the pathway just consists
> of a A binds B which binds C).  Or do you want to model biological reactions
> which seems sequential to me like a pathway ?

The goal is simply to be able to represent interactions between sets of
things.  If this happens not to be a useful feature then we could consider
doing away with it.  I'm not crazy about the extra joins that it entails,
but at the time it seemed like it would be a reasonable generalization to
make (and nobody objected when it was done.)  We could consider changing
it back, but definitely not until after I've finished the 3.0 migration,
since I've already moved the Pathway data into the new Interaction schema.

> >>>  (the target.)  Previously the Interaction table could only
> >>> represent the interaction
> >>>  between a single pair of entities (OK if they happened to be
> >>> Complexes, for example,
> >>>  but a potential problem in other situations.)
>
>  but a potential problem in other situations?  What are more of these?

I'm not sure that I have any great examples, but since we've been talking
about Complexes, what about using Interaction to represent Complex
*formation* (e.g. dimerization)?  Assuming that we had reason to explicitly
represent the formation of a Complex (versus the mere fact of its existence,
which is handled by Complex/ComplexComponent), wouldn't this be done with
the Interaction table?  If it were, then you'd have to be able to support
multiple effectors.  To represent dimerization, for example, you'd have
2 inputs (effectors) and 1 output (the target.)  The effectors would be
the same entities referenced by the ComplexComponents and the target would
be the Complex itself.  This sounds redundant, but if (yet another
hypotheticals) you wanted to represent the fact that a second or third
protein acted to inhibit the dimerization process (through some as-yet-
undetermined mechanism) then you'd need to create the dimerization
Interaction so that you could reference it in yet another Interaction (as
a target being inhibited by the new protein).

>  (Although the current schema lets us group effectors together, it
> > doesn't let
> > us say (for example) that E1 interacts *directly* with T1 to
> > phosphorylate
> > it, but that E1's active site is only exposed when E1 is bound to E2.  In
> > other words, E1's role in the activity can be viewed as "primary", and
> > E2's
> > role is secondary (in some sense) but all we can say in the schema is
> > that
> > the Complex consisting of E1 and E2 interacts with T1 to phosphorylate
> > it.)
>
> The above case:
>
> E2 interacts with E1 (they also happen to be represented by a complex; but now
> consider this only an interaction); then E1 interacts with T1 to modify it.

Yes, although if the interaction between E2 and E1 were transient then the
result of E2 and E1's interaction would not be a complex, but rather a
modified E1.

> E2 affects E1; then E1 affects T1. or
>
> Protein X (effector) interacts with protein Y (target); protein Y (effector )
> modifies protein Z (target).

I'm not sure I see the difference between these two alternatives, apart from
the fact that the second uses X,Y, and Z instead of E2, E1, and T1??

> I guess I have a problem with the E1-E2 concept (or multiple effectors if one
> does not effect or interact with a target directly) in the interaction table.

Well, I think complex formation is a good example of a situation in which
both effectors interact directly with the target, because they both become
part of it.  Whether we actually need to represent this is another
question.  Can anyone else come up with any good examples of multiple-
effector/target interactions (that couldn't be easily modeled, as Joan
points out, with a series of simpler "single-valued" Interactions)?

Jonathan