Open Data Wizard

Dokumentation · Feld-Referenz · Technische Spezifikation · Changelog · Security · Lizenz

Ein WordPress-Plugin zur einfachen Veröffentlichung offener Daten nach DCAT-AP 3.0

Open Data Wizard ermöglicht es Organisationen und Einzelpersonen, Datensätze direkt in WordPress zu beschreiben und als maschinenlesbare, standardkonforme Metadaten bereitzustellen — ohne technische Vorkenntnisse, ohne externe Plattformabhängigkeit.


_{Erfassen im WordPress-Backend: Fragen statt Fachbegriffe}	_{Veröffentlichen auf der eigenen Website: der Datenkatalog}

_{Alle Screenshots zeigen die mitgelieferten Beispieldaten (frei erfunden: Musterstadt, Musterkreis, Musterland).}

Das Problem

Offene Daten zu veröffentlichen ist schwieriger, als es sein müsste. Wer es versucht, stößt meist auf drei Hürden:

Die Fachsprache. Datenkataloge verlangen Metadaten nach dem europäischen Standard DCAT-AP: dct:publisher, dcat:accessURL, dcatde:politicalGeocodingLevelURI. Wer damit nicht täglich arbeitet, weiß nicht, was gemeint ist — und rät.

Die Plattformabhängigkeit. Der übliche Weg führt über ein fremdes Portal: dort registrieren, dort einpflegen, dort pflegen. Die Organisation gibt Kontrolle ab und bindet sich an eine Infrastruktur, die ihr nicht gehört.

Der technische Aufwand. Wer selbst hosten will, braucht einen Katalogserver, RDF-Kenntnisse und jemanden, der das betreibt. Für eine Organisation mit drei Datensätzen steht das in keinem Verhältnis.

Dabei besitzen viele dieser Organisationen längst eine Infrastruktur, die sie kennen und kontrollieren: eine WordPress-Website.

Hier setzt der Open Data Wizard an.

Die Idee

Das Plugin bringt einen geführten Metadaten-Wizard ins WordPress-Backend. Organisationen beschreiben ihre Datensätze dort, wo sie ohnehin arbeiten. Das Plugin generiert daraus eine maschinenlesbare Beschreibung nach dem internationalen Standard DCAT-AP 3.0 und stellt sie unter einer persistenten URL bereit.

Open-Data-Portale binden diese URL als Harvest-Quelle ein und holen sich die Metadaten selbst ab — regelmäßig und automatisch.

Der entscheidende Unterschied: Die Daten bleiben bei der Organisation. Der Katalog kommt zu ihr. Es wandern ausschließlich Metadaten — die Beschreibung der Daten — zum Portal, nie die Daten selbst. Und dieselben Metadaten lassen sich an beliebig viele Portale gleichzeitig ausliefern, ohne sie mehrfach zu pflegen.

Was ist DCAT-AP?

DCAT-AP (Data Catalog Vocabulary — Application Profile) ist ein europäischer Standard zur Beschreibung von Datensätzen und Datenkatalogen. Er definiert, welche Angaben ein Datensatz braucht, damit er von Plattformen, Suchmaschinen und Anwendungen einheitlich gelesen und verarbeitet werden kann — Titel, Beschreibung, Lizenz, Format, Herausgeber und mehr.

Open Data Wizard implementiert DCAT-AP 3.0 und erzeugt valide JSON-LD-Ausgaben.

Für wen ist das Plugin?

Vereine, Stiftungen und NGOs — Mitgliederstatistiken, Förderdaten, Wirkungsberichte, Messreihen. Meist ohne eigene IT-Abteilung, aber mit vorhandener WordPress-Seite.
Forschungseinrichtungen und Bildungsträger — Forschungsdaten unter offener Lizenz. Die CESSDA-Klassifikation und die Felder für Urheber, Version und Herkunft zielen genau darauf.
Kommunen und öffentliche Einrichtungen — Bereitstellungspflichten erfüllen, ohne ein eigenes Portal zu betreiben. Die DCAT-AP.de-Felder für amtliche Gebietsschlüssel und Verwaltungsebenen sind vorhanden.
Portalbetreiber profitieren indirekt: standardkonforme Quellen, die sich einfach anbinden lassen, statt manuell nachgepflegter Metadaten.

Funktionsübersicht

🗂 Datensätze verwalten

Eigener Bereich im WordPress-Backend mit Übersicht, Filterung und Statusverwaltung (Entwurf / Veröffentlicht).

😊 Benutzerfreundliche Formularsprache

Das Wizard-Formular wurde vollständig überarbeitet, um es auch ohne DCAT-AP-Kenntnisse intuitiv zu machen:

Klare Fragen statt technischer Begriffe: Statt „Herausgebende Organisation (dct:publisher)" fragt das Plugin: „Wer gibt diese Daten heraus?"
Zwei Hilfen mit klaren Rollen: Das ⓘ-Symbol zeigt den DCAT-AP-Begriff des Feldes — der schnelle Blick für alle, die wissen wollen, was das im Standard ist. „Mehr erfahren" klappt die ausführliche Erklärung auf: die DCAT-AP-Eigenschaft und ihre Multiplizität als Kurzangabe, darunter eine Erklärung in Alltagssprache mit Beispiel und die normkonforme Definition
Jede Information an genau einem Ort: Dadurch können Kurzhilfe und Langtext sich nicht mehr widersprechen
Validierungsmeldungen in Klartext, mit Ort: Wird die Veröffentlichung blockiert, nennt die Meldung den Tab und den verständlichen Feldnamen (der technische DCAT-AP-Begriff steht nur klein daneben) — ein Klick auf „Zum Feld springen" öffnet den passenden Tab und hebt das Feld hervor

🧭 Geführter Wizard

Fünf-Tab-Assistent mit praktischen Beispielen. Pflichtfelder sind mit einem roten Sternchen (*) gekennzeichnet; als Entwurf lässt sich der Datensatz jederzeit speichern — erst zum Veröffentlichen müssen alle Pflichtangaben ausgefüllt sein.

Grundlegende Informationen — „Wer gibt diese Daten heraus?", „Worum geht es in diesem Datensatz?", „Welchem Thema ist dieser Datensatz zugeordnet?", „Mit welchen Schlagworten finde ich diese Daten?". Weniger häufige Einordnungen (CESSDA-Themenklassifikation, ZiviZ-Engagementfeld) liegen in einer aufklappbaren Untergruppe am Tab-Ende.
Sprache & Übersetzungen — die Sprache der Daten sowie Titel, Beschreibung und Schlagworte in weiteren Sprachen
Datenbereitstellung — Zugriffs-URL oder Datei-Upload (Mediathek), Format, Dateigröße, Lizenz (Pflicht je Distribution), Namensnennungstext; optional weitere Distributionen (wiederholbar)
Erweiterte Angaben — Projektseite, Erstveröffentlichung, Aktualisierungsfrequenz, geografische und zeitliche Abdeckung, Kontaktinformationen, Verantwortlichkeiten (Urheber/pflegende Stelle, GovData-Contributor-ID), High-Value-Datensatz (HVD) Kategorie
Vorschau — generiertes JSON-LD live einsehen

Der Reiter Vorschau prüft die Pflichtangaben noch während des Ausfüllens und zeigt darunter das zuletzt gespeicherte JSON-LD — genau das, was Harvester abrufen.

🏷 Lizenz-Auswahl

Vordefinierte Auswahlliste mit ausgeschriebenen Lizenznamen (z. B. „CC BY 4.0 — Namensnennung")
Unter der Auswahl erscheint eine allgemeinverständliche Erklärung, was die gewählte Lizenz erlaubt
Option „Sonstige" öffnet ein Freitextfeld mit Auto-Suggest aus config/licenses.txt
Lizenz ist Pflichtfeld pro Distribution (nicht am Datensatz selbst)

🧾 Metadatenfelder & kontrollierte Vokabulare

53 dokumentierte Felder — die vollständige Referenz mit DCAT-AP-Definition und allgemeinverständlicher Erklärung je Feld steht in docs/FELD-REFERENZ.md.

Pflicht: dct:title, dct:description, dct:publisher, dct:license + dcat:accessURL
DCAT-AP.de: dcatde:contributorID, originator, maintainer, amtlicher Gebietsschlüssel (politicalGeocodingURI), Verwaltungsebene, Rechtsgrundlage, Qualitätsprozess, Namensnennungstext
High-Value-Datensätze: dcatap:hvdCategory + applicableLegislation (EU-DVO 2023/138)
Mehrsprachigkeit: Titel, Beschreibung und Schlagworte je Sprache als @language/@value
Mehrere Distributionen je Datensatz — dieselben Daten z. B. als CSV und JSON, jeweils mit eigener Lizenz, Größe und Format

Statt Freitext kontrollierte Vokabulare: Themen, Dateiformate, Sprachen (alle 24 EU-Amtssprachen), Lizenzen, Zugriffsrechte und Aktualisierungsfrequenzen stammen aus den offiziellen EU- und DCAT-AP.de-Listen. Sie wählen „Umwelt" — gespeichert wird die dazugehörige URI.

🎓 CESSDA-Themenklassifikation

Auswahlfeld aus der CESSDA Topic Classification 4.2.3 (95 deutsche Konzepte, SKOS/RDF, 24h Cache). Im Feld wird das sprechende Label (z. B. „Bildung") angezeigt; die zugehörige URI wird im Hintergrund gespeichert und als Hinweis eingeblendet.

🗺 Geografische Region (GeoNames)

Kuratierte Auswahlliste (Deutschland, alle 16 Bundesländer, größere Städte). Die Auswahl wird im JSON-LD automatisch mit der passenden GeoNames-URI verknüpft; Freitext und eigene URIs bleiben möglich.

📥 Batch-Import (CSV & JSON)

Datenkatalog → Batch-Import

Importiere mehrere Datensätze auf einmal aus CSV oder JSON Dateien. Der Import-Wizard zeigt eine Vorschau aller gültigen Zeilen, markiert Fehler, und lässt dich auswählen, welche Datensätze importiert werden. Alle importierten Datensätze werden als Entwürfe erstellt — zur Bearbeitung vor Publishing bereit.

Unterstützte Formate:

CSV: Spaltenköpfe = Feldnamen (siehe unten); Reihenfolge beliebig, nicht benötigte Spalten dürfen fehlen
JSON: Array von Objekten oder einzelnes Objekt mit gleichen Feldnamen

Pflichtfelder beim Import:

title — Datensatztitel
publisher — Herausgebende Organisation
description — Beschreibung
access_url — Zugriffs-URL (muss mit http/https beginnen)
license — Lizenz (Kürzel wie cc-by, cc0, dl-de-by oder volle URI). Eine Lizenz außerhalb der Auswahlliste, etwa CC BY-NC, wird wie im Formular als eigene Lizenz („Sonstige") gespeichert.

Optionale Felder:

Spalte	Inhalt	Beispiel
`theme`	Themen, mehrere durch Komma oder Zeilenumbruch getrennt	`SOCI,ECON`
`keywords`	Schlagworte, eines pro Zeile (kein Komma als Trenner — in eine CSV-Zelle passen mehrere Zeilen, wenn sie in Anführungszeichen steht)	`Bevölkerung⏎Statistik`
`language`	Sprache: zwei- oder dreibuchstabiger Code oder Name	`de`, `DEU`, `Deutsch`
`format`	Dateiformat, Schreibweise egal	`CSV`, `geojson`
`media_type`	Medientyp, wird zur IANA-URI	`text/csv`
`byte_size`	Dateigröße in Bytes (nur ganze Zahl)	`184320`
`download_url`	Direkter Download-Link	`https://…/daten.csv`
`attribution`	Namensnennungstext	`Datenquelle: Stadt Musterstadt, 2025`
`rights`	Nutzungsrechte der Datei in Worten oder als URI	`Nutzung erlaubt, Quelle nennen.`
`issued`	Veröffentlichungsdatum	`2025-02-14` oder `14.02.2025`
`temporal_start`, `temporal_end`	Zeitlicher Bezug von–bis (Datum wie oben; Beginn nicht nach dem Ende)	`2015-01-01`, `2024-12-31`
`accrual_periodicity`	Aktualisierung: `DAILY`, `WEEKLY`, `MONTHLY`, `QUARTERLY`, `ANNUAL`, `BIENNIAL`, `IRREG`, `UNKNOWN`	`ANNUAL`
`spatial`	Geografische Region	`Musterstadt`
`political_geocoding_level`	Verwaltungsebene: `federal`, `state`, `administrativeDistrict`, `municipality`	`municipality`
`landing_page`	Projektseite	`https://…/projekt`
`contact_name`, `contact_email`, `contact_url`	Kontaktpunkt	`opendata@musterstadt.example`
`access_rights`	Zugriffsrechte: `PUBLIC`, `RESTRICTED`, `NON_PUBLIC`	`PUBLIC`
`availability`	Geplante Verfügbarkeit: `AVAILABLE`, `STABLE`, `EXPERIMENTAL`, `TEMPORARY`	`STABLE`
`hvd`	Hochwertiger Datensatz: `ja`/`nein` (auch `yes`/`no`, `1`/`0`)	`ja`
`hvd_category`	HVD-Kategorie als Code aus dem EU-Vokabular: `c_ac64a52d` Georaum, `c_dd313021` Erdbeobachtung und Umwelt, `c_164e0bf5` Meteorologie, `c_e1da4e07` Statistik, `c_a9135398` Unternehmen, `c_b79e35eb` Mobilität	`c_e1da4e07`
`version`	Version	`2.0`
`conforms_to`	Standard oder Schema (URI)	`https://www.rfc-editor.org/rfc/rfc7946`

Bei den Auswahlwerten (Sprache, Aktualisierung, Verwaltungsebene, Zugriffsrechte, Verfügbarkeit, HVD-Kategorie) gehen statt des Kürzels auch die volle URI und die Bezeichnung aus dem Formular in der Sprache der Website („Jährlich"). Ein unbekannter Wert, ein ungültiges Datum, eine ungültige Adresse oder E-Mail-Adresse wird mit Zeile und Spalte gemeldet; die Zeile wird dann nicht importiert. Leere Zellen sind immer erlaubt.

Gut zu wissen:

Excel-kompatibel: UTF-8-CSVs mit BOM (Excel-Standardexport) werden korrekt eingelesen.
Limit: Bis zu 2.000 Datensätze pro Import (Schutz vor Speicher-/Timeout-Problemen).
Sicherheit: Zell-Inhalte, die als Tabellen-Formel interpretiert werden könnten (Beginn mit = + @ -), werden beim Import automatisch neutralisiert; Datei-Typ wird anhand der echten Endung geprüft, nicht des Browser-MIME-Typs.

Die Batch-Import-Seite ist vollständig ins WordPress-Admin-Design integriert (Standard-Buttons, dezente Icons).

📥 CSV-Beispiel herunterladen | 📄 JSON-Beispiel

Die Beispieldateien enthalten 42 vollständig ausgefüllte, frei erfundene Datensätze (Musterstadt, Musterkreis, Musterland; alle Adressen unter .example) mit abgeschlossenen Zeiträumen, verschiedenen Lizenzen, Themen und Formaten sowie 15 HVD — genug, um alle Filter des Datenkatalogs auszuprobieren. CSV und JSON enthalten dieselben Datensätze. Über den Batch-Import eingelesen, sind es gewöhnliche Datensätze (als Entwürfe). Zum bloßen Ausprobieren gibt es den Knopf „Beispieldaten laden" — siehe nächster Abschnitt.

🧪 Beispieldaten zum Ausprobieren

Datenkatalog → Einstieg  (oder Batch-Import)  →  „Beispieldaten laden"

Der Katalog startet leer — das Plugin legt bei der Aktivierung keine Datensätze mehr an. Wer das Plugin erst kennenlernen will, lädt mit einem Klick die 42 Datensätze aus samples/import-example.json. Sie werden angelegt, als Beispieldaten gekennzeichnet und veröffentlicht. Für sie gilt:

In keinem Harvest-Endpunkt. /catalog (auch ?full=1 und Turtle), /datasets/<id> und /delta liefern sie nie aus — auch keine Löschmeldung, wenn eines im Papierkorb landet. Ein Portal wie GovData sammelt also keine erfundenen Daten ein.
Im Datenkatalog nur für die Redaktion. Wer angemeldet ist und Datensätze bearbeiten darf, sieht sie mit dem Abzeichen „Beispieldaten" und kann alle Filter ausprobieren. Besucher sehen sie nicht — weder in der Liste noch in den Trefferzahlen der Filter. Ihre Detailseiten antworten Besuchern mit 404 und tragen für die Redaktion noindex. Mit show_demo="1" (Block: „Beispieldaten auch Besuchern zeigen") zeigt ein Katalog sie allen, etwa auf einer Demo-Seite.
Gekennzeichnet. In der Datensatzliste steht „— Beispieldaten" hinter dem Titel, im Formular ein Hinweis. Die Karte zeigt „Beispieldaten" statt des Links auf die Metadaten.
Bleiben Beispiele. Bearbeiten und Speichern ändert daran nichts. Wer aus einem Beispiel einen eigenen Datensatz machen will, klickt im Formular auf „Als eigenen Datensatz übernehmen".
Mit einem Klick wieder weg. „Beispieldaten entfernen" (Einstieg, Batch-Import oder Hinweis über der Datensatzliste) löscht sie endgültig.

Per WP-CLI: wp open-data-wizard samples load, … samples remove --yes, … samples status.

Wer von einer Version vor 2.47.0 aktualisiert: Der damals bei der Aktivierung angelegte Demo-Datensatz („Beispiel: Zivilgesellschaftliche Organisationen") wird, solange er nie bearbeitet wurde, ebenfalls als Beispiel gekennzeichnet und verschwindet damit aus den Endpunkten. Ein bearbeiteter Demo-Datensatz bleibt, wie er ist.

📎 Datei-Upload (Mediathek)

Steht in Tab 3 direkt unter der Zugriffs-URL, zu der er die Alternative ist:

„Datei auswählen / hochladen"-Button öffnet den nativen WordPress Media Library Frame
Beim Speichern werden _odw_file_size (Bytes) und _odw_file_format (z.B. „CSV") automatisch berechnet
Sicherheit: wp_verify_nonce + current_user_can('edit_post')

⚙️ Einstellungsseite

Untermenü unter Datenkatalog → Einstellungen mit vier Bereichen:

Katalog — Titel und Herausgebende Organisation
Standardwerte — Standard-Sprache (wird bei neuen Datensätzen vorausgefüllt)
REST API — Cache-Laufzeit (60–86400 Sekunden)
Deinstallation — Opt-in Checkbox für vollständige Datenlöschung

📊 Qualitätsindikatoren

Automatische Metadaten-Qualitätsprüfung nach der EU-MQA-Methodik. Der Leitwert ist überall Prozent + Stufe (z. B. „72 % · Gut"):

Stufe	Prozent	Bedeutung
Ausgezeichnet	≥ 87 %	nahezu vollständig
Gut	55–86 %	über der Mindestanforderung
Ausreichend	30–54 %	Grundangaben vorhanden
Mangelhaft	< 30 %	wesentliche Angaben fehlen

Berechnung nach jedem Speichern. Die Listenspalte zeigt Prozent + Stufe; die Qualitäts-Meta-Box ergänzt den MQA-Rohwert (z. B. „54 / 259 Punkte, von max. 405") als Detailzeile.

📥 Download-Card — Block oder Shortcode

Zwei Wege zur selben Karte. Empfohlen ist der Block:

Im Beitrags- oder Seiteneditor über das Plus-Symbol „Datensatz-Karte" einfügen und rechts in der Seitenleiste den Datensatz aus einer Liste wählen — keine ID zum Abtippen. Zur Auswahl stehen nur veröffentlichte Datensätze.

Alternativ der Shortcode, etwa in klassischen Editoren oder Widgets:

[odw_dataset id="123"]

Beide rendern dieselbe strukturierte Download-Card im Frontend: Titel, Thema-Badge, Lizenz, Schlagwörter als Tag-Pillen, Download-Button sowie einen Metadaten-Download-Button (JSON-LD). CSS (assets/css/frontend.css) wird nur auf Seiten geladen, die die Karte auch enthalten.

Der Block speichert ausschließlich die Datensatz-ID und rendert beim Ausliefern — ein später umbenannter Datensatz erscheint also mit seinem aktuellen Titel, statt eine eingefrorene Kopie im Beitrag zu hinterlassen.

📚 Datenkatalog — alle Datensätze auf einer Seite

Für eine Übersichtsseite aller veröffentlichten Datensätze gibt es den Block „Datenkatalog" bzw. den Shortcode:

[odw_catalog]

Die Liste zeigt je Datensatz Titel, Aktualisierungsdatum, einen kurzen Auszug der Beschreibung, Badges für Thema, Format, Größe und Lizenz sowie einen direkten Link zur Datei bzw. zum Datenangebot. Ein Klick auf den Titel öffnet die vollständige Download-Card auf derselben Seite (?odw_ds=<ID>); „Zurück zum Katalog" führt auf die zuvor besuchte Listenseite zurück. Ab mehr Einträgen als per_page blättert eine eigene Seitennavigation (?odw_page=<n>).

Attribut	Standard	Bedeutung
`per_page`	`20`	Einträge pro Seite (1–50)
`orderby`	`title`	`title` (A–Z) oder `modified` (zuletzt aktualisiert zuerst)
`theme`	—	Nur bestimmte Themen, kommagetrennt als EU-Code (`EDUC,HEAL`)
`title`	—	Überschrift über der Liste
`excerpt`	`30`	Wörter im Auszug; `0` blendet ihn aus (max. 100)
`show_demo`	`0`	`1` zeigt geladene Beispieldaten auch Besuchern. Sonst sieht sie nur, wer angemeldet ist und Datensätze bearbeiten darf. In den Harvest-Endpunkten erscheinen sie nie.
`license`	—	Nur eine Lizenz, als Kurzform (`cc-by`, `cc0`, `cc-by-sa`, `dl-de-by`, `dl-de-zero`, `odc-odbl`) oder als Lizenz-URI — auch eine eigene
`filters`	—	Auswahlfelder für Besucher, kommagetrennt: `theme`, `license`, `format`, `publisher`, `keyword`, `sort`, `period`, `open`, `hvd`
`search`	`0`	`1` zeigt ein Suchfeld (Titel, Beschreibung und Schlagworte)

[odw_catalog per_page="10" orderby="modified" theme="EDUC" title="Unsere Daten"]

Im Block stehen dieselben Einstellungen in der Seitenleiste; Themen werden dort angehakt. Ein Katalog pro Seite: Blättern (?odw_page) und Detailansicht (?odw_ds) gelten für die ganze Seite. Im Inhalt lässt sich der Block deshalb nur einmal einfügen; auch zusätzlich als Widget, in einer Seitenleiste oder im Template gehört kein zweiter Katalog auf dieselbe Seite — dort würde ein Klick beide umschalten. Für nach Thema getrennte Kataloge je eine eigene Seite anlegen. Entwürfe, private und passwortgeschützte Datensätze erscheinen weder in der Liste noch in der Detailansicht. Die Liste kommt unabhängig von der Katalogsgröße mit rund einem halben Dutzend Datenbankabfragen pro Seite aus.

Filter und Suche für Besucher

[odw_catalog filters="theme,license,format,sort" search="1"]
[odw_catalog license="cc-by" filters="theme"]
[odw_catalog filters="theme,publisher,keyword,period,open,hvd,sort" search="1"]

Mit filters und search steht über der Liste ein schlichtes Formular — ohne JavaScript, abgeschickt über „Anzeigen". Die Auswahlfelder zeigen nur Werte, die tatsächlich vorkommen, mit der Zahl der Treffer, die die Wahl zusammen mit den übrigen Filtern und der Suche ergäbe; „Filter zurücksetzen" führt zur ungefilterten Liste. Fest eingestellte Themen (theme) oder Lizenzen (license) bietet das Formular nicht noch einmal an. Der Filterzustand bleibt beim Blättern und auf dem Weg in die Detailansicht und zurück erhalten. Ohne die beiden Attribute sieht ein Katalog genau so aus wie bisher.

Eintrag in `filters`	Feld im Formular
`theme`, `license`, `format`	Auswahlfeld Thema, Lizenz bzw. Format
`publisher`	Auswahlfeld Herausgeber
`keyword`	Schlagworte mit Mehrfachauswahl; mehrere ergeben Datensätze mit mindestens einem davon
`sort`	Sortierung nach Titel oder Aktualisierung
`period`	Zeitraum der Daten, Jahr ab/bis (aus „Zeitlicher Bezug")
`open`	Kästchen „Nur Open Data"
`hvd`	Kästchen „Nur hochwertige Datensätze (HVD)", nur wenn es solche gibt

Über der Liste stehen die aktiven Filter als Chips; jeder lässt sich mit × einzeln entfernen. Auf schmalen Bildschirmen ist das Formular unter „Filter und Suche" eingeklappt, damit die Liste gleich zu sehen ist; die Chips bleiben sichtbar. Dafür und für das Aufklappfeld der Schlagworte lädt der Katalog ein kleines Skript. Ohne JavaScript funktioniert alles, nur schlichter: Die Schlagworte sind dann ein normales Mehrfach-Auswahlfeld (Strg- bzw. Cmd-Taste), das Formular ist immer offen.

Zeitraum: Ein Datensatz erscheint, wenn sich sein zeitlicher Bezug mit den gewählten Jahren überschneidet. Nur ein Startdatum heißt „seit …" und reicht bis heute. Datensätze ohne zeitlichen Bezug fallen heraus, sobald ein Zeitraum gewählt ist.
Nur Open Data: zählt jede Lizenz, die in config/licenses.txt im Abschnitt „Freie Nutzung" steht (CC0, CC BY, CC BY-SA, Datenlizenz Deutschland, ODbL …). CC BY-NC und CC BY-ND zählen nicht, eine eigene Lizenz nur, wenn ihre Adresse in diesem Abschnitt steht. Anpassen lässt sich das mit dem Filter odw_license_is_open.

Grenzen, bewusst einfach gehalten: Format und Lizenz beziehen sich auf die erste Distribution, nicht auf weitere. Eine eigene Lizenz („Sonstige") ist nur dann wählbar, wenn sie als Adresse (https://…) eingetragen ist — ein Freitext wie „Nutzung nach Absprache" erscheint nicht im Lizenzfilter. Die Suche ist eine einfache Textsuche ohne Relevanz-Sortierung und braucht mindestens zwei Zeichen. Das Engagementfeld ist nicht filterbar.

Suchmaschinen und Seiten-Caches

Die Detailansicht ist eine eigene Seite für Suchmaschinen: Titel „Datensatz – Katalogseite", Canonical <Katalogseite>?odw_ds=<ID> und <link rel="alternate"> auf JSON-LD und Turtle des Datensatzes. Eine unbekannte oder nicht öffentliche ID antwortet mit HTTP 404 und noindex, ebenso eine Listenseite hinter dem Ende.
Listenseiten ab 2 haben einen eigenen Canonical; gefilterte, durchsuchte oder umsortierte Varianten sind noindex, follow — sie zeigen dieselben Datensätze in anderer Auswahl. Ist die Website auf „Suchmaschinen davon abhalten" gestellt oder die Katalogseite auf nofollow, bleibt es dabei.
Mit Yoast SEO, Rank Math oder All in One SEO gelten dieselben Regeln; das Plugin gibt ihnen Titel, Canonical und robots über deren eigene Filter vor. Yoasts „Crawl-Bereinigung" lässt die odw_-Parameter stehen; in der Crawl-Bereinigung von All in One SEO dürfen sie nicht auf der Sperrliste stehen. Für alle anderen SEO-Plugins gilt noindex zusätzlich als HTTP-Header (X-Robots-Tag).
Seiten-Caches: Ein Datensatz hat keine eigene Adresse, ein Cache-Plugin leert die Katalogseite beim Speichern deshalb nicht von selbst. Die Katalogseite am besten vom Ganzseiten-Cache ausnehmen oder eine kurze Cache-Dauer setzen — die Liste ist billig genug. Für ein gezieltes Leeren meldet die Action odw_catalog_changed jede Änderung, die den Katalog betrifft (siehe DOCUMENTATION.md).

🔗 REST API Endpoints

GET https://deine-website.de/wp-json/datenatlas/v1/catalog
GET https://deine-website.de/wp-json/datenatlas/v1/datasets/<id>
GET https://deine-website.de/wp-json/datenatlas/v1/delta?since=<ISO8601>

Diese URLs können bei einer Open-Data-Plattform als Harvest-Quelle eingetragen werden — einmalig, ohne weiteren Aufwand.

Catalog-Parameter: page, per_page, theme, license, format (jsonld, json oder turtle), full

Content Negotiation: Alle drei Endpunkte liefern jsonld, json und turtle. Ohne ?format= entscheidet der Accept-Header (mit q-Werten); ein explizites ?format= hat immer Vorrang. Antworten tragen Vary: Accept.

Delta-Parameter: since (erforderlich, ISO 8601), page, per_page, format — liefert nur Datensätze, die nach dem angegebenen Zeitstempel geändert wurden, plus Löschmeldungen (odw:removed) für Datensätze, die seitdem im Papierkorb gelandet sind oder ein Passwort bekommen haben

Nur Öffentliches: Die Endpunkte liefern genau die Datensätze, die auch der Datenkatalog der Website Besuchern zeigt. Entwürfe, private und passwortgeschützte Datensätze sowie Beispieldaten erscheinen nicht; /datasets/<id> antwortet für sie mit derselben 404 wie für eine unbekannte ID.

🌾 Harvesting durch externe Open-Data-Portale

Viele Open-Data-Portale holen Metadaten per Pull-Harvesting ab: Sie hinterlegen beim Portal eine stabile URL, unter der Ihr kompletter Katalog als ein DCAT-AP.de-Dokument liegt. Genau dafür bietet der Catalog-Endpoint einen Voll-Modus:

# Vollständiger Katalog als Turtle (empfohlen für RDF-Harvester)
GET https://deine-website.de/wp-json/datenatlas/v1/catalog?full=1&format=turtle   →  text/turtle

# … oder als JSON-LD
GET https://deine-website.de/wp-json/datenatlas/v1/catalog?full=1                 →  application/ld+json

full=1 liefert alle öffentlichen Datensätze in einem Abruf (ohne Paginierung) als dcat:Catalog → dcat:Dataset → dcat:Distribution — das Muster, das RDF-Harvester erwarten.
format=turtle serialisiert denselben Graphen als Turtle (text/turtle) — ohne externe RDF-Bibliothek. JSON-LD (application/ld+json) und json bleiben verfügbar. Harvester, die rein über Header aushandeln, senden stattdessen Accept: text/turtle.
Die Datensatz-URIs (@id) sind über Releases stabil (an die Post-ID gebunden), sodass Harvester Aktualisierungen/Löschungen korrekt zuordnen und keine Duplikate anlegen.

Die fertigen Harvest-URLs zeigt das Plugin kopierfertig unter Datenkatalog → Einstellungen → Harvesting an.

✅ DCAT-AP 3.0 Konformität — nachgewiesen, nicht behauptet

Alle Ausgaben folgen DCAT-AP 3.0 / DCAT-AP.de. Die erzeugten Dokumente wurden gegen die offiziellen SHACL-Regeldateien geprüft — beide Profile melden Conforms: True:

Profil	Quelle	Ergebnis
DCAT-AP.de	GovData (v3.0)	✅ konform
DCAT-AP 3.0 (EU)	SEMICeu (Release 3.0.0)	✅ konform

Diese Regeldateien liegen dem Plugin bei (siehe unten), sodass Sie vor der Anmeldung bei einem Portal selbst prüfen können.

🔎 DCAT-AP-Validierung (SHACL)

Ob die erzeugten Metadaten dem Standard formal entsprechen, lässt sich mit SHACL prüfen — der offiziellen Regelsprache, mit der die EU und GovData DCAT-AP-Konformität definieren. Damit du nicht auf inoffizielle Regeln angewiesen bist, bringt das Plugin die maßgeblichen, offiziellen Shape-Dateien gebündelt mit (unter config/shacl/):

Datei	Herkunft	Zweck	Lizenz
`dcat-ap-SHACL.ttl`	SEMICeu/DCAT-AP (Release 3.0.0)	generische EU-DCAT-AP-3.0-Regeln	CC BY 4.0
`dcat-ap-SHACL-DE.ttl`	GovDataOfficial (v3.0)	DCAT-AP.de-Ergänzungen (u. a. `dcatde:`-Felder, deutschsprachige Meldungen)	CC0

Wichtig: Das Plugin führt SHACL nicht selbst aus — dafür gibt es in PHP keine praxistaugliche Engine. Die Dateien liegen als Referenz bei; die eigentliche Prüfung erfolgt über einen externen Validierungsdienst oder ein lokales SHACL-Werkzeug. So bleibt das Plugin self-contained und ohne Pflicht-Netzwerkzugriff.

So validierst du einen Datensatz

JSON-LD abrufen — jeder veröffentlichte Datensatz ist über die REST-API erreichbar:
```
https://<deine-site>/wp-json/datenatlas/v1/datasets/<ID>
```
(den ganzen Katalog liefert …/datenatlas/v1/catalog).
Gegen die Shapes prüfen — mit einem der offiziellen Dienste (Datei hochladen bzw. JSON-LD einfügen):
- EU-Validator (SHACL / ITB): https://www.itb.ec.europa.eu/shacl/dcat-ap/upload
- data.europa.eu MQA: https://data.europa.eu/mqa/
- DCAT-AP.de-Validator (Docker/ITB): siehe DCAT-AP.de-SHACL-Validation

Oder lokal validieren, z. B. mit pySHACL gegen die gebündelten Shapes:

# JSON-LD des Datensatzes speichern …
curl -s "https://<deine-site>/wp-json/datenatlas/v1/datasets/42" -o datensatz.jsonld
# … und gegen die DCAT-AP.de-Shapes prüfen
pyshacl -s config/shacl/dcat-ap-SHACL-DE.ttl -df json-ld datensatz.jsonld

Der Validierungs-Report zeigt Verstöße (sh:Violation) mit Pfad und Meldung — so siehst du genau, welches Feld ggf. nachzubessern ist.

Verhältnis zum Qualitäts-Score

Die integrierten Qualitätsindikatoren (siehe oben) decken die „gesetzt?"- und Vokabular-Prüfungen der EU-MQA-Methodik bereits offline ab. Die MQA-Metrik „DCAT-AP-Konformität" (SHACL, 30 Punkte) wird davon bewusst nicht automatisch bewertet, sondern über die hier beschriebene externe Validierung geprüft (Ansatz „achievable max"). Details im MQA-Konzept.

Was der Open Data Wizard nicht ist

Eine ehrliche Abgrenzung hilft bei der Einordnung:

Kein Datenportal. Das Plugin macht eine einzelne Organisation harvestbar. Der Datenkatalog-Block zeigt die eigenen Datensätze auf der eigenen Website, auf Wunsch mit einfachen Filtern und einer Textsuche. Relevanz-Suche, Nutzerkonten, Kommentare oder das Zusammenführen fremder Kataloge bleiben Aufgabe der Portale, die die Daten abholen (GovData, data.europa.eu).
Kein Datenmanagement-System. Die eigentlichen Dateien liegen, wo sie liegen: in der Mediathek, auf einem Server, in einem Repositorium. Das Plugin beschreibt sie, es verwaltet sie nicht.
Kein Ersatz für fachliche Sorgfalt. Es prüft, ob eine Lizenz angegeben ist — nicht, ob es die richtige ist. Es weist auf fehlende Angaben hin; die inhaltliche Qualität der Beschreibung bleibt Aufgabe der Person, die sie schreibt.

Installation

Für Anwender:innen

ZIP-Datei aus den Releases herunterladen
Im WordPress-Backend: Plugins → Installieren → Plugin hochladen
Plugin aktivieren

Keine weiteren Abhängigkeiten. Keine Programmierkenntnisse erforderlich. Der Katalog startet leer; zum Ausprobieren lassen sich Beispieldaten mit einem Klick laden.

Wichtig: das Release-ZIP verwenden, nicht das Quellcode-Archiv. Der grüne „Code"-Button auf GitHub liefert ein Archiv ohne die benötigten Programmbibliotheken — damit bleibt das Plugin inaktiv und meldet „Installation unvollständig". Nur das unter Releases verlinkte open-data-wizard-<version>.zip ist vollständig.

Dasselbe gilt, wenn Sie aus einer Version vor 2.34.0 automatisch aktualisiert haben: Einmalig das Release-ZIP hochladen behebt es dauerhaft; danach ziehen Updates automatisch das vollständige Paket. Ihre Datensätze bleiben dabei erhalten — sie liegen in der Datenbank, nicht in den Plugin-Dateien.

Automatische Updates

Das Plugin meldet neue Versionen im WordPress-Backend (via GitHub Plugin URI, ausgewertet von Git Updater o. ä.). Das Update-Paket kommt aus dem Branch release, den die CI bei jeder Veröffentlichung neu erzeugt: Er enthält exakt den Inhalt des Release-ZIPs, also das installationsfertige Plugin samt vendor/.

Der Weg über einen Branch statt über das Release-Asset ist Absicht — er läuft über ein schlichtes Quellarchiv statt über die GitHub-API und braucht deshalb weder Zugriffstoken noch API-Kontingent.

Umstieg auf 2.35.6: Der Updater liest die Kopfzeilen der installierten Version. Wer von 2.35.5 oder früher kommt, muss das Release-ZIP einmalig von Hand hochladen; ältere Installationen zeigen sonst „Aktualisierung fehlgeschlagen. Das Aktualisierungspaket ist nicht verfügbar." Ab 2.35.6 laufen Updates dann automatisch durch.

Für Entwickler:innen

git clone https://github.com/daimpad/OpenDataWizard.git
cd OpenDataWizard
composer install   # erzeugt vendor/ (Carbon Fields + PHPStan, WPCS, PHPUnit)

composer install ist zwingend erforderlich. vendor/ ist bewusst nicht im Repository — es wird reproduzierbar aus composer.lock erzeugt (lokal, in der CI und beim Release-Build). Ohne diesen Schritt fehlt Carbon Fields und das Plugin zeigt einen entsprechenden Admin-Hinweis.

Den Plugin-Ordner in eine lokale WordPress-Instanz einbinden (z.B. via LocalWP).

Systemvoraussetzungen:

WordPress ≥ 6.4
PHP ≥ 8.1
Composer (nur für Entwicklung)

Dev-Tools:

composer phpcs      # WordPress Coding Standards prüfen
composer phpcbf     # Automatisch korrigieren
composer phpstan    # Statische Analyse (Level 6)
composer test       # PHPUnit-Tests ausführen

CI läuft via GitHub Actions (.github/workflows/ci.yml) auf PHP 8.1, 8.2 und 8.3.

Für Entwickler: Siehe CLAUDE.md für Architektur-Übersicht, Patterns, Debugging-Tipps und Workflows.

🛠 Technische Dokumentation

Die ausführliche Entwickler-Dokumentation (Architektur, Dateistruktur, DCAT-AP-Feldmapping, REST-API, Erweiterbarkeit, WP-CLI, Abhängigkeiten) ist in einem eigenen Dokument gepflegt:

➡️ DOCUMENTATION.md

🧩 Technische Spezifikationen

Alle technischen Spezifikationen — Metadatenmodell, JSON-LD-Namespaces, kontrollierte Vokabulare, der vollständige DCAT-AP-/DCAT-AP.de-Feldkatalog mit Gap-Analyse, das Feld-Registry-Schema sowie die phasierte Umsetzungsplanung samt Umsetzungsstand — sind in einem eigenen Dokument gepflegt:

➡️ TECHNICAL-SPEC.md

Neue technische Festlegungen gehören in dieses Dokument (nicht in die anwenderorientierten Kapitel oben).

Roadmap

Abgeschlossen (v1.0 — v2.1):

In Planung (v2.2+): — Details siehe Technische Spezifikationen § 7

Mitwirken

Beiträge sind willkommen — ob Fehlermeldungen, Verbesserungsvorschläge oder Pull Requests.

Bitte öffne zunächst ein Issue, bevor du größere Änderungen einreichst.

Deinstallation

Das Plugin löscht bei Deinstallation standardmäßig keine Daten (Opt-in).

Um alle Plugin-Daten zu löschen, die Checkbox unter Datenkatalog → Einstellungen → Deinstallation aktivieren und dann das Plugin im WordPress-Backend deinstallieren. uninstall.php entfernt alle odw_dataset-Posts, alle _odw_*-Metafelder sowie die Plugin-Optionen.

In einem Satz

Der Open Data Wizard verwandelt eine gewöhnliche WordPress-Website in eine standardkonforme Open-Data-Quelle — bedienbar von Menschen ohne DCAT-AP-Kenntnisse, anschlussfähig für Portale, die europäische Standards erwarten, und ohne dass die Organisation Kontrolle über ihre Daten oder ihre Infrastruktur abgibt.

Lizenz

GPL-2.0-or-later — siehe LICENSE

Name		Name	Last commit message	Last commit date
.github		.github
assets		assets
bin		bin
blocks		blocks
config		config
docs		docs
includes		includes
languages		languages
samples		samples
tests		tests
.gitignore		.gitignore
.wp-env.json		.wp-env.json
API.md		API.md
CHANGELOG.md		CHANGELOG.md
CLAUDE.md		CLAUDE.md
DOCUMENTATION.md		DOCUMENTATION.md
E2E_TESTING.md		E2E_TESTING.md
LICENSE		LICENSE
README.md		README.md
SECURITY.md		SECURITY.md
TECHNICAL-SPEC.md		TECHNICAL-SPEC.md
composer.json		composer.json
composer.lock		composer.lock
open-data-wizard.php		open-data-wizard.php
package-lock.json		package-lock.json
package.json		package.json
playwright.config.js		playwright.config.js
uninstall.php		uninstall.php

Latest commit

History

Folders and files

Repository files navigation