A Data Dictionary for a Small Social Network Survey: Variables, Name Generators, and Tie Measures

Why a network survey needs a data dictionary

A conventional questionnaire often treats each respondent as an independent observation. A social network survey also asks about relationships between people. Its answers may produce two connected datasets: a node table describing participants and an edge table describing reported relationships. Without consistent variable definitions, the same answer can be interpreted differently during cleaning, graph construction, and analysis.

A data dictionary is the document that prevents this ambiguity. For every field, it specifies a variable name, definition, data type, allowed values, and coding instructions. It can also identify whether a field belongs in the node table, edge table, or survey administration record.

For example, a question asking respondents whom they approach for academic advice produces reported relationships. The resulting edge means that one respondent nominated another person for a particular purpose. It does not automatically establish friendship, emotional closeness, or the nominated person's awareness of the relationship.

Name generators define the network boundary

A name generator is a survey question designed to elicit the names or identifiers of people connected to a respondent through a specified relationship or activity. The wording determines which ties become visible in the dataset. Asking whom someone consults for academic advice produces a different network from asking whom they socialize with outside work.

A focused question might read: Think about the past 30 days. Which people in your department have you asked for help understanding an academic or work-related problem? This wording establishes a population, a relationship purpose, and a recall period. The researcher must also define whether respondents may nominate people outside the department.

Open name generators allow respondents to nominate people without selecting from a predefined list. They can capture relationships that a researcher did not anticipate, although spelling variations and duplicate identities require careful reconciliation. Roster-based questions instead present a defined list of eligible people and ask respondents to identify relevant relationships. They simplify identity matching but restrict the network to the roster.

The number of nominations also matters. A survey allowing three nominations produces a different observed network from one allowing unlimited nominations. A cap can reduce respondent burden, but it truncates the recorded network and may disproportionately omit less salient relationships. The questionnaire and resulting dataset should record the cap explicitly.

• Define the population from which names may be selected.
• Specify the relationship being measured.
• Use a clear recall period.
• State whether nominations are open or roster-based.
• Document any nomination limit.

Separate nodes, respondents, and reported ties

The respondent is the person completing the questionnaire. A node is an entity represented in the network. These categories may overlap, but they are not identical. A respondent can nominate someone who does not complete the survey, creating a node with an outgoing reported relationship but no corresponding respondent record.

A node table should contain one row per identified network participant. A basic example includes node_id, respondent_status, and group. The node_id must be unique and stable. Names or email addresses should not be used as graph identifiers in a working analysis dataset when a coded identifier will serve the same purpose.

An edge table should contain one row per reported relationship. Its essential fields are source_id, target_id, and relation_type. If A nominates B as someone they consult for advice, A is the source, B is the target, and the relationship type is advice. This represents a directed nomination. It does not establish that B would nominate A in return.

The same two participants can have more than one relationship type. A may ask B for advice and also socialize with B. These should be separate edge records or separate clearly defined relationship fields. Combining them into a single generic connection would remove information that may be important for the research question.

A practical data dictionary template

The following template is suitable for a fictional small network survey. It separates participant characteristics from reported relationships and includes fields that help preserve the meaning of each answer. Variable names use lowercase words separated by underscores, a convention that is easy to maintain across CSV files and common analysis environments.

For a simple survey, the node table can include node_id, respondent_status, and group_code. The edge table can include source_id, target_id, relation_type, frequency, and closeness. The survey administration table can include response_id, completion_status, and survey_date. Each field should have a defined type and an explicit missing-value rule.

A frequency variable might use an ordered scale from 1 to 4, where 1 means less than monthly, 2 means monthly, 3 means weekly, and 4 means daily or almost daily. Closeness might use a separate scale from 1 to 5. These are illustrative coding choices, not universal standards. The exact categories should follow the research question and be stated in the questionnaire.

A dictionary should also distinguish a genuine zero from a missing response. A respondent who reports no advice ties has supplied a meaningful zero. A respondent who skips the question has supplied missing data. Treating these as the same value can distort degree calculations and other network statistics.

• node_id: unique coded identifier; text; required.
• respondent_status: whether the node completed the survey; categorical; yes or no.
• group_code: participant's defined study group; categorical; use the survey's group catalog.
• source_id: identifier of the person reporting the relationship; text; required for an edge.
• target_id: identifier of the nominated person; text; required for an edge.
• relation_type: purpose of the reported tie; categorical; use documented survey categories.

From questionnaire answers to an edge list

Consider a fictional department with four participants: P01, P02, P03, and P04. The survey asks whom each participant approaches for academic advice during the past 30 days. P01 nominates P02 and P03, P02 nominates P03, and P04 nominates P01. These answers create four directed edges.

The edge list contains P01 to P02, P01 to P03, P02 to P03, and P04 to P01. P03 receives two nominations, while P01 has two outgoing nominations. These are different measures of position: incoming nominations and outgoing nominations. The graph preserves both without assuming that relationships are reciprocal.

If P03 does not complete the survey, P03 should still appear in the node table if the study's network boundary permits nominated nonrespondents. The respondent_status field can identify this distinction. Removing P03 because of nonresponse would discard relationships that other participants explicitly reported.

AI coding assistants can help convert a documented dictionary and fictional CSV files into a graph-building script. They can suggest data validation rules, identify duplicated identifiers, and generate a visualization. The researcher remains responsible for confirming that the code preserves direction, missingness, nomination limits, and the survey's actual definitions.

Survey quality, missing ties, and interpretation

A network survey captures relationships within a defined measurement design. It does not automatically capture every relationship respondents have. Recall periods, question wording, social desirability, nomination limits, and nonresponse all influence the resulting graph. These constraints should be recorded as methodological information alongside the data dictionary.

A useful quality-control step is to compare the questionnaire with the dictionary before collecting responses. Every question that produces a network variable should have a corresponding definition, and every coded category should appear in the questionnaire or its documented processing rules. Check that source and target identifiers use the same format and that relationship direction is consistent throughout the dataset.

Privacy also matters because network data can reveal relationships involving people who never completed the questionnaire. Use coded identifiers in analysis files, restrict access to identifying information, and follow the applicable institutional research and data-protection requirements. A small group can be identifiable even when names have been replaced by codes.

The next step is to draft one name generator, define the eligible population, and build a dictionary with at least three node variables and three edge variables. Populate it with four fictional participants and convert the example answers into a directed CSV edge list.

Questions readers ask