Analyzing Sociocentric Data: The netwrite Function

Sociocentric Data Processing and Analysis

Global, or sociocentric, networks capture a full census of actors (typically referred to as nodes or vertices) and the relationships between them (typically referred to as ties or edges) in a given context of interest (such as a classroom, hospital, city, etc.). Users applying ideanet to sociocentric data can use the netwrite function to generate an extensive common set of measures and summaries of their networks, which may be stored in a variety of data structures.

Network data are generally represented as two linked datasets: the edgelist capturing relations and the nodelist capturing attributes of each node. In an edgelist each row represents an edge of a particular type connecting one node, i, to another node, j, both of whom are represented by a unique ID number. In a directed network, one column represents the sender of a tie while another represents the receiver. If the network is undirected, ties between nodes have no direction, and these columns merely represent the two nodes at the ends of a tie. Edgelists can also contain additional columns representing edge attributes, such as the relational type, strength or duration.

Edgelists are often accompanied by a nodelist containing attribute information about nodes. In a nodelist, each row represents a node in the network and each column is a node attribute. One of the columns is an ID that matches the unique ID number in the edgelist. If your network contains isolates – nodes with no relations – a nodelist is needed to retain information about them, as they cannot be represented in the edgelist.

To familiarize ourselves with netwrite and other functions for sociocentric data, we’ll work with a nodelist and an edgelist representing a simulated network of friendships in an American high school (“Faux Mesa High”) borrowed from the package. Friendship ties between nodes (students) are stored in the fauxmesa_edges data frame, while attributes of individual nodes are contained in fauxmesa_nodes (both of which are native to ideanet):

library(ideanet)

fauxmesa_edges <- fauxmesa_edges
fauxmesa_nodes <- fauxmesa_nodes

Let’s look over these two data frames:

dplyr::glimpse(fauxmesa_edges)
#> Rows: 203
#> Columns: 2
#> $ from <dbl> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 5, 8, 8, 8, 9,…
#> $ to   <dbl> 25, 52, 58, 70, 87, 92, 96, 100, 110, 127, 151, 161, 174, 52, 100…

This edgelist represents 203 directed connections between students. Looking at our nodelist, we see that we have information about grade level, race/ethnicity, and sex for 205 students.

dplyr::glimpse(fauxmesa_nodes)
#> Rows: 205
#> Columns: 4
#> $ id    <dbl> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 1…
#> $ grade <dbl> 7, 7, 11, 8, 10, 10, 8, 11, 9, 9, 9, 11, 9, 11, 8, 10, 10, 7, 10…
#> $ race  <chr> "Hisp", "Hisp", "NatAm", "Hisp", "White", "Hisp", "NatAm", "NatA…
#> $ sex   <chr> "F", "F", "M", "M", "F", "F", "M", "M", "M", "F", "M", "F", "M",…

The netwrite function will generate a comprehensive set of node and system-level measures for a network. netwrite asks users to specify several arguments pertaining to node-level input data, edge-level input data, and function outputs. To familiarize ourselves with this function, we list these arguments below, organized by category.

Edge-Level Arguments

• data_type: Specifies the data format of the input data. This argument accepts three different values – "edgelist", "adjacency_list", and "adjacency_matrix" – each of which correspond to popular formats for storing relational data (we’ll cover adjacency matrices later in this vignette).
• i_elements: A vector of “ego” ids. For directed networks, this argument specifies which nodes serve as the source of directed edges.
• j_elements: A vector of “alter” ids. For directed networks, this argument specifies which nodes serve as the target or destination of directed edges.
• weights: Vector of edge weights, typically used to signify the strength of edges between nodes. If not specified, netwrite will assume that all edges are unweighted and assign them an equal values of 1. Note that netwrite requires that all edge weights be greater than zero.
• weight_type: If weights is specified, this argument determines how netwrite should interpret edge weight values. Possible arguments are: "frequency", indicating the higher values represent stronger ties, and "distance", indicating that higher values represent weaker ties.
• missing_code: A single numeric value indicating a missing tie – in cases where the edge information contains both missing and existing ties. Missing codes often appear in edgelists for which there is not a corresponding nodelist; here missing codes are used to include nodes that are network isolates.
• directed: Specify if the edges should be interpreted as directed or undirected. Expects a TRUE or FALSE logical.
• type: When working with multiple relation types, a numeric or character vector indicating the types of relationships represented in the edgelist.

Node-Level Arguments

• nodelist: If available, one can specify this argument as either a vector of unique node identifiers or a data frame containing a full nodelist (if not specified, node_id will be generated from the edgelist).
• node_id: If a data frame is given for the nodelist argument, this argument should be set to a single character value indicating the name of the column in the nodelist containing unique node identifiers.

Output Arguments

• output: netwrite produces a set of outputs pertaining to different aspects of network analysis. While netwrite produces all possible outputs by default, users may want only a subset to minimize clutter. The output argument takes a character vector specifying which outputs should be created. Possible arguments are: "graph", "largest_bi_component", "largest_component", "node_measure_plot", "nodelist", "edgelist", "system_level_measures", and "system_measure_plot".
• net_name: A character value indicating the name that exported igraph objects should be given.
• message: Silences messages and warnings. Expects TRUE or FALSE logical.
• shiny: A logical value indicating whether netwrite is being used in conjunction with . shiny should also be set to TRUE when using ideanet in an R Markdown file that users expect to knit into a document.

Now let’s use netwrite to get a better understanding of this school’s friendship network:

nw_fauxmesa <- netwrite(data_type = "edgelist",
                        nodelist = fauxmesa_nodes,
                        node_id = "id",
                        i_elements = fauxmesa_edges$from,
                        j_elements = fauxmesa_edges$to,
                        directed = TRUE,
                        net_name = "faux_mesa",
                        shiny = TRUE)
#> Warning in bonacich_igraph(g, directed = as.logical(directed), message =
#> message): (Bonacich power centrality) Isolates detected in network. Isolates
#> will be removed from network when calculating power centrality measure, and
#> will be assigned NA values in final output.
#> Warning in bonacich_igraph(g, directed = as.logical(directed), message = message): (Bonacich power centrality) Adjacency matrix for network is singular. Network will be treated as undirected in order to calculate measures
#> Warning in bonacich_igraph(g, directed = as.logical(directed), bpct = -0.75, :
#> (Bonacich power centrality) Isolates detected in network. Isolates will be
#> removed from network when calculating power centrality measure, and will be
#> assigned NA values in final output.
#> Warning in bonacich_igraph(g, directed = as.logical(directed), bpct = -0.75, : (Bonacich power centrality) Adjacency matrix for network is singular. Network will be treated as undirected in order to calculate measures
#> Warning in eigen_igraph(g, directed = as.logical(directed), message = message): (Eigenvector centrality) Isolates detected in network. Isolates will be removed from network when calculating eigenvector centrality measure, and will be assigned NA values in final output.
#> Warning in eigen_igraph(g, directed = as.logical(directed), message = message): (Eigenvector centrality) Adjacency matrix for network is singular. Network will be treated as undirected in order to calculate measures
#> Warning in eigen_igraph(g, directed = as.logical(directed), message = message): (Eigenvector centrality) Network consists of 2+ unconnected components. Eigenvector centrality scores will be calculated for nodes based on their position within their respective components. Nodes in components consisting of a single dyad will be assigned NA values in final output.
#> Warning in eigen_centralization(g, directed = TRUE): Eigenvector centralization
#> calculated only for largest weak component.
#> Warning in k_cohesion(graph = g): Graph will be treated as undirected for
#> calculation of k-core cohesion measure.

Many network measures only apply to networks with particular structures. For example, eigenvector based methods cannot apply to isolates and many measures assume a network with one large connected component. In cases (as here), where the network does not conform to those expectations, we have made choices that seem reasonable to us (such as assigning NA values or running the measure separately by connected component) and send a warning to the output. Users should take care to inspect these warnings to see if they apply to measures they intend to use in analysis and that they agree with our choices. Here we see that certain centrality measures have been adjusted to account for the presence of singular matrices, multiple components, and isolated nodes.

Upon completion, netwrite stores its outputs in a single list object. In the following section, we’ll examine each of the outputs within this list and what they contain.

Interpreting netwrite Output

nw_fauxmesa$system_measure_plot

head(nw_fauxmesa$system_level_measures)

nw_fauxmesa$faux_mesa
#> IGRAPH a5a95de DNW- 205 203 -- 
#> + attr: name (v/c), attr (v/c), in_original_nodelist (v/l), grade
#> | (v/n), race (v/c), sex (v/c), id (v/n), original_id (v/c),
#> | weak_membership (v/n), in_largest_weak (v/l), strong_membership
#> | (v/n), in_largest_strong (v/l), total_degree (v/n), weighted_degree
#> | (v/n), norm_weighted_degree (v/n), in_degree (v/n), out_degree (v/n),
#> | weighted_indegree (v/n), norm_weighted_indegree (v/n),
#> | weighted_outdegree (v/n), norm_weighted_outdegree (v/n), closeness_in
#> | (v/n), closeness_out (v/n), closeness_undirected (v/n), betweenness
#> | (v/n), bonpow (v/n), bonpow_negative (v/n), eigen_centrality (v/n),
#> | component (v/n), burt_constraint (v/n), burt_hierarchy (v/n),
#> | effective_size (v/n), proportion_reachable_in (v/n),
#> | proportion_reachable_out (v/n), proportion_reachable_all (v/n),
#> | in_largest_bicomponent (v/l), weight (e/n)
#> + edges from a5a95de (vertex names):

plot(nw_fauxmesa$faux_mesa,
     vertex.label = NA,
     vertex.size = 4,
     edge.arrow.size = 0.2,
     vertex.color = igraph::V(nw_fauxmesa$faux_mesa)$grade)

plot(nw_fauxmesa$largest_component, vertex.label = NA, vertex.size = 2, edge.arrow.size = 0.2, 
     main = "Largest Component")

plot(nw_fauxmesa$largest_bi_component, vertex.label = NA, vertex.size = 2, edge.arrow.size = 0.2, 
     main = "Largest Bicomponent")

head(nw_fauxmesa$edgelist)

head(nw_fauxmesa$node_measures)

nw_fauxmesa$node_measure_plot

Adjacency Matrices

In addition to edgelists, netwrite supports processing and analysis of network data stored as an adjacency matrix. An adjacency matrix is a square matrix in which each row and each column corresponds to an individual node in the network. The value of a given cell in this matrix, [i, j], indicates the existence of a tie from node i to node j. Here we provide a quick example of how to use netwrite on an adjacency matrix. The matrix below represents a network of 9 nodes, the ties between which form all possible triads and motifs that can appear in a directed network.

triad
#>       V1 V2 V3 V4 V5 V6 V7 V8 V9
#>  [1,]  0  1  1  1  0  1  0  1  0
#>  [2,]  0  0  0  0  1  0  0  1  0
#>  [3,]  1  0  0  1  0  0  0  1  0
#>  [4,]  1  0  1  0  0  0  0  0  0
#>  [5,]  1  0  0  0  0  1  0  1  0
#>  [6,]  0  0  0  0  0  0  0  0  0
#>  [7,]  0  0  0  0  0  0  0  0  0
#>  [8,]  1  0  0  0  0  1  0  0  0
#>  [9,]  0  0  0  0  0  1  0  0  0

Now we pass this matrix into netwrite.

nw_triad <- netwrite(data_type = "adjacency_matrix",
                     adjacency_matrix = triad,
                     directed = TRUE,
                     net_name = "triad_igraph",
                     shiny = TRUE)

To show that we’ve successfully processed this matrix, let’s plot the igraph object produced by netwrite:

plot(nw_triad$triad_igraph,
     edge.arrow.size = 0.2,
     vertex.label = NA)

Multirelational Networks

In some networks, edges may represent one of several different types of relationships between nodes. These multirelational (or multiplex) networks often demand more detailed processing and analysis— users may want to subset these networks by each edge type and calculate measures based on each subset. netwrite handles such processing and analysis in a streamlined manner while making minimal additional user demands. The function only requires that a multirelational network’s edgelist is stored in a long format in which each dyad-relationship type combination is given its own row.

To show how netwrite works with multirelational networks, we’ll work with an edgelist of relationships between prominent families in Renaissance-era Florence. Here edges between nodes can represent marriages or business transactions between families:

head(florentine_edges)

To treat this network as multirelational, we only need to specify which column in this edgelist indicates the type of each edge in the network. We do this using the type argument:

nw_flor <- netwrite(nodelist = florentine_nodes,
                    node_id = "id",
                    i_elements = florentine_edges$source,
                    j_elements = florentine_edges$target,
                    type = florentine_edges$type,
                    directed = FALSE,
                    net_name = "florentine")
#> Processing network for edge type marriage
#> Processing network for edge type business
#> Processing aggregate network of all edge types

When given a multi-relational network, netwrite will return the outputs described previously in slightly different ways. First, we can see that the edgelist object is now a list containing an edgelist subset by each type of tie. Additionally, this list contains a complete edgelist for the summary_graph containing all ties.

head(nw_flor$edgelist$business)

head(nw_flor$edgelist$summary_graph)

node_measures remains a single data frame, but now includes each node-level metric calculated for each individual relation type as well as the overall graph. We see here that netwrite has calculated 3 different values for total_degree. However, node_measures_plot is now a list containing summary visualizations for each relation type as well as the overall summary_graph.

Similarly, system_level_measures remains a single data frame, while system_measure_plot has become a list containing multiple visualizations. Note that system_level_measures now contains additional column detailing measure values for each individual relation type.

head(nw_flor$system_level_measures)

netwrite also produces both an igraph object of the overall network, as it does with networks with a single relation type, as well as a list of igraph objects for each subset of the network. Here we access the igraph_list object to compare business and marriage relationships between families side-by-side:

# Create a consistent layout for both plots
flor_layout <- igraph::layout.fruchterman.reingold(nw_flor$igraph_list$marriage)
plot(nw_flor$igraph_list$marriage, vertex.label = NA, vertex.size = 4, edge.arrow.size = 0.2, 
     vertex.color = "gray", main = "Marriage Network", layout = flor_layout)

plot(nw_flor$igraph_list$business, vertex.label = NA, vertex.size = 4, edge.arrow.size = 0.2, 
     vertex.color = "red", main = "Business Network", layout = flor_layout)

Community Detection

When analyzing a network, users are often interested in whether nodes cluster together to form distinct subgroups or communities. Many methods exist for identifying discernible communities in a network, and one might want to know how different methods perform the same task. ideanet’s comm_detect function leverages several community detection algorithms found in the igraph package, as well as a couple of others, to find and compare inferred communities across these methods. Where relevant, each method is only run at default values here so, for instance, the edge_betweenness method will warn that mamberships “will be selected based on the highest modularity score” from the dendrogram generated by the method. Similarly cluster_leiden is run here at the default resolution parameter for modularity and at a resolution equal to the average weighted density of the network for the constant Potts model.

Using comm_detect is simple: you only needs to pass an igraph object produced by netwrite into the function. Let’s quickly apply several community detection methods to the Florentine families network we just processed.

flor_communities <- comm_detect(nw_flor$florentine)
#> Warning in comm_detect(nw_flor$florentine): Calling cluster_edge_betweenness
#> with reciprocal weights, which may affect selected membership vector
#> incorrectly.
#> Warning in igraph::cluster_edge_betweenness(g_undir, weights =
#> igraph::E(g_undir)$r_weight, : At
#> vendor/cigraph/src/community/edge_betweenness.c:498 : Membership vector will be
#> selected based on the highest modularity score.

The comm_detect function returns a list of three data frames, and will automatically generate a set of visualizations showing each node’s community membership as determined by each community detection method. Within the list produced, the summaries data frame details the number of communities detected by each method, as well as the modularity score associated with each method. This offers one way of comparing community detection methods— higher modularity scores (within a single network) typically indicate more effective partitioning of the network (though there are many scores that one can use).

flor_communities$summaries

A second data frame in the list, score_comparison, allows for further comparison of community detection methods. score_comparison contains a matrix of adjusted Rand values indicating the level of similarity between two methods in how they assigned nodes to communities. This matrix tells us, for example, that the Fast-Greedy and Leading Eigenvector methods were identical in their community assignment:

flor_communities$score_comparison

memberships, the final data frame in the list, shows each node’s community membership according to each of the methods used.

flor_communities$memberships

memberships is designed to be easily merged with the node_measures data frame produced by netwrite, should users be inclined to combine the two.

node_info <- nw_flor$node_measures %>%
  dplyr::left_join(flor_communities$memberships, by = "id")