[TASK] Generic commit.

Bachelorarbeit.tex

@@ -1519,32 +1519,21 @@ Weiterhin erwähnenswert ist die Besonderheit, dass die Engine keine Abfragen mi
 
 Zuletzt ist die Registrierung von Abfragen als Ereignisdatenstrom durch den Umweg über einen \texttt{RdfStreamFormatter} ein Punkt, der in Zukunft durch eine Verbesserung der Implementierung der Engine abgeschafft werden könnte.
 
-\paragraph{Aufwand}
-Obwohl es vergleichsweise einfach ist, die Engine zu initialisieren und sowohl Datenströme als auch Abfragen an ihr zu registrieren, ergeben sich bei der Formulierung der C-SPARQL-Queries zur Umsetzung der Anforderungen immer wieder kleinere Flüchtigkeitsfehler. Sofern der Query selbst syntaktisch korrekt ist, fallen diese Fehler nur dann auf, wenn die erwarteten Ergebnisse der Abfrage nicht eintreten. Eine Abhilfe an dieser Stelle kann die Nutzung von definierten Testdatenströmen bieten, die speziell für eine Abfrage zugeschnittene Ereignisdaten schicken, mit denen dann ein Test der Abfrage auf ihre korrekte Funktionsweise möglich ist. Für die Verarbeitung von Ereignisdatenströmen in großen Stil sollte an dieser Stelle ein größerer Aufwand für die Tests der Abfragen eingeplant werden. 
+\paragraph{Korrektheit der Ergebnisse}
+Sofern ein Query selbst syntaktisch korrekt ist, kann er dennoch logische Fehler enthalten, die zu fehlerhaften (oder gar keinen!) Ergebnissen führen. Diese Fehler können nur dann erkannt werden, wenn die Korrektheit der Ergebnisse einer Abfrage zuverlässig geprüft werden kann. Eine Abhilfe kann hier die Nutzung von zuvor definierten Testdatenströmen bieten, die speziell für eine Abfrage zugeschnittene Ereignisdaten schicken, die in dieser Abfrage ein fest definiertes Ergebnis auslösen. Auf diese Weise ist es möglich, die Korrektheit einer Abfrage zu garantieren; allerdings bringt diese Methode einen stark erhöhten Aufwand mit sich. Für die Verarbeitung von Ereignisdatenströmen in großem Stil empfiehlt sich der erhöhte Aufwand für Tests jedoch sehr, da gerade bei mehrstufigen Verarbeitungsprozessen fehlerhafte Zwischenergebnisse nur schwer entdeckt werden können.
 
 
 \chapter{Fazit}\label{cpt:conclusion}
+In Betrachtung der Ergebnisse, die durch die Implementierung des Szenarios mit der C-SPARQL-Engine erzielt wurden, bietet die C-SPARQL-Engine viel Potential, um die Verarbeitung von RDF-Ereignisdatenströmen praktisch umzusetzen. Gerade der stark erleichterte Zugriff auf lokal hinterlegtes Domänenwissen ist im Vergleich zu der traditionellen CEP-Engine Esper ein großer Pluspunkt. Dem ist natürlich der vergleichsweise stark erhöhte Umfang der C-SPARQL-Queries, der durch die strukturelle Natur der RDF-Daten bedingt ist, entgegen zu setzen.
 
-\begin{itemize}
-\item Bewertung der Ergebnisse im Abgleich mit den Anforderungen und dem Aufwand?
-\item Ist es für die Anforderungen (und mehr) praxistauglich?
-\item Oder gibt es zur Zeit bessere Alternativen?
-\end{itemize}
-
-Die Engine wurde in Version 0.9.6 verwendet, da in 0.9.7 einige Bugs enthalten sind, die dazu führen, dass sie nur eingeschränkt benutzbar ist.
-Weiterhin gibt es einige False Positives des Tokenizers für die C-SPARQL-Sprache, die unter anderem dazu führen, dass Bezeichner, die das Wort \enquote{Stream} enthalten, fälschlicherweise für das Schlüsselwort \texttt{STREAM} gehalten werden.
+Aufgrund der Erfahrungen, die bei der Erstellung dieser Arbeit mit der C-SPARQL-Engine gemacht wurden, ist die Engine mit leichten Einschränkungen für den Einsatz in der Praxis tauglich.
 
+Die Verwendung der Engine und die Formulierung von Queries in C-SPARQL ist zu Beginn leicht zu erlernen, jedoch stößt man bei der Formulierung von C-SPARQL-Queries häufig auf Situationen, in denen die einem bereits bekannten Sprachkonstrukte auf den aktuellen Kontext nicht passen. Häufig muss dann für die Formulierung von Queries auf Dokumentationen von C-SPARQL und SPARQL zurückgegriffen werden.
 
 \section{Ausblick}
+Sollte die Engine in Zukunft weiterentwickelt werden, so ist zu erwarten, dass sie sich für den Einsatz in kleinen und mittelgroßen Projekten gut eignet, um Prototypen zu entwickeln. 
 
-\todo{Eventuell mit Fazit zusammenführen, wenn es nicht zu groß wird.}
 
-\begin{itemize}
-\item Kann man mit der Engine in Zukunft noch mehr schaffen?
-\item Wie steht es um Reasoning auf RDF-Ereignisdatenströmen? Geht das? Wenn ja, nur RDFS oder auch OWL? \todo{Ist der Unterschied zwischen den Beiden fürs erste sehr wichtig oder führt das zu weit?}
-\end{itemize}
-
-Vielleicht geht das mit dem Reasoning später ja noch besser --- aktueller Stand ist noch limitiert, aber es wird fleißig daran geforscht \dots
 
 \begin{comment}
 \chapter*{Dummy-Kapitel für Tests und Notizen}