unknown interactor types - and related ComplexViewer errors in new IntAct Portal
bmeldal opened this issue · 21 comments
We are using new interactor types in IntAct that are not working with the viewer:
https://intact-portal.github.io/intact-portal-view/details/interaction/EBI-25816865
has double-stranded RNA -> interactor type not used in CP so probably needs hard-coding
https://intact-portal.github.io/intact-portal-view/details/interaction/EBI-25570228
has interactor = small molecule (= ChEBI AC), which is used in CP - error unknown
https://intact-portal.github.io/intact-portal-view/details/interaction/EBI-6884640
uncertain - contains stoichiometry but that should work - error unknown
yes, the first one is easy to fix. EBI-25816865 also contains an interactor of type MI:0318 'nucleic acid' which hadn't been encountered before. These interactor types are added now in version 2.0.2 (and its published in npm; pushed to MICommunity version of project; tagged as a release and updated on the complexviewer.org demo website where EBI-25816865 is included as an example).
EBI-25570228 - the participant with id '1' and interactorRef 'complex portal_CPX-5709' is full of features on interactor 'uniprotkb_P0C6X7-PRO_0000037322', but this interactor is not in the json, so it fails. I've just defended against the interactor a feature is in not being found in the json, it'll print a warning to the console and ignore it. This is in v2.0.2 and EBI-25570228 is added as an example on complexviewer.org.
It might warrant some further discussion - should features of proteins in complexes be included as features of complexes (even though the proteins themselves are not included)? That said, i think its doing the right thing now with this workaround that just ignores them.
EBI-6884640 - bit of a weird one... it has this in its json:
{
"id": "5",
"interactorRef": "uniprotkb_Q961T8",
"stoichiometry": "5",
[...]
"features": [
{
"id": "6",
"name": "region",
"category": "experimentalFeatures",
"type": {
"id": "MI:0366",
"name": "alkaline phosphatase tag"
},
"sequenceData": [
{
"pos": "?-?",
"interactorRef": "uniprotkb_Q961T8",
"participantRef": "5"
}
]
},
{
"id": "3",
"name": "extracellular region",
"category": "bindingSites",
"type": {
"id": "MI:0442",
"name": "sufficient binding region"
},
"sequenceData": [
{
"pos": "58-308",
"interactorRef": "uniprotkb_Q9VT76",
"participantRef": "1"
}
],
"linkedFeatures": [
"2"
]
}
]
}
so, interactor uniprotkb_Q961T8 has a feature that isn't on uniprotkb_Q961T8 but is instead on uniprotkb_Q9VT76. This doesn't normally happen. I guess either:
- JAMI's gone wrong
- somebodies typed the wrong thing into the IntAct Editor
- this is some funny edge case I don't know about.
Anyway, I removed that feature and then included it as example on complexviewer.org to show it works with that feature removed.
Probably we need to follow up on that last one, not sure what the right thing to do about it is.
Ok, cases 1 & 2 are probably fixed. We'll see how they are looking with the feature annotations in the new Intact Portal.
Case 3 is odd, I can't see any issues with the feature annotation in the editor. Looks like backend gremlins of the IntAct kind ;-) @noedelta I think this one is one to look at with an IntAct curator (Sandra curated that particular entry).
As a side note: on the demo site these new examples are collapsed by default and when I expand them the bars expand on top of each other. In the case of EBI-6884640 it only shows 3 bars as the other 3 are underneath :o I hope this doesn't happen in the Apps when we implement in IntAct and CP...
yep... so they do. It would happen when its deployed, so I'll fix this first.
In the case of EBI-6884640 it only shows 3 bars as the other 3 are underneath :o I hope this doesn't happen
ok, now when you ask it to Expand All it runs the auto layout again. (v2.0.3, see it at complexviewer.org)
Clicking through the examples, I think its better like that.
It's still the case that if you expand a single thing then it could overlap things near it. This could maybe be avoided by fixing the other things in position and running the layout again (so it only moves the thing you expanded). How big a problem do you think this is? (The user will have seen it happening...)
re. that last thing, could also add a button to the web page to rerun layout
ok, now when you ask it to Expand All it runs the auto layout again. (v2.0.3, see it at complexviewer.org)
Clicking through the examples, I think its better like that.
Looks good!
It's still the case that if you expand a single thing then it could overlap things near it. This could maybe be avoided by fixing the other things in position and running the layout again (so it only moves the thing you expanded). How big a problem do you think this is? (The user will have seen it happening...)
Not ideal, but as you said, the user sees it happening so can move the bar away from the other items.
I use ctl+r to reset the layout which works on the CP website but in the demo it goes back to the top example ;-) Did an earlier version reset the layout when we collapsed it? I seem to remember something like that. Now it just collapses the bars back to circles.
I use ctl+r to reset the layout which works on the CP website but in the demo it goes back to the top example ;-)
hmmm, I don't remember doing that. Listening for that ctrl+r is maybe something added to the webpage on your side. We can have such a thing if you wish...
Did an earlier version reset the layout when we collapsed it? I seem to remember something like that. Now it just collapses the bars back to circles.
I took that as a request. It now runs the layout again after 'collapse all'.
Thanks. Let's see how it works in CP when we update the version.
Just FYI: [randomly came across this again just now]
In some cases, 2 interactors partially overlay and flicker like mad until you move a circle, as in this example:
https://www.ebi.ac.uk/complexportal/complex/CPX-5897
or
https://www.ebi.ac.uk/complexportal/complex/CPX-5605
Might cause people a fit. Reminds me of the seasickness-inducing dancing participants of the past - but more irritating as it doesn't stop ;-)
I've seen it a few times now with homodimers that are in a subcomplex.
The new layout algorithm will probably take care of it but we should check it once deployed hence why I'm posting here as a reminder!
2 interactors partially overlay and flicker like mad
I've just tested and the same problem is present in the new version.
So this is something needing fixed. I'll try to get it done this week, will update you here when it is.
Ups - and thanks!
re. CPX-5897 & CPX-5605, the problem's caused by things like this (last interaction from CPX-5605 json):
{
"object": "interaction",
"id": "complex portal_CPX-5605",
"interactionType": {
"id": "MI:0915",
"name": "physical association"
},
"complexType": {
"id": "MI:1302",
"name": "stable complex"
},
"evidenceType": {
"id": "ECO:0005547",
"name": "biological system reconstruction evidence based on inference from background scientific knowledge used in manual assertion"
},
"organism": {
"taxid": "9606",
"common": "human",
"scientific": "Homo sapiens"
},
"identifiers": [
{
"db": "intenz",
"id": "3.4.21.47"
},
{
"db": "complex portal",
"id": "CPX-5605"
},
{
"db": "intact",
"id": "EBI-25436990"
}
],
"participants": [
{
"id": "7",
"interactorRef": "complex portal_CPX-973",
"minStoichiometry": "1",
"maxStoichiometry": "5",
"bioRole": {
"id": "MI:0499",
"name": "unspecified role"
}
},
{
"id": "8",
"interactorRef": "complex portal_CPX-5601",
"minStoichiometry": "1",
"maxStoichiometry": "5",
"bioRole": {
"id": "MI:0501",
"name": "enzyme"
}
},
{
"id": "9",
"interactorRef": "uniprotkb_P27918",
"stoichiometry": "2",
"bioRole": {
"id": "MI:0499",
"name": "unspecified role"
}
}
]
}
CPX-5605 has CPX-973 as participant with id 7, but (earlier in the json) CPX-5601 also contains CPX-973 this time with an id of 5. So its like there's two CPX-973s with different ids.
I've added them as examples with the duplicates in the upper complex removed at complexviewer.org - is that how they're meant to be?
Because CPX-973 is participant of CPX-5601 and CPX-5601 is participant of CPX-5605.
But it doesn't happen in all complexes with subcomplexes. The subcomplex of https://www.ebi.ac.uk/complexportal/complex/CPX-1556 are fine (although this top one still bursts out of frame...).
I could be making some mistake, but I think the way CPX-1556 and CPX-5605 are recorded is inconsistent?
The last interaction of CPX-1556 (below, its the one that is CPX-1556) has two participants CPX-2110 and CPX-297.
If CPX-1556 was recorded the same way as CPX-5605 then it would contain participants for CPX-2944 and CPX-1641, as they are participants of CPX-297? (then shouldn't e.g. cdc45 also be participant of CPX-1556 if we're doing things that way)
The examples at complexviewer.org are with (what seems to me like) the extra participants removed, which is why I was checking if they are displayed correctly there. I can see a potential edge case that the viewer doesn't work for, but it may never come up (A is sub of B, B is sub of C, but A also directly sub of C; maybe one reason our json should work the CPX-1556 way is so that this could be distinguished).
do you see why I'm seeing it as inconsistent? (@noedelta ?)
{
"complexType": {
"id": "MI:1302",
"name": "stable complex"
},
"evidenceType": {
"id": "ECO:0005547",
"name": "biological system reconstruction evidence based on inference from background scientific knowledge used in manual assertion"
},
"id": "complex portal_CPX-1556",
"identifiers": [
{
"db": "intenz",
"id": "2.7.7.7"
},
{
"db": "intenz",
"id": "3.6.4.12"
},
{
"db": "complex portal",
"id": "CPX-1556"
},
{
"db": "intact",
"id": "EBI-16706245"
}
],
"interactionType": {
"id": "MI:0915",
"name": "physical association"
},
"object": "interaction",
"organism": {
"common": "yeast",
"scientific": "Saccharomyces cerevisiae",
"taxid": "559292"
},
"participants": [
{
"bioRole": {
"id": "MI:0501",
"name": "enzyme"
},
"id": "32",
"interactorRef": "complex portal_CPX-2110"
},
{
"bioRole": {
"id": "MI:0501",
"name": "enzyme"
},
"id": "33",
"interactorRef": "complex portal_CPX-297"
}
]
}
Ok, I might have found the problem: CPX-973 is indeed a participant of CPX-5605 AND CPX-5601, so exactly the edge case you predicted, Colin! And that's exactly what the JSON above shows.
See original curation for CPX-5605 in the editor:
EBI-25437020 / fbb-c3b_human is CPX-5601
EBI-25437022 / c3b_human is CPX-973
(sorry, the editor doesn't display the CPX- for participants)
but ComplexViewer 'looses' CPX-973 as participant of CPX-5605, only using it as participant of CPX-5601.
Biologically, what happens is that the C3b dimer (CPX-973) forms, binds to the pathogen surface, joins up with protein CBb forming CPX-5601 and then joins with another C3b dimer and 2x Properdin (prop_human) forming CPX-5605. In the end we have complex "C3bBbC3bP". Each step has a unique function, hence why I curated them all.
I could make it "worse" and create a dimer for Properdin but that has no function on its own so that's why we don't make a separate entry ;-)
Same is happening with "C3bBbC3b" https://www.ebi.ac.uk/complexportal/complex/CPX-5604 - which is the same as CPX-5605 but without Properdin (as Properdin gives it a slightly different function...). You can see how the viewer has the same participants for the green and orange complexes as the green one 'lost' the second CPX-973. But it's in the table.
Of course, there is the philosophical question of whether we should curate this Russian doll system as once in a complex all proteins have the same "rights" whether they are only present here or have a separate function as part of a different complex. We thought it would be good for the user to know this overlapping system but the visualisation is becoming an issue...
Nothing is easy with complexes ;-)
ok, so it is a bug in the viewer. (and what is currently displayed at complexviewer.org for these is wrong)
but ComplexViewer 'looses' CPX-973 as participant of CPX-5605, only using it as participant of CPX-5601.
yep, it doesn't actually lose it, its more that both copies of CPX-973 end up having exactly the same participants. The shaking you see is the two copies of CPX-973 fighting over who gets the particpants.
there is the philosophical question of whether we should curate this Russian doll system [...] We thought it would be good for the user to know this overlapping system but the visualisation is becoming an issue...
i think always curate it in the way that's most intuitive to users / most correct (others can decide what that means) and save workarounds until we reach an insurmountable problem with the viz, which i don't think this is
its a change to the (stoichiometry) expansion code? I think for each additional occurrence of a complex as a participant its own participants need to be duplicated.
do you have any examples with complexes as participants with stoich > 1? I think it will break and if its stoich 4 you'll end up with 4 of these complexes fighting over the same participants.
yep, it doesn't actually lose it, its more that both copies of CPX-973 end up having exactly the same participants. The shaking you see is the two copies of CPX-973 fighting over who gets the particpants.
But one CPX-973 should be on the green background and the flickering is on the blue one.
do you have any examples with complexes as participants with stoich > 1?
Not from the top of my head but it's certainly a possibility.
@noedelta , as we are seeing more and more issues with our JSON, I feel it needs a review ;-)
i made a separate issue just for the 'multiple instances of same complex' problem (#180), so i think this can be closed