JPT
/
bachelorthesis
0
0
Fork 0
Code Issues Pull Requests Activity

[TASK] Generic commit.

This commit is contained in:
Jan Philipp Timme 2016-10-12 11:45:17 +02:00
parent 4017e1c06f
commit 6ec153f70b
1 changed files with 8 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
Bachelorarbeit.tex
View File

@ -1504,28 +1504,23 @@ Tiefgehende Details über die Implementierung von Reasoning in der C-SPARQL-Engi
\section{Ergebnis}
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.
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 meisten Anforderungen des Szenarios mit der C-SPARQL-Engine erfolgreich umgesetzt werden. Somit ist es möglich, eintretenden Verschleiß an geliehenen Fahrzeugen direkt dem aktuellen Fahrer des Fahrzeugs zuzuordnen und auf auftretendem Wartungsbedarf zeitnah zu reagieren. Auch die Erkennung von PKW, die ohne angezogene Handbremse abgestellt wurden ist machbar.
Lediglich mit der Abfrage aus Listing~\ref{lst:scenario_tire_wear} zur Erkennung von niedrigem Reifendruck gab es Probleme. Trotz mehrfacher Anpassungsversuche und dem Umstieg vom Datentyp \texttt{xsd:double} auf den Datentypen \texttt{xsd:integer} zur Repräsentation von Reifendruckangaben führte diese Abfrage leider nicht zu Ergebnissen. Selbst unter künstlichen Bedingungen, in denen die gemeldeten Reifendruckdaten immer unter den im Domänenwissen vorgehaltenen Grenzwerten lagen, führten nicht zum Erfolg. Es wird vermutet, dass es mit den logischen Operatoren \texttt{&&} und \texttt{||} innerhalb von \texttt{FILTER()}-Anweisungen noch unbekannte Probleme geben könnte.
\paragraph{Technische Schwierigkeiten}
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.
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\footnote{Unter \url{https://github.com/streamreasoning/CSPARQL-engine/issues} sind die aktuell bekannten Probleme der Software einsehbar.}. 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.
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 einer Exception aus Apache Jena mit der Nachricht \enquote{SELECT * not legal with GROUP BY} 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.
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.
\begin{itemize}
\item (Konnten die gestellten Anforderungen erfüllt werden?)
\item Was konnte erreicht werden?
\item Was konnte nicht erreicht werden?
\item Gab es Schwierigkeiten? [Guter Zeitpunkt, um hier f:timestamp() vs Tripel mit Literals zu erwähnen]
\item Wie hoch war der Aufwand?
\item Wie steht es um die Qualität der Ergebnisse?
\item Eventuell ein Blick auf die Performance?
\end{itemize}
\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.
\chapter{Fazit}\label{cpt:conclusion}