C5 Method-level enrichment table (Stage 2 of the C3 chat; structure held fixed)
Implementation-Ready Enrichment: Vastopolis Outbreak Workflow
The structural design (artifacts, transforms, loops) from the previous stage is unchanged. Below, each phase/step is enriched with concrete methodological detail drawn from the six source papers. Citations use short paper names: MovTracks (Andrienko et al., events-to-places), HITL (Human-in-the-Loop behaviour patterns), DaedalusData, CrossImpact (Detecting Stable Cross-Impact Patterns), IVESA, LFPeers.
Phase 1 — Extraction and Validation of Illness Reports
| Step | Analytical Purpose | Recommended Method/Approach | Source | Parameters / Validation Notes |
|---|---|---|---|---|
| T_extract_reports (initial classification) | Flag microblog messages as candidate illness reports | Treat as a feature-engineering + labeling problem: derive text/behavioral features first, classify second, rather than a one-shot keyword filter | HITL (general approach, Fig. 2) | HITL frames this as: (1) segment data into analyzable units, (2) engineer discriminative features from domain knowledge, (3) assess feature separability visually, (4) group/label, (5) evaluate with a classifier — apply this five-step scaffold to symptom-keyword criteria refinement |
| F_report_sample (feature prep for review) | Produce inspectable summaries of flagged/excluded messages | Use interval/summary-style descriptive features (value level, variability) adapted to text: keyword-hit counts, confidence-score distributions, histogram of borderline cases | HITL §"General Approach" (catalog of interval features: min/max/mean, quantiles, histograms) | Recommend histogramming classifier confidence scores to locate a natural threshold "bend point," analogous to HITL's frequency-distribution inspection of the curvature feature |
| V_report_sample / T_visualise_sample | Let analyst inspect flagged/excluded messages in context | Multi-particle/multi-item selection and bulk visual inspection rather than one-by-one review; use lasso/rectangle selection over a 2D layout of messages | DaedalusData §5.6 (Detail/Selection-Inspection Views), §5.2 (Canvas multi-selection) | DaedalusData reports lasso tool initially less preferred than rectangle but ultimately valued for bulk selection efficiency — provide both selection tools |
| T_assess_extraction | Judge completeness/precision of extraction criteria | (a) Compare system-flagged vs. visually-identified positives directly, as in HITL's comparison of formal-specification hits vs. visually confirmed trawling episodes; (b) use Selection-Inspection View–style attribute distribution summaries (e.g., % of selection with each keyword/confidence bucket) to spot systematic misses | HITL Case Study 1 (comparison of specification-based detection vs. visual/ML detection); DaedalusData §5.6 (Selection-Inspection View) | HITL found their feature-based approach recovered ~4x more true positives (2242) than the rigid rule-based system (530) — use this as a template for validating whether relaxed/ tolerant criteria recover more true reports without inflating false positives |
| T_revise_criteria (criteria refinement loop) | Iteratively adjust keyword list/threshold | Use dimensionality-reduction embedding (UMAP) over report features (confidence, keyword-hit vector, message length, etc.) to visually check whether "true" and "false" reports separate into distinct regions before committing to a final threshold | HITL §Case Study 1 (UMAP grouping, n_neighbors, min_dist) | HITL used UMAP with n_neighbors=50, min_dist=0.25 for a large dataset and n_neighbors=16, min_dist=0.25 for a smaller one — start with n_neighbors ≈ 15–50 depending on report volume; results reported robust across parameter combinations |
| Selecting representative "confirmed"/"rejected" examples | Build a small set of labeled report examples to calibrate/validate criteria | Use k-means clustering on the feature space, take cluster cores (members with silhouette score ≥ ~0.24–0.55 depending on dataset homogeneity) as representative examples rather than manual brushing alone | HITL §Case Study 1–2 (clustering + silhouette threshold) | HITL used silhouette threshold 0.55 for a large, homogeneous dataset and 0.24 for a smaller, more heterogeneous one (football styles) — choose threshold empirically via the silhouette-score histogram |
| Quality check of final report set | Confirm the extraction generalizes beyond hand-checked examples | k-NN classification using labeled examples to check whether unlabeled messages "inherit" correct classification from similar neighbors | HITL (kNN evaluation, k=10–50) | Choose k proportional to dataset/label-set size (HITL: k=50 for ~1600 labeled examples, k=10 for ~380). Flag items with no majority class (<50–60% weight) as uncertain for manual review |
Phase 2 — Spread Overview and Origin Localisation
| Step | Analytical Purpose | Recommended Method/Approach | Source | Parameters / Validation Notes |
|---|---|---|---|---|
| T_assign_zone / F_daily_incidence | Aggregate reports into zone-level, population-normalized daily incidence | Spatio-temporal aggregation of extracted "events" (illness reports treated as m-events) by place (zone) and time interval, computing counts, distinct-reporter counts, and attribute statistics per place-interval combination | MovTracks §4.3 (Step 3: aggregating events and trajectories) | MovTracks aggregates by 1-hour intervals for traffic; for epidemiological reports, daily intervals aligned to the outbreak's reporting cadence are appropriate; consider also cyclic aggregation (day-of-week) if reporting behavior itself has a weekly pattern |
| T_visualise_spread (small multiples) | Trace spatio-temporal spread visually | Small-multiples map sequence with per-panel choropleth + point overlay, one panel per time interval | MovTracks §6 (temporal diagrams positioned on map; time graph of counts by area) | MovTracks also recommends a time graph (line chart per zone, colored by category) linked to the map — add this as a companion display to identify surge intervals before switching to per-panel maps |
| T_select_early_reports / D_early_reports | Restrict to earliest-phase reports for origin search | Treat each illness report as an "m-event"; before clustering, decide the event-generation strategy for consecutive/near-duplicate reports from the same reporter or location: (1) independent events, (2) representative point (first/last/medoid), (3) averaged point, (4) single multi-point event | MovTracks §4.1 (Step 1: strategies for consecutive points) | For illness reports, strategy 2 (first point / earliest timestamp per reporter) is most semantically appropriate, analogous to using the first point for "landing" events, to avoid inflating counts from a single person's repeated posts |
| T_cluster_origin (two-stage clustering) | Isolate a compact, fine-grained candidate origin cluster from early reports | Two-stage density-based clustering (DBSCAN/OPTICS): Stage 1 — spatio-temporal clustering using a custom multi-attribute distance function over space, time, and optionally thematic attributes (e.g., symptom severity); Stage 2 — spatial-only clustering of the Stage-1 clusters (after discarding noise) to merge co-located sub-clusters into final "places" | MovTracks §4.2 (Step 2, full distance-function formalism, Eq. 1–3) | Distance function requires per-dimension thresholds <Ds, Dtime, D_theta,...> and an aggregation rule: max/cube (Eq. 3a, recommended — more intuitive) vs. Euclidean/sphere (Eq. 3b). MovTracks used thresholds of 100m / 10min / 20° for Stage 1 and 100m / 20° for Stage 2 in their traffic case; comparable orders of magnitude (e.g., 200–500m / a few hours) are reasonable starting points for pedestrian-scale illness reports and should be tuned interactively |
| Threshold selection for clustering | Choose spatial/temporal thresholds defensibly | Visual threshold estimation: render events semi-transparently on the map, adjust transparency until concentrations become visible, zoom into candidate concentrations, measure distance from a few sample points to their 3rd–4th nearest neighbor — the maximum of these distances approximates a good spatial threshold. Iteratively adjust by 10–25% per trial if clusters come out too large/small | MovTracks §4.2 | Explicitly log threshold trials (MovTracks reports "final chosen values" only, but recommends multiple runs) — feed this into the K_origin_quality assessment step of the origin-localisation loop |
| T_visualise_origin / buffers | Represent origin candidates as delineated places | Construct spatial buffers or convex hulls around final clusters; verify buffer orientation/shape against known infrastructure (e.g., building footprints, landmark positions) | MovTracks §4.2, §6 (airport buffer validation) | MovTracks validated airport buffers by checking that known airport coordinates fell inside the buffer and that buffer orientation matched runway orientation — analogously, verify that the origin buffer plausibly contains or neighbors a landmark (market, hospital, water source) before finalizing |
| T_assess_origin (validation) | Judge plausibility of the origin cluster | Cross-check extracted place against independent evidence: infrastructure layout, domain expectations, and (if available) an external ground truth or secondary data source | MovTracks §5 "Validation of findings" (compared clusters to Google Maps traffic and to a domain expert) | Note MovTracks' own caveat: without an external expert, they self-validated via infrastructure correspondence — recommend involving a public-health domain expert for this same self-validation role in Vastopolis |
Phase 3 — Transmission-Mode Hypothesis Testing
Person-to-person hypothesis
| Step | Method | Source | Parameters |
|---|---|---|---|
| Spatial contiguity/diffusion evidence | Reuse the MovTracks m-event/place framework: define "spatial context elements" (e.g., road segments, other reports) and compute distance-to-nearest-neighbor-report and neighborhood counts within a spatial/temporal window as diffusion indicators | MovTracks §4.1 (context-oriented dynamic attributes: distance to nearest STCE within temporal window; neighborhood counts) | Use MovTracks' explicit attribute types: "count of STCE within given spatial and temporal windows" directly operationalizes contact-diffusion evidence — window sizes should reflect a plausible incubation-to-symptom-report delay |
Airborne hypothesis
| Step | Method | Source | Parameters |
|---|---|---|---|
| F_hypothesis_evidence (lagged wind–incidence correlation) | Compute a robust, tolerance-adjusted Kendall's τ between wind time series (base) and case-incidence time series (response) over a sliding window, across a range of time lags | CrossImpact §3.1 (Algorithm 1: Kendall's Tau with Tolerance) | Tolerance thresholds εx, εy — start at 2–5% of each series' value range (CrossImpact's case study settled on 2%); use percentile-based (5th–95th) range estimation if outliers are present |
| Sliding window / lag range | Choose window length TW and max lag L aligned to natural cycles and epidemiologically plausible delay |
CrossImpact §3.1.2 (Table 3: parameter guidance) | CrossImpact recommends TW aligned to weekly cycles (e.g., 7 days) and L set to the expected incubation/reporting delay (their COVID case used TW=7 days, L=7–21 days); for airborne spread in Vastopolis, a shorter L (hours to 1–2 days) is more appropriate given faster transmission dynamics — but the same tuning logic applies |
| Statistical significance | Determine whether a given τ is meaningful given window length and tolerance-induced ties | CrossImpact Eq. 1, Fig. 3 (critical τ thresholds vs. T and p) | For p=0.05, critical |
| V_hypothesis (Ikat plot) | Visualize the 2D distribution of impact values across (time × lag) to identify sustained, transient, lag-specific, episodic, stable trend-driven, or noise patterns | CrossImpact §3.2 (Ikat plot design), Table 4 (pattern typology) | Use the typology in Table 4 directly to classify the wind-incidence relationship pattern found; combine with dynamic query sliders (level/trend/impact conditions) to isolate periods where wind direction plausibly precedes case spread |
| T_log_evidence / event extraction | Convert visually-identified stable impact regions into standalone "impact events" (defined by t1,t2,l1,l2) for systematic evidence accumulation |
CrossImpact §3.3 (event extraction algorithm, Appendix B: connected-region search) | Apply the same connected-region (flood-fill) extraction algorithm to formalize "wind precedes case-increase" intervals as discrete evidence items rather than relying purely on visual impression |
| Parameter robustness check | Confirm findings are not artifacts of a single threshold choice | CrossImpact §3.4 (parameter sensitivity analysis, Fig. 9) | Vary tolerance ε systematically within a small range and re-run extraction; look for "bend points" in the resulting event-count curve to identify a defensible operating threshold before committing to the airborne verdict |
Waterborne hypothesis
| Step | Method | Source | Parameters |
|---|---|---|---|
| Distance-to-water feature | Compute spatial distance to nearest context element (here, water body) per report, analogous to MovTracks' distance-based dynamic attributes | MovTracks §4.1 (spatial distance to nearest/n-th-nearest SCE) | Directly reuse MovTracks' formal attribute definition; combine with a neighborhood count (reports within X meters of a water body) as a second corroborating feature |
| Cluster near water independent of population density | Re-apply the two-stage density clustering method (MovTracks §4.2) restricted to reports near water bodies, to check whether a distinct, population-independent cluster emerges | MovTracks §4.2 | Same distance-function and thresholding procedure as origin-localisation; compare resulting cluster's population-normalized density against the zone baseline to rule out simple population confounding |
Point-source / other hypothesis
| Step | Method | Source | Parameters |
|---|---|---|---|
| Shared-venue text evidence | Treat venue/landmark mentions in early-case message text as a categorical thematic attribute for event clustering, alongside space/time | MovTracks §4.2 (clustering with additional thematic attributes; non-numeric attribute distance = 0 if equal, ∞ otherwise) | If landmark name is extracted from text, include it as a zero-threshold categorical dimension in the Stage-1 clustering distance function, forcing same-venue reports to cluster tightly regardless of minor spatial offset |
Cross-hypothesis exploration and comparison (all four hypotheses)
| Step | Method | Source | Parameters |
|---|---|---|---|
| A_hypothesis / V_hypothesis (multi-view coordination) | Cross-cut report distributions by two criteria at once (e.g., wind-direction bin × time; water-distance bin × zone) using a heatmap "Metadata View," with an option to switch to small-multiples for structural comparison | IVESA §IV-C (Metadata View: heatmap cross-cut, binning strategies, small multiples) | IVESA's default binning cap is 20 bins, based on the empirical finding that beyond ~20 bins, perceptual improvement plateaus (Sahann et al., cited in IVESA); use domain-preserving binning for continuous variables (wind direction, water distance) |
| Filtering during hypothesis exploration | Let analyst narrow the report set by attribute (zone, symptom confidence, distance-to-water) with visible preview of filter effect before committing | IVESA §IV-E1 (Filtering View: bar-chart preview of included/excluded counts) | Adopt IVESA's specific design choice of showing filtered-out items as reduced-opacity/striped marks rather than fully hidden, to preserve context — directly reusable for the map/timeline views in Phase 3 |
| T_formulate_hypothesis / search-then-explore structure | Frame each hypothesis test as: (1) a search phase — find the subset of time/zones where a candidate factor and the case trend co-occur before a reference point t0; (2) an exploration phase — analyze how the relationship evolves/diverges after t0 | LFPeers §2 (two-phase concept: search phase before t0, exploration phase after t0) | LFPeers explicitly supports multiple parallel similarity criteria (up to 4) whose results are intersected — apply this to require, e.g., "wind-direction match AND temporal proximity" simultaneously when narrowing candidate airborne-impact windows |
| T_interpret_hypothesis (correlation with external factors) | After identifying a co-occurrence pattern, automatically rank candidate explanatory attributes by correlation strength at a chosen time point, with drill-down scatterplots | LFPeers §3.2 (Exploration Phase: correlation ranking list + scatterplot pop-over) | LFPeers computes correlation "at time point t1" across all peers/attributes and ranks by strength — apply directly: at a chosen point in the outbreak timeline, rank {wind metrics, water proximity, road connectivity, venue co-mentions} by correlation with case increase to prioritize which hypothesis to pursue next |
| Distance/similarity metric choice | Choose between Euclidean distance (emphasizes exact timing) and Dynamic Time Warping (tolerates temporal distortion) when comparing candidate factor time series to the case-incidence series | LFPeers §3.1 ("Interactive similarity concepts") | LFPeers lets users switch interactively; recommend DTW if reporting delays/noise are suspected, Euclidean if exact lag timing matters (as it does for testing incubation-period-consistent lags) |
Phase 4 — Synthesis
| Step | Method | Source | Parameters/Notes |
|---|---|---|---|
| Quantify which event features predict impact | Fit an interpretable model (e.g., logistic regression) using event attributes (duration, trend direction, spatial location, amplitude) to predict whether a trend/event "had impact," rather than relying solely on visual judgment | CrossImpact §5.4 ("Quantitative analysis and modeling") | CrossImpact builds per-wave and global logistic regression models and reports feature-weight magnitudes as an interpretability aid (accuracy 70–92% in their case) — an analogous model regressing "case-increase occurrence" on {wind-lag evidence, water-proximity evidence, mobility/contiguity evidence, venue co-mention evidence} would let the synthesis step assign relative quantitative weight to each transmission hypothesis rather than a purely qualitative verdict |
| Present findings with spatial context | Use a timeline chart (not a space-time cube) as the default display for combined trend/impact events across zones, ordering zones along the non-time axis by a similarity-based 1D projection (e.g., Sammon mapping of zone centroids) rather than arbitrary order | CrossImpact §5.2, §6.2 | CrossImpact explicitly found the space-time cube "requires interactive rotation... to reduce occlusion" and preferred the simpler timeline chart with a similarity-informed axis ordering — recommend the same for presenting the final zone-by-time findings to the public-health team |
Possible Refinements to Workflow Structure
(Not incorporated into the fixed design — flagged separately as the source papers suggest they would materially change the workflow's shape.)
-
Unify origin-localisation and hypothesis-testing into one before/after-t0 structure. LFPeers' core insight — a single "search phase" (find similar/co-occurring items before a reference point) followed by an "exploration phase" (analyze divergence after that point) — could replace the current two separate loops (
L_origin_localisation,L_transmission_analysis) with one unified temporal framework, using the outbreak's earliest detected surge as the shared t0. -
Restructure Phase 1 around label alphabets rather than a single keyword/threshold specification. DaedalusData's model of multiple, parallel, persistent "label alphabets" (e.g., separate alphabets for symptom-type, credibility, and venue-mention) would let analysts build a richer, reusable knowledge base of report categorizations rather than iteratively overwriting a single extraction specification — this is a more substantial data-augmentation architecture than the current single-specification refinement loop.
-
Add an explicit motif-detection/simplification step for report and case-time-series patterns. IVESA's dedicated Motif View (interactive definition, matching via Euclidean/DTW, coverage tracking) suggests that recurring temporal signatures (e.g., daily tweet/report bursts, weekly reporting cycles) could be extracted and used as first-class artifacts throughout the workflow, rather than being noticed only incidentally during visual inspection.
-
Replace the sequential hypothesis-testing loop with a persistent multi-linked-view system. IVESA's architecture (Sequence Overview + Metadata View + Details View + Summary View, all linked) supports simultaneous, side-by-side comparison of all four transmission hypotheses rather than iterating through them one at a time — this would be a more parallel, exploratory structure than the current sequential loop with an evidence log.
-
Add explicit parameter-sensitivity-analysis and quantitative-modeling sub-phases. CrossImpact treats parameter sensitivity analysis (systematically varying tolerance/thresholds and observing event-count trends) and quantitative modeling (logistic regression over extracted events) as distinct, formal pipeline stages rather than embedded assessment judgments — promoting these to standalone phases would make the workflow's evidentiary reasoning more auditable and reproducible.
-
Infrastructure-scalability layer. If the Vastopolis microblog corpus proved too large for in-memory processing, MovTracks' scalable architecture (moving temporal/spatial windows, database-backed incremental clustering) offers a concrete blueprint for re-architecting the extraction and clustering steps for out-of-core processing — not needed at assumed data volumes here, but worth flagging for larger-scale deployments.