Dharmalib combines curated Sanskrit source materials with several layers of derived data. The site does not treat every displayed number, tag, or relation as an independent scholarly source: much of what appears in the interface is computed from parsed texts or extracted from structured source notes.

This page describes what each layer contributes, how it is transformed, and how it should be cited or interpreted.

The source chain at a glance

SanskritRepo/11-sanskrit
├── parsed text folders (.conllu)
├── text-level Markdown notes
├── 00-lemma-index (lemma Markdown records)
├── 00-concepts (semantic and synset Markdown records)
├── 00-dhatus and 00helpers/synaptic (root, lexical, and sūtra data)
└── supporting indexes
          ↓
static/data (canonical site inputs)
          ↓
static-runtime/data/generated/v1 (public runtime projections)
          ↓
Dharmalib reader, dictionary, root, concept, graph, and search views

The source repository is currently configured locally as /Users/amrit/SanskritRepo/11-sanskrit. Build scripts also support environment-variable overrides so that the same pipeline can run elsewhere.

Parsed Sanskrit texts

What the text corpus supplies

The principal textual source is the collection of CoNLL-U files in the non-00-* text folders of the Sanskrit repository. Each parsed sentence supplies, where present:

• the IAST text of the sentence or verse;
• a token sequence;
• token form, lemma, universal part-of-speech label, and morphological features;
• token identifiers and any compound-range rows;
• source reference metadata such as chapter, sentence counter, subcounter, and sentence identifier.

scripts/build-texts.js recursively discovers .conllu files in every text folder. It reads their metadata headers and token rows, then writes one canonical JSON text file per text beneath static/data/texts and a catalogue record in static/data/texts.json.

References and ordering

Displayed references are taken from the parsed source headers whenever they are available. The builder gives priority to ## chapter, # sent_counter, and # sent_subcounter; it falls back to the source sentence identifier or local sequence only when a fuller reference is absent.

This means a reader location reflects the supplied edition’s structure—chapter and verse, section and sentence, or another native scheme—rather than a site-invented numbering system. Edition prefixes may be suppressed in the display where they are redundant, but the underlying stored reference remains available for navigation.

Devanāgarī display

The raw parsed text is stored in IAST. The reader’s Devanāgarī string is generated during the text build with the sanscript transliteration library. It is a display transliteration of the supplied IAST line, not a separately collated Devanāgarī edition. Where exact orthography, punctuation, or an edition-specific reading matters, consult the cited source edition.

What CoNLL-U analysis means

The morphological and syntactic fields in the reader originate in the parsed corpus. They are computational annotations attached to the selected source text. They are useful for exploration and comparison, but users should regard difficult parses, segmentation, and compound treatment as analyses that can be revised—not as final critical judgments.

Text-level descriptions, notes, and citations

Markdown text records

The Sanskrit repository also contains Markdown records for texts. scripts/build-text-descriptions.mjs reads their frontmatter and selected sections to create static/data/text-descriptions.json.

These records supply the text title, short description, tags, related-text suggestions, and notable-lemma tables. The builder deliberately excludes routine high-frequency function words from notable-lemma output. Tags and classifications are editorial navigation aids, not universal bibliographic standards.

Text notes on text pages

For texts with an available note, the runtime folder contains a Markdown document named with the text slug under data/generated/v1/text-notes. The text page renders selected content from that document rather than relying only on an older bodyHtml field.

The presentation removes a redundant document H1, presents the substantive thematic subsections directly, and combines edition and citation material under Source and Citations. Related-text and notable-lemma sections are rendered through the site’s structured data instead.

Citing a text

For scholarly citation, use the text’s own source-and-citation material and the passage reference shown by the reader. Dharmalib’s URL, parser annotations, and generated Devanāgarī are useful access aids, but they should not replace the source edition named in the note.

Lemmas, dictionary material, and concordance data

Lemma index

00-lemma-index is the source for the detailed lemma analytics. It contains a LEMMAS.md index and individual Markdown records in lemmas/. scripts/build-lemma-concordance.mjs extracts structured information from those records:

• part of speech;
• total occurrences and number of texts;
• dictionary definitions;
• semantic classifications;
• top text distributions;
• sample concordance contexts.

The resulting static/data/lemma-concordance.json is keyed by ASCII-normalized lemma form. It drives the corpus-profile, semantic, distribution, and concordance portions of lemma entries and the word lens.

Dictionary definitions

Dictionary entries are supplied through the lexical helper data used by scripts/build-bundles.js, specifically dictionary-entries.json. The bundle preserves source labels with entries; the current pipeline may surface definitions associated with sources such as DCS, Apte, and Monier-Williams when they are present in the upstream record.

Definitions are therefore source-labelled lexical extracts, not new translations authored by the interface. A brief preview may be shortened for display. Consult the named dictionary or full upstream lemma record for extended context, editorial conventions, and citation practice.

Derived occurrences

scripts/build-occurrences.js scans every canonical text JSON file and creates word-occurrences.json, mapping each lemma to the set of text slugs in which it appears. Counts and “appears in N texts” statements are derived from the current parsed corpus.

They are corpus statistics. They do not claim that a lemma occurs only in those texts, nor do they establish a lemma’s frequency in Sanskrit literature generally.

Dhātus, derivation, and grammatical sūtras

The root and root-word data is assembled by scripts/build-bundles.js from helper data beneath 00helpers/synaptic in the Sanskrit repository.

The bundle builder normalizes and joins these records. For example, it matches root records using Devanāgarī forms with a fallback transliteration path, then attaches any available sūtra references and upasargas. The root pages present this assembled result; they are a navigational projection of the supplied lexical and grammatical records.

Semantic concepts

00-concepts supplies the semantic layer. scripts/build-concept-graph.mjs reads:

• INDEX.md and numbered top-level Markdown files for supersense categories;
• synsets/*.md for individual synsets, parentage, and hyponyms;
• semantic classifications already extracted from the lemma index.

The builder produces static/data/concepts.json with supersense summaries, synsets, a concept-to-lemma reverse index, and a lemma-to-concept index. Concept pages and word-lens semantic chips use these projections.

The semantic layer is a structured discovery vocabulary, including WordNet-style supersense and synset information where supplied. It supports comparison and browsing; it is not a claim that a Sanskrit lemma has one exhaustive or context-invariant meaning.

Generated runtime artifacts

scripts/build-query-artifacts.mjs turns canonical static/data inputs into versioned JSON under static-runtime/data/generated/v1. These files are public delivery artifacts, not new primary sources.

Text artifacts are stored as 20-verse source chunks. The reader composes a requested 20-, 50-, or 100-verse display from the small number of consecutive chunks it needs. This is a delivery optimization; it does not alter the source text’s sequence or reference system.

What is editorial, computed, or source-derived

The following distinction is useful when interpreting the site:

All four layers are useful, but they answer different questions. A computational count is not an edition; a tag is not a scholarly consensus; and a parsed token is not a substitute for philological judgment.

Reproducibility and limits

The public runtime data can be regenerated from the canonical inputs with pnpm data:build. Reconstructing the canonical inputs from raw sources requires the full source repository and pnpm data:rebuild.

Coverage changes as source files, lemma records, concept records, and descriptions are added or corrected. A missing definition, compound analysis, citation, or concept link generally indicates that the corresponding upstream record or projection is incomplete. It should be read as an invitation to verify the source, not as evidence that the data is absent from Sanskrit tradition.