Understand the data

Architecture

The database, validation, and interface behind Mnemo Atlas.

Mnemo Atlas uses one PostgreSQL database for its catalog records, connections, classifications, and citations. A Next.js application presents that data through several views.

One catalog, several views

Entries are stored in an entities table. A separate association table lets an entry have multiple types. Connections link entries; classifications associate entries with concepts; citations attach sources to records and claims.

Catalog, Timeline, Map, Scatter, Network, and Compare read this common model. They select the records appropriate to their view rather than maintaining separate copies of the catalog.

Storage

PostGIS provides geographic points for the Map. Standard columns hold common fields such as names and dates. JSONB holds attributes validated against shared and type-specific schemas.

Relationships can carry dates, roles, ranks, causal signs, review status, and source information. Ranked relationships and dispute citations support the representation of differing claims; they do not imply that every attribute has a complete conflict-resolution interface (see competing claims).

Validation and writes

The application uses Zod schemas to validate data before it reaches the catalog's write functions. Multiple types contribute their applicable fields. Unknown attributes are stripped rather than silently added to the schema.

Shared catalog changes go through designated modules in lib/. A repository check detects writes that bypass that boundary. Database constraints enforce rules such as external-ID uniqueness; application logic enforces additional domain rules.

The application uses parameterized SQL. Recursive queries handle tasks such as following concept hierarchies and traversing connections.

Identity and vocabularies

External identifiers connect catalog entries to records in systems such as Wikidata and Getty. A given external identifier can belong to only one entry.

Classification mappings connect outside vocabularies through Mnemo Atlas concepts. They record whether a match is exact, close, broader, narrower, or related.

The design draws on patterns from SKOS, CIDOC-CRM, Wikidata, Getty vocabularies, and a subset of CiTO citation roles. These patterns are represented in relational tables. The current application does not depend on an RDF triplestore, OWL reasoner, vector database, or separate graph database.

Imports and review

Import scripts and drafting tools use the catalog's validation and write paths. Import previews let the maintainer examine proposed additions before committing them. Suggestions and proposed batches have distinct review workflows.

Human-approved imports can write accepted records. Other workflows store proposed records pending acceptance. How entries are added explains the differences.

Interface

The frontend uses Next.js, React, and TypeScript. Leaflet renders maps; Vega-Lite renders scatter plots; Vega renders network diagrams; KaTeX typesets equations. The Timeline uses custom interface code.

Network overview positions are computed with d3-force on the server. The browser receives a prepared layout rather than running the initial force simulation itself.

Documentation is authored as Markdown. Editorial stories are separate content files with prose, citations, and references to catalog records.

Public deployment

The public deployment is configured as a read-only demo. Its build excludes editing pages and write routes, and request handling blocks non-read API operations. Read pages use server rendering and caching, with refresh behavior that varies by route.

The local project also contains personal features and maintenance tools. Their presence in the code does not make them available on the public site. Public accounts and multi-user contribution workflows remain future work.