Raw session log. Atwl spec + one worked example (hitl).
4 turns (2 user · 2 assistant) json raw log
You have received two files: the ATWL specification, which defines a formal language for representing visual analytics workflows, and an example workflow expressed in ATWL. Please read both carefully before we proceed.
The ATWL specification describes the language's artifact types, transform intents, actor designations, loop constructs, and syntax. The example workflow illustrates how these elements are used together to describe a specific visual analytics process. Note that the example represents one type of workflow among many possible; its specific analytical structure reflects its particular task and should not be treated as a template that must be followed for other tasks. What the example illustrates is how the language is used — the syntax, the vocabulary, and the conventions for organising artifacts, transforms, and loops — not what analytical structure any given task requires.
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, and to express your recommendation both in natural language (for readability) and in ATWL (for structural precision). The natural-language description should explain the analytical logic of the workflow; the ATWL representation should formally specify the artifacts, transforms, loops, actors, and control flow.
Before we proceed, could you briefly confirm that you have understood the ATWL specification and the example, and let me know if you have any questions about the language or the syntax?
You need to reply in English.
I've carefully read through the ATWL specification and the example workflow. Here's my understanding:
Core structure: Workflows are built from artifacts (entities, feature, arrangement, visualisation, pattern, model, knowledge, specification) and transforms that consume/produce them, each with a single intent (define-unit, characterise, contextualise, visualise, abstract, build-model, generate-knowledge, assess), an optional manner specialisation, and an actor (human/machine/hybrid).
Artifacts: Each type has specific fields — e.g., entities carry internal structure and embedment (with a clear distinction between the two: internal structure organizes components within an entity, embedment organizes entities relative to each other); features declare value structure/value type; arrangements map entities into a context; visualisations specify layout/form/encoding; patterns are abstract regularities (not raw data); models generalize beyond observed data; knowledge is either derived (generate-knowledge) or injected (origin: given), and evaluative (from assess) vs. substantive (from generate-knowledge); specifications encode control/configuration decisions.
Control structures: loop (with purpose/until, either implicit or via explicit assess+conditional+exit loop), if/then/else conditionals, and assign for iterative artifact updates. Templates can compactly summarize stages, optionally using loop(...) notation.
Example takeaway: The HITL workflow shows a human-in-the-loop pattern-recognition pipeline (partition → characterise → iterative clustering/feature refinement loop → labelling → model training → iterative model refinement loop → synthesise knowledge). I understand this is one illustrative structure — reflecting its specific iterative, exploratory, model-building task — not a mandatory template. Other tasks (e.g., purely descriptive analyses, comparative analyses, single-pass exploratory visualisation) would call for different artifact/transform arrangements, possibly with no loops at all, or different intent sequences.
I have no outstanding questions about the syntax or vocabulary — I'm ready. Please go ahead and describe the visual analytics design task you'd like me to model.
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.
For each time window, I'll apply community detection algorithms like Louvain to identify author clusters, then characterize what each community studies by extracting topics from their papers' titles, abstracts, and keywords. The trickier part is tracking community stability—I need to measure how author groups persist or shift between consecutive time slices by computing overlap metrics and identifying which members stay together versus move to different communities, essentially creating lineages that show how research groups evolve. Then I'll need to visualize this evolution using alluvial diagrams or network layouts, detect structural events like when communities merge, split, or dissolve, and build in a refinement loop where domain experts can adjust clustering parameters and re-run the analysis to improve results. The final step synthesizes all this into knowledge artifacts describing each community's identity, leadership patterns, and how their research focus changes over time.
For the actual workflow design, I'm starting by defining authors as the analysis units — extracting unique author identifiers from the paper records using DBLP IDs. The papers themselves are the base entities with elementary structure, positioned temporally by publication year, and carrying features like author lists (as references to author IDs), titles, abstracts, keywords, and citation counts. Citations might also help characterize influence and leadership roles within communities, though the primary focus is co-authorship structure.
To capture how communities evolve, I'm partitioning papers into time windows — probably 5-year sliding windows — then constructing co-authorship networks within each window by identifying which authors collaborated based on shared paper authorship. I need to track author activity across time windows, so I'm considering whether to represent this as author-window pairs or as network snapshots per window. The network snapshot approach mirrors the dynamic network pattern better—each snapshot captures the co-authorship graph for a specific time period with edge weights representing the number of papers co-authored between pairs of authors within that window.
From those snapshots, I can apply community detection algorithms like Louvain to identify clusters of authors, creating communities as entities with their own internal structure and time-based embedment. Then I'd compute features for each community—size, density, and stability metrics—though tracking stability across time requires matching communities between consecutive windows to see how they evolve.
I'd calculate community similarity using Jaccard overlap of membership between adjacent time windows, building a temporal matching graph. Then I'd merge matched communities across time into persistent lineages or "community tracks"—meta-entities that capture how communities split, merge, or persist as sequences or formation graphs over time.
From these lineage structures, I can directly extract lifecycle events (merge, split, dissolve, persist) as typed event annotations. I'd also need to characterize the stable core of each community track—identifying which authors consistently appear across most time windows—to understand membership stability within each tracked community.
Beyond membership dynamics, I should apply text mining to the papers within each community across time windows to extract research topics and track how research foci evolve alongside the community structure itself. This requires fitting topic models and then abstracting the results into named research focus patterns that can be tracked longitudinally, similar to how I'm tracking community lifecycles. The whole pipeline is getting intricate, so I need to structure it with clear stages and build in loops for human refinement of both the community detection parameters and the interpretive labels.
Since the analyst wants to visually inspect and validate results at each step using domain knowledge, I should incorporate feedback loops for tuning the Louvain resolution parameter and for validating community lifecycle events and research focus labels interactively. For visualization, I'm planning node-link diagrams of the co-authorship network per time window with communities color-coded to assess quality, and then alluvial or Sankey diagrams to show how communities flow and transform across time windows.
I'm also considering streamgraphs for tracking topic evolution within communities and a timeline or heatmap showing which core authors persist across years. To manage this complexity, I'm structuring the workflow into distinct phases: first preparing the data by defining authors and time windows and building network snapshots, then iterating through community detection with visualization and quality assessment, and finally tracking how communities evolve and merge or split across consecutive snapshots.
After that comes characterizing the core members and leadership stability within each community track, then building topic models on the papers within each community to identify and visualize research foci evolution. The final phase synthesizes everything—integrating community dynamics, stability patterns, and topic shifts into a coherent narrative about the field's evolution. completing the community lifecycle model with topic modeling and evolution tracking, then defining the data entities like papers with their temporal positioning and author references.
Now I'm specifying the partitioning step to break papers into overlapping time windows, which requires both analyst input for window parameters and automated execution of the actual partitioning logic.
I'm defining the windowing specification artifact that captures the temporal window configuration—like 5-year windows advancing by 1 year—and then describing the resulting data structure where each window groups papers together as a temporal snapshot of the network.
Now I need to extract authors as global entities across all windows, capturing their activity years, publication count, and citation metrics, since author presence varies temporally even though the author list itself is consistent across the entire period.
For the network analysis, I'm shifting to create network snapshot entities for each time window rather than just computing co-authorship features—each snapshot represents that window's collaboration graph with authors as nodes and co-authored papers as weighted edges. I think modeling the co-authorship graph as a feature rather than an entity artifact is cleaner and aligns better with the spec's guidance on relational configurations. So the transform will characterize the relationships between authors within each window, producing a feature that captures the co-authorship structure, and then community detection can operate on that feature to identify clusters.
Defining transform T_build_networks... be meaningful collaboration groups. I'm applying a community detection algorithm like Louvain or Leiden to each window's co-authorship network to identify clusters of densely collaborating authors, using configurable parameters that control how fine-grained the detected communities are.
Now I'm defining the community structure itself—tracking the size of each author group and assigning a community membership label to each author within their time window. Then I'm visualizing these networks as node-link diagrams where nodes are colored by their detected community, making it easy to visually inspect how the collaboration groups separate and evolve. I'm capturing the quality assessment as a knowledge artifact, then checking if the community detection needs refinement—if so, I'll adjust the parameters based on that judgment and update the specification accordingly.
Now I'm moving on to track how communities evolve across time windows by computing membership overlap between consecutive detections, which will help establish lineage and correspondence relationships.
Then I'm building longitudinal community tracks by linking corresponding instances across windows, allowing for splits and merges as communities change over time.
Now I need to identify lifecycle events—persistence, merging, splitting, dissolution, emergence—by examining the linkage structure and cross-referencing with visual snapshots of the network.
These events get labeled with timestamps and event types, capturing how communities transform across the study period. Then I'm arranging the community tracks along the timeline to set up an alluvial visualization that shows how membership flows and communities evolve over time. Defining the visualization encoding with block widths representing community size, ribbon widths showing shared membership between time periods, and color indicating community identity, along with markers for lifecycle events. Then moving into characterizing core membership by computing for each author their proportion of time windows in a given community lineage to identify stable core members.
Good — I've thought this through. Before showing the design, here's a quick summary of the analytical logic, followed by the formal ATWL specification.
Natural-language description of the workflow
1. Data preparation. Starting from the paper records, the workflow first extracts the disambiguated authors as analysis units (using the DBLP identifiers) and partitions the papers into overlapping multi-year time windows (e.g., 5-year sliding windows). For each window, a weighted co-authorship graph is built among the authors active in that window (edge weight = number of jointly authored papers).
2. Community detection (with human-in-the-loop tuning). A community-detection algorithm (e.g., Louvain/Leiden) is applied to each window's co-authorship graph to produce candidate communities. The analyst visually inspects each window's network with community colouring, judges whether the granularity and separation are meaningful (e.g., communities correspond to recognisable research groups), and — if not — adjusts the algorithm's resolution parameter and re-runs. This loop continues until the communities are judged interpretable and well separated.
3. Tracking communities over time. Once communities are stable within each window, their membership overlap across consecutive windows is computed (e.g., Jaccard similarity), and matched community instances are linked into longitudinal community lineages (tracks), which may branch (split) or converge (merge). The analyst inspects these lineages, together with the per-window network visualisations, to abstract and label lifecycle events: persistence, merge, split, dissolution, emergence. An alluvial/Sankey visualisation of the tracked communities over time supports this interpretation and directly answers questions about membership overlap and evolution.
4. Core stability and leadership. For each community track, the persistence of each author's membership across windows is computed, distinguishing a stable core from peripheral/moving members. Core members are then ranked by productivity and citation influence to identify leaders. A timeline/heatmap visualisation of core-member presence lets the analyst judge each community's stability and formulate statements about leadership continuity and turnover.
5. Research foci and their evolution. A topic model is fit on titles/abstracts/keywords across the whole corpus. Topic proportions are aggregated per community instance and window to obtain an evolving topical profile for each community track. A streamgraph visualises how each community's topic mix shifts over time; the analyst interactively names the dominant research foci and assesses whether the labelling is distinct and stable, refining the topic model if needed.
6. Synthesis. Finally, the analyst integrates the community-tracking results, lifecycle events, core-stability findings, and research-focus evolution into a narrative characterising the intellectual structure of the IEEE VIS community: how many communities exist, how stable their cores/leaders are, what they work on, and how/when they merge, split, or dissolve.
ATWL specification
workflow collaboration-community-evolution
template: define-unit (extract authors) -> define-unit (time-partitioning) ->
characterise (co-authorship network) ->
loop(define-unit (community detection) -> visualise -> assess ->
generate-knowledge (parameter refine)) ->
characterise (community overlap) -> define-unit (track lineages) ->
abstract (lifecycle events) -> contextualise -> visualise (evolution) ->
characterise (core & leadership) -> visualise (core stability) ->
generate-knowledge (stability) ->
build-model (topic model) -> characterise (topic profiles) ->
loop(visualise (foci evolution) -> abstract (name foci) -> assess ->
build-model (refine topics)) ->
generate-knowledge (synthesis)
description: "Identify collaboration communities among IEEE VIS authors over
time, track their evolution (persistence, merges, splits, dissolutions),
characterise the stability of their core/leadership, and relate them to
evolving research foci."
# ============================================================================
# INPUT
# ============================================================================
artifact D_papers : entities
origin: given
internal structure: elementary
embedment: time
features:
- id: authors
value structure: list
value type: reference
description: "DBLP-disambiguated author identifiers"
- id: title
value structure: atomic
value type: text
description: "Paper title"
- id: abstract
value structure: atomic
value type: text
description: "Paper abstract"
- id: keywords
value structure: list
value type: text
description: "Author/venue keywords"
- id: citations
value structure: list
value type: reference
description: "Identifiers of cited papers"
description: "IEEE VIS papers (1990-2024) with authorship, metadata, and
citation links"
# ============================================================================
# STEP 1: EXTRACT AUTHORS AND TIME WINDOWS
# ============================================================================
transform T_extract_authors :
intent: define-unit
manner: "extract"
input: D_papers
output: D_authors
actor: machine
description: "Extract unique disambiguated authors as analysis units from
the paper author lists"
artifact D_authors : entities
internal structure: elementary
embedment: set
features:
- id: active_years
value structure: list
value type: temporal
description: "Years in which the author published"
- id: paper_count
value structure: atomic
value type: numeric
description: "Total number of papers authored"
- id: total_citations
value structure: atomic
value type: numeric
description: "Aggregate citation count"
description: "Disambiguated authors extracted from paper records"
artifact S_windowing : specification
origin: given
representation form: "parameter settings"
description: "Time window length and overlap (e.g., 5-year windows advancing
by 1 year) used to construct temporal snapshots of collaboration"
transform T_partition_time :
intent: define-unit
manner: "time-partitioning with overlapping windows"
input: D_papers, S_windowing
output: D_windows
actor: hybrid
description: "Partition papers into overlapping multi-year time windows to
serve as temporal snapshots for network construction"
artifact D_windows : entities
internal structure: group/cluster
embedment: time
features:
- id: window_span
value structure: atomic
value type: temporal
description: "Start and end year of the window"
description: "Overlapping time windows used as temporal snapshots"
# ============================================================================
# STEP 2: BUILD CO-AUTHORSHIP NETWORKS
# ============================================================================
transform T_build_networks :
intent: characterise
manner: "define-relations (co-authorship)"
input: D_windows, D_authors, D_papers
output: F_coauth_network
actor: machine
description: "For each window, build a weighted co-authorship graph among
authors active in that window (edge weight: number of co-authored papers)"
artifact F_coauth_network : feature(D_windows)
value structure: relational configuration
representation form: "weighted co-authorship graph per window"
description: "Temporal sequence of co-authorship networks, one per window"
# ============================================================================
# STEP 3: COMMUNITY DETECTION LOOP
# ============================================================================
artifact S_community_params : specification
origin: given
representation form: "parameter settings"
description: "Community-detection algorithm choice and resolution parameter"
loop L_community_detection:
purpose: "Detect coherent, interpretable collaboration communities within
each window's network"
until: "Communities show clear separation/cohesion and are judged by the
analyst to correspond to meaningful collaboration groups"
body:
transform T_detect_communities :
intent: define-unit
manner: "cluster-by-similarity (community detection)"
input: F_coauth_network, S_community_params
output: D_communities
actor: machine
description: "Detect densely collaborating groups of authors within
each window's co-authorship network"
artifact D_communities : entities
internal structure: group/cluster
embedment: time
features:
- id: members
value structure: list
value type: reference
description: "Author identifiers belonging to this community
instance"
- id: community_size
value structure: atomic
value type: numeric
description: "Number of authors in the community"
description: "Groups of densely collaborating authors within a given
time window"
transform T_vis_communities :
intent: visualise
manner: "node-link-diagram"
input: F_coauth_network, D_communities
output: V_communities
actor: machine
description: "Display each window's network with nodes coloured by
detected community for visual assessment"
artifact V_communities : visualisation(F_coauth_network, D_communities)
layout: "force-directed layout per time window"
form: "coloured nodes and edges"
encoding: "node colour: community membership; edge thickness:
co-authorship weight"
description: "Per-window views for inspecting community structure"
transform T_assess_communities :
intent: assess
manner: "evaluate-clustering-quality"
input: V_communities, D_communities
output: K_community_quality
actor: human
description: "Judge whether communities are well-separated, cohesive,
and correspond to recognisable research groups"
artifact K_community_quality : knowledge(D_communities)
representation form: "quality judgment"
description: "Assessment of whether community granularity/separation is
adequate or requires parameter adjustment"
if K_community_quality indicates refinement needed:
then:
transform T_refine_params :
intent: generate-knowledge
manner: "adjust method parameters"
input: K_community_quality, S_community_params
output: S_community_params_r
actor: human
description: "Revise resolution parameter/algorithm choice"
artifact S_community_params_r : specification
representation form: "parameter settings"
description: "Updated community-detection parameters"
assign:
S_community_params := S_community_params_r
else:
exit loop L_community_detection
end loop L_community_detection
# ============================================================================
# STEP 4: TRACK COMMUNITIES OVER TIME
# ============================================================================
transform T_match_communities :
intent: characterise
manner: "define-relations (membership overlap)"
input: D_communities
output: F_community_overlap
actor: machine
description: "Compute membership overlap (e.g., Jaccard similarity) between
communities detected in consecutive/overlapping windows"
artifact F_community_overlap : feature(D_communities)
value structure: relational configuration
representation form: "correspondence graph linking community instances
across consecutive windows by membership overlap"
description: "Temporal linkage structure between community instances"
transform T_build_tracks :
intent: define-unit
manner: "merge-groups (track lineages over time)"
input: D_communities, F_community_overlap
output: D_community_tracks
actor: hybrid
description: "Link corresponding community instances into longitudinal
lineages, allowing branching (splits) and convergence (merges)"
artifact D_community_tracks : entities
internal structure: formation
embedment: time
features:
- id: track_span
value structure: atomic
value type: temporal
description: "Time span over which the lineage is observed"
description: "Longitudinal communities represented as lineage graphs of
linked community instances"
transform T_identify_lifecycle_events :
intent: abstract
manner: "perception-and-interpretation"
input: D_community_tracks, F_community_overlap, V_communities
output: P_lifecycle_events
actor: hybrid
description: "Identify and label structural transitions in lineages:
persistence, merge, split, dissolution, emergence"
artifact P_lifecycle_events : pattern(D_community_tracks)
representation form: "typed event annotations (persist/merge/split/
dissolve/emerge) with time points"
description: "Lifecycle events characterising community evolution"
transform T_contextualise_evolution :
intent: contextualise
manner: "relative-time-alignment"
input: D_community_tracks, D_windows
output: A_evolution
actor: machine
description: "Arrange community-track instances along the window timeline
for flow-based visualisation"
artifact A_evolution : arrangement(D_community_tracks)
context: D_windows
principle: "chronological ordering of windows, instances stacked by track
identity"
description: "Temporal arrangement supporting alluvial visualisation"
transform T_vis_evolution :
intent: visualise
manner: "alluvial/Sankey diagram"
input: A_evolution, P_lifecycle_events, F_community_overlap
output: V_evolution
actor: machine
description: "Show community membership flows over time, highlighting
merges, splits, and dissolutions"
artifact V_evolution : visualisation(A_evolution, P_lifecycle_events, F_community_overlap)
layout: "alluvial layout, time on horizontal axis"
form: "coloured flow ribbons and blocks"
encoding: "block width: community size; ribbon width: shared membership;
colour: track identity; markers: lifecycle events"
description: "Overview of community evolution for analyst interpretation"
# ============================================================================
# STEP 5: CORE STABILITY AND LEADERSHIP
# ============================================================================
transform T_characterise_core :
intent: characterise
manner: "compute-statistics (membership persistence)"
input: D_community_tracks, D_communities, D_authors
output: F_core_membership
actor: machine
description: "Compute, per track, each author's persistence across windows,
distinguishing stable core from peripheral/transient members"
artifact F_core_membership : feature(D_community_tracks)
value structure: list
value type: {reference, numeric}
description: "Per-author persistence scores within each community track"
transform T_characterise_leaders :
intent: characterise
manner: "compute-statistics (productivity/citation ranking)"
input: F_core_membership, D_authors
output: F_leadership_score
actor: machine
description: "Rank core members by productivity and citation influence to
identify leading researchers per track"
artifact F_leadership_score : feature(D_community_tracks)
value structure: list
value type: {reference, numeric}
description: "Ranked core members and leadership scores per community track"
transform T_vis_core_stability :
intent: visualise
manner: "coloured-marks (presence heatmap)"
input: F_core_membership, F_leadership_score, D_windows
output: V_core_stability
actor: machine
description: "Timeline/heatmap of core author presence per track across
windows, highlighting stable leaders vs. fluctuating members"
artifact V_core_stability : visualisation(F_core_membership, F_leadership_score, D_windows)
layout: "author x window grid, grouped by community track"
form: "coloured heatmap cells"
encoding: "cell colour: presence and leadership score; rows grouped by track"
description: "Support for inspecting core stability and leadership"
transform T_generate_stability_knowledge :
intent: generate-knowledge
manner: "formulate-statements"
input: V_core_stability, F_core_membership, F_leadership_score
output: K_core_stability
actor: human
description: "Formulate statements on core stability, leadership continuity,
and membership turnover per community"
artifact K_core_stability : knowledge(D_community_tracks, D_authors)
representation form: "statements"
description: "Insights on core stability, leadership continuity, and
membership turnover"
# ============================================================================
# STEP 6: RESEARCH FOCI AND THEIR EVOLUTION
# ============================================================================
transform T_topic_model :
intent: build-model
manner: "fit-topic-model"
input: D_papers
output: M_topics
actor: machine
description: "Fit a topic model on titles/abstracts/keywords to derive
latent research topics"
artifact M_topics : model(D_papers)
model type: "topic model"
representation form: "topic-term distributions and per-paper topic
proportions"
description: "Latent topic structure of the paper corpus"
transform T_characterise_foci :
intent: characterise
manner: "aggregate (topic proportions per community-window)"
input: M_topics, D_community_tracks, D_communities, D_windows
output: F_topic_profile
actor: machine
description: "Aggregate topic proportions of member-authored papers to
obtain an evolving topical profile per community track"
artifact F_topic_profile : feature(D_community_tracks)
value structure: matrix
value type: numeric
representation form: "community-track x topic x window proportions"
description: "Evolving topical profile of each community lineage"
loop L_foci_interpretation:
purpose: "Assign and validate interpretable research-focus labels for each
community's evolving topical profile"
until: "Labels are judged distinct, stable, and accurately reflective of
each community's evolving foci"
body:
transform T_vis_foci_evolution :
intent: visualise
manner: "streamgraph"
input: F_topic_profile, D_windows
output: V_foci_evolution
actor: machine
description: "Display evolving topical composition of each community
track as a streamgraph across windows"
artifact V_foci_evolution : visualisation(F_topic_profile, D_windows)
layout: "streamgraph, time on horizontal axis"
form: "stacked coloured bands"
encoding: "band thickness: topic proportion; colour: topic identity;
faceted by community track"
description: "Support for interpreting shifting research foci"
transform T_name_foci :
intent: abstract
manner: "name-patterns"
input: V_foci_evolution, F_topic_profile, M_topics
output: P_research_foci
actor: human
description: "Assign concise research-focus labels to dominant topics
per community and period"
artifact P_research_foci : pattern(F_topic_profile)
representation form: "labelled sequences of dominant research foci per
community track"
description: "Human-interpreted research-focus labels and their
evolution"
transform T_assess_foci :
intent: assess
manner: "judge-visualisation-adequacy"
input: V_foci_evolution, P_research_foci
output: K_foci_quality
actor: human
description: "Judge whether labels are distinct, stable, and accurate"
artifact K_foci_quality : knowledge(P_research_foci)
representation form: "quality judgment"
description: "Assessment of labelling adequacy"
if K_foci_quality indicates refinement needed:
then:
transform T_refine_topics :
intent: build-model
manner: "adjust topic model parameters"
input: K_foci_quality, D_papers, M_topics
output: M_topics_r
actor: hybrid
description: "Adjust topic count/preprocessing and refit the model"
artifact M_topics_r : model(D_papers)
model type: "topic model"
representation form: "topic-term distributions and per-paper topic
proportions"
description: "Refined topic model"
assign:
M_topics := M_topics_r
else:
exit loop L_foci_interpretation
end loop L_foci_interpretation
# ============================================================================
# STEP 7: SYNTHESISE FINDINGS
# ============================================================================
transform T_synthesise :
intent: generate-knowledge
manner: "formulate-statements"
input: D_community_tracks, P_lifecycle_events, K_core_stability,
P_research_foci, V_evolution
output: K_findings
actor: human
description: "Synthesise the number and stability of communities, leadership
continuity, evolving research foci, and merge/split/dissolution history"
artifact K_findings : knowledge(D_community_tracks, P_research_foci)
representation form: "statements and narrative summary"
description: "Integrated account of the IEEE VIS community's collaboration
structure: major communities, stable cores/leaders, evolving research
foci, and merge/split/dissolution events"