I'm recognizing that the user wrote in German, so I should respond in German as well before proceeding with the task description.

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.

I should confirm that I'm ready to proceed with the task 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.

I'm thinking through how to design a workflow for analyzing bibliometric networks and tracking how research communities evolve over time. I want to leverage visualization techniques like NodeTrix for showing the dense local structure within co-authorship communities, and combine that with methods for tracking network changes across different time periods to see how these communities form and shift. I'm now framing this as a dynamic community detection problem in co-authorship networks, which requires building sliding-window networks per time period, applying community detection algorithms like Louvain to identify core-periphery structures, then tracking how individual communities evolve across time slices—similar to treating each community-at-time-slice as a distinct entity to match and trace through the temporal sequence. I could also build a global supergraph first across all years to identify stable core communities using density-based clustering, then track how those canonical communities evolve through each time window — this anchors the analysis to robust collaboration groups rather than letting communities drift arbitrarily across snapshots. For each time slice, I'd then measure which authors are active and how they map onto these established communities.

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

1. 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.
2. 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:

1. Overview: alluvial community-flow diagram + 2D snapshot-embedding (Phase 3) — pick a community trajectory of interest.
2. Structure drill-down: NodeTrix view of the selected community at a chosen period (Phase 4) — inspect core/leader structure, bridging authors.
3. Author timeline: scarf-plot view of individual authors to verify stability/drift claims (Phase 4).
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.
5. Overlap matrix / StratomeX-style query: check whether the selected community is converging with, diverging from, or embedded inside another (Phase 6).
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.

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

1. "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.

2. "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

3. "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

4. "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

5. "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

6. "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.

7. "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

8. "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.

9. "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

10. "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.

11. "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)

12. "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.

I'm designing an ATWL workflow from the ground up to analyze bibliometric co-authorship networks across nearly 3600 VIS papers spanning three decades, using author identifiers, publication years, titles, abstracts, keywords, and citation data to uncover community structures, track leadership stability, map research evolution, and detect significant membership shifts like mergers or dissolutions over time.

Now I'm thinking through the entity definitions using ATWL constructs — papers as given elementary entities embedded in time and set, with features like title, abstract, keywords, and author lists as references. Authors themselves can be extracted as derived entities from the paper records, creating a separate author collection with their own properties like activity years, though they're fundamentally grounded in the paper data.

For the analysis, I need to think about time windowing to partition the papers into overlapping temporal slices, which creates collaboration snapshots or author-pair groupings within each window — this becomes the core analytical unit rather than just individual papers or authors alone.

The key insight is that these time windows should be modeled as network snapshots themselves: each window entity contains a co-authorship network with its own internal formation structure and temporal embedment. This directly mirrors the spec's example of dynamic network snapshots organized in a temporal sequence, where each snapshot has features like edge weights and presence/absence indicators. So I'm defining D_networks as a collection of these co-authorship network entities, each representing a distinct time period. I'm considering whether to split this into two separate transforms or keep it unified. The key tension is that I need time windows as entities for the partitioning step, but the actual network snapshots—each with their own nodes and edges—are what matter for downstream community detection. So the network structure itself should be the primary entity, with time as an embedding property, rather than treating time windows as separate entities that then get characterized.

I'm settling on a single transform that does both: partition the data into overlapping time windows and construct the co-authorship network for each window in one step. This mirrors the trajectory episode extraction pattern from the example workflow, but produces network entities instead of episodes. I should also consider whether to generate both a full-period supergraph as a single entity and the windowed snapshots as multiple entities for comparison.

Then I'd run community detection on the full-period network to establish anchor communities, creating entities that capture which authors belong to which communities. After that, I'd apply community detection per window to track how communities evolve across time windows, with each community instance representing a (window, community) pair.

To match communities across adjacent windows, I need to compute an overlap feature between communities in consecutive windows—essentially building a weighted bipartite graph showing membership overlap. Then I can trace community trajectories by grouping these overlapping communities across time.

This produces a new entity type: community threads, where each thread is a sequence of window-community instances ordered chronologically. I'm treating the collection of threads as an unordered set, though each thread internally maintains its temporal ordering. I can then compute features like thread duration and prepare to visualize these trajectories—likely using an alluvial diagram that arranges the threads in a flow-based layout.

Now I'm adding a projection step: taking the window-communities and their features (topic profiles, member vectors) and projecting them into a 2D space, which will serve as the basis for the visualization. The alluvial diagram will then display these community flows as ribbons, showing how communities evolve and connect over time. Finally, I'm identifying key structural events—merges, splits, emergence, and dissolution—by analyzing the overlap patterns and alluvial layout to extract the underlying evolution dynamics.

For the stability analysis, I need to compute per-author metrics like tenure, centrality, and cross-membership across communities, then classify authors into roles: core members, peripheral participants, and boundary-spanners who bridge different communities.

Next I'll create a hybrid matrix-node visualization for selected community periods to show the network structure alongside role information, and build author timelines using a scarf plot to track membership changes over time windows. Then I'm moving into topic modeling on the paper texts to extract research focus features from titles, abstracts, and keywords. Then I need to set up a refinement loop where I iteratively cluster and refine the topic model—visualizing results, assessing quality, and adjusting parameters like the number of topics until they become interpretable. After that, I'll visualize how topics evolve across time windows and create an overlap matrix showing which communities share similar topics, styled like a heatmap. I also need assessment loops to evaluate whether the community detection is well-resolved and adjust the resolution parameter accordingly, plus similar quality checks for the topic model parameters.

Now I'm designing a high-level template that chains these operations sequentially without excessive nesting: starting with extracting authors and building time-partitioned network snapshots, then running a loop that detects communities, characterizes their overlap, and assesses quality. From there I'll trace how communities persist or change over time, project them into a lower-dimensional space, and visualize the evolution using alluvial diagrams alongside the projection. I'll detect merge, split, and dissolution events, then classify author roles within communities and prepare them for node-link visualization.

Next comes the topic modeling phase: I'll extract text features, build an initial topic model, then run a refinement loop that profiles topics, visualizes them, interprets the results, and iteratively improves the model. After that I'll aggregate topic profiles across communities, visualize how topics evolve, and examine the community overlap matrix before generating the final knowledge output. This mirrors the example's structure with two main refinement loops—one for community detection and one for topic modeling—keeping the workflow organized despite its complexity. I'm adding the active years feature to track when each author was publishing, then moving into time partitioning to create network snapshots using overlapping windows—I need to specify the windowing parameters like window length and stride for the temporal analysis.

Now I'm defining how to partition the networks by aggregating co-authorship edges within each time window, creating snapshots that capture the network structure at different points in time, with edge weights representing the number of co-authored papers between authors in that window.

Next I'm building an anchor network that aggregates co-authorship across the entire period... ields interpretable, stable community structure. I'll keep refining the resolution parameter until the community sizes and counts feel analytically meaningful—neither fragmented into too many small groups nor collapsed into overly broad ones—and the internal cohesion meets acceptable standards. Then I'm running community detection on the full-period network to establish anchor communities, which gives me a long-term reference structure and assigns each author to their stable community membership.

Now I'm detecting communities within each time window independently, so I get a separate snapshot of the community structure for every period. I need to think through how to represent window membership though—it's not just a simple feature on authors since membership changes across windows. I think it makes more sense to define it as a feature on the window communities themselves, listing which authors belong to each community instance at that time.

With that structure in place, I can move to contextualizing these community snapshots by embedding them in a projection space based on member and topic similarity, which will let me visualize how communities evolve and relate to each other over time.

Then I need to assess whether the detected communities have the right granularity and cohesion—if the quality metrics suggest refinement is needed, I'll adjust the detection parameters and loop back through the process, otherwise I'm done with community detection. Now I'm defining the overlap-matching transform that compares community membership across adjacent time windows using Jaccard similarity to create weighted links between instances, which produces a relational feature capturing how communities persist or merge over time. Then I'm moving into the thread-tracing step to connect these overlapping communities into continuous trajectories. ement requires visual inspection and domain expertise. Now I'm setting up an alluvial diagram to visualize how communities evolve over time, ordering them by thread membership and scaling the ribbon widths to represent community sizes. This layout will help identify significant events in the community structure.

From the visualization, I can detect key evolution events—merges, splits, emergences, and dissolutions—by examining the patterns in the alluvial diagram and marking the time windows where these structural changes occur. Then I'm moving into characterizing author roles by computing metrics like tenure, centrality, and cross-membership within each thread to understand leadership and stability patterns. les (core, peripheral, boundary-spanning) based on their community thread participation. I'm also defining a role label feature that assigns each author to one of these categories. Now I'm setting up a loop for detailed structural inspection where the analyst can drill down into selected communities to validate the role classifications and uncover collaboration patterns, continuing until they've reviewed enough threads to feel confident about the community structure.

For the next phase, I'm having the analyst select a specific community thread and time window to examine more closely, then I'm generating a hybrid visualization that combines a dense matrix view for the core members with node-link edges showing the bridging connections between communities. Then I'll create a timeline visualization showing each author's activity across the discussion threads, and assess whether the resulting network structure and temporal patterns align with what we'd expect from domain knowledge. If there are inconsistencies, I'll need to refine the thread connections and role assignments based on that feedback. I'm realizing the distinction matters here: explicit termination requires an assess transform plus a conditional with an exit branch, while implicit termination has no explicit assessment or conditional at all. But I can use a conditional without an exit branch—that doesn't automatically make it explicit termination style, since the spec defines explicit termination by the presence of an exit, not just by having a conditional. So I could keep the correction capability with a conditional check but no exit statement, which would still align with implicit termination. I'll keep the loop structure since the analyst iteratively inspects multiple threads and revises across communities—that's analytically significant and matches the workflow. Now moving to text feature extraction, where I'll encode the papers' titles, abstracts, and keywords to generate text features as input for topic modeling. I'm fitting the NMF model to produce topic weights, then computing the topic mixture for each paper to see how they distribute across topics, and finally visualizing the topics through ranked term lists to make them interpretable. "adjust topic count or merge-split topics based on quality feedback", then loop back to refine the parameters. Once the topics meet quality standards, I move on to aggregating community-level topic profiles by averaging the paper topic mixtures within each community window, which will let me track how research focus evolves across communities over time.

Now I'm organizing these aggregated profiles into a communities-by-time matrix layout, then visualizing how the topic distributions shift across different community threads and periods. After that, I'll examine the cross-community membership overlaps for each time period. The human assessment of overlap patterns feeds into the final synthesis step, where I'm pulling together all the evolution events, role metrics, topic data, and structural assessments to formulate comprehensive findings that answer the analyst's original questions.

I'm structuring the overall template to avoid deep nesting by using loops for the three main analytical cycles—community detection, role characterization, and model building—flowing from network construction through event detection and ending with the synthesis of findings.

Now I need to write this out in full ATWL syntax with consistent IDs, proper artifact references, and all inputs declared before use. I should verify that the network entity doesn't need internal structure embedding since it's treated as a single object, and confirm the author features are properly typed with temporal values for active years.

I'm also reconsidering the author naming — the ID itself serves as the entity identifier, so a separate name feature might be redundant. For the community membership tracking, I'll consolidate by having T_detect_window_communities directly output D_window_communities with F_community_members as a feature listing author references, then replace all downstream references to F_window_membership with this unified feature. I also need to add a reciprocal per-author feature tracking which window-communities they belong to.

For tenure and cross-membership metrics, I can derive those from F_community_members through the characterise step using author role metrics with inputs from D_authors, D_community_threads, and D_networks. I'll keep F_anchor_membership as a per-author feature since anchor communities assign one label per author rather than a list.

Now I'm drafting the full ATWL document with clear step headers and comments matching the example style — balancing thoroughness with readability given the workflow's complexity. I'm also reassessing actor assignments, starting with extraction and partitioning as machine tasks since they're straightforward from disambiguated IDs.

For community detection and projection, those are machine operations too. Assessment of resolution quality is human-driven, but rather than a separate generate-knowledge step, I'm modeling it so T_assess_resolution outputs both K_resolution_quality and optionally updated S_community_params directly — mirroring how the example uses assess to inform domain-specific transforms like characterise or build-model that explicitly refine based on that knowledge. The spec actually allows assess transforms to output both knowledge and specification artifacts directly—including optional updated specifications for revised parameters. So I can model the assessment of resolution quality as producing both the evaluation results and optionally updated community parameters, which means I don't need a separate generate-knowledge transform for parameter refinement. This simplifies the workflow: the assess transform evaluates resolution quality and conditionally suggests parameter adjustments, then downstream logic applies those updates if the quality assessment warrants it. So the assess transform always runs and outputs the quality metric unconditionally, then a conditional branch decides whether refinement is needed—if so, a separate transform (generate-knowledge for parameters or characterise for features) produces the updated specification. This mirrors the HITL example exactly and keeps the logic cleaner and more consistent. justing resolution and topic parameters is really just a methodological choice, so generate-knowledge fits the spec's own guidance about selecting modeling strategies and setting parameters. For Step 8's structure inspection, though, the actual corrections to thread linkages and role labels are substantive data changes, so those should use define-unit and characterise directly rather than generate-knowledge—I'll skip the separate knowledge generation step and just do the manual corrections to produce the updated thread structure and role labels.

Correcting thread linkage is fundamentally redefining the merge-groups, which aligns perfectly with define-unit intent, consistent with how I handled the earlier trace-threads step. So the correction transform uses define-unit with manner "manual correction of thread linkage based on domain knowledge," taking the original threads, structure assessment, and overlap data as inputs to produce the revised threads. For role labels, since they're categorical assignments, I could use characterise for relabeling, but since the grouping of authors themselves isn't changing—only their label assignments—define-unit works better for this categorical reassignment.

Now I'm finalizing the loop body for the structure inspection step, which cycles through selecting community windows, contextualizing them as node-link diagrams and timelines, then visualizing each representation. After assessing the structure, if corrections are needed, the loop manually fixes thread linkages and role classifications before reassigning the updated data; otherwise it continues informally until the analyst decides to stop.

Now I'm realizing there's a tension with the spec's definition of implicit termination — it says no explicit assessment or conditional should appear in the loop body, but I've included both an assess step and a conditional for triggering corrections. That seems to contradict the implicit style, since the spec suggests the analyst should monitor the until condition informally without explicit checks inside the loop itself. I think treating loop termination as implicit—where the analyst decides when to stop inspecting—makes sense here, since my internal conditional serves a different purpose (triggering corrections rather than exit logic). This is a reasonable extension within the spirit of the language, even if it doesn't strictly match the "explicit assessment" pattern. Given the task emphasizes thorough treatment and visual inspection, I'll keep the drill-down loop but stay concise. Now I need to reconsider the T_class definition.

For the classify_roles step, I'm outputting D_author_roles and F_role_label as before with the actor hybrid approach. Then I'll compile the full document, placing S_windowing, S_community_params, and S_topic_params near the top or at first use. I should also add K_prior_domain_knowledge as a knowledge artifact representing the analyst's informal domain experience with known VIS research groups that get referenced during assessments.

Now I'm ready to write out the complete ATWL file with proper comments, artifact declarations before use, and transforms with their correct fields. I need to verify the characterize transform's typical outputs, particularly around feature artifacts with relational config value structures.

For the contextualise step, I'm checking whether our computed contexts align properly with their output types—the alluvial and nodetrix contexts use existing entities as arrangement outputs, while the author timeline context needs a time axis representation, which I can derive from the author embeddings themselves rather than creating a separate timeline artifact. Now I need to finalize the template structure, making sure I've defined all the necessary entities like the selected window community as a filtered subset, and then write out the complete workflow with proper section organization matching the step-by-step approach from the beginning. rix) -> generate-knowledge. That gives me three loops total with no nesting, which aligns with the template guidelines. Now I'm writing out the complete document with proper ATWL syntax, making sure artifact IDs stay consistent throughout, and structuring each transform with its intent, manner, input, output, actor, and description, along with properly defined entities, loops with their purpose and termination conditions, and any conditionals or assignments.

Below is the ATWL specification for the workflow, designed fresh from the constructs of the language rather than as a transcription of my earlier natural-language design. I use three top-level loops (community-resolution refinement, structural drill-down/correction, and topic-model refinement) rather than the phase-based prose structure, since these are the points where the analyst genuinely iterates with visual inspection and domain judgement. Where an ATWL construct suggested a cleaner formulation than my earlier phase list (e.g., treating network snapshots directly as formation-structured entities per the language's own dynamic-network example, or letting assess gate explicit generate-knowledge/define-unit correction steps), I followed the construct rather than my original narrative.

workflow vis-coauthorship-community-evolution
  template: define-unit (extract authors) ->
            define-unit (network construction: windows & anchor) ->
            loop(define-unit (community-detection) -> contextualise (projection) ->
                 visualise -> assess) ->
            characterise (cross-time overlap) -> define-unit (trace threads) ->
            contextualise (alluvial) -> visualise -> abstract (detect events) ->
            characterise (author role metrics) -> define-unit (classify roles) ->
            loop(contextualise (drill-down layouts) -> visualise -> assess) ->
            characterise (text encoding) ->
            loop(build-model (topic model) -> characterise (topic profiles) ->
                 visualise -> abstract (interpret) -> assess) ->
            characterise (aggregate community topic profiles) ->
            visualise (topic evolution) ->
            characterise (period overlap matrix) -> visualise (overlap matrix) ->
            generate-knowledge
  description: "Human-in-the-loop visual analytics workflow for identifying
    communities of collaborating VIS researchers, tracing their evolution
    (stability, drift, merges, splits, dissolution), characterising core
    leadership, and linking communities to their evolving research foci."

# ============================================================================
# INPUT
# ============================================================================

artifact D_papers : entities
  origin: given
  internal structure: elementary
  embedment: {set, time}
  features:
    - id: f_title
      value structure: atomic
      value type: text
      description: "Paper title"
    - id: f_abstract
      value structure: atomic
      value type: text
      description: "Paper abstract"
    - id: f_keywords
      value structure: list
      value type: categorical
      description: "Author/venue keywords"
    - id: f_authors
      value structure: list
      value type: reference
      description: "Disambiguated author identifiers"
    - id: f_citations
      value structure: list
      value type: reference
      description: "References to other papers"
  description: "3596 IEEE VIS (Vis/InfoVis/VAST/SciVis) papers, 1990-2024"

artifact K_prior_domain_knowledge : knowledge(D_papers)
  origin: given
  representation form: "informal domain expertise"
  description: "Analyst's prior knowledge of known VIS research groups,
    leading researchers, institutional moves, and historical events, used
    throughout to validate detected communities, threads, and topics"

# ============================================================================
# STEP 1: EXTRACT AUTHOR ENTITIES
# ============================================================================

transform T_extract_authors :
  intent: define-unit
  manner: "extract distinct entities (disambiguated authors)"
  input: D_papers
  output: D_authors
  actor: machine
  description: "Extract the set of distinct disambiguated authors referenced
    across the paper corpus"

artifact D_authors : entities
  internal structure: elementary
  embedment: {set, time}
  features:
    - id: f_active_years
      value structure: list
      value type: temporal
      description: "Years in which the author published at IEEE VIS"
  description: "Disambiguated VIS authors, 1990-2024"

# ============================================================================
# STEP 2: CONSTRUCT NETWORK SNAPSHOTS AND FULL-PERIOD ANCHOR NETWORK
# ============================================================================

artifact S_windowing : specification
  origin: given
  representation form: "parameter settings"
  description: "Window length and stride for overlapping time windows
    (e.g., 5-year windows advancing by 2 years)"

transform T_build_windows :
  intent: define-unit
  manner: "time-partitioning with overlapping windows; aggregate
    co-authorship edges per window"
  input: D_papers, D_authors, S_windowing
  output: D_networks
  actor: machine
  description: "Partition the publication timeline into overlapping windows
    and build one weighted co-authorship network snapshot per window"

artifact D_networks : entities
  internal structure: formation
  embedment: time
  features:
    - id: f_edge_weight
      value structure: atomic
      value type: numeric
      description: "Number of co-authored papers between two authors within
        the window"
    - id: f_window_span
      value structure: atomic
      value type: temporal
      description: "Time span covered by the window"
  description: "Co-authorship network snapshots, one per overlapping time
    window"

transform T_build_anchor :
  intent: define-unit
  manner: "aggregate co-authorship edges across the full period"
  input: D_papers, D_authors
  output: D_network_full
  actor: machine
  description: "Build a single full-period co-authorship network to serve
    as a stable long-run reference structure"

artifact D_network_full : entities
  internal structure: formation
  features:
    - id: f_edge_weight
      value structure: atomic
      value type: numeric
      description: "Number of co-authored papers between two authors across
        the full 1990-2024 period"
  description: "Full-period reference co-authorship network (single entity)"

# ============================================================================
# STEP 3: COMMUNITY-DETECTION RESOLUTION LOOP
# ============================================================================

artifact S_community_params : specification
  origin: given
  representation form: "method choice and parameter settings"
  description: "Initial community-detection algorithm (e.g., Leiden) and
    resolution parameter, applied identically to anchor and windowed
    networks"

loop L_community_detection:
  purpose: "Detect communities on the anchor network and on each windowed
    snapshot at a resolution that yields analytically meaningful,
    interpretable community structure"
  until: "Community counts and sizes are neither over-fragmented nor overly
    coarse, and communities are visually cohesive and consistent with
    known VIS research groups"
  body:

    transform T_detect_anchor_communities :
      intent: define-unit
      manner: "cluster-by-similarity (community detection on full-period
        network)"
      input: D_network_full, S_community_params
      output: D_anchor_communities, F_anchor_membership
      actor: machine
      description: "Detect long-run reference communities on the full-period
        network"

    artifact D_anchor_communities : entities
      internal structure: group/cluster
      embedment: set
      description: "Long-term reference communities detected on the
        full-period network"

    artifact F_anchor_membership : feature(D_authors)
      value structure: atomic
      value type: categorical
      description: "Anchor community assignment for each author"

    transform T_detect_window_communities :
      intent: define-unit
      manner: "cluster-by-similarity (community detection per window)"
      input: D_networks, S_community_params
      output: D_window_communities, F_community_members
      actor: machine
      description: "Detect communities independently within each windowed
        network snapshot"

    artifact D_window_communities : entities
      internal structure: group/cluster
      embedment: {set, time}
      description: "Communities detected within each time-window network
        snapshot"

    artifact F_community_members : feature(D_window_communities)
      value structure: list
      value type: reference
      description: "Author members belonging to each community instance"

    transform T_contextualise_projection :
      intent: contextualise
      manner: "projection-based (embed community-window instances by member
        similarity)"
      input: D_window_communities, F_community_members
      output: D_projection_space, A_projection_communities
      actor: machine
      description: "Compute a 2D projection space in which community-window
        instances close in membership/time appear near each other, and
        arrange instances within it"

    artifact D_projection_space : entities
      internal structure: elementary
      features:
        - id: f_dimensions
          value structure: atomic
          value type: numeric
          description: "Number of projection dimensions (2)"
      description: "Computed 2D projection space for community-window
        instances"

    artifact A_projection_communities : arrangement(D_window_communities)
      context: D_projection_space
      principle: "similarity-preserving projection based on member overlap"
      description: "Positions of community-window instances in projection
        space"

    transform T_vis_overview :
      intent: visualise
      manner: "2D projection with temporal trails"
      input: A_projection_communities, D_anchor_communities, F_anchor_membership
      output: V_community_states
      actor: machine
      description: "Show community-window instances in projection space,
        coloured by anchor community, to assess granularity and cohesion"

    artifact V_community_states : visualisation(A_projection_communities,
        F_anchor_membership)
      layout: "2D projection"
      form: "coloured points with temporal trail lines"
      encoding: "position from A_projection_communities; colour from
        F_anchor_membership; trails connect same-authorship-dominant
        instances across adjacent windows"
      description: "Overview for judging whether detected communities are
        cohesive, distinct, and stable across time"

    transform T_assess_resolution :
      intent: assess
      manner: "evaluate community granularity and cohesion"
      input: V_community_states, D_window_communities, D_anchor_communities,
             K_prior_domain_knowledge
      output: K_resolution_quality
      actor: human
      description: "Judge whether the current resolution parameter yields
        interpretable, stable communities consistent with known VIS
        research groups"

    artifact K_resolution_quality : knowledge(D_window_communities,
        D_anchor_communities)
      representation form: "quality judgment"
      description: "Judgment of whether community granularity is adequate
        or requires adjustment"

    if K_resolution_quality indicates refinement needed:
      then:
        transform T_refine_resolution :
          intent: generate-knowledge
          manner: "formulate revised community-detection specification"
          input: K_resolution_quality, S_community_params
          output: S_community_params_r
          actor: human
          description: "Decide on a revised resolution parameter or
            algorithm variant"

        artifact S_community_params_r : specification
          representation form: "method choice and parameter settings"
          description: "Revised community-detection configuration"

        assign:
          S_community_params := S_community_params_r
      else:
        exit loop L_community_detection

end loop L_community_detection

# ============================================================================
# STEP 4: CROSS-TIME MATCHING AND COMMUNITY THREADS
# ============================================================================

transform T_characterise_overlap :
  intent: characterise
  manner: "define-relations (membership overlap between temporally adjacent
    community instances)"
  input: D_window_communities, F_community_members
  output: F_community_overlap
  actor: machine
  description: "Compute Jaccard-style member overlap between every pair of
    community instances in temporally adjacent windows"

artifact F_community_overlap : feature(D_window_communities)
  value structure: relational configuration
  value type: numeric
  representation form: "weighted directed graph linking community instances
    in adjacent time windows by member-overlap weight"
  description: "Overlap-based linkage used to trace community continuity"

transform T_trace_threads :
  intent: define-unit
  manner: "trace continuity chains across time (merge-groups via overlap
    linkage)"
  input: D_window_communities, F_community_overlap
  output: D_community_threads
  actor: hybrid
  description: "Chain community-window instances into long-run trajectories
    wherever member overlap is strong; propose thread identities for
    analyst review"

artifact D_community_threads : entities
  internal structure: sequence
  embedment: set
  features:
    - id: f_thread_span
      value structure: atomic
      value type: temporal
      description: "First and last window of the thread"
    - id: f_thread_size_trend
      value structure: vector
      value type: numeric
      description: "Member count per window along the thread"
  description: "Long-run community trajectories chained from per-window
    community instances"

# ============================================================================
# STEP 5: VISUALISE EVOLUTION AND DETECT STRUCTURAL EVENTS
# ============================================================================

transform T_contextualise_alluvial :
  intent: contextualise
  manner: "flow-based layout (alluvial ordering by time and thread)"
  input: D_community_threads, D_window_communities
  output: A_alluvial
  actor: machine
  description: "Order community instances along a temporal flow layout
    grouped by thread"

artifact A_alluvial : arrangement(D_window_communities)
  context: D_community_threads
  principle: "temporal flow ordering; vertical position by thread membership,
    ribbon width by community size"
  description: "Layout underlying an alluvial/stream diagram of community
    evolution"

transform T_vis_alluvial :
  intent: visualise
  manner: "alluvial/stream diagram"
  input: A_alluvial, F_community_overlap
  output: V_alluvial
  actor: machine
  description: "Display community size and flow of membership across time,
    exposing persistence, merges, splits, emergence, and dissolution"

artifact V_alluvial : visualisation(A_alluvial, F_community_overlap)
  layout: "alluvial/stream diagram"
  form: "flow ribbons with width encoding community size"
  encoding: "horizontal axis: time windows; ribbons: F_community_overlap
    linkage strength between adjacent-window communities"
  description: "Primary overview for answering how many communities exist
    and how they merge, split, or dissolve over time"

transform T_detect_events :
  intent: abstract
  manner: "perception-and-interpretation (identify merge/split/emergence/
    dissolution events)"
  input: V_alluvial, F_community_overlap, D_community_threads,
         K_prior_domain_knowledge
  output: P_evolution_events
  actor: human
  description: "Visually identify and label points where threads merge,
    split, newly emerge, or dissolve, cross-checked against known VIS
    community history"

artifact P_evolution_events : pattern(D_community_threads)
  representation form: "labelled structural events (merge, split, emergence,
    dissolution) with time windows and involved thread IDs"
  description: "Identified structural transition events in the community
    evolution"

# ============================================================================
# STEP 6: CORE STABILITY AND LEADERSHIP CHARACTERISATION
# ============================================================================

transform T_characterise_author_roles :
  intent: characterise
  manner: "compute tenure, centrality, and cross-membership per author"
  input: D_authors, D_community_threads, D_networks, F_community_members
  output: F_author_role_metrics
  actor: machine
  description: "For each author and each thread they belong to, compute
    tenure (fraction of thread windows present), average network centrality
    within the community, and count of distinct threads/communities joined"

artifact F_author_role_metrics : feature(D_authors)
  value structure: vector
  value type: numeric
  description: "Per-author tenure, centrality, and cross-membership metrics"

transform T_classify_roles :
  intent: define-unit
  manner: "cluster-by-similarity / rule-based classification (core,
    peripheral, boundary-spanning)"
  input: D_authors, F_author_role_metrics
  output: D_author_roles, F_role_label
  actor: hybrid
  description: "Classify authors into core (high tenure, high centrality),
    peripheral (short tenure, low centrality), or boundary-spanning
    (member of multiple communities) role categories"

artifact D_author_roles : entities
  internal structure: group/cluster
  embedment: set
  description: "Groups of authors sharing similar role profiles"

artifact F_role_label : feature(D_authors)
  value structure: atomic
  value type: categorical
  description: "Assigned role category per author"

# ============================================================================
# STEP 7: STRUCTURAL DRILL-DOWN AND CORRECTION LOOP
# ============================================================================

loop L_structure_inspection:
  purpose: "Inspect the internal structure and leadership of selected
    community threads to validate thread linkage and role classification"
  until: "The analyst has examined a representative sample of threads and
    periods and is satisfied that thread continuity and role labels are
    consistent with domain knowledge"
  body:

    transform T_select_instance :
      intent: define-unit
      manner: "filter (analyst selects a thread and time window of
        interest)"
      input: D_community_threads, V_alluvial
      output: D_selected_window_community
      actor: human
      description: "Select a single community-window instance for detailed
        inspection"

    artifact D_selected_window_community : entities
      internal structure: group/cluster
      embedment: set
      description: "Single community instance selected for detailed
        inspection"

    transform T_contextualise_nodetrix :
      intent: contextualise
      manner: "hybrid matrix/node-link layout (dense core as matrix,
        bridging ties as node-link)"
      input: D_selected_window_community, D_networks, F_role_label
      output: A_nodetrix
      actor: machine
      description: "Arrange the selected community's dense collaboration
        core as an adjacency matrix while rendering bridging ties to other
        communities as node-link edges"

    artifact A_nodetrix : arrangement(D_selected_window_community)
      context: D_networks
      principle: "NodeTrix-style layout: densely connected core as matrix,
        sparser bridging ties as node-link edges"
      description: "Hybrid layout exposing core/leader structure and
        boundary-spanning ties"

    transform T_vis_nodetrix :
      intent: visualise
      manner: "node-link + matrix hybrid diagram"
      input: A_nodetrix, F_role_label, F_author_role_metrics
      output: V_nodetrix
      actor: machine
      description: "Display the selected community's internal structure,
        coloured by role classification"

    artifact V_nodetrix : visualisation(A_nodetrix, F_role_label)
      layout: "hybrid matrix/node-link"
      form: "adjacency matrix cells for the core, node-link edges for
        bridging ties"
      encoding: "matrix/edge presence from A_nodetrix; node colour from
        F_role_label"
      description: "Detailed view of a single community's core and
        boundary-spanning structure"

    transform T_contextualise_timeline :
      intent: contextualise
      manner: "relative time alignment (one track per author)"
      input: D_authors, D_community_threads, F_community_members, D_networks
      output: A_author_timeline
      actor: machine
      description: "Arrange authors as parallel tracks positioned along
        the shared time axis defined by the network windows, coloured
        segments indicating which thread the author belongs to at each
        window"

    artifact A_author_timeline : arrangement(D_authors)
      context: D_networks
      principle: "one horizontal track per author positioned along time
        windows"
      description: "Per-author community-membership timeline arrangement"

    transform T_vis_timeline :
      intent: visualise
      manner: "scarf-plot / aligned timeline diagram"
      input: A_author_timeline, F_role_label
      output: V_author_timeline
      actor: machine
      description: "Show each author's community membership over time,
        revealing loyal core members versus movers"

    artifact V_author_timeline : visualisation(A_author_timeline, F_role_label)
      layout: "aligned per-author timelines"
      form: "coloured segments per time window"
      encoding: "track position: author; colour: community/thread
        membership per window; opacity: role from F_role_label"
      description: "Author-level view of membership stability and drift"

    transform T_assess_structure :
      intent: assess
      manner: "judge consistency of thread linkage and role labels with
        domain knowledge"
      input: V_nodetrix, V_author_timeline, P_evolution_events,
             K_prior_domain_knowledge
      output: K_structure_assessment
      actor: human
      description: "Decide whether the selected thread's continuity or role
        labels need manual correction"

    artifact K_structure_assessment : knowledge(D_community_threads,
        F_role_label)
      representation form: "quality judgment with diagnostic notes"
      description: "Judgment on whether thread linkage or role
        classification requires correction for the inspected instance"

    if K_structure_assessment indicates correction needed:
      then:
        transform T_correct_threads :
          intent: define-unit
          manner: "manual correction of thread linkage"
          input: D_community_threads, K_structure_assessment,
                 F_community_overlap
          output: D_community_threads_r
          actor: human
          description: "Manually relink, split, or merge thread segments
            based on domain knowledge"

        artifact D_community_threads_r : entities
          internal structure: sequence
          embedment: set
          description: "Corrected community threads"

        transform T_correct_roles :
          intent: define-unit
          manner: "manual correction of role classification"
          input: D_author_roles, F_role_label, K_structure_assessment
          output: D_author_roles_r, F_role_label_r
          actor: human
          description: "Manually adjust role labels found inconsistent with
            domain knowledge"

        artifact D_author_roles_r : entities
          internal structure: group/cluster
          embedment: set
          description: "Corrected author role groups"

        artifact F_role_label_r : feature(D_authors)
          value structure: atomic
          value type: categorical
          description: "Corrected role labels"

        assign:
          D_community_threads := D_community_threads_r
          D_author_roles := D_author_roles_r
          F_role_label := F_role_label_r
      else:
        # No correction needed for this instance; analyst continues
        # inspecting further threads/periods, or stops when satisfied.
        assign:
          D_community_threads := D_community_threads

end loop L_structure_inspection

# ============================================================================
# STEP 8: RESEARCH-FOCUS EXTRACTION VIA TOPIC MODELLING
# ============================================================================

transform T_characterise_text :
  intent: characterise
  manner: "encode (text feature extraction from title/abstract/keywords)"
  input: D_papers
  output: F_text_features
  actor: machine
  description: "Encode each paper's title, abstract, and keywords as a
    numeric text representation"

artifact F_text_features : feature(D_papers)
  value structure: vector
  value type: numeric
  representation form: "TF-IDF or embedding vector per paper"
  description: "Numeric text representation of each paper"

artifact S_topic_params : specification
  origin: given
  representation form: "parameter settings"
  description: "Initial number of topics and NMF configuration"

loop L_topic_modelling:
  purpose: "Fit and refine a topic model whose topics are interpretable as
    recognisable VIS research foci"
  until: "Topics are coherent, mutually distinct, and readily nameable by
    the analyst"
  body:

    transform T_fit_topics :
      intent: build-model
      manner: "fit-topic-model (NMF)"
      input: F_text_features, S_topic_params
      output: M_topic_model
      actor: machine
      description: "Fit a non-negative matrix factorisation topic model
        over the paper corpus"

    artifact M_topic_model : model(F_text_features)
      model type: "topic model"
      representation form: "non-negative matrix factorisation (W,H)"
      description: "Topic model over the VIS paper corpus"

    transform T_compute_paper_topics :
      intent: characterise
      manner: "project (compute per-paper topic-mixture from model)"
      input: D_papers, M_topic_model
      output: F_paper_topic_mixture
      actor: machine
      description: "Compute each paper's topic-mixture weights"

    artifact F_paper_topic_mixture : feature(D_papers)
      value structure: vector
      value type: numeric
      description: "Topic-mixture weights per paper"

    transform T_vis_topics :
      intent: visualise
      manner: "ranked term lists / topic-word matrix"
      input: M_topic_model, F_paper_topic_mixture
      output: V_topics
      actor: machine
      description: "Display top terms and representative papers per topic"

    artifact V_topics : visualisation(M_topic_model, F_paper_topic_mixture)
      layout: "topic-word matrix with representative-paper lists"
      form: "ranked term lists, bar charts"
      encoding: "topic ranked by weight from M_topic_model; representative
        papers ranked by F_paper_topic_mixture"
      description: "View for judging topic coherence and interpretability"

    transform T_interpret_topics :
      intent: abstract
      manner: "name-patterns (assign labels to topics)"
      input: V_topics
      output: P_topics
      actor: human
      description: "Interpret and name topics based on top terms and
        representative papers"

    artifact P_topics : pattern(M_topic_model)
      representation form: "named topic descriptions (label + representative
        terms/papers)"
      description: "Interpreted research-focus topics"

    transform T_assess_topics :
      intent: assess
      manner: "judge topic coherence and distinctiveness"
      input: V_topics, P_topics
      output: K_topic_quality
      actor: human
      description: "Decide whether the topic model needs refinement (merge,
        split, or change topic count)"

    artifact K_topic_quality : knowledge(M_topic_model, P_topics)
      representation form: "quality judgment"
      description: "Judgment on topic coherence and whether refinement is
        needed"

    if K_topic_quality indicates refinement needed:
      then:
        transform T_refine_topic_params :
          intent: generate-knowledge
          manner: "formulate revised topic-model specification"
          input: K_topic_quality, S_topic_params
          output: S_topic_params_r
          actor: human
          description: "Decide on a revised topic count or model
            configuration"

        artifact S_topic_params_r : specification
          representation form: "parameter settings"
          description: "Revised topic-model configuration"

        assign:
          S_topic_params := S_topic_params_r
      else:
        exit loop L_topic_modelling

end loop L_topic_modelling

# ============================================================================
# STEP 9: COMMUNITY RESEARCH-FOCUS PROFILES AND THEIR EVOLUTION
# ============================================================================

transform T_aggregate_community_topics :
  intent: characterise
  manner: "aggregate (average paper topic-mixtures per community instance)"
  input: D_window_communities, F_community_members, F_paper_topic_mixture
  output: F_community_topic_profile
  actor: machine
  description: "Aggregate the topic-mixtures of papers authored within each
    community instance into a single topic profile"

artifact F_community_topic_profile : feature(D_window_communities)
  value structure: vector
  value type: numeric
  description: "Aggregated topic-mixture profile per community instance"

transform T_contextualise_topic_matrix :
  intent: contextualise
  manner: "grid-based (community threads x time windows)"
  input: D_community_threads, D_networks
  output: A_topic_matrix
  actor: machine
  description: "Arrange community threads and time windows into a matrix
    grid for small-multiples display of topic evolution"

artifact A_topic_matrix : arrangement(D_community_threads)
  context: D_networks
  principle: "rows = community threads; columns = time windows"
  description: "Grid layout for topic-evolution small multiples"

transform T_vis_topic_evolution :
  intent: visualise
  manner: "matrix/small-multiples plot of topic profiles"
  input: A_topic_matrix, F_community_topic_profile, P_topics
  output: V_topic_evolution
  actor: machine
  description: "Show each community thread's topic profile per time window
    as small multiples, labelled with named topics"

artifact V_topic_evolution : visualisation(A_topic_matrix,
    F_community_topic_profile, P_topics)
  layout: "matrix grid (threads x windows)"
  form: "small-multiple stacked bar/area charts"
  encoding: "cell position from A_topic_matrix; bar segments from
    F_community_topic_profile; segment labels from P_topics"
  description: "Primary view for answering what each community's research
    foci are and how they evolve"

# ============================================================================
# STEP 10: CROSS-COMMUNITY MEMBERSHIP OVERLAP
# ============================================================================

transform T_characterise_period_overlap :
  intent: characterise
  manner: "define-relations (pairwise membership overlap within the same
    time window)"
  input: D_window_communities, F_community_members
  output: F_period_overlap_matrix
  actor: machine
  description: "Compute pairwise Jaccard overlap among communities
    coexisting within the same time window"

artifact F_period_overlap_matrix : feature(D_window_communities)
  value structure: matrix
  value type: numeric
  representation form: "pairwise overlap matrix among co-existing
    communities per window"
  description: "Within-period membership overlap between communities"

transform T_vis_overlap_matrix :
  intent: visualise
  manner: "matrix-plot"
  input: F_period_overlap_matrix
  output: V_overlap_matrix
  actor: machine
  description: "Display the within-period community overlap matrix,
    faceted by time window"

artifact V_overlap_matrix : visualisation(F_period_overlap_matrix)
  layout: "matrix grid, one facet per time window"
  form: "coloured matrix cells"
  encoding: "cell colour from F_period_overlap_matrix overlap value"
  description: "View for identifying converging, diverging, or
    near-duplicate communities within a period"

transform T_assess_overlap :
  intent: assess
  manner: "identify candidate merges or eroding distinctiveness"
  input: V_overlap_matrix, K_prior_domain_knowledge
  output: K_overlap_assessment
  actor: human
  description: "Flag community pairs with persistently high overlap as
    candidates for merger or loss of distinct identity"

artifact K_overlap_assessment : knowledge(F_period_overlap_matrix)
  representation form: "quality judgment with flagged pairs"
  description: "Judgment identifying community pairs at risk of merging or
    losing distinctiveness"

# ============================================================================
# STEP 11: SYNTHESISE FINDINGS
# ============================================================================

transform T_synthesise :
  intent: generate-knowledge
  manner: "formulate-statements"
  input: P_evolution_events, F_author_role_metrics, F_role_label, P_topics,
         V_topic_evolution, K_overlap_assessment, K_structure_assessment
  output: K_findings
  actor: human
  description: "Synthesise the analyst's answers regarding the number and
    stability of communities, their core leadership, their research foci
    and evolution, cross-community membership overlap, and merge/split/
    dissolution events"

artifact K_findings : knowledge(D_community_threads, P_topics)
  representation form: "statements and insights"
  description: "Consolidated findings on the intellectual structure and
    evolution of the IEEE VIS collaboration community"

Notes on Design Departures from the Natural-Language Version

• Network snapshots as first-class entities: Rather than treating time-windowed subgraphs as an intermediate data structure, I modelled them directly as D_networks with internal structure: formation / embedment: time — this is exactly the structure ATWL's own specification illustrates for dynamic networks (artifact D3 in the spec), and it made the anchor-vs-window duality (from MobilityGraphs) fall out naturally as two define-unit calls on the same underlying data rather than a separate "Phase."

• Three flat, non-nested loops instead of six phases: ATWL's guidance to avoid nested loops in templates, and its explicit vocabulary for both explicit-assessment and implicit-termination loop styles, suggested collapsing my earlier six-phase narrative into three genuinely iterative units — community-resolution tuning, structural drill-down/correction, and topic-model refinement — each matching one of the places where the analyst's visual judgement actually gates further computation (per SOMFlow's and the example workflow's provenance-tracked refinement pattern).

• assess → generate-knowledge/define-unit correction pattern: Following the example workflow's T_assess_model → conditional → T_refine_model pattern, I used assess strictly for evaluative judgments and routed parameter changes through generate-knowledge (producing specification artifacts, per the spec's explicit note that this is the intent's typical role for methodological decisions) while routing substantive corrections (thread relinking, role relabelling) through define-unit, since these actually redefine analysis units rather than merely configure a downstream transform.

• NodeTrix and scarf-plot views placed inside a dedicated inspection loop with corrective branches: This reflects the task's explicit requirement that "the analyst will need to inspect intermediate results visually... and make judgements at each stage" more directly than a linear phase sequence would — the loop's assess/conditional lets a single instance's inspection trigger propagated corrections to D_community_threads and F_role_label without terminating the loop, an intentional (if slightly non-canonical) use of ATWL's conditional construct independent of loop-exit.