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

CHU-DING LING lingchuding at gmail.com
Sat Jun 6 20:27:16 PDT 2020


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> 于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> 于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 liststatnet_help at u.washington.eduhttp://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/20200607/80c2b4bf/attachment.html>


More information about the statnet_help mailing list