{
  "chat_uuid": "5d275aac-7bf3-488a-be31-1a0516b72edb",
  "history": [
    {
      "content": "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.\n\nThe 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.\n\nIn 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.\n\nBefore 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?\n\nYou need to reply in English.",
      "role": "user"
    },
    {
      "content": "I've carefully read through the ATWL specification and the example workflow. Here's my understanding:\n\n**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).\n\n**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.\n\n**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.\n\n**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.\n\nI 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.",
      "role": "assistant"
    },
    {
      "content": "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).\n\nA 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.\n\nThe 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?\n\nThe analyst will need to inspect intermediate results visually and use domain knowledge to interpret patterns and make judgements at each stage.\n\nDesign an analytical workflow for this problem.",
      "role": "user"
    },
    {
      "content": "<think>I'm mapping out the analytical framework for this co-authorship network study—starting with disambiguated author data from DBLP, then building the network structure where authors are nodes connected through collaborative relationships, and I need to track how these connections and communities evolve across time periods.\n\nFor 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.\n\nFor 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.\n\nTo 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.\n\nFrom 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.\n\nI'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.\n\nFrom 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.\n\nBeyond 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.\n\nSince 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.\n\nI'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.\n\nAfter 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.\n\nNow 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.\n\nI'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.\n\nNow 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.\n\nFor 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.\n\nDefining 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.\n\nNow 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.\n\nNow 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.\n\nThen I'm building longitudinal community tracks by linking corresponding instances across windows, allowing for splits and merges as communities change over time.\n\nNow 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.\n\nThese 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.</think>\n\nGood — I've thought this through. Before showing the design, here's a quick summary of the analytical logic, followed by the formal ATWL specification.\n\n## Natural-language description of the workflow\n\n**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).\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n---\n\n## ATWL specification\n\n```atwl\nworkflow collaboration-community-evolution\n  template: define-unit (extract authors) -> define-unit (time-partitioning) ->\n            characterise (co-authorship network) ->\n            loop(define-unit (community detection) -> visualise -> assess ->\n                 generate-knowledge (parameter refine)) ->\n            characterise (community overlap) -> define-unit (track lineages) ->\n            abstract (lifecycle events) -> contextualise -> visualise (evolution) ->\n            characterise (core & leadership) -> visualise (core stability) ->\n            generate-knowledge (stability) ->\n            build-model (topic model) -> characterise (topic profiles) ->\n            loop(visualise (foci evolution) -> abstract (name foci) -> assess ->\n                 build-model (refine topics)) ->\n            generate-knowledge (synthesis)\n  description: \"Identify collaboration communities among IEEE VIS authors over\n    time, track their evolution (persistence, merges, splits, dissolutions),\n    characterise the stability of their core/leadership, and relate them to\n    evolving research foci.\"\n\n# ============================================================================\n# INPUT\n# ============================================================================\n\nartifact D_papers : entities\n  origin: given\n  internal structure: elementary\n  embedment: time\n  features:\n    - id: authors\n      value structure: list\n      value type: reference\n      description: \"DBLP-disambiguated author identifiers\"\n    - id: title\n      value structure: atomic\n      value type: text\n      description: \"Paper title\"\n    - id: abstract\n      value structure: atomic\n      value type: text\n      description: \"Paper abstract\"\n    - id: keywords\n      value structure: list\n      value type: text\n      description: \"Author/venue keywords\"\n    - id: citations\n      value structure: list\n      value type: reference\n      description: \"Identifiers of cited papers\"\n  description: \"IEEE VIS papers (1990-2024) with authorship, metadata, and\n    citation links\"\n\n# ============================================================================\n# STEP 1: EXTRACT AUTHORS AND TIME WINDOWS\n# ============================================================================\n\ntransform T_extract_authors :\n  intent: define-unit\n  manner: \"extract\"\n  input: D_papers\n  output: D_authors\n  actor: machine\n  description: \"Extract unique disambiguated authors as analysis units from\n    the paper author lists\"\n\nartifact D_authors : entities\n  internal structure: elementary\n  embedment: set\n  features:\n    - id: active_years\n      value structure: list\n      value type: temporal\n      description: \"Years in which the author published\"\n    - id: paper_count\n      value structure: atomic\n      value type: numeric\n      description: \"Total number of papers authored\"\n    - id: total_citations\n      value structure: atomic\n      value type: numeric\n      description: \"Aggregate citation count\"\n  description: \"Disambiguated authors extracted from paper records\"\n\nartifact S_windowing : specification\n  origin: given\n  representation form: \"parameter settings\"\n  description: \"Time window length and overlap (e.g., 5-year windows advancing\n    by 1 year) used to construct temporal snapshots of collaboration\"\n\ntransform T_partition_time :\n  intent: define-unit\n  manner: \"time-partitioning with overlapping windows\"\n  input: D_papers, S_windowing\n  output: D_windows\n  actor: hybrid\n  description: \"Partition papers into overlapping multi-year time windows to\n    serve as temporal snapshots for network construction\"\n\nartifact D_windows : entities\n  internal structure: group/cluster\n  embedment: time\n  features:\n    - id: window_span\n      value structure: atomic\n      value type: temporal\n      description: \"Start and end year of the window\"\n  description: \"Overlapping time windows used as temporal snapshots\"\n\n# ============================================================================\n# STEP 2: BUILD CO-AUTHORSHIP NETWORKS\n# ============================================================================\n\ntransform T_build_networks :\n  intent: characterise\n  manner: \"define-relations (co-authorship)\"\n  input: D_windows, D_authors, D_papers\n  output: F_coauth_network\n  actor: machine\n  description: \"For each window, build a weighted co-authorship graph among\n    authors active in that window (edge weight: number of co-authored papers)\"\n\nartifact F_coauth_network : feature(D_windows)\n  value structure: relational configuration\n  representation form: \"weighted co-authorship graph per window\"\n  description: \"Temporal sequence of co-authorship networks, one per window\"\n\n# ============================================================================\n# STEP 3: COMMUNITY DETECTION LOOP\n# ============================================================================\n\nartifact S_community_params : specification\n  origin: given\n  representation form: \"parameter settings\"\n  description: \"Community-detection algorithm choice and resolution parameter\"\n\nloop L_community_detection:\n  purpose: \"Detect coherent, interpretable collaboration communities within\n    each window's network\"\n  until: \"Communities show clear separation/cohesion and are judged by the\n    analyst to correspond to meaningful collaboration groups\"\n  body:\n\n    transform T_detect_communities :\n      intent: define-unit\n      manner: \"cluster-by-similarity (community detection)\"\n      input: F_coauth_network, S_community_params\n      output: D_communities\n      actor: machine\n      description: \"Detect densely collaborating groups of authors within\n        each window's co-authorship network\"\n\n    artifact D_communities : entities\n      internal structure: group/cluster\n      embedment: time\n      features:\n        - id: members\n          value structure: list\n          value type: reference\n          description: \"Author identifiers belonging to this community\n            instance\"\n        - id: community_size\n          value structure: atomic\n          value type: numeric\n          description: \"Number of authors in the community\"\n      description: \"Groups of densely collaborating authors within a given\n        time window\"\n\n    transform T_vis_communities :\n      intent: visualise\n      manner: \"node-link-diagram\"\n      input: F_coauth_network, D_communities\n      output: V_communities\n      actor: machine\n      description: \"Display each window's network with nodes coloured by\n        detected community for visual assessment\"\n\n    artifact V_communities : visualisation(F_coauth_network, D_communities)\n      layout: \"force-directed layout per time window\"\n      form: \"coloured nodes and edges\"\n      encoding: \"node colour: community membership; edge thickness:\n        co-authorship weight\"\n      description: \"Per-window views for inspecting community structure\"\n\n    transform T_assess_communities :\n      intent: assess\n      manner: \"evaluate-clustering-quality\"\n      input: V_communities, D_communities\n      output: K_community_quality\n      actor: human\n      description: \"Judge whether communities are well-separated, cohesive,\n        and correspond to recognisable research groups\"\n\n    artifact K_community_quality : knowledge(D_communities)\n      representation form: \"quality judgment\"\n      description: \"Assessment of whether community granularity/separation is\n        adequate or requires parameter adjustment\"\n\n    if K_community_quality indicates refinement needed:\n      then:\n        transform T_refine_params :\n          intent: generate-knowledge\n          manner: \"adjust method parameters\"\n          input: K_community_quality, S_community_params\n          output: S_community_params_r\n          actor: human\n          description: \"Revise resolution parameter/algorithm choice\"\n\n        artifact S_community_params_r : specification\n          representation form: \"parameter settings\"\n          description: \"Updated community-detection parameters\"\n\n        assign:\n          S_community_params := S_community_params_r\n      else:\n        exit loop L_community_detection\n\nend loop L_community_detection\n\n# ============================================================================\n# STEP 4: TRACK COMMUNITIES OVER TIME\n# ============================================================================\n\ntransform T_match_communities :\n  intent: characterise\n  manner: \"define-relations (membership overlap)\"\n  input: D_communities\n  output: F_community_overlap\n  actor: machine\n  description: \"Compute membership overlap (e.g., Jaccard similarity) between\n    communities detected in consecutive/overlapping windows\"\n\nartifact F_community_overlap : feature(D_communities)\n  value structure: relational configuration\n  representation form: \"correspondence graph linking community instances\n    across consecutive windows by membership overlap\"\n  description: \"Temporal linkage structure between community instances\"\n\ntransform T_build_tracks :\n  intent: define-unit\n  manner: \"merge-groups (track lineages over time)\"\n  input: D_communities, F_community_overlap\n  output: D_community_tracks\n  actor: hybrid\n  description: \"Link corresponding community instances into longitudinal\n    lineages, allowing branching (splits) and convergence (merges)\"\n\nartifact D_community_tracks : entities\n  internal structure: formation\n  embedment: time\n  features:\n    - id: track_span\n      value structure: atomic\n      value type: temporal\n      description: \"Time span over which the lineage is observed\"\n  description: \"Longitudinal communities represented as lineage graphs of\n    linked community instances\"\n\ntransform T_identify_lifecycle_events :\n  intent: abstract\n  manner: \"perception-and-interpretation\"\n  input: D_community_tracks, F_community_overlap, V_communities\n  output: P_lifecycle_events\n  actor: hybrid\n  description: \"Identify and label structural transitions in lineages:\n    persistence, merge, split, dissolution, emergence\"\n\nartifact P_lifecycle_events : pattern(D_community_tracks)\n  representation form: \"typed event annotations (persist/merge/split/\n    dissolve/emerge) with time points\"\n  description: \"Lifecycle events characterising community evolution\"\n\ntransform T_contextualise_evolution :\n  intent: contextualise\n  manner: \"relative-time-alignment\"\n  input: D_community_tracks, D_windows\n  output: A_evolution\n  actor: machine\n  description: \"Arrange community-track instances along the window timeline\n    for flow-based visualisation\"\n\nartifact A_evolution : arrangement(D_community_tracks)\n  context: D_windows\n  principle: \"chronological ordering of windows, instances stacked by track\n    identity\"\n  description: \"Temporal arrangement supporting alluvial visualisation\"\n\ntransform T_vis_evolution :\n  intent: visualise\n  manner: \"alluvial/Sankey diagram\"\n  input: A_evolution, P_lifecycle_events, F_community_overlap\n  output: V_evolution\n  actor: machine\n  description: \"Show community membership flows over time, highlighting\n    merges, splits, and dissolutions\"\n\nartifact V_evolution : visualisation(A_evolution, P_lifecycle_events, F_community_overlap)\n  layout: \"alluvial layout, time on horizontal axis\"\n  form: \"coloured flow ribbons and blocks\"\n  encoding: \"block width: community size; ribbon width: shared membership;\n    colour: track identity; markers: lifecycle events\"\n  description: \"Overview of community evolution for analyst interpretation\"\n\n# ============================================================================\n# STEP 5: CORE STABILITY AND LEADERSHIP\n# ============================================================================\n\ntransform T_characterise_core :\n  intent: characterise\n  manner: \"compute-statistics (membership persistence)\"\n  input: D_community_tracks, D_communities, D_authors\n  output: F_core_membership\n  actor: machine\n  description: \"Compute, per track, each author's persistence across windows,\n    distinguishing stable core from peripheral/transient members\"\n\nartifact F_core_membership : feature(D_community_tracks)\n  value structure: list\n  value type: {reference, numeric}\n  description: \"Per-author persistence scores within each community track\"\n\ntransform T_characterise_leaders :\n  intent: characterise\n  manner: \"compute-statistics (productivity/citation ranking)\"\n  input: F_core_membership, D_authors\n  output: F_leadership_score\n  actor: machine\n  description: \"Rank core members by productivity and citation influence to\n    identify leading researchers per track\"\n\nartifact F_leadership_score : feature(D_community_tracks)\n  value structure: list\n  value type: {reference, numeric}\n  description: \"Ranked core members and leadership scores per community track\"\n\ntransform T_vis_core_stability :\n  intent: visualise\n  manner: \"coloured-marks (presence heatmap)\"\n  input: F_core_membership, F_leadership_score, D_windows\n  output: V_core_stability\n  actor: machine\n  description: \"Timeline/heatmap of core author presence per track across\n    windows, highlighting stable leaders vs. fluctuating members\"\n\nartifact V_core_stability : visualisation(F_core_membership, F_leadership_score, D_windows)\n  layout: \"author x window grid, grouped by community track\"\n  form: \"coloured heatmap cells\"\n  encoding: \"cell colour: presence and leadership score; rows grouped by track\"\n  description: \"Support for inspecting core stability and leadership\"\n\ntransform T_generate_stability_knowledge :\n  intent: generate-knowledge\n  manner: \"formulate-statements\"\n  input: V_core_stability, F_core_membership, F_leadership_score\n  output: K_core_stability\n  actor: human\n  description: \"Formulate statements on core stability, leadership continuity,\n    and membership turnover per community\"\n\nartifact K_core_stability : knowledge(D_community_tracks, D_authors)\n  representation form: \"statements\"\n  description: \"Insights on core stability, leadership continuity, and\n    membership turnover\"\n\n# ============================================================================\n# STEP 6: RESEARCH FOCI AND THEIR EVOLUTION\n# ============================================================================\n\ntransform T_topic_model :\n  intent: build-model\n  manner: \"fit-topic-model\"\n  input: D_papers\n  output: M_topics\n  actor: machine\n  description: \"Fit a topic model on titles/abstracts/keywords to derive\n    latent research topics\"\n\nartifact M_topics : model(D_papers)\n  model type: \"topic model\"\n  representation form: \"topic-term distributions and per-paper topic\n    proportions\"\n  description: \"Latent topic structure of the paper corpus\"\n\ntransform T_characterise_foci :\n  intent: characterise\n  manner: \"aggregate (topic proportions per community-window)\"\n  input: M_topics, D_community_tracks, D_communities, D_windows\n  output: F_topic_profile\n  actor: machine\n  description: \"Aggregate topic proportions of member-authored papers to\n    obtain an evolving topical profile per community track\"\n\nartifact F_topic_profile : feature(D_community_tracks)\n  value structure: matrix\n  value type: numeric\n  representation form: \"community-track x topic x window proportions\"\n  description: \"Evolving topical profile of each community lineage\"\n\nloop L_foci_interpretation:\n  purpose: \"Assign and validate interpretable research-focus labels for each\n    community's evolving topical profile\"\n  until: \"Labels are judged distinct, stable, and accurately reflective of\n    each community's evolving foci\"\n  body:\n\n    transform T_vis_foci_evolution :\n      intent: visualise\n      manner: \"streamgraph\"\n      input: F_topic_profile, D_windows\n      output: V_foci_evolution\n      actor: machine\n      description: \"Display evolving topical composition of each community\n        track as a streamgraph across windows\"\n\n    artifact V_foci_evolution : visualisation(F_topic_profile, D_windows)\n      layout: \"streamgraph, time on horizontal axis\"\n      form: \"stacked coloured bands\"\n      encoding: \"band thickness: topic proportion; colour: topic identity;\n        faceted by community track\"\n      description: \"Support for interpreting shifting research foci\"\n\n    transform T_name_foci :\n      intent: abstract\n      manner: \"name-patterns\"\n      input: V_foci_evolution, F_topic_profile, M_topics\n      output: P_research_foci\n      actor: human\n      description: \"Assign concise research-focus labels to dominant topics\n        per community and period\"\n\n    artifact P_research_foci : pattern(F_topic_profile)\n      representation form: \"labelled sequences of dominant research foci per\n        community track\"\n      description: \"Human-interpreted research-focus labels and their\n        evolution\"\n\n    transform T_assess_foci :\n      intent: assess\n      manner: \"judge-visualisation-adequacy\"\n      input: V_foci_evolution, P_research_foci\n      output: K_foci_quality\n      actor: human\n      description: \"Judge whether labels are distinct, stable, and accurate\"\n\n    artifact K_foci_quality : knowledge(P_research_foci)\n      representation form: \"quality judgment\"\n      description: \"Assessment of labelling adequacy\"\n\n    if K_foci_quality indicates refinement needed:\n      then:\n        transform T_refine_topics :\n          intent: build-model\n          manner: \"adjust topic model parameters\"\n          input: K_foci_quality, D_papers, M_topics\n          output: M_topics_r\n          actor: hybrid\n          description: \"Adjust topic count/preprocessing and refit the model\"\n\n        artifact M_topics_r : model(D_papers)\n          model type: \"topic model\"\n          representation form: \"topic-term distributions and per-paper topic\n            proportions\"\n          description: \"Refined topic model\"\n\n        assign:\n          M_topics := M_topics_r\n      else:\n        exit loop L_foci_interpretation\n\nend loop L_foci_interpretation\n\n# ============================================================================\n# STEP 7: SYNTHESISE FINDINGS\n# ============================================================================\n\ntransform T_synthesise :\n  intent: generate-knowledge\n  manner: \"formulate-statements\"\n  input: D_community_tracks, P_lifecycle_events, K_core_stability,\n         P_research_foci, V_evolution\n  output: K_findings\n  actor: human\n  description: \"Synthesise the number and stability of communities, leadership\n    continuity, evolving research foci, and merge/split/dissolution history\"\n\nartifact K_findings : knowledge(D_community_tracks, P_research_foci)\n  representation form: \"statements and narrative summary\"\n  description: \"Integrated account of the IEEE VIS community's collaboration\n    structure: major communities, stable cores/leaders, evolving research\n    foci, and merge/split/dissolution events\"\n```",
      "role": "assistant"
    }
  ]
}