Networks are a powerful and flexible methodology for expressing biological knowledge for computation and communication. Albeit its benefits, the sharing of networks, the collaboration on network curation, keeping track of changes between different network versions, and detecting different versions itself, still is a major problem in network biology.
The Network Data Exchange, or NDEx, is an open-source software framework to manipulate, store and exchange networks of various types and formats (Pratt et al., 2015, Cell Systems 1, 302-305, October 28, 2015 ©2015 Elsevier Inc. ScienceDirect). NDEx can be used to upload, share and publicly distribute networks, while providing an output in formats, that can be used by plenty of other applications.
The public NDEx server is a network data commons which provides pathway collections like the Pathway Interaction Database of the NCI (http://www.ndexbio.org/#/user/301a91c6-a37b-11e4-bda0-000c29202374) and the Cancer Cell Maps Initiative (http://www.ndexbio.org/#/user/b47268a6-8112-11e6-b0a6-06603eb7f303).
This package provides an interface to query the public NDEx server, as well as private installations, in order to upload, download or modify biological networks.
This document aims to help the user to install and benefit from the wide range of funtionality of this implementation. The package also provides classes to implement the Cytoscape Cyberinfrastructure (CX) Format and to extend the [iGraph Package] (http://igraph.org/r/).
The package is compatible with both NDEx versions 1.3 and 2.0.
Some short overview of the most important functions
## search the networks for "EGFR"
networks <- ndex_find_networks(ndexcon, "EGFR")
## UUID of the first search result
networkId <- networks[1,'externalId']
## get summary of the network
networkSummary <- ndex_network_get_summary(ndexcon, networkId)
## get the entire network as RCX object
rcx <- ndex_get_network(ndexcon, networkId)
## remove NDEx artefacts from network
rcx <- rcx_asNewNetwork(rcx)
## do some fancy stuff with the network, then
## update the meta-data
rcx <- rcx_updateMetaData(rcx)## upload network as a new network to the NDEx server
networkId <- ndex_create_network(ndexcon, rcx)
## do some other fancy stuff with the network, then
## update the network on the server
networkId <- ndex_update_network(ndexcon, rcx)
## realize, you did bad things to the poor network, so better
## delete it on the server
ndex_delete_network(ndexcon, networkId)First, establish an connection to the NDEx server. This object is required for most of the other ndexr functions, because it stores options and authentication details. It is possible to connect to the server anonymously or provide a username and password to enable further functionality. If you have set up your own NDEx server, you might change the host to your local installation.
## load the library
library(ndexr)
## connect anonymously
ndexcon = ndex_connect()
## log in with user name and password
ndexconUser = ndex_connect(username="username", password="password")
## specify the server
ndexconLocal = ndex_connect(username="username",
password="password",
host="localhost:8888/ndex/rest")
## manually change the api and connection configuration
ndexcon13 = ndex_connect(ndexConf=ndex_config$Version_1.3)This package is developed following the structure of the documented api structure. For complete description of the NDEx server api see http://www.home.ndexbio.org/using-the-ndex-server-api/. The R functions are named by the category, context and function they fullfil. In the following, the usage is described in detail, and hopefully gives a better understanding of logic behind the naming convention of this package.
To explore or search the networks on an NDEx server, this package offers a function to retrieve a list of networks from the server. It is possible to restrict the networks to a specific search string (e.g. “EGFR”), an account name (only networks of this account will be shown), or limit the number of fetched networks.
## list networks on server
networks <- ndex_find_networks(ndexcon)
## same as previous
networks <- ndex_find_networks(ndexcon, start=0, size=5)
## search for "EGFR"
networksEgfr <- ndex_find_networks(ndexcon, searchString="EGFR")
## same as previous
networksEgfr <- ndex_find_networks(ndexcon, "EGFR")
## same as previous
networksOfUser <- ndex_find_networks(ndexcon, accountName="ndextutorials")As result you get a data.frame containing information of the networks.
## [1] "ownerUUID" "isReadOnly" "subnetworkIds"
## [4] "isValid" "warnings" "isShowcase"
## [7] "isCertified" "indexLevel" "hasLayout"
## [10] "hasSample" "visibility" "nodeCount"
## [13] "completed" "edgeCount" "version"
## [16] "owner" "name" "properties"
## [19] "description" "externalId" "isDeleted"
## [22] "modificationTime" "creationTime"## name externalId
## 1 Gene-Variant Associations b30b57c3-8172-11e8-a4bf-0ac135e8bacf
## 2 Gene-Disease Associations b9989f1c-816f-11e8-a4bf-0ac135e8bacf
## 3 Variant-Disease Associations 51bb8860-855c-11e8-a4bf-0ac135e8bacf
## 4 Variant-Drug Associations b59a3728-855f-11e8-a4bf-0ac135e8bacf
## 5 rasmachine 85276abf-379f-11e7-8f50-0ac135e8bacfTo both, users and networks stored on an NDEx server, a universally unique identifier (UUID) is assigned. Although both have the same format (i.e. “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”, where x is one of [a-z0-9]), it has to be distinguished between the user UUID and the network UUID, but the difference is obvious by the context. Within RCX objects and search results, the network UUID is also referred to as “externalId” (see previous section). This UUID can be used to access a network on the server and retrieve just a summary of the network (similar to the results of a network search) or even the entire network as RCX object (see next section).
Since networks can contain many nodes and edges, and a huge amount of other attributes, it is typically advisable to first get a network summary, to check the node and edge counts for a network before retrieving the entire network. Thereby the structure of the network summary is similar the structure of the network list
## UUID of the first search result
networkId <- networksOfUser[1,'externalId']
## get network summary
networkSummary <- ndex_network_get_summary(ndexcon, networkId)
names(networkSummary)## [1] "ownerUUID" "isReadOnly" "subnetworkIds"
## [4] "isValid" "warnings" "isShowcase"
## [7] "isCertified" "indexLevel" "hasLayout"
## [10] "hasSample" "visibility" "nodeCount"
## [13] "completed" "edgeCount" "version"
## [16] "owner" "name" "properties"
## [19] "description" "externalId" "isDeleted"
## [22] "modificationTime" "creationTime"## $name
## [1] "Metabolism of RNA"
##
## $externalId
## [1] "c9243cce-2d32-11e8-b939-0ac135e8bacf"To send a network to an server, there are two possibilities. Either one wants to update an existing network on the server or create a new one. In both cases, a UUID is returned, either of the updated network or a newly generated one for the created network. For updating a network, the UUID is extracted from the “externalId” property of the “ndexStatus” aspect, or can be set manually.
## create a new network on server
networkId <- ndex_create_network(ndexcon, rcx)
## update a network on server
networkId <- ndex_update_network(ndexcon, rcx)
## same as previous
networkId <- ndex_update_network(ndexcon, rcx, networkId)Besides creating, reading and updating, it is also possible to delete networks on the server. This operation cannot be undone, so be careful!
This example workflow shows how to connect to the public NDEx server, browse and retrieve the pathways of the Pathway Interaction Database of the NCI which are hosted there.
## load the library!
library(ndexr)
## login to the NDEx server
ndexcon = ndex_connect()
## retrieve pathways of user "nci-pid"
networks_pid <- ndex_find_networks(ndexcon, accountName="nci-pid")
## list retrieved network information
networks_pid[,"name"]
## show information on the first pathways listed
networks_pid[1,]
## retrieve network data
mynetwork = ndex_get_network(ndexcon, networks_pid[1,"externalId"])
## convert into R graph format
mygraph = rcx_toRCXgraph(mynetwork)
## show graph information
mygraph
## use readable node names instead of IDs and plot the graph
V(mygraph)[as.character(mynetwork$nodes[,"@id"])]$name = mynetwork$nodes[,"n"]
plot(mygraph)This code snippet starts with loading the ndexr library and connecting to the server anonymously. Afterwards ndex_find_networks retrieves a list of networks of user nci-pid, which contains the data of the Pathway Interaction Database. The function ndex_get_network downloads the network data and stores in the RCX format (explained in the next section) and is then converted into an igraph-based object via rcx_toRCXgraph. Here, the node IDs of the graph are set to readable names and the graph is plotted. Naturally, this graph can be annotated and beautified as required for the specific use cases.
For the exchange of network data, NDEx uses the Cytoscape Cyberinfrastructure Network Interchange Format, or just CX format (See http://www.home.ndexbio.org/data-model/). CX is an Aspect-Oriented Network Interchange Format encoded in JSON, which is used as basis for the R implementation of the CX format, namely RCX.
The RCX object is currently implemented within this package as a list of data.frames, containing meta-data and all aspects of the network. The structure of an RCX object, as shown via str(rcx) could be a list like this:
## List of 12
## $ metaData :'data.frame': 9 obs. of 7 variables:
## ..$ consistencyGroup: int [1:9] 1 1 1 1 1 1 1 1 1
## ..$ elementCount : int [1:9] 1 1 152 9885 17458 4 551 276 0
## ..$ lastUpdate : num [1:9] 1.52e+12 1.44e+12 1.44e+12 1.44e+12 1.44e+12 ...
## ..$ name : chr [1:9] "ndexStatus" "@context" "citations" "edgeCitations" ...
## ..$ properties :List of 9
## ..$ version : chr [1:9] "1.0" "1.0" "1.0" "1.0" ...
## ..$ idCounter : int [1:9] NA NA 69733788 NA 69733891 NA NA 69733888 NA
## $ numberVerification:'data.frame': 1 obs. of 1 variable:
## ..$ longNumber: num 2.81e+14
## $ @context :'data.frame': 1 obs. of 39 variables:
## ..$ KEGG REACTION : chr "http://identifiers.org/kegg.reaction/"
## ..$ RAT GENOME DATABASE : chr "http://identifiers.org/rgd/"
## ..$ INTACT : chr "http://identifiers.org/intact/"
## ..$ ChEBI : chr "http://identifiers.org/chebi/"
## ..$ HETEROGEN : chr "http://uri.ndexbio.org/ns/9d13db7d-63db-11e5-b435-06603eb7f303/HETEROGEN/"
## ..$ BIOGRID : chr "http://identifiers.org/biogrid/"
## ..$ Wikipedia : chr "http://identifiers.org/wikipedia.en/"
## ..$ GENE ONTOLOGY : chr "http://identifiers.org/go/"
## ..$ PANTHER FAMILY : chr "http://identifiers.org/panther.family/"
## ..$ UniProt Isoform : chr "http://identifiers.org/uniprot.isoform/"
## ..$ GENECARDS : chr "http://identifiers.org/genecards/"
## ..$ PUBCHEM-SUBSTANCE : chr "http://uri.ndexbio.org/ns/9d13db7d-63db-11e5-b435-06603eb7f303/PUBCHEM-SUBSTANCE/"
## ..$ DrugBank : chr "http://www.drugbank.ca/drugs/"
## ..$ HGNC : chr "http://identifiers.org/hgnc/"
## ..$ REACTOME : chr "http://identifiers.org/reactome/"
## ..$ UniProt Knowledgebase : chr "http://identifiers.org/uniprot/"
## ..$ UNIPROT ACCESSION : chr "http://uri.ndexbio.org/ns/9d13db7d-63db-11e5-b435-06603eb7f303/UNIPROT_ACCESSION/"
## ..$ KEGG COMPOUND : chr "http://identifiers.org/kegg.compound/"
## ..$ HPRD : chr "http://identifiers.org/hprd/"
## ..$ PHARMGKB GENE : chr "http://uri.ndexbio.org/ns/9d13db7d-63db-11e5-b435-06603eb7f303/PHARMGKB_GENE/"
## ..$ GENPEPT : chr "http://www.ncbi.nlm.nih.gov/protein/"
## ..$ NCBI GENE : chr "http://identifiers.org/ncbigene/"
## ..$ PUBCHEM-COMPOUND : chr "http://identifiers.org/pubchem.compound/"
## ..$ VEGA : chr "http://uri.ndexbio.org/ns/9d13db7d-63db-11e5-b435-06603eb7f303/VEGA/"
## ..$ CHEMICAL NAME : chr "http://uri.ndexbio.org/ns/9d13db7d-63db-11e5-b435-06603eb7f303/CHEMICAL_NAME/"
## ..$ ENSEMBL : chr "http://identifiers.org/ensembl/"
## ..$ OMIM : chr "http://identifiers.org/omim/"
## ..$ PROTEIN DATA BANK : chr "http://identifiers.org/pdb/"
## ..$ HGNC SYMBOL : chr "http://identifiers.org/hgnc.symbol/"
## ..$ NUCLEOTIDE GENBANK IDENTIFIER: chr "http://www.ncbi.nlm.nih.gov/nuccore/"
## ..$ GENATLAS : chr "http://identifiers.org/genatlas/"
## ..$ CHEMICAL COMPONENT DICTIONARY: chr "http://uri.ndexbio.org/ns/9d13db7d-63db-11e5-b435-06603eb7f303/CHEMICAL_COMPONENT_DICTIONARY/"
## ..$ GENBANK INDENTIFIER : chr "http://uri.ndexbio.org/ns/9d13db7d-63db-11e5-b435-06603eb7f303/GENBANK_INDENTIFIER/"
## ..$ InChIKey : chr "http://identifiers.org/inchikey/"
## ..$ INTERPRO : chr "http://identifiers.org/interpro/"
## ..$ CAS : chr "http://identifiers.org/cas/"
## ..$ REFSEQ : chr "http://identifiers.org/refseq/"
## ..$ ENA : chr "http://identifiers.org/ena.embl/"
## ..$ CHEMBL : chr "http://identifiers.org/chembl.compound/"
## $ ndexStatus :'data.frame': 1 obs. of 10 variables:
## ..$ externalId : chr "c9243cce-2d32-11e8-b939-0ac135e8bacf"
## ..$ creationTime : num 1.52e+12
## ..$ modificationTime: num 1.52e+12
## ..$ visibility : chr "PUBLIC"
## ..$ published : logi FALSE
## ..$ nodeCount : int 276
## ..$ edgeCount : int 17458
## ..$ owner : chr "ndextutorials"
## ..$ ndexServerURI : chr "http://public.ndexbio.org"
## ..$ readOnly : logi FALSE
## $ provenanceHistory :'data.frame': 1 obs. of 1 variable:
## ..$ entity:'data.frame': 1 obs. of 3 variables:
## $ citations :'data.frame': 152 obs. of 7 variables:
## ..$ @id : int [1:152] 69716032 69716033 69716034 69716035 69716057 69716120 69716237 69716238 69716243 69716244 ...
## ..$ dc:title : chr [1:152] "" "" "" "" ...
## ..$ dc:contributor: logi [1:152] NA NA NA NA NA NA ...
## ..$ dc:identifier : chr [1:152] "pmid:11983179" "pmid:12776181" "pmid:2944599" "pmid:8196654" ...
## ..$ dc:type : chr [1:152] "URI" "URI" "URI" "URI" ...
## ..$ dc:description: logi [1:152] NA NA NA NA NA NA ...
## ..$ attributes :List of 152
## $ edgeCitations :'data.frame': 9885 obs. of 2 variables:
## ..$ po :List of 9885
## ..$ citations:List of 9885
## $ edges :'data.frame': 17458 obs. of 4 variables:
## ..$ @id: int [1:17458] 69716000 69716002 69716004 69716006 69716008 69716010 69716012 69716014 69716016 69716018 ...
## ..$ s : int [1:17458] 69715997 69715997 69715997 69715997 69715997 69715997 69715997 69715997 69715997 69715997 ...
## ..$ t : int [1:17458] 69715998 69716001 69716003 69716005 69716007 69716009 69716011 69716013 69716015 69716017 ...
## ..$ i : chr [1:17458] "chemical-affects" "chemical-affects" "chemical-affects" "chemical-affects" ...
## $ networkAttributes :'data.frame': 4 obs. of 2 variables:
## ..$ n: chr [1:4] "name" "description" "version" "ndex:sourceFormat"
## ..$ v: chr [1:4] "Metabolism of RNA" "<div><span style=\"font-size: 13.86px;float: none;\">*** This network is used for tutorial purpose only and wil"| __truncated__ "OFFICIAL" "SIF"
## $ nodeAttributes :'data.frame': 551 obs. of 4 variables:
## ..$ po: int [1:551] 69715997 69715997 69715998 69715998 69716001 69716001 69716003 69716003 69716005 69716005 ...
## ..$ n : chr [1:551] "alias" "relatedTo" "alias" "relatedTo" ...
## ..$ v :List of 551
## ..$ d : chr [1:551] "list_of_string" "list_of_string" "list_of_string" "list_of_string" ...
## $ nodes :'data.frame': 276 obs. of 2 variables:
## ..$ @id: int [1:276] 69715997 69715998 69716001 69716003 69716005 69716007 69716009 69716011 69716013 69716015 ...
## ..$ n : chr [1:276] "2-amino-7-methyl-1,7-dihydro-6H-purin-6-one" "DDX20" "GEMI2" "GEMI4" ...
## $ status :'data.frame': 1 obs. of 2 variables:
## ..$ error : chr ""
## ..$ success: logi TRUE
## - attr(*, "class")= chr [1:2] "RCX" "list"The data.frames representing nodes and edges could look like this:
## @id n
## 1 69715997 2-amino-7-methyl-1,7-dihydro-6H-purin-6-one
## 2 69715998 DDX20
## 3 69716001 GEMI2
## 4 69716003 GEMI4
## 5 69716005 GEMI5## @id s t i
## 1 69716000 69715997 69715998 chemical-affects
## 2 69716002 69715997 69716001 chemical-affects
## 3 69716004 69715997 69716003 chemical-affects
## 4 69716006 69715997 69716005 chemical-affects
## 5 69716008 69715997 69716007 chemical-affectsUsually, and RCX object is automatically created by using the functions of this package for downloading network data from a NDEx server. But it might be useful to convert an RCX object from/to JSON manually, for example for down-/uploading a CX file from/to a NDEx server via the web interface. For handling the network information within R, besides RCX objects, one can use RCXgraph objects. A lossless conversion between the two files can be done using the following functions:
## convert RCX to JSON
json <- rcx_toJSON(rcx)
## ...and back
rcx <- rcx_fromJSON(json)
## convert RCX to RCXgraph
rcxgraph <- rcx_toRCXgraph(rcx)
## ...and back
rcx <- rcxgraph_toRCX(rcxgraph)It is possible to create blank RCX objects from scratch:
After a RCX object is downloaded from an NDEx server, it will contain some aspects that are not present in a newly generated network, i.e. “ndexStatus”, “provenanceHistory” and “status”. Removing those aspects might be useful in some cases.
After a RCX object underwent some changes (adding/removing nodes/edges/aspects/meta- data, etc.), it is advisable to check a RCX object for its integrity and update its meta-data.
The meta-data is not only updated by the function, but also created, if not existent in the first place. It is necessary to mention, that the function tries to check the format and content of most of the aspects and properties, but due to the dynamic structure of RCX and CX, it is advised to have a look at the CX data model specification for a deeper insight about the core structure, dependencies and limitations.
In general it is not advisable to retrieve a complete RCX object from a server without knowing the number of aspects and its corresponding size, because this may cause unwanted or unnecessary network traffic and decline in performance. To avoid these problems, a possible workflow is to download the meta-data of a network at first to check the available aspects.
## get meta-data for a network
metadata = ndex_network_get_metadata(ndexcon, networkId)
names(metadata)## [1] "name" "elementCount" "version"
## [4] "consistencyGroup" "properties" "idCounter"## name elementCount
## 1 @context 1
## 2 citations 152
## 3 edgeCitations 9885
## 4 edges 17458
## 5 networkAttributes 4
## 6 nodeAttributes 551
## 7 nodes 276
## 8 provenanceHistory 0Afterwards, only the favored aspects can be downloaded individually.
## get aspect "nodeCitations" for the network
networkAttibutes = ndex_network_get_aspect(ndexcon, networkId, "networkAttributes")
networkAttibutes## n
## 1 name
## 2 description
## 3 version
## 4 ndex:sourceFormat
## v
## 1 Metabolism of RNA
## 2 <div><span style="font-size: 13.86px;float: none;">*** This network is used for tutorial purpose only and will not be updated. ***</span><br/></div>
## 3 OFFICIAL
## 4 SIFEven after creation, it is possible to change the name, the description or version of a network.
ndex_network_update_profile(ndexcon, networkId, name="My network", version="1.3")
ndex_network_update_profile(ndexcon, networkId, description="Nothing to see here")For collaborative work, it is necessary to share networks between several users and groups. Therefore there are specialized functions to grant access to a network, change the permissions and withdraw access permissions. It is possible to use those functions on single users or groups. Possible permissions are “READ” to have reading access to private networks, “WRITE” to be able modify, and “ADMIN” for the owner of the network.
## show all user who have permission to a network
permissions = ndex_network_get_permission(ndexcon, networkId, 'user')
## show all groups who have permission to a network
permissions = ndex_network_get_permission(ndexcon, networkId, 'group')
## show all users with write access to a network
permissions = ndex_network_get_permission(ndexcon, networkId, 'user', 'WRITE')
## grant an user permission to a network
ndex_network_update_permission(ndexcon, networkId, user=someUserUuid, 'READ')
## change the permission of an user to the network
ndex_network_update_permission(ndexcon, networkId, user=someUserUuid, 'WRITE')
## withdraw the permission from an user
ndex_network_delete_permission(ndexcon, networkId, user=someUserUuid)Besides permission management on user and group level, it is also possible to set some system properties on a network that influence the accessibility further. By default a network is private, which means that it is only visible to the owner and invited users and groups. If at some point one decides to make the network readable by anyone, it is possible to change the visibility of a network to “PUBLIC”.
ndex_network_set_systemProperties(ndexcon, networkId, visibility="PUBLIC")
ndex_network_set_systemProperties(ndexcon, networkId, visibility="PRIVATE")When a network has reached the point to be published, further edits should be prevented. While it would be possible to set the access permissions of all users and groups to “READ”, this approach is very inconvenient. Therefore, a simpler way is to just set the network to read-only using the network system properties.
One also has the option at the NDEx server to choose a selection of their favorite networks for display in his or her home page.
ndex_network_set_systemProperties(ndexcon, networkId, showcase=TRUE)
ndex_network_set_systemProperties(ndexcon, networkId, showcase=FALSE)
# change more than one property simultaneously
ndex_network_set_systemProperties(ndexcon, networkId, readOnly=TRUE, visibility="PUBLIC", showcase=TRUE)The provenance history aspect of an NDEx network is used to document the workflow of events and information sources that produced the current network (for the official provenance documentation see http://www.home.ndexbio.org/network-provenance-history/ ). There is a convenience function, that retrieves the provenance of the network.
In the following table all API functions are listed. The functions are grouped by the content they access, namely networks, users, or groups. For every function also is shown, if authentication is needed, and by which version it is supported (Version 2.0 or 1.3). A function marked with brackets indicates, that, although the function would be supported by this version, for different reasons no function could be implemented. Limitations of the single API functions are also given in the column of the corresponding version.
| Function name | Authentication | Version 2.1 | Version 2.0 | Version 1.3 |
| Networks | ||||
| ndex_find_networks | no | X | X | |
| ndex_network_get_summary | no | X | X | |
| ndex_get_network | no | X | X | |
| ndex_create_network | yes | X | X | |
| ndex_update_network | yes | X | X | |
| ndex_delete_network | yes | X | X | |
| ndex_network_get_metadata | no | X | (x) | |
| ndex_network_aspect_get_metadata | no | (x) | ||
| ndex_network_get_aspect | no | X | (x) | |
| ndex_network_update_aspect | yes | (x) | ||
| ndex_network_get_permission | yes | X | only for users, different response | |
| ndex_network_update_permission | yes | X | (only for users) | |
| ndex_network_delete_permission | yes | X | only for users | |
| ndex_network_set_systemProperties | yes | X | only readOnly | |
| ndex_network_update_profile | yes | X | X | |
| ndex_network_get_provenance | no | X | X | |
| Users | ||||
| ndex_find_users | no | X | X | |
| ndex_find_user_byName | no | X | ||
| ndex_find_user_byId | no | X | ||
| ndex_create_user | yes | X | ||
| ndex_delete_user | yes | X | ||
| ndex_update_user | yes | X | ||
| ndex_verify_user | no | X | ||
| ndex_user_change_password | yes | X | ||
| ndex_user_mail_password | no | X | ||
| ndex_user_forgot_password | no | X | ||
| ndex_user_list_groups | yes | X | ||
| ndex_user_show_group | yes | X | ||
| ndex_user_list_permissions | yes | X | ||
| ndex_user_show_permission | yes | X | ||
| ndex_user_get_showcase | no | X | ||
| ndex_user_get_networksummary | yes | X | ||
| Groups | ||||
| ndex_find_groups | no | X | X | |
| ndex_get_group | no | X | ||
| ndex_create_group | yes | X | ||
| ndex_delete_group | yes | X | ||
| ndex_update_group | yes | X | ||
| ndex_group_list_users | no | X | ||
| ndex_group_set_membership | yes | X | ||
| ndex_group_list_networks | no | X | ||
| ndex_group_network_get_permission | no | X |
In the section “Connect to a server”, briefly a method for manually changing the API version was introduced, with the API definition stored in ndex_config.
## [1] "defaultVersion" "Version_2.1" "Version_2.0" "Version_1.3"## List of 4
## $ defaultVersion: chr "Version_2.0"
## $ Version_2.1 :List of 3
## ..$ version : chr "2.1"
## ..$ connection:List of 3
## .. ..$ description: chr "URL of the NDEx server"
## .. ..$ host : chr "http://www.ndexbio.org"
## .. ..$ api : chr "/v2"
## ..$ api :List of 5
## .. ..$ serverStatus:List of 4
## .. ..$ user :List of 11
## .. ..$ group :List of 6
## .. ..$ network :List of 12
## .. ..$ search :List of 3
## $ Version_2.0 :List of 3
## ..$ version : chr "2.0"
## ..$ connection:List of 3
## .. ..$ description: chr "URL of the NDEx server"
## .. ..$ host : chr "http://www.ndexbio.org"
## .. ..$ api : chr "/v2"
## ..$ api :List of 5
## .. ..$ serverStatus:List of 3
## .. ..$ user :List of 11
## .. ..$ group :List of 6
## .. ..$ network :List of 12
## .. ..$ search :List of 3
## $ Version_1.3 :List of 3
## ..$ version : chr "1.3"
## ..$ connection:List of 3
## .. ..$ description: chr "URL of the NDEx server"
## .. ..$ host : chr "http://www.ndexbio.org"
## .. ..$ api : chr "/rest"
## ..$ api :List of 4
## .. ..$ serverStatus:List of 3
## .. ..$ user :List of 1
## .. ..$ network :List of 11
## .. ..$ search :List of 3This object contains the api definition for several versions (currently version 1.3 and 2.0). By default, ndex_connect() uses the version defined in ndex_config$defaultVersion (“Version_2.0”). To use another, or even a customized version to establish a server connection, the ndexConf parameter can be used, like shown before. In the following, the structure of such a configuration is elaborated in more detail.
## [1] "version" "connection" "api"The main structure of the configuration consists of three elements: The version is used to distinguish manually set configurations, which is used in some API functions to work differently for the single versions.
The “connection” element holds information about the default connection to the server, namely the host (e.g. “http://www.ndexbio.org/”) and the path to the api (e.g. “/v2” or “/rest”).
The REST API itself is defined in the “api” element, and follows the scheme of the function names, or the scheme of url paths likewise. E.g. in the “user” branch the different functions for handling user data are defined. If required, the functions might be grouped together in sub-branches furthermore. At the end of an branch, the actual definition of an API can be found.
To show, how such an API is defined and how to define one by themselves, let’s have a look at ndex_config$Version_2.0$api$user$password$mail, which is used by ndex_user_mail_password(). Where to find the configuration of the function is shown in the “REST query” section of the function documentation. For a better readability, the yaml notation for this function configuration is used:
mail:
description: "Causes a new password to be generated for ..."
url: "/user/#USERID#/password"
method: "PUT"
params:
user:
method: "replace"
tag: "#USERID#"
forgot:
method: "parameter"
tag: "forgot"
default: "true"Note: To get the yaml notation for the whole ndex_config simply use yaml::as.yaml(ndex_config) (requires package yaml to be installed).
The single parameter definitions are given as list by the “params” parameter. Each parameter is defined by a method, and, if applicable, a tag, a default value and/or an optional flag. There are three keywords defining the method: replace, append or parameter.
#NETWORKID# in the url /network/#NETWORKID#/provenance is replaced by a value (e.g. aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee) given as network id, which leads to the url /network/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee/provenance./network/search and the given values for start = 0 and size = 100 generates the following url: /network/search/0/100username and the value SomeName is encoded in the url /user as follows: /user?username=SomeNameIt is also possible to set parameter as optional (except for replace), or define default values. Values are assigned to the parameters using the parameter name in the … parameter of the ndex_helper_encodeParams() function. Parameters, that are not defined in the configuration are ignored.
The easiest to write an own configuration is by simply copying an existing configuration and tailor it to the needs.
# Copy an existing config
custom_ndex_config = ndex_config$Version_2.0
# Change the host connection for a local NDEx server installation
custom_ndex_config$connection$host ="localhost:8090"
# Custom path to the REST api
custom_ndex_config$connection$api ="/api/rest"
# Change the REST path for the ndex_get_network function
custom_ndex_config$api$network$get$url ="/custom/networks/#NETWORKID#"
# Add some (default) parameters to the function
custom_ndex_config$api$network$get$params$newParam = list(method="parameter", tag="someTag", default="someValue")It is also possible to write an own configuration in yaml (or convert ndex_config to yaml, see above) and load it as object (yaml::load or yaml::load_file) or to translate the configuration into R code using the function ndexr:::yamlToRConfig()
Note: For package maintenance it is advised to add new versions as yaml definitions in /R/ndex_api_config.yml (for example as "Version_3.0") and update the R code in /R/ndex_api_config.r, which defines the ndex_config object.
yamlToRConfig = function(yamlFile='R/ndex_api_config.yml', rScriptFile='R/ndex_api_config.r', defaultHeader=ndex_conf_header){
yamlObj = yaml::yaml.load_file(yamlFile)
rCodeTxt = paste0(defaultHeader, listToRCode(yamlObj))
outFile = file(rScriptFile)
writeLines(rCodeTxt, outFile)
close(outFile)
}
yamlToRConfig()