[statnet_help] Help seeking on calculating betweenness
centrality with valued ties
Carter T. Butts
buttsc at uci.edu
Sat Jun 6 14:52:55 PDT 2020
Hi, Chuding -
You may find the valued network tutorial to be helpful here:
http://statnet.org/Workshops/valued.html
If you are interested in calculating betweenness per se, however, it is
probably most straightforward to either store your data in either a
valued adjacency matrix, or an sna edgelist (see ?as.edgelist.sna).
When you pass the data object to the betweenness function, you will also
need to tell it to use the edge values, since it otherwise will assume
that you want to calculate betweenness on the underlying unvalued
digraph (see ?betweenness).
Note that directly passing a network object that happens to contain edge
values to betweenness et al. will not result in those values being used;
the reason is that a network object can contain any number of different
sets of edge variables (which need not even be "values" as such - you
can have a dozen network objects attached to each edge, if you like),
and the NLI functions have no way of knowing which if any values you
want it to use. Thus, the way to do it is to pass an object with the
values extracted (e.g., a valued sociomatrix or sna edgelist, as noted
above). If you have encoded your edge values into a network object,
this can easily be done with code like so:
library(sna)
data(emon)
betweenness(as.edgelist.sna(emon[[1]],"Frequency"), ignore.eval=FALSE)
In this case, "Frequency" is a numeric variable associated with the
edges in emon[[1]]. If we left ignore.eval at its default value of
TRUE, we would obtain the corresponding scores for the underlying
(unvalued) network. Likewise, if we just called betweenness(emon[[1]])
- with or without ignore.eval=FALSE - the betweenness function would
have no idea that we wanted the "Frequency" variable, and would hence
operate on the raw graph structure. This same approach is used by most
of the functional indices in statnet, but you should always check the
individual help pages for details; some indices are not defined for
valued data, and others may have additional options that are important
to consider.
In line with that last note - and mostly for the benefit of others who
may encounter the thread - I would also observe that generalizing node
or graph-level indices to the valued case is not always trivial, and in
some cases the "valued" version of an index may only make sense when the
edge values are interpreted in a particular way. For instance, indices
based on geodesics (including betweenness) implicitly treat edge values
as distances, with the additional implicit assumption that a length of
an i,j path is the sum of the values of the edges contained within it.
If one's data were to consist e.g. of subjective ratings of positive
feeling (e.g., how much does ego "like" alter on some scale or other),
then using these values in this way would make little sense; statnet
would dutifully compute the indices for you in such a situation if you
asked it to, but they would have no obvious substantive interpretation.
In some cases, it may be possible to transform one's original
observations into a form that is more appropriate for such an analysis
(e.g., transforming similarity scores to distance scores), but in other
cases there may be a mismatch between the data properties tacitly
assumed by the indices (at least, in their conventional interpretation*)
and what was actually measured. In such cases, it may be wise to
consider a different index that is more appropriate to one's problem.
Finally, it can also be important to ensure that valued data is coded in
the way that one intends. For instance, the Drabek et al. EMON data
used above codes interaction frequency from 1 to 4, with 1 being the
highest level of frequency ("continuous") and four being the lowest
non-zero value ("about once a day or less"). For betweenness or
closeness (where we are treating the edges as if they are distances),
that at least makes ordinal sense, but calculating valued degree without
recoding would give us rather perverse results. (Whether it is
reasonable to treat path lengths as additive with respect to such a
measure is an interesting question that I will not answer, but instead
allow to hang in the proverbial air for silent contemplation.) So
anyway, be sure to verify that your index is using your edge values in a
way that both makes substantive sense and that is compatible with how
they are coded.
Hope that helps,
-Carter
* Technically speaking, an index doesn't "assume" anything. It is
simply a function of the network. But our conventional
/interpretations/ of what structural indices tell us about social
networks usually involve quite a few assumptions, often tacit. When
working with valued data, it is often necessary to become more explicit
about what one is assuming.
On 6/6/20 7:47 AM, CHU-DING LING wrote:
>
> Dear all,
>
> I am trying to calculate the betweenness centrality with valued ties,
> but I do not figure it out. Here are the dataset and codes.
>
> 1. This is an example dataset with only four nodes/individuals. When
> collecting the network data, I asked the participants to answer the
> question about friendship tie on a 7-point Likert scale. So, this is a
> *directed* and *valued* network. Moreover, when inputting the network
> data, I adopted the edge list format and saved it into a CSV file. The
> details of the data are as follows:
>
> Actor Target Friend
>
> 1001 1002 5
>
> 1001 1003 6
>
> 1001 1004 5
>
> 1002 1001 6
>
> 1002 1003 6
>
> 1002 1004 6
>
> 1003 1001 4
>
> 1003 1002 4
>
> 1003 1004 4
>
> 1004 1001 6
>
> 1004 1002 6
>
> 1004 1003 6
>
> 2. Then I ran the following codes to calculate the betweenness centrality:
>
> library(statnet)
>
> #Step 1. read the edgelist format dataset into R
>
> Mydata <- read.table("Example.csv", header=TRUE, sep=",")
>
> #Step 2. convert an edgelist matrix with valued edges/ties into a network
>
> Mynet <- network (Mydata)
>
> #Step 3. calculate betweenness centrality but fail to account for the
> value/weight of the tie
>
> betweenness (Mynet)
>
> 3. The results came out are as follows:
>
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0
>
> [43] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0
>
> [85] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0
>
> [127] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [169] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [211] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [253] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [295] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [337] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [379] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [421] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [463] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [505] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [547] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [589] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [631] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [673] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [715] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [757] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [799] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [841] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [883] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [925] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0
>
> [967] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> [ reached getOption("max.print") -- omitted 4 entries ]
>
> It seems that the package treated the IDs of actor and target as edges
> when computing. *If I want to keep the numeric IDs for the further
> merging with other variables, what can I do to solve this problem?*
>
> Also, if I replace the numeric IDs with strings and organize the data
> as follows:
>
> Actor Target Friend
>
> A B 5
>
> A C 6
>
> A D 5
>
> B A 6
>
> B C 6
>
> B D 6
>
> C A 4
>
> C B 4
>
> C D 4
>
> D A 6
>
> D B 6
>
> D C 6
>
> Then, I re-ran the Step 2 and Step 3, the results were as follows:
>
> [1] 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 44.0 44.0 44.0
>
> I think the results are also wrong since the expected results should
> be four values. However, there are 15 values with the first 12 looking
> equal.
>
> I have searched archival of the list, but I failed to locate the
> information that can completely solve my problems. So, I am wondering
> whether any colleagues here could share with me any information about
> this. I would be grateful if you can provide me any suggestions or
> references. Many thanks in advance!
>
> Best,
>
> Chuding
>
>
> _______________________________________________
> statnet_help mailing list
> statnet_help at u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/statnet_help
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/statnet_help/attachments/20200606/4b54f027/attachment.html>
More information about the statnet_help
mailing list