[TASK] Gliederung neu angefangen

Bachelorarbeit.tex

@@ -51,6 +51,9 @@
     {°}{{${^\circ}$}}1
 }
 
+% Befehl für TODO-Markierungen
+\newcommand{\todo}{\textbf{TODO \dots}}
+
 % Festlegung Kopf- und Fußzeile     
 \defpagestyle{meinstil}{%
 	{\headmark \hfill}
@@ -80,7 +83,7 @@
 \includegraphics[width=0.2\textwidth]{res/Wortmarke_WI_schwarz.pdf}
 { ~ \sffamily
 	\vfill
-	{\Huge\bfseries Tolle Arbeit über C-SPAQRL}
+	{\Huge\bfseries Verarbeitung von RDF-Ereignisdatenströmen mit C-SPARQL unter Verwendung von Hintergrundwissen}
 	\bigskip
 
 	{\Large Jan Philipp Timme
@@ -105,10 +108,10 @@
 	& Abteilung Informatik, Fakultät IV \\
 	& Hochschule Hannover \\
 	& juergen.dunkel@hs-hannover.de \\[5ex]
-{\bfseries\sffamily Zweitprüfer:} &Prof. Dr. Vorname Name \\
+{\bfseries\sffamily Zweitprüfer:} &Prof. Dr. --- --- \\
 	& Abteilung Informatik, Fakultät IV \\
 	& Hochschule Hannover \\
-	& email@Adresse
+	& ---@---.--
 \end{tabular}
 
 \vfill
@@ -138,16 +141,50 @@ Hannover, den \today \hfill Unterschrift
 
 %%% Hier kommt inhaltlicher Inhalt! %%%
 
-\chapter{Motivation}
+\part{Die eigentliche Bachelorarbeit}
 
-Dank dem sogenannten \enquote{Internet der Dinge} und der ständig wachsenden Zahl an Geräten, die an Netzwerke oder direkt an das Internet angeschlossen sind, stehen uns eine Vielzahl von Messdaten zur Verfügung. Aus diesen wollen wir für unsere Zwecke spezifische Informationen entnehmen, daraus Schlussfolgerungen ziehen und gegebenenfalls darauf zu reagieren.
+\chapter{Einleitung}
 
-Diese Messdaten können als Datenströme von aufeinander folgende Ereignissen bezogen werden, wobei jedes Ereignis neben den inhaltlichen Daten mit einem Zeitstempel und einer eindeutigen ID versehen ist.
-Der Zeitstempel ermöglicht die zeitliche Korrelation mit weiteren Ereignissen in einem vorgegebenen Zeitrahmen oder die Verknüpfung mit bereits bekannten zeitlichen Gegebenheiten (beispielsweise den Gezeiten, dem Sonnenaufgang oder dem Beginn der Frühschicht in einem Betrieb).
-Die ID stellt sicher, dass jedes Ereignis eindeutig behandelt werden kann und somit beispielsweise nicht irrtümlich mit sich selbst korreliert wird.
+\todo
 
-Ein einfaches Ereignis kann beispielsweise so aussehen:
-\begin{lstlisting}[caption={Beispiel eines Ereignis in JSON}]
+Diese Arbeit beschäftigt sich mit der Verarbeitung von komplexen Ereignissen (CEP) auf RDF-Datenströmen mit C-SPARQL.
+
+\section{Einführung in Complex Event Processing}
+
+Was ist CEP und warum sollte man es verwenden wollen?
+
+Wir verarbeiten Ereignisströme und versuchen aus dem großen Rauschen bestimmte Ereignismuster zu erkennen.
+Und wir wollen kurz-, mittel- oder langfristig bestimmte Werte beobachten und sicherstellen, dass sie innerhalb eines spezifizierten Wertebereichs bleiben.
+Es ist eine tolle Herangehensweise, um aus großen Datenströmen wesentliche Informationen zu extrahieren - noch bevor ein Mensch diese Daten zu Gesicht bekommt.
+\todo
+
+\section{Ereignisquellen}
+
+Ereignisse treten überall auf, wenn man sich darauf einlässt.
+
+Welche Ereignisse kann man sich denn so vorstellen?
+Diese hier:
+\begin{itemize}
+\item Ein Online-Shop meldet eine ausgelöste Bestellung
+\item Ein soziales Netzwerk meldet die Interaktion eines Benutzers
+\item Die Wetterstation meldet ihre aktuellen Messwerte
+\item Windkraftanlagen melden ihre Drehgeschwindigkeit
+\item Ein Auto meldet Fehlzündungen im zweiten Zylinder
+\item Fabrikmaschinen melden Fehler im Betrieb
+\item Rauchmelder melden ihre Auslösung
+\item \dots und vieles mehr
+\end{itemize}
+
+\section{Ereignisse als Informationsträger}
+
+Alles, was irgendwo passiert liefert Informationen über den Zustand unserer Umgebung.
+Jede aktuell gemeldete Information ist ein Ereignis. Eine gerade gemessene Temperatur, eine Fehlermeldung einer Werkzeugmaschine oder das Auslösen eines Rauchmelders sind Ereignisse, die einen aktuellen Zustand unserer Welt repräsentieren.
+
+Für unsere Zwecke können wir das nutzen.
+Ereignisse haben einen Zeitstempel [und eine ID]. Der Zeitstempel ist wichtig, die ID auch etwas.
+
+Ein Ereignis kann beispielsweise so strukturiert sein:
+\begin{lstlisting}[caption={Beispielhaftes Ereignis dargestellt in JSON}]
 {
 	"ID": "17352",
 	"Zeitstempel": "Mo 4. Apr 12:38:19 CEST 2016",
@@ -158,38 +195,106 @@ Ein einfaches Ereignis kann beispielsweise so aussehen:
 }
 \end{lstlisting}
 
-Diese Ereignisse für sich alleine betrachtet enthalten ohne Kontext keine wertvollen Erkenntnisse, sie stellen lediglich einen eingetretenen Zustand dar. Es kann jedoch nicht direkt erkannt werden ob Handlungsbedarf besteht, das Ereignis von großer Bedeutung oder komplett belanglos ist.
+\section{Ereignisströme als Datenquelle}
 
-Um nun den passenden Kontext herzustellen, muss dieses Ereignis also mit weiteren Daten verknüpft werden. Hierfür müssen folgende Fragen beantwortet werden:
+Ja, Ereignisse treten auch in Rudeln. Wenn mehrere Ereignisse aneinandergereiht werden, kann man von einem Ereignisstrom sprechen.
+Anbieter von Daten können anstatt aktueller Messwerte als einzelnes Ereignis natürlich gleich Ereignisströme liefern. Das ist technisch sicherlich auch ganz praktisch, weil Verzicht auf Polling usw.
 
-\begin{enumerate}
-\item Wo befindet sich Sensor 23?\\
-Sensor 23 befindet sich in einem Schadstofflager, in dem neben Altöl auch andere, leichtentzündliche Stoffe gelagert werden.
+\chapter{Anforderungen/Rolle an/von CEP-Engines}
 
-\item Was hat der Sensor zuvor gemessen?\\
-Der Sensor hat zuvor schon Temperaturen in diesem Bereich gemessen, vor 2 Stunden begann der leichte Anstieg bei ca. 30°C.
+Dieser Bereich wird hoffentlich etwas kürzer ausfallen - es geht hier vielleicht eher um die Rolle einer CEP-Engine als die Anforderungen.
 
-\item Was ist über die Umgebung bekannt, in der sich Sensor 23 befindet?\\
-Einige der Stoffe, die dort lagern, haben einen Flammpunkt von ca. 65°C.
+Es wäre ja schon wichtig, dass man Hintergrundwissen integriert.
+Sonst werden die Abfragen so spezifisch und das ist doch doof.
 
-\end{enumerate}
+\section{Kombination von Ereignissen}
 
-\chapter{Stuff}
+\todo
 
-Was noch so kommen muss:
-\begin{itemize}
-\item Grobe Einführung in Richtung CEP Begrifflichkeiten
-\item Benötigte Features für eine CEP-Sprache allgemein (Syntax Buch)\\
-Verknüpfung von Ereignissen, Reihenfolge von Ereignissen, \dots
+\section{Sliding Windows}
 
-\item Vorstellung der Engine + Features: C-SPARQL
-\item Optional: Vergleich mit Alternativen - Featuresets?
-\item Anwendungsszenario mit dem ganzen Tam-Tam\\
-Volle Breitseite umsetzen und zeigen!
-\item Bewertung der Ergebnisse
-\item Optional: RDF-Reasoning angucken und klären, ob geht oder nicht
-\item Ausblick in Zukunft
-\end{itemize}
+\todo
+
+\section{Integration von Hintergrundwissen}
+
+Ereignisse kommen ohne Kontext, daher ist es nötig, sie in einen Kontext zu bringen, um etwas mit dem Ereignis anfangen zu können.
+Um nun den passenden Kontext herzustellen, muss dieses Ereignis also mit weiteren Daten verknüpft werden.
+Das können andere Ereignisse oder Daten sein, die uns schon bekannt sind - Hintergrundwissen.
+
+\section{Performance}
+
+Auch, wenn einige tausend Ereignisse über einen Datenstrom in der Minute eintreffen muss die Software dennoch sehr zeitnah (im Idealfall sofort) Ergebnisse liefern.
+
+(Das hier wird später ein Grund sein, weshalb Reasoning nur sehr begrenzt auf Datenströmen stattfinden kann oder aber sehr teuer ist.)
+
+\chapter{Gegenüberstellung existierender CEP-Engines}
+
+Es gibt bereits einige Technologien um Ereignisströme zu verarbeiten.
+Im Folgenden stelle ich nun ein paar bekannte Systeme kurz vor.
+
+\section{Etalis/EP-SPARQL?}
+
+\todo
+
+\section{CQELS?}
+
+\todo
+
+\section{Esper}
+
+Ein Ansatz mit einer eigenen Abfragesprache.
+Hintergrundwissen etwas fummelig, aber theoretisch möglich. Nur halt nicht in der selben Abfragesprache.
+
+\section{C-SPARQL}
+
+Verarbeitet Ströme im RDF-Format. Kann Hintergrundwissen im RDF-Format einbeziehen. Wurde in Java implementiert...
+Es gibt einen W3C-Standard für die Sprache C-SPARQL.
+Auf das Ding gehe ich gleich näher ein. :-)
+
+\chapter{Die C-SPARQL-Engine im Detail}
+
+... und zwar hier.
+
+\todo
+
+\section{Abfrage von bestimmten Ereignistypen}
+
+\todo
+
+\section{Keine Ahnung, aber ganz viel}
+
+\todo
+
+\chapter{Verarbeitung von RDF-Datenströmen mit C-SPARQL}
+
+\section{RDF-Datenströme}
+
+Spannender ist es, wenn man dann ein Haufen RDF-Tripel reingedrückt bekommt.
+Die sehen anders aus, sind aber auch toll.
+Schemenhaft könnten die ja so aussehen:
+\todo
+
+Wir können uns diese Datenströme angucken und beispielsweise auf bestimmte Dinge achten.
+Aber irgendwie ist das nicht so toll, weil unsere Abfragen recht spezifisch sein müssen.
+Wäre es nicht toll, wenn wir bestimmte Dinge bereits vorher irgendwie da integrieren könnten?
+
+\section{Beispielszenario}
+
+\todo
+
+Ich hab noch keine richtig tolle Idee, aber irgendetwas wird es schon werden.
+
+\section{Umsetzung mit C-SPARQL}
+
+\todo
+
+%%% To be removed %%%
+
+\part{Temporärer Anhang - To be removed}
+
+Raum für Notizen
+
+\chapter{Generelle Ideen für Anwendungsszenarien}
 
 Ideen für CEP mit C-SPARQL und Hintergrundwissen
 
@@ -206,6 +311,7 @@ Generell sollen Muster in primitiven Events erkannt und zu komplexen Events zusa
 \item 
 \end{itemize}
 
+% Kurzer Test
 \cite{robbins:gawk}[Siehe ab S.95]
 
 % Referenz auf Bibtex mit Kommentar