Development record · research corpus

Sacred Harp Corpus

A local corpus and knowledge graph for tracing how Sacred Harp repertoire changes across editions and related books. The project grew from source indexing into a linked, editable research environment.

Development record

A graph assembled from source differences

The work moves from a cross-edition research question through source indexing, first-line canonicalization, Obsidian export, and the current 5,300+ note corpus.

  • Source acquisition and metadata normalization
  • Canonical text identities without erasing book context
  • Editable graph exports for local research

Context

Problem

The Sacred Harp corpus began from a practical research question: what changes when a beloved repertoire is revised, renumbered, moved, or split across editions and related books? A flat list of songs could not answer that question. The work needed a structure that could show continuity and rupture at the same time.

The project became a local research corpus and knowledge graph for mapping relationships among songs, hymn texts, and tunebooks across multiple shape-note traditions.

Implementation

The implementation repository scrapes source indexes, builds combined first-line data, canonicalizes text identities, exports Obsidian-ready notes, and supports corpus inspection through a local CLI.

The key abstraction is first-line canonicalization. Hymn texts recur across books under different tune names, page numbers, editorial conventions, and formatting choices. Canonical first-line identity gives the graph a stable way to connect related material without pretending the sources are cleaner than they are.

Project timeline

This page has no single source-repository link, so the development trail is shown as project stages rather than commit hashes.

  1. Stage 01 · question

    Start with edition change

    The research question was not simply which songs exist. It was what changes when repertoire is revised, renumbered, moved, or split across editions and related books.

    Result: a flat list was replaced by a model that could show continuity and rupture.

  2. Stage 02 · sources

    Acquire and normalize source indexes

    Source indexes were scraped and combined with titles, first lines, book context, and other metadata so the inputs could be inspected together without losing their origins.

    Result: source differences became data the graph could preserve.

  3. Stage 03 · identity

    Give recurring texts a stable identity

    First-line canonicalization connected recurring hymn texts across different tune names, page numbers, and editorial conventions while keeping each song manifestation tied to its book.

    Result: related material could be found without pretending that the sources were identical.

  4. Stage 04 · graph

    Export an editable research environment

    Song nodes, text nodes, book nodes, and cross-links were exported into Obsidian-ready notes and made inspectable through a local CLI.

    Result: the corpus became a working graph rather than a one-time scrape.

  5. Current · scale

    Keep the corpus open to revision

    The current environment contains more than 5,300 interconnected notes across 10 tunebook traditions, with generated structure and human interpretation kept editable side by side.

    Current state: the corpus supplies the source and edition context that the Shape Note Atlas builds on.

System

Architecture

  • Source acquisition from multiple online tunebook indexes.
  • Normalization for titles, first lines, source metadata, and book context.
  • Canonical text notes indexed by first line.
  • Song notes for specific tune entries in specific books.
  • Book-level nodes and tags for filtering, clustering, and tradition context.
  • Generated Obsidian notes that link songs to texts, songs to books, and texts back to their song manifestations.

The corpus is local-first because the graph needed to remain inspectable and editable as a research environment. Obsidian was not only a display layer; it was the working surface where generated structure and interpretation could coexist without being collapsed into one database view.

Current state

Outcomes

The current corpus contains more than 5,300 interconnected notes, including roughly 3,326 song notes and 1,972 canonicalized text notes across 10 tunebook traditions. It makes repertoire overlap, text reuse, tune migration, and edition-level change easier to see.

The project is strongest as evidence of data modeling, corpus normalization, and research tooling: it turns a personal research obsession into a structured, queryable environment.

Artifacts

Artifacts

  • Graph model: song nodes, text nodes, book context, and cross-book links.
  • Corpus scale summary: 5,300+ generated notes across songs, texts, and tunebooks.
  • Pipeline summary: source scraping, first-line normalization, canonicalization, note export, and review artifacts.