interaction with complexes not displaying
Closed this issue · 23 comments
problem ones:
https://www.ebi.ac.uk/complexportal/complex/CPX-5684
https://www.ebi.ac.uk/complexportal/complex/CPX-5695
https://www.ebi.ac.uk/complexportal/complex/CPX-5696
haven't looked into this yet, will update issue when have.
@noedelta - do you know of anything wrong on your side? maybe something to do with the references to subcomplexes?
My fault, I forgot to make a link in the editor and the reviewer missed it, too. Thanks for the reminder, though, as I still need to fix it! Will do it now.
if they don’t specify the component inside the complex that has the feature the viewer doesn’t support yet the connection of a feature with the whole complex (although I remember that you were creating a prototype with some connectors in your last visit)
yes, I think this is done?
If you go to complexviewer.org and choose the example CPX-2020 (which appears to have been mislabelled and is really CPX-1920) it shows features connected to a whole complex?
yet, if you go to https://www.ebi.ac.uk/complexportal/complex/CPX-1920 its one of the ones that doesn't display
I'm wondering if its really the most recent version of the viewer that's deployed? Or it could be to do with the version of JAMI (or config options for JAMI) being used to create the MI-JSON?
I think getting CPX-1920 displaying in ComplexPortal as it does in the demo page would be good as next step forward?
It displays fine in the editor. There is no linked feature between the proteins and the subcomplex.
I'm wondering if its really the most recent version of the viewer that's deployed?
Answering my own question, yes, it is the most recent version of the viewer. I have the same behaviour (i.e. nothing) with the MI-JSON from CPX-1920.
I may be repeating what Noe said above, but the difference is that the one that doesn't work has a feature with sequenceData like:
"sequenceData": [
{
"pos": "?-?"
}
]
that is, no interactorRef or participantRef, while the working one has it like:
"sequenceData": [
{
"interactorRef": "complex portal_CPX-1919",
"participantRef": "69",
"pos": "?-?"
}
]
I'm not sure if this is the same as "not specifying the component inside the complex", its more like not specifiying the complex?
@noedelta - I know we've looked at this before, I can't remember exactly where we got to on it... do you?
@bmeldal - I'm not sure if the this is the same as the 'forgotten link' you mentioned either? The editor must have a different version of viewer because the MI-JSON will be the same, right?
cheers,
colin
Yes, this all the same issue! In the editor we have to manually select the complex component and I guess that creates this part of the JSON:
"interactorRef": "complex portal_CPX-1919",
"participantRef": "69",
As curators we need to remember to select the complex participant or we simply shouldn't link a protein to a complex. If we make the link without selecting the participant it shows nothing in the editor.
When Colin was visiting, he developed a version where the protein was linked to the centre of the complex if no participant was selected. But that may only have be a demo version, I can't remember. If no participant is selected the graph is not showing in the Editor and also broke on the website. Noe, I just removed the selection for one link (feature = "broken binding region") in https://www.ebi.ac.uk/intact/editor/complex/EBI-25491646 so you can see the link with missing participant selection. I need to add it in again before the release or the complex breaks!
PS: When we don't know the complex participant a protein binds to then the evidence for the link is very weak and we can justify not making the link in the first place. When Noe checked for complexes with missing participant selections we had about 6 complexes where I simply removed the link as there was little evidence anyway. And the fact that they are all complex participants already gives the user sufficient information!
Ok, I will fix the example complex so it doesn't break in the next release!
Noe, we can live with the current version without linking a protein to a complex that has no selected participant.
I renamed this so it reflects the more general problem, though we think its really a problem with jami.
the representation of this is better in the new version I think. TBH I hadn't seen birgit's comment that you can live without it. Would be nice to have, so i think still worth fixing in jami if we can.
re. this, I think I might have fixed it on the ComplexViewer side without needing to make changes to JAMI.
things like CPX-1920, which aren't displaying in ComplexPortal at the moment (even with the problematic feature link removed i think, because its the feature itself that crashes it) should now display
should be you can start curating things as you want them to be rather than working around problems in the viewer
Ok, to be checked when @git4anjali has deployed the new version in CP, it works in http://complexviewer.org/
its the manually fixed version of the data you're looking at on complexviewer.org to be honest,
there seemed to be some other funny things about the JSON data for the current version of CPX-1920 that you might want to take a look at (when you can see it),
it has weird protein names and some of the annotations you get are outside the range of the sequences
it has weird protein names
It is "weird" because we used the UniProt PRO chains? They have different names, P00736-PRO_0000027578 = UniProtAC+PROchainID - that's normal.
some of the annotations you get are outside the range of the sequences
Can you give me an example so I can check it? It might be due to the PRO chains, as we restart counting from 1 in the PRO chain but some UniProt + superfamily features might be annotated to the positions on the canonical sequence.
Can you give me an example
If you go to complexviewer.org then the current data for CPX-1920 is now there as an example (second from top, called "CPX-1920")
its the Superfamily annotations that are off-sequence but it sounds like you know why
this is without any manual changes to the JSON so it should appear like this when the viewer is updated in complex portal (and in editor)
I actually can't see any examples of out-of-ranges features on the demo site.
And no PRO chains as names in this example.
Or did you fix it here already. Sorry, I am slow!
It works in our Editor that has a much older version of the viewer (I think) but not on the CP website. So have to wait for Anjali to redeploy before I can see the changes on our website.
I actually can't see any examples of out-of-ranges features on the demo site.
I think either your browser has cached the file with the list of examples or you've been confused by the way I've named the examples, which is confusing.
If cached file then control-F5 to hard reload (unless its Safari, then its something else).
If its naming confusion - there are two CPX-1920s: the top one "~CPX-1920" is the old data modified so it worked in the previous version of the viewer; the second from top one "CPX-1920" (no tilde) is the data exactly as it currently is.
Current CPX-1920 comes out looking like:
It was cached!!! It happens to me all.the.time. :S (there was only ~CPX-1920 before)
So, yes, now I see the out-of-bounds regions. They need fixing. If we use PRO chains as identifiers then you should only display features for those ranges. UniProt has the ranges in their "domains" section so you should be able to do a diff and set start and end points for displaying ranges and recalculating positions by resetting PRO chain start = 1.
If we use PRO chains as identifiers then you should only display features for those ranges.
I don't think I easily have access to the info on what the ranges for PRO chains are, the complete JSON for one is like:
{ "object": "interactor", "id": "uniprotkb_P09871-PRO_0000027588", "sequence": "IIGGSDADIKNFPWQVFFDNPWAGGALINEYWVLTAAHVVEGNREPTMYVGSTSVQTSRLAKSKMLTPEHVFIHPGWKLLEVPEGRTNFDNDIALVRLKDPVKMGPTVSPICLPGTSSDYNLMDGDLGLISGWGRTEKRDRAVRLKAARLPVAPLRKCKEVKVEKPTADAEAYVFTPNMICAGGEKGMDSCKGDSGGAFAVQDPNDKTKFYAAGLVSWGPQCGTYGLYTRVKNYVDWIMKTMQENSTPRED", "type": { "id": "MI:0326", "name": "protein" }, "organism": { "taxid": "9606", "common": "human", "scientific": "Homo sapiens" }, "identifier": { "db": "uniprotkb", "id": "P09871-PRO_0000027588" }, "label": "p09871-pro_0000027588" }
I guess I would need another way to get the range info.
Out of interest, why are the PRO chains sometimes used?
(maybe the JAMI output should be updated to include the range info for PRO chains)
i'll close this and make a new one for the PRO chain issue
yeah, I should've done that... thanks