<p><div><div><div><div data-show-faces="false" data-height="21" data-width="100" data-layout="button_count" data-send="true" data-href="https://www.r-bloggers.com/network-centrality-in-r-new-ways-of-measuring-centrality/"></div></div><div></div></div><div></div></div>
<div>
(This article was first published on <strong><a href="http://blog.schochastics.net/post/network-centrality-in-r-new-ways-of-measuring-centrality/"> schochastics</a></strong>, and kindly contributed to <a rel="nofollow" href="https://www.r-bloggers.com/">R-bloggers)</a> </div>
<p>This is the third post of a series on the concept of “network centrality” with<br>
applications in R and the package <code>netrankr</code>. The last part introduced the concept of<br>
neighborhood-inclusion and its implications for centrality. In this post, we<br>
extend the concept to a broader class of dominance relations by deconstructing indices<br>
into a series of building blocks and introduce new ways of evaluating centrality.</p>
<pre><code>library(igraph)
library(ggraph)
library(tidyverse)
library(netrankr)</code></pre>
<div>
<h1>Introduction</h1>
<p>Neighborhood-inclusion seems to underlie many different centrality indices and as such<br>
serves (or better: could serve) as a defining property of a centrality index. That is:</p>
<blockquote>
<p>An index is a measure of centrality if and only if it preserves the partial ranking induced by neighborhood-inclusion</p>
</blockquote>
<p>While this gives as a theoretical basis for centrality, it comes with a bit of problem.<br>
Namely, that we do not expect many comparable pairs in (large) real-world networks.<br>
Take the third example network from the first post.</p>
<pre><code>g3 &lt;- readRDS(&quot;example_3.rds&quot;)
P &lt;- neighborhood_inclusion(g3)
comparable_pairs(P)</code></pre>
<pre><code>## [1] 0.00600532</code></pre>
<p>Only 0.6% of pairs are comparable. This means that<br>
centrality indices are at liberty to rank 99.4% of pairs in any order. So, neighborhood-inclusion<br>
may not be very restrictive in large networks. This is much like with <em>structural equivalence</em>.<br>
It is a very intuitive concept for equivalences in networks (having exactly the same neighbors), however we do not expect many equivalent pairs in large networks. This does not render the concept useless, but requires some relaxations.</p>
<p>In the following, we introduce dominance relations, which incrementally extend the<br>
partial ranking of neighborhood-inclusion and thus tighten the partial ranking<br>
that indices preserve. We start by illustrating how indices can be decomposed into a series<br>
of building blocks.</p>
</div>
<div>
<h1>Deconstructing Indices</h1>
<p>Centrality indices assess structural importance based on a great variety of different<br>
graph theoretic notions, like shortest paths (closeness) or walks (subgraph centrality).<br>
Implicitly, though, they all follow a simple recipe:</p>
<ul>
<li>derive an indirect relation</li>
<li>aggregate the indirect relations</li>
</ul>
<p>As mentioned above, indirect relation are commonly derived via graph trajectories such as paths<br>
and walks, for instance to compute distances. The aggregation is usually a simple summation of all relations of a node, but others are<br>
possible too (e.g. <span>\(\max\)</span> as in eccentricity). In its most generic form, we can thus write a centrality index as<br>
<span>\[<br>
c(i)= \sum_j \tau(x)_{ij}<br>
\]</span><br>
where <span>\(x\)</span> are the observed relations (basically the adjacency matrix) and <span>\(\tau\)</span><br>
a generic transformation function. Replacing <span>\(\tau\)</span> with <span>\(id\)</span>, we obtain degree centrality<br>
and setting <span>\(\tau=dist\)</span>, we obtain closeness. A suitable function <span>\(\tau\)</span> can be<br>
defined for all centrality indices, such that any index can basically be seen as degree in an<br>
appropriately transformed network.</p>
<p>The package <code>netrankr</code> provides a set of 24 different indirect relations that can be used<br>
to construct indices. A few common examples are given below.</p>
<pre><code>#closeness 
g %>% 
  indirect_relations(type='dist_sp') %>% 
  aggregate_positions(type='invsum')
  
#betweenness
g %>% 
  indirect_relations(type='depend_sp') %>% 
  aggregate_positions(type='sum')
  
#eigenvector
g %>% 
  indirect_relations(type='walks',FUN=walks_limit_prop) %>% 
  aggregate_positions(type='sum')

#subgraph 
g %>% 
  indirect_relations(type='walks',FUN=walks_exp) %>% 
  aggregate_positions(type='self')</code></pre>
<p>(Consult the help for <code>indirect_relations()</code> to see all options)<br>
Note that we make use of the <code>%>%</code> operator. This should appeal to the recipe<br>
idea from above: <code>network %>% indirect_relation %>% aggregation</code>. The package also<br>
includes a handy RStudio addin, which can be used to build the pipelines more easily.</p>
<p><img src="https://i2.wp.com/blog.schochastics.net/img/index_builder.png?w=456" data-recalc-dims="1"></p>
<p>Defining indices in this way is certainly more cumbersome than using, say, <code>betweennes(g)</code>.<br>
However, it allows us to intervene at any step and <em>do something else</em>.</p>
</div>
<div>
<h1>Extended Dominance Relations</h1>
<p>To illustrate the “something else”, we look at our small example network again.</p>
<pre><code>g1 &lt;- readRDS(&quot;example_1.rds&quot;)</code></pre>
<p><img src="https://i0.wp.com/blog.schochastics.net/post/2018-12-12-network-centrality-in-r-new-ways-of-measuring-centrality_files/figure-html/examplenets-1.png?w=450" data-recalc-dims="1"></p>
<p>Following the recipe, you have decided, that the <em>relations of interest</em> for your analysis<br>
are the distances between nodes. The problem is, aggregating them into an index can still<br>
be done in various ways. Three distance based centrality examples are shown below.</p>
<pre><code>#classic closeness
c_C &lt;- g1 %>% 
  indirect_relations(type=&quot;dist_sp&quot;) %>% 
  aggregate_positions(type=&quot;invsum&quot;)

#harmonic closeness
c_HC &lt;- g1 %>% 
  indirect_relations(type=&quot;dist_sp&quot;,FUN=dist_inv) %>% 
  aggregate_positions(type=&quot;sum&quot;)

#residual-type closeness
c_RC &lt;- g1 %>% 
  indirect_relations(type=&quot;dist_sp&quot;,FUN=dist_2pow) %>% 
  aggregate_positions(type=&quot;sum&quot;)</code></pre>
<p>Any of the above indices starts with the derivation of distances, but then proceeds with<br>
a different form of aggregation:<br>
<span>\[<br>
c_C(i)=\frac{1}{\sum dist(i,j)},\quad c_{HC}(i)=\sum\frac{1}{dist(i,j)}, \quad c_{RC}(i)=\sum 2^{-dist(i,j)}<br>
\]</span><br>
Possibilities are virtually endless for aggregating distances into an index.<br>
From the previous part, we know that any of these indices preserve neighborhood-inclusion.<br>
Once we have settled for a relation, as in this case, we can extend the partial ranking<br>
using the following considerations: If a <span>\(dist(i,k)\)</span> is larger than <span>\(dist(j,k)\)</span> for all<br>
nodes <span>\(k\)</span>, then no matter how we aggregate the relations (as long as it is monotonic),<br>
<span>\(i\)</span> will always be less central then <span>\(j\)</span>. With a bit more formalism:<br>
<span>\[<br>
dist(i,k) \geq dist(j,k) \text{ for all } k \implies c_x(i)\leq c_x(j)<br>
\]</span><br>
where <span>\(c_x\)</span> is an arbitrary centrality index based on distances. This actually defines<br>
a new dominance relation among nodes. In fact, we can go a step further. It does<br>
not really matter in which order we aggregate the distances, the result will always be the same.<br>
Hence, we can permute all relations of a single node without affecting the result.<br>
A convenient choice of permutation is simply to reorder all relations in descending<br>
order. Afterwards, we can compute the dominance relations as above. (More formal details on these dominance relations can be found in <a rel="nofollow" href="https://journals.sagepub.com/doi/abs/10.1177/2059799116630650" target="_blank">this article</a>.)</p>
<p>We can compute this new dominance relation using the function <code>positional_dominance()</code>.<br>
The <code>benefit</code> parameter is set to <code>FALSE</code> since large distances are not beneficial for<br>
a node to have. Setting <code>map=TRUE</code> invokes the above mentioned reordering. For comparison,<br>
we also compute neighborhood-inclusion again.</p>
<pre><code>P &lt;- neighborhood_inclusion(g1)
D &lt;- g1 %>% 
  indirect_relations(type=&quot;dist_sp&quot;) %>% 
  positional_dominance(benefit=FALSE,map=TRUE)

c(&quot;neighborhood-inclusion&quot;=comparable_pairs(P),&quot;distance dominance&quot;=comparable_pairs(D))</code></pre>
<pre><code>## neighborhood-inclusion     distance dominance 
##              0.1636364              0.8727273</code></pre>
<p>By fixing our relation of interest to distances and allowing reordering of relations, we<br>
went from only 16% of comparable pairs to 87%! Hence, no matter what index based on distance we use,<br>
results will always be very similar. As a sanity check, we can verify that all distance based indices from above preserve the dominance relations.</p>
<pre><code>c(&quot;classic&quot;=is_preserved(D,c_C),&quot;harmonic&quot;=is_preserved(D,c_HC),&quot;residual&quot;=is_preserved(D,c_RC))</code></pre>
<pre><code>##  classic harmonic residual 
##     TRUE     TRUE     TRUE</code></pre>
</div>
<div>
<h1>Partial Centrality</h1>
<p>By now, we should have understood that there are various kinds of partial rankings in networks,<br>
which form the basis of centrality. Indices extend these partial rankings into <strong>one</strong> possible ranking,<br>
but, as we will see later, there might be hundreds of thousands of possible rankings. And hence, hundreds of<br>
thousands of indices that produce these rankings. Instead of inventing hundreds of thousands of<br>
indices, why not just study the partial rankings? Or why not be extremely bold, and try to<br>
analyse <strong>all</strong> possible rankings at once?</p>
<p>In this section, we consider the former question, by introducing <em>rank intervals</em>. A rank interval<br>
of a node is the set of ranks a node can have in any ranking that extends a given partial ranking.<br>
Let us consider two extreme cases. A node that is neither dominated nor dominates any other node can potentially<br>
have any rank. So its rank interval is <span>\([1,n]\)</span>. (We use the convention, that <span>\(n\)</span> is the top rank and <span>\(1\)</span> the lowest possible rank).<br>
On the other hand, if a node dominates all other nodes, it can only be ranked on the top. So its rank interval is just a point.</p>
<p><code>netrankr</code> includes the function <code>rank_intervals()</code> which returns the rank intervals for all nodes in the network.<br>
A visual representation of the intervals can be obtained with the <code>plot_rank_intervals()</code> function, as done below for the<br>
first example network and neighborhood-inclusion as partial ranking input. We also included an optional <code>data.frame</code><br>
containing centrality scores of five indices.</p>
<pre><code>cent_scores &lt;- data.frame(
   degree=degree(g1),
   betweenness=betweenness(g1),
   closeness=closeness(g1),
   eigen=eigen_centrality(g1)$vector,
   subgraph=subgraph.centrality(g1))

plot_rank_intervals(P,cent.df = cent_scores,ties.method = &quot;average&quot;)</code></pre>
<p><img src="https://i0.wp.com/blog.schochastics.net/post/2018-12-12-network-centrality-in-r-new-ways-of-measuring-centrality_files/figure-html/rank_intervals_all-1.png?w=450" data-recalc-dims="1"><br>
The rank intervals are extremely big for this network. Node 10, for instance can take any possible rank.<br>
The most constraint interval is that of node 1, containing 6 possible ranks. The rank intervals can be interpreted as<br>
a sort of confidence interval for centrality. The larger the interval, the less explanatory power<br>
a single index may have Again, consider Node 10. It is the most central node according to subgraph centrality, but ranks very low in<br>
betweenness.</p>
<p>We have learned that we can extend neighborhood-inclusion by choosing a relation of interest as<br>
basis for our analysis. For the example network, we considered distances.<br>
The below figure shows the resulting rank intervals.</p>
<pre><code>cent_scores &lt;- data.frame(
   classic=c_C,
   harmonic=c_HC,
   residual=c_RC)

plot_rank_intervals(D,cent.df = cent_scores)</code></pre>
<p><img src="https://i0.wp.com/blog.schochastics.net/post/2018-12-12-network-centrality-in-r-new-ways-of-measuring-centrality_files/figure-html/rank_intervals_dist-1.png?w=450" data-recalc-dims="1"><br>
Notice how much smaller they got. The intervals of node 1 and 2 even collapse into a single point.<br>
They will thus always be ranked at the bottom in any distance based centrality ranking.</p>
<p>Rank intervals are a convenient choice to assess the possibilities of rankings in a network.<br>
It is important to understand, though, that the ranks in each interval do not occur with<br>
uniform probability. A rank interval <span>\([6,7]\)</span> does not mean that the node is ranked 6th in 50%<br>
of all possible rankings. We address the <em>rank probabilities</em> in the next section.</p>
</div>
<div>
<h1>Probabilistic Centrality</h1>
<p>A node ranking can be defined as a mapping<br>
<span>\[rk: V \to \{1,\ldots,n\},\]</span><br>
where we use the convention that <span>\(u\)</span> is the top ranked node if <span>\(rk(u)=n\)</span> and the<br>
bottom ranked one if <span>\(rk(u)=1\)</span>. The set of all possible rankings can then be characterized as<br>
<span>\[<br>
\mathcal{R}(\leq)=\{rk:V \to \{1,\ldots,n\}\; : \; u\leq v \implies rk(u)\leq rk(v)\}.<br>
\]</span><br>
This set contains all rankings that could be obtained for centrality indices that preserve the<br>
partial ranking of a dominance relation “<span>\(\leq\)</span>”.</p>
<p>Once <span>\(\mathcal{R}(\leq)\)</span> is calculated, it can be used for a probabilistic assessment of centrality,<br>
analyzing all possible rankings at once. Examples include <em>relative rank probabilities</em><br>
(How likely is it, that a node <span>\(u\)</span> is more central than another node <span>\(v\)</span>?) or<br>
<em>expected ranks</em> (How central do we expect a node <span>\(u\)</span> to be).</p>
<p><code>netrankr</code> includes the function <code>exact_rank_prob()</code>, which helps to answer the above posted questions.<br>
We stick with our small example network and apply the function to both, neighborhood-inclusion<br>
and dominance based on distances.</p>
<pre><code>probNI &lt;- exact_rank_prob(P) 
probD  &lt;- exact_rank_prob(D)</code></pre>
<p>The function returns a large list of different outputs, which we discuss in the following.<br>
The number of possible rankings is stored in <code>lin.ext</code>.</p>
<pre><code>c(&quot;neighborhood-inclusion&quot;=probNI$lin.ext,&quot;distances&quot;=probD$lin.ext)</code></pre>
<pre><code>## neighborhood-inclusion              distances 
##                 739200                     20</code></pre>
<p>So, for this tiny network, there are still more than 700,000 possibilities to rank the nodes differently.<br>
If we restrict ourselves to distances, we end up with only 20.</p>
<p>The rank probabilities (for example how likely is it that node <span>\(u\)</span> is ranked on top?)<br>
are stored in the matrix <code>rank.prob</code>. We here focus on the probability to be the most central node.</p>
<pre><code>top_rank &lt;- ncol(probNI$rank.prob)
probNI$rank.prob[,11]</code></pre>
<pre><code>##         V1         V2         V3         V4         V5         V6 
## 0.00000000 0.00000000 0.00000000 0.13636364 0.16363636 0.10909091 
##         V7         V8         V9        V10        V11 
## 0.10909091 0.13636364 0.09090909 0.09090909 0.16363636</code></pre>
<p>Node 5 and 11 have the highest probability to be the most central node. You can think of the<br>
probabilities as follows: If we would apply thousands of indices to the network, in 16% of the cases<br>
will node 5 be the most central node.</p>
<p>Relative rank probabilities (How likely is it that <span>\(u\)</span> is less central than <span>\(v\)</span>?) are stored in the matrix <code>relative.rank</code>.</p>
<pre><code>round(probNI$relative.rank,2)</code></pre>
<pre><code>##       V1   V2   V3   V4   V5   V6   V7   V8   V9  V10  V11
## V1  0.00 0.67 1.00 0.95 1.00 1.00 1.00 0.95 0.86 0.86 1.00
## V2  0.33 0.00 0.67 1.00 0.92 0.83 0.83 1.00 0.75 0.75 0.92
## V3  0.00 0.33 0.00 0.80 1.00 0.75 0.75 0.80 0.64 0.64 1.00
## V4  0.05 0.00 0.20 0.00 0.56 0.44 0.44 0.50 0.38 0.38 0.56
## V5  0.00 0.08 0.00 0.44 0.00 0.38 0.38 0.44 0.32 0.32 0.50
## V6  0.00 0.17 0.25 0.56 0.62 0.00 0.50 0.56 0.43 0.43 0.62
## V7  0.00 0.17 0.25 0.56 0.62 0.50 0.00 0.56 0.43 0.43 0.62
## V8  0.05 0.00 0.20 0.50 0.56 0.44 0.44 0.00 0.38 0.38 0.56
## V9  0.14 0.25 0.36 0.62 0.68 0.57 0.57 0.62 0.00 0.50 0.68
## V10 0.14 0.25 0.36 0.62 0.68 0.57 0.57 0.62 0.50 0.00 0.68
## V11 0.00 0.08 0.00 0.44 0.50 0.37 0.37 0.44 0.32 0.32 0.00</code></pre>
<p>For example, the probability that node 2 is less central than node 1 is <span>\(0.33\)</span>.<br>
The closer a probability to <span>\(0.5\)</span> (see node 11 and 5), the less reason exists to put either node on top of the other.</p>
<p>The last return values of interest are the expected ranks and the standard deviation in <code>expected.rank</code> and <code>rank.spread</code>.<br>
The expected ranks can be seen as a sort of baseline ranking. Applying hundreds of random indices, this is the ranking we could expect to get on average.</p>
<pre><code>exp_rk &lt;- round(probNI$expected.rank,2)
sd_rk &lt;- round(probNI$rank.spread,2)
tibble(nodes=1:11,expected=exp_rk,sd=sd_rk) %>% 
  ggplot(aes(x=reorder(nodes,expected)))+
  geom_segment(aes(y=expected-sd,yend=expected+sd,xend=reorder(nodes,expected)))+
  geom_point(aes(y=expected))+
  theme_minimal()+
  labs(y=&quot;Rank&quot;,x=&quot;Node&quot;)</code></pre>
<p><img src="https://i0.wp.com/blog.schochastics.net/post/2018-12-12-network-centrality-in-r-new-ways-of-measuring-centrality_files/figure-html/exprksNI-1.png?w=450" data-recalc-dims="1"><br>
The standard deviations are quite large for neighborhood-inclusion, which was to be expected from the big rank<br>
intervals. The below figure shows the expected ranks for the distance based dominance.</p>
<pre><code>exp_rk &lt;- round(probD$expected.rank,2)
sd_rk &lt;- round(probD$rank.spread,2)
tibble(nodes=1:11,expected=exp_rk,sd=sd_rk) %>% 
  ggplot(aes(x=reorder(nodes,expected)))+
  geom_segment(aes(y=expected-sd,yend=expected+sd,xend=reorder(nodes,expected)))+
  geom_point(aes(y=expected))+
  theme_minimal()+
  labs(y=&quot;Rank&quot;,x=&quot;Node&quot;)</code></pre>
<p><img src="https://i2.wp.com/blog.schochastics.net/post/2018-12-12-network-centrality-in-r-new-ways-of-measuring-centrality_files/figure-html/exprksD-1.png?w=450" data-recalc-dims="1"></p>
<p>As a word of warning: The problem of finding all possible rankings for a partial ranking is<br>
computationally a hard problem. So it is advisable to use <code>exact_rank_prob()</code> only for small<br>
networks. Some benchmark results and approximation methods for larger networks can be found <a rel="nofollow" href="https://schochastics.github.io/netrankr/articles/benchmarks.html" target="_blank">here</a>.</p>
</div>
<div>
<h1>Summary</h1>
<p>After this post, it is time to take stock of what we have done so far.<br>
To date, putting it bluntly, network centrality is nothing more than the application of indices<br>
to a network:</p>
<p><img src="https://i2.wp.com/blog.schochastics.net/img/diagram_old.png?w=456" data-recalc-dims="1"><br>
The only degree of freedom is the choice of index and it is hard to justify choices<br>
without resorting to data-driven reasoning, as in “We used betweenness because it worked best”.</p>
<p>The introduced neighborhood-inclusion and more specific<br>
dominance concepts allow for additional ways of analyzing centrality in networks,<br>
described in this superficial diagram.</p>
<p><img src="https://i1.wp.com/blog.schochastics.net/img/diagram_new.png?w=456" data-recalc-dims="1"></p>
<p>Any centrality analysis starts with identifying the <em>relation of interest</em>, which<br>
replaces the choice of index. The relation of interest is usually some graph-theoretic<br>
property (e.g. distances) that we assume to be indicative for centrality. The relations<br>
of a node to all others is called its <em>position</em>. The aggregation of the relations leads<br>
to the definition of indices, hence the usual centrality concept. However, positions can also<br>
be compared via <em>positional dominance</em>, the dominance relation introduced in this post, leading to partial centrality rankings and<br>
the option to calculate probabilistic centrality rankings.</p>
<p>So far, we have mostly been toying around with small contrived networks. The final post<br>
will illustrate the introduced methodology by means of a more realistic application example.</p>
</div>
	<p>
<div>
<div>To <strong>leave a comment</strong> for the author, please follow the link and comment on their blog: <strong><a href="http://blog.schochastics.net/post/network-centrality-in-r-new-ways-of-measuring-centrality/"> schochastics</a></strong>.</div>
<hr>
<a rel="nofollow" href="https://www.r-bloggers.com/">R-bloggers.com</a> offers <strong><a rel="nofollow" href="https://feedburner.google.com/fb/a/mailverify?uri=RBloggers">daily e-mail updates</a></strong> about <a rel="nofollow" href="https://www.r-project.org/" title="The R Project for Statistical Computing">R</a> news and <a rel="nofollow" href="https://www.r-bloggers.com/search/tutorial" title="R tutorials">tutorials</a> on topics such as: <a rel="nofollow" href="https://www.r-bloggers.com/search/data%20science" title="Data science">Data science</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/Big%20Data" title="Big Data">Big Data, <a rel="nofollow" href="https://www.r-users.com/" title="R jobs">R jobs</a>, visualization (<a rel="nofollow" href="https://www.r-bloggers.com/search/ggplot2" title="ggplot and ggplot2 tutorials">ggplot2</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/boxplot" title="Boxplots using lattice and ggplot2 tutorials">Boxplots</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/map" title="Maps and gis">maps</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/animation" title="Animation in R">animation</a>), programming (<a rel="nofollow" href="https://www.r-bloggers.com/search/RStudio" title="RStudio IDE for R">RStudio</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/sweave" title="Sweave and literate programming">Sweave</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/LaTeX" title="LaTeX in R">LaTeX</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/SQL" title="SQL and databases">SQL</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/eclipse" title="Eclipse IDE for R">Eclipse</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/git" title="git and github, Version Control System">git</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/hadoop" title="Large data in R using Hadoop">hadoop</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/Web+Scraping" title="Web Scraping of google, facebook, yahoo, twitter and more using R">Web Scraping</a>) statistics (<a rel="nofollow" href="https://www.r-bloggers.com/search/regression" title="Regressions and ANOVA analysis tutorials">regression</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/PCA" title="principal component analysis tutorial">PCA</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/time+series" title="Time series">time series</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/trading" title="finance trading">trading</a>) and more...
<img width="1" alt="" src="http://feeds.feedburner.com/~r/RBloggers/~4/wXXfZfExy9U" height="1"></a></div>