Florian J. Auer1*
1Augsburg University
*Florian.Auer@informatik.uni-augsburg.de
2023-04-25
- 1. Introduction
- 1.1 The Cytoscape Exchange (CX)
- 1.2 The NDEx platform
- 1.3 landscape
- 1.4 RCX - an adaptation of the CX format
- 2 Installation
- 3 The basics
- 3.1 Reading and writing CX files
- 3.2 Explore the RCX object
- 3.3 View the network
- 3.4 Validation
- 4 Get information about networks
- 5 Conversion to R graph data models
- 5.1 graph
- 6 Bioconductor graph (graphNEL)
- 7 Session Information
Networks are a powerful and flexible methodology for expressing biological knowledge for computation and communication. Biological networks can contain a variety of different types of information, such as genetic or metabolic interactions, gene and transcriptional regulation, protein-protein interaction (PPI), or cell. signaling networks and pathways. They often constitute a valuable resource for hypothesis generation and future research, and in the course of analyses, they are processed and enriched with additional information from experiments. As a result, more networks are generated, either as intermediate results that need to be documented in the process, as the result of those analyses, or as visual representations and illustrations used in reports and publications. As a consequence, these resulting networks no longer follow the strict rules that the source networks were subject to, therefore a more flexible format is needed to capture their content.
In addition, the right solutions for streaming conflict with those for storage or use in applications and analytics. Therefore, the perfect conversion between those different formats becomes as important as the data itself.
1.1The Cytoscape Exchange (CX)
A possible solution as a flexible transmission format is the Cytoscape Exchange (CX) format. CX is an aspect-oriented data structure based on JSON, which means that the network is divided into several independent modules ("aspects"). In this way, every aspect of a network, which means nodes, edges, their attributes, and visual representations can be handled individually without interference. Each aspect has its own schema for the information it contains, and links between aspects are made by referencing the unique internal IDs of other aspects. The CX data model was developed by the NDEx project, in collaboration with the Cytoscape Consortium (http://www.cytoscapeconsortium.org/) as a streaming format among its tools, and since adopted by many others. More details about the CX data model can be found on its documentation website:https://home.ndexbio.org/modelo-de-datos/
1.2The NDEx platform
Network Data Exchange, or NDEx, is a common online resource for biological networks (Pratt et al., 2015, Cell Systems 1, 302-305, October 28, 2015 ©2015 Elsevier Inc.DirectScience). It is an open source software framework for manipulating, storing, and exchanging networks of various types and formats. NDEx can be used to publicly upload, share, and distribute networks while providing output in formats that can be used by many other applications.
The NDEx public server is a common data network that provides collections of pathways such as the NCI pathway interaction database (http://www.ndexbio.org/#/user/301a91c6-a37b-11e4-bda0-000c29202374) and the Cancer Cell Mapping Initiative (http://www.ndexbio.org/#/user/b47268a6-8112-11e6-b0a6-06603eb7f303). Public networks can be searched and retrieved from the platform for later use. Own networks can be uploaded and shared with certain collaborators or groups privately or provided publicly to the community. In addition, the private installation of the NDEx platform can be used to store and collaborate on networks locally.
The ndexr package available from Bioconductor (https://doi.org/doi:10.18129/B9.bioc.ndexr) allows you to connect to the NDEx platform from within R. This package provides an interface to query the public NDEx server, as well as private facilities, to upload, download, or modify biological networks.
1.3citoscape
The most prominent software environment for the analysis and visualization of biological networks is Cytoscape (https://cytoscape.org/). It supports large networks and comes with a rich set of features for custom visualization and advanced design and analysis algorithms. One of these visualization functions is "attribute-to-visual mapping", where data from the network is translated into a visual representation. Based on this display strategy, Cytoscape brought skins to the CX format to capture the visual representation as part of the grid. Due to these aspects, the visualization can not only be documented together with the network, but also reproduced on other platforms, and even shared between networks with the same attributes used to create the visualization.
1.4RCX - an adaptation of the CX format
CX is a JSON-based data structure designed as a flexible model for networking with a focus on flexibility, modularity, and extensibility. Although those features are widely used in common REST protocols, they don't quite fit the R way of thinking about data. .
This package provides a port of the CX format to the standard R data types and formats for creating and modifying, loading, exporting, and displaying those networks. This document is intended to help the user install and take advantage of the wide range of features of this implementation. .For an overview of the differences between the RCX implementation and the CX specification, seeAppendix: The RCX and CX Data Model
To install packages from github, thedevelopment tools
The package is the most common approach. However, it requires XML libraries installed on the system, which can cause problems during installation due to unsatisfied dependencies.remote controls
The package covers the functionality to download and install R packages stored in 'GitHub', 'GitLab', 'Bitbucket', 'Bioconductor' or 'subversion' or 'git' repositories without relying on XML libraries.development tools
is already installed, of course it can be used, otherwise it is recommended to use the lightweightremote controls
package.
From github using remotes:
if (!"remotes" %in% installed.packages()) { install.packages("remotes")}if (!"RCX" %in% installed.packages()) { remotes::install_github("frankkramer- lab /RCX")}library(RCX)
From github using devtools:
if (!"devtools" %in% instalado.paquetes()) { install.packages("devtools")}if (!"RCX" %in% instalado.paquetes()) { devtools::install_github("frankkramer-lab /RCX")}biblioteca(RCX)
Next, it will be explained how to read and write networks from/to CX files, create and modify RCX networks, validate their content and finally visualize them.
3.1Read and write CX files
The networks can be downloaded from theNDEx platformas CX files in JSON format. Those files can be read and are automatically transformed into RCX networks that can be used in R. Here we load an example network provided from the file:
cxFile <- system.file( "extdata", "Imatinib-Inhibición-de-BCR-ABL-66a902f5-2022-11e9-bb6a-0ac135e8bacf.cx", package = "RCX")rcx = readCX(cxFile)
This network can also be accessed and downloaded from NDEx athttps://www.ndexbio.org/viewer/networks/66a902f5-2022-11e9-bb6a-0ac135e8bacf
RCX networks can be saved in a similar way:
writeCX(rcx, "route/to/some-file.cx");
However, some errors may occur while reading the CX file. This can happen because the definition of CX has changed over time and therefore the definition of some aspects. So it is possible that there are still some networks stored in the NDEx. platform following an outdated format. In those cases, it might be useful to process the CX network step by step:
1.just read the JSON content without parsing
json <- leerJSON(cxFile)substr(json, 1, 77)
## [{"numberVerification":[{"longNumber":281474976710655}]},{"metaData":[{"name"
This also makes it possible to handle a CX network in JSON format, even if it comes from a different source instead of a file.
2.parse the JSON
listAspecto <- parseJSON(json)str(listAspecto, 2)
## List of 12## $ :List of 1## ..$ check number:List of 1## $ :List of 1## ..$ metadata:List of 9## $ :List of 1## .. $ provenanceHistory:List of 1## $ :List of 1## ..$ nodes:List of 75## $ :List of 1## ..$ edges:List of 159## $ :List of 1## . .$ networkAttributes:List of 10## $ :List of 1## ..$ nodeAttributes:List of 1129## $ :List of 1## ..$ edgeAttributes:List of 229## $ :List of 1## ..$ cartesianLayout:List of 75## $ :List of 1## ..$ cyVisualProperties:List of 3## $ :List of 1## ..$ cyHiddenAttributes:List of 1## $ :List of 1# # ..$ state:List of 1
The result of the analysis are nested lists that contain all the aspects and their content. This format is not easy to handle in R, but it allows for debugging before forming skin and RCX objects.
3.process the appearance data
rcx <- processarCX (list of aspects)
All of the above functions for processing CX networks come with an option to show the steps performed. This could be useful for finding errors that occur:
rcx <- readCX(cxFile, verbose = TRUE)
## Read the file "/tmp/RtmpdGvAw0/Rinst1cc2fc76490e53/RCX/extdata/Imatinib-BCR-inhibition-ABL-66a902f5-2022-11e9-bb6a-0ac135e8bacf.cx"...done!## Parse json. .. done!## Parsing nodes... create skin... done!## Create RCX from parsed nodes... done! ## Parsing edges... create skin... done!## Adds skin "edges" to RCX... done!## Parsing node attributes... creates skin... done! ## Add "nodeAttributes" aspect to RCX... done! ## Parsing the border attributes... create the look... done! ## Add "edgeAttributes" skin to RCX... done!## Parsing network attributes... create skin... done!## Add "networkAttributes" skin to RCX... done !## Parsing cartesian layout... .create skin... done!## Add "cartesianLayout" skin to RCX... done!## Analyze Cytoscape visual properties... done!# # - Create sub-objects... done!## - Create skin ...done!## Add the "cyVisualProperties" skin to RCX... done!## Parsing Cytoscape's hidden attributes... create the skin... done!## Add "cyHiddenAttributes" skin to RCX... done!# # Metadata parsing... done!## Ignore "numberVerification" skin, not needed in RCX! ## Can't render "numberVerification" aspect, so skip it... done!## I don't know what to do Do it with a "Source History" skin!## Can't render "Source History" skin ", so skip it... done!## Ignore the "status" aspect, it's not needed in RCX!## Can't process the "status" aspect, so skip it... done!
This shows that some aspects that are contained in the CX file are ignored when creating the RCX network. Those are, for example, aspects necessary for the transmission of the CX (state
,numberVerification
), or obsolete aspects (procedenciaHistoria
). For more details on skin differences, seeAppendix: The RCX and CX Data Model.
3.2Explore the RCX object
The easiest way to see the content of an RCX object is to print it:
imprimir(rcx)## O:rcx
However, especially for large networks, this can produce long, hard-to-read output. To get a better overview of the contained aspects, the mandatory and automatically generated datametadata
The aspect provides information about the contained aspects. This includes information about the number of items or the highest id used, if an aspect uses internal ids:
rcx$metadata
## Metadata:## name version idCounter elementCount consistencyGroup## 1 nodes 1.0 11551 75 1## 2 edges 1.0 11554 159 1## 3 nodeAttributes 1.0 NA 1129 1## 4 edgeAttributes 1.0 NA 229 1## 5 networkAt taxes 1.0 NA 10 1## 6 cartesianLayout 1.0 NA 75 1## 7 cyVisualProperties 1.0 NA 3 1## 8 cyHiddenAttributes 1.0 NA 1 1
In addition to exploring the RCX object manually, a summary of the object, or individual aspects, can provide more information about them:
resume(rcx$nodeAttributes)
## propertyOf name value ## Total: 1129 Length: 1129 Boolean: 185 ## Unique IDs: 75 Unique: 34 Double: 92 ## Min. :11321 Class :character Integer: 68 ## Max. :11551 String :784
We can already quickly see that many different node attributes are used. The different node attributes are:
unique(rcx$nodeAttributes$name)
## [1] "sbo" "metaId" "compartment code" ## [4] "sbml type" "sbml id" "reversible" ## [7] "sbml compartment" "cyId" "label" ## [10] "type sbml ext" "fast" "constant" ## [13] "units" "boundary condition" "derived units" ## [16] "initial quantity sbml" "value" "units of substance " ## [19] "has only substance units" " uniprot" "inchikey" ## [22] "chebi" "biocyc" "cas" ## [25] "chemspider" "kegg.compound" "inchi" # # [28] "pubchem.compound" "hmdb" "scale " ## [31] "exponent" "type" "multiplier" ## [34] "unitSid"
3.3visualize the network
This package provides simple functions to display the network encoded in the RCX object.
visualize (rcx)
Inhibition of BCR-ABL (66a902f5-2022-11e9-bb6a-0ac135e8bacf) by imatinib
The visualization also uses the same JavaScript library as the NDEx platform. Therefore, the visual result is the same as when the network is loaded on the NDEx platform. Additionally, this allows the visualization to be exported as a single HTML file, which can be directly hosted on a web server or included in existing websites:
writeHTML(rcx, "route/to/some-file.html");
Networks with many nodes and edges, or those without a proportionate layout, are often difficult to interpret visually. To detangle the "hairball", it is possible to apply different design options provided by theCytoscape.jsframe. A force-driven design is a good starting point in those cases. For demo purposes, let's first remove the visual layout of our network:
## save them for lateroriginalVisualProperties <- rcx$cyVisualProperties## and remove them from the grid RCXrcx$cyVisualProperties <- NULLrcx <- updateMetaData(rcx)rcx$metaData
## Metadata:## name version idCounter elementCount consistencyGroup## 1 nodes 1.0 11551 75 1## 2 edges 1.0 11554 159 1## 3 nodeAttributes 1.0 NA 1129 1## 4 edgeAttributes 1.0 NA 229 1## 5 networkAt taxes 1.0 NA 10 1## 6 cartesianLayout 1.0 NA 75 1## 7 cyHiddenAttributes 1.0 NA 1 1
Let's take a look at the visualization now:
display(rcx, layout=c(name="thing"))
Forced display of the network without visual properties
Unfortunately, no tags are displayed on the network. We can fix that by defining a simple transfer mapping for the node labels and adding it to the network:
cyMapping <- createCyVisualPropertyMappings( name= "NODE_LABEL" , type = "PASSTHROUGH", definition = "COL=label,T=string")cyVisualProperties <- createCyVisualProperties( defaultNodes = createCyVisualProperty( mapeos = cyMapping ))rcx <- updateCyVisualProperties(rcx, cyVisualProperties)
By default, the visualization opens in RStudio, but it can also be forced to open in an external browser.Cytoscape.js
The parameters used to customize the layout algorithm can be found in its documentation athttps://js.cytoscape.org/#layouts/cose
display( rcx, layout = c( name="sew", idealEdgeLength="80", edgeElasticity="250"), openExternal = TRUE)
3.4Validation
The RCX network fix is important for conversion to CX and therefore to be used on all platforms and tools. The validity of an RCX network can be verified simply:
validate (rcx)
## Checking nodes aspect:## - It is an object of class "NodesAspect"... OK## - All required columns are present (id)... OK## - Column (id) is not contains no NA value. .OK## - At least one node present...OK## - Column(id) contains only unique values...OK## - Column(id) contains only numeric values...OK## - The column (id) ) contains only positive values (>=0)...OK## - No merge artifacts present (ie column with old ids: oldId)...OK## - Only allowed columns present ( id, name, represents). .OK## >> Node Aspect: OK## ## Edge Aspect Check:## - It is an object of class "EdgesAspect"...OK## - All required columns are present (id , source, destination)...OK ## - Column(id) does not contain any NA values...OK## - Column(id) contains only unique values...OK## - Column(id) contains only numeric values...OK## - Column (id) only contains positive values (>=0)...OK## - Column (source) does not contain any NA values...OK## - The column (source) only contains numeric values... OK## - Column (source) only contains positive values (>=0)...OK## - Column (target) does not contain any NA values...OK ## - Column (target) contains only numeric values...OK## - Column (target) only contains positive values (>=0)...OK## - No merge artifacts present (i.e., column with old ids: oldId)...OK## - Only allowed columns present (id, source, destination, name, interaction)...OK## >> Border Appearance: OK## ## Appearance check for node attributes: ## - Is an object of class "NodeAttributesAspect"...OK## - All required columns are present (propertyOf, name, value, dataType, isList)...OK## - The combination of columns(propertyOf, name) contains only single elements values...OK## - Column (propertyOf) does not contain any NA values...OK## - Column (propertyOf) contains only numeric values...OK## - Column (propertyOf) contains only positive (>=0) values...OK## - Is column (name) a character vector...OK## -Is column (value) a list. ..OK## - Column (data type) does not contain any NA values...OK## - Is column (data type) a character vector...OK## - All values of type data is in the allowed set (boolean, integer, long, double, string)...OK ## - Column (isList) does not contain any NA values... OK## - Column (isList) contains only values logical... OK## - Only allowed columns are present (propertyOf, name, value, dataType, isList )...OK## >> Appearance of node attributes: OK## ## Check appearance of logical edge attributes:## - Is the object of class "EdgeAttributesAspect"...OK## - All required columns are present (propertyOf, name, value, dataType, isList)...OK## - The combination of columns(propertyOf, name) contains only unique values...OK## - Column(propertyOf) does not contain any NA values...OK## - Column(propertyOf) contains only numeric values...OK## - Column (propertyOf) only contains positive values (>=0)...OK## - Is column (name) a character vector...OK## - Is column (value) a list... OK ## - Column (data type) does not contain any NA values... OK## - Column (data type) is a character vector... OK## - All dataType values are in array allowed(boolean, integer, long, double, string)...OK## - Column (isList) does not contain any NA values...OK## - Column (isList) contains only logical values...OK# # - Only allowed columns present (propertyOf, name, value, dataType, isList)...OK## >> Border Attributes Aspect: OK## ## Network Attributes Aspect Check:## - Is subject to the "NetworkAttributesAspect" class...OK## - All required columns present (name, value, datatype, isList)...OK## - Column (name) contains only unique values...OK## - Is column (name) a character vector...OK## - Is column (value) a list...OK## - Column (data type) does not contain any NA values... OK## - Is the column (data type) a character vector... OK## - All data type values are in the allowed set (boolean, integer, long, double, string)... OK## - Column (isList) does not contain any NA values...OK## - Column (isList) only contains logical values...OK## - Only allowed columns present (name, value, datatype, isList )...OK## >> Layout Attributes Aspect: OK# # ## Cartesian Layout Aspect Check:## - Is the object of class "CartesianLayoutAspect"...OK## - All required columns (node, x, y) are present...OK## - Column (node) contains only single element values...OK## - Column (node) only contains numeric values...OK## - The column(node) does not contain any values NA...OK## - Column(x) contains only numeric values. ..OK## - Column (x) does not contain any NA values...OK## - Column (y) contains only numeric values...OK## - Column (y) does not contain any NA values. ..OK## - Only allowed columns present (node, x, y, z)...OK## >> Cartesian layout skin: OK## ## Cytoscape visual properties check Skin:## - Is object of class "CyVisualPropertiesAspect"...OK## - Is the object a list...OK## - Is it a named list ("network", "nodes", "edges", "defaultnodes" or "defaultedges" ")...OK ## - List contains only entries of class "CyVisualProperty"...OK## - At least one of the elements present (network, nodes, edges, defaultNodes, defaultEdges)...OK# # For defaultNodes: Cytoscape Visual Check Property Subaspect:## - Is the object of class "CyVisualProperty"...OK## - Is the object a list...OK## - Is a named list (" appliesTo", "view", "properties", "dependencies" or "assignments")...OK## - The list item (applies to) contains only numeric values...OK## - The list item (view) contains only numeric values...OK## - Combination of columns (applies to, view) contains only unique values... OK## - At least one of the elements present (properties, dependencies, assignments). .. OK## Checking Cytoscape visual property mappings: ## - Are the mappings a list? ..OK## - List contains only entries of class "CyVisualPropertyMappings"...OK## - All required columns present (name, type, definition)...OK## - All elements of list of name contain only character values ...OK## - All list items name contain no value NA...OK## - All list items (name) contain only unique values...OK ## - All type list items contain only character values...OK## - All type list items contain no NA values...OK## - All definition list items contain character values only...OK## - All definition list items does not contain any NA values...OK## - Only allowed columns present (name, type, definition)...OK## >> Cytoscape Visual Property Subaspect: OK## >> Cytoscape Visual Property Aspect: OK ## ## Cytoscape Aspect Hidden Attributes Check:## - Is object of class "CyHiddenAttributesAspect"...OK## - All required columns are present (name, value, datatype, isList)...OK## - Column (name ) contains only unique values... OK## - Is column (name) a vector of characters... OK## - Is the column (value) a list... OK## - The column (data type) does not contain any NA values...OK## - Is the column (data type) ) a character vector...OK## - All data type values are in the allowed set (boolean, integer, long, double, string)... OK## - Column (isList) does not contain any NA value... OK## - Column (isList) contains only logical values... OK## - Only allowed columns present (name, value, datatype, isList) ...OK## >> Appearance from Cytoscape hidden attributes: OK## ## Checking RCX:## - Is object of class "RCX"...OK## - Node skin is present...OK## - Validate node skin. ..OK## - Validate edge aspect...OK## - Reference Aspect (nodes) present and correct...OK## - All reference IDs exist (source EdgesAspect$ids in NodesAspect$id) . .OK## - All id references exist (target EdgesAspect$id in NodesAspect$id)...OK## - Validate node attributes aspect...OK## - Reference Aspect (nodes) present and correct...OK# # - All id references exist (NodeAttributesAspect$propertyOf ids in NodesAspect$id)...OK## - Validate edge attribute aspect...OK## - Reference aspect (edges) present and correct...OK## - All id references exist (EdgeAttributesAspect$propertyOf ids in EdgesAspect$id)...OK## - Validate network attributes aspect...OK## - Validate cartesian layout aspect ...OK## - Reference Aspect (nodes) present and correct ...OK## - All id references exist (CartesianLayoutAspect$node ids in NodesAspect$id)...OK## - Validate the aspect of cytoscape visual property...OK## - Validate cytoscape hidden attribute appearance...OK# # >> RCX: OK
Verbose output also shows what tests are performed on. Let's manually enter an error in one aspect and validate only this one again. Therefore, we simply duplicate a node ID.
nodes <- rcx$nodosnodos$id[1] <- nodes$id[2] test <- validate(nodes)
## Node Aspect Check:## - It is an object of class "NodesAspect"... OK## - All required columns are present (id)... OK## - Column (id) is not contains no NA value. .OK## - At least one node present...OK## - Column(id) contains only unique values...FAIL## - Column(id) contains only numeric values...OK## - The column (id) ) contains only positive values (>=0)...OK## - No merge artifacts present (ie column with old ids: oldId)...OK## - Only allowed columns present ( id, name, represents). .OK## >> Appearance of nodes: FAIL
proof
## [1] FALSE
As expected, the test fails and returnsFALSE
.
It is always useful to get basic information about the network. For example, it can be the number of elements in the different aspects of the network:
countElements(rcx)
## NodesAspect MetaDataAspect EdgesAspect ## 75 NA 159 ## NodeAttributesAspect EdgeAttributesAspect NetworkAttributesAspect ## 1129 229 10 ## CartesianLayoutAspect CyHiddenAttributesAspect CyVisualPropertiesAspect ## 75 1 1
This also works for individual skins:
countElements(rcx$nodes)
## [1] 75
To determine if an aspect contains IDs (as opposed to knowing it in advance), this can be checked with:
hasIds(rcx$nodes)
## [1] TRUE
If an aspect has an ID, you can check which is the most used ID, so you know which ID the next elements should continue under before adding them. This can even be done for the entire network at once.
maxId(rcx$nodes)
## [1] 11551
maxId(rcx)
## NodesAspect EdgesAspect ## 11551 11554
Since we now know that the aspect of the nodes has IDs, we can also determine the name of the property that contains the IDs:
idProperty(rcx$nodes)
## [1] "identification"
Other skins use those IDs to reference them. Let's find out what aspect is referred to by others:
referred to (rcx)
## $NodesAspect## [1] "EdgesAspect" "NodeAttributesAspect" "CartesianLayoutAspect"## ## $EdgesAspect## [1] "EdgeAttributesAspect"
The appearance of the nodes refers to the appearance of the edges, so we can figure out which properties of the appearance of the edges refer to it:
refers to (rcx $edges)
## origin destination ## "Aspect of nodes" "Aspect of nodes"
It may have come to your attention that there is a difference between the aspect name and the aspect class. This has been done intentionally to avoid naming conflicts. The different names can be converted to each other:
## all classes aspectClasses
## rcx metaData ## "RCX" "MetaDataAspect" ## bordes de nodos ## "NodesAspect" "EdgesAspect" ## nodeAttributes edgeAttributes ## "NodeAttributesAspect" "EdgeAttributesAspect" ## networkAttributes cartesianLayout ## "NetworkAttributesAspect" "CartesianLayoutAspect" ## cyGroups cyVisualProperties ## "CyGroupsAspect" "CyVisualPropertiesAspect" ## cyHiddenAttributes cyNetworkRelations ## "CyHiddenAttributesAspect" "CyNetworkRelationsAspect" ## cySubNetworks cyTableColumn ## "CySubNetworksAspect" "CyTableColumnAspect" ## networkProvenance ## "NetworkPro venanceAspect"
## class of nodesaspectName2Class("nodes")
## nodes ## "Aspect Nodes"
## access name of NodesAspectaspectClass2Name("NodesAspect")
## [1] "nodes"
## class roundtrip(rcx[[aspectClass2Name("NodesAspect")]])
## [1] "NodesAspecto" "data.frame"
Use:This function can help especially to write the RCX data model extension (see03 Extension of the RCX data model).
The RCX package provides conversion to and from iGraph and Bioconductor graph objects, both widely used libraries for graph manipulation and network analysis.
5.1igrafo
igraph is a library for creating and manipulating graphs and analyzing (especially large) networks. RCX networks can be simply converted to igraph objects as follows:
biblioteca (igraph)
## ## Attaching package: 'igraph'
## The following objects are masked from 'package: stats': ## ## decompose, wraith
## The following object is masked from 'package: base': ## ## union
ig <- toIgraph(rcx)summary(ig)
## IGRAPH efcac9d UN-- 75 159 -- ## + attr: attr...name(g/c), description(g/c), smpdb(g/c),## | sbmlVersion(g/c), sbmlId(g/c), metaId(g/c), sbmlNetwork(g/c),## | label (g/c), network type (g/c), reference (g/c), name (v/n), id## | (v/n), sbo(v/c), metaId(v/c), compartmentcode(v/c),## | codecompartment... datatype(v/c), sbmltype(v/c), sbmlid(v/c), ## | reversible (v/c), compartment sbml(v/c), cyId(v/c), label(v/c),## | sbml type ext(v/c), fast(v/c), constant(v/c), units(v/c),## | boundary condition (v/c), derived units (v/c), initial amount of sbml## | (v/c), value(v/c), substanceunits(v/c), hasOnlySubstanceUnits## | (v/c), uniprot(v/c), inchikey(v/c), chebi (v/c), biocyc(v/c), case## | (v/c), knife (v/c), kegg.compound(v/c), inch (v/c),## | pubchem.compound(v/c), hmdb(v/c), scale(v/c), scale... datatype## | (v/c), exponent(v/c), type(v/c), multiplier(v/c), unitSid(v/c),## | cartesianLayout...x(v/n), cartesianLayout...y(v/n), id(e/n),## | interaction (e/c), sbo (e/c), stoichiometry (e/c), interaction type## | (CE)
To ensure a consistent conversion in both directions, some conventions must be matched: For example, avoiding collisions betweenname
used in nodes,name
used as an attribute of the nodes, and thename
used by igraph, the first two were renamed in igraph tonode name
yAttribute Name
respectively. A similar convention is used for Cartesian coordinates: in the igraph object they are stored ascartesian design...x
,cartesian design...and
, ycartesian design...z
.If the vertex attributes match this naming convention, they are assigned the correct aspect when converted back:
rcxFromIg <- fromIgraph(ig)
Igraph objects cannot contain information about the visual representation of the network and therefore Cytoscape aspects are lost in the conversion. But we can simply add theCyVisual Properties
appearance that we previously saved to return to the original design:
rcxFromIg <- actualizarCyVisualProperties(rcxFromIg, originalVisualProperties)
view(rcxFromIg)
Bioconductor graph is a package that implements some simple graph handling capabilities. It can handle multiple edges, but only if the graph is directed and the source and destination do not start or end between the same nodes. Unfortunately, this is the case in our sample network. .A quick solution is to simply change the source and destination address for multiple borders:
dubEdges <- duplicated(rcx$edges[c("source", "target")])s <- rcx$edges$sourcercx$edges$source[dubEdges] <- rcx$edges$target[dubEdges]rcx$edges$ target[dubEdges] <- s[dubEdges]gNel <- toGraphNEL(rcx,directed = TRUE)rcxBack <- fromGraphNEL(gNel)
So we can simply convert the RCX to a graphNEL object:
gNel <- toGraphNEL(rcx, directed = TRUE)gNel
## A graphNEL graph with directed edges## Number of nodes = 75 ## Number of edges = 159
For conversion, igraph is used as the intermediate format, therefore the same conventions apply as for igraph conversion. The conversion back to the RCX object works analogously:
rcxBack <- fromGraphNEL(gNel)rcxBack$metaData
## Metadata:## name version idCounter elementCount consistencyGroup## 1 nodes 1.0 11551 75 1## 2 edges 1.0 11554 159 1## 3 nodeAttributes 1.0 NA 1129 1## 4 edgeAttributes 1.0 NA 388 1## 5 networkAt taxes 1.0 NA 10 1## 6 Cartesian design 1.0 NA 75 1
Like igraph, graphNEL objects cannot contain information about the visual representation of the network, so here too we can restore the original layout by adding theCyVisual Properties
aspect that we saved previously.
sessionInfo()
## R version 4.3.0 RC (2023-04-13 r84269)## Platform: x86_64-pc-linux-gnu (64-bit)## Running under: Ubuntu 22.04.2 LTS## ## Matrix products: default # # BLAS: /home/biocbuild/bbs-3.17-bioc/R/lib/libRblas.so ## LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.10.0## ## configuration regional:## [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C ## [3] LC_TIME=en_GB LC_COLLATE=C ## [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 ## [ 7] LC_PAPER=en_US.UTF-8 LC_NAME=C ## [9] LC_ADDRESS=C LC_TELEPHONE=C ## [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C ## ## time zone: Americas/New_York## tzcode source: system (glibc)## ## attached base packages:## [1] statistics graphs grDevices utils datasets base methods ## ## other attached packages:## [1] igraph_1.4.2 base64enc_0.1-3 RCX_1. 4.0 knitr_1.42 ## [5] BiocStyle_2.28.0## ## loaded via namespace (and not attached):## [1] cli_3.6.1 rlang_1.1.0 xfun_0.39 ## [4] jsonlite_1 .8.4 plyr_1. 8.8 htmltools_0.5.5 ## [7] graph_1.78.0 stats4_4.3.0 formatR_1.14 ## [10] sass_0.4.5 rmarkdown_2.21 evaluate_0.20 ## [13] jquerylib_0.1.4 fastmap_1.1.1 yaml_2.3.7 ## [16 ] bookdown_0.33 BiocManager_1.30.20 compiler_4.3.0 ## [19] Rcpp_1.0.10 pkgconfig_2.0.3 digest_0.6.31 ## [22] R6_2.5.1 magrittr_2.0.3 bslib_0.4.2 ## [25] tools_4.3.0 BiocGenerics _0.46.0 cache m_1 .0.7