Mehr Gliederung

Bachelorarbeit.tex

@@ -52,7 +52,7 @@
 }
 
 % Befehl für TODO-Markierungen
-\newcommand{\todo}{\textbf{TODO \dots}}
+\newcommand{\todo}{\emph{Dieser Bereich ist in Bearbeitung.}}
 
 % Festlegung Kopf- und Fußzeile     
 \defpagestyle{meinstil}{%
@@ -83,7 +83,7 @@
 \includegraphics[width=0.2\textwidth]{res/Wortmarke_WI_schwarz.pdf}
 { ~ \sffamily
 	\vfill
-	{\Huge\bfseries Verarbeitung von RDF-Ereignisdatenströmen mit C-SPARQL unter Verwendung von Hintergrundwissen}
+	{\Huge\bfseries Verarbeitung von Datenströmen im RDF-Format in Kombination mit Hintergrundwissen in der C-SPARQL-Engine}
 	\bigskip
 
 	{\Large Jan Philipp Timme
@@ -151,15 +151,18 @@ Diese Arbeit beschäftigt sich mit der Verarbeitung von komplexen Ereignissen (C
 
 \section{Einführung in Complex Event Processing}
 
+\todo
+
 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}
 
+\todo
+
 Ereignisse treten überall auf, wenn man sich darauf einlässt.
 
 Welche Ereignisse kann man sich denn so vorstellen?
@@ -177,6 +180,8 @@ Diese hier:
 
 \section{Ereignisse als Informationsträger}
 
+\todo
+
 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.
 
@@ -197,40 +202,31 @@ Ein Ereignis kann beispielsweise so strukturiert sein:
 
 \section{Ereignisströme als Datenquelle}
 
+\todo
+
 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.
 
-\chapter{Anforderungen/Rolle an/von CEP-Engines}
 
-Dieser Bereich wird hoffentlich etwas kürzer ausfallen - es geht hier vielleicht eher um die Rolle einer CEP-Engine als die Anforderungen.
+\chapter{Gegenüberstellung existierender CEP-Engines}
-
-Es wäre ja schon wichtig, dass man Hintergrundwissen integriert.
-Sonst werden die Abfragen so spezifisch und das ist doch doof.
-
-\section{Kombination von Ereignissen}
 
 \todo
 
-\section{Sliding Windows}
+Es gibt bereits einige Technologien um Ereignisströme zu verarbeiten.
+Im Folgenden stelle ich nun ein paar bekannte Systeme kurz vor.
 
-\todo
+Wichtig wären gegebenenfalls diese Kriterien:
-
-\section{Integration von Hintergrundwissen}
 
+\paragraph{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}
+\paragraph{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?}
 
@@ -242,21 +238,26 @@ Im Folgenden stelle ich nun ein paar bekannte Systeme kurz vor.
 
 \section{Esper}
 
+\todo
+
 Ein Ansatz mit einer eigenen Abfragesprache.
 Hintergrundwissen etwas fummelig, aber theoretisch möglich. Nur halt nicht in der selben Abfragesprache.
 
 \section{C-SPARQL}
 
+\todo
+
 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
 
+So, hier kommt dann das, was man so zu C-SPARQL erzählen kann.
+Dieser Bereich bekommt noch genug Sections für die Features von C-SPARQL
+
 \section{Abfrage von bestimmten Ereignistypen}
 
 \todo
@@ -265,14 +266,19 @@ Auf das Ding gehe ich gleich näher ein. :-)
 
 \todo
 
-\chapter{Verarbeitung von RDF-Datenströmen mit C-SPARQL}
+\chapter{Die C-SPARQL-Engine im Einsatz}
+
+\todo
+
+Hier wird jetzt mal wirklich C-SPARQL verwendet.
 
 \section{RDF-Datenströme}
 
+\todo
+
 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.
@@ -282,12 +288,36 @@ Wäre es nicht toll, wenn wir bestimmte Dinge bereits vorher irgendwie da integr
 
 \todo
 
-Ich hab noch keine richtig tolle Idee, aber irgendetwas wird es schon werden.
+Ich hab noch keine richtig tolle Idee, aber irgendetwas wird es schon werden. Im \enquote{temporären Anhang} sind ein paar Notizen hierzu.
 
 \section{Umsetzung mit C-SPARQL}
 
 \todo
 
+\subsection{Nötiger Code}
+
+\todo
+
+\subsection{Verwendete C-SPARQL-Abfragen}
+
+\todo
+
+\section{Bewertung/Ergebnis}
+
+\todo
+
+\chapter{Fazit}
+
+\todo
+
+Die Engine macht sich sicher irgendwie gut - mal gucken.
+
+\chapter{Ausblick}
+
+\todo
+
+Vielleicht geht das mit dem Reasoning später ja deutlich besser und so.
+
 %%% To be removed %%%
 
 \part{Temporärer Anhang - To be removed}
@@ -308,7 +338,7 @@ Generell sollen Muster in primitiven Events erkannt und zu komplexen Events zusa
 \item Betrugserkennung (erst Passwort ändern, dann große Transaktion)
 \item Steuerung einer Heizungsanlage durch Überwachung von Räumen (Licht an, Fenster auf?)
 \item Client/Server Interaktion zur Erkennung von Einbruchsversuchen
-\item 
+\item \dots
 \end{itemize}
 
 % Kurzer Test