Tutorials › Generalized Linear Mixed Models (GLMM) › Visualizing Hierarchies With Membership Graphs

Crossed and Nested Random Effects · Tutorial 522 of 698

Visualizing Hierarchies With Membership Graphs

Use tree diagrams and membership graphs to display and read nested and crossed classifications without losing track of what each record contributes.

Advanced 10 min read

What You'll Learn

  • Draw a tree that shows each nested unit and its unique parent.
  • Represent two crossed factors with a bipartite graph and interpret its edges.
  • Distinguish an unweighted edge from a repeated or multiplicity-weighted membership.
  • Display records classified by three factors using multipartite incidence graphs.
  • Reconcile a graph with a record-level table while noting what a representation omits.

Why Draw Memberships?

A model formula can name several grouping factors, but it may not make the observed pattern of membership easy to inspect. A diagram makes the relationships visible: a tree shows which lower-level units belong to which higher-level units, while a graph shows which levels of different factors occur together in records. These are descriptions of the observed data structure. A diagram by itself does not establish which effects belong in a model or whether a particular model is appropriate.

The basic object to preserve is the record: one observed response and the factor-level memberships associated with it. If record \(r\) belongs to level \(a\) of factor \(A\), that membership must be readable from the representation. When several records share the same combination of factor levels, a representation must also make clear whether it records that repetition or only the fact that the combination occurred.

Definition: A membership representation displays which observed records belong to which levels of one or more factors. A nested tree represents units arranged in parent–child levels, with each child attached to its parent. A bipartite graph has two disjoint sets of nodes and edges only between the sets; for crossed factors, the sets are the factor levels and an edge indicates an observed pairing. A multipartite incidence graph extends this idea to three or more factor types, often by including a node for each record and connecting it to each of its memberships.

These representations have different strengths. A tree emphasizes ancestry or containment. A bipartite graph emphasizes observed pairings between two classifications. A record-node incidence graph emphasizes the memberships of individual observations and can retain repeated records. Choosing a representation is therefore a question of what structure the reader needs to see, not simply what looks most compact.

Nested Units as a Tree

In a nested arrangement, a lower-level unit has one parent at the level immediately above it in the represented hierarchy. For example, a classroom may belong to one school, and a student may belong to one classroom for the period being described. A tree draws the parent–child links directly. If labels such as “Room 1” are reused at different schools, identify a child by its full path in the tree, such as “School S1, Room 1”; otherwise, a reader could mistake two distinct units for one.

To build a useful tree, start with the highest displayed level, add one node for each observed unit at the next level, and connect each child to its parent. Continue downward to the units or records of interest. If the records are observations within the lowest-level units, show them as terminal nodes or list them beside their unit. The tree describes the observed parent assignments; it need not include empty or merely possible units.

Worked Example: Drawing a Nested Hospital Structure

Suppose a hypothetical service audit records five patient responses from two hospitals. Each ward belongs to one hospital, and each patient in this audit is assigned to one ward. The records are:

RecordHospitalWard
r1H1W1
r2H1W1
r3H1W2
r4H2W3
r5H2W3

The ward-to-hospital parent assignments are W1 to H1, W2 to H1, and W3 to H2. The tree is:

$$ \begin{array}{c} \text{Hospitals}\\ \begin{array}{cc} \text{H1} & \text{H2}\\ \downarrow & \downarrow\\ \begin{array}{cc}\text{W1}&\text{W2}\end{array} & \text{W3} \end{array}\\ \begin{array}{ccc} \text{W1: }r1,r2 & \text{W2: }r3 & \text{W3: }r4,r5 \end{array} \end{array} $$

Reading downward, W1 and W2 belong to H1, while W3 belongs to H2. Reading upward from r3, the record belongs to W2 and therefore to H1. The tree has five record memberships distributed across three wards: two records in W1, one in W2, and two in W3. The repeated records under W1 and W3 matter; a diagram that shows only one terminal “patient” per ward would not preserve how many records were observed. The unique-parent condition is satisfied here because every listed ward is assigned to exactly one hospital.

Two Crossed Factors as a Bipartite Graph

For two factors, draw one set of nodes for the levels of factor \(A\) and a disjoint set for the levels of factor \(B\). Draw an edge between \(a\) and \(b\) when at least one observed record has that pair of memberships. No edge means that pair was not observed in the data being represented; it does not by itself say whether the combination was impossible or merely absent from the sample.

A simple, unweighted graph records whether a pair occurred, not how many times. If two records have the same \(A\)-\(B\) pair, they still create just one edge in an ordinary simple graph. To retain the count, label the edge with its multiplicity or use a multigraph with repeated edges. Alternatively, make a separate node for each record and connect it to both of its factor-level nodes. That record-node representation retains every row, including duplicates.

Worked Example: Reading Repeated Pairs in a Crossed Graph

In a hypothetical review exercise, each record is classified by a clinician and a facility. The six records are:

RecordClinicianFacility
r1AX
r2AX
r3AY
r4BX
r5BZ
r6CY

The observed factor-level edges are A–X, A–Y, B–X, B–Z, and C–Y. The multiplicities are 2, 1, 1, 1, and 1, respectively. A multiplicity-labelled bipartite graph can be read as follows:

$$ \begin{array}{c|ccc} & X & Y & Z\\ \hline A & 2 & 1 & 0\\ B & 1 & 0 & 1\\ C & 0 & 1 & 0 \end{array} $$

A positive entry gives the number of records for that pair; zero means that no such pair appears among these six records. For instance, A–X has multiplicity 2 because r1 and r2 share that pair. The simple unweighted graph would show the edge A–X once and would therefore not distinguish these data from data with only one A–X record. The displayed counts sum to \(2+1+1+1+1=6\), matching the six rows in the table.

To preserve individual record identities instead, use a record node for each of r1 through r6. Connect r1 and r2 separately to A and X; connect r3 to A and Y; and proceed similarly for the other records. This graph has six record nodes and twelve membership edges, since each record links to one clinician and one facility. It answers a more detailed question than the simple factor-level graph: not only which pairs occurred, but which records supply each occurrence.

Three or More Factors: Multipartite Incidence Graphs

With three crossed factors, each record has a triple of memberships. A direct extension that retains record identity uses four node sets: one for each of the three factor types and one for the records. Each record node connects to exactly one level node from each factor set. This is a multipartite incidence graph: edges connect record nodes to factor-level nodes, not one factor type directly to another.

Another option is to display each observed triple as a three-way membership tuple, sometimes described as a hyperedge joining three factor levels. A conventional pairwise graph is not generally an adequate substitute for those triples: pairwise links can show that each pair occurred without revealing which three levels occurred together in the same record. Record nodes or explicit tuples preserve that joint information.

Worked Example: Preserving Three-Way Memberships

Suppose five hypothetical records are classified by site, assessor, and protocol:

RecordSiteAssessorProtocol
r1S1AP
r2S1AQ
r3S1BP
r4S2AP
r5S2BQ

In the record-node graph, r1 connects to S1, A, and P; r2 connects to S1, A, and Q; r3 connects to S1, B, and P; r4 connects to S2, A, and P; and r5 connects to S2, B, and Q. Each record has three membership edges, so the graph has \(5\times3=15\) such edges. A reader can follow any record node to recover its complete triple. For example, the neighbors of r4 are S2, A, and P.

If instead the three factor types are summarized only by separate pairwise graphs, those graphs show S1–A, S1–B, A–P, A–Q, B–P, B–Q, S1–P, S1–Q, S2–A, S2–B, and S2–P, S2–Q as applicable to the records above. But the pairwise views do not themselves identify which three-way combinations occur. In particular, S1–B, B–Q, and S1–Q each occur, yet the data do not include the triple (S1, B, Q). The observed S1–B–P and S2–B–Q records are different triples. Keeping record nodes or listing the triples prevents a reader from assembling pairwise links into a three-way combination that was never observed.

Why Record Nodes Preserve the Assignments

The relationship between a record-node graph and a row-based membership representation can be stated exactly. Suppose there are \(n\) records and a factor \(A\) with levels \(a_1,\ldots,a_J\). Define the membership indicator \(z_{rj}\) to be 1 if record \(r\) belongs to level \(a_j\), and 0 otherwise. If each record has exactly one observed level of \(A\), then each row of the membership array contains one 1. A record-node graph has an edge from record \(r\) to \(a_j\) exactly when \(z_{rj}=1\).

$$ z_{rj} = \begin{cases} 1, & \text{if record } r \text{ belongs to level } a_j,\\ 0, & \text{otherwise} \end{cases} \qquad \sum_{j=1}^{J} z_{rj}=1 $$

The equation says that the graph adjacency for record \(r\) identifies the same factor level as the corresponding row of the membership array. Repeating this construction for each factor gives one edge per record per factor, and the record nodes keep separate rows separate even when all their memberships coincide. Thus a graph with a node for every record can represent the same row-to-level assignments as the design representation, provided the factor memberships and record identities are included. In contrast, an unweighted graph with only factor-level nodes merges repeated occurrences of the same pair and cannot recover the number of records from that pair.

This is a representational result, not a claim that every graph and every matrix are interchangeable without qualification. To translate faithfully, specify the factor-level node sets, the record identities or edge multiplicities, and the mapping from each record to its levels. If those pieces are omitted, information is lost.

Checks, Alternatives, and Limits

A diagram is useful only if it reconciles with the underlying records. For each factor, check that every record has the intended membership, and compare the number of represented record nodes or total edge multiplicities with the number of rows. For a nested tree, check that every child has one parent at the level above and that reused labels are distinguished by their parent path. For a crossed bipartite graph, verify that every recorded pair appears as an edge and that absent pairs have not accidentally been drawn.

Common failure modes include the following:

  • Using one edge to stand for an unspecified number of records. An unweighted edge means only that a pair occurred. Add multiplicities or record nodes if counts matter.
  • Reading a missing edge as proof of impossibility. It means the pair was not observed in the represented data. Whether it could occur is a separate substantive question.
  • Turning a three-factor display into pairwise links only. Pairwise links can fail to preserve which three levels were jointly present. Keep record nodes or explicit three-way tuples when joint membership matters.
  • Assuming a diagram chooses the model. A graph summarizes observed memberships; model specification also requires statistical and scientific judgment.

A table is often the best alternative when exact record-level detail is essential or the graph would be too dense to read. A tree is compact for a genuine parent–child hierarchy. A bipartite graph is often clearest for two crossed classifications, especially when only the pattern of observed pairs is the focus. A record-node multipartite graph is more faithful for repeated or multi-factor memberships, but may become visually crowded. An incidence matrix can be more compact for computation or systematic checking, while the graph can make connections easier to see. These are complementary views, and any compressed view should state what it omits.

Key takeaway: Use a tree to display unique parent–child assignments, a bipartite graph to display observed pairs between two factor types, and record nodes or explicit tuples when repeated rows or multi-factor combinations must remain distinguishable. Always state whether multiplicity is retained.

Check Your Understanding

Answer each question, then compare your reasoning with the solutions below.

  1. A nested data set has units U1 and U2 under group G1, and U3 under group G2. What parent does each unit have, and what should a tree show?
  2. In a bipartite graph, four records have pair (A, X), while one record has pair (B, X). How many edges does an unweighted simple graph show, and what must be added to retain the record counts?
  3. Three records have triples (S1, A, P), (S1, B, Q), and (S2, A, Q). Why might three pairwise graphs be insufficient to identify the observed triples?
  4. There are 12 records and each has one membership in each of two factors. How many record-to-factor membership edges are in the record-node graph?

Solutions. (1) U1 and U2 each have parent G1; U3 has parent G2. Draw G1 and G2 above their respective child units, with each child connected to exactly one parent. (2) The simple graph shows two edges, A–X and B–X, regardless of the repeated A–X records. Label A–X with multiplicity 4 and B–X with multiplicity 1, or use separate record nodes and their memberships. (3) Pairwise graphs show which site–assessor, site–protocol, and assessor–protocol pairs occurred, but not which pairs belong together in a single record. Preserve the three record nodes or list the three tuples. (4) Each of the 12 record nodes has two membership edges, one to each factor, so there are \(12\times2=24\) record-to-factor edges.

Clinical Biostats