C5 Method-level enrichment table (Stage 2 of the C3 chat; structure held fixed)
Implementation-Ready Enrichment of the Workflow
Below, each phase of the original workflow (Phases A–H) is enriched with method-level detail extracted from the ten source papers now provided. Tables list the analytical purpose, concrete methodological choices, their source, and any parameter ranges or validation considerations reported by the original authors.
Phase A — Units of Analysis: Windows, Authors, Networks
| Step | Purpose | Method/Approach | Source | Parameters / Validation |
|---|---|---|---|---|
| Define time windows | Choose a temporal segmentation scheme for the 35-year corpus | Segmentation criteria should be semantics-driven (natural periodicity), domain-driven (expert-specified), or data-driven (gaps); doing segmentation as a fixed pre-process rather than at runtime substantially improves scalability | IVESA (Bernard et al.) — Section III-F, Tasks TS/TA | No universal window length is prescribed; IVESA explicitly recommends fixing the segmentation policy in advance once a dominant criterion is identified, rather than exploring it interactively at runtime |
| Choose sequence alignment strategy | Make windows/communities comparable across time | Three alignment strategies: absolute-time alignment (fixed global calendar axis), relative alignment (uniform relative length, e.g., career-stage-based), event-count alignment | IVESA — Section III-F (TA) | Choice should match the analytical question: absolute alignment (calendar years) is appropriate here since publication years are meaningful anchors |
| Build co-authorship network per window | Ensure structural comparability of "the same" author-node across windows | Build a "supergraph" combining all time steps first (averaged edge weights/presence), from which per-window subgraphs are extracted — ensures consistent object/region correspondence across snapshots | MobilityGraphs (von Landesberger et al.) — Section 4.1.1 "Suitability for time-variant data" | Authors note this sacrifices detection of very short-lived local structures but is necessary for cross-window comparability — directly a trade-off relevant to our lineage-tracking design |
Phase B — Per-Window Community Detection (Iterative Calibration)
| Step | Purpose | Method/Approach | Source | Parameters / Validation |
|---|---|---|---|---|
| Detect communities | Partition each window's co-authorship graph | Louvain remains the standard choice; comparable precedent is a density-based / connectivity-constrained clustering extended with domain-specific similarity criteria | MobilityGraphs — Section 4.1.1 (DBScan extension with spatial closeness + flow-strength conditions) | MobilityGraphs' concrete example thresholds: thdist=2.25 km, thconn=3, relative flow filter=0.3 — illustrates the style of dual-thresholded parameterization, not directly transferable values |
| Calibrate resolution parameter | Avoid over-fragmentation / over-coarsening | Compute several quality metrics (e.g., analogous to "total flows within region," "number of clusters," "average inter-cluster distance") across a regularly sampled grid of parameter combinations, and visualize the grid as a heatmap (parameter × parameter) to identify a "balanced" setting | MobilityGraphs — Section 4.2 "Parameter adjustment," Fig. 7 | Explicit validation procedure: sample grid, compute 3 complementary quality criteria, visually pick the setting balancing all three (avoids both too-low and too-high threshold extremes) |
| Interactive top-down / bottom-up refinement of cluster count | Let analyst converge on a meaningful number of communities | Top-down: pick number of clusters directly, system re-partitions (+/- buttons); Bottom-up: browse the hierarchy, select cluster, request "more/less similar" via a single button, cluster expands/contracts | Cluster and Calendar (van Wijk & van Selow) — Section 4.2 "Interaction" | Full re-clustering cost was empirically ~5 s even on 1999 hardware for ~365 elements — supports iterative, interactive parameter exploration at runtime |
| Assess community coherence | Judge visual/statistical quality before accepting a partition | Represent dense communities as adjacency-matrix glyphs embedded in the node-link overview (hybrid NodeTrix representation); use LinLog layout (Noack 2005) for the surrounding node-link structure since it emphasizes cluster separation | NodeTrix (Henry, Fekete & McGuffin) — Sections 3.2.3, 4 | NodeTrix's three social-network-analysis tasks (identify communities T1, identify central actors T2, analyze roles/positions T3) map directly onto our assessment criteria |
Phase C — Cross-Window Lineage Tracking (Iterative Calibration)
| Step | Purpose | Method/Approach | Source | Parameters / Validation |
|---|---|---|---|---|
| Compute overlap between adjacent-window communities | Basis for linking community instances | Jaccard similarity of member sets (as specified); represent overlap magnitude as relative band width (overlap size ÷ set size), not absolute count | StratomeX (Streit et al.) — Fig. 1 caption, Supplementary Fig. 3 | StratomeX explicitly uses relative overlap for band width — important because raw counts bias toward large communities |
| Match instances into lineages; classify continuation/merge/split/birth/dissolution | Track persistent community identity | Treat this as a thread-extraction problem: tensor decomposition (CP/PARAFAC) of an entity × time × event tensor into K latent threads, with orthogonality constraint (BᵗB = I) enforced for interpretability; number of threads K chosen manually via interpretability, not algorithmically | EventThread (Guo et al.) — Section 4.2 "Summarization Algorithm" | No fixed optimum for K; authors manually selected K per case (4–7 in their datasets) by interpretability; this is a structural alternative to Jaccard-threshold matching, see "Possible Refinements" below |
| Calibrate matching/threshold parameter | Avoid spurious fragmentation or over-merging | Provide an interactive distance/threshold slider that re-clusters "thread segments" at each time-slice on demand, with immediate visual feedback | EventThread — Section 5.3.2 "Layout Algorithm," Fig. 6 | Because "there is often little ground truth... it is important to create methods which allow users to tune parameters to experiment with sensitivity" (EventThread §1, R4) — directly justifies our calibration loop's exit condition being human judgment rather than a statistical stopping rule |
| Arrange and visualize evolution | Show continuity, merges, splits, dissolutions across windows | Column-of-stacked-blocks representation (StratomeX) with connecting overlap bands; complement with EventThread's thread glyphs: dashed line segments for temporary absence (~birth/dissolution gaps), circular nodes sized by top-event likelihood, small "process bars" indicating what proportion of a lineage's members come from each constituent community instance | StratomeX — Fig. 1; EventThread — Fig. 5 (thread visual design) | StratomeX additionally offers a query wizard + LineUp ranking framework to score/rank stratifications (lineages) by criteria such as overlap with a chosen set or divergence in an outcome variable — directly reusable for ranking "interesting" lineages by e.g. persistence or size |
| Assess lineage plausibility | Decide whether current threshold is acceptable | No statistical acceptance criterion is given in the sources; instead, iterative sensitivity testing by adjusting the threshold/α parameter and re-inspecting the diagram is the recommended validation method | EventThread — R4; MobilityGraphs — §4.2 | Consistent across both sources: threshold selection is human-in-the-loop, not automated |
Phase D — Core Stability and Leadership
| Step | Purpose | Method/Approach | Source | Parameters / Validation |
|---|---|---|---|---|
| Compute core membership / centrality | Quantify per-author presence and centrality within a lineage | Betweenness centrality ("number of times a node lies on a shortest path between every pair of nodes") and degree centrality for identifying bridging/central actors; task framing: T1 identify communities, T2 identify central actors, T3 analyze roles/positions | NodeTrix — Section 2.1 "Social Network Analysis" | No numeric thresholds prescribed; centrality is used comparatively within the visualization, not as an absolute cutoff |
| Visualize per-author presence across windows | Show stable core vs. turnover | Feature Matrix heatmap (diverging colormap, mean value per state/column) plus Feature Distribution view (mean, std, histogram, and a shaded bar indicating missing values per cell) | DPVis (Kwon et al.) — Section 4.1, Figs. 2–3 | DPVis recommends training/interpreting state models with fewer than 20 states to preserve interpretability — analogous guidance for capping the number of distinguished "leadership tiers" or role categories |
| Visualize author trajectories through community states | Preserve density/detail while showing individual paths | Pathway Waterfall: parallel beeswarm plot (one lane per state/community) + force-directed edge bundling (Holten & van Wijk 2009) for trajectory lines, rendered on a dark background for contrast | DPVis — Section 4.2.1, Fig. 4 | DPVis explicitly notes overplotting risk for very large N and recommends canvas resizing / temporarily hiding dots as a mitigation, rather than a fixed density threshold |
| Classify leadership/collaboration patterns | Distinguish types of core-leader relationships | Empirically identified typology: "Cross pattern" (one prolific author linked to many mutually unconnected collaborators — likely a supervisor/PI), "Block pattern" (dense, mutually collaborating group — no single leader), "Intermediate pattern" (a central author plus a dense sub-block) | NodeTrix — Section 6.3 "Patterns of Collaboration," Fig. 6 | This typology is a qualitative validation heuristic, directly reusable for characterizing "leadership style" of each community's core |
| Test whether an author is a genuine bridge/articulation point | Validate hypothesized "bridge" authors | Interactive drag-and-drop removal test: temporarily extract a node from its matrix community and observe whether the community visually disconnects into components | NodeTrix — Section 6.2, Fig. 5 ("Ed Chi" example) | Demonstrated concretely: removing the hypothesized bridge author visibly splits the community into two disconnected sub-blocks, confirming bridge status |
Phase E — Research Foci via Topic Modeling (Iterative)
| Step | Purpose | Method/Approach | Source | Parameters / Validation |
|---|---|---|---|---|
| Filter/denoise text corpus per community instance | Remove uninformative terms before modeling | TF-IDF scoring (n-gram, n=1,2) to rank term importance; discard terms with significantly low TF-IDF as noise | EventThread — Section 4.1 "Data Filtering" | No fixed cutoff given; histogram of TF-IDF scores is inspected to choose a noise threshold |
| Choose topic-modeling algorithm | Derive interpretable, stable research-focus topics | NMF, not LDA, is recommended for visual-analytics settings, because of superior run-to-run consistency and faster empirical convergence | UTOPIAN (Choo et al.) — Sections 6.2–6.4 | Empirical results: with NMF, 10–25% of documents changed topic-cluster membership across repeated runs vs. 60–85% for LDA on comparable corpora; NMF converged in ~389 iterations (~48 s) vs. LDA showing no true convergence even after 20,000 iterations (~10 min) — a strong quantitative argument for NMF in our (repeatedly re-run, per-window) topic modeling |
| Fit and interactively refine the topic model | Produce named, stable research-focus labels | Semi-supervised NMF (SS-NMF): introduce reference matrices V (keyword-wise) and G (document-wise) with mask/weight matrices M_W, M_H to selectively supervise specific topics; supports five concrete interactive operations: topic keyword refinement, topic merging, topic splitting, document-induced topic creation, keyword-induced topic creation | UTOPIAN — Sections 4.1–4.3 | Number of topics k is user-chosen and iteratively adjusted based on interpretability of resulting keyword summaries (as in our loop's exit condition) |
| Visualize topic space for interpretability | Support visual judgment of topic coherence | Modified t-SNE with a shrinkage parameter α (default α = 0.4) applied to pairwise distances of same-cluster document pairs, sharpening visual cluster separation; slider allows interactive α adjustment | UTOPIAN — Section 5.1, Fig. 2 | Authors show qualitatively that α=0.4 substantially improves visual cluster separability versus unmodified t-SNE (α=1, i.e., no shrinkage) |
| Support real-time responsiveness during refinement | Enable fluid iterative topic refinement | Multi-threaded architecture: separate threads for SS-NMF computation, t-SNE computation, and rendering; intermediate iterations are shown incrementally rather than waiting for full convergence | UTOPIAN — Section 5.2 | Recommended primarily for interactivity/UX, not analytical necessity — flagged as a possible structural enhancement (see below) |
| Assess topic-model reliability | Judge coherence/stability of resulting topics | Compare keyword summaries across repeated runs with identical settings; large keyword-set divergence across runs (as demonstrated for LDA vs. NMF, Table 3 in UTOPIAN) signals an unreliable model requiring re-parameterization | UTOPIAN — Section 6.2, Table 2 (running-time results) | This "compare-across-reruns" procedure is itself the validation method suggested by the source, absent external ground truth |
Phase F — Individual-Level Mobility and Cross-Community Overlap
| Step | Purpose | Method/Approach | Source | Parameters / Validation |
|---|---|---|---|---|
| Reconstruct per-author trajectories through lineages | Represent an author's path across communities over time | Adapt the motion-graph metaphor: aggregate "poses" (here: community instances) as nodes; observed transitions between them (here: an author moving from one community to another) as edges; global overview via node-link diagram | MotionExplorer (Bernard et al.) — Section 4.3, Fig. 3d | The motion-graph abstraction naturally generalizes from "poses connected by observed motions" to "community instances connected by observed author transitions" |
| Lay out the trajectory/lineage overview | Preserve a stable, globally interpretable ordering (rather than a force-directed layout that shifts unpredictably) | Use a deterministic PCA projection of node positions rather than force-directed layout, explicitly because (a) it preserves a consistent global similarity ordering across incremental changes to the displayed node set, and (b) it has near-zero re-layout cost when nodes are added/removed | MotionExplorer — Section 5.3 "Analysis of Human Motion Sequences" | Authors explicitly chose PCA over force-directed after design-study feedback (Section 5.6) — directly informs our choice for laying out author-trajectory-over-lineage displays that change frequently under filtering |
| Alternative layout for comparing trajectory patterns (not raw structure) | Show similarity relationships among author-mobility patterns | MDS-based "distance-based positioning" of pattern thumbnails, using a user-selectable graph-edit-distance function (composed of edge weight, edge existence, node existence, node weight terms), as a complement to simple sequential (chronological) positioning | MobilityGraphs — Section 4.2 "Cluster Thumbnails," Fig. 4 | Authors explicitly retain both layouts (sequential = overlap-free but ignores similarity; distance-based = shows similarity but risks overlap) as complementary, switchable views |
| Avoid local overplotting in dense trajectory regions | Maintain readability where many authors converge | Provide (1) geometric zoom + small overview window, and (2) a local "flower" focus+context re-layout that temporarily arranges only the locally colliding nodes without perturbing the global layout | MotionExplorer — Section 5.6 "Design Process" (six candidate solutions ranked; the last two were selected) | Explicitly ranked against four rejected alternatives (global glyph-size slider, focus+hide, focus+highlight, semantic zoom) — useful evidence for why these two techniques were preferred |
| Identify bridging/multi-community authors | Detect authors that provide connective structure across communities | Reuse the NodeTrix drag-and-drop removal test (see Phase D) applied at the individual level: temporarily removing an author from a community and observing whether trajectory connectivity across lineages collapses | NodeTrix — Section 6.2 | Same validation logic as Phase D, applied here at the cross-lineage (rather than within-lineage) level |
Phase G — Integrated Interpretation
| Step | Purpose | Method/Approach | Source | Parameters / Validation |
|---|---|---|---|---|
| Structure the collaborative interpretation process | Support domain-expert-driven sense-making without ground truth | "Pair Analytics" protocol (cited and applied by DPVis): a tool operator and a domain expert jointly drive the analysis in structured workshops, with the expert interpreting patterns and formulating hypotheses in real time | DPVis (Kwon et al.) — Section 5.1 "Long-Term Collaboration With Study Group" | DPVis ran quarterly workshops over ~1 year with domain experts, iterating on findings — supports treating our integrated-interpretation loop as a multi-session process, not a single pass |
| Build/refine/compare analyst-defined subgroups | Support hypothesis testing on specific lineages, cohorts, or time windows | Provide a State/Sequence Finder-style graphical query builder (node-and-edge canvas with per-node/per-edge constraint popups, e.g. time window, minimum posterior/confidence) plus a persistent Subgroup List (auto-saved cohorts with descriptive titles) | DPVis — Section 4.5 "Subgroup Builder," Figs. 2G, 10 | DPVis reports that every view in the system can serve as a subgroup-construction/filtering tool — a general design principle: make every visualization also a query mechanism |
| Guard against unwarranted trust in model outputs | Ensure findings are not artifacts of a single parameterization | Explicit repeated caution from domain-expert interviews: insights should be treated as hypotheses to validate via repeated small-scale sensitivity checks, not accepted from a single run; experts value the ability to "conduct sensitivity analysis again and again" | DPVis — Section 5.3 ("DPVis Reduces the Effort...", "Users Want to Provide Feedback...") | Direct quote-based evidence for structuring Phase G explicitly as an iterative, not single-pass, refinement loop |
| Decide when to revisit earlier configuration (window size, matching threshold, topic granularity) | Formal criterion for loop exit / re-entry into earlier phases | Residual-pattern inspection: after model-fitting, examine whether residuals (here: analogous to "unexplained" structure, e.g. clusters/communities whose behavior isn't captured by the current window/threshold choice) show non-random temporal or structural patterning; if so, return to grouping or window/threshold configuration; if residuals appear structureless, accept current configuration | Andrienko & Andrienko (VA framework for ST analysis) — Section 3.2.4 "Model Evaluation" | This gives our loop L_interpretation an operational stopping criterion: recompute community/lineage residual structure (e.g., unexplained membership volatility) and check for randomness before terminating |
| Structure/evaluate the analyst's own workflow | Understand and later report on which task sequences were most productive | Build a state-transition diagram of task usage (nodes = task types, edges = observed transitions) from think-aloud session logs; report task coverage, number of transitions, dominant start/end tasks, and most frequent task-to-task transitions | IVESA (Bernard et al.) — Section VI-C "Reflection on User Workflows," Fig. 18 | IVESA's empirical finding of frequent transitions (e.g., "group → relate," "overview → details," "details → motif-definition → overview") is a useful expected pattern against which our own analysts' logged workflows could be compared during Phase G write-up |
Phase H — Knowledge Synthesis
| Step | Purpose | Method/Approach | Source | Parameters / Validation |
|---|---|---|---|---|
| Externalize findings into a reusable, machine-processable form | Prevent loss of interpreted patterns and enable communication/reuse | Store model descriptions (grouping/lineage assignments, chosen parameters, per-object statistics needed to reconstruct/re-apply models) in a human- and machine-readable external format (e.g., XML); explicitly separate "patterns in the analyst's mind" from "patterns represented as computer-processable models" | Andrienko & Andrienko (VA framework for ST analysis) — Sections 1, 3.2.5 "Storing the Models Externally" | This is presented as a general visual-analytics principle, not merely an implementation detail: "annotation tools... do not enable utilization of the patterns in further computerized analyses... patterns need to be represented in the form of computer-processable models" |
| Support prediction/extrapolation from stored models | Enable downstream use (e.g., forecasting community trajectories, testing "what happened next") | Store per-object statistics (e.g., quartiles) alongside group-level models so that group-level predictions can be individually rescaled to each object's own historical distribution (level-shift + amplitude-scaling formula) rather than naively applying one group curve to every member | Andrienko & Andrienko — Section 3.3 "Using the Models for Prediction" | Provides a concrete rescaling formula (using quartiles Q1, M, Q3) — directly reusable if the recommendation extends to forecasting a lineage's likely future member composition or size trajectory |
Possible Refinements to the Workflow Structure
(Not incorporated into the fixed design — flagged separately, as requested, since adopting them would change the workflow's phase structure rather than merely its methods.)
-
Joint tensor-based community-and-evolution discovery (EventThread). Instead of the two-phase pipeline (Phase B: independent per-window detection → Phase C: post-hoc lineage matching), EventThread's tensor decomposition jointly discovers latent "threads" (≈ lineages) and their per-window manifestations in a single factorization. Adopting this would merge Phases B and C into one computational step, removing the need for a separate overlap-threshold calibration loop but requiring a single "number of threads K" hyperparameter instead.
-
Pre-aggregation via a global supergraph (MobilityGraphs). Building one super-network across the entire 35-year span before windowing/clustering (rather than clustering each window independently) would reorder Phases A and B, guaranteeing consistent community identity across windows by construction and potentially eliminating the need for Phase C's lineage-matching step altogether — at the cost of underweighting short-lived, window-specific communities.
-
Generative sequential state modeling (DPVis / HMMs). Rather than independently detecting communities per window and then matching them, one could fit a (continuous-time) Hidden Markov Model directly over each author's community-membership sequence. This would replace Phases B+C with a single probabilistic model, natively producing transition probabilities (interpretable as merge/split/persistence tendencies) and offering built-in per-author "state" uncertainty (posterior distributions) — but would require rearchitecting the workflow around a state-space model rather than discrete graph clustering.
-
Live incremental recomputation (UTOPIAN's real-time NMF/t-SNE architecture). Restructuring Phases B, C, and E as continuously-updating, multi-threaded computations (showing intermediate algorithm states as they converge) rather than discrete "run → assess → adjust → rerun" loops would turn the workflow's iterative loops into a single continuous interaction — a substantial control-flow change from discrete iteration to live steering.
-
Motif-based simplification layer (IVESA). Adding a dedicated motif-detection step — treating recurring higher-order evolutionary patterns (e.g., "merge-then-split-within-two-windows" cycles occurring across many lineages) as queryable, substitutable motifs — would introduce an additional simplification phase between Phase C (lineage tracking) and Phase G (integrated interpretation), shifting some interpretive burden from manual event-by-event inspection to pattern-based query and substitution.