Dataset-Schema: Datensätze für Dataset Search auszeichnen

Das Dataset-Schema ist ein Vokabular von schema.org, mit dem du einer Suchmaschine erklärst, dass eine Seite einen Datensatz beschreibt: was er enthält, wer ihn erstellt hat, unter welcher Lizenz er steht und wo man ihn herunterlädt. Google wertet dieses Markup vor allem für Google Dataset Search aus, eine eigene Suche, die sich an Forschende, Journalistinnen, Datenanalysten und alle richtet, die nach Rohdaten statt nach Artikeln suchen.

Für Hochschulen, Statistikämter, Behörden und Datenportale ist das der wichtigste Weg, gefunden zu werden. Ein Datensatz besteht oft nur aus einer Tabelle zum Download und ein paar Zeilen Text. Ohne strukturierte Angaben kann eine Suchmaschine kaum erkennen, dass es sich um Daten handelt, geschweige denn, was sie messen. Dieser Beitrag zeigt, welche Eigenschaften zählen, wie ein sauberes Beispiel aussieht und wo die typischen Fehler liegen.

Was Dataset-Markup leistet und was nicht

Dataset-Markup ist kein Ranking-Hebel für gewöhnliche Webseiten. Es macht Datensätze als solche auffindbar. Google Dataset Search durchsucht nach Angaben von Google Seiten, die Datensätze mit schema.org/Dataset oder vergleichbaren Formaten beschreiben, und führt Nutzer von dort zur Originalseite des Anbieters. Der Datensatz selbst wird nicht bei Google gehostet. Die Daten bleiben bei dir, Google baut nur einen Verzeichnisdienst darüber.

Wichtig ist die Abgrenzung zur normalen Websuche. Ob Google Dataset-Informationen dort zusätzlich als erweiterte Darstellung zeigt, liegt in Googles Hand und kann sich ändern. Plane deshalb nicht mit einem garantierten Snippet. Plane mit der Dataset Search als Ziel und betrachte alles darüber hinaus als Bonus. Das Markup hat außerdem einen Nebeneffekt, der unabhängig von Google wirkt: Andere Dienste, Datenkataloge und Forschungsinfrastrukturen können dieselben Angaben lesen.

Ebenso wichtig ist, was das Schema nicht ist. Es ersetzt weder eine Datendokumentation noch ein Metadatenformat wie DCAT. Es ist die knappe, maschinenlesbare Visitenkarte, die auf der Landingpage des Datensatzes steht und auf die ausführliche Dokumentation verweist.

Die Landingpage als Grundlage: eine URL pro Datensatz

Bevor du eine Zeile JSON schreibst, brauchst du eine Seite, die den Datensatz beschreibt. Das klingt banal, scheitert aber häufig. Viele Institutionen legen Daten als nackte Dateien auf einen Server oder bündeln hundert Tabellen auf einer einzigen Übersichtsseite. Für Dataset-Markup gilt: Jeder Datensatz braucht eine eigene, dauerhaft erreichbare URL, die den Datensatz für Menschen beschreibt. Google verlangt, dass die im Markup genannten Informationen auch für Besucher auf der Seite sichtbar sind. Markup, das Inhalte behauptet, die niemand sieht, widerspricht den Richtlinien für strukturierte Daten.

Die Landingpage sollte mindestens Titel, eine verständliche Beschreibung, die Herkunft der Daten, den Zeitraum, das räumliche Gebiet, die Lizenz und die Downloadlinks enthalten. Wer das sauber auf die Seite schreibt, hat den größten Teil des Markups bereits formuliert; der Rest ist Übersetzung in JSON-LD.

Die Seite muss außerdem normal indexierbar sein. Ein noindex, eine per robots.txt gesperrte Landingpage oder ein Login davor schließen sie von der Dataset Search aus, genau wie von jeder anderen Suche. Das betrifft vor allem Datenportale, die ihre Detailseiten per JavaScript nachladen. Prüfe im gerenderten HTML, dass das JSON-LD tatsächlich im Dokument steht.

Pflichtangaben und empfohlene Eigenschaften

Google nennt in der Dokumentation zwei Pflichtfelder: name und description. Der Name bezeichnet den Datensatz, nicht die Organisation und nicht die Seite. Die Beschreibung muss nach Googles Vorgabe zwischen 50 und 5.000 Zeichen lang sein und den Inhalt erklären: Was wurde erhoben, in welcher Einheit, wie umfangreich ist er? Ein Satz wie „Daten zur Bevölkerung“ erfüllt formal die Pflicht und hilft niemandem.

Darüber hinaus gibt es eine Reihe empfohlener Eigenschaften, die in der Praxis den Unterschied zwischen einem gefundenen und einem übersehenen Datensatz ausmachen. Die wichtigsten:

• creator: Person oder Organisation, die den Datensatz erstellt hat, am besten mit Name und URL. Bei Forschungsdaten gehört hier die Einrichtung hin, nicht die Webredaktion.
• license: Die Nutzungslizenz, idealerweise als URL, etwa zu einer Creative-Commons-Lizenz. Fehlt sie, bleibt für Nachnutzer unklar, ob sie die Daten verwenden dürfen.
• distribution: Ein oder mehrere DataDownload-Objekte mit contentUrl und encodingFormat, etwa CSV, JSON oder XLSX. Sie verbinden die Beschreibung mit den Dateien.
• temporalCoverage und spatialCoverage: Zeitraum und Gebiet, auf die sich die Daten beziehen. Der Zeitraum steht im ISO-8601-Format, offene Enden sind mit zwei Punkten möglich.
• keywords: Suchbegriffe, die Fachleute tatsächlich verwenden, nicht Marketingvokabular.
• identifier: Ein persistenter Bezeichner, bei Forschungsdaten typischerweise ein DOI.
• variableMeasured: Welche Größen der Datensatz enthält, etwa „Jahresniederschlag in Millimetern“.
• isAccessibleForFree: Ob der Zugriff kostenlos ist.
• version, dateModified, citation, funder, includedInDataCatalog, sameAs, isBasedOn: Angaben zu Stand, Herkunft und Einbettung, die Vertrauen schaffen und Dubletten auflösen.

Ein vollständiges Beispiel in JSON-LD

Google empfiehlt JSON-LD, und für Datensätze ist das auch praktisch: Der Block steht getrennt vom sichtbaren HTML und lässt sich aus einer Metadatenbank generieren. Als Beispiel dient ein fiktiver Datensatz eines Landesamts für Umwelt, Messwerte der Gewässergüte. Die Werte sind ausgedacht und dienen nur der Illustration.

Der Block beginnt mit dem Kontext https://schema.org und dem Typ Dataset. Es folgen name („Gewässergüte an Messstellen in Musterland, 2010 bis 2023“) und eine description, die erklärt, dass monatliche Messungen von Sauerstoffgehalt, pH-Wert und Nährstoffen an festen Messstellen zusammengefasst sind, wie sie erhoben wurden und welche Lücken es gibt. Unter creator steht das Landesamt als Organization mit Name und URL. Die license verweist auf die URL der Lizenz, unter der die Daten stehen.

Bei temporalCoverage steht „2010-01-01/2023-12-31“. Bei spatialCoverage steht ein Place mit dem Namen des Bundeslandes; wer genauere Geometrien hat, kann eine GeoShape mit Koordinaten der Bounding Box ergänzen. Unter distribution liegen zwei DataDownload-Objekte: eine CSV-Datei und eine JSON-Fassung, jeweils mit contentUrl und encodingFormat. Ein identifier mit dem DOI, ein paar keywords wie „Gewässergüte“, „Wasserqualität“ und „Umweltmonitoring“ sowie variableMeasured für die erfassten Größen runden den Block ab.

Zwei Details, die oft schiefgehen: Die Werte in contentUrl müssen auf die tatsächliche Datei oder einen stabilen Downloadpfad zeigen, nicht auf eine Seite, die erst nach einem Formular die Datei liefert. Und die Angaben im JSON-LD dürfen der sichtbaren Seite nicht widersprechen. Steht im Markup ein anderer Zeitraum als im Fließtext, ist das schlimmer als ein fehlendes Feld.

Besondere Fälle: Versionen, Teilmengen und Datenkataloge

Reale Datensätze sind selten statisch. Ein Statistikamt veröffentlicht jedes Jahr eine neue Ausgabe derselben Reihe, ein Forschungsprojekt korrigiert Fehler und vergibt eine neue Version. Es gibt hier keine einzige richtige Lösung, aber ein vernünftiges Muster: Jede Version bekommt nach Möglichkeit eine eigene Landingpage mit eigenem Identifier, und die Seiten verweisen mit Angaben wie version, isBasedOn oder sameAs aufeinander. Alternativ führst du eine Seite für die aktuelle Fassung und hältst frühere Stände auf Unterseiten vor. Was du vermeiden solltest, ist eine Seite, deren Inhalt sich unbemerkt ändert, während der DOI auf einen alten Stand zeigt.

Besteht ein Datensatz aus Teilen, etwa einer Tabelle je Bundesland, kannst du mit hasPart und isPartOf Beziehungen ausdrücken. Das ist sinnvoll, wenn die Teile eigenständig nutzbar sind. Stecken dahinter nur technische Dateiaufteilungen, reicht eine Dataset-Seite mit mehreren Einträgen unter distribution.

Betreibst du ein ganzes Portal, hilft die Eigenschaft includedInDataCatalog, die den Datensatz einem DataCatalog zuordnet. Portale auf Basis von Software wie CKAN können schema.org-Markup aus ihren Metadaten erzeugen; in Deutschland und Europa basieren viele Verzeichnisse auf dem DCAT-Vokabular (DCAT-AP). Die Abbildung von DCAT auf schema.org ist weitgehend möglich, aber nicht verlustfrei. Kontrolliere deshalb, was ein Generator tatsächlich ausgibt, statt dich darauf zu verlassen, dass ein Häkchen in den Einstellungen alles richtig macht.

Prüfen, überwachen und typische Fehler

Validiere das Markup, bevor es live geht. Der Schema-Markup-Validator von schema.org prüft die Syntax und die Typen generell, der Rich-Results-Test von Google zeigt, ob Google die Dataset-Angaben erkennt. Nach der Veröffentlichung kann die Search Console einen Bericht zu Datensätzen anzeigen, sobald Google entsprechendes Markup auf deiner Domain findet. Dort siehst du Fehler und Warnungen, etwa fehlende Pflichtfelder.

Wundere dich nicht, wenn die Aufnahme dauert. Google muss die Seite crawlen, das Markup verarbeiten und den Datensatz in den eigenen Index der Dataset Search übernehmen. Wie lange das im Einzelfall dauert, kann niemand seriös zusagen. Eine aktuelle XML-Sitemap mit den Landingpages beschleunigt die Entdeckung, weil Google die Seiten dann nicht nur über interne Links finden muss.

Aus der Praxis kennt man eine Handvoll wiederkehrender Fehler:

• Das Markup steht auf einer Übersichtsseite mit hundert Datensätzen statt auf den einzelnen Landingpages.
• Die Beschreibung ist ein Platzhalter oder wiederholt nur den Titel.
• Die Lizenz fehlt oder steht nur als Hinweis „siehe Nutzungsbedingungen“ im Text.
• contentUrl zeigt auf eine Login- oder Formularseite statt auf die Datei.
• Die Seite wird erst per JavaScript aufgebaut, und das Markup fehlt im gerenderten HTML.
• Seiten, die gar keinen Datensatz beschreiben, etwa Blogartikel über Daten oder Werbung für ein Analyseprodukt, werden mit Dataset ausgezeichnet. Das ist irreführend und verstößt gegen die Richtlinien.

Beschreibungen schreiben, die Fachleute finden

Die Beschreibung ist der Teil, an dem Institutionen am meisten verschenken. Datenportale übernehmen oft den Text aus einem internen Metadatenfeld, der für Kolleginnen geschrieben wurde: Abkürzungen, Projektkürzel, Verweise auf Dokumente, die außerhalb des Hauses niemand kennt. Wer über eine Suche kommt, kennt weder dein Projekt noch deine Behörde. Die Beschreibung muss deshalb für sich allein stehen und die Fragen beantworten, die jemand vor dem Download stellt.

Hilfreich ist eine feste Reihenfolge. Zuerst der Gegenstand in einem Satz: Was wurde gemessen oder gezählt? Dann die Einheit der Beobachtung, also ob eine Zeile eine Person, eine Messstelle, einen Monat oder eine Gemeinde darstellt. Danach Umfang und Erhebungsmethode, bekannte Lücken und Einschränkungen, und zuletzt ein Hinweis auf die Dokumentation. Solche Angaben sind keine Dekoration. Wer Daten nachnutzen will, entscheidet anhand genau dieser Punkte, ob der Datensatz taugt.

Vermeide Werbesprache. „Umfassende, hochwertige Daten“ sagt nichts, „monatliche Messwerte von 140 Messstellen“ dagegen schon, sofern die Zahl stimmt. Nenne nur Zahlen, die du selbst belegen kannst, und halte sie aktuell. Bei der Wortwahl lohnt ein Blick in die Fachsprache des Gebiets: Hydrologen suchen nach „Abfluss“ und „Pegel“, nicht nach „Wassermengen“. Wer beides sinnvoll in Beschreibung und keywords unterbringt, deckt mehr echte Suchformulierungen ab, ohne zu stopfen.

Zusammenarbeit, Zugang und Nachnutzung

In der Praxis scheitert Dataset-Markup selten an der Technik. Es scheitert daran, dass die Menschen, die die Daten kennen, nicht die sind, die die Webseite pflegen. Die Fachabteilung liefert Dateien und vielleicht ein Metadatenblatt, das Webteam baut eine Seite, und niemand fühlt sich für das JSON-LD zuständig. Lege deshalb fest, aus welcher Quelle die Angaben kommen, und erzeuge das Markup automatisch aus ihr, statt es per Hand zu tippen.

Ein tragfähiger Ablauf sieht so aus: Die Fachabteilung pflegt ein strukturiertes Metadatenblatt mit festen Feldern für Titel, Beschreibung, Lizenz, Zeitraum, Gebiet und Kontakt. Das Content-Management-System oder das Portal rendert daraus die sichtbare Landingpage und das JSON-LD in einem Schritt. Eine einfache Prüfung beim Veröffentlichen lehnt Datensätze ohne Lizenz oder mit zu kurzer Beschreibung ab. Stichproben nach dem Livegang zeigen dann, ob die Ausgabe stimmt.

Halte außerdem fest, wer bei Änderungen verantwortlich ist. Wenn ein Datensatz zurückgezogen wird, sollte die Seite nicht einfach verschwinden und einen Fehler liefern. Ist er ersetzt worden, verweist du per Weiterleitung oder Hinweis auf die Nachfolgeversion. Wurde er aus rechtlichen Gründen entfernt, ist ein sauberer 410-Status ehrlicher als eine leere Seite, die weiter im Index steht.

Findbarkeit ist nur der erste Schritt. Wer über die Dataset Search kommt, will die Daten in der Regel laden, prüfen und zitieren. Dafür brauchen sie drei Dinge: einen stabilen Link, eine klare Lizenz und eine Zitierempfehlung. Die citation-Eigenschaft und ein DOI sind dafür gedacht. Wenn Behörden offene Daten bereitstellen, entscheidet die Lizenzangabe oft darüber, ob Dritte den Datensatz überhaupt in eigene Anwendungen einbinden.

Bei eingeschränktem Zugang, etwa bei sensiblen Gesundheitsdaten, ist Dataset-Markup trotzdem möglich. Du beschreibst dann den Datensatz, setzt isAccessibleForFree passend und erklärst auf der Seite, wie der Zugang beantragt wird. Die Metadaten sind öffentlich, die Daten müssen es nicht sein. Das ist gerade für Forschung nützlich, weil andere erfahren, dass es diese Daten überhaupt gibt.

Pflege schließlich das Markup mit, wenn sich die Daten ändern. dateModified, Zeiträume, Dateigrößen und Links veralten sonst still. Am zuverlässigsten ist es, das JSON-LD aus derselben Quelle zu erzeugen wie die sichtbare Beschreibung, sodass beide nicht auseinanderlaufen können.