Diese Arbeit beschäftigt sich mit \enquote{Complex Event Processing} (CEP), also der Verarbeitung komplexer Ereignisse auf Ereignisdatenströmen mit Integration von Hintergrundwissen, und der praktischen Nutzung der CEP-Engine C-SPARQL.
Nach einem kurzen Einstieg in das Thema CEP soll der Leser einen Einblick in die Features von aktuellen CEP-Engines erhalten und am Beispiel der Engine C-SPARQL\footnote{Mehr Informationen zu C-SPARQL und Download unter \url{http://streamreasoning.org/resources/c-sparql}} die Verarbeitung von Ereignisströmen im RDF-Format in Kombination mit Hintergrundwissen im Detail kennenlernen.
An einem Beispielszenario soll dann der Praxiseinsatz von C-SPARQL erklärt werden, in dem einige der vorgestellten Funktionen Anwendung finden. Im Abschluss wird ein kurzer Ausblick auf die technischen Möglichkeiten des \enquote{Reasoning} gegeben --- eine Technik, die es erlaubt auf den vorhandenen und eingehenden Daten logische Operationen und Schlussfolgerungen durchzuführen um daraus neues Wissen abzuleiten.
Es gibt kaum andere Formate, die ebenso universell und offen sind.
Wie sieht RDF im Vergleich zu RDBMS aus?
Bei RDBMS gibt es je nach Anwendung unterschiedlichste Datenbankschemen, die Struktur und verwendete Datentypen von Tupeln in Relationen vorschreiben.
Für die Verknüpfung von Daten aus verschiedenen RDBMS miteinander wird es hier sehr schwierig, da beispielsweise klassisches SQL keine Unterstützung für Queries über mehrere Datenbankserver unterstützt.
Im folgenden Abschnitt wird ein kurzer Einstieg in das Konzept von Complex Event Processing (CEP) gegeben. Eine detailreiche Erläuterung von CEP und die beispielhafte Anwendung der CEP-Engine \enquote{Esper} wird in \cite{hsh:cep} beschrieben.
Wie der Begriff \enquote{Complex Event Processing} schon andeutet, geht es bei CEP um die Verarbeitung von komplexen Ereignissen --- konkret: Die Erkennung und Erfassung von komplexen Ereignissen aus Datenströmen von primitiven Ereignissen. Von Messereignissen aus mit Sensoren ausgestatteten Geräten über Transaktionen im Handel bis hin zu Benutzerinteraktionen auf Webseiten entstehen täglich unzählig viele Ereignisse, die abhängig von ihrem Kontext für einen bestimmten Zeitraum ein Stück der echten Welt korrekt abbilden.
Die Informationen dieser Ereignisse stellen nur einen momentanen Zustand dar; sie sind für sich alleine betrachtet Kontext- und somit Bedeutungslos. Betrachtet man beispielsweise ein Ereignis \enquote{Die gemessene Temperatur beträgt 42°C.}, so ist zunächst nicht einmal zu erkennen, was es mit dieser Temperatur auf sich hat. Hier kommt das \emph{Hintergrundwissen} (auch Domänenwissen) ins Spiel, welches uns in diesem Fall verraten kann, dass die Quelle dieses Ereignisses ein Sensor in einem PKW ist und am Motorblock befestigt ist. Dieses Wissen beinhaltet auch weitere Angaben zum konkreten Modell des PKW --- unter anderem auch dessen zulässige Höchstgeschwindigkeit und die für den Motor zugelassenen Temperaturbereiche. Dies ermöglicht eine weiterführende Interpretation des Ereignisses; allerdings werden noch weitere Informationen benötigt, um ein eindeutiges Bild zu erhalten. Kombiniert man dieses Ereignis mit den Meldungen des im PKW installierten Geschwindigkeitssensors, so kann man herausfinden, ob die gemessene Motortemperatur für den aktuellen Betriebszustand des PKW innerhalb der im Hintergrundwissen für die über das spezifische PKW-Modell hinterlegten Grenzwerten liegt.
Ein weiterer, wichtiger Faktor ist der Zeitraum in dem gewisse Ereignisse auftreten. Um dies näher zu erläutern, betrachten wir den gegebenen Ereignisstrom aus Listing~\ref{lst:sample_eventstream}.
Auf den ersten Blick ist ersichtlich, dass die Messwerte einen sehr starken Temperaturanstieg abbilden, jedoch fehlt eine Angabe darüber, wie viel Zeit zwischen diesen Ereignissen vergangen ist. Dadurch ist die Interpretation dieser Ereignisse nicht mehr eindeutig möglich: Liegen zwischen den Messereignissen beispielsweise etwa 30-60 Minuten, so könnte es sich um einen normalen Betrieb bei hoher Geschwindigkeit handeln. Sollten jedoch nur wenige Minuten zwischen den Messereignissen vergangen sein, so lassen die Messwerte auf einen Defekt schließen und ein Motorschaden wäre eine mögliche Folge. Die Zeitachse darf somit bei der Ereignisverarbeitung nicht vernachlässigt werden.
Ein weiterer Kernaspekt von CEP ist die Mustererkennung in Ereignissen. Aus bestimmten primitiven Ereignissen, die in einer bestimmten Abfolge auftreten, soll ein konkreter Sachverhalt abgeleitet werden. Treten bei einem PKW beispielsweise in kurzer Zeit nacheinander die Ereignisse \enquote{Motor abgeschaltet}, \enquote{Fahrzeug verriegelt} und \enquote{PKW beschleunigt} auf, so ist daraus zu schließen, dass ein gerade abgestelltes Fahrzeug wahrscheinlich unbeabsichtigt losgerollt ist und es sollte unverzüglich eine Reaktion darauf gestartet werden.
Insgesamt liegt die Herausforderung von CEP darin, in kürzester Zeit große Datenströme von Ereignissen mit Hintergrundwissen anzureichern, diese zu höherwertigen Ereignissen zu kombinieren und bestimmte Muster zu finden, sowie die Ergebnisse mit möglichst geringer Verzögerung in Echtzeit ausgeben zu können oder Reaktionen einzuleiten.
Um Ereignisse aus verschiedenartigen Quellen gemeinsam zu verarbeiten ist das RDF-Format das Mittel der Wahl. Das Ressource Description Framework (RDF) wird bereits im semantischen Web zur Erfassung und Verknüpfung von Wissen verwendet und kann leicht über die Sprache SPARQL (\enquote{SPARQL Protocol And RDF Query Language}) abgefragt werden. RDF-Daten bestehen aus einer Menge von Tripeln, welche sich aus den drei Komponenten Subjekt, Prädikat und Objekt zusammensetzen. Ein Subjekt wird durch eine eindeutige URI identifiziert; über Prädikate aus Ontologien können diesem Subjekt über Spezifikation im Objekt-Teil des Tripels bestimmte Attribute mit Werten zugesprochen werden oder Verknüpfungen mit anderen Subjekten hergestellt werden. Aufgrund der Flexibilität dieser Struktur ist es möglich, nahezu jede Art von Informationen auf Tripel abzubilden.
Zur Verarbeitung von Ereignissen im RDF-Format werden die Ereignisdatenströme der verarbeitenden Engine entweder direkt als RDF-Datenstrom zugeführt oder gegebenenfalls vor der Zuführung in einen RDF-Datenstrom konvertiert. In Listing~\ref{lst:sample_rdf_event} aufgeführt sind RDF-Tripel, die ein beispielhaftes Zustands-Ereignis aus einem PKW zeigen.
Der große Vorteil bei der Ereignisverarbeitung mit SPARQL auf RDF-Daten liegt in der Mächtigkeit dieser Abfragesprache: Innerhalb einer einzigen SPARQL-Abfrage ist es möglich Ereignisse aus verschiedenen Quellen miteinander zu kombinieren, direkt mit Hintergrundwissen zu kombinieren, nach eigenen Kriterien zu filtern, einfache Berechnungen anzustellen und aus dem Ergebnis neue Ereignisse beliebiger Struktur zu erzeugen.
Somit muss der Anwender neben SPARQL keine weitere Programmiersprache lernen oder sich anderweitig mit der Implementierung der Engine auseinandersetzen, sondern kann sich komplett auf die zu analysierenden Ereignisse konzentrieren. Listing~\ref{lst:sample_combine_events_sparql} zeigt einen SPARQL-Query, in dem zwei aufeinanderfolgende Ereignisse mit Angaben zur Momentangeschwindigkeit eines Autos zu einem komplexeren Beschleunigungsereignis kombiniert werden.
Öhm \dots wie sieht dieser Part eigentlich aus? Habe ich wirklich Anforderungen? Immerhin wird es irgendwo Grenzen geben, was für Anforderungen ich stellen kann.
Die Timestamp-Funktion der C-SPARQL-Engine (Version 0.9.6) gibt für Tripel die Literale enthalten keinen Timestamp zurück. Dadurch ist es nicht direkt möglich, solche Tripel zeitlich einzuordnen. Es ist allerdings möglich, dieses Problem durch Erweiterung oder Umstrukturierung der Ereignistripel zu umgehen.
