Raw session log. Continues c6; gap-analysis of the atwl translation.
14 turns (7 user · 7 assistant) json raw log
You have received a document titled Workflow Library: Titles and Summaries. This document contains natural-language summaries of 53 visual analytics workflows drawn from the published research literature. Each summary describes the analytical goal, the workflow structure, and the methodological approach of a specific published workflow. The summaries were extracted from a public workflow library curated by our research group.
Please read the summaries carefully before we proceed. In the next message I will describe a specific visual analytics design task. Your job will be to design an analytical workflow that addresses the task, drawing on the workflows in the library where relevant. The library is a resource — you may consult it to identify workflow structures, analytical strategies, or methodological approaches that could inform your recommendation for the target task. You are not obliged to use the library workflows, and you may combine elements from multiple workflows, adapt them, or design new steps as the task requires.
Please describe your recommended workflow in natural language, in sufficient detail that a research analyst could use it as a design template. Where you draw on specific library workflows, please cite them by name so the analyst can trace the sources of your recommendation.
Before we proceed, could you briefly confirm that you have absorbed the library, and let me know if you have any questions before the task is described?
Ich habe das Dokument mit den 53 Workflow-Zusammenfassungen sorgfältig gelesen und die zentralen Konzepte, Methoden und Strukturen jedes Workflows erfasst — von zeitreihenbasierten Clustering-Ansätzen (z. B. Calendar-Based Visualization, SOMFlow, Cluster/Calendar-Workflows) über netzwerk- und bewegungsbezogene Analysen (z. B. Reducing Snapshots to Points, MobilityGraphs, Movement-to-Places) bis hin zu Modell-Diagnose- und Erklärbarkeits-Workflows (z. B. explAIner, What-If Tool, RuleSense, VBridge) sowie kohorten- und ereignisbasierten Analysen (z. B. COQUITO, Coral, EventFlow/Temporal Event Sequence Simplification, EventThread, EventAction).
Ich bin bereit, diese Bibliothek als Referenz zu nutzen, um für die konkrete Design-Aufgabe passende Workflow-Strukturen, Analysestrategien oder methodische Bausteine zu identifizieren und daraus einen maßgeschneiderten Workflow-Vorschlag zu entwickeln.
Ich habe derzeit keine offenen Fragen zur Bibliothek selbst. Bitte beschreiben Sie die konkrete Design-Aufgabe — ich werde dann gegebenenfalls gezielt nachfragen, falls Ziel, Datenlage oder Nutzerkontext unklar bleiben, bevor ich den Workflow-Vorschlag ausarbeite.
Please reply only in English.
Confirmed — I have carefully read and absorbed all 53 workflow summaries in the Workflow Library. I now have a working grasp of the analytical goals, structures, and methodological approaches across the collection, including (non-exhaustively):
- Temporal/calendar pattern discovery: Cluster and Calendar Based Visualization, SOMFlow, Spatio-temporal Analysis and Modelling
- Dynamic network/mobility analysis: Reducing Snapshots to Points, MobilityGraphs, Movement Tracks through Events to Places, Progressive Clustering of Movement Data
- Event sequence analytics: Temporal Event Sequence Simplification, EventThread, EventAction, COQUITO, IVESA
- Cohort construction/comparison: Coral, Kokiri, Visual Cohort Comparison (Spatial Single-Cell Omics), StratomeX
- Model diagnosis/explainability: explAIner, What-If Tool, Diagnosing Binary Classifiers, RfX, VBridge, RuleSense, Understanding Compound Potency Models, TensorFlow Dataflow Graphs
- Exploratory modelling: Exploratory Model Analysis, Partition-based Regression Modelling, Hybrid Visual Steering, ParaGlide, Tuner, Progressive High-Dimensional Analysis
- Human-in-the-loop labeling/embedding: Active Gaze Labeling, DaedalusData, Knowledge-Incorporated Embedding Exploration, EnsembleLens
- Eye-tracking/gaze analytics: ISeeCube, Space-Time Eye-Tracking, Image-Based Projection Labeling
- Text/investigative/provenance analysis: Jigsaw, SensePath, Visual Movie Analytics, Multimodal Collaborative Design Analysis
- Graph/state/network structure: NodeTrix, RelEx, Multivariate State Transition Graphs, MotionExplorer
- Advanced pattern/topic discovery: Progressive Abstraction Analysis (Episodes and Topics), QVis, Cross-Impact Pattern Detection, DPVis
I have no outstanding questions at this stage. Please go ahead and describe the specific visual analytics design task — I'll consult the library as needed, cite relevant workflows by name, and may ask clarifying questions about the task's data, goals, or user context before finalizing my recommended workflow.
The IEEE VIS conferences (Vis, InfoVis, VAST, SciVis) have accumulated 3596 papers between 1990 and 2024. Each paper record contains the list of authors, publication year, title, abstract, keywords, and citations. Author names have been disambiguated against DBLP (unique author identifiers are provided alongside the raw name strings).
A research analyst studying the intellectual structure of the visualization community wants to identify the major communities of collaborating researchers and characterise how they have evolved. The analyst expects that a community typically has a relatively stable core of leading researchers who continue collaborating across many years, while other members may move between communities over time or contribute to several communities simultaneously. Each community should also be associated with its major research foci — the topics or problem areas that characterise its work.
The analyst wants to answer questions such as: how many distinct communities can be identified? How stable is each community's core, and who are its leaders? What are its main research foci, and how have they evolved? How does membership overlap between communities, and how does it change over time? Do communities merge, split, or dissolve, and if so, when and why?
The analyst will need to inspect intermediate results visually and use domain knowledge to interpret patterns and make judgements at each stage.
Design an analytical workflow for this problem.
To track evolution, I'd construct a community-flow graph by computing Jaccard similarity between community memberships across adjacent time windows — high overlap signals persistence, splits and merges become visible as divergence patterns, and I can visualize this as a streamgraph or Sankey diagram showing how communities flow and transform over time.
Then for each community across its lifespan, I'd extract per-author metrics like tenure across time-windows, centrality within the community, publication volume, and betweenness to identify core members versus peripheral contributors and surface leadership patterns.
For characterizing research foci, I'm extracting text features from papers and building a term-document matrix to apply topic modeling techniques. This lets me discover latent topics within each community and track how their research focus evolves across time windows — treating each community-period as an episode where papers reveal the dominant themes, similar to how the COVID-19 case study tracked topic distributions across regions and time.
For the visual interface, I'm designing a multi-view system: an alluvial diagram showing community dynamics over time, a NodeTrix-style view for inspecting internal structure at specific snapshots, a topic panel displaying each community's top keywords per period with interactive steering capabilities, and an author-level timeline showing which communities individuals belonged to and whether they were core members.
I'm also including an overlap matrix to visualize shared authors between communities at each time slice, and a provenance graph tracking all clustering decisions and manual corrections so the analyst can review and validate the entire refinement process. The key is letting the analyst adjust the community detection resolution parameter iteratively while inspecting results and applying domain expertise. Topic modeling to characterize research foci within each community across different time periods, then a visual interface combining timeline/alluvial diagrams, community matrices, author trajectories, and topic panels to support interactive exploration. I'm also considering how to incorporate provenance tracking throughout the refinement loop, and drawing on approaches like Reducing Snapshots to Points for projecting network evolution and MobilityGraphs for identifying representative community states across time.
NodeTrix visualization would be particularly useful for examining the internal structure of communities and spotting key actors, while interactive topic modeling tools like UTOPIAN could help extract and refine research themes directly from paper text. I'm also thinking about Progressive Abstraction Analysis as a framework for converting temporal episodes into meaningful patterns.
SOMFlow's approach to tracking iterative refinement with explicit provenance appeals to me for managing the community-detection workflow, and EventThread's tensor-based method for discovering evolving stages across time could directly inform how I track community evolution and link those patterns back to individual authors and their collaborations. StratomeX offers a useful template for comparing different community groupings side by side. Coral could help track how author cohorts are defined within each community, and DPVis's approach to visualizing state progressions might work well for mapping how communities evolve through merge, split, or dissolution stages using something like a Sankey diagram. Now I'm ready to structure this into a concrete workflow that a researcher can follow step-by-step, organized into clear phases starting with data preparation, then temporal network construction with snapshot windows.
Recommended Analytical Workflow: Intellectual Structure and Evolution of the VIS Co‑Authorship Community
This task combines three distinct analytical problems that none of the individual library workflows solves alone: (1) dynamic community detection in a co-authorship network, (2) tracking core stability, membership drift, and merge/split/dissolution events over 35 years, and (3) characterising each community's research foci from text. I therefore propose a composite workflow that adapts pieces from several library workflows — principally Reducing Snapshots to Points, MobilityGraphs, NodeTrix, SOMFlow, EventThread, Human-Steered Topic Modelling (UTOPIAN), StratomeX, and RelEx — into a single pipeline with a human-in-the-loop visual interface at every stage.
Phase 0 — Data Preparation
Construct one record per paper with disambiguated author IDs, year, title, abstract, keywords, and citation links. Build a full-period co-authorship graph (nodes = disambiguated authors, edges = weighted by number of joint papers) as a reference structure, analogous to the "supergraph across all time steps" used in MobilityGraphs to obtain a consistent spatial aggregation before temporal analysis. This full-period graph is not the final community structure — it only anchors later comparisons.
Phase 1 — Temporal Network Construction
Following the snapshotting logic of Reducing Snapshots to Points, divide 1990–2024 into overlapping time windows (e.g., 5-year windows advancing by 1–2 years) to keep adjacent snapshots smoothly related rather than abruptly different. For each window, build a weighted co-authorship subgraph containing only authors/edges active in that period. This yields a sequence of comparable network states, exactly the input structure that workflow uses for detecting stable, recurring, and outlier states.
Phase 2 — Community Detection: Anchor + Per-Window
- Anchor communities: Apply a density-aware community-detection algorithm (e.g., Louvain, Leiden, or an OPTICS/DBSCAN-style approach as used for spatial aggregation in MobilityGraphs) to the full-period graph. This produces a stable set of "reference" macro-communities that persist across the whole dataset — the analogue of MobilityGraphs' spatial simplification step, which prevents weakly-connected authors from being merged just because they occasionally co-publish.
- Per-window communities: Independently run the same detection algorithm on each windowed snapshot from Phase 1. This captures short-lived alliances, splinters, and newly emerging groups that the anchor step, by construction, would smooth over.
Both partitions are kept — the anchor communities give a long-term skeleton; the per-window communities give the fine-grained temporal signal needed for merge/split/dissolution detection.
Phase 3 — Cross-Time Community Matching and Evolution Events
For each pair of adjacent (overlapping) time windows, compute member-set overlap between every pair of communities (Jaccard or a weighted variant using publication counts). Represent this as a community-flow graph: nodes are (community, time-window) pairs; edge weight is overlap. High mutual overlap → persistence; one community splitting its members across two next-period communities → split; two communities converging into one → merge; a community with no strong successor → dissolution; a new community with no strong predecessor → emergence.
This tracking logic is a simplified, set-based analogue of the tensor-decomposition "threads" in EventThread, where entities (here: authors), stages (here: time windows), and latent groupings are jointly modeled to reveal branching, merging, and persisting patterns. If community identities look ambiguous under simple overlap, consider EventThread's tensor approach directly: build an author × community-membership × time-window tensor and decompose it into latent "threads" that represent long-run community trajectories even when exact membership varies.
Visualization: Render the community-flow graph as an alluvial/stream diagram (community size over time, ribbons showing flow between periods), paired with a Reducing Snapshots to Points–style 2D projection in which each (community, window) node is embedded by its member/topic vector — clusters of nearby points across consecutive times indicate stable regimes, isolated points indicate anomalous/transient communities, and trails indicate transitions. This gives the analyst the "map of community states" needed to answer how many distinct communities exist and when they merge, split, or dissolve.
Phase 4 — Core Stability and Leadership Analysis
For each tracked community trajectory (a chain of matched per-window communities), compute per-author metrics across its life span: - Tenure: fraction of time-windows in which the author is assigned to this community. - Centrality: degree/betweenness within the community subgraph at each window. - Cross-membership: number of distinct communities an author belongs to over the full period (identifies boundary-spanners vs. movers vs. loyal members).
Classify authors into core (high tenure + high centrality, present across many years — the "stable leadership"), peripheral/transient (short tenure, low centrality), and boundary-spanning (member of multiple communities, possibly simultaneously).
For detailed inspection of any single community/period, use NodeTrix (developed and validated on exactly this kind of co-authorship data): render the community as a hybrid node-link/matrix view, converting the locally dense collaboration core into a readable adjacency matrix while keeping bridging ties to other communities visible as node-link edges. This is the natural tool for testing hypotheses like "is this a cross pattern with one central PI and many loosely connected collaborators, or a dense block of mutually collaborating leaders?" — the two collaboration-pattern archetypes NodeTrix's own case study identifies in InfoVis co-authorship data.
For an author-centric view of movement between communities over time (a per-author "community timeline"), adapt the scarf-plot/event-sequence idiom from Temporal Event Sequence Simplification or IVESA: each author is a horizontal track, colored segments indicate community membership per period, gaps indicate inactivity. This directly visualizes membership overlap and drift, letting the analyst answer "how stable is the core, who moves, and when."
Phase 5 — Research Foci Extraction and Evolution
Build a term-document matrix from titles, abstracts, and keywords. Apply Human-Steered Topic Modelling (UTOPIAN)'s NMF-based approach rather than LDA, because its deterministic, steerable behavior is well suited to iterative refinement: the analyst can merge redundant topics, split overly broad ones, or seed new topics from representative documents/keywords, and immediately see the recomputed decomposition.
To connect topics to communities and track their evolution, follow the Progressive Abstraction Analysis (Episodes and Topics) pattern directly: treat each (community, time-window) pair as an "episode," aggregate its papers' topic-mixtures into a single topic profile, and visualize topic-profile distributions across communities and time using matrix/small-multiples displays (exactly as that workflow shows COVID mobility topics across countries and time). This answers "what are a community's major research foci, and how have they evolved" and additionally supports comparing foci across communities.
Phase 6 — Overlap and Cross-Community Comparison
To make cross-community membership overlap and its temporal change explicit (beyond the flow diagram in Phase 3), build a pairwise overlap matrix per time window — communities on both axes, cell values = number/fraction of shared authors — following the matrix-comparison logic of RelEx (which uses a sender/receiver matrix to expose significant relational patterns in a large relational structure) and StratomeX (which compares multiple stratifications of the same population via overlap bands and supports ranking/querying for "stratifications similar to X" or "sets with high overlap"). This lets the analyst treat each period's set of communities as a "stratification" and directly query for high-overlap community pairs, candidates for eventual merging, or communities that quietly lost their distinctiveness.
Phase 7 — Integrated Interface and Iterative Refinement Loop
Assemble the above into a linked-view system, with the following interaction loop, modeled on the iterative "propose → inspect → refine → recompute" logic common to SOMFlow, UTOPIAN, and explAIner:
- Overview: alluvial community-flow diagram + 2D snapshot-embedding (Phase 3) — pick a community trajectory of interest.
- Structure drill-down: NodeTrix view of the selected community at a chosen period (Phase 4) — inspect core/leader structure, bridging authors.
- Author timeline: scarf-plot view of individual authors to verify stability/drift claims (Phase 4).
- Topic panel: NMF topic profile for the selected community-period, editable via merge/split/seed operations (Phase 5); recompute and observe topic drift across adjacent periods.
- Overlap matrix / StratomeX-style query: check whether the selected community is converging with, diverging from, or embedded inside another (Phase 6).
- Provenance log: as in SOMFlow's flow graph, record every parameter choice (resolution, window size, overlap threshold, manual merges/splits of communities or topics) so the analyst's judgment calls are traceable and revisions can be compared against earlier ones.
The analyst iterates: adjusting the community-detection resolution or window size if communities look too fragmented or too coarse, correcting community-flow matches that seem implausible given known VIS-community history (e.g., a known research group), merging/splitting topics that don't align with domain knowledge, and re-running downstream steps. This mirrors the corrective, domain-knowledge-driven iteration explicit in UTOPIAN and SOMFlow, and is essential given the explicit requirement that "the analyst will need to inspect intermediate results visually and use domain knowledge to interpret patterns and make judgements at each stage."
Summary of Library Sources Used
- Reducing Snapshots to Points — windowed snapshot construction; projecting states to visualize evolution/stability/transitions.
- MobilityGraphs — full-period "supergraph" simplification prior to temporal clustering; calendar/temporal-cluster visualization pattern.
- NodeTrix — hybrid node-link/matrix visualization of dense co-authorship communities; validated on this exact data domain.
- EventThread — tensor-based latent "thread" tracking for entities across stages; inspiration for robust community-trajectory tracking beyond simple overlap.
- SOMFlow — iterative guided clustering with explicit provenance/flow-graph tracking.
- Human-Steered Topic Modelling (UTOPIAN) — interactive NMF topic modeling with merge/split/seed operations for research-foci extraction.
- Progressive Abstraction Analysis of Multivariate Temporal Data — episode-to-topic abstraction and matrix/small-multiples visualization of topic evolution across entities and time.
- StratomeX — overlap/band visualization and query-based comparison of multiple groupings ("stratifications").
- RelEx — matrix-based visualization for exposing significant relational patterns in a large relational structure, adapted here for community overlap.
- Temporal Event Sequence Simplification / IVESA — scarf-plot/timeline idiom adapted for author-level community-membership tracks.
Make a list of papers from which you have taken relevant approaches.
Workflow Library Sources for the Co-Authorship Community Analysis Task
Below is the list of papers/workflows from the library that I drew on for the recommended workflow, organized by the analytical function they informed.
Network Snapshotting and State-Space Projection
-
"Reducing Snapshots to Points: A Visual Analytics Approach to Dynamic Network Exploration" — van den Elzen, Holten, Blaas, and van Wijk (2016). IEEE TVCG. doi: 10.1109/TVCG.2015.2468078 — Source of the windowed-snapshot construction and the projection-based approach for visualizing network states as points/trajectories to detect stability, recurrence, and transitions.
-
"MobilityGraphs: Visual Analysis of Mass Mobility Dynamics via Spatio-Temporal Graphs and Clustering" — von Landesberger, Brodkorb, Roskosch, Andrienko, Andrienko, and Kerren (2016). IEEE TVCG. doi: 10.1109/TVCG.2015.2468111 — Source of the "full-period supergraph as anchor, then per-window analysis" pattern used to keep temporal simplification consistent.
Community/Entity Trajectory Tracking Over Time
- "EventThread: Visual Summarization and Stage Analysis of Event Sequence Data" — Guo, Xu, Zhao, Gotz, Zha, and Cao (2018). IEEE TVCG. doi: 10.1109/TVCG.2017.2745320 — Source of the tensor-decomposition "latent thread" concept adapted for robust community-trajectory tracking (merges, splits, persistence) beyond simple set-overlap matching.
Detailed Community Structure Visualization
- "NodeTrix: A Hybrid Visualization of Social Networks" — Henry, Fekete, and McGuffin (2007). IEEE TVCG. doi: 10.1109/TVCG.2007.70582 — Directly informs the hybrid node-link/matrix inspection of individual communities' internal structure (core-periphery, bridging authors); notably validated on InfoVis co-authorship data itself.
Iterative, Provenance-Tracked Clustering
- "SOMFlow: Guided Exploratory Cluster Analysis with Self-Organizing Maps and Analytic Provenance" — Sacha, Kraus, Bernard, Behrisch, Schreck, Asano, and Keim (2018). IEEE TVCG. doi: 10.1109/TVCG.2017.2744805 — Source of the iterative "propose → inspect → adapt → partition → track provenance" loop applied to the overall interface design and refinement cycle.
Topic Modeling and Research-Foci Extraction
-
"Human-Steered Topic Modelling" (UTOPIAN) — Choo, Lee, Reddy, and Park (2013). IEEE TVCG. doi: 10.1109/TVCG.2013.212 — Source of the interactive NMF-based topic modeling approach (merge/split/seed topics) used for extracting and refining research foci from titles/abstracts/keywords.
-
"Progressive Abstraction Analysis of Multivariate Temporal Data" (Episodes and Topics) — Andrienko, Andrienko, and Shirato (2023). Computer Graphics Forum. doi: 10.1111/cgf.14926 — Source of the episode-to-topic abstraction pattern and matrix/small-multiples visualization for tracking topic evolution across entities (here: communities) and time.
Overlap and Cross-Group Comparison
-
"Guided Visual Exploration of Genomic Stratifications in Cancer" (StratomeX) — Streit, Lex, Gratzl, Partl, Schmalstieg, Pfister, Park, and Gehlenborg (2014). Nature Methods. doi: 10.1038/nmeth.3088 — Source of the overlap-band/query-based comparison logic adapted for comparing community memberships across time periods.
-
"RelEx: Visualization for Actively Changing Overlay Network Specifications" — Sedlmair, Frank, Munzner, and Butz (2012). IEEE TVCG. doi: 10.1109/TVCG.2012.255 — Source of the matrix-based relational-pattern visualization adapted for the community-overlap matrix.
Timeline/Scarf-Plot Idiom for Individual Trajectories
-
"Temporal Event Sequence Simplification" — Monroe, Lan, Lee, Plaisant, and Shneiderman (2013). IEEE TVCG. doi: 10.1109/TVCG.2013.200 — Source of the aggregated event-sequence/scarf-plot idiom adapted for per-author community-membership timelines.
-
"IVESA – Visual Analysis of Time-Stamped Event Sequences" — Bernard et al. (2025). IEEE TVCG. doi: 10.1109/TVCG.2024.3382760 — Additional source for the overview-then-detail sequence timeline pattern used for author-level membership tracks.
Model Diagnosis/Explainability (Iterative Interpretation Loop)
- "explAIner: A Visual Analytics Framework for Interactive and Explainable Machine Learning" — Spinner et al. (2020). IEEE TVCG. doi: 10.1109/TVCG.2019.2934629 — Source of the general "understand → diagnose → refine" iterative loop used to structure the overall analyst interaction cycle in Phase 7.
You have designed a visual analytics workflow for a specific task, expressing it in natural language. In this second stage, I am now uploading the ATWL specification and one example workflow expressed in ATWL. Your task is to produce an ATWL representation of the workflow you designed in the previous stage.
This is not a mechanical translation. Please express your workflow in the ATWL vocabulary using its artifact types, transform intents, actor designations, loop constructs, and specification artifacts in the way that most faithfully captures the analytical process you described in your natural-language recommendation. Where your natural-language description implied structure that is naturally expressed as an ATWL construct (for example, an iterative refinement step that is naturally expressed as a loop with an assess transform and a specification artifact), please make this structure explicit in the ATWL representation.
At the same time, please be honest about what your original recommendation supports. If a phase of your workflow was described only as a linear sequence of steps without explicit iteration, without human-machine actor distinctions, or without specifications being updated, please do not fabricate these elements to make the ATWL representation appear more sophisticated. The goal is to represent, in ATWL, the workflow you actually designed, not a hypothetically enhanced version of it.
After you produce the ATWL representation, please briefly note any structural elements you added that were implicit in your original recommendation. This helps me understand the difference between what your original design communicated explicitly and what your ATWL representation makes explicit. If some structural elements in the ATWL are new additions rather than translations of what was already there, please say so.
Please read the ATWL specification and the example carefully before proceeding. Do you have any questions about the language or the syntax before you produce the ATWL representation?
identifying anchor communities from the full graph and then detecting communities within each time window using similarity and graph clustering methods. Phase 3 handles cross-temporal analysis by matching communities across windows, building a community-flow graph, then projecting and visualizing it with alluvial diagrams before abstracting patterns like merges, splits, and dissolutions. Phase 4 focuses on core stability by measuring author-level metrics like tenure and centrality, classifying authors into roles, and visualizing their trajectories through NodeTrix and timeline plots. Phase 5 extracts topics using term-document features and NMF modeling with human-in-the-loop refinement, then aggregates topic profiles across community-time combinations.
Now I'm visualizing topic evolution through matrices and small multiples, then identifying high-overlap author pairs in Phase 6. The whole system needs an integrated iterative loop where I can adjust community detection resolution and other specifications based on assessment, cycling through refinement until I reach final knowledge generation. I'm thinking about how to represent this workflow comprehensively but concisely—probably using a template that chains intents, artifacts, and transforms for each phase, with explicit loops for human-guided iteration.
I'm now layering in author-level analysis: characterizing metrics like tenure and centrality to classify authors as core, peripheral, or boundary-spanning, then visualizing these with node-link diagrams and timelines. Alongside this, I'm building a topic model iteratively, assessing it, and updating the specification based on what emerges. Then I'm profiling topics within each community-period combination, visualizing the evolution matrix, and finally characterizing the pairwise overlap to generate the complete knowledge artifact. The complexity is substantial, so I'll structure this as a full ATWL document with clearly defined phases, artifacts, and transforms, starting with the input data schema.
Defining the papers dataset with its core fields...
I need to establish authors as explicit entities first since they're the primary analytical objects for the network analysis, rather than treating them as derived from papers. ows to capture temporal evolution of the network. I'm defining the co-authorship feature as a weighted graph where edge weights represent the number of joint papers across the full 1990-2024 period, which serves as the baseline structure for detecting communities over time. I'm reconsidering whether this feature should be indexed by windows rather than authors, since the graphs themselves are per-window snapshots. I'll redefine it as a feature of D_windows where each window contains a weighted co-authorship graph with nodes representing only the authors active in that period.
Now moving into phase 2, I need to apply community detection to the full-period co-authorship graph using an algorithm like Louvain or Leiden to establish a stable reference partition. This transform takes the complete author network and produces anchor communities along with membership assignments, which will serve as the baseline for comparing temporal variations.
Then I'm doing the same community detection process independently on each windowed snapshot to capture how collaborations shift over time—identifying short-lived groups, splinters, and emerging alliances that wouldn't show up in the full-period analysis.
Now moving into Phase 3, where I need to match communities across time windows to track their evolution, build a flow graph showing how they merge, split, or persist, and identify the key events that characterize their lifecycle. Defining the overlap characterization transform...
Now I'm thinking about how to contextualize the flow—embedding each community-window pair into a 2D space based on member and topic similarity, then arranging them temporally using an alluvial layout. Actually, these might work better as two separate transforms since they produce distinct visualizations rather than combining them into one.
Defining the projection transform... Defining the visualization transform that renders the alluvial diagram alongside a 2D projection scatterplot, showing community evolution with ribbons representing flows and trails connecting matched states across time windows. Continuing to define the knowledge generation transform, where I'm formulating statements about the long-run community structure—how many distinct communities persist, when and why they merge or split—and capturing these conclusions as structured knowledge artifacts.
Now moving into phase 4, I'm computing author-level metrics like tenure across windows, their centrality within communities, and how many different communities they've participated in over time. Then I'll classify authors by similarity based on these characteristics. Now I'm defining a visualization that combines node-link and matrix representations for a selected community period, showing the dense collaboration core as an adjacency matrix while rendering bridging ties between communities as node-link edges to reveal leadership and boundary-spanning patterns.
Next, I'm creating a timeline visualization where each author appears as a horizontal track with colored segments representing their community membership across time windows, with gaps showing periods of inactivity.
Then I need to interpret these patterns to identify which authors are stable core members or leaders within communities versus those who move between groups or bridge different communities.
Now I'm formulating conclusions about the stability and leadership structure of each community based on these patterns, capturing which ones have consistent cores and which experience significant turnover. Moving into the next phase, I'm beginning to characterize the text features of the papers by encoding them into a term-document representation...
Building the term-document matrix from paper titles, abstracts, and keywords to create a numeric feature representation for topic modeling. I'll also need the initial topic specification with parameters like the number of topics and seed terms that the analyst provides, then enter an iterative refinement loop where I can steer the NMF topic model interactively until the topics align with what we know about VIS research areas. Continuing to define the visualization and assessment steps—I'm creating an interface that displays the top terms for each topic along with representative documents, then having a human evaluate whether the topics are coherent and distinct enough, or if they need to be merged, split, or adjusted with new seeds. artifact F_topic_profiles : feature-set representation form: "topic mixture vectors per community-period" description: "Aggregated topic distributions characterizing each episode"
Now I'm setting up a visualization that displays how these topic profiles evolve across communities and time windows, using either a matrix layout with communities on one axis and time on the other, or small-multiples panels, rendered as stacked bars or heatmap cells to show the composition of topics.
Then I need to have a human step in to interpret these patterns—assigning meaningful labels to the dominant topics in each community-period and tracking how the research focus shifts over time, which produces a set of named research foci with their temporal trajectories.
From those labeled patterns, I formulate conclusions about what each community's main research directions are and how they've evolved, creating knowledge statements about community-specific research foci.
Now moving into phase 6, I'm computing pairwise overlap matrices for each time window to characterize how much membership overlap exists between communities... aph with one heatmap per time window, showing cell color intensity representing the degree of shared authorship between community pairs. I'm then identifying persistently high-overlap community pairs as candidates for potential merging or loss of distinctiveness, ranking them by salience.
For Phase 7, I'm framing this as an integrated iterative loop where I can adjust community-detection resolution or window size and re-run the entire pipeline. I need to add a specification artifact at the detection phase that can be updated based on overall assessment results, creating an outer loop that wraps the community-detection and matching phases. Wrapping the entire analytical workflow in an outer refinement loop makes sense—the assess transform evaluates whether the detected communities, stability patterns, and topics meet quality standards, and if not, it updates the detection specifications and reruns the downstream phases. This directly mirrors the iterative process described: adjusting resolution, window size, and thresholds, then reexecuting. I'll structure the final ATWL with input declarations, Phase 0 for author and graph setup, then Phase 1 onward consuming the detection specification. I'm settling on a more linear structure to keep things manageable: defining units for authors and windows with their characterizations, then a loop that handles anchor detection, community characterization, and overlap analysis, feeding into a final knowledge synthesis step that answers the analyst's questions. The community-detection loop wraps around the windowing, community-finding, and event-matching phases since those are what get refined when adjusting resolution or window size. Topics and stability patterns follow as downstream analyses that mostly run once, though I should note the topic refinement loop in phase 5 handles any merging or splitting needed there.
Now I'm laying out the full ATWL structure systematically—I need to define the specification artifacts like the detection spec (window size, overlap, resolution parameters) and topic spec that gets refined iteratively. For the entity embeddings, I'm thinking through how papers should be represented: they have internal structure but the key embeddings are really about the author set and publication year as identifying features, though I need to be careful about what counts as an embedment versus a feature attribute. I'll include citations as a documented input field even though it won't be used in the analysis—that's fine since the task specifies it's part of the data schema. For D_papers embedment, I'm settling on {set, time} since papers form an unordered collection organized along the calendar time axis.
Now I'm thinking through D_authors: they're derived from D_papers through extraction, and while they're embedded in time (representing career spans across years), they also form a relational structure through co-authorship networks—which I'd characterize separately as a relational configuration feature rather than part of the embedment itself. So the network itself should be captured as a separate feature with relational configuration value structure, since the spec explicitly calls for this when relations between entities are characterized. This means embedment reflects the data-level positioning of authors in time and network structure, while a distinct characterize transform produces the relational configuration feature that explicitly models the co-authorship relations.
For the remaining data entities: windows are episodes bounded in time with features like span and ID; anchor communities are author groups partitioned by set embedment; window communities are groups situated in both set and time with size and window reference features; author roles are clustered groups with set embedment; and the state space is a computed context representing the 2D projection, which doesn't have traditional embedment since it's a single derived object rather than a collection.
The text features form a term-document matrix over the papers, which aligns with the matrix representation pattern from the example spec. Now I need to work through the transforms, which are numerous.
I'm planning to structure the ATWL document with clear sections for Phases 0 through 7, incorporating two explicit loops—one for community-detection refinement and another for topic refinement—followed by a final assessment and knowledge synthesis phase. I'll stick to what was in the original design rather than adding extra loops, and I'll note in the closing remarks where I've made structural clarifications, like formalizing the community-detection iteration that was described informally in the original text.
For Phase 7, I'm modeling the analyst's iterative process as an outer loop that wraps community detection, matching, and topic modeling, with assessment and conditional specification updates—this directly reflects what the original text described about adjusting resolution, correcting matches, and merging or splitting topics before re-running downstream steps. The full loop cycles through community detection and matching, then assesses whether the results are well-resolved and plausible—if not, I adjust the detection parameters like window size or resolution, or manually correct flow matches, then loop back. I'm treating manual correction as a form of specification adjustment too. Now I'll write out the complete algorithm with consistent IDs and phase headers, and I'm considering whether to include actor annotations since many steps involve machine-generated data.
I'm mapping out which steps are purely machine-driven (graph algorithms, matrix computations), which are human-driven (interpretation, assessment, labeling), and which are hybrid—like window partitioning where the analyst chooses the scheme but the system implements it computationally, or role classification where humans set thresholds but machines compute them. The assessment phases lean heavily on domain judgment and human inspection, so those stay marked as human-led. Restructuring the outer loop to include an assessment step that checks whether the community partition is appropriately granular and the flow matches are plausible, then conditionally refines the parameters if needed. I should move T_abstract_events inside the loop before the assessment step so it can evaluate the plausibility of identified events, then generate the final knowledge representation after the loop converges. The loop body should sequence the partitioning, graph construction, and community anchoring operations in order. If refinement is needed, I loop back to adjust the detection spec and reassign it; otherwise I exit. After the loop converges, I generate the final knowledge evolution using the accumulated events. This mirrors the example's pattern of iterating through cluster-project-visualize-interpret-assess-refine cycles. Phase 4 then proceeds linearly using the final community data from the last iteration. So the artifacts that get recomputed each iteration—like D_window_communities and F_window_membership—don't need explicit reassignment since they're regenerated fresh from the updated S_detection_spec through the transform. Only S_detection_spec itself needs to be reassigned since it's the refined parameter carrying forward to the next iteration. After the loop exits, I can reference those final computed artifacts directly. After the community-structure loop, Phase 4 will use the final window communities and coauthor data as inputs for its linear transforms. Then Phase 5 handles topic modeling with its own refinement loop, followed by Phase 6 for the overlap matrix. Finally, the synthesis step combines the evolution, stability, and focus artifacts to answer the analyst's core questions about community count and characteristics. evolving the workflow template to capture the full analytical pipeline—starting with author characterization across the complete period, then iterating through time windows to track community dynamics and overlap, followed by stability analysis through tenure and centrality metrics, and finally topic modeling to extract research focus patterns, all synthesized into integrated findings about community structure and evolution. I need to verify that each transform has proper intent declarations and input references, then define the specification artifacts for detection and topic analysis. I'll also need to establish the author data features like active years. Let me assemble the full document now, keeping descriptions concise while maintaining completeness for the template format. T_char_window_graphs should be recomputed each iteration since D_windows changes, making it dependent on the loop variable. Now I'm ready to write out the full ATWL text. The workflow structure is valid—S_detection_spec gets reassigned each iteration while other identifiers are implicitly regenerated with fresh values, which aligns with the pattern where identifiers maintain consistent names across iterations but their values change. I need to add disclaimers about the structural choices I made: the community-detection loop is now explicit rather than implicit, the topic-refinement loop was already there in UTOPIAN's iterative nature, I've assigned actor roles based on the human/machine distinctions described, and I've treated D_authors as a first-class entity even though the original text only mentioned "authors" without formally declaring an extraction step. I should also note that Phases 4 and 6 remain linear as originally described—no loops were added there, though I did make the abstract-and-generate-knowledge pairing more explicit in Phase 4 where the original just said "let the analyst answer how stable is the core."
Before producing the ATWL specification, I read both documents carefully. I have no open questions about the syntax — the artifact types, transform intents/manners, actor field, loop/conditional/assignment constructs, and template notation are clear, and the worked example (behaviour-pattern-recognition-in-time-series) gives me a good model for how to structure a multi-phase, loop-containing workflow. I'll now express my Phase 0–7 recommendation in ATWL, staying as faithful as possible to what I actually described, and flagging additions at the end.
workflow vis-coauthorship-community-evolution
template: define-unit (authors) -> characterise (full-period co-authorship) ->
loop(define-unit (windows) -> characterise (per-window co-authorship) ->
define-unit (anchor + per-window communities) ->
characterise (cross-time overlap/flow) ->
contextualise (state projection + flow layout) ->
visualise -> abstract (evolution events) -> assess) ->
generate-knowledge (evolution findings) ->
characterise (author tenure/centrality/cross-membership) ->
define-unit (author roles) ->
visualise (NodeTrix + author timelines) ->
abstract (stability patterns) -> generate-knowledge (stability findings) ->
characterise (text features) ->
loop(build-model (topic model) -> visualise -> assess) ->
characterise (topic profiles per community-period) ->
visualise (topic evolution) -> abstract (research foci) ->
generate-knowledge (foci findings) ->
characterise (pairwise overlap matrix) -> visualise (overlap matrix) ->
abstract (overlap patterns) ->
generate-knowledge (integrated synthesis)
description: "Visual analytics workflow for identifying and characterising the
intellectual communities of the IEEE VIS co-authorship network, tracking
their core stability, membership drift, merge/split/dissolution events, and
associated research foci across 1990-2024"
# ============================================================================
# INPUT
# ============================================================================
artifact D_papers : entities
origin: given
internal structure: elementary
embedment: {set, time}
features:
- id: f_authors
value structure: list
value type: reference
description: "Disambiguated author IDs"
- id: f_year
value structure: atomic
value type: temporal
description: "Publication year"
- id: f_title
value structure: atomic
value type: text
- id: f_abstract
value structure: atomic
value type: text
- id: f_keywords
value structure: list
value type: text
- id: f_citations
value structure: list
value type: reference
description: "Citation links (provided but not used in this workflow)"
description: "3596 IEEE VIS papers (Vis/InfoVis/VAST/SciVis), 1990-2024"
# ============================================================================
# PHASE 0: DEFINE AUTHORS AND FULL-PERIOD CO-AUTHORSHIP NETWORK
# ============================================================================
transform T_define_authors :
intent: define-unit
manner: "extract"
input: D_papers
output: D_authors
actor: machine
description: "Extract distinct disambiguated authors as analysis units"
artifact D_authors : entities
internal structure: elementary
embedment: {time, relational structure}
features:
- id: f_active_years
value structure: list
value type: temporal
description: "Years in which the author published"
description: "Distinct disambiguated authors, situated in publication time
and in the co-authorship network"
transform T_char_coauthor_full :
intent: characterise
manner: "define-relations (co-authorship, full period)"
input: D_authors, D_papers
output: F_coauthor_full
actor: machine
description: "Compute weighted co-authorship relation across the full
1990-2024 period, edge weight = number of joint papers"
artifact F_coauthor_full : feature(D_authors)
value structure: relational configuration
value type: numeric
representation form: "weighted co-authorship graph, full period (anchor structure)"
description: "Full-period network used to anchor long-run community structure"
# ============================================================================
# SPECIFICATION: COMMUNITY-DETECTION PARAMETERS
# ============================================================================
artifact S_detection_spec : specification
origin: given
representation form: "parameter settings (window length, window step,
community-detection algorithm and resolution)"
description: "Initial analyst-defined choices governing temporal windowing
and community-detection granularity"
# ============================================================================
# PHASE 1-3 (LOOPED): WINDOWING, COMMUNITY DETECTION, CROSS-TIME MATCHING
# ============================================================================
loop L_community_structure:
purpose: "Refine temporal windowing and community-detection resolution
until communities are neither too fragmented nor too coarse, and
community-flow matches (persistence/merge/split/dissolution) are
plausible given domain knowledge of the VIS community"
until: "Community partition granularity and cross-time matches are judged
adequate by the analyst"
body:
transform T_partition_windows :
intent: define-unit
manner: "time-partitioning with overlapping windows"
input: D_papers, S_detection_spec
output: D_windows
actor: hybrid
description: "Partition 1990-2024 into overlapping time windows
(e.g. 5-year windows advancing by 1-2 years)"
artifact D_windows : entities
internal structure: episode
embedment: time
features:
- id: f_window_span
value structure: atomic
value type: temporal
description: "Start and end year of the window"
description: "Overlapping time windows over the publication period"
transform T_char_window_graphs :
intent: characterise
manner: "define-relations (co-authorship, per window)"
input: D_authors, D_papers, D_windows
output: F_coauthor_windows
actor: machine
description: "Compute weighted co-authorship subgraph restricted to
authors/papers active within each window"
artifact F_coauthor_windows : feature(D_windows)
value structure: relational configuration
value type: numeric
representation form: "weighted co-authorship graph per window"
description: "Sequence of comparable network snapshots"
transform T_anchor_communities :
intent: define-unit
manner: "cluster-by-similarity (graph community detection, full period)"
input: D_authors, F_coauthor_full, S_detection_spec
output: D_anchor_communities, F_anchor_membership
actor: machine
description: "Detect long-term reference communities from the
full-period network"
artifact D_anchor_communities : entities
internal structure: group/cluster
embedment: set
features:
- id: f_size
value structure: atomic
value type: numeric
description: "Long-run reference communities of collaborating authors"
artifact F_anchor_membership : feature(D_authors)
value structure: atomic
value type: categorical
description: "Anchor-community label per author"
transform T_window_communities :
intent: define-unit
manner: "cluster-by-similarity (graph community detection, per window)"
input: D_authors, F_coauthor_windows, S_detection_spec
output: D_window_communities, F_window_membership
actor: machine
description: "Detect communities independently within each windowed
snapshot, capturing short-lived alliances and emerging groups"
artifact D_window_communities : entities
internal structure: group/cluster
embedment: {set, time}
features:
- id: f_size
value structure: atomic
value type: numeric
- id: f_window
value structure: atomic
value type: reference
description: "Per-window communities of collaborating authors"
artifact F_window_membership : feature(D_authors)
value structure: atomic
value type: categorical
description: "Per-window community label per author (varies by window)"
transform T_char_overlap :
intent: characterise
manner: "define-relations (membership overlap across adjacent windows)"
input: D_window_communities, F_window_membership
output: F_community_flow
actor: machine
description: "Compute weighted overlap of author membership between
communities in adjacent/overlapping windows"
artifact F_community_flow : feature(D_window_communities)
value structure: relational configuration
value type: numeric
representation form: "directed weighted graph linking (community,window)
pairs by membership overlap"
description: "Community-flow structure capturing persistence, split,
merge, emergence, dissolution"
transform T_project_states :
intent: contextualise
manner: "projection-based (community-state embedding)"
input: D_window_communities, F_community_flow
output: D_state_space, A_state_projection
actor: machine
description: "Embed each (community,window) state in 2D by member/topic
similarity to reveal stable regimes vs. transient states"
artifact D_state_space : entities
internal structure: elementary
features:
- id: f_dimensions
value structure: atomic
value type: numeric
description: "Computed 2D projection space for community-window states"
artifact A_state_projection : arrangement(D_window_communities)
context: D_state_space
principle: "similarity-preserving projection of member/topic vectors"
description: "Layout where proximity indicates persistence across windows"
transform T_arrange_flow :
intent: contextualise
manner: "flow/alluvial arrangement based on temporal order and overlap"
input: D_window_communities, F_community_flow, D_windows
output: A_flow_layout
actor: machine
description: "Arrange communities along the temporal axis with ribbon
widths determined by overlap weights"
artifact A_flow_layout : arrangement(D_window_communities)
context: D_windows
principle: "alluvial/stream layout ordered by time window, ribbon width
by overlap weight"
description: "Temporal arrangement suitable for visualising merges,
splits, and dissolutions"
transform T_vis_evolution :
intent: visualise
manner: "coordinated alluvial diagram and projection scatterplot"
input: A_flow_layout, A_state_projection, F_community_flow
output: V_evolution
actor: machine
description: "Render community-flow as alluvial diagram alongside a 2D
state-projection scatterplot with trails linking matched states"
artifact V_evolution : visualisation(A_flow_layout, A_state_projection, F_community_flow)
layout: "alluvial diagram; 2D projection scatterplot"
form: "stream ribbons; coloured points with trails"
encoding: "ribbon width/position from F_community_flow; point position
from A_state_projection; trails connect matched states across windows"
description: "Overview for detecting persistent, merging, splitting,
emerging, and dissolving communities"
transform T_abstract_events :
intent: abstract
manner: "perception-and-interpretation of evolution events"
input: V_evolution, F_community_flow
output: P_evolution_events
actor: human
description: "Visually identify and classify evolution events
(persist/split/merge/emerge/dissolve) per community trajectory"
artifact P_evolution_events : pattern(D_window_communities)
representation form: "labelled event templates (persist/split/merge/
emerge/dissolve) per community trajectory"
description: "Identified structural evolution events"
transform T_assess_structure :
intent: assess
manner: "judge community granularity and match plausibility"
input: V_evolution, P_evolution_events
output: K_structure_quality
actor: human
description: "Judge whether communities are appropriately resolved and
whether identified merge/split/dissolution matches are plausible
given domain knowledge of the VIS community"
artifact K_structure_quality : knowledge(D_window_communities, P_evolution_events)
representation form: "quality judgment"
description: "Assessment of whether resolution/windowing needs adjustment"
if K_structure_quality indicates refinement needed:
then:
transform T_refine_detection_spec :
intent: generate-knowledge
manner: "formulate methodological adjustment"
input: K_structure_quality, S_detection_spec
output: S_detection_spec_r
actor: human
description: "Adjust window size/step, clustering algorithm or
resolution parameter based on assessment"
artifact S_detection_spec_r : specification
representation form: "updated parameter settings"
description: "Refined temporal-windowing and community-detection
configuration"
assign:
S_detection_spec := S_detection_spec_r
else:
exit loop L_community_structure
end loop L_community_structure
transform T_knowledge_evolution :
intent: generate-knowledge
manner: "formulate-statements"
input: P_evolution_events, V_evolution
output: K_evolution
actor: human
description: "Formulate conclusions about the number of distinct long-run
communities and when/how they merged, split, or dissolved"
artifact K_evolution : knowledge(P_evolution_events, D_window_communities)
representation form: "statements"
description: "Conclusions about community count and evolution events"
# ============================================================================
# PHASE 4: CORE STABILITY AND LEADERSHIP
# ============================================================================
transform T_char_author_metrics :
intent: characterise
manner: "compute-statistics (tenure, centrality, cross-membership)"
input: D_authors, F_window_membership, F_coauthor_windows
output: F_author_metrics
actor: machine
description: "Compute per-author tenure (fraction of windows in a given
community), within-community centrality per window, and count of
distinct communities occupied over the full period"
artifact F_author_metrics : feature(D_authors)
value structure: vector
value type: numeric
description: "Tenure, centrality, and cross-membership count per author"
transform T_classify_authors :
intent: define-unit
manner: "rule-based classification (core / peripheral / boundary-spanning)"
input: D_authors, F_author_metrics
output: D_author_roles, F_role_label
actor: hybrid
description: "Classify authors into core (high tenure+centrality),
peripheral/transient, and boundary-spanning (multi-community) roles"
artifact D_author_roles : entities
internal structure: group/cluster
embedment: set
description: "Groups of authors sharing the same structural role"
artifact F_role_label : feature(D_authors)
value structure: atomic
value type: categorical
description: "Assigned role label per author"
transform T_vis_nodetrix :
intent: visualise
manner: "node-link/matrix hybrid (NodeTrix)"
input: D_window_communities, F_coauthor_windows, F_role_label
output: V_nodetrix
actor: machine
description: "For a selected community-period, render the dense
collaboration core as an adjacency matrix and bridging ties as
node-link edges"
artifact V_nodetrix : visualisation(D_window_communities, F_coauthor_windows, F_role_label)
layout: "hybrid node-link and matrix"
form: "adjacency matrix blocks for dense cores; node-link edges for
inter-community ties"
encoding: "matrix cell = intra-core edge weight; node colour = role label;
external edges = bridging ties"
description: "Detailed core-periphery/leadership structure of one community"
transform T_vis_author_timeline :
intent: visualise
manner: "scarf-plot / event-sequence timeline per author"
input: D_authors, F_window_membership, D_windows
output: V_author_timeline
actor: machine
description: "Render each author as a track with coloured segments
indicating community membership per window"
artifact V_author_timeline : visualisation(D_authors, F_window_membership, D_windows)
layout: "aligned horizontal timelines, one row per author"
form: "coloured segments"
encoding: "row = author; horizontal position = time window; colour =
community membership"
description: "Author-level view of membership stability and drift"
transform T_abstract_stability :
intent: abstract
manner: "perception-and-interpretation of stability/leadership patterns"
input: V_nodetrix, V_author_timeline, F_author_metrics
output: P_stability_patterns
actor: human
description: "Identify stable cores/leaders per community and members who
move between or span multiple communities"
artifact P_stability_patterns : pattern(D_authors, D_window_communities)
representation form: "labelled roles with textual descriptions"
description: "Core stability, leadership, and drift characterisation"
transform T_knowledge_stability :
intent: generate-knowledge
manner: "formulate-statements"
input: P_stability_patterns
output: K_stability
actor: human
description: "Formulate conclusions about core stability and leadership
per community"
artifact K_stability : knowledge(P_stability_patterns)
representation form: "statements"
description: "Conclusions on which communities have stable cores/leaders
and which show high turnover"
# ============================================================================
# PHASE 5: RESEARCH FOCI (HUMAN-STEERED TOPIC MODELLING)
# ============================================================================
transform T_char_text_features :
intent: characterise
manner: "encode (term-document representation)"
input: D_papers
output: F_text_features
actor: machine
description: "Build term-document matrix from titles, abstracts, and keywords"
artifact F_text_features : feature(D_papers)
value structure: matrix
value type: numeric
representation form: "term-document matrix"
description: "Textual representation of papers for topic modelling"
artifact S_topic_spec : specification
origin: given
representation form: "parameter settings (number of topics, seed terms)"
description: "Initial topic-model configuration"
loop L_topic_refinement:
purpose: "Interactively steer the NMF topic model until topics are
coherent, non-redundant, and align with recognisable VIS research areas"
until: "Topics are judged coherent and interpretable"
body:
transform T_build_topic_model :
intent: build-model
manner: "fit-topic-model (NMF)"
input: F_text_features, S_topic_spec
output: M_topic_model
actor: machine
description: "Fit NMF topic model using current specification"
artifact M_topic_model : model(F_text_features)
model type: "topic model"
representation form: "matrix factorisation (W,H)"
description: "NMF-based topic model of the paper corpus"
transform T_vis_topics :
intent: visualise
manner: "topic term/document display"
input: M_topic_model
output: V_topics
actor: machine
description: "Display top terms per topic and representative documents"
artifact V_topics : visualisation(M_topic_model)
layout: "ranked term lists with representative documents"
form: "ranked term lists, document excerpts"
encoding: "topic weight -> term rank; document-topic weight ->
representative document selection"
description: "Interface for inspecting the current topic decomposition"
transform T_assess_topics :
intent: assess
manner: "judge topic coherence and interpretability"
input: V_topics
output: K_topic_quality
actor: human
description: "Judge whether topics are coherent, distinct, and align
with known VIS research areas"
artifact K_topic_quality : knowledge(M_topic_model)
representation form: "quality judgment"
description: "Assessment of topic coherence/redundancy"
if K_topic_quality indicates refinement needed:
then:
transform T_refine_topic_spec :
intent: generate-knowledge
manner: "formulate methodological adjustment (merge/split/seed topics)"
input: K_topic_quality, S_topic_spec
output: S_topic_spec_r
actor: human
description: "Merge redundant topics, split overly broad ones, or
seed new topics from representative terms/documents"
artifact S_topic_spec_r : specification
representation form: "updated parameter settings and seed constraints"
description: "Refined topic-model configuration"
assign:
S_topic_spec := S_topic_spec_r
else:
exit loop L_topic_refinement
end loop L_topic_refinement
transform T_char_topic_profiles :
intent: characterise
manner: "aggregate (topic-mixture per community-period)"
input: D_window_communities, M_topic_model, D_papers
output: F_topic_profiles
actor: machine
description: "Aggregate topic-mixtures of papers authored within each
community-period into a single topic profile"
artifact F_topic_profiles : feature(D_window_communities)
value structure: vector
value type: numeric
description: "Topic-mixture (research-foci) profile per community-window"
transform T_vis_topic_evolution :
intent: visualise
manner: "matrix / small-multiples"
input: F_topic_profiles, D_window_communities, D_windows
output: V_topic_evolution
actor: machine
description: "Visualise topic-profile distributions across communities
and time"
artifact V_topic_evolution : visualisation(F_topic_profiles, D_window_communities, D_windows)
layout: "matrix (community x time) / small multiples"
form: "stacked bars or heatmap cells"
encoding: "rows = communities; columns = time windows; cell content =
topic-mixture profile"
description: "Display of research-foci evolution per community"
transform T_abstract_foci :
intent: abstract
manner: "name-patterns"
input: V_topic_evolution, F_topic_profiles
output: P_research_foci
actor: human
description: "Assign descriptive labels to dominant topics per
community-period and identify foci shifts over time"
artifact P_research_foci : pattern(D_window_communities)
representation form: "labelled topic descriptions per community-period"
description: "Named research foci and their temporal evolution"
transform T_knowledge_foci :
intent: generate-knowledge
manner: "formulate-statements"
input: P_research_foci
output: K_foci
actor: human
description: "Formulate conclusions about each community's main research
foci and how they evolved"
artifact K_foci : knowledge(P_research_foci)
representation form: "statements"
description: "Conclusions about community-specific research foci and
their evolution"
# ============================================================================
# PHASE 6: CROSS-COMMUNITY MEMBERSHIP OVERLAP
# ============================================================================
transform T_char_overlap_matrix :
intent: characterise
manner: "define-relations (pairwise membership overlap within a window)"
input: D_window_communities, F_window_membership
output: F_overlap_matrix
actor: machine
description: "For each window, compute a pairwise overlap matrix among
communities based on shared author membership"
artifact F_overlap_matrix : feature(D_window_communities)
value structure: matrix
value type: numeric
representation form: "pairwise community overlap matrix per window"
description: "Cross-community membership overlap"
transform T_vis_overlap :
intent: visualise
manner: "matrix-plot"
input: F_overlap_matrix
output: V_overlap
actor: machine
description: "Display community x community overlap matrix per window"
artifact V_overlap : visualisation(F_overlap_matrix)
layout: "matrix grid, selectable per time window"
form: "heatmap cells"
encoding: "cell colour intensity = degree of shared authorship"
description: "Overview for detecting high-overlap community pairs and
their change over time"
transform T_abstract_overlap :
intent: abstract
manner: "find-salient-groups"
input: V_overlap
output: P_overlap_patterns
actor: human
description: "Identify community pairs with persistently high overlap,
candidates for merging or loss of distinctiveness"
artifact P_overlap_patterns : pattern(D_window_communities)
representation form: "ranked list of high-overlap community pairs"
description: "Salient overlap relationships between communities across time"
# ============================================================================
# FINAL SYNTHESIS
# ============================================================================
transform T_final_synthesis :
intent: generate-knowledge
manner: "formulate-statements (integrated synthesis)"
input: K_evolution, K_stability, K_foci, P_overlap_patterns
output: K_findings
actor: human
description: "Synthesise conclusions across community evolution, core
stability/leadership, research foci, and cross-community overlap"
artifact K_findings : knowledge(D_window_communities, D_authors)
representation form: "statements and structured summary"
description: "Integrated findings: number/identity of major communities,
core stability and leadership, research foci and their evolution,
membership overlap and its change over time, and merge/split/
dissolution events with plausible interpretations"
Notes on structural elements made explicit or added
Faithful translations (structure was present in the original, now made explicit):
- The two loop constructs (L_community_structure, L_topic_refinement) correspond directly to iterative behaviors I described in prose — Phase 7's "the analyst iterates: adjusting the community-detection resolution or window size... re-running downstream steps" and Phase 5's UTOPIAN-style interactive merge/split/seed cycle.
- Human/machine/hybrid actor distinctions reflect the roles I described (e.g., algorithmic clustering = machine, visual interpretation/domain judgement = human, window-scheme choice or role classification = hybrid).
- The assess → conditional → specification-update pattern in both loops is a direct structuring of what I described informally.
Additions made for ATWL completeness (not explicit, or only implicit, in the original prose):
1. T_define_authors as an explicit define-unit step: my original text spoke of "authors" and a "co-authorship graph" throughout but never explicitly described extracting the author entity set from paper records as a discrete step.
2. Scoping of L_community_structure: I explicitly bundled window partitioning, both community-detection calls, and cross-time matching inside one loop governed by a single S_detection_spec. My original Phase 7 described this iteration only in general terms ("adjusting resolution or window size... correcting matches"); I made a concrete decision about exactly which steps recompute on each iteration.
3. Separate generate-knowledge transforms per phase (K_evolution, K_stability, K_foci) and a final synthesis transform (T_final_synthesis/K_findings): my original description discussed these as questions to be answered but did not explicitly separate "abstraction" from "knowledge formulation" as distinct steps in Phases 4 and 6 the way it did for Phase 3 (events) and Phase 5 (topics). I added them for consistency and to close the workflow with an explicit answer to the analyst's original questions.
4. Omitted: the EventThread tensor-decomposition alternative I mentioned as a conditional fallback ("if community identities look ambiguous... consider EventThread's tensor approach directly") is not represented as a branch in this ATWL — it was a hedged, optional suggestion in the original text, not a committed part of the design, so I did not fabricate a conditional path for it.
5. Citations feature on D_papers is declared (matching the task's data description) but never consumed by any transform — this is an honest reflection that my original workflow did not use citation data.
Thank you. As a separate reflection: now that you have expressed this workflow in ATWL and worked through its structural elements, are there aspects of the workflow that thinking in ATWL terms suggests could be improved? For example, are there phases where the ATWL framing revealed missing structural elements (unnamed loops without specifications, ambiguous actor roles, implicit criteria that should be externalised as specifications) that would strengthen the workflow if added?
Please describe any such improvements separately as recommended modifications, not as changes to the ATWL representation you just produced. If ATWL thinking has not revealed anything worth modifying, please say so.
The community structure loop is where things get complex. It's bundling together window partitioning, anchor detection, per-window detection, overlap computation, projection, visualization, event abstraction, and assessment all in one iteration—that's quite heavy and means every cycle recomputes everything from scratch. I'm realizing this might actually need to be split into two separate loops: one for tuning the structural parameters like window size and detection algorithm, and another for refining the overlap threshold used to match communities across time. I conflated these into a single "S_detection_spec" artifact, but the overlap threshold for temporal matching is really a distinct parameter that deserves its own specification element in the representation.
Looking back at the formalization, I notice S_detection_spec doesn't explicitly include the overlap threshold, and T_char_overlap doesn't take S_detection_spec as input—that's an inconsistency I should fix. The natural language description mentioned adjusting the overlap threshold, but I never gave it proper representation in the formal structure.
There's also an actor ambiguity with T_partition_windows that I marked as "hybrid," but I'm questioning whether choosing window size is really hybrid or just human specification plus mechanical application. The other transforms like T_anchor_communities and T_window_communities are clearly "machine" given a spec, so T_partition_windows should probably be "machine" too since the window scheme comes directly from the specification—the human decision happens in the assess and refine step afterward.
Reflecting on the ATWL representation, several genuine structural gaps and ambiguities emerged that were not obvious when the workflow was described in prose. These are recommendations for how the design could be strengthened — I am not editing the ATWL I already produced.
1. Implicit classification thresholds should be externalised as specifications
Two places in the workflow perform rule-based classification whose criteria are never made explicit:
T_classify_authors(Phase 4) sorts authors into core/peripheral/boundary-spanning based on "high tenure + high centrality," but what counts as "high" is left implicit inside the transform'smannerdescription rather than being a named, inspectable artifact.T_abstract_events(Phase 3) labels community trajectories as persist/split/merge/emerge/dissolve, but the overlap threshold that distinguishes, say, a "split" from noisy attrition is buried inside human judgment rather than stated anywhere.
Both should be backed by explicit specification artifacts (e.g., S_role_thresholds, S_event_classification_spec). This would make the classification criteria visible, arguable, and — importantly — tunable through the same assess/refine mechanism already used for S_detection_spec and S_topic_spec. Right now these two classification steps look like one-off human judgments, when in fact they are exactly the kind of threshold-dependent decision ATWL's specification artifact is designed to surface.
2. Actor-role inconsistency
T_partition_windows is marked hybrid, but given that the window scheme is fully determined by S_detection_spec, the transform itself is a mechanical application of given parameters — it should be machine. The human judgment about window size belongs entirely to the assess/refine step that follows, not to the partitioning step itself. Working through the ATWL forced this distinction; in prose, "hybrid" felt like a safe default for anything involving a parameter, but ATWL's actor field is meant to describe who executes this specific transform, not who set the upstream parameters.
3. Phases 4 and 6 lack the iterative structure the task actually requires
Only Phase 3 (community detection) and Phase 5 (topic modelling) were given explicit assess-and-refine loops. But the analyst's stated need — "inspect intermediate results visually and use domain knowledge... at each stage" — applies just as much to:
- Phase 4, where the core/leader classification and NodeTrix inspection could easily reveal that the tenure/centrality thresholds are wrong, prompting reclassification;
- Phase 6, where the overlap-matrix inspection could reveal that the granularity of D_window_communities itself needs adjusting.
My original natural-language description did gesture at this in the "integrated interface" section (Phase 7: "adjusting resolution... correcting matches... merging/splitting topics"), but when formalised, that cross-cutting iteration collapsed into just the two loops that had an obvious single output artifact to refine (S_detection_spec, S_topic_spec). Phases 4 and 6 ended up linear not because the underlying design intended them to be non-iterative, but because I hadn't identified a clean specification artifact for them until working through the ATWL. This is a genuine design gap worth fixing: add explicit assess steps (and corresponding specification artifacts from point 1) to Phases 4 and 6.
4. The two loops are structurally disconnected, understating cross-view iteration
L_community_structure and L_topic_refinement are independent loops with no feedback path between them. But my prose explicitly imagined a single interactive session where "insights from the topic panel or overlap matrix" could prompt the analyst to go back and adjust community-detection resolution — i.e., a discovery late in Phase 5 or 6 should be able to re-open the Phase 3 loop. As written, the ATWL treats these as sequential, self-contained refinement cycles, which is easier to specify but weaker than what was actually described. A more faithful design would either (a) nest all four loops under one outer loop with a shared stopping condition and a shared provenance artifact, or (b) at minimum add a conditional branch from later assess steps back to S_detection_spec.
5. Missing provenance artifact
The prose explicitly invoked SOMFlow's "flow graph... record every parameter choice... so revisions can be compared against earlier ones." No such artifact appears in the ATWL — each loop iteration's history is implicitly discarded once assign rebinds the specification. A knowledge (or specification-adjacent) artifact accumulating the sequence of parameter choices across all loops would make this traceability explicit rather than assumed.
6. Overlap threshold for event detection deserves its own specification
T_char_overlap/F_community_flow computes membership overlap that later drives event classification, but the threshold determining "strong enough overlap to count as a match" is not parameterised anywhere — it is folded silently into the human abstraction step. This is really the same issue as point 1's S_event_classification_spec, but worth calling out separately because it sits at the boundary between a characterise transform (machine) and an abstract transform (human), and ATWL's separation of these two intents makes it obvious that a threshold decision is being smuggled into the human step rather than stated as a control parameter either could consume.
None of these are fabrications of sophistication that wasn't there — rather, working through ATWL's requirement to name every artifact and justify every actor designation exposed places where my prose used a judgment step (e.g., "classify authors," "identify event type") without making the criteria or their tunability explicit, and where an iteration I described in general terms (the Phase 7 "integrated loop") was not actually reflected as a connected control structure once decomposed into concrete artifacts.
Thank you. Now please implement the modifications you just recommended, producing a revised ATWL representation of the workflow.
Treat this as a genuine revision, not an exercise in maximising apparent structural sophistication: implement each recommended modification only if, on reflection, you still judge it a real improvement to the analytical workflow, not simply because it would add a loop, specification, or actor distinction. If implementing a change would not actually strengthen the workflow (for example, because the added structure wouldn't reflect a decision an analyst would really need to revisit), say so and leave that part as it was, explaining why.
You are not restricted to additive changes. If implementing a recommendation well requires restructuring an existing phase (splitting, merging, or re-sequencing transforms) rather than only adding to it, do so — but note explicitly where you departed from a purely additive patch.
After producing the revised representation, summarise what changed relative to the previous stage: which recommended modifications were implemented as described, which were implemented differently than originally suggested (and why), and which were not implemented and why not.
On the third recommendation about adding iterative loops to Phase 4 and Phase 6, I'm weighing whether this genuinely strengthens the workflow or just adds structure for its own sake. Phase 4 could benefit from a loop where I assess whether the role classifications align with domain knowledge and potentially refine the thresholds, which makes sense given the new specification I'm adding. Phase 6's overlap-matrix inspection could feed back to Phase 3's community granularity, but that's a cross-phase loop tied to a separate recommendation. Now I'm filtering through which recommendations actually warrant implementation versus those that would just add complexity for its own sake. The specification additions for classification and overlap thresholds are genuine improvements an analyst would need. The actor role fix is straightforward. For Phase 4, adding a small iteration loop makes sense since someone would realistically want to refine role classifications after seeing the NodeTrix visualization reveal misclassifications. Phase 6's overlap threshold adjustment is similarly plausible, though I'm considering whether a full assess-loop with visualization is necessary or if a simpler threshold-adjustment mechanism would suffice.
The trickier question is whether to implement full cross-loop connectivity allowing Phase 3 to be revisited from later phases. The original prose did describe this back-and-forth across all phases, but nesting four loops together would significantly restructure the ATWL and risk departing from what I actually designed. I need to weigh whether this is a genuine analytical necessity or just added sophistication that overcomplicates the representation. ATWL doesn't have a direct "jump" mechanism for crossing between loops, so I need to either restructure this as a single outer loop encompassing all four refinement activities—letting the whole subprocess iterate if the community detection needs adjustment—or find another way to represent this feedback path within the language's constraints. I'm weighing whether a full restructuring would actually clarify the specification or just make it harder to follow. The pragmatic approach is to add a conditional branch after Phase 6 that loops back to community detection if the overlap assessment reveals inadequate resolution — either by wrapping Phases 3-6 in an outer loop or using a final assess step with a conditional that re-enters the workflow.
But given ATWL's guidance against nested loops for clarity and the fact that the original design only mentioned this cross-phase adjustment as a general aspiration rather than a core characteristic, I'm deciding not to implement the full nested restructuring. It would overcomplicate the representation beyond what genuinely reflects how the method actually works.
That said, I could add a lighter compromise: a single outer loop wrapping the entire Phase 3–6 sequence with a final coherence check that determines whether the community/topic/overlap structure is sound, and if not, loops back to redo everything with adjusted detection parameters. This feels like a more natural fit for the workflow.
Looking back at the ATWL guidance about avoiding nested loops in templates, I realize that refers to template notation specifically—the example workflow itself has two sequential loops without nesting. Given the complexity trade-off, I should focus on what actually improves the design. My earlier critique pointed out that a more faithful approach would either nest all four loops under one outer loop with a shared stopping condition, or at minimum add conditional branches from later assessment steps back to the detection phase.
Option (b) is the lighter-weight, more defensible path. I can add a conditional after the Phase 6 overlap assessment: if the assessment suggests the community structure is inadequate, I generate a revised detection spec and explicitly trigger a re-run of the community structure loop and subsequent phases. I'd use an assignment to reset the detection spec, then wrap the entire Phase 3-6 body in a new outer loop that sequences the community structure loop, Phase 4, the topic refinement loop, Phase 5 continuation, and Phase 6.
Given the instructions allow restructuring when needed, I should attempt this, but I'll keep it pragmatic and manageable rather than fully nesting everything. I'll preserve the existing community structure and topic refinement loops with minor fixes (actor references, threshold specs), then add small refinement loops to Phase 4 for role classification and Phase 6 for overlap thresholds.
For the cross-loop connection, I'll wrap Phases 3–6 in a single outer loop that runs the full sequence of inner activities and ends with an integrated assessment checking coherence across community structure, roles, topics, and overlap. If the assessment finds inadequacy, the detection spec regenerates and the outer loop repeats the entire inner sequence; otherwise it exits to final synthesis. This directly implements the recommendation to nest under one outer loop with a shared stopping condition.
ATWL does allow nested loops syntactically—the guidance against nesting is about template notation for clarity, not about actual structural nesting. So I can implement the outer loop wrapping the inner loops without violating the language constraints. Given how complex a full nested restructure would be, I need to weigh whether the effort justifies the scope of this answer.
I'm settling on a focused approach: add specification artifacts for role and overlap classification thresholds with small assess-loops tied to each, fix the actor for T_partition_windows to machine, implement assess-refine loops in Phase 4 and Phase 6, and accumulate provenance artifacts tracking specification history. This balances genuine engagement with practical execution.
For the cross-loop connection, I'm wrapping the entire community-structure-through-overlap pipeline in a single outer loop that can regenerate the detection spec and re-trigger the inner sequence, which satisfies the recommendation without over-nesting everything.
Now I need to carefully build out the full ATWL phase by phase, starting with the unchanged Phase 0 components, then adding the initial specifications for role thresholds and overlap thresholds, and figuring out how to model the provenance log as a knowledge artifact that accumulates across loop iterations while working within the ATWL reassignment mechanism.
For the outer loop, I'm designing L_integrated_analysis to iteratively refine the joint analysis of communities, roles, topics, and overlaps until the overall characterization feels coherent and consistent with domain knowledge, which will also allow me to revisit and adjust those early-stage specification choices around temporal windowing and community-detection resolution parameters.
The loop body includes the community structure phase, knowledge evolution analysis, and then moves into phase 4 with author metrics and a smaller role classification loop where I define units, classify authors, and refine the role thresholds based on assessment results, followed by visualizations for the network structure, author timelines, and stability metrics across both abstracts and knowledge.
Then phase 5 handles text features and topic refinement through another small loop, generating topic profiles and evolution visualizations before assessing the research foci. Phase 6 tackles the overlap matrix with its own threshold refinement loop, and finally there's an integrated assessment that checks whether the community and window structure itself needs revision or if only the thresholds need adjustment—if the structure itself is problematic, I regenerate the detection specification. I need to write out the full ATWL structure now, keeping descriptions efficient to manage the length since I'm adding the outer loop, two new inner loops, and a final synthesis step. I should also update the template line at the top to reflect the new loop hierarchy. Continuing through author timelines and stability patterns, then building topic models to track research focus evolution across communities, assessing pairwise overlaps to refine thresholds, and finally synthesizing all findings into an integrated analysis.
I'm realizing the template is getting too deeply nested, which goes against the spec's guidance on clarity. I should flatten it to show just the outer loop structure in the template itself, keeping the inner loops described in the body rather than embedded in the notation.
Flattening the template... Completing the outer loop with the integrated synthesis knowledge artifact, then I need to carefully structure the full template with comments tracking what's changed. I'll also need to handle the provenance log by initializing it before the outer loop and updating it whenever any specification gets refined within the inner loops. I need to flesh out the provenance log artifact with its full specification—it tracks references to all the specs being refined, starts as an empty log, and accumulates a chronological record of each parameter change made during refinement iterations. Then each refinement transform will produce an updated version of this log as an additional output.
Since each refinement transform already has a single intent to generate a refined specification, I can simply add the provenance log as a second output without needing separate transforms. This means updating the outputs to include both the refined spec and the updated log, then reassigning both artifacts back to their base forms. This naturally incorporates the provenance tracking into the existing refinement pipeline.
Now I need to apply the same pattern to the role threshold and overlap threshold specifications. I need to decide whether to include the visualization transforms inside the loop for real-time assessment or keep them separate and reuse them later—I'll embed a lightweight version in the loop for checking role assignments, then reuse those same computations in the final abstraction steps to avoid redundant work. ability consume the final V_nodetrix and V_author_timeline from the last loop iteration, along with F_author_metrics. For Phase 6, I'll move the overlap visualization into the loop alongside assessment and conditional refinement of the overlap threshold, then have the abstraction step consume the final V_overlap afterward. The question is whether S_overlap_threshold should feed into the characterization step or the abstraction step — it makes more sense in abstraction, where I'm identifying high-overlap pairs based on the threshold, rather than in characterization which just computes the raw overlap matrix.
Let me restructure this: the visualization step consumes both the overlap matrix and the threshold to highlight cells above it, the assessment evaluates whether those highlighted pairs are meaningful, and if not, the threshold gets refined. Then abstraction uses the final threshold to identify salient high-overlap pairs. This keeps the flow consistent. I should also revisit Phase 3's outer community loop and fix the actor reference for T_partition_windows.
Now I'm thinking about wrapping everything from Phase 3 through Phase 6 in a top-level integrated analysis loop that ensures all the community structures, evolution events, stability patterns, research foci, and overlap patterns form a coherent, mutually consistent picture. This loop would run until the integrated findings align with domain knowledge, and it could trigger regeneration of the detection spec if needed, allowing early choices about temporal windowing to be revisited based on downstream results. Defining the revision workflow... The reassignment of S_detection_spec triggers a cascade through the downstream loops, so each iteration re-runs the community structure detection with the updated specification—this satisfies the recommendation for iterative refinement. The artifact dependency graph stays acyclic except for these explicit loop assignments, which aligns with the ATWL validity constraints. The topic refinement loop remains independent, handling its own concerns separately, so there's no unintended feedback between the two processes. I'm weighing whether this restructuring genuinely improves the analysis or just adds complexity without corresponding analytical benefit.
Actually, this does reflect what an analyst would want: after observing overlap patterns or research foci that seem off, revisiting the community granularity to decide whether communities should merge, split, or dissolve is exactly the kind of iterative refinement that matters. I'll go with this design.
Now I need to be mindful of the document length and time constraints, so I'll write the full output with concise artifact descriptions where they haven't changed, but complete coverage. I also need to fix the actor role for T_partition_windows to machine, and I'll structure the final output with clear phase comments marking the changes.
For the artifact list, I'm keeping D_authors with its elementary internal structure, and I'm now including the new specification artifacts (S_role_thresholds, S_overlap_threshold, K_provenance_log) alongside the existing ones, making sure all required fields are present while trimming some repeated boilerplate where possible.
Now I'm laying out the main integrated analysis loop with the community structure phase, knowledge evolution tracking, and then moving into Phase 4 where I classify authors by role using the thresholds, generate the node-link and timeline visualizations, and assess the resulting role assignments.
Then there's a conditional refinement step where I can iteratively improve the role thresholds if the quality metrics warrant it, followed by analyzing stability patterns across the visualizations and text metrics. Phase 5 shifts focus to characterizing text features and refining topics through another iterative loop, generating topic profiles and visualizations to identify research foci.
Now moving into Phase 6, I'm computing an overlap matrix between elements and running another refinement loop to calibrate the overlap threshold based on visualization quality assessments. Once the threshold is optimized, I'll abstract the overlap patterns to identify how different components relate to each other.
After that outer loop completes, I'm evaluating how well the detection specification integrates with everything else, and if needed, revising it based on that assessment. Finally, I'll synthesize all the accumulated knowledge—evolution patterns, stability metrics, key foci, and overlap patterns—into the final findings.
I need to preserve the artifact declarations from before and make sure the coauthor computation happens outside the loop since it doesn't depend on the detection spec changes. Actually, wait—the anchor communities detection does use the detection spec's resolution parameter, so it needs to be recomputed whenever the spec changes across iterations. That's already handled correctly since it's nested inside the integrated analysis loop.
Revised ATWL Representation
workflow vis-coauthorship-community-evolution
template: define-unit -> characterise ->
loop(define-unit (windows/communities) -> characterise (flow) ->
contextualise -> visualise -> abstract (events) -> assess ->
generate-knowledge (evolution) ->
characterise (author metrics) -> define-unit (roles) -> visualise ->
abstract (stability) -> generate-knowledge (stability) ->
characterise (text) -> build-model (topics) -> visualise ->
characterise (topic profiles) -> visualise (topic evolution) ->
abstract (foci) -> generate-knowledge (foci) ->
characterise (overlap) -> visualise (overlap) -> abstract (overlap) ->
assess (integration)) ->
generate-knowledge (integrated synthesis)
description: "Visual analytics workflow for identifying and characterising the
intellectual communities of the IEEE VIS co-authorship network, tracking
core stability, membership drift, merge/split/dissolution events, and
associated research foci across 1990-2024, with an outer refinement loop
allowing foundational community-detection choices to be revisited in light
of downstream role, topic, and overlap findings"
# ============================================================================
# INPUT
# ============================================================================
artifact D_papers : entities
origin: given
internal structure: elementary
embedment: {set, time}
features:
- id: f_authors
value structure: list
value type: reference
description: "Disambiguated author IDs"
- id: f_year
value structure: atomic
value type: temporal
- id: f_title
value structure: atomic
value type: text
- id: f_abstract
value structure: atomic
value type: text
- id: f_keywords
value structure: list
value type: text
- id: f_citations
value structure: list
value type: reference
description: "Citation links (provided but not used in this workflow)"
description: "3596 IEEE VIS papers (Vis/InfoVis/VAST/SciVis), 1990-2024"
# ============================================================================
# PHASE 0: DEFINE AUTHORS AND FULL-PERIOD CO-AUTHORSHIP NETWORK
# ============================================================================
transform T_define_authors :
intent: define-unit
manner: "extract"
input: D_papers
output: D_authors
actor: machine
description: "Extract distinct disambiguated authors as analysis units"
artifact D_authors : entities
internal structure: elementary
embedment: {time, relational structure}
features:
- id: f_active_years
value structure: list
value type: temporal
description: "Distinct disambiguated authors, situated in publication time
and in the co-authorship network"
transform T_char_coauthor_full :
intent: characterise
manner: "define-relations (co-authorship, full period)"
input: D_authors, D_papers
output: F_coauthor_full
actor: machine
description: "Compute weighted co-authorship relation across the full
1990-2024 period"
artifact F_coauthor_full : feature(D_authors)
value structure: relational configuration
value type: numeric
representation form: "weighted co-authorship graph, full period (anchor structure)"
# ============================================================================
# SPECIFICATIONS AND PROVENANCE LOG (given at start; consumed/updated throughout)
# ============================================================================
artifact S_detection_spec : specification
origin: given
representation form: "parameter settings (window length, window step,
community-detection algorithm and resolution)"
description: "Initial choices governing temporal windowing and
community-detection granularity"
artifact S_role_thresholds : specification
origin: given
representation form: "parameter settings (tenure and centrality thresholds)"
description: "Initial thresholds defining what counts as high tenure, high
centrality, and multi-community (boundary-spanning) membership"
artifact S_overlap_threshold : specification
origin: given
representation form: "parameter settings (overlap-weight threshold)"
description: "Initial threshold defining what counts as a persistently
high-overlap community pair"
artifact S_topic_spec : specification
origin: given
representation form: "parameter settings (number of topics, seed terms)"
description: "Initial topic-model configuration"
artifact K_provenance_log : knowledge(S_detection_spec, S_topic_spec,
S_role_thresholds, S_overlap_threshold)
origin: given
representation form: "chronological log of specification changes"
description: "Initially empty; accumulates a record of each change made to
S_detection_spec, S_topic_spec, S_role_thresholds, or S_overlap_threshold
during iterative refinement, so revisions can be compared to earlier ones"
# ============================================================================
# OUTER LOOP: INTEGRATED REFINEMENT ACROSS ALL DOWNSTREAM PHASES
# ============================================================================
loop L_integrated_analysis:
purpose: "Ensure that community structure, core stability, research foci,
and cross-community overlap together form a coherent account of the VIS
intellectual structure; allow foundational temporal-windowing and
community-detection choices to be revisited in light of downstream
role, topic, or overlap findings, not only in light of the community
partition itself"
until: "The combined characterisation of communities, their evolution
events, core stability/leadership, research foci, and overlap patterns
is judged coherent and consistent with domain knowledge of the VIS
community"
body:
# ------------------------------------------------------------------------
# PHASE 3 (INNER LOOP): WINDOWING, COMMUNITY DETECTION, CROSS-TIME MATCHING
# ------------------------------------------------------------------------
loop L_community_structure:
purpose: "Refine temporal windowing and community-detection resolution
until communities are neither too fragmented nor too coarse, and
cross-time matches (persistence/merge/split/dissolution) are
plausible given domain knowledge"
until: "Community partition granularity and cross-time matches are
judged adequate"
body:
transform T_partition_windows :
intent: define-unit
manner: "time-partitioning with overlapping windows"
input: D_papers, S_detection_spec
output: D_windows
actor: machine
description: "Partition 1990-2024 into overlapping time windows
as specified by S_detection_spec"
artifact D_windows : entities
internal structure: episode
embedment: time
features:
- id: f_window_span
value structure: atomic
value type: temporal
description: "Overlapping time windows over the publication period"
transform T_char_window_graphs :
intent: characterise
manner: "define-relations (co-authorship, per window)"
input: D_authors, D_papers, D_windows
output: F_coauthor_windows
actor: machine
description: "Compute weighted co-authorship subgraph per window"
artifact F_coauthor_windows : feature(D_windows)
value structure: relational configuration
value type: numeric
representation form: "weighted co-authorship graph per window"
transform T_anchor_communities :
intent: define-unit
manner: "cluster-by-similarity (graph community detection, full period)"
input: D_authors, F_coauthor_full, S_detection_spec
output: D_anchor_communities, F_anchor_membership
actor: machine
description: "Detect long-term reference communities from the
full-period network"
artifact D_anchor_communities : entities
internal structure: group/cluster
embedment: set
features:
- id: f_size
value structure: atomic
value type: numeric
description: "Long-run reference communities"
artifact F_anchor_membership : feature(D_authors)
value structure: atomic
value type: categorical
description: "Anchor-community label per author"
transform T_window_communities :
intent: define-unit
manner: "cluster-by-similarity (graph community detection, per window)"
input: D_authors, F_coauthor_windows, S_detection_spec
output: D_window_communities, F_window_membership
actor: machine
description: "Detect communities independently within each
windowed snapshot"
artifact D_window_communities : entities
internal structure: group/cluster
embedment: {set, time}
features:
- id: f_size
value structure: atomic
value type: numeric
- id: f_window
value structure: atomic
value type: reference
description: "Per-window communities of collaborating authors"
artifact F_window_membership : feature(D_authors)
value structure: atomic
value type: categorical
description: "Per-window community label per author"
transform T_char_overlap :
intent: characterise
manner: "define-relations (membership overlap across adjacent windows)"
input: D_window_communities, F_window_membership
output: F_community_flow
actor: machine
description: "Compute weighted overlap of author membership between
communities in adjacent/overlapping windows"
artifact F_community_flow : feature(D_window_communities)
value structure: relational configuration
value type: numeric
representation form: "directed weighted graph linking (community,
window) pairs by membership overlap"
transform T_project_states :
intent: contextualise
manner: "projection-based (community-state embedding)"
input: D_window_communities, F_community_flow
output: D_state_space, A_state_projection
actor: machine
description: "Embed each (community,window) state in 2D by
member/topic similarity"
artifact D_state_space : entities
internal structure: elementary
features:
- id: f_dimensions
value structure: atomic
value type: numeric
description: "Computed 2D projection space for community-window states"
artifact A_state_projection : arrangement(D_window_communities)
context: D_state_space
principle: "similarity-preserving projection of member/topic vectors"
description: "Layout where proximity indicates persistence across windows"
transform T_arrange_flow :
intent: contextualise
manner: "flow/alluvial arrangement based on temporal order and overlap"
input: D_window_communities, F_community_flow, D_windows
output: A_flow_layout
actor: machine
description: "Arrange communities along the temporal axis with
ribbon widths from overlap weights"
artifact A_flow_layout : arrangement(D_window_communities)
context: D_windows
principle: "alluvial/stream layout ordered by time window, ribbon
width by overlap weight"
transform T_vis_evolution :
intent: visualise
manner: "coordinated alluvial diagram and projection scatterplot"
input: A_flow_layout, A_state_projection, F_community_flow
output: V_evolution
actor: machine
description: "Render community-flow as alluvial diagram alongside
a 2D state-projection scatterplot"
artifact V_evolution : visualisation(A_flow_layout, A_state_projection,
F_community_flow)
layout: "alluvial diagram; 2D projection scatterplot"
form: "stream ribbons; coloured points with trails"
encoding: "ribbon width/position from F_community_flow; point
position from A_state_projection; trails connect matched states"
transform T_abstract_events :
intent: abstract
manner: "perception-and-interpretation of evolution events"
input: V_evolution, F_community_flow
output: P_evolution_events
actor: human
description: "Identify and classify evolution events
(persist/split/merge/emerge/dissolve) per community trajectory"
artifact P_evolution_events : pattern(D_window_communities)
representation form: "labelled event templates per community
trajectory"
transform T_assess_structure :
intent: assess
manner: "judge community granularity and match plausibility"
input: V_evolution, P_evolution_events
output: K_structure_quality
actor: human
description: "Judge whether communities are appropriately
resolved and whether identified matches are plausible"
artifact K_structure_quality : knowledge(D_window_communities,
P_evolution_events)
representation form: "quality judgment"
if K_structure_quality indicates refinement needed:
then:
transform T_refine_detection_spec :
intent: generate-knowledge
manner: "formulate methodological adjustment"
input: K_structure_quality, S_detection_spec, K_provenance_log
output: S_detection_spec_r, K_provenance_log_r
actor: human
description: "Adjust window size/step or clustering resolution;
append the change to the provenance log"
artifact S_detection_spec_r : specification
representation form: "updated parameter settings"
artifact K_provenance_log_r : knowledge(S_detection_spec_r)
representation form: "chronological log of specification changes"
description: "Provenance log updated with this window/resolution change"
assign:
S_detection_spec := S_detection_spec_r
K_provenance_log := K_provenance_log_r
else:
exit loop L_community_structure
end loop L_community_structure
transform T_knowledge_evolution :
intent: generate-knowledge
manner: "formulate-statements"
input: P_evolution_events, V_evolution
output: K_evolution
actor: human
description: "Formulate conclusions about the number of distinct
long-run communities and when/how they merged, split, or dissolved"
artifact K_evolution : knowledge(P_evolution_events, D_window_communities)
representation form: "statements"
# ------------------------------------------------------------------------
# PHASE 4: CORE STABILITY AND LEADERSHIP (with role-classification loop)
# ------------------------------------------------------------------------
transform T_char_author_metrics :
intent: characterise
manner: "compute-statistics (tenure, centrality, cross-membership)"
input: D_authors, F_window_membership, F_coauthor_windows
output: F_author_metrics
actor: machine
description: "Compute per-author tenure, within-community centrality
per window, and cross-community membership count"
artifact F_author_metrics : feature(D_authors)
value structure: vector
value type: numeric
loop L_role_classification:
purpose: "Refine role-classification thresholds until core/leader,
peripheral, and boundary-spanning assignments are judged consistent
with domain knowledge of the VIS community"
until: "Classified roles match the analyst's knowledge of known
research groups and leaders"
body:
transform T_classify_authors :
intent: define-unit
manner: "rule-based classification (core / peripheral / boundary-spanning)"
input: D_authors, F_author_metrics, S_role_thresholds
output: D_author_roles, F_role_label
actor: hybrid
description: "Classify authors into roles using current thresholds"
artifact D_author_roles : entities
internal structure: group/cluster
embedment: set
description: "Groups of authors sharing the same structural role"
artifact F_role_label : feature(D_authors)
value structure: atomic
value type: categorical
transform T_vis_nodetrix :
intent: visualise
manner: "node-link/matrix hybrid (NodeTrix)"
input: D_window_communities, F_coauthor_windows, F_role_label
output: V_nodetrix
actor: machine
description: "Render a selected community-period's dense
collaboration core as an adjacency matrix, bridging ties as
node-link edges"
artifact V_nodetrix : visualisation(D_window_communities,
F_coauthor_windows, F_role_label)
layout: "hybrid node-link and matrix"
form: "adjacency matrix blocks; node-link edges for external ties"
encoding: "matrix cell = intra-core edge weight; node colour =
role label; external edges = bridging ties"
transform T_vis_author_timeline :
intent: visualise
manner: "scarf-plot / event-sequence timeline per author"
input: D_authors, F_window_membership, D_windows
output: V_author_timeline
actor: machine
description: "Render each author as a track with coloured segments
indicating community membership per window"
artifact V_author_timeline : visualisation(D_authors,
F_window_membership, D_windows)
layout: "aligned horizontal timelines"
form: "coloured segments"
encoding: "row = author; horizontal position = time window;
colour = community membership"
transform T_assess_roles :
intent: assess
manner: "judge role-classification plausibility"
input: V_nodetrix, V_author_timeline, F_role_label
output: K_role_quality
actor: human
description: "Judge whether classified core/leader, peripheral,
and boundary-spanning assignments match known VIS leaders and
research groups"
artifact K_role_quality : knowledge(D_author_roles)
representation form: "quality judgment"
if K_role_quality indicates refinement needed:
then:
transform T_refine_role_thresholds :
intent: generate-knowledge
manner: "formulate methodological adjustment"
input: K_role_quality, S_role_thresholds, K_provenance_log
output: S_role_thresholds_r, K_provenance_log_r2
actor: human
description: "Adjust tenure/centrality thresholds; append the
change to the provenance log"
artifact S_role_thresholds_r : specification
representation form: "updated parameter settings"
artifact K_provenance_log_r2 : knowledge(S_role_thresholds_r)
representation form: "chronological log of specification changes"
assign:
S_role_thresholds := S_role_thresholds_r
K_provenance_log := K_provenance_log_r2
else:
exit loop L_role_classification
end loop L_role_classification
transform T_abstract_stability :
intent: abstract
manner: "perception-and-interpretation of stability/leadership patterns"
input: V_nodetrix, V_author_timeline, F_author_metrics
output: P_stability_patterns
actor: human
description: "Identify stable cores/leaders per community and members
who move between or span multiple communities"
artifact P_stability_patterns : pattern(D_authors, D_window_communities)
representation form: "labelled roles with textual descriptions"
transform T_knowledge_stability :
intent: generate-knowledge
manner: "formulate-statements"
input: P_stability_patterns
output: K_stability
actor: human
description: "Formulate conclusions about core stability and
leadership per community"
artifact K_stability : knowledge(P_stability_patterns)
representation form: "statements"
# ------------------------------------------------------------------------
# PHASE 5: RESEARCH FOCI (HUMAN-STEERED TOPIC MODELLING)
# ------------------------------------------------------------------------
transform T_char_text_features :
intent: characterise
manner: "encode (term-document representation)"
input: D_papers
output: F_text_features
actor: machine
description: "Build term-document matrix from titles, abstracts, keywords"
artifact F_text_features : feature(D_papers)
value structure: matrix
value type: numeric
representation form: "term-document matrix"
loop L_topic_refinement:
purpose: "Interactively steer the NMF topic model until topics are
coherent, non-redundant, and align with recognisable VIS research areas"
until: "Topics are judged coherent and interpretable"
body:
transform T_build_topic_model :
intent: build-model
manner: "fit-topic-model (NMF)"
input: F_text_features, S_topic_spec
output: M_topic_model
actor: machine
description: "Fit NMF topic model using current specification"
artifact M_topic_model : model(F_text_features)
model type: "topic model"
representation form: "matrix factorisation (W,H)"
transform T_vis_topics :
intent: visualise
manner: "topic term/document display"
input: M_topic_model
output: V_topics
actor: machine
description: "Display top terms per topic and representative documents"
artifact V_topics : visualisation(M_topic_model)
layout: "ranked term lists with representative documents"
form: "ranked term lists, document excerpts"
encoding: "topic weight -> term rank; document-topic weight ->
representative document selection"
transform T_assess_topics :
intent: assess
manner: "judge topic coherence and interpretability"
input: V_topics
output: K_topic_quality
actor: human
description: "Judge whether topics are coherent, distinct, and
align with known VIS research areas"
artifact K_topic_quality : knowledge(M_topic_model)
representation form: "quality judgment"
if K_topic_quality indicates refinement needed:
then:
transform T_refine_topic_spec :
intent: generate-knowledge
manner: "formulate methodological adjustment (merge/split/seed topics)"
input: K_topic_quality, S_topic_spec, K_provenance_log
output: S_topic_spec_r, K_provenance_log_r3
actor: human
description: "Merge/split/seed topics; append the change to
the provenance log"
artifact S_topic_spec_r : specification
representation form: "updated parameter settings and seed constraints"
artifact K_provenance_log_r3 : knowledge(S_topic_spec_r)
representation form: "chronological log of specification changes"
assign:
S_topic_spec := S_topic_spec_r
K_provenance_log := K_provenance_log_r3
else:
exit loop L_topic_refinement
end loop L_topic_refinement
transform T_char_topic_profiles :
intent: characterise
manner: "aggregate (topic-mixture per community-period)"
input: D_window_communities, M_topic_model, D_papers
output: F_topic_profiles
actor: machine
description: "Aggregate topic-mixtures of papers within each
community-period into a topic profile"
artifact F_topic_profiles : feature(D_window_communities)
value structure: vector
value type: numeric
transform T_vis_topic_evolution :
intent: visualise
manner: "matrix / small-multiples"
input: F_topic_profiles, D_window_communities, D_windows
output: V_topic_evolution
actor: machine
description: "Visualise topic-profile distributions across communities
and time"
artifact V_topic_evolution : visualisation(F_topic_profiles,
D_window_communities, D_windows)
layout: "matrix (community x time) / small multiples"
form: "stacked bars or heatmap cells"
encoding: "rows = communities; columns = time windows; cell content =
topic-mixture profile"
transform T_abstract_foci :
intent: abstract
manner: "name-patterns"
input: V_topic_evolution, F_topic_profiles
output: P_research_foci
actor: human
description: "Assign descriptive labels to dominant topics per
community-period; identify foci shifts over time"
artifact P_research_foci : pattern(D_window_communities)
representation form: "labelled topic descriptions per community-period"
transform T_knowledge_foci :
intent: generate-knowledge
manner: "formulate-statements"
input: P_research_foci
output: K_foci
actor: human
description: "Formulate conclusions about each community's main
research foci and their evolution"
artifact K_foci : knowledge(P_research_foci)
representation form: "statements"
# ------------------------------------------------------------------------
# PHASE 6: CROSS-COMMUNITY MEMBERSHIP OVERLAP (with threshold loop)
# ------------------------------------------------------------------------
transform T_char_overlap_matrix :
intent: characterise
manner: "define-relations (pairwise membership overlap within a window)"
input: D_window_communities, F_window_membership
output: F_overlap_matrix
actor: machine
description: "For each window, compute a pairwise overlap matrix among
communities based on shared authorship"
artifact F_overlap_matrix : feature(D_window_communities)
value structure: matrix
value type: numeric
representation form: "pairwise community overlap matrix per window"
loop L_overlap_threshold:
purpose: "Refine the overlap threshold until the resulting set of
high-overlap community pairs is judged meaningful rather than
arbitrary"
until: "The highlighted set of high-overlap pairs is judged meaningful"
body:
transform T_vis_overlap :
intent: visualise
manner: "matrix-plot"
input: F_overlap_matrix, S_overlap_threshold
output: V_overlap
actor: machine
description: "Display community x community overlap matrix per
window, highlighting pairs above the current threshold"
artifact V_overlap : visualisation(F_overlap_matrix, S_overlap_threshold)
layout: "matrix grid, selectable per time window"
form: "heatmap cells with threshold highlighting"
encoding: "cell colour intensity = degree of shared authorship;
highlight = above current threshold"
transform T_assess_overlap_threshold :
intent: assess
manner: "judge meaningfulness of highlighted overlap set"
input: V_overlap
output: K_overlap_threshold_quality
actor: human
description: "Judge whether the highlighted high-overlap pairs are
meaningful (e.g., plausible near-merges) or arbitrary"
artifact K_overlap_threshold_quality : knowledge(F_overlap_matrix)
representation form: "quality judgment"
if K_overlap_threshold_quality indicates refinement needed:
then:
transform T_refine_overlap_threshold :
intent: generate-knowledge
manner: "formulate methodological adjustment"
input: K_overlap_threshold_quality, S_overlap_threshold, K_provenance_log
output: S_overlap_threshold_r, K_provenance_log_r4
actor: human
description: "Adjust overlap threshold; append the change to
the provenance log"
artifact S_overlap_threshold_r : specification
representation form: "updated parameter settings"
artifact K_provenance_log_r4 : knowledge(S_overlap_threshold_r)
representation form: "chronological log of specification changes"
assign:
S_overlap_threshold := S_overlap_threshold_r
K_provenance_log := K_provenance_log_r4
else:
exit loop L_overlap_threshold
end loop L_overlap_threshold
transform T_abstract_overlap :
intent: abstract
manner: "find-salient-groups"
input: V_overlap
output: P_overlap_patterns
actor: human
description: "Identify community pairs with persistently high overlap,
candidates for merging or loss of distinctiveness"
artifact P_overlap_patterns : pattern(D_window_communities)
representation form: "ranked list of high-overlap community pairs"
# ------------------------------------------------------------------------
# INTEGRATED ASSESSMENT (governs whether the outer loop re-enters)
# ------------------------------------------------------------------------
transform T_assess_integration :
intent: assess
manner: "judge overall coherence of integrated community characterisation"
input: K_evolution, K_stability, K_foci, P_overlap_patterns
output: K_integration_quality
actor: human
description: "Judge whether the combined picture of communities, cores,
foci, and overlaps is internally coherent, or whether the underlying
temporal-windowing/community-detection resolution itself should be
revisited (e.g., persistent high overlap or indistinguishable foci
suggesting two 'communities' are really one, or a community is too
coarse to reveal known sub-groups)"
artifact K_integration_quality : knowledge(K_evolution, K_stability,
K_foci, P_overlap_patterns)
representation form: "quality judgment"
if K_integration_quality indicates that community/window resolution needs revision:
then:
transform T_revise_detection_spec :
intent: generate-knowledge
manner: "formulate methodological adjustment based on downstream findings"
input: K_integration_quality, S_detection_spec, K_provenance_log
output: S_detection_spec_r2, K_provenance_log_r5
actor: human
description: "Revise temporal windowing/community-detection
resolution based on evidence from role, topic, or overlap
analysis; append the change to the provenance log; this
triggers re-execution of the entire inner sequence, beginning
with L_community_structure"
artifact S_detection_spec_r2 : specification
representation form: "updated parameter settings"
artifact K_provenance_log_r5 : knowledge(S_detection_spec_r2)
representation form: "chronological log of specification changes"
assign:
S_detection_spec := S_detection_spec_r2
K_provenance_log := K_provenance_log_r5
else:
exit loop L_integrated_analysis
end loop L_integrated_analysis
# ============================================================================
# FINAL SYNTHESIS
# ============================================================================
transform T_final_synthesis :
intent: generate-knowledge
manner: "formulate-statements (integrated synthesis)"
input: K_evolution, K_stability, K_foci, P_overlap_patterns
output: K_findings
actor: human
description: "Synthesise conclusions across community evolution, core
stability/leadership, research foci, and cross-community overlap"
artifact K_findings : knowledge(D_window_communities, D_authors)
representation form: "statements and structured summary"
description: "Integrated findings: number/identity of major communities,
core stability and leadership, research foci and their evolution,
membership overlap and its change over time, and merge/split/
dissolution events with plausible interpretations"
Summary of Changes Relative to the Previous Stage
Implemented as originally described:
- Actor-role fix (recommendation 2): T_partition_windows changed from hybrid to machine, since it mechanically applies S_detection_spec; the human judgment now lives entirely in T_assess_structure.
- Externalised classification thresholds (recommendation 1): Added S_role_thresholds (consumed by T_classify_authors) and S_overlap_threshold (consumed by T_vis_overlap), replacing implicit judgment criteria that were previously buried inside transform manner descriptions.
Implemented, but differently than originally suggested:
- Iterative structure for Phases 4 and 6 (recommendation 3): Rather than adding a bare assess step, I restructured each phase around a proper loop (L_role_classification, L_overlap_threshold) modelled on the existing L_topic_refinement pattern — classify/visualise → assess → conditional refine of the newly introduced specification. This required moving T_vis_nodetrix, T_vis_author_timeline, and T_vis_overlap inside their respective loops (as the artifacts being assessed), with the later abstract/generate-knowledge steps consuming the loop's final-iteration outputs — a small but real restructuring, not a pure addition, because it changes which transforms are inside vs. outside the loop boundary.
- Provenance log (recommendation 5): Rather than a separate dedicated transform, I added K_provenance_log as an additional output of each existing generate-knowledge refinement transform (T_refine_detection_spec, T_refine_role_thresholds, T_refine_topic_spec, T_refine_overlap_threshold, T_revise_detection_spec), each appending to the shared log via reassignment. This was simpler and more consistent with ATWL's multi-output transform capability than inventing a parallel logging mechanism.
- Cross-loop connection (recommendation 4): I implemented the heavier option — (a) nest all phase-level activity under one outer loop L_integrated_analysis with a shared stopping condition — rather than the lighter option of a single conditional branch. This is a genuine restructuring: Phases 3–6, previously a linear sequence of independent loops, are now all nested inside one outer loop, closed by a new T_assess_integration step whose negative outcome regenerates S_detection_spec and causes the entire inner sequence (including re-running L_community_structure) to repeat. I chose this over the lighter "conditional branch back" option because a bare conditional cannot actually re-trigger an already-exited inner loop without an enclosing loop structure — the restructuring was necessary to make the described behaviour ("adjusting resolution... re-running downstream steps") mechanically coherent in ATWL rather than merely gestured at.
Not implemented, with justification:
- I considered, but did not add, additional nested nuance such as independent outer-loop feedback into L_topic_refinement's S_topic_spec from the integration assessment (i.e., letting T_assess_integration selectively revise any of the four specifications rather than only S_detection_spec). I judged this unnecessary: S_topic_spec, S_role_thresholds, and S_overlap_threshold already have their own dedicated local loops that can be revisited on the next full pass of L_integrated_analysis if S_detection_spec changes and the whole inner sequence reruns; adding a second, parallel revision path from the integration assessment would duplicate control flow without adding real analytical capability, and would depart further from what I actually described in prose (which spoke specifically of revisiting resolution/windowing in response to downstream findings, not all parameters symmetrically).
- I did not add loop notation to the workflow's template line for the inner loops (L_community_structure, L_role_classification, L_topic_refinement, L_overlap_threshold), keeping only the outer loop(...) visible at the template level. This follows the specification's explicit guidance that "nested loops should generally be avoided in templates to maintain clarity and abstraction" — the full nesting is represented faithfully in the workflow body, where it belongs, rather than in the high-level summary.