[statnet_help] Help seeking on calculating betweenness centrality with valued ties

Carter T. Butts buttsc at uci.edu
Sat Jun 6 20:55:50 PDT 2020


Hi, Chuding -

I am not sure here to what type of object you are referring - what the
software computes will depend upon what you asked it to do.  If you e.g.
create an adjacency matrix full of zeros, then all functions are going
to treat that as a null graph.  If you create a network object in which
all possible edges are present but then give each edge a numeric
attribute whose value is zero, then (1) functions told to act only on
the raw network structure will treat it as a complete graph, but (2)
extracting the edge values to an adjacency or edgelist matrix will then
lead to the behavior described above.  If one only has one set of edge
values, one usually does not create edges for the zero-valued dyads (in
which case this effect will not occur).  However, one certainly can
create an object like that if one likes (and there are some special
cases in which one may want to do so).

Hope that helps,

-Carter

On 6/6/20 8:27 PM, CHU-DING LING wrote:

>

> Another problem is that even though I transform those valued ties into

> binary ties, the package would still treat everyone in the network is

> connected with the others, as long as I have 12 edges in the 4-vertex

> graph. I tried to remove the cases with a value of edge as 0 in the

> graph and calculated the indegree of each vertex, the results are

> consistent with the reality in the network. So, it seems that the

> package would always treat the column regarding the value of the edges

> as a weight no matter it is a binary or continuous variable. Am I right?

>

> Best,

>

> Chuding

>

>

>

> CHU-DING LING <lingchuding at gmail.com <mailto:lingchuding at gmail.com>>

> 于2020年6月7日周日 上午9:44写道:

>

> Dear Carter,

>

> Thanks for your prompt reply. Actually, I have noticed the

> tutorial on valued ties. However, I did not follow many steps of

> it. And I failed to reproduce the results by just copying and

> running the codes in the examples. There are some errors. That is

> why I have to post this question in the list.

>

> After reading your suggestions, I have attempted to convert the

> network object into a matrix:

>

> Mynet.matrix = as.matrix(Mynet)

>

> class (Mynet.matrix)

>

> [1] "matrix" "array"

>

> And I ran the code to calculate the betweenness centrality again:

>

> betweenness (as.edgelist.sna (Mynet.matrix[[1]],"Friend"),

> ignore.eval=FALSE)

>

> Error in as.edgelist.sna (Mynet.matrix[[1]], "Friend"):

>

> as.edgelist.sna input must be an adjacency matrix/array, edgelist

> matrix, network, or sparse matrix, or list thereof.

>

> According to the results from the “class (Mynet.matrix)” command,

> I think the “Mynet.matrix” object is a matrix now. *Why does the

> “as.edgelist.sna ()” cannot work it out?*

>

> Also, I have explored the class of the “emon” object in your

> example and results showed it is a list.

>

> class(emon)

>

> [1] "list"

>

> *Does this difference lead the “as.edgelist.sna ()” command to

> reporting the errors?*

>

> I am sorry to bother you again. I am a novice of R and “statnet”,

> so I am wondering whether you can give me more detailed

> illustration based on my example dataset. Many thanks in advance!

>

> Best,

>

> Chuding

>

>

>

> Carter T. Butts <buttsc at uci.edu <mailto:buttsc at uci.edu>>

> 于2020年6月7日周日 上午5:54写道:

>

> 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 <mailto:statnet_help at u.washington.edu>

>> http://mailman13.u.washington.edu/mailman/listinfo/statnet_help

> _______________________________________________

> statnet_help mailing list

> statnet_help at u.washington.edu

> <mailto:statnet_help at u.washington.edu>

> http://mailman13.u.washington.edu/mailman/listinfo/statnet_help

>

>

> _______________________________________________

> 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/089a42f0/attachment.html>


More information about the statnet_help mailing list