Help:SPARQL und RDF-Speicher nutzen

Standardmäßig speichert Semantic MediaWiki (SMW) alle Daten in einer relationalen Datenbank (üblicherweise eine MySQL-Datenbank), die auch von MediaWiki verwendet wird. Dadurch wird eine einfache Installation ermöglicht. Allerdings ist einer relationale Datenbank nicht ideal zum Speichern semantischer Daten. Naturgemäß wäre RDF hierfür das Datenbankformat der Wahl. Es handelt sich dabei um ein Datenformat, das Informationen innerhalb von Graphen im Gegensatz zu feststehenden Datentabellen speichert. Es ist glücklicherweise möglich RDF-gestützte Systeme in Verbindung mit einem SQL-gestützten System zu verwenden, um die in SMW gespeicherten Daten zu verwalten sowie abzufragen. Auf dieser Seite werden die entsprechenden Einzelheiten dargestellt.

Vor- und Nachteile eines RDF-Datenspeichers
Die Nutzung eines RDF-Datenspeichers auf einem speziellen Wiki ist von verschiedenen Faktoren abhängig. Das beinhaltet vornehmlich Faktoren bezüglich des RDF-Datenbanksystems, das genutzt werden soll. Es ist glücklicherweise ohne größeren Aufwand möglich zwischen einem SQL- und RDF-gestützten Datenspeicher hin- und herzuwechseln, so dass eine Entscheidung nach einer Erprobungsphase neu überdacht werden kann.

Vorteile
Folgende Vorteile ergeben sich aus der Nutzung einer RDF-Datenbank: RDF-Datenbanken sind darauf abgestimmt Abfragen in der Abfragesprache SPARQL zu beantworten. Semantische Abfragen mit SMW können in dieser Sprache wesentlich besser dargestellt werden als in der SQL-Abfragesprache relationaler Datenbanken. Insofern sind derartige SMW-Abfragen der Hauptgrund eine RDF-Datenbank zu verwenden, während sie für relationale Datenbanken einen eher exotischen Anwendungsfall darstellen. Ferner sind viele wichtige, bei relationalen Datenbanken Anwendung findende, Optimierungsmethoden im Zusammenhang mit SMW-Abfragen zwecklos oder gar zweckwidrig. Es kann daher davon ausgegangen werden, dass RDF-Datenbanken eine wesentlich bessere Abfrageleistung erwarten lassen. RDF-Datenbanken die den SPARQL-Standard unterstützen, ermöglichen die Verwendung zusätzlicher Anwendungen, um SPARQL-Abfragen ausführen zu können, ohne dabei auf die Benutzeroberfläche von SMW angewiesen zu sein. Dies ermöglicht eine effizientere Nutzung der im Wiki gespeicherten Daten durch andere Anwendungen. Zudem unterstützen einige SPARQL-fähige Datenbanken ganz oder teilweise die OWL-Ontologiesprache und stellen entsprechende Bedienoberflächen zum Abfragen der gespeicherten Daten, bspw. mit Hilfe des OWL-Linkprotokolls bereit. Semantische Webapplikationen nutzen auch eine Anzahl allgemeiner Programmbibliotheken wie z. B. librdf oder die OWL-API, die dazu verwendet werden können sie auf einer niederschwelligen Ebene mit anderen Anwendungen zu kombinieren. Semantische Websprachen wie bspw. RDF-Schema (RDFS) oder OWL stellen zusätzliche Ausdrucksfunktionen zum Erstellung von Abfragen bereit. Sie ermöglichen z. B. die Bezeichnung abgeleiteter Klassen oder die Bezeichnung weiterer Attributcharakteristiken wie bspw. Transitivität. Einige SPARQL-fähige Datenbanken können diese Funktionen zum Beantworten der Abfragen bewerten, wie bspw. der ontologiegestützer Datenzugriff (OBDA) und die Methode zur Erstellung „virtueller Ansichten“ oder Daten über semantische Datengebilde. Es ist möglich zusätzliche Daten in einer RDF-Datenbank zu speichern, die durch SMW aktualisiert wird. Dadurch kann der RDF-Speicher als Plattform zur Datenintegration und Ontologieweiterverwendung dienen. Ein von MediaWiki unabhängiges Datenbankbackend ermöglicht eine einfache Verteilung der Rechenaufgaben über mehrere Server. Insbesondere bei komplexen Abfragen können Leistungseinschränkungen beim Normalbetrieb eines Wikis verhindert werden. Dies ist sogar dann der Fall, wenn die Abfragen unerwartet hohen oder gar fatalen Leistungsbedarf an die Rechenleistung stellen, sprich den Server, auf dem sich die RDF-Datenbank befindet, zum Absturz bringen.
 * Besser Abfrageleistung
 * Zusätzliche Schnittstellen
 * Schlussfolgerungsfunktionen und ontologiegestützer Datenzugriff
 * Datenintegration und Ontologieweiterverwendung
 * Physische Aufteilung der Rechenleistung

Nachteile
Es ergeben sich allerdings aus der Nutzung einer RDF-Datenbank auch Nachteile: Die Daten werden lediglich in die RDF-Datenbank gespiegelt und nicht aus der SQL-Datenbank entfernt. Daher ergibt sich ein höherer Speicherplatzbedarf. Die Einrichtung eines RDF-Backends zu SMW ist einfach, allerdings bedeutet der Betrieb des zusätzlichen Datenbankmanagementsystems auch einen zusätzlichen Aufwand. Es gibt inzwischen eine gewisse Anzahl leistungsfähiger RDF-Datenbanken, von denen einige frei und guelloffen sind. Indes ist der Einsatz dieser Datenbanksysteme durch SMW immer noch begrenzt, so dass Tests erforderlich wie hilfreich sind, bevor man sich für ein bestimmtes Datenbanksystem bei einer umfangreichen SMW-Anwendung entscheidet.
 * Höhere Speicheranforderungen
 * Zusätzlicher Wartungsaufwand
 * Offene Fragen bezüglich Leistung und Stabilität

Entscheidung bezüglich eines RDF-Datenspeichers
Grundsätzlich unterstützt SWM jede Datenbank, welche die SPARQL-Abfragesprache mitsamt der Erweiterung SPARUL (SPARQL/Update) gemäß Version 1.1 unterstützt. In SWM 1.6.0 müssen Datenspeicher Aktualisierungen und Abfragen akzeptieren, die über keinen bezeichneten Graphen (named graph) verfügen. Es ist allerdings geplant diese Einschränkung in der Zukunft aufzuheben. Es gibt zwei Orte im Internet an denen eine Liste verfügbarer RDF-Speicher gepflegt wird:
 * semanticweb.org
 * w3.org

RDF-Speicher werden häufig als Tripelspeicher bezeichnet, obgleich viele modere RDF-Speicher tatsächlich Quadrupelspeicher sind, die also jedem RDF-Tripel auch einen bezeichneten Graphen zuordnen.

Mit Stand 2012 gibt es mit 4Store und Virtuoso zwei bedeutende freie und quelloffene RDF-Datenbanken. Beide wurde im Zusammenhang mit SMW erfolgreich eingesetzt. Bei der Nutzung von Virtuoso sind kleinere Änderungen bei SMW notwendig, um die Einschränkung, keine bezeichneten Graphen verwenden zu können, zu vermeiden.

Konfiguration von SMW für RDF-Datenspeicher
SPARQL-Abrufe, gleich ob Abfragen oder Aktualisierungen werden über Webdienste ausgeführt. Dies bedeutet, dass die Abrufe an und die Daten von URLs gesandt werden, die den Ort des betreffenden Dienstes angeben. Dieser Standort wird von der RDF-Datenbank sowie ihrer Konfiguration bestimmt. Beispielsweise kann auf einem lokalen Rechner die typische Position des SPARQL-Abfragedienstes („Endpunkt“) von 4Store http://localhost:8080/sparql/ sein.

Um SMW für die Nutzung einer SPARQL-fähigen Datenbank zu konfigurieren, muss man den Standort des SPARQL-Abfragedienstes und den des SPARQL-Aktualisierungsdienstes kennen. Optional kann man auch einen Dienst nutzen, der für Aktualisierungen das SPARQL-über-HTTP-Protokoll (en) unterstützt. Sofern eingesetzt, wird SMW diese Methode bei einfachen Aktualisierungsanfragen gegenüber SPARUL vorziehen. Im Fall von Problemen kann sie allerdings entfallen. Die Orte dieser Webdienste müssen in der Datei LocalSettings.php wie im folgenden Beispiel angegeben werden:

Der erste Parameter legt die SPARQL-Speicherimplementierung zum Speicher der Daten fest (anstellen der Standardeinstellung SMWSQLStore2). In den übrigen Zeilen werden die Orte der relevanten Dienste festgelegt. Die letzten beiden Einstellungen können auch entfallen. In vielen Fällen sollte die Einstellung $smwgSparqlDataEndpoint nicht festgelegt werden, da die meisten Speicherimplementierungen ihr eigenes spezifisches Protokoll zur Speicherung verwenden.

Standardmäßig wird SWM den generischen SPARQL-Konnektor verwenden, der auf Basis der aktuellen SPARQL-Spezifikation entwickelt wurde. Einige RDF-Datenbanken könnten daher noch nicht vollständig kompatibel sein oder benötigen noch speziellen Anpassungen, um diese fortgeschrittenen und noch nicht standardkonformen Funktionen verwenden zu können. Daher sollten im Zusammenhang mit einigen Datenspeichern Sondereinstellung vorgenommen werden.

4Store
4Store wird seit SMW 1.6.0 unterstützt. Sofern man 4Store als RDF-Datenbank nutzt müssen folgende Einstellungen vorgenommen werden:

Zusätzlich zu den standardmäßig vorzunehmenden Einstellungen, muss 4Store ausdrücklich mit $smwgSparqlDatabase = 'SMWSparqlDatabase4Store'; gesetzt werden.

Die gesonderte Konfiguration stellt sicher, dass der bei 4Store verfügbare Parameter „soft limit“ genutzt werden kann, um die zur Abfragebeantwortung notwendige Systemleistung beschränken zu können. Zudem ist das unter 4Store verfügbare Protokoll für den Datenendpunkt systemspezifisch, sofern dieser konfiguriert wird. Es ist empfohlen ihn zu konfigurieren, da er beim Schreiben effizienter ist.

Virtuoso
Virtuoso wird seit SMW 1.7.1 unterstützt. Sofern man Virtuoso als RDF-Datenbank nutzt müssen folgende Einstellungen vorgenommen werden:

Zusätzlich zu den standardmäßig vorzunehmenden Einstellungen, muss Virtuoso ausdrücklich mit $smwgSparqlDatabase = 'SMWSparqlDatabaseVirtuoso'; gesetzt werden.

Die eindeutigen URLs sind dabei von der lokalen Konfiguration abhängig. Die URI des Standardgraphen kann dabei frei gewählt werden, muss allerdings festgelegt werden. Folgende Einschränkungen im Zusammenhang mit diversen Versionen von Virtuoso sind aktuell bekannt:
 * Numerische Datentypen werden nicht richtig unterstützt. Es werden daher nicht alle zu erwartenden Abfrageergebnisse ausgegeben, sofern die Abfragebedingungen Zahlenwerte enthalten. Dies beeinflusst zudem Attribute des Datentyps Datum da sie bei Abfragen numerische Werte nutzen.
 * Aus unbekannten Gründen scheitern Abfragen mit Schreibvorgängen. Vermutlich hängt dies mit ungewöhnlichen oder komplexen Eingabedaten zusammen, wie bspw. die Verwendung von Sonderzeichen innerhalb von Zeichenketten. Speichervorgänge zu derartigen Daten auf einer Seite werden daher zu Fehlern führen.
 * XSD-Datumsangaben (XML Schema Definition) mit negativen Jahresangaben können nicht verarbeitet werden, selbst wenn sie nur aus vier Ziffern bestehen. Das Speichern derartiger Daten führt zu Fehlern.

Andere RDF-Datenspeicher
Datenspeicher, die dem offiziellen SPARQL- und SPARUL-Standard entsprechen, sollten ohne Probleme funktionsfähig sein. Die RDF-Datenbank Sesame soll beispielsweise mit dem Standardkonnektor einwandfrei funktionieren. In vielen Fällen sollte die Einstellung $smwgSparqlDataEndpoint = ''; gesetzt werden, da die Unterstützung für dieses optionale Endpunktprotokoll bislang nicht hinreichend getestet wurde.

Um Sonderfunktionen des jeweils genutzten Datenspeichers nutzen zu können, kann einfach eine angepasste Implementierung erstellt werden, indem man eine Unterklasse für $smwgSparqlDatabase erstellt. Beispiele hierfür finden sich in den Dateien zur Implementierung von 4Store (SMW_SparqlDatabase4Store.php) und Virtuoso (SMW_SparqlDatabaseVirtuoso.php). Sie befinden sich unter „[Pfad zur Semantic-MediaWiki-Installation]/includes/sparql/“. Entsprechende Vorschläge oder bereits erstelle Implementierungen können über den Bugtracker (siehe den Link Report a bug in der Seitenleiste auf der linken Seite) oder per E-Mail gemacht, bzw. weitergegeben werden.

Daten in die neue Datenbank übertragen
Unmittelbar nach Änderung der Konfiguration befinden sich noch keine Daten in der RDF-Datenbank. Um die bereits im Wiki hinterlegten Daten in diese Datenbank zu übertragen, muss eine komplette Datenaktualisierung, wie auf der Hilfeseite Datenreparatur beschrieben, durchgeführt werden. Dabei kann jede der beschriebenen Methoden zur Datenaktualisierung genutzt werden. Alle SMW-Abfragen (eingebettete Abfragen wie auch semantisches Browsen) werden nach der Umstellung ausschließlich über die RDF-Datenbank durchgeführt. Sofern also die Daten nicht richtig aktualisiert wurden, werden die Abfrageergebnisse nicht stimmen.

Bekannte Einschränkungen
Es gibt ein paar Funktionen, die noch nicht unterstützt werden, sofern man eine RDF-Datenbank für die Abfragen nutzt:
 * Konzeptabfragen: Konzepte werden aktuell noch nicht unterstützt.
 * Kategorie- und Attributhierarchien: Hierarchien werden nur berücksichtigt, sofern die genutzte RDF-Datenbank die Funktionen „rdfs:subClassOf“ und „rdfs:subPropertyOf“ von RDF-Schema (RDFS) unterstützt. Anderenfalls werden Informationen zu Hierarchien nicht zu zusätzlichen Abfrageergebnissen führen.