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.
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.
5.1.1. Endpunkt definieren#
Zuerst muss 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, welches wir auf der Webseite https://data.europa.eu/de finden. Dazu verwenden wir einen “Magic”, d. h. einen Befehl, der Teil vom SPARQL-Python-Paket ist, der es uns erlaubt, alle künftigen Abfragen mit dem europäischen Datenportal als unserem Endpunkt zu verknüpfen.
Dieser 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
Hier folgt eine einfache SPARQL-Abfrage, um Ihnen die Systematik von Abfragen zu erklären.
Select-Befehl und Where-Befehl.
Code
Show code cell content
SELECT ?contributorid
WHERE {
?uri <http://dcat-ap.de/def/dcatde/contributorID> ?contributorid .
}
Output
Show code cell outputs
Erklärung des Ergebnisses
Nun haben wir das europäische Datenportal data.europa.eu als Endpunkt festgelegt und können mit der Erstellung von SPARQL-Abfragen beginnen. Allerdings fragen wir nur jene Metadaten ab, welche zu den Datensätzen im Portal gespeichert sind. Siehe hierzu Kapitel … .
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.
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 Ressorucen 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:titel 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 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 Vorerst betrachten wir aber den SELECT-Befehl. Mit SELECT wählen wir die Properties bzw. die Eigenschaften, die aufgelistet werden sollen. Jede Eigenschaft entspricht einer Spalte, die in der Tabelle mit Ergebnissen zu sehen ist.
Wir wollen mit unserer Abfrage folgende Informationen erhalten: 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 Als nächstes haben wir den Kern jeder SPARQL-Abfrage - den WHERE-Befehl. Der WHERE-Befehl definiert die Bedingungen, die erfüllt werden müssen, damit eine Beobachtung aufgelistet werden kann. Das heißt, es werden nur die Beobachtungen aufgelistet, die alle Bedingungen erfüllen.
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. So stellen wir sicher, dass wir trotz des SELECT-Befehls keine leere Liste erhalten.
In jeder Zeile in der WHERE-Funktion müssen drei Elemente zu sehen sein. Diese Struktur ist essentiell für die SPARQL-Sprache - durch die sogenannten “triplets” werden Bezüge zwischen den Eigenschaften erstellt. Jede Zeile bestimmt einen Bezug zwischen zwei Eigenschaften. Die erste Eigenschaft ist somit das Subjekt (S), das zweite Element - der Bezug, der aus einem Prefix und einer zusätzlichen Spezifizierung besteht - heißt Prädikat (P), und das dritte - die zweite Eigenschaft - ist das Objekt (O). P entspricht einem Link, der darauf verweist, wo die zweite Eigentschaft zu finden ist. Die Einordnung der Eigenschaften ist nach dem W3C-Standard, der schon in einem früheren Kapitel erklärt wurde, definiert. In dem DCAT-AP-Handbuch ist dann die genaue Verortung von jeder Eingenschaft zu finden. Durch die Triplets fragen wir genau ab, welche Datensätze wir erfragen wollen, je nach den Bedingungen, die solche Datensätze erfüllen sollen.
Mit unserer Abfrage suchen wir die Datensätze ab, die einen Titel, ein 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
Show code cell content
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX dcatde: <http://dcat-ap.de/def/dcatde/>
PREFIX pg: <https://www.dcat-ap.de/def/politicalGeocoding/>
SELECT ?uri ?title ?contributorid ?stateKey
WHERE {
?uri dct:title ?title .
?uri dcatde:contributorID ?contributorid .
OPTIONAL {?uri pg:stateKey ?stateKey} .
}
Output
Show code cell outputs
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.
5.1.4. Zusammenfassung#
In diesem Abschnitt haben wir einen 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 getätigt haben.
Um unsere Abfrage zu verfeinern, benötigen wir weitere Befehle, die im nächsten Abschnitt vermittelt werden.