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

[TASK] Generic commit.

Browse Source
This commit is contained in:
Jan Philipp Timme 2016-09-29 11:00:59 +02:00
parent 7f69b83e27
commit 61017753ef
2 changed files with 2 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

0
Bachelorarbeit.synctex.gz(busy) Normal file
View File

5
Bachelorarbeit.tex
View File

@ -613,7 +613,7 @@ CarStatusEvent(ID=324, timestamp=1344829400, relatedCarID=0, speed=63)
CarStatusEvent(ID=325, timestamp=1344829405, relatedCarID=0, speed=75)
\end{lstlisting}
Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jede Ereignisinstanz quasi ein eigenes Objekt, welches alle für sich relevanten Daten entweder direkt oder als Zeiger auf andere Objekte enthalten kann. Um diese über RDF-Datenströme zu transportieren, müssen diese Ereignisse mit RDF-Quadrupeln beschrieben werden. Listing~\ref{lst:sample_event_rdf_quads} zeigt die Beschreibung der Ereignisse aus Listing~\ref{lst:sample_abstract_event_data} mit RDF-Quadrupeln.
Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jede Ereignisinstanz quasi ein eigenes Objekt, welches alle für sich relevanten Daten entweder direkt oder als Zeiger auf andere Objekte enthalten kann. Um diese über RDF-Datenströme zu transportieren, müssen diese Ereignisinstanzen mit RDF-Quadrupeln beschrieben werden, wie Listing~\ref{lst:sample_event_rdf_quads} zeigt.
\begin{lstlisting}[caption={RDF-Quadrupel mit Zeitstempeln beschreiben zwei Ereignisse eines PKW},label={lst:sample_event_rdf_quads}]
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@ -628,8 +628,7 @@ Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jede E
(1344829405) event:325 carOnt:relatedCar car:0 .
(1344829405) event:325 carOnt:speed 75 .
\end{lstlisting}
Ü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.
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.
\section{Sprachkonzepte für C-SPARQL}
Um die Ereignisdatenströme von RDF-Quadrupeln nun in der C-SPARQL-Engine verarbeiten zu können, werden im Verarbeitungsprozess CEP-Regeln benötigt, um die Ereignisdaten auszuwerten. Im Fall der C-SPARQL-Engine sind CEP-Regeln als C-SPARQL-Queries zu formulieren. Anhand einer abstrakten CEP-Regelsprache soll dieses Kapitel veranschaulichen, wie die einzelnen Aspekte eines C-SPARQL-Queries zur Verarbeitung von Ereignisdaten verwendet werden können.