Live: wossibel2go.wossidia.de
What is this?
Richard Wossidlo (1859—1939) was a Mecklenburg folklorist who created thousands of handwritten index cards on legends, customs, and dialects of Mecklenburg. The University of Rostock is digitizing this collection and making it accessible through the WossiDiA platform.
Wossibel2Go is the public-facing web application for this effort. It enables anyone to:
- Browse digitized index cards by category
- View scanned page images and zoom via lightbox
- Read existing transcriptions
- Contribute their own transcriptions, translations, or audio recordings ( crowdsourcing )
Architecture
The application is a classic SPA with an Express backend as an API proxy :
Vue 3 SPA ──> Express Backend ──> WossiDiA API (Uni Rostock)
(Browser) (Proxy/Middleware) api.wossidia.de
│
Digipool (Image Server)
digipool.wossidia.de
The backend has no database of its own. It forwards requests to the WossiDiA PowerGraph API and enriches the responses — for example, with convolute names from a ~30,000-entry lookup map that is refreshed hourly in the background.
Why a Proxy Instead of Direct API Access?
The WossiDiA API requires authenticated requests with credentials that must not reside in the browser. The backend handles authentication (token cache with 30-minute TTL), validates inputs, and transforms the graph data into a format the frontend can render directly.
The backend also solves a practical problem: the API’s convolute signatures do not contain human-readable names. The local lookup map assigns a name to each signature — an O(1) lookup per entry instead of additional API calls.
Navigation and Data Structure
The collection is organized hierarchically: Categories → Convolutes → Records → Pages. The sidebar reflects this hierarchy, with search and pagination at each level:
- Categories — Thematic groups such as “Superstition” or “Customs”, with a toggle between handwritten manuscripts (ZAW) and machine transcriptions (ZTW)
- Convolutes — Bundles of related cards within a category
- Records — Individual index cards within a convolute
- Pages — The scanned pages of a record with image viewer, transcription, and contribution form
Crowdsourcing: Contributions Without an Account
The contribution form is deliberately low-barrier — no login required. Users can make three types of contributions:
- Transcription — Convert handwritten cards (ZAW) into text
- Translation — Translate existing texts into other language variants (Standard German, Low German, mixed forms)
- Audio recording — Record directly in the browser (MediaRecorder API), as Base64-encoded WAV
Contributions are created as new nodes in the WossiDiA database via the backend.
Wossidlo’s Card Index
Wossidlo’s collection is a classic Zettelkasten — a system where knowledge is written on individual cards and interconnected through signatures, categories, and cross-references. Each card stands on its own but gains its value through its placement in a web of relationships. Over decades, Wossidlo built a knowledge system that is far more than a filing cabinet: the connections between cards make the collection navigable and enable discoveries that a linear list could never reveal.
This principle lives on in modern tools. Applications like Obsidian, Logseq, or Roam Research digitize the Zettelkasten method: individual notes are interconnected through backlinks, tags, and graphs — a “second brain” where connections become visible that were not yet planned during writing.
The Knowledge Graph on this portfolio is directly inspired by this idea. Blog posts and projects are the cards, tags and explicit links are the cross-references. The interactive graph makes the interconnections visible — just as Wossidlo did with his physical index cards and signatures, only with Cytoscape.js instead of wooden card boxes.
Design: Historical Rather Than Modern
The color scheme deliberately draws on archive aesthetics: parchment backgrounds, sepia tones, Playfair Display as a serif font for headings. The accent colors — a muted blue and red — are inspired by the state colors of Mecklenburg-Vorpommern.
What I Learned
- Third-party APIs require a proxy layer — Authentication, validation, and data transformation do not belong in the browser. A thin proxy cleanly separates responsibilities and protects credentials.
- Large lookup data needs a strategy — Fetching 30,000 convolute entries from the API on every request would be too slow. An hourly background refresh with fallback to a static file is a pragmatic compromise.
- Crowdsourcing only works without barriers — No account, no captcha, minimal required fields. The lower the threshold, the more contributions come in.