[TASK] Add more text, add a reference file for the last export.

Bachelorarbeit.tex

@@ -26,7 +26,7 @@
 	frame=single,
 	%framexleftmargin=19pt,
 	inputencoding=utf8,
-	language=awk,
+	%language=awk,
 	%numbers=left,
 	%numbersep=8pt,
 	showspaces=false,
@@ -35,11 +35,11 @@
 	%xleftmargin=19pt,
 	captionpos=b,
 	% Styling
-	%basicstyle=\footnotesize\ttfamily,
-	%commentstyle=\footnotesize,
-	%keywordstyle=\footnotesize\ttfamily,
-	%numberstyle=\footnotesize,
-	%stringstyle=\footnotesize\ttfamily,
+	basicstyle=\footnotesize\ttfamily,
+	commentstyle=\footnotesize,
+	keywordstyle=\footnotesize\ttfamily,
+	numberstyle=\footnotesize,
+	stringstyle=\footnotesize\ttfamily,
 }
 % Hack für Sonderzeichen in Codeblocks
 \lstset{literate=%
@@ -180,15 +180,45 @@ Ein weiterer wichtiger Faktor ist der Zeitraum, in dem Ereignisse auftreten. Um
 [T=3] Temperatursensor: 61°C
 [T=4] Temperatursensor: 84°C
 \end{lstlisting}
-Zunächst sei unter Verwendung von Hintergrundwissen verraten: Der Temperatursensor befindet sich an dem Motor eines PKW und hat in regelmäßigen Abständen diese vier Messwerte gemeldet. Auf den ersten Blick ist ersichtlich, dass die Messwerte einen sehr starken Temperaturanstieg abbilden, jedoch kann über den nächsten Messwert nur spekuliert werden, da die zeitlichen Abstände zwischen den Messereignissen einen großen Unterschied ausmachen können. 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 im Kühlsystem schließen und ein Motorschaden wäre eine mögliche Folge. Die Zeitachse darf somit bei der Ereignisverarbeitung nicht vernachlässigt werden.
+Unter Verwendung von Hintergrundwissen sei nun verraten: Der Temperatursensor befindet sich an dem Motor eines PKW und hat in regelmäßigen Abständen diese vier Messwerte gemeldet. Auf den ersten Blick ist ersichtlich, dass die Messwerte einen sehr starken Temperaturanstieg abbilden, jedoch kann über den nächsten Messwert nur spekuliert werden, da die zeitlichen Abstände zwischen den Messereignissen einen großen Unterschied ausmachen können. 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 im Kühlsystem schließen und ein Motorschaden wäre eine mögliche Folge. Die Zeitachse darf somit bei der Ereignisverarbeitung nicht vernachlässigt werden.
 
-\todo{Kombination von Ereignissen, Ereignismuster}
+Ein weiterer wichtiger Gesichtspunkt ist die Kombination von verschiedenen Ereignissen miteinander. Dies kann genutzt werden, um für ein Ereignis weitere Informationen aus dem Kontext zu erhalten oder um ein Ereignis mit Daten aus anderer Quelle abgleichen zu können. So können beispielsweise die Temperaturmessungen aus dem obigen Beispiel mit Informationen über die Geschwindigkeit des PKW in dem Zeitraum abgeglichen werden oder durch den Vergleich mit anderen Temperatursensoren falsche Messergebnisse durch defekte Sensoren erkannt werden.
+Darauf aufbauend ist die Mustererkennung ist ein weiteres Kernfeature von CEP-Engines und dient dazu, aus bestimmten primitiven Ereignissen in vorgegebener Abfolge einen höheren Sachverhalt abzuleiten. Treten bei einem PKW beispielsweise nacheinander die Ereignisse \enquote{Motor abgeschaltet}, \enquote{Fahrzeug verriegelt} und \enquote{PKW beschleunigt} auf, so ist ein abgestelltes Fahrzeug losgerollt, und man sollte unverzüglich dessen Besitzer darüber informieren.
 
-Die Herausforderung bei CEP liegt also darin große Ströme von Ereignissen unter Zuhilfenahme von Hintergrundwissen zu kombinieren, relevante Ereignisse daraus zu selektieren und unter diesen bestimmte Muster zu erkennen, daraus höherwertige und bedeutungsvolle Ereignisse zu konstruieren und die Ergebnisse möglichst in Echtzeit weiterzugeben.
+Insgesamt liegt die Herausforderung bei CEP also darin große Ströme von Ereignissen unter Zuhilfenahme von Hintergrundwissen zu kombinieren, relevante Ereignisse daraus zu selektieren und unter diesen Muster zu erkennen, daraus höherwertige und bedeutungsvolle Ereignisse zu konstruieren und möglichst in Echtzeit weiterzugeben.
 
 \section{Complex Event Processing auf RDF-Datenströmen}
 
-\todo{Speziell RDF-Datenströme und co}
+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. Hierbei werden die Ereignisdatenströme der Engine entweder direkt als RDF-Datenstrom zugeführt oder falls nötig zuvor in einen RDF-Datenstrom konvertiert. Da RDF-Daten aus vielen (Subjekt, Prädikat, Objekt)-Tripeln bestehen, gehen bei der Umwandlung keine Informationen verloren.
+
+\begin{lstlisting}[caption={Beispielhafte Ereignisse im RDF-Format}]
+http://myexample.org/cars/event#1468064960110	http://myexample.org/cars#carID	http://myexample.org/cars#8
+http://myexample.org/cars/event#1468064960110	http://myexample.org/cars#currentTemperature	"27"^^http://www.w3.org/2001/XMLSchema#integer	
+http://myexample.org/cars/event#1468064960110	http://myexample.org/cars#currentSpeed	"13"^^http://www.w3.org/2001/XMLSchema#integer	
+\end{lstlisting}
+
+Der große Vorteil bei der Arbeit mit SPARQL auf RDF-Datenströmen liegt darin, innerhalb einer einzigen SPARQL-Abfrage 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.
+
+\begin{lstlisting}[caption={Erzeugung von Beschleunigungs-Ereignissen mit SPARQL}]
+REGISTER QUERY ConstructAcceleratingCars AS
+PREFIX f: <http://larkc.eu/csparql/sparql/jena/ext#>
+PREFIX cars: <http://myexample.org/cars#>
+CONSTRUCT {
+	[] cars:carID ?car;
+	   cars:acceleratedBy ?deltaSpeed .
+}
+FROM STREAM <http://myexample.org/cars> [RANGE 5s STEP 1s]
+WHERE {
+	?e1 cars:carID ?car ;
+	    cars:currentSpeed ?speed1 .
+	?e2 cars:carID ?car ;
+	    cars:currentSpeed ?speed2 .
+	BIND (?speed2 - ?speed1 AS ?deltaSpeed)
+	FILTER(f:timestamp(?e1,cars:carID,?car) < f:timestamp(?e2,cars:carID,?car))
+	FILTER(?speed1 < ?speed2)
+}
+\end{lstlisting}
+
 
 \chapter{Gegenüberstellung existierender CEP-Engines}
 
@@ -235,9 +265,7 @@ Diese Engine werde ich nachher genauer vorstellen und benutzen.
 
 \subsection{Bekannte Probleme}
 
-Ein durchaus wichtiger Punkt ist die mangelhafte Umsetzung der Timestamp-Funktion in der Version 0.9.6 der C-SPARQL-Engine.
-Diese führt dazu, dass man bei der Verarbeitung von Daten aus Temperatursensoren eine Entscheidung treffen muss: Entweder ist es möglich die Timestamps der Events auszuwerten; die Temperaturwerte sind dann keine Literale und können nicht in Filter-Operationen verglichen werden. Oder aber die Temperaturwerte sind Literale und dementsprechend in Filter-Operationen vergleichbar; dann fällt aber die Timestamp-Funktion raus und es ist nicht möglich die zeitliche Abfolge der Ereignisse nachzuvollziehen.
-
+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.
 
 \chapter{Die C-SPARQL-Engine im Detail}
 

LAST_EXPORT

@@ -0,0 +1 @@
+a00b3740760cf35e4d5311c8d9b2c16b964abe9f