5.1. 🚀 Grundlagen#
In diesem Abschnitt widmen wir uns einer praktischen SPARQL-Übung, die die Grundlagen dieser Abfragesprache vermittelt und aufzeigt, wie Datensätze mit SPARQL abgefragt werden können. Thematisch nähern wir uns damit bereits dem Untersuchungsauftrag des Experten Amir Weber an, der in der Einleitung vorgestellt wurde. Der Auftrag besteht darin, zu prüfen, welche offen verfügbaren Daten existieren, die dazu beitragen können, den Baumbestand in einer bestimmten Region zu ermitteln.
Weitere Informationen
Der Open Data Support der Europäischen Kommission hat ein Trainingsmodul als Präsentation (pdf) zu RDF und SPARQL veröffentlicht. Wenn Sie möchten, schauen Sie auch in diese Einführung, um Ihr Wissen zu rekapitulieren oder das, was Sie hier lesen zu begleiten und zu vertiefen.
Wir arbeiten mit Jupyter Notebook - einem Dateiformat, welches ermöglicht, Erklärtext und Code in verschiedenen Programmiersprachen gleichberechtigt nebeneinander darzustellen. Dadurch wird die visuelle Darstellung von echtem Code für Abfragen und deren Ergebnisse ermöglicht. Zusätzlich können Erläuterungen zu den aufgerufenen Befehlen sowie weitere Kommentare dargestellt werden.
Am besten lässt sich das Gelernte direkt ausprobieren. Für eigene SPARQL-Abfragen empfehlen wir den interaktiven SPARQL-Editor von data.europa.eu. Dieser bietet eine intuitive Benutzeroberfläche, mit der sich SPARQL-Queries unkompliziert testen und ausführen lassen – ideal, um erste praktische Erfahrungen zu sammeln oder die im Jupyter Notebook gezeigten Beispiele nachzuvollziehen.
Die eingangs erwähnte Forschungsfrage lautet:
Welche offenen Daten gibt es, die dazu beitragen, den Bewässerungsbedarf von Bäumen in einer bestimmten Region zu ermitteln?
Um diese Frage zu beantworten, werden verschiedene Aspekte aus Datenportalen erfragt werden müssen.
Wie viele Datensätze beinhalten das Wort „Baumkataster“ im Titel?
Wer stellt die meisten Daten bereit?
Wie unterscheiden sich die Bereitsteller in ihrer Anzahl an Formaten?
Story
Diese Fragen sind der Ausgangspunkt für eine tiefere Untersuchung der verfügbaren offenen Daten. An der Seite von Dr. Weber werden wir die Datensätze nach Bundesländern und Bereitstellern filtern, um ein besseres Verständnis darüber zu gewinnen, welche Regionen besonders viele und vielfältige Baumkataster-Daten zur Verfügung stellen. Recherchieren Sie mit ihm zusammen, wie die entsprechende Datengrundlage ist.
5.1.1. Endpunkt definieren#
In der Regel muss zuerst ein sogenannter endpoint bzw. Endpunkt definiert werden. Der Endpunkt ist die maschinenlesbare Schnittstelle zum Repositorium, in dem jene Metadaten gespeichert sind, die wir abfragen wollen.
Bei der Verwendung eines Online-Tools zur Generierung von SPARQL-Abfragen ist die Definition eines Endpunkts häufig nicht nötig, da dieser schon automatisch definiert ist.
Der SPARQL Endpunkt des deutschen Open Data Portals GovData ist beispielsweise https://www.govdata.de/sparql [IT-Kooperation, 2024].
Beispielhaft wollen wir nun das europäische Datenportal durchsuchen. Die Seite für SPARQL-Queries finden wir auf der Webseite https://data.europa.eu/data/sparql.
Wenn Sie unserer Empfehlung folgen und die SPARQL-Abfragen über das Portal von data.europa.eu eingeben, brauchen Sie die folgende Übung, die Angabe des Endpunktes, nicht zu absolvieren.
Der folgende Befehl, der Teil vom SPARQL-Python-Paket ist, erlaubt uns, alle künftigen Abfragen mit dem europäischen Datenportal als unserem Endpunkt zu verknüpfen.
Er lautet %endpoint https://data.europa.eu/sparql und wird der SPARQL-Abfrage vorangestellt.
%endpoint https://data.europa.eu/sparql
5.1.2. SPAQRL-Syntax#
Widmen wir uns nun der SPARQL-Syntax, indem wir uns die Struktur unserer ersten Abfrage ansehen.
Zur Erinnerung: Der im Kapitel DCAT-AP erklärte Metatenstandard DCAT-AP ist zentral für die Untersuchung der Metadateneigenschaften und definiert die Struktur und den Inhalt der Metadatenfelder (DCAT-AP Handbuch).
Einführung in den Code
Widmen wir uns zuerst den Befehlen SELECT und WHERE:
SELECT
Mit SELECT wählen wir die Properties bzw. die Eigenschaften, die aufgelistet werden sollen sowie deren Anzeigereihenfolge. Jede Eigenschaft entspricht einer Spalte, die in der Tabelle mit Ergebnissen zu sehen ist.
SELECT ?contributorid zeigt uns also alle Werte für contributorid an.
WHERE
Der WHERE-Befehl ist der Kern jeder SPARQL-Abfrage, denn er definiert die Bedingungen, die erfüllt werden müssen, damit eine Beobachtung unter SELECT überhaupt aufgelistet werden kann. Das heißt, es werden nur die Beobachtungen aufgelistet, die alle Bedingungen erfüllen.
Unsere Bedingung ?uri http://dcat-ap.de/def/dcatde/contributorID ?contributorid.
sucht nach allen Ressourcen ?uri, die eine Eigenschaft (Property) mit dem URI http://dcat-ap.de/def/dcatde/contributorID besitzen. Der Wert dieser Eigenschaft wird in der Variable ?contributorid gespeichert.
Die WHERE-Funktion besteht immer aus drei Elementen. Diese Struktur ist essentiell für die SPARQL-Sprache. Durch die sogenannten Tripeln werden Bezüge zwischen den Eigenschaften erstellt.
Das heißt: Die Abfrage findet sämtliche Beitragenden-IDs (z.B. IDs von Behörden, die den Datensatz verantworten) in den Metadaten, die auf data.europa.eu verfügbar sind und nach dem DCAT-AP.de-Vokabular beschrieben sind.
Code
Output
Erklärung des Ergebnisses
Wir haben eine erste SPARQL-Abfrage erstellt. Diese enthält nur eine Spalte, die uns Datenbereitsteller ausgibt und daher nur wenig aussagekräftig ist. Außerdem dürfen wir nicht aus dem Blick verlieren, dass wir nur jene Metadaten abfragen (können), die im Portal data.europa.eu überhaupt verzeichnet sind.
5.1.3. Erweiterung der Abfrage#
Unsere erste Abfrage ist nicht besonders präzise oder aussagekräftig. Daher wollen wir nun weitere Befehle hinzufügen, um Ergebnisse zu erhalten, mit denen wir weiterarbeiten können. Schauen Sie sich dazu den Code und die Erklärung an.
Einführung in den Code
PREFIX
In den ersten drei Zeilen sehen wir sogenannte PREFIXES. Durch sie kann man auf diverse Eigenschaften verweisen und Bezüge zwischen diesen Eigenschaften herstellen. Sie sind zwar wichtig für eine einfachere Gestaltung der Abfragen, aber nicht essentiell. Es handelt sich um Abkürzungen, die es ermöglichen, Links nicht immer wieder ausschreiben zu müssen.
dct: <http://purl.org/dc/terms/> bedeutet, dass mit dct (dublin core term) nach Ressourcen gesucht werden kann, die sich im Namensraum von http://purl.org/dc/terms/, also der Dublin Core Metadata Initiative (DCMI), befinden. So lässt sich nach DCMI standardisierten Metadaten suchen ohne die volle Adresse eingeben zu müssen. Mit dct:title lässt sich beispielsweise nach dem Metadatenelement “Titel” suchen.
Mit dcatde: <http://dcat-ap.de/def/dcatde/> können wir, analog zum vorherigen Beispiel, mit der Abkürzung dcatde (dcat deutschland) den Namensraum des deutschen Applikationsprofils von DCAT (Data Catalog Vocabulary) durchsuchen. dcatde:contributorID ermöglicht die Suche nach einem eindeutig identifizierbaren Datenbereitsteller innerhalb des deutschen DCAT-AP.
Die Abkürzung pg im PREFIX pg: <https://www.dcat-ap.de/def/politicalGeocoding/> steht für “political geocoding” und verweist auf eine geopolitische Abdeckung im Sinne eines administrativen Gebiets der Bundesrepublik Deutschland.
SELECT
Mit SELECT wählen wir wieder die Eigenschaften aus, die aufgelistet werden sollen. Jede Eigenschaft wird wieder in einer Tabellenspalte angezeigt.
Wir wollen mit unserer Abfrage folgende Informationen in folgender Reihenfolge angezeigt bekommen: die URIs, die Titel, die Namen der Datenbereitsteller und das Kürzel des jeweiligen Landes, aus dem der Datensatz stammt.
Daher geben wir in unserem SELECT-Befehl diese vier Properties an: ?uri, ?title, ?contributorid, ?stateKey.
Die genauen Benennungen der Properties (Labels) werden im oben verlinkten DCAT-AP-Handbuch definiert, auf das wir zurückgreifen müssen, um die genauen Labels für jede Property zu finden.
WHERE
Mit dem WHERE-Befehl definieren wir wieder die Bedingungen, die erfüllt werden müssen, damit eine Beobachtung aufgelistet werden kann. Da wir mit den PREFIXes Abkürzungen definiert haben, ist diese Suche “kürzer” als die vorherige. Wir suchen nach dem Titel (?uri dct:title ?title) eines Datensatzes und der ID des Bereitstellers (?uri dcatde:contributorID ?contributorid).
OPTIONAL
Im Unterschied dazu besagt der Befehl OPTIONAL, dass die folgende Bedingung nicht zwingend zu erfüllen ist. OPTIONAL ist ein gutes Werkzeug, das benutzt werden kann, wenn man sich nicht sicher ist, ob die jeweiligen Properties ordentlich codiert sind. In unserem Fall der Schlüssel für ein Bundesland (?uri pg:stateKey ?stateKey). So stellen wir sicher, dass wir trotz des SELECT-Befehls keine leere Liste erhalten.
Mit unserer Abfrage suchen wir also jene Datensätze, die einen Titel, einen URI, einen mitcodierten Datenbereitsteller, und wenn vorhanden, einen Schlüssel für das Bundesland haben. Mit anderen Worten: Wir suchen nach offenen Daten, die von einem deutschen Datenbereitsteller stammen und wollen diese den Bundesländern zuordnen.
Code
Output
Erklärung des Ergebnisses
Wie befürchtet ist die Spalte für das Bundesland(-Kürzel) (stateKey) leer. Das liegt daran, dass stateKey nicht definiert worden ist, wodurch diese Felder leer bleiben. Möglicherweise müssen diese Felder nicht verpflichtend ausgefüllt werden. Dies ist ein klares Beispiel für lückenhaftes Metadatenmanagement. In der Praxis kommt es oft zu Fällen, in denen SPARQL-Abfragen nicht erfolgreich sind, weil die Metadatenbeschreibung unvollständig ist. Mit dem OPTIONAL-Befehl kann man dieses Problem teilweise umgehen.
Darüber hinaus konnten wir durch das fehlende stateKey-Element die offenen Daten nicht den einzelnen Bundesländern zuordnen.
Wir erhalten stattdessen eine Liste, die uns die URI des europäischen Datenportals, den Titel und den Bereitsteller der Daten angibt. Als Bereitsteller lässt sich openDataBrandenburg ermitteln. Wie sich aus dem Titel entnehmen lässt, handelt es sich bei dem ausgegebenen Datensatz um eine digitale topografische Karte im Maßstab 1 : 10.000 von Groß Muckrow, einem Ortsteil der Stadt Friedland in Brandenburg. Dieser Datensatz wird auf verschiedenen Sprachen ausgegeben.
Vielleicht ist Ihnen aufgefallen, dass uns nur 20 von 100.000 Ergebnissen angezeigt werden und wir uns die weiteren Daten nicht ansehen können. Das liegt daran, dass SPARQL keine Paginierungsfunktion, also das Durchblättern von Ergebnissen wie auf einer Weboberfläche, unterstützt. Stattdessen muss die Paginierung manuell durch die Verwendung von Befehlen wie LIMIT und OFFSET in der Abfrage implementiert werden. Um die aktuelle Ausgabe vollständig zu sehen, müsste man diese Befehle zusätzlich einfügen.
Was Sie mitnehmen sollten
Das Vokabular „dcat-ap.de“ bietet spezifische Eigenschaften wie „contributorID“, um Datenbereitsteller eindeutig zu identifizieren.
Die Erweiterung „politicalGeocoding“ ermöglicht die Einbindung geografischer Identifikatoren wie „stateKey“. Diese sind für die Suche aber nur sinnvoll, wenn sie in den Metadaten von Datensätzen enthalten sind.
5.1.4. Zusammenfassung#
In diesem Abschnitt haben wir einen ersten Einblick in die Funktionsweise der Abfragesprache SPAQRL vermittelt, indem wir einen Endpunkt gesetzt und erste Abfragen mit den Befehlen SELECT und WHERE sowie PREFIX und OPTIONAL ausgeführt haben.
Um unsere Abfrage zu verfeinern, benötigen wir weitere Befehle, die im nächsten Abschnitt erklärt werden.
Literatur
Föderale IT-Kooperation. Schnittstellen. 2024. Accessed: 2025-04-08. URL: https://www.govdata.de/sparql-assistent/.