[TASK] Generic commit.

Bachelorarbeit.tex

@@ -975,7 +975,7 @@ TODO: ERGEBNIS
 Die technischen Details von Reasoning in der C-SPARQL-Engine werden in Kapitel~\ref{cpt:csparql_reasoning} beleuchtet.
 
 \chapter{Umsetzung des Beispielszenarios}\label{cpt:csparql_in_practice}
-Nachdem die Umsetzung von CEP-Regeln in C-SPARQL im vorherigen Kapitel erläutert wurde, soll nun das in Kapitel~\ref{cpt:scenario} angerissene Beispielszenario der Autoverleihgesellschaft umgesetzt werden. Gegeben hierfür sind zwei Ereignisdatenströme, eine lokale Wissensbasis (ABox) und ein grundlegendes Vokabular (TBox), welches Definitionen für die in der ABox und in den Ereignisdatenströmen verwendeten Objektklassen und Attributen enthält. Mit diesen Resourcen soll die Umsetzung der Anforderungen des Beispielszenarios Schritt für Schritt durchgeführt werden.
+Nachdem die Umsetzung von CEP-Regeln in C-SPARQL im vorherigen Kapitel erläutert wurde, soll nun das in Kapitel~\ref{cpt:scenario} angerissene Beispielszenario der Autoverleihgesellschaft umgesetzt werden. Eine für diesen Zweck entwickelte, einfach gehaltene Software simuliert die Bestandteile des Beispielszenarios und stellt als Ausgangspunkt zur Verarbeitung zwei Ereignisdatenströme bereit. Zusätzlich dazu sind eine lokale Wissensbasis (ABox) und ein grundlegendes Vokabular (TBox) gegeben, wobei die TBox Definitionen für die in der ABox und in den Ereignisdatenströmen verwendeten Objektklassen und Attributen enthält. Mit diesen Resourcen soll die Umsetzung der Anforderungen des Beispielszenarios Schritt für Schritt durchgeführt werden.
 
 Im Folgenden werden zunächst die beiden zu verarbeitenden RDF-Ereignisdatenströme vorgestellt:
 
@@ -1498,15 +1498,24 @@ engine.updateReasoner(
 );
 \end{lstlisting}
 
+Nach dem Aufruf von \texttt{updateReasoner()} reichert die Engine nun die Ergebnisse des betroffenen Queries durch die im Reasoning ermittelten, impliziten Fakten an.
+
 Tiefgehende Details über die Implementierung von Reasoning in der C-SPARQL-Engine können in \cite{barbieri:reasoning} nachgelesen werden. Weiterführend kann über die Umsetzung von Reasoning mit Hilfe von Complex Event Processing in der Masterarbeit von Stefan Lier\cite{hsh:reasoning} gelesen werden.
 
 
-\section{Ergebnis}
+\section{Ergebnis} 
-Die Verwendung der C-SPARQL-Engine gestaltete sich in vielen Teilen leicht, dank dem CSPARQL-ReadyToGoPack konnte ein Blick in beispielhafte Implementationen diverser Szenarien Aufschluss darüber geben, wie die einzelnen Elemente der Engine zusammenspielen können.
+Baut man all die C-SPARQL-Abfragen mit dem nötigen Java-Unterbau zusammen, so erhält man eine flexible Lösung zur Auswertung von RDF-Ereignisdatenströmen. Die Umsetzung der Anforderungen des gegebenen Beispielszenarios bereitete zwar einige Schwierigkeiten, dennoch konnten die Anforderungen des Szenarios mit der C-SPARQL-Engine umgesetzt werden.
 
-\paragraph{Reibungspunkte}
+\paragraph{Technische Schwierigkeiten}
-An einigen Stellen der Implementierung des Beispielszenarios haben sich 
+Da die C-SPARQL-Engine im Rahmen von zur Zeit Forschungsprojekten entwickelt wurde, die zur Zeit scheinbar abgeschlossen sind, ist bisher noch keine aktive Weiterentwicklung der Software in Sicht. Für die Umsetzung des Beispielszenarios im Rahmen dieser Arbeit wurde die C-SPARQL-Engine in der Version 0.9.6 verwendet, da die aktuellste Version (0.9.7) für die Nutzung von Reasoning aufgrund von Ausnahmefehlern innerhalb der Engine nicht geeignet ist. 
 
+Die Implementation des Sprachparsers für C-SPARQL-Queries enthält weiterhin einen Fehler, durch den an einigen Stellen in der Abfrage Bezeichner, die das Wort \enquote{Stream} beinhalten, fälschlicherweise als das Token \texttt{STREAM} erkannt werden, worauf die Abfrage mit einer Exception zurückgewiesen wird. Ob es womöglich weitere dieser False Positives gibt, ist bisher unklar; sollte man jedoch auf eine scheinbar ungerechtfertigte Fehlermeldung des Parsers stoßen, so kann es hilfreich sein, diesen Fehler im Hinterkopf zu behalten.
+
+Ein weiteres Problem besteht darin, dass die Funktion \texttt{f:timestamp()} Anstelle des erwarteten Zeitstempels eines gegebenen Tripels dann ein \texttt{false} zurückgibt, wenn das als Parameter übergebene Tripel einen Literalwert (also eine Zeichenkette, Ganzzahl oder ähnliches) enthält. Dieses Problem konnte jedoch umschifft werden, da die Zeitstempel für Ereignisdaten grundsätzlich über Tripel mit ihrer Typangabe mit \texttt{rdf:type} abgefragt wurden.
+
+Weiterhin erwähnenswert ist die Besonderheit, dass die Engine keine Abfragen mit dem Schlüsselwort \texttt{CONSTRUCT} in Kombination mit der Verwendung von Aggregationen und \texttt{GROUP BY} erlaubt; dies wird mit dem kryptischen Ausnahmefehler \enquote{} quittiert. Abhilfe kann hier die Verwendung von Subqueries innerhalb der \texttt{WHERE}-Klausel schaffen, von dem das Ergebnis dann ohne Probleme innerhalb der \texttt{CONSTRUCT}-Klausel verwendet werden kann. Listing~\ref{lst:scenario_union_maintenance} zeigt diesen Ansatz in der Praxis.
+
+Zuletzt ist die Registrierung von Queries als Ereignisdatenströme durch den Umweg über einen \texttt{RdfStreamFormatter} ein Punkt, der in Zukunft durch eine Verbesserung der Implementierung der Engine abgeschafft werden könnte.
 
 \begin{itemize}
 \item (Konnten die gestellten Anforderungen erfüllt werden?)