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

[TASK] Cleanup no more needed file.

Browse Source
This commit is contained in:
Jan Philipp Timme 2016-10-12 16:52:04 +02:00
parent 42f14f2bd9
commit 174687ef57
1 changed files with 0 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
temporary_storage.txt
View File

@ -1,62 +0,0 @@
\subsection{Ereignisse als RDF-Datenstrom}
\todo{Begründung, warum Ereignisse hier über Event-Subjekte definiert werden sollten}
Um Ereignisse aus verschiedenen Quellen gemeinsam zu verarbeiten ist RDF als kleinster gemeinsamer Nenner für Informationen das Mittel der Wahl. Hierbei werden die Ereignisse gegebenenfalls vorher in das RDF-Format transformiert und als Datenstrom aus RDF-Quadrupeln der CEP-Engine zugeführt. Die Quadrupel führen neben den ereignisrelevanten Informationen zusätzlich noch den Zeitstempel mit, zu dem das Ereignis ausgelöst wurde.
Als Abfragesprache für die RDF-Datenströme kommt eine erweiterte Form von SPARQL --- im Folgenden \enquote{CSPARQL} --- zum Einsatz, welche Erweiterungen und Funktionen speziell für die Verarbeitung von RDF-Datenströmen mitbringt. CSPARQL kann die eingehenden RDF-Datenströme in sogenannten \enquote{Sliding Windows} erfassen und ermöglicht die Berücksichtigung der Zeitstempel der Ereignisse innerhalb der Abfrage durch die Bereitstellung von zusätzlichen Sprachkonstrukten und Funktionen. Dabei besteht weiterhin die Möglichkeit, lokal in Form von RDF-Daten vorhandenes Domänenwissen in die Abfrage einzubeziehen und mit den Ereignisdaten zu verknüpfen.
In Listing~\ref{lst:sample_rdf_event} aufgeführt sind RDF-Tripel, die ein beispielhaftes Zustands-Ereignis aus einem PKW zeigen. Das Prefix \texttt{http://example.org/cars} wurde zu Zwecken der Übersichtlichkeit durch \texttt{cars:} abgekürzt.
\begin{lstlisting}[caption={Ereignis im RDF-Format},label={lst:sample_rdf_event}]
http://example.org/cars/event#1468064960110 http://example.org/cars#carID http://example.org/cars#8
http://example.org/cars/event#1468064960110 http://example.org/cars#currentTemperature "27"^^http://www.w3.org/2001/XMLSchema#integer
http://example.org/cars/event#1468064960110 http://example.org/cars#currentSpeed "13"^^http://www.w3.org/2001/XMLSchema#integer
\end{lstlisting}
\subsection{SPARQL-Erweiterung zur Verarbeitung von RDF-Datenströmen}
\todo{Grobes Konzept: CSPARQL als erweiterte Form von SPARQL für die Verwendung mit RDF-Datenströmen.}
Der große Vorteil bei der Ereignisverarbeitung mit SPARQL auf RDF-Daten liegt in der Mächtigkeit dieser Abfragesprache: Innerhalb einer einzigen SPARQL-Abfrage ist es möglich Ereignisse aus verschiedenen Quellen miteinander zu kombinieren, direkt mit Hintergrundwissen zu kombinieren, nach eigenen Kriterien zu filtern, einfache Berechnungen anzustellen und aus dem Ergebnis neue Ereignisse beliebiger Struktur zu erzeugen.
Somit muss der Anwender neben SPARQL keine weiteren Sprachen lernen oder sich anderweitig mit der Implementierung der Engine auseinandersetzen, sondern kann sich komplett auf die zu analysierenden Ereignisse konzentrieren. Listing~\ref{lst:sample_combine_events_sparql} zeigt einen SPARQL-Query, in dem zwei aufeinanderfolgende Ereignisse mit Angaben zur Momentangeschwindigkeit eines PKWs zu einem komplexeren Beschleunigungsereignis kombiniert werden.
\begin{lstlisting}[caption={Generation von neuen Ereignissen aus existierenden Ereignissen mit SPARQL},label={lst:sample_combine_events_sparql}]
REGISTER QUERY ConstructAcceleratingCars AS
PREFIX f: <http://larkc.eu/csparql/sparql/jena/ext#>
PREFIX cars: <http://example.org/cars#>
CONSTRUCT {
[] cars:carID ?car;
cars:acceleratedBy ?deltaSpeed .
}
FROM STREAM <http://example.org/cars> [RANGE 5s STEP 1s]
WHERE {
?e1 cars:carID ?car ;
cars:currentSpeed ?speed1 .
?e2 cars:carID ?car ;
cars:currentSpeed ?speed2 .
BIND (?speed2 - ?speed1 AS ?deltaSpeed)
FILTER(f:timestamp(?e1,cars:carID,?car) < f:timestamp(?e2,cars:carID,?car))
FILTER(?speed1 < ?speed2)
}
\end{lstlisting}
\todo{Streaming-Erweiterungen aus dem Listing ein wenig hervorheben, damit verbundene Schlüsselwörter hervorheben und Begriffe klären (Sliding Window, Timestamps, Range und Step, \dots}
\subsection{Reasoning auf RDF-Datenströmen?}
\todo{Reasoning kann man als automatisches Enrichment der Eingabetripel im Rahmen der Möglichkeiten der verwendeten TBox (Ontologien) betrachten}
\todo{FALLS ich Reasoning rechtzeitig unterbringe, werde ich hier die Grundlagen von Reasoning auf Datenströmen und die zusätzlichen Herausforderungen dabei hier erklären. Der Prozess des Reasoning wurde auf statischen Daten bereits in der Einführung in das semantische Web erklärt.}
\begin{itemize}
\item Immer noch ein Forschungsgebiet
\item sehr hoher Datendurchsatz (viele kleine Ereignisse in geringem Zeitraum)
\item Ereignisinformationen ändern sich sehr häufig, sind nie sehr lange gültig und nicht immer relevant zur einer Abfrage
\item Aber: Ergebnisse sollen möglichst schnell vorliegen
\item $\Longrightarrow$ große Menge Rechenaufwand
\item Einer der möglichen Ansätze: Reasoner errechnet für die Ereignisse Tripel mit begrenzter Lebensdauer (z.B. in C-SPARQL-Engine verwendet) [Der Part wandert eventuell in das Konzept-Kapitel in dem ich erkläre, auf welche Weise ich das RDFS-Reasoning der Engine nutzen möchte.]
\end{itemize}