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

[TASK] Generic commit.

This commit is contained in:
Jan Philipp Timme 2016-09-29 11:42:01 +02:00
parent 510472b03a
commit 0e8a538667
1 changed files with 14 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
Bachelorarbeit.tex
View File

@ -630,8 +630,8 @@ Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jede E
Wie in Listing~\ref{lst:sample_event_rdf_quads} zu sehen ist, wurde die ID der Ereignisinstanzen zur Generierung der Subjekt-URI verwendet, die in den Quadrupeln verwendet werden, um die Ereignisse zu beschreiben. Aus dem Ereignistyp wurde eine Aussage, die die Subjekt-URI via \texttt{rdf:type} mit einer RDFS-Objektklasse verknüpft, die diesen Ereignistypen repräsentieren soll. Alle weiteren Attribute der Ereignisinstanzen wurden über eigens hierfür definierte RDFS-Prädikate dem Ereignissubjekt zugeordnet. Die Angabe des PKW, auf den sich die Ereignisinstanzen beziehen, wurde durch eine direkte Verknüpfung der Ereignissubjekte mit dem zugehörigen PKW-Subjekt modelliert. Die PKW-Subjekte sind hierbei im Domänenwissen hinterlegt; dazu später mehr\todo{Kapitelreferenz!}. Wie in Listing~\ref{lst:sample_event_rdf_quads} zu sehen ist, wurde die ID der Ereignisinstanzen zur Generierung der Subjekt-URI verwendet, die in den Quadrupeln verwendet werden, um die Ereignisse zu beschreiben. Aus dem Ereignistyp wurde eine Aussage, die die Subjekt-URI via \texttt{rdf:type} mit einer RDFS-Objektklasse verknüpft, die diesen Ereignistypen repräsentieren soll. Alle weiteren Attribute der Ereignisinstanzen wurden über eigens hierfür definierte RDFS-Prädikate dem Ereignissubjekt zugeordnet. Die Angabe des PKW, auf den sich die Ereignisinstanzen beziehen, wurde durch eine direkte Verknüpfung der Ereignissubjekte mit dem zugehörigen PKW-Subjekt modelliert. Die PKW-Subjekte sind hierbei im Domänenwissen hinterlegt; dazu später mehr\todo{Kapitelreferenz!}.
\section{C-SPARQL als Sprache für CEP-Regeln} \section{C-SPARQL als Sprache für CEP-Regeln}
Um die Ereignisdatenströme mit RDF-Quadrupeln nun in der C-SPARQL-Engine verarbeiten zu können, werden im Verarbeitungsprozess in C-SPARQL-Queries formulierte CEP-Regeln benötigt. Die Konstrukte und Fähigkeiten von C-SPARQL sollen in diesem Abschnitt erläutert werden. Um die Ereignisdatenströme mit RDF-Quadrupeln nun in der C-SPARQL-Engine verarbeiten zu können, werden im Verarbeitungsprozess in C-SPARQL-Queries formulierte CEP-Regeln benötigt. Die Konstrukte und Fähigkeiten von C-SPARQL sollen in diesem Abschnitt erläutert werden; weiterführend ist eine detailliertere Erläuterung von C-SPARQL mit Beispielabfragen unter \cite{barbieri:csparql} nachzulesen.
Da C-SPARQL die Abfragesprache SPARQL lediglich erweitert, kann ein einfacher SPARQL-\texttt{SELECT}-Query als Ausgangspunkt verwendet werden: Da C-SPARQL die Abfragesprache SPARQL lediglich erweitert, kann ein einfacher SPARQL-\texttt{SELECT}-Query als Ausgangspunkt verwendet werden:
\begin{lstlisting} \begin{lstlisting}
SELECT ... SELECT ...
WHERE { WHERE {
@ -640,12 +640,22 @@ WHERE {
\end{lstlisting} \end{lstlisting}
\paragraph{Sliding Windows} \paragraph{Sliding Windows}
Um mit der Verarbeitung von Ereignisdatenströmen beginnen zu können, müssen die für die Verarbeitung benötigten RDF-Datenströme in der CEP-Regel angegeben werden. Das Konstrukt \texttt{FROM STREAM <\emph{streamUri}> [RANGE \emph{window}]} wird zwischen den Klauseln \texttt{SELECT} und \texttt{WHERE} angegeben und definiert neben der URI des zu konsumierenden RDF-Datenstroms auch das Sliding Window, in dem dieser betrachtet werden soll\cite{barbieri:csparql}. Die Angabe des Sliding Windows ist hier zwingend erforderlich, da die kontinuierlich einströmenden Ereignisdaten zur Verarbeitung auf eine endliche Datenmenge reduziert werden müssen. Weiterhin ist die Spezifikation des Sliding Window sinnvoll, da je nach Anforderungen der CEP-Regel Ereignisse aus bestimmten Zeiträumen für die Verarbeitung interessant sind --- je nach Zweck der CEP-Regel können diese Zeiträume sich stark unterscheiden. Um mit der Verarbeitung von Ereignisdatenströmen beginnen zu können, müssen die für die Verarbeitung benötigten RDF-Datenströme in der CEP-Regel angegeben werden. Das Konstrukt \texttt{FROM STREAM <\emph{streamUri}> [\emph{window}]} wird zwischen den Klauseln \texttt{SELECT} und \texttt{WHERE} angegeben und definiert neben der in \texttt{streamUri} zu hinterlegenden URI des zu konsumierenden RDF-Datenstroms auch das an Stelle von \texttt{window} zu definierende Sliding Window, in dem dieser betrachtet werden soll\cite{barbieri:csparql}. Die Angabe des Sliding Windows ist hier zwingend erforderlich, da die kontinuierlich einströmenden Ereignisdaten zur Verarbeitung auf eine endliche Datenmenge reduziert werden müssen. Weiterhin ist die Spezifikation des Sliding Window sinnvoll, da je nach Anforderungen der CEP-Regel Ereignisse aus bestimmten Zeiträumen für die Verarbeitung interessant sind --- je nach Zweck der CEP-Regel können diese Zeiträume sich stark unterscheiden.
Um ein Sliding Window zu definieren, wird die folgende Grammatik (entnommen aus \cite{barbieri:csparql}) ab Einstiegspunkt \texttt{window} verwendet:
\begin{lstlisting}[mathescape=true]
window $\rightarrow$ LogicalWindow | PhysicalWindow
LogicalWindow $\rightarrow$ Number TimeUnit WindowOverlap
TimeUnit $\rightarrow$ 'MSEC' | 'SEC' | 'MIN' | 'HOUR' | 'DAY'
WindowOverlap $\rightarrow$ 'STEP' Number TimeUnit | 'TUMBLING'
PhysicalWindow $\rightarrow$ 'TRIPLES' Number
\end{lstlisting}
\begin{lstlisting} \begin{lstlisting}
[RANGE 10 MIN STEP 30 SEC] [RANGE 10 MIN STEP 30 SEC]
[RANGE 10 MIN TUMBLING] [RANGE 10 MIN TUMBLING]
[RANGE 150 TUPLES] [RANGE TRIPLES 150]
\end{lstlisting} \end{lstlisting}