[TASK] Generic commit
This commit is contained in:
parent
4b3d94f269
commit
0ce14a2fc4
|
|
@ -338,7 +338,7 @@ Listing~\ref{lst:sample_sparql_query} zeigt, dass SPARQL in der groben Grundstru
|
|||
Für das gefundene \texttt{?carModel} wird nun ein Tripel gesucht, welches für \texttt{?carModel} das Prädikat \texttt{carOnt:maximumMotorRPM} nutzt, um die Angabe der maximalen Drehzahl für dieses Automodell zu definieren. Wird hierfür ebenfalls ein Treffer gelandet, so wird der Platzhalter \texttt{?maxMotorRPM} mit dem dazugehörigen Wert gefüllt und kann dann in der \texttt{SELECT}-Klausel selektiert werden. Für jede Tripelkombination, die auf die in der \texttt{WHERE}-Klausel formulierten Beschreibung passt, ergibt sich nun ein Ergebnis, für welches die in der \texttt{SELECT}-Klausel angegebenen Felder zurückgegeben werden --- in diesem Fall also lediglich ein Ergebnis mit dem Wert \enquote{4300}.
|
||||
|
||||
\paragraph{Konstruktion von Daten durch Abfragen}
|
||||
Neben \texttt{SELECT} unterstützt SPARQL auch das Schlüsselwort \texttt{CONSTRUCT}. Dieses ermöglicht die direkte Konstruktion von neuen Tripeln aus vorgegebenen Tripeln mit Platzhaltern, welche mit den Ergebnissen der Abfrage gefüllt werden. Listing~\ref{lst:sample_sparql_construct} zeigt die beispielhafte Erzeugung von Tripeln auf Basis der Daten aus Listing~\ref{lst:sample_rdf_data}, welche über das Prädikat \texttt{carOnt:motorRPMTolerance} Auskunft über die Größe des akzeptablen Drehzahlbereiches der Automodelle geben sollen.
|
||||
Neben \texttt{SELECT} unterstützt SPARQL auch den Befehl \texttt{CONSTRUCT}. Dieses ermöglicht die direkte Konstruktion von neuen Tripeln aus vorgegebenen Tripeln mit Platzhaltern, welche mit den Ergebnissen der Abfrage gefüllt werden. Listing~\ref{lst:sample_sparql_construct} zeigt die beispielhafte Erzeugung von Tripeln auf Basis der Daten aus Listing~\ref{lst:sample_rdf_data}, welche über das Prädikat \texttt{carOnt:motorRPMTolerance} Auskunft über die Größe des akzeptablen Drehzahlbereiches der Automodelle geben sollen.
|
||||
\begin{lstlisting}[caption={Konstruktion von neuen Tripeln auf Basis des Wissens aus Listing~\ref{lst:sample_rdf_data}},label={lst:sample_sparql_construct}]
|
||||
PREFIX carOnt: <http://example.org/carSim/carSimulationOntology#>
|
||||
PREFIX car: <http://example.org/carSim/objects/Car#>
|
||||
|
|
@ -372,10 +372,11 @@ Die Vorteile von Reasoning erkauft man sich durch einen nicht unerheblichen Eins
|
|||
|
||||
\section{Einführung in Complex Event Processing}\label{cpt:cep_intro}
|
||||
\begin{itemize}
|
||||
\item Definition von CEP
|
||||
\item Ereignisse und Hintergrundwissen/Domänenwissen
|
||||
\item Definition von CEP ohne RDF direkt zu involvieren (RDF kommt später)
|
||||
\item Mustererkennung
|
||||
\item Ereignisse
|
||||
\item Integration von Domänenwissen
|
||||
\item Beispielhafter, fiktiver Ereignisstrom mit Hinweis auf Zeitachse
|
||||
\item Kurzer Exkurs in Richtung Mustererkennung
|
||||
\end{itemize}
|
||||
\todo{Nun wollen wir auf Datenströmen im RDF-Format CEP fahren. Was genau bedeutet das eigentlich und wie sieht das in der Theorie aus?}
|
||||
|
||||
|
|
@ -396,67 +397,40 @@ Ein weiterer Kernaspekt von CEP ist die Mustererkennung in Ereignissen. Aus best
|
|||
Insgesamt liegt die Herausforderung von CEP darin, in kürzester Zeit große Datenströme von Ereignissen mit Hintergrundwissen anzureichern, diese zu höherwertigen Ereignissen zu kombinieren und bestimmte Muster zu finden, sowie die Ergebnisse mit möglichst geringer Verzögerung in Echtzeit ausgeben zu können oder Reaktionen einzuleiten.
|
||||
|
||||
|
||||
\subsection{Ereignisse als RDF-Datenstrom}
|
||||
\chapter{CEP auf RDF-Datenströmen}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
|
||||
\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}
|
||||
\section{Ereignisse}
|
||||
|
||||
|
||||
\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.}
|
||||
\section{Sprachkonzepte}
|
||||
|
||||
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}
|
||||
\todo{Dieser Bereich wird definitiv mit abstrakter Sprache und dann konkretem C-SPARQL CSPARQL-Query demonstriert.}
|
||||
|
||||
|
||||
\subsection{Reasoning auf RDF-Datenströmen?}
|
||||
\subsection{Mustererkennung, Sliding Windows, Aggregation von Ereignissen}
|
||||
|
||||
\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.}
|
||||
|
||||
|
||||
\subsection{Auslösen von (Re-)Aktionen (Code und neue Ereignisse)}
|
||||
|
||||
|
||||
|
||||
\section{Einbindung von Domänenwissen}
|
||||
|
||||
|
||||
|
||||
\section{Reasoning auf RDF-Datenströmen}
|
||||
\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.]
|
||||
\item Bei Stefan Lier mal gucken
|
||||
\item Reasoning auf RDFS-Level kann die C-SPARQL-Engine definitiv.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\chapter{Vergleich von RDF-fähigen CEP-Engines}\label{cpt:engine_comparison}
|
||||
\chapter{Vergleich aktueller RDF-fähiger CEP-Engines}\label{cpt:engine_comparison}
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
Es gibt bereits einige Technologien um Ereignisströme zu verarbeiten.
|
||||
|
|
@ -523,44 +497,13 @@ Grobe Eckpunkte zur Orientierung:
|
|||
\todo{Warum jetzt eigentlich C-SPARQL? Weil es in Java fährt, auf Jena basiert, Datenströme im RDF-Format direkt unterstützt, Generatoren zum Einspeisen in die Engine nutzt und somit echt komfortabel in der Handhabung ist. Und trotzdem kommen noch akzeptable Ergebnisse mit minimalem Support für RDFS-Reasoning raus. Dadurch ist es für Einsteiger gut geeignet und bietet dennoch schon solide Features durch CSPARQL.}
|
||||
|
||||
|
||||
\chapter{Konzeption/CEP auf RDF-Datenströmen}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
\todo{Objektklassen und Attribute + deren Zusammenhänge [Für RDFS-Reasoning dann noch ein wenig mehr Details]}
|
||||
|
||||
\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.}
|
||||
|
||||
Um die Anforderungen der Autoverleihgesellschaft aus Kapitel~\ref{cpt:scenario} mit der in Kapitel~\ref{cpt:engine_comparison} ausgewählten CEP-Engine \enquote{C-SPARQL} zu implementieren, muss zunächst die Verarbeitung der Ereignisdaten geplant und vorbereitet werden. Da es zum Formulieren der CSPARQL-Abfragen nötig ist, die Struktur der Ereignisdaten, die Struktur des Domänenwissens und das dazugehörige Vokabular zu kennen, sollen diese Punkte für die Anforderungen des Beispielszenarios festgelegt werden. Im Anschluss daran sollen die CSPARQL-Anfragen für die Erfüllung der Anforderungen des Szenarios formuliert und erläutert werden.
|
||||
|
||||
\section{Ereignisse}
|
||||
|
||||
\section{Sprachkonzepte}
|
||||
|
||||
\todo{Dieser Bereich wird definitiv mit abstrakter Sprache und dann konkretem C-SPARQL CSPARQL-Query demonstriert.}
|
||||
|
||||
\subsection{Mustererkennung, Sliding Windows, Aggregation von Ereignissen}
|
||||
|
||||
|
||||
\subsection{Auslösen von (Re-)Aktionen (Code und neue Ereignisse)}
|
||||
|
||||
|
||||
\section{Einbindung von Domänenwissen}
|
||||
|
||||
|
||||
\section{Reasoning auf RDF-Datenströmen}
|
||||
\begin{itemize}
|
||||
\item Bei Stefan Lier mal gucken
|
||||
\item Reasoning auf RDFS-Level kann die C-SPARQL-Engine definitiv.
|
||||
\end{itemize}
|
||||
|
||||
\chapter{Implementierung/Umsetzung des Beispielszenarios}
|
||||
\chapter{Umsetzung des Beispielszenarios}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
\todo{In diesem Kapitel wird die Engine konkret ausgepackt und mit Java-Code benutzt. Es werden Datenstromgeneratoren gezeigt, Queries registriert und vielleicht etwas Reasoning eingeschaltet und dessen Ergebnisse begutachtet.}
|
||||
|
||||
In diesem Kapitel wird die C-SPARQL-Engine konkret vorgestellt und verwendet um das Beispielszenario aus Kapitel~\ref{cpt:scenario} umzusetzen.
|
||||
In diesem Kapitel wird die C-SPARQL-Engine konkret vorgestellt und verwendet um das Beispielszenario aus Kapitel~\ref{cpt:scenario} umzusetzen. Dafür werden die Anforderungen des Szenarios einzeln betrachtet, die Ereignisdatenströme und der ganze Kram, der da mit dranhängt um dann eine Lösung zu konzipieren und implementieren.
|
||||
|
||||
\begin{itemize}
|
||||
\item RDF-Datenströme
|
||||
|
|
|
|||
|
|
@ -0,0 +1,62 @@
|
|||
|
||||
\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}
|
||||
|
||||
Loading…
Reference in New Issue