Hello,
Thank you
Hi Mada,
Thanks for reaching out!
Best,
Caden
Hi mada,
Chiming in re: #2 here. As far as I know, Network Canvas generally assumes that the user is only analyzing each ego network in isolation rather than connecting them into a broader global network. However, as you’ve probably intuited, a well-designed Network Canvas protocol that uses a roster can theoretically generate all the data needed to construct said global network. I have a bit of experience trying to build the kind of network you’re looking for, so I’ll try to help out on this end:
The main task involved in getting your Network Canvas dataset to generate a global network is combining the ego-alter lists of all participants into a single edgelist representing all ties in the network. If you’ve collected alter-alter ties as reported by participants, you’ll want to omit those (at least initially), as they can indicate ties between nodes that the nodes themselves haven’t reported. This creates questions regarding the perception vs. reality of ties that aren’t optimal when you’re getting started.
In theory, once you have this edgelist for the global network, you can pass it through igraph, statnet, or any other preferred R package for network analysis to start analyzing the global network. In practice, however, this might not correctly generate the global network. You need to ensure that values in one ego identifier column match values in its corresponding alter identifier column. In my initial attempt at making this work, this entails ensuring that the name each participant enters at the beginning of the survey matches how it appears your roster CSV file. We made sure this was possible in the test data we created, but it might not be a reliable approach in the field.
Off the top of my head, there’s a more reliable way to ensure this matching. At the beginning of your survey, I would add a roster interface in which participants are asked to find themselves in the roster. Here they are only allowed to select a single entity from the roster, and the “tie” created by this selection can be designated as being of a different “type” than subsequent roster selections. You’d need to reshape your ego-alter list data a bit after you export it from Network Canvas, but once that’s done you’d be good to go.
If you’re already collecting final data and can’t revise your protocol, you’re left with the challenge of manually linking self-reported ego names to how the appear in your roster. This doesn’t preclude the task of creating a global network edgelist, but it does make creating said edgelist more tedious.
Let me know if there’s anything in the above I can better clarify, and feel free to message me directly for more support!
Hello Caden,
Thank you for the response.
Hello tomwolff,
Thank you for the elaborate response. I am about to start data collection and I had not thought of a person identifying themselves in the roster at the start of the interview. At the moment, everything is clear. If I have further questions later on, I will reach out
Hello Tom,
I made an attempt of the analysis following your response using some pilot data. I have been able to produce a map but it’s not coming out as intended and I think the issue is to with the identifiers.
In my protocol, there is one generic name generator created using the roster interface. Participants can only nominate those in the roster. When I export the data, I have the ego csv and the attribute csv (the edge csv is empty- my initial thought was that a nomination leads to an edge creation). Now going back to the analysis, I am using the attribute csv.
During the mapping process, the columns being used are the node ID (as alters) and networkCanvasEgoUUID (as egos). The problem is that the node IDs include the egos as well (e.g node 1 is the ego but they are being mapped to themselves using the egoUUID). Additionally, the node IDs are just incremental and not unique to the participant (e.g participant on node 5 and 11 are the same just they are an ego in one case and an alter in another). Using the networkCanvasUUID poses similar problems. How exactly should I manipulate the data so that I am able to pair a unique ego to an alter without self-loops and a person who is nominated multiple times can be tracked throughout the data.
Regards
On the edge CSV file being empty, I believe it’s because that file is meant to record edges between nominated alters in an ego’s network. Since you’re not asking participants if their ties are connected to each other, this file is going to remain empty unless you do so.
Otherwise, the issue you’re currently facing is precisely the issue I would anticipate. To properly construct the global network, you can’t rely on networkCanvasEgoUUID and networkCanvasUUID because their values are generated with the assumption that each ego network exists independent of one another. The safer route is to rely on some kind of name column as it appears in the roster to create a linkage. I assume your roster has a name column that contains the names displayed to participants in Network Canvas. Does that column appear in your attributes CSV file? That’s the first thing you’ll want to confirm.
The second thing you’ll need to do, as I described previously, is to have a question where you ask participants to identify themselves in the roster. If you specify “ties” generated by this question as being of a different “type” than the ones that appear above, the self-identification ties should end up stored in a set of separate CSV files. Merge these files together and you have a key for linking networkCanvasEgoUUID values to names in the roster (assuming roster names appear in your CSV files).
Let me know if I need to clarify anything in the above, and feel free to message me directly if you need a bit more guidance!
Thank you,
I do have a name variable and with this I have managed to resolve the issues I had raised. I will reach out if I have more questions
Thank you very much.
Madalo
