diff --git a/Bachelorarbeit.tex b/Bachelorarbeit.tex
index c5b693a..39f9cca 100644
--- a/Bachelorarbeit.tex
+++ b/Bachelorarbeit.tex
@@ -474,13 +474,13 @@ Unter Berücksichtigung dieser Kriterien fiel die Wahl auf die CEP-Engine C-SPAR
 
 
 \chapter{CEP auf RDF-Datenströmen anhand der C-SPARQL Engine}
-In diesem Kapitel wird die Verarbeitung von RDF-Datenströmen anhand der CEP-Engine \enquote{C-SPARQL} erläutert.
+Nachdem die Wahl der CEP-Engine auf die C-SPARQL-Engine gefallen ist, sollen in diesem Kapitel nun ihre Möglichkeiten zur Verarbeitung von RDF-Datenströmen beleuchtet werden.
 
 
 \section{Ereignisse}
-Ereignisse werden aufgrund der Nutzung von RDF-Datenströmen als Transportmedium nun durch RDF-Tupel beschrieben. Diese tragen neben den typischen Inhalten von Tripeln (Subjekt, Prädikat und Objekt) nun eine vierte Information mit sich: den Zeitstempel zu dem das Ereignis ausgelöst wurde. Da die Tupel nun mit dem Zeitstempel vier Angaben enthalten, werden sie als Quadrupel bezeichnet.
+Ereignisse werden aufgrund der Nutzung von RDF-Datenströmen als Transportmedium nun durch RDF-Tupel beschrieben. Diese tragen neben den typischen Inhalten von Tripeln (Subjekt, Prädikat und Objekt) nun eine vierte Information mit sich: den Zeitstempel, zu dem das Ereignis ausgelöst wurde. Da die Tupel nun mit dem Zeitstempel insgesamt vier Angaben enthalten, werden sie als \emph{Quadrupel} bezeichnet.
 
-Um die Ereignisquadrupel trotz identischer Ereignistypen oder Zeitstempel voneinander unterscheiden zu können, ist es nötig, die Ereignisse mit einer eindeutigen ID zu versehen. Um dies zu erreichen, werden die einzelnen Ereignisse als separate Subjekte in RDF repräsentiert. Dadurch erhalten alle Quadrupel eines Ereignisses eine eindeutige Zuordnung zu ihrem Ereignissubjekt. 
+Um die Ereignisquadrupel trotz identischer Ereignistypen oder Zeitstempel voneinander unterscheiden zu können, ist es nötig, die Ereignisse mit einer eindeutigen ID zu versehen. Um dies zu erreichen, werden die einzelnen Ereignisse als eigene, separate Subjekte in RDF repräsentiert. Dadurch erhalten alle Quadrupel eines Ereignisses eine eindeutige Zuordnung zu ihrem Ereignissubjekt. 
 
 Um dies zu verdeutlichen folgt nun ein kleines Beispiel. Gegeben seien zwei beispielhafte Ereignisse mit Statusdaten über einen PKW. Listing~\ref{lst:sample_abstract_event_data} zeigt diese beiden Ereignisse in abstrakter Notation.
 \begin{lstlisting}[caption={Zwei Statusereignisse eines PKW in abstrakter Notation},label={lst:sample_abstract_event_data}]
@@ -506,29 +506,27 @@ Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jedes
 @prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .
 @prefix event: <http://example.org/carSim/objects/event#> .
 
-(1344829400)	event:324	rdf:type	CarStatusEvent .
+(1344829400)	event:324	rdf:type	carOnt:CarStatusEvent .
 (1344829400)	event:324	carOnt:relatedCar	car:0 .
 (1344829400)	event:324	carOnt:speed	63 .
 
-(1344829405)	event:325	rdf:type	CarStatusEvent .
+(1344829405)	event:325	rdf:type	carOnt:CarStatusEvent .
 (1344829405)	event:325	carOnt:relatedCar	car:0 .
 (1344829405)	event:325	carOnt:speed	75 .
 \end{lstlisting}
-Ereignisdaten, die über RDF-Ereignisdatenströme ausgeliefert werden und zur Verarbeitung einer CEP-Engine zugeführt werden, sehen den in Listing~\ref{lst:sample_abstract_event_data} gezeigten RDF-Quadrupeln von der Struktur her sehr ähnlich.
+Über RDF-Ereignisdatenströme ausgelieferte Ereignisdaten, die zur Verarbeitung einer RDF-fähigen CEP-Engine zugeführt werden, sind von der Struktur her angelehnt an die Beispielereignisse aus Listing~\ref{lst:sample_abstract_event_data} aufgebaut.
 
 
 \section{Sprachkonzepte für CEP-Regeln}
-Da Ereignisse nun in Form von RDF-Quadrupeln verarbeitet werden sollen, ... ähm ... ja.
-Genau.
+Um die Ereignisdatenströme von RDF-Quadrupeln nun in der C-SPARQL-Engine verarbeiten zu können, werden CEP-Regeln benötigt, die im eigentlichen Verarbeitungsprozess verwendet werden, um die Ereignisdaten auszuwerten. Diese Regeln beschreiben Bedingungen, auf die sie matchen, sowie Aktionen, die ausgeführt werden sollen, wenn die Regel matcht. In abstrakter Notation sieht dies wie folgt aus:
+\begin{lstlisting}[label={lst:sample_abstract_cep_rule}, caption={Abstrakte Struktur einer CEP-Regel}]
+CONDITION (Event1 as e1, Event2 as e2)[within last 10min]
+	e1.foo > 500 AND e2.origin != "Mars"
+ACTION
+	create new Event3(foo=(e1.baz+e2.baz/3), bar=e2.origin)
+\end{lstlisting}
 
 
-\todo{Dieser Bereich wird definitiv mit abstrakter Sprache und dann konkretem C-SPARQL CSPARQL-Query demonstriert. - das nötige C-SPARQL wurde zuvor ja als Engine der Wahl begründet.}
-\begin{itemize}
-\item Sliding Windows zur Betrachtung der Ereignisströme
-\item Mustererkennung
-\item Aggregation von Ereignissen
-\end{itemize}
-
 \subsection{CSPARQL als Sprache für CEP-Regeln}
 \todo{Und so weiter \dots}