Add RNA types

[EliotRagueneau]

We were having an error regarding this interaction so we updated the different types.

I created a new service in our backend to determine the style of our different representations and we were thinking to use that to send directly the shape that the elements should have inside the MIJson. This way we wouldn't have those problems of missing types, and you wouldn't have to manually check the types of interactions. What do you think about it @colin-combe ? Should we work on that, or is it overkill?

[colin-combe]

oops, I didn't realise this was a pull request not an issue, and I made the same change also.

I created a new service in our backend to determine the style of our different representations and we were thinking to use that to send directly the shape that the elements should have inside the MIJson.

hmmm, i don't like it. Its breaking the separation between the data and the representation of the data. Also, I think it makes complex viewer less easily reusuable as a component in different contexts.

This way we wouldn't have those problems of missing types, and you wouldn't have to manually check the types of interactions.

neither of these things is really a problem, it was easy for you to add things to that list (

ComplexViewer/src/js/read-mijson.js

Lines 236 to 296 in 45c9044

	}else if (interactor.type.id === "MI:1304" //molecule set
	||
	interactor.type.id === "MI:1305" //molecule set - candidate set
	||
	interactor.type.id === "MI:1307" //molecule set - defined set
	||
	interactor.type.id === "MI:1306" //molecule set - open set
	) {
	participant = new MoleculeSet(participantId, app, interactor, interactor.label);
	} else if (interactor.type.id === "MI:1100" // bioactive entity
	||
	interactor.type.id === "MI:0904" // bioactive entity - polysaccharide
	||
	interactor.type.id === "MI:0328" //bioactive entity - small mol
	) {
	participant = new BioactiveEntity(participantId, app, interactor, interactor.label);
	} else if (interactor.type.id === "MI:0326" || interactor.type.id === "MI:0327") { // proteins, peptides
	participant = new Protein(participantId, app, interactor, interactor.label, interactor.sequence);
	} else if (interactor.type.id === "MI:0250") { //genes
	participant = new Gene(participantId, app, interactor, interactor.label);
	} else if (interactor.type.id === "MI:0320" // RNA
	||
	interactor.type.id === "MI:0321" // RNA - catalytic
	||
	interactor.type.id === "MI:0322" // RNA - guide
	||
	interactor.type.id === "MI:0323" // RNA - heterogeneous nuclear
	||
	interactor.type.id === "MI:2190" // RNA - long non-coding
	||
	interactor.type.id === "MI:0324" // RNA - messenger
	||
	interactor.type.id === "MI:0679" // RNA - poly adenine
	||
	interactor.type.id === "MI:0608" // RNA - ribosomal
	||
	interactor.type.id === "MI:0611" // RNA - signal recognition particle
	||
	interactor.type.id === "MI:0610" // RNA - small interfering
	||
	interactor.type.id === "MI:0607" // RNA - small nuclear
	||
	interactor.type.id === "MI:0609" // RNA - small nucleolar
	||
	interactor.type.id === "MI:0325" // RNA - transfer
	||
	interactor.type.id === "IA:2966" // RNA - double stranded ribonucleic acid
	||
	interactor.type.id === "MI:0318" // nucleic acid
	||
	interactor.type.id === "MI:2204" // micro RNA
	) {
	participant = new RNA(participantId, app, interactor, interactor.label);
	} else if (interactor.type.id === "MI:0319" // DNA
	||
	interactor.type.id === "MI:0681" // DNA - double stranded
	||
	interactor.type.id === "MI:0680" // DNA - single stranded
	) {
	participant = new DNA(participantId, app, interactor, interactor.label);
	} else {

)
and I also don't mind maintaining it.

Should we work on that, or is it overkill?

its getting the thumbs down from me :) The two real problems with the MIJson are #160
and the issue at the end of
#155

Re. #155 - the unknown interactor types reffered to in the title were easy to resolve, just like here. But the issue at the end is a bit tricky, seems like the json can't really record the situation, like @bmeldal sayas hacking the viewer prob isn't the right thing to do.

[bmeldal]

hmmm, i don't like it. Its breaking the separation between the data and the representation of the data.

I agree with the argument about the separation and making integration of the viewer by a third party easy. The problem is that we never know that an interactor type is missing until we accidentally find a case that's broken. So a way that doesn't rely on hard-coding type and symbol but using the MI ontology to find the right branch for the type would be ideal - not? In most cases the missing symbols were "new" types of RNAs (new = not use as an interactor yet, not new to biology) so being able to identify them as "RNA" and then grabbing the right symbol would be best.

(I'm just a dumb curator, so what do it know ;-) )

[EliotRagueneau]

Believe it or not @bmeldal but that's exactly what I'm doing on the backend! (so of course you're not dumb at all ;) ) And basically, we needed it for both IntAct App, and IntAct Portal, hence the centralisation in the backend.

I totally understand your concern @colin-combe as I had exactly the same before, it just happens to be simpler, in the end, to implement styling once and for all in the backend than on every front-end of ours, especially when we need to update the styles ^^

So I won't insist anymore on that personally, just know that if at some point you want to use it, it can be there ^^

[EliotRagueneau]

By the way @colin-combe IA:2966 has been replaced by MI:2359. It's already available from the latest release. So maybe you'll need to update that as well on the master branch ;)

[EliotRagueneau]

We added a new type for small molecules as well that you are missing on your side: case "MI:2258": // bioactive entity - xenobiotic

[colin-combe]

using the MI ontology to find the right branch for the type would be ideal - not?

yes, i'd agree with that

as a short term thing i'll add those two other types also, but I agree this can be improved...

[colin-combe]

ok, they're added (v2.1.6), I wonder if there are other ones missing... I should check it properly

@bmeldal - I'll make a GH issue along lines you suggest

the biggest prob with the hardcoding (perhaps) is that it means updating it in CP, Intact and the Editor every time it changes:-
could these things be made so that they just take the most recent release when the page loads?

[bmeldal]

I think those are 2 different things.

Hard-coding means you have to make the change each time we use a new interactor type and curators don't know when this happens as they are often already in the DB. If a curator asks for a completely new CV term we can ask whoever is taking over the PSI-MI CV to let you, Colin, know and you can proactively add the new links at the time.

I'm not sure we can do much about the fact that we need to redeploy each applications in order to update to the next viewer version. However, we have other 3rd party widget in the CP (Reactome, LiteMol, GXA). @EliotRagueneau can you see how these would be updated?

[colin-combe]

Hard-coding means you have to make the change each time we use a new interactor type and curators don't know when this happens as they are often already in the DB. If a curator asks for a completely new CV term we can ask whoever is taking over the PSI-MI CV to let you, Colin, know and you can proactively add the new links at the time.

yes, I agree it's not a good system. #173 would fix this?