[TASK] Generic commit.

This commit is contained in:
Jan Philipp Timme 2016-07-14 21:52:05 +02:00
parent 18e505634f
commit ea25e8d4b9

View File

@ -1,6 +1,6 @@
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Setup des Dokuments
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass[12pt,DIV14,BCOR10mm,a4paper,twoside,parskip=half-,headsepline,headinclude]{scrreprt} % Grundgröße 12pt, zweiseitig
% Packages from template
\usepackage[headsepline,automark]{scrpage2} % Seitenköpfe automatisch
@ -78,9 +78,9 @@
\renewcommand{\topfraction}{1}
\renewcommand{\bottomfraction}{1}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Beginn der Inhalte
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Beginn des Dokuments (Titelseite und der ganze Krempel)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
% Titelseite
@ -144,7 +144,9 @@ Hannover, den \today \hfill Unterschrift
\newpage
%%% Hier kommt inhaltlicher Inhalt! %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Hier geht es richtig los mit dem Text!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Einleitung}
@ -155,13 +157,21 @@ An einem Beispielszenario soll dann der Praxiseinsatz von C-SPARQL erklärt werd
\todo{Den Inhalten der Arbeit angepasste Einleitung}
\section{Motivation}
\todo{Fließtext}
Warum machen wir überhaupt CEP mit RDF und CSPARQL?
Wir haben offene Systeme, die Informationen via RDF bereitstellen.
Warum RDF? Warum nicht irgendein anderes Format? Warum ist RDF im Vergleich zu RDBMS so viel geiler?
\section{Einführung in Complex Event Processing}
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} 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 ermöglicht nun eine weitere Interpretation des Ereignisses; allerdings müssen noch weitere Informationen hinzugezogen werden, 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 hinterlegten Grenzwerten liegt.
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} 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 ermöglicht nun eine weitere Interpretation des Ereignisses; allerdings müssen noch weitere Informationen hinzugezogen werden, 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}.
\begin{lstlisting}[caption={Exemplarischer Ereignisstrom: Motortemperatur eines PKW},label={lst:sample_eventstream}]
@ -178,7 +188,7 @@ Insgesamt liegt die Herausforderung von CEP darin, in kürzester Zeit große Dat
\section{Complex Event Processing auf RDF-Datenströmen}
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 repräsentiert; ü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.
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.
\begin{lstlisting}[caption={Ereignis im RDF-Format},label={lst:sample_rdf_event}]