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

[TASK] Generic commit.

This commit is contained in:
Jan Philipp Timme 2016-09-03 16:10:25 +02:00
parent c990872089
commit bd7ec5176d
1 changed files with 11 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
Bachelorarbeit.tex
View File

@ -454,7 +454,7 @@ WHERE {
\end{itemize}
\chapter{Vergleich von CEP-Engines für RDF-Datenströme}
\chapter{Vergleich von CEP-Engines für RDF-Datenströme}\label{cpt:engine_comparison}
\todo{Zusammenfassungsüberleitung über das Kapitel}
Es gibt bereits einige Technologien um Ereignisströme zu verarbeiten.
@ -527,6 +527,15 @@ Grobe Eckpunkte zur Orientierung:
In diesem Kapitel werden abstrakte Condition-Action-Regeln für das Beispielszenario formuliert und dann mit konkreten CSPARQL-Queries für die \enquote{C-SPARQL}-Engine umgesetzt. Die Ergebnisse dieser Queries kommen im nächsten Kapitel, da sie näher an der Implementierung dran sind. Grundlegende Idee: Query mit ggf. nötigem Beiwerk registrieren und dann die Ergebnisse präsentieren.
Um das Beispielszenario aus Kapitel~\ref{cpt:scenario} mit der in Kapitel~\ref{cpt:engine_comparison} ausgewählten CEP-Engine \enquote{C-SPARQL} nun zu implementieren, muss die Verarbeitung der Ereignisdaten zunächst geplant werden. Hierfür ausschlaggebend sind Struktur und Inhalte der Ereignisdaten, auf denen der Verarbeitungsprozess aufbaut. In diesem Kapitel werden diese Fragen der Reihe nach behandelt und darauf aufbauend Abfragen konzipiert, die dann im CSPARQL-Dialekt der \enquote{C-SPARQL}-Engine formuliert werden müssen.
\section{Struktur der Ereignisdaten}
\todo{Die beiden Ereignisdatenströme + wie die Ereignisse strukturiert sind, die darüber durchrauschen}
\section{Verwendetes Vokabular}
@ -535,17 +544,12 @@ In diesem Kapitel werden abstrakte Condition-Action-Regeln für das Beispielszen
\todo{FALLS es soweit kommt wird hier auch speziell hervorgehoben, mit welchen Konstrukten (Klassenhierarchien und Merkmale) das RDFS-Reasoning der Engine die Abfragen an einigen Stellen flexibler als gehabt ermöglicht.}
\section{Struktur der Ereignisdaten}
\todo{Die beiden Ereignisdatenströme + wie die Ereignisse strukturiert sind, die darüber durchrauschen}
\section{Inhalte des Domänenwissens}
\todo{Welche Angaben sind im Domänenwissen enthalten und wie sollen Sie die Verarbeitung der Ereignisse unterstützen?}
\section{Formulierung von Abfragen}
\section{Formulierung von CSPARQL-Abfragen}
\todo{Immer weiter treiben nach dem Schema Anforderung,abstrakte Condition-Action-Regel, konkrete CSPARQL-Regel}