Die Idee

Die Form der Dinge steht längst fest.
Trotzdem fängt jedes Programm bei null an.

Druidbase liefert das Datenmodell mit: 30 kuratierte Typen nach schema.org, verbindlich, mit Pflichtfeldern und echten Grenzen. Du legst keine Struktur an — du wählst aus und fängst an.

01 — Das ProblemDie Bedeutung landet im Kopf, nicht in den Daten

Ein Ort, eine Person, ein Termin, ein Preis: Fast alles, was festgehalten wird, hat eine bekannte Form. Jedes Werkzeug erfindet trotzdem eigene Namen dafür — weil es leer ausgeliefert wird. Wer ein Feld braucht, legt eines an und nennt es Datum2.

Sichtbar wird das erst später, und immer als das Problem von jemand anderem: Die KI-Suche findet die Öffnungszeiten nicht. Die dritte Integration kostet wieder Abstimmung. Schema-Daten werden nachgerüstet und passen doch nicht. Und beim Werkzeugwechsel beginnt alles von vorn.

Die Struktur fehlt nicht — sie wird nur jedes Mal neu erfunden.

02 — Die AntwortDer fehlende Knopf ist das Produkt

Ein geschlossenes, kuratiertes Profil aus 30 schema.org-Typen. Mit Pflichtfeldern, mit Grenzen — und ohne Knopf für eigenen Typ anlegen.

schema.org steht dabei nicht als Versprechen an Suchmaschinen, sondern als Argument: Die Struktur ist nicht unsere private Meinung darüber, was eine Person ist. Sie ist der Konsens, an dem sich seit Jahren alle ausrichten.

Akteure
PersonOrganization LocalBusinessPlace
Redaktion
ArticleWebPageWebSite HowToCourseDataset Book
Medien
MediaObject
Eingang
ReviewCommentMessage
Handel
ProductServiceOffer OrderInvoiceMembershipProgram Brand
Zeit
EventReservation
Struktur & Vokabular
ItemListDefinedTermJobPosting SoftwareApplicationQuestionAction

Kein Branchenwerkzeug, sondern die allgemeinste vordefinierte Datenbank, die sich vernünftig bauen lässt: Kundenkartei wie Adressbuch, Firma mit Angeboten, Bestellungen und Rechnungen wie Traumtagebuch, Lagerliste wie Rezeptsammlung. Nicht weil für jeden Fall ein Fall gebaut wurde, sondern weil Person, Ort, Termin, Vorgang, Ding, Text und Begriff die Formen von fast allem sind.

03 — Was daraus folgtSechs Dinge, die man sonst dazukauft

Tag eins entfällt

Kein leeres Werkzeug, kein Modellieren, keine Migration zwei Wochen später, weil die halbe Struktur falsch war. Installieren, Typ wählen, Inhalt eintragen.

Vorgänge sind auch Daten

Unter den Typen steht Bewegung, nicht nur Dinge: Anfrage, Termin, Bestellung, Rechnung, Aufgabe — mit Status, verknüpft mit Personen, Orten und Produkten. Das CRM ist kein zweites System. Das Kontaktformular ist kein Plugin, es ist ein Typ.

Daten erklären sich selbst

Jede Sammlung liegt unter einer Adresse — als JSON-LD, Tabelle oder Markdown, ganze Liste oder einzelner Datensatz. Kein Export, kein Mapping: Wer sie braucht, liest das Original. Ein Schalter pro Feld entscheidet, was das Haus verlässt.

Fragen brauchen kein Handbuch

Dieselbe Adresse nimmt Filter, Sortierung und Suche entgegen. Weil die Feldnamen dem Standard folgen, muss man sie nicht nachschlagen: Was auf einem Bestand funktioniert, funktioniert auf jedem anderen.

Die Adresse nimmt auch entgegen

Was gelesen werden kann, kann geschrieben werden — auf Vollmacht, geprüft gegen den Typ. In einer Welt, in der zunehmend Maschinen schreiben, ist diese Vertrauensschicht der Kern des Systems, kein Verwaltungsdetail.

Die Website fällt ab

Eine lesbare Ansicht ist eine Serialisierung derselben Daten — kein zweites System, das gepflegt werden will.

04 — Eine AdresseVier Formate, dieselbe Wahrheit

Dieselbe Sammlung liegt als jsonld, json, csv, md und html unter derselben Adresse. Ohne Suffix entscheidet die Content-Negotiation.

Schreibend gilt derselbe Weg, aber nie dieselbe Tür: Menschen bekommen Konten mit Sitzung und drei festen Rollen. Maschinen bekommen Tokens mit einer Vollmacht — „Der Buchungsdienst darf Reservierungen anlegen“, „Die Kasse darf payment_status auf Rechnungen setzen“. Ein Token erreicht nie die Oberfläche, ein Konto nie den Schreib-Endpunkt. Jede Nutzung wird protokolliert.

# lesen — gefiltert, sortiert, ohne Handbuch GET /v1/events.jsonld?start_date>=2026-09-01&sort=start_date { "@context": "https://schema.org", "@type": "Event", "name": "Druidbase Werkstattabend", "location": { "@id": "/v1/places/werkstatt" } } # schreiben — nur auf Vollmacht, geprüft gegen den Typ POST /v1/reservations Authorization: Bearer <token> → 201 grant: reservations · create

05 — Die BauweiseDer Werkzeugkasten ist die Wartungslast

Nicht die Sprache. Alles, was gebaut, aufgelöst oder gesperrt werden muss, bevor der Code läuft, ist eine Schuld, die länger lebt als ihr Nutzen.

SchichtEntscheidung
SprachePHP 8.3+ — Selbst betreiben heißt Dateien auf günstigen Webspace kopieren, statt einen Prozess zu beaufsichtigen.
SpeicherSQLite — eine Datei, kein Daemon, keine Zugangsdaten. cp ist das Backup. Dateien bleiben das Exportformat: ein vollständiger Abzug als JSON-LD und Markdown, lesbar ohne diese Software.
Abhängigkeitenkeine — kein npm, kein Composer, kein Lockfile. Vue liegt als eine Datei im Repository; ein Update ist ein Dateitausch.
Oberflächeserver-gerendert — Inseln statt Single-Page-App. Eine Seite, die nicht reaktiv ist, kann nicht kaputtgehen.
Updatesselbsttätig — prüfen, Signatur verifizieren, sichern, tauschen, migrieren, bei Fehlschlag zurückrollen. Für den Verein ohne Betreiber ist „mach ein git pull“ keine Antwort.

Am besten sieht man es am eigenen Bestand

Der Prototyp läuft öffentlich, mit Beispieldaten in allen 30 Typen. Schau nach, wo deine eigenen Inhalte hineinpassen.

Demo öffnen