creating network through RCy3 resulting network has the right nodes and edges but edge table gets messed up with conflicting data

[risserlin]

I am not sure if this is an issue coming from RCy3 or from cytoscape itself. (Also, I am having a little bit of deja vu when I am submitting this issue. I am not sure if I have already reported this or if I have encountered this issue before and was able to fix it. Sorry if that is the case)

With RCy3 I create a network with the following commands: network_suid <- createNetworkFromDataFrames(nodes, edges, collection = "Master_interaction_map", title = "Master_interaction_map", base.url = cyto_url)

The R objects, nodes and edges -
edges.csv nodes.csv

In the resulting network there are edges that are clearly there in the original data but the attributes associated with them are from different edges.

For example - edges between OBSCN and SORBS1

In the original edges table they are defined as -

But in the resulting network -

[risserlin]

Sorry, this was deja vu. I have had this issue in the past but I forgot how to fix it. I switched back to using my docker version which has the latest version of RCy3 and this is not an issue. (I haven't been using the docker version because of incompatibilities with the latest version of docker and cytoscape and RCy3. I can no longer use localhost:1234 and instead have to use host.docker.internal:1234/v1 but then not all the RCy3 functions work)

[risserlin]

Using RCy3 2.14.1 The interactions are the correct interactions but where there is a duplicated edge only one of the edge attributes get loaded. Is there a way to fix this? I think it is only loading the attributes for the last edge (eventhough it is creating the 3 interactions)

[m-grimes]

Ruth

I made a wrapper that checks for errors as a workaround. Recently with RCy3_2.14.1 I don’t seem to get bad edge loads.

createNetworkFromDataFrames.check <- function(nodes, edges, 

title="Checked", collection="Checked interactions") { for (i in 1:10){ createNetworkFromDataFrames(nodes, edges, title, collection) edgeTable <- getTableColumns("edge", c("name", "shared name")) if(!identical(edgeTable[,1], edgeTable[,2])) { print(paste('Network', i, "is bad.")) deleteNetwork()} else { print (paste("Network", i, "passes edge test.")) break } }}

Mark

On 5 Jan 2022, at 9:02, Ruth Isserlin wrote:

Using RCy3 2.14.1 The interactions are the correct interactions but where there is a duplicated edge only one of the edge attributes get loaded. Is there a way to fix this?

-- Reply to this email directly or view it on GitHub: https://github.com/cytoscape/RCy3/issues/168#issuecomment-1005855665 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[AlexanderPico]

My first impression is that this is impossible... The identity of edges are defined by the concatenation of source, interaction and target. This gets set as the interaction name. And you have 3 edges with the exact same name. The fix we added to RCy3 was to keep track of the SUID assigned to a given edge name and make sure it loaded data onto that edge, as identified by SUID in Cytoscape.

So, the behavior you are seeing is exactly what I would expect from the code.

I can't think of a way for RCy3 to "know" this edge to add data to if they all have the exact same name... Maybe a lack of imagination on my part :) If you have suggestions for an algorithm or set of steps that could distinguish one from the other, please let me know.

[risserlin]

But yet there are still 3 unique edges created. Are the edge attributes loaded as a separate step after all the edges are created?

I guess a way around it for me would be to define my own unique identifier to edge and load the edge attributes after the network is created using my unique identifier as the key.

[AlexanderPico]

Yes, exactly! They are separate steps. createNetworkFromDataframe() calls loadTableData(), which relies on mapping to SUID.

But, as you suggest, you could dissect the function and run in line-by-line (or make your own function) to customize the loadTableData step to use your own unique identifier.