Repository Core

This page explains what the Ta-Na-Si Media & Document Repository is built from — its architecture, its technology, and the people behind its development. We believe in full transparency: anyone who uses an archive, or thinks about running one of their own, deserves to know exactly what the system is made of. The About page explains what the archive is for; this page explains how it works.

1. What the Repository Core Is

The Repository Core is the software this archive runs on: a fully independent, self-hosted digital archive system, written from the ground up for one purpose — to store, organize, and openly serve documents and media as evidential source material. It is not based on WordPress, Joomla, Drupal, or any other pre-built CMS, and it uses no PHP framework. Every component — the database layer, the search engine, the curation workroom, the public pages — was designed and written specifically for this task.

The software is built as a multi-installation platform: it does not serve one central archive, but powers many separate, independent ones. Each archive — whether a small family collection or a large regional repository — is its own complete installation with its own database, its own files, and its own keeper. There is no shared infrastructure between archives and no central service they depend on.

2. One Codebase, Many Independent Archives

Every installation runs the identical codebase. Everything that is specific to one server — its public address, its database access, its mail sender — lives in a single environment file that is created once during setup and never travels with the code. This strict separation is what makes the model work: the same software update can be applied to every archive, small or large, without touching any archive's individual configuration.

A new archive is installed through a guided setup assistant in the browser — no command line, no configuration files to edit by hand. The assistant speaks 18 languages, checks the server's requirements, tests the database connection before anything is written, and creates the owner account with a securely hashed password. Database tables are created by an idempotent migration system: it can run any number of times and always converges on the correct schema. Later schema changes are versioned and tracked, so every installation can see exactly where it stands; routine changes apply automatically, while heavy ones wait for the owner's deliberate confirmation. Updates follow the same careful order: back up first, then migrate, then clear the cache.

3. Technology Stack Version 1.0.0 (Thuringia)

4. Search and Facet Navigation

The heart of the public archive is its search. A single full-text index covers every published record — title, description, summary, notes, and article text — so one search field reaches everything. But full text alone is not enough for serious research, which is why every record is also classified along nine facet axes:

• Subject — the topics and themes a record is about.
• Place — the geographic locations a record relates to, drawn from a structured place directory (see the GeoNames section below).
• Language — the language of the record's content, from 49 natively supported languages.
• Contributor — the people involved: authors, speakers, photographers, editors.
• Genre — the kind of material: testimony, analysis, report, and so on.
• Part of — the larger work a record belongs to, connecting multi-part material.
• Collection — curated named groupings maintained by the archive's keepers.
• Series — ordered groupings for material that follows a sequence.
• Access — the access level of a record, for example public or members-only.

Facet navigation works the way researchers expect from large institutional archives. Next to the results, each axis shows its most frequent values with live hit counts — one click narrows the results, and filters from different axes can be combined freely: for example, all audio records in German on the subject education from the 1990s. Active filters are shown as removable chips above the results, so the current narrowing is always visible and any filter can be dropped again with one click. Where an axis holds more values than the sidebar shows, a full alphabetical index of the entire axis can be browsed, letter by letter.

Beyond the facets, results can be limited by kind of material (articles, audio, video, documents, images, datasets — several at once if wanted) and by date, either through quick decade links or an exact year range. Results can be sorted by relevance, title, or date, and displayed in four ways: a detailed list, an image gallery, a compact grid, or a full-screen slideshow. The entire search state — query, filters, sorting, view — lives in the address bar, so any result page can be bookmarked, cited, and shared exactly as it stands.

The facets are not free-floating tags: their vocabularies are curated by the archive's keepers, and axes like collection and series can be organized hierarchically. Every facet value shown on a record page links back into the search, so a reader can always pivot from one interesting record to everything else the archive holds on the same subject, place, person, or series.

5. Record Pages

Each record has its own page with type-appropriate presentation: audio and video play directly in the page, PDF documents open in an embedded viewer, images can be examined in a zoomable deep-view, and articles are rendered from safely filtered Markdown. Alongside the file itself, a record page shows the full description, the contributors, the larger work it belongs to (with navigation between its parts), related items worth seeing next, and ready-made citations in Chicago, APA, and MLA form. Every record carries machine-readable metadata (schema.org JSON-LD) and a stable address that never changes; short permanent links of the form /go/… can be assigned for citation in print and external references.

6. Languages

The archive is built for a multilingual world, on two distinct levels.

The interface — everything a visitor or keeper reads on the pages themselves — is written in English and keeps every visible text in translatable language files, never buried in code. Interface language packs for 18 languages are in preparation and currently in translation: English, German, French, Italian, Spanish, Portuguese, Dutch, Russian, Polish, Swedish, Danish, Norwegian, Chinese, Japanese, Korean, Turkish, Czech, and Romanian. Packs are installed and managed from the administration panel, which also tracks how complete each translation is against the English source. The setup assistant already speaks all 18 today.

The content — the archived material itself — natively supports 49 languages: English, German, French, Italian, Spanish, Portuguese, Dutch, Russian, Ukrainian, Polish, Greek, Swedish, Danish, Norwegian, Turkish, Chinese, Hindi, Arabic, Indonesian, Japanese, Vietnamese, Korean, Belarusian, Czech, Slovak, Hungarian, Romanian, Bulgarian, Croatian, Slovenian, Finnish, Bengali, Urdu, Persian, Icelandic, Irish, Swahili, Thai, Filipino, Hebrew, Punjabi, Telugu, Tamil, Marathi, Hausa, Yoruba, Amharic, Javanese, and Pashto. Records are tagged with the language of their content, and the language facet of the search filters by any of them — so a reader can, for example, pull up everything the archive holds in Ukrainian or in Arabic with one click. Right-to-left scripts such as Arabic, Hebrew, Persian, and Urdu are displayed correctly throughout.

In addition, a language switcher on every public page opens a machine-translated view of the page, without loading any third-party script into the page itself.

7. Place Data: GeoNames

The place facet is backed by a geographic directory organized as a hierarchy — country, region, place — so that records can be located precisely and found again by geography. The base data (countries and their administrative regions worldwide) comes from the GeoNames geographical database and is imported into a local lookup store during setup or later from the administration panel; archive keepers can extend it with their own local places. Place data: GeoNames.org, licensed under CC BY 4.0.

8. Vocabulary Data: Subject & Genre Catalogs

The curated vocabularies behind facets such as subject and genre ship with the software and are translated centrally, so their terms carry meaning in every interface language. To keep them compatible with established knowledge-organization standards, the following public controlled vocabularies serve as reference sources for the catalog work: EuroVoc, the multilingual thesaurus of the European Union (© European Union, CC BY 4.0), IPTC Media Topics (© IPTC, CC BY 4.0), and the Getty Art & Architecture Thesaurus (ODC-By 1.0). Every catalog term derived from an external vocabulary records its origin, and the complete list of all third-party components and data sources ships with every installation: read it here.

9. The Working Side

Behind the public archive lies an administration panel organized into four areas: People & Governance (operator and member accounts, roles, permissions), Internal Publication (the record curation workroom and editors), Platform Configuration (settings, media forms, facets, languages, site structure), and Technology & Data (system status, diagnostics, backups). Everything an archive keeper needs to configure is reachable through these pages — running an archive requires no code changes.

Records move through a clear curation workflow: created as drafts, filled with metadata and facets, optionally submitted for review, then published — or archived again later. Files are uploaded in small resumable chunks, so large media survive unstable connections, and every upload is verified against its declared type by file-signature inspection before it is accepted. Preview images are generated automatically where the server supports it.

An optional member area lets an archive grow beyond its keepers: registered members can be trusted step by step across four fixed tiers, from reading and discussing up to curating and publishing records. Permissions are fine-grained on both sides — administrative roles are freely definable and draw from a detailed rights registry, and individual overrides can widen or narrow any single person's access. The owner's access is deliberately kept outside the database entirely, so the door to an archive can never be locked by a corrupted file or a failed change.

10. Data Safety

Backups are first-class: an archive keeper can create date-stamped ZIP backups of the database, the media content, the installation, or everything at once — on demand, with a retention policy that keeps the newest and removes the oldest. Each backup can additionally be replicated offsite to any S3-compatible storage provider. Restoring is deliberately guarded: the system verifies that a backup matches the installation and takes a fresh safety backup before it touches anything. Together with the versioned schema tracking, this means an archive built with care can be maintained, moved, and repaired for the long term.

11. Design Principles

The repository is built around a small set of non-negotiable principles that guided every architectural decision:

• No tracking, no analytics, no third-party requests — every asset, including fonts and script libraries, is served from the archive's own server. Nothing about a visitor is sent anywhere.
• Openly crawlable by design — clean HTML, a structured sitemap, descriptive metadata, and a robots.txt that welcomes search engines and AI systems, so the archived facts can be found and read widely.
• Printable and downloadable — documents are meant to leave the screen and enter the real world.
• Readable in many languages — 18 interface language packs in preparation, 49 content languages natively supported in search and facets, and a language switcher on every public page (see the Languages section above).
• Minimal, contained dependencies — a handful of self-hosted components (a Markdown parser on the server; editor and viewer libraries in the browser), kept strictly separated from the system's own code. No CDN, no package manager, no build step.
• Environment-agnostic — the identical code runs on every installation; only one environment file differs per server.
• Degrade gracefully — optional features check their prerequisites and switch off cleanly where a server cannot support them, instead of breaking the archive.

12. Development Credits

13. The Rules This Software Comes With

Every installation of this software carries the same rules, and whoever installed this archive agreed to them before a single file was written. They are short, and they were written to be read by a person rather than parsed by a lawyer: read them here.

In one sentence: the archive you are looking at belongs entirely to the people who run it — its name, its collection, its members, its data — and the project behind the software holds no key to any of it. What stays, in every installation, is the software's own name, the ground texts, and the naming of the two people who made the project. Not because a licence says so, but because an archive that lies about its own origin has broken the very thing it exists to do.

14. Contact & Feedback

This is a living system — it evolves with the project. If you encounter a technical issue, a broken link, or have a suggestion for improvement, please reach out through the contact page linked in the footer of every page, or leave a comment on any of our platform channels. We read everything.