{
  "chat_uuid": "5f6118af-0d37-4767-a57c-3158f153b82d",
  "history": [
    {
      "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": "## Goal\n\nBuild an **interactive temporal, overlapping community-analysis workflow** rather than relying on one clustering result. Communities should be inferred from collaboration patterns, then interpreted and validated using topics, venues, citations, and expert review.\n\n---\n\n## 1. Prepare and validate the data\n\n### 1.1 Normalize paper and author records\nUse the DBLP author identifier as the primary author key; retain raw names for display.\n\nFor each paper, retain:\n\n- Paper ID\n- Year\n- Conference/track: VIS, InfoVis, VAST, SciVis\n- DBLP author IDs and display names\n- Title, abstract, keywords\n- Citation count or citation links, if available\n\n### 1.2 Perform quality checks\nBefore community detection, provide an analyst-facing audit view for:\n\n- Papers with missing or unusually long author lists\n- Authors with implausibly high publication counts\n- Duplicate papers across conference datasets\n- Missing abstracts/keywords by year\n- Very recent papers with immature citation counts\n- Changes in conference naming or scope over time\n\nDo not use raw author strings to define identity; use DBLP IDs. Flag possible remaining errors for manual inspection.\n\n---\n\n## 2. Model collaboration as a temporal network\n\n### 2.1 Create an author–paper bipartite network\nRepresent:\n\n- Authors as one node type\n- Papers as another node type\n- An edge when an author wrote a paper\n\nThis preserves the original collaboration structure and avoids prematurely converting every multi-author paper into a dense clique.\n\n### 2.2 Derive an author collaboration network\nFor each time period, project the bipartite graph to an author network:\n\n- Node: author\n- Edge: coauthorship relationship\n- Edge weight: strength of collaboration\n\nA useful fractional weighting is:\n\n\\[\nw_{ij} = \\sum_{p:\\, i,j\\in A_p} \\frac{1}{|A_p|-1}\n\\]\n\nwhere \\(A_p\\) is the set of authors on paper \\(p\\). This prevents a paper with many authors from contributing disproportionately many strong ties.\n\nOptionally incorporate recency:\n\n\\[\nw_{ij,t} = \\sum_{p:\\, i,j\\in A_p,\\; y_p \\le t}\n\\frac{\\exp[-\\lambda(t-y_p)]}{|A_p|-1}\n\\]\n\nThis emphasizes current collaboration while retaining historical ties.\n\n### 2.3 Use multiple time views\nCreate several network representations:\n\n| View | Purpose |\n|---|---|\n| Full-period network, 1990–2024 | Identify broad historical communities |\n| Non-overlapping periods, e.g. 1990–1994, 1995–1999 | Compare eras clearly |\n| Rolling windows, e.g. 5-year windows | Track gradual evolution |\n| Year-by-year network | Inspect sudden changes, but may be sparse |\n| Conference-specific networks | Distinguish VIS, InfoVis, VAST, and SciVis structures |\n\nA five-year rolling window is a reasonable initial choice, but it should be adjustable interactively.\n\n---\n\n## 3. Identify candidate communities\n\nNo single algorithm should be treated as ground truth. Run several methods and compare results.\n\n### 3.1 Establish a non-overlapping baseline\nApply a standard weighted community detection method such as:\n\n- Leiden\n- Louvain\n- Degree-corrected stochastic block model\n\nThis gives an easy-to-explain baseline partition and helps identify the largest collaboration regions.\n\n### 3.2 Use overlapping community detection\nBecause researchers may participate in multiple communities, use methods that support multi-membership, such as:\n\n- Link communities / edge clustering\n- BigCLAM\n- Mixed-membership stochastic block models\n- Overlapping stochastic block models\n- OSLOM\n\nFor each author \\(i\\), retain a membership score rather than only a single label:\n\n\\[\nm_{ik} \\in [0,1]\n\\]\n\nwhere \\(m_{ik}\\) represents the strength of author \\(i\\)'s membership in community \\(k\\).\n\nThis distinguishes:\n\n- **Core members:** high and persistent membership in one community\n- **Boundary spanners:** meaningful memberships in multiple communities\n- **Transient contributors:** brief or weak membership\n- **New entrants:** recently appearing members\n\n### 3.3 Make algorithm parameters inspectable\nThe analyst should be able to adjust:\n\n- Time-window length\n- Minimum edge weight\n- Resolution parameter\n- Minimum community size\n- Whether repeated collaboration is required\n- Inclusion/exclusion of single-paper authors\n\nShow how results change under these choices. A community that appears only under one narrow parameter setting should be treated cautiously.\n\n---\n\n## 4. Track communities through time\n\nCommunity labels generated independently in each time window are not inherently comparable. Align them across adjacent windows.\n\n### 4.1 Match communities between periods\nFor communities \\(C_{k,t}\\) and \\(C_{l,t+1}\\), calculate similarity using weighted membership overlap, for example weighted Jaccard similarity:\n\n\\[\nJ(C_{k,t}, C_{l,t+1}) =\n\\frac{\\sum_i \\min(m_{ik,t},m_{il,t+1})}\n{\\sum_i \\max(m_{ik,t},m_{il,t+1})}\n\\]\n\nMatch highly similar communities across consecutive windows.\n\n### 4.2 Identify temporal events\nClassify changes using membership flow and overlap:\n\n| Event | Evidence |\n|---|---|\n| Continuation | One community strongly matches one later community |\n| Growth / contraction | Same lineage, but substantial membership-size change |\n| Merge | Multiple prior communities substantially contribute to one later community |\n| Split | One prior community substantially contributes to multiple later communities |\n| Birth | A new community has no strong predecessor |\n| Dissolution | A community has no strong successor |\n| Reorganization | Membership persists but is redistributed across communities |\n\nDo not assign an event solely from an overlap threshold. Present candidate events to the analyst with supporting evidence.\n\n### 4.3 Display a community lineage graph\nUse an alluvial/Sankey-style diagram or temporal lineage graph:\n\n- Each block represents a community in one time window.\n- Block size represents active members, papers, or weighted collaboration volume.\n- Links represent author-membership flow.\n- Link width reflects overlap strength.\n- Color reflects community lineage or primary research focus.\n\nAllow the analyst to click a transition and inspect the authors and papers responsible for it.\n\n---\n\n## 5. Define stability, cores, and leaders\n\n### 5.1 Measure community stability\nUse several complementary measures:\n\n| Measure | Interpretation |\n|---|---|\n| Membership retention | Fraction of members retained from one period to the next |\n| Core retention | Fraction of core members retained |\n| Lineage duration | Number of consecutive windows in which a community persists |\n| Internal collaboration persistence | Stability of internal coauthor ties |\n| Topic persistence | Similarity of research foci over time |\n| Structural cohesion | Internal edge density or conductance relative to outside ties |\n\nA stable community need not retain every member; the key question is whether its central members and collaboration structure persist.\n\n### 5.2 Define the stable core\nFor each community, define a core using a combination of:\n\n- High membership strength in that community\n- Presence in multiple consecutive time windows\n- Strong internal collaboration ties\n- Repeated publication within the community\n- Low dependence on a single one-off collaboration\n\nFor example, classify an author as a core member if they:\n\n1. Have membership above a chosen threshold in the community,\n2. Appear in at least \\(r\\) consecutive or nearby windows, and\n3. Have substantial weighted collaboration with other community members.\n\nThe analyst should be able to inspect and alter these thresholds.\n\n### 5.3 Identify leaders using multiple roles\n“Leader” should not mean only the most cited person. Report several roles:\n\n| Role | Possible indicators |\n|---|---|\n| Collaboration hub | Weighted degree, internal degree |\n| Structural broker | Betweenness, cross-community ties |\n| Persistent core leader | Long-term core membership and repeated coauthorship |\n| Productive contributor | Papers within the community |\n| Influential contributor | Citation impact, field-normalized by publication year |\n| Topic leader | Strong association with a major topic or emerging topic |\n\nShow a profile for each leader, including coauthors, papers, topics, temporal role, and affiliations with multiple communities.\n\nCitation counts should be normalized by publication age, since papers from 2023–2024 have had little time to accumulate citations.\n\n---\n\n## 6. Characterize each community’s research foci\n\n### 6.1 Build a paper text representation\nUse title, abstract, and keywords. Recommended preprocessing:\n\n- Standardize keyword variants\n- Preserve domain terms and acronyms\n- Remove generic publication language\n- Track terms whose meaning changes over time\n- Retain conference/track labels as metadata, not as text features\n\nRepresent papers using both:\n\n- Keyword and phrase features for interpretable labels\n- Modern text embeddings for semantic similarity\n\n### 6.2 Discover paper-level topics\nUse a combination of:\n\n- Embedding-based topic modeling, such as BERTopic\n- Hierarchical clustering of paper embeddings\n- Keyword co-occurrence analysis\n- Manual expert labeling of top topic clusters\n\nPotential high-level VIS topics may include interaction, graph visualization, scientific visualization, volume visualization, visual analytics, geospatial analysis, uncertainty, machine learning for visualization, evaluation, and storytelling. These labels should emerge from the data and be reviewed by domain experts rather than imposed in advance.\n\n### 6.3 Aggregate topics to community–time profiles\nAssign each paper’s topic contribution fractionally to its authors’ communities. A paper coauthored by people in multiple communities should contribute to each relevant community rather than being forced into one.\n\nFor every community and time window, report:\n\n- Top topics\n- Representative keywords and phrases\n- Most representative papers\n- Emerging topics\n- Declining topics\n- Topic diversity\n- Topic similarity to other communities\n\n### 6.4 Visualize topic evolution\nUseful views include:\n\n| Visualization | Use |\n|---|---|\n| Community-topic heatmap | Compare research foci across communities and periods |\n| Topic streamgraph | Show rise and decline of topics within a community |\n| Temporal keyword map | Reveal emerging terminology |\n| Paper embedding map | Inspect semantic clusters and outliers |\n| Representative-paper list | Validate automatic topic labels |\n| Topic similarity network | Identify intellectually related communities |\n\nRequire analyst review of topic labels. Automatically generated labels should be treated as suggestions.\n\n---\n\n## 7. Analyze overlaps and boundary-spanning researchers\n\n### 7.1 Measure community overlap\nFor each pair of communities, compute:\n\n- Shared active members\n- Shared core members\n- Fractional membership overlap\n- Cross-community coauthorship volume\n- Topic similarity\n- Shared papers or recurring author teams\n\nDisplay this as a matrix and as an inter-community network.\n\n### 7.2 Identify bridges\nFor each author, calculate:\n\n- Number of active community memberships\n- Membership entropy\n- Cross-community coauthor tie strength\n- Betweenness centrality\n- Topics associated with each membership\n\nHigh-overlap authors may be:\n\n- Interdisciplinary contributors\n- Collaborators linking InfoVis and VAST, for example\n- Researchers transitioning between communities\n- Members of a temporary cross-community project team\n\nThe analyst should inspect individual publication trajectories before assigning an interpretation.\n\n---\n\n## 8. Explain merges, splits, and dissolutions\n\nFor each candidate event, create an evidence panel containing:\n\n1. **Membership evidence**\n   - Which authors moved, remained, or left?\n   - Were core members retained?\n\n2. **Collaboration evidence**\n   - Did cross-group coauthorship increase before a merge?\n   - Did internal ties weaken before a split?\n\n3. **Topic evidence**\n   - Did communities converge on similar topics?\n   - Did a new topic create a separate subgroup?\n\n4. **Publication evidence**\n   - Which papers, author teams, or research programs drove the change?\n\n5. **Conference evidence**\n   - Did the event coincide with shifts in VIS, InfoVis, VAST, or SciVis participation?\n\n6. **External contextual evidence**\n   - Major methodological shifts, new datasets, emerging application domains, institutional changes, or field-wide trends.\n\nThe final “why” should be an expert interpretation supported by the evidence, not an automated causal claim.\n\n---\n\n## 9. Build an analyst-facing visual workspace\n\nA practical dashboard should include linked views:\n\n| View | Main purpose |\n|---|---|\n| Temporal community map | Explore collaboration structure in a selected period |\n| Community lineage/Sankey view | Track communities, merges, splits, births, and dissolution |\n| Community profile panel | Inspect members, leaders, papers, topics, and metrics |\n| Author trajectory view | Follow one researcher’s memberships and collaborators over time |\n| Topic heatmap and streamgraph | Compare and track research foci |\n| Inter-community overlap matrix | Identify shared members and bridges |\n| Paper embedding map | Inspect content-level structure |\n| Parameter/sensitivity panel | Compare results across windows, thresholds, and algorithms |\n| Event evidence panel | Examine candidate merge, split, or dissolution events |\n\nAll views should support filtering by year, conference, topic, community size, author role, and citation threshold.\n\n---\n\n## 10. Validate and assess robustness\n\n### 10.1 Compare alternative specifications\nRepeat analyses across:\n\n- Different time-window widths\n- Different edge-weighting schemes\n- Multiple community detection algorithms\n- Different resolution parameters\n- Inclusion/exclusion of weak or one-off ties\n\nA robust community should recur across reasonable choices.\n\n### 10.2 Use quantitative diagnostics\nAssess:\n\n- Community cohesion versus null models\n- Temporal membership stability\n- Agreement between algorithms\n- Topic coherence\n- Sensitivity of leaders and cores to parameter changes\n- Whether apparent communities are simply conference-specific or truly collaborative groups\n\n### 10.3 Conduct expert validation\nAsk visualization researchers to review:\n\n- Community labels\n- Key leaders\n- Representative papers\n- Major claimed mergers/splits\n- Interpretation of emerging topics\n\nRecord annotations and disagreements. These are valuable outputs, not merely corrections.\n\n---\n\n## 11. Recommended final deliverables\n\n1. **Historical community atlas** for 1990–2024  \n2. **Community lineage graph** showing temporal evolution  \n3. **Community profiles** with cores, leaders, collaboration patterns, and research foci  \n4. **Author mobility and bridge analysis**  \n5. **Topic evolution report** for each major community  \n6. **Candidate merge/split/dissolution event catalog** with evidence  \n7. **Sensitivity and validation report** documenting which findings are robust  \n8. **Interactive visual analytics system** for expert exploration  \n\nThe central principle is to treat communities as **dynamic, overlapping, and interpretable research formations**, not as fixed clusters produced once by an algorithm.",
      "role": "assistant"
    }
  ]
}