Remove old slides, fresh start
This commit is contained in:
parent
d0182f2173
commit
79e8f89ea3
349
MA-KO-Inhalt.tex
349
MA-KO-Inhalt.tex
@ -1,346 +1,9 @@
|
||||
\section{Motivation}
|
||||
\section{}
|
||||
|
||||
\begin{frame}{Motivation}
|
||||
\begin{itemize}
|
||||
\item Immer mehr Geräte sind mit dem Internet verbunden
|
||||
\item Sollen überwacht werden beziehungsweise überwachen selbst etwas
|
||||
\item Bieten kontinuierlich aktuelle Zustands- und Messinformationen
|
||||
\item $\rightarrow$ In Form von RDF-Ereignisdatenströmen abrufbar
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Ereignisdatenströme}
|
||||
\begin{itemize}
|
||||
\item Transportieren Daten von einzelnen Ereignissen
|
||||
\item Jedes Ereignis bildet kleinen Teil der Realität ab
|
||||
\begin{itemize}
|
||||
\item \dots sofern Daten korrekt sind (Messfehler, Übertragungsfehler, \dots)
|
||||
\end{itemize}
|
||||
\item Aber: Sind oft zeitlich begrenzt gültig
|
||||
\item Und: Treten meist hochfrequent auf
|
||||
\item $\rightarrow$ Große Datenmengen in kürzester Zeit
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Verarbeitung der Ereignisdatenströme}
|
||||
\begin{itemize}
|
||||
\item Ein Ereignis für sich trägt kaum Bedeutung
|
||||
\item Betrachtung in Kontext notwendig
|
||||
\item Der Kontext ergibt sich \dots
|
||||
\begin{itemize}
|
||||
\item \dots durch relevante, weitere Ereignisse
|
||||
\item \dots durch Integration von \emph{Domänenwissen}
|
||||
\end{itemize}
|
||||
\item Möglichst schnelle Verarbeitung gefordert
|
||||
\item $\rightarrow$ Complex Event Processing (CEP)
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Was ist Complex Event Processing? (CEP)}
|
||||
\begin{itemize}
|
||||
\item Betrachtung von Ereignissen in \emph{Sliding Windows}
|
||||
\item $\rightarrow$ In-Memory Processing
|
||||
\item Erkennung von Ereignismustern
|
||||
\item Aggregation von Ereignissen
|
||||
\item $\rightarrow$ Erzeugung von komplexen Ereignissen
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Ziel der Arbeit}
|
||||
\begin{itemize}
|
||||
\item Verarbeitung von RDF-Ereignisdatenströmen mit CEP
|
||||
\begin{itemize}
|
||||
\item \dots unter Nutzung der C-SPARQL-Engine
|
||||
\end{itemize}
|
||||
\item Dabei: Integration von Domänenwissen
|
||||
\item Und: In wie weit kann Reasoning\footnote{Dazu später mehr \dots} genutzt werden?
|
||||
\item $\rightarrow$ Anhand eines Beispielszenarios praktisch durchführen
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
|
||||
\section{Exkurs: Grundlagen RDF}
|
||||
|
||||
\begin{frame}{Exkurs: Grundlagen RDF}
|
||||
\begin{itemize}
|
||||
\item Resource Description Framework
|
||||
\item Framework zur Beschreibung und Modellierung von Wissen
|
||||
\item Aussagen sind Tripel
|
||||
\item Bestehen aus Subjekt, Prädikat und Objekt
|
||||
\item Werden als URI repräsentiert
|
||||
\begin{itemize}
|
||||
\item Im Objektteil sind auch Literalwerte erlaubt
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
||||
Es folgt ein Beispiel \dots
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}[fragile]{Beispiel: Zwei RDF-Tripel in Turtle-Notation}
|
||||
Fakten über ein beispielhaftes Subjekt in RDF:
|
||||
\begin{lstlisting}
|
||||
@prefix car: <http://example.org/carSim/objects/Car#> .
|
||||
@prefix carModel: <http://example.org/carSim/objects/CarModel#> .
|
||||
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .
|
||||
|
||||
car:23 carOnt:isCarModel carModel:42 .
|
||||
car:23 carOnt:hasNickname "Alf"^^xsd:string .
|
||||
\end{lstlisting}
|
||||
\begin{itemize}
|
||||
\item Turtle erlaubt mit \texttt{@prefix} die Definition von Prefixen\footnote{Für die Übersichtlichkeit werden Prefixe auf den folgenden Folien weggelassen.}
|
||||
\item $\rightarrow$ Übersichtliche Repräsentation der Fakten
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}[fragile]{Beispiel: Zwei RDF-Tripel visualisiert}
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
%\includegraphics[width=\textwidth]{img/triple-spo.pdf}
|
||||
\caption{Prädikate verknüpfen ein Subjekt mit Objekt und Literalwert}
|
||||
\label{fig:triple_spo}
|
||||
\end{figure}
|
||||
\begin{lstlisting}
|
||||
car:23 carOnt:isCarModel carModel:42 .
|
||||
car:23 carOnt:hasNickname "Alf"^^xsd:string .
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Assertion Box (ABox) und Terminology Box (TBox)}
|
||||
\begin{itemize}
|
||||
\item Unterscheidung zwischen Faktenbasis (ABox) und Terminologie (TBox)
|
||||
\item TBox enthält Vokabular mit definierter Bedeutung
|
||||
\item $\rightarrow$ Analog: Klassendefinition in OOP
|
||||
\begin{itemize}
|
||||
\item Objektklassen
|
||||
\item Prädikate
|
||||
\end{itemize}
|
||||
\item ABox enthält konkrete Fakten
|
||||
\item $\rightarrow$ Analog: Instanzen in OOP
|
||||
\begin{itemize}
|
||||
\item z.B. Wissen über existierende Objekte, \dots
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{comment}
|
||||
\begin{frame}[fragile]{Beispiel für eine TBox}
|
||||
Definition der Klassen \texttt{Car}, \texttt{CarModel} und \texttt{Driver} in RDF-Schema (RDFS):
|
||||
\begin{lstlisting}
|
||||
:Car rdf:type rdfs:class .
|
||||
:CarModel rdf:type rdfs:class .
|
||||
:Driver rdf:type rdfs:class .
|
||||
|
||||
:drives rdf:type rdf:Property .
|
||||
:drives rdfs:domain :Driver .
|
||||
:drives rdfs:range :Car .
|
||||
|
||||
:isCarModel rdf:type rdf:Property .
|
||||
:isCarModel rdfs:domain :Car .
|
||||
:isCarModel rdfs:range :CarModel .
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}[fragile]{Beispiel für eine ABox}
|
||||
Beschreibung eines PKW und dessen Fahrer mit Hilfe der Terminologie aus der vorherigen TBox:
|
||||
\begin{lstlisting}
|
||||
car:5 rdf:type :Car .
|
||||
car:5 :isCarModel carModel:8 .
|
||||
|
||||
carModel:8 rdf:type :CarModel .
|
||||
carModel:8 :maximumMotorRPM 4300 .
|
||||
|
||||
driver:1 rdf:type :Driver .
|
||||
driver:1 :drives car:5 .
|
||||
driver:1 :hasName "Max Mustermann"^^xsd:string .
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
\end{comment}
|
||||
|
||||
\begin{frame}{Reasoning}
|
||||
\begin{itemize}
|
||||
\item Prozess zum automatischen Anreichern von RDF-Daten
|
||||
\item Baut auf einer gegebenen TBox auf
|
||||
\item Ermittelt in der ABox enthaltenes, \emph{implizites} Wissen
|
||||
\end{itemize}
|
||||
|
||||
Dazu folgt nun ein Beispiel \dots
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}[fragile]{Beispiel: Reasoning}
|
||||
Gegeben sei folgende Faktenbasis (ABox):
|
||||
\begin{lstlisting}
|
||||
:a :drives :b .
|
||||
\end{lstlisting}
|
||||
Führt man nun Reasoning mit Hilfe dieser Terminologie (TBox) durch:
|
||||
\begin{lstlisting}
|
||||
:drives rdf:type rdf:Property .
|
||||
:drives rdfs:domain :Driver .
|
||||
:drives rdfs:range :Car .
|
||||
|
||||
:Vehicle rdf:type rdfs:class .
|
||||
:Car rdf:type rdfs:class .
|
||||
:Car rdfs:subclassOf :Vehicle .
|
||||
\end{lstlisting}
|
||||
So ergibt sich daraus folgendes, implizites Wissen:
|
||||
\begin{lstlisting}
|
||||
:a rdf:type :Driver .
|
||||
:b rdf:type :Car .
|
||||
:b rdf:type :Vehicle .
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
|
||||
\begin{comment}
|
||||
\begin{frame}{Zusammenfassung RDF-Exkurs}
|
||||
\begin{itemize}
|
||||
\item RDF-Daten bestehen aus Tripeln (Subjekt, Prädikat, Objekt)
|
||||
\item ABox enthält Fakten
|
||||
\item TBox enthält Definitionen für Klassen und Attribute
|
||||
\item Reasoning reichert vorhandenes Wissen automatisch um \emph{implizites} Wissen an
|
||||
\begin{itemize}
|
||||
\item \dots dafür ist eine TBox mit Vokabular notwendig
|
||||
\item Unter Nutzung von Vokabular auf RDFS-Basis kann schon viel erreicht werden
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
\end{comment}
|
||||
|
||||
|
||||
\section{Complex Event Processing mit C-SPARQL}
|
||||
|
||||
\begin{frame}[fragile]{Input: RDF-Ereignisdatenströme}
|
||||
\begin{itemize}
|
||||
\item Ereignisdaten kommen als RDF-Quadrupel an
|
||||
\begin{itemize}
|
||||
\item Tripel + Zeitstempel $\rightarrow$ Quadrupel (kurz: Quads)
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
Beispiel für Quadrupel aus RDF-Ereignisdatenströmen:
|
||||
\begin{lstlisting}
|
||||
(1344829400) event:324 rdf:type carOnt:CarStatusEvent .
|
||||
(1344829400) event:324 carOnt:relatedCar car:0 .
|
||||
(1344829400) event:324 carOnt:speed 63 .
|
||||
|
||||
(1344829405) event:325 rdf:type carOnt:CarStatusEvent .
|
||||
(1344829405) event:325 carOnt:relatedCar car:0 .
|
||||
(1344829405) event:325 carOnt:speed 75 .
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Complex Event Processing}
|
||||
\begin{itemize}
|
||||
\item Ereignisdaten werden in Sliding Windows betrachtet
|
||||
\item Auswertung anhand von CEP-Regeln
|
||||
\begin{itemize}
|
||||
\item Definieren Bedingungen und Aktionen
|
||||
\item Aktionen werden ausgeführt, wenn Bedingungen erfüllt sind
|
||||
\end{itemize}
|
||||
\item Mustererkennung und Aggregation von Ereignissen
|
||||
\item $\rightarrow$ Erzeugung komplexer Ereignisse aus Ergebnissen
|
||||
\item $\rightarrow$ Auslösen von Aktionen (externe Dienste anstoßen, Code ausführen)
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Sliding Window und Tumbling Window}
|
||||
\begin{itemize}
|
||||
\item Nur Ereignisse in einem Window sind Teil der Auswertung
|
||||
\item Haben feste Größe (z.B. 15 Minuten oder 100 Ereignisse)
|
||||
\item Werden nach jeder Auswertung weitergeschoben
|
||||
\item Tumbling Window ist Sonderfall
|
||||
\item \dots wird um seine Größe weitergeschoben
|
||||
\begin{itemize}
|
||||
\item $\rightarrow$ Ereignisse nur ein \emph{einziges Mal} darin enthalten
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
%\includegraphics[width=\textwidth]{img/slidingvstumblingwindow.pdf}
|
||||
\caption{Sliding- und Tumbling Window auf einem Ereignisstrom}
|
||||
\label{fig:slidingvstumblingwindow}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{CEP mit der C-SPARQL-Engine}
|
||||
\begin{itemize}
|
||||
\item \enquote{Continuous SPARQL}
|
||||
\item In Java implementiert, basiert auf Bibliotheken Apache Jena und Sesame
|
||||
\item Erweiterung der Abfragesprache SPARQL für RDF-Daten
|
||||
\item Enthält Funktionalität zur Verarbeitung von RDF-Datenströmen
|
||||
\item Ermöglicht leichte Einbindung von lokalem Domänenwissen
|
||||
\item Unterstützt Reasoning auf RDF-Datenströmen mit RDFS-Vokabular
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{CEP-Regeln}
|
||||
Szenario:
|
||||
\begin{itemize}
|
||||
\item PKW-Verleihgesellschaft möchte Fuhrpark überwachen
|
||||
\item Vergünstigte Tarife für verschleißarmes Fahrverhalten
|
||||
\item PKW senden periodisch \texttt{CarStatusEvent}s aus
|
||||
\item Domänenwissen enthält Daten über die Fahrer der PKW
|
||||
\item Beispiel: Notorische Raser (>130km/h) sollen erkannt werden
|
||||
\end{itemize}
|
||||
Dazu folgt nun der C-SPARQL-Query \dots
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}[fragile]{C-SPARQL Query}
|
||||
\begin{lstlisting}
|
||||
REGISTER QUERY getSpeedingCars AS
|
||||
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
|
||||
PREFIX car: <http://example.org/carSim/carSimulationOntology#>
|
||||
SELECT ?driverName ?car (AVG(?speed) AS ?avgSpeed)
|
||||
FROM STREAM <http://example.org/carSim/stream/carStream> [RANGE 5m STEP 1m]
|
||||
FROM <http://example.org/carSimKnowledgeGraph>
|
||||
WHERE {
|
||||
?e rdf:type car:CarStatusEvent .
|
||||
?e car:relatedCar ?car .
|
||||
?e car:speed ?speed .
|
||||
?driver car:isDriving ?car .
|
||||
?driver car:hasName ?driverName .
|
||||
}
|
||||
GROUP BY (?car)
|
||||
HAVING (AVG(?speed) > 130)
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Ergebnis}
|
||||
\begin{itemize}
|
||||
\item Alle PKW mit Durchschnittsgeschwindigkeit >130km/h werden gemeldet
|
||||
\item Verantwortliche Fahrer sind Teil des Ergebnisses
|
||||
\item Weiterführend möglich: Observer in Java schreiben und an Abfrage registrieren
|
||||
\item In Observer: über solche Vorfälle Buch führen
|
||||
\item Gesamte Umsetzung des Szenarios in Bachelorarbeit beschrieben
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
|
||||
\section{Fazit}
|
||||
|
||||
\begin{frame}{Fazit}
|
||||
\begin{itemize}
|
||||
\item C-SPARQL-Engine noch nicht vollständig ausgereift
|
||||
\begin{itemize}
|
||||
\item Probleme mit Sprachparser, kryptische Exceptions, Zeitstempel nicht immer abrufbar
|
||||
\end{itemize}
|
||||
\item Einige Probleme bei der Durchführung des Beispielszenarios aufgetaucht
|
||||
\item Einfacher Zugriff auf Domänenwissen ist großer Pluspunkt
|
||||
\item Domänenwissen zur Laufzeit leicht veränderbar
|
||||
\item Nutzung von Reasoning auf Basis von TBox mit RDF-Schema möglich
|
||||
\begin{itemize}
|
||||
\item \dots auch auf Daten der Ereignisdatenströme!
|
||||
\end{itemize}
|
||||
\item Für rein didaktische Zwecke auf jeden Fall zur Erprobung von CEP geeignet
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Ausblick}
|
||||
\begin{itemize}
|
||||
\item Nach einigen Verbesserungen und Fehlerbehebungen gut nutzbar
|
||||
\item Dann auch definitiv für Einsteiger geeignet
|
||||
\item Eventuell Reasoning auf Basis von TBox mit OWL-Ontologien denkbar
|
||||
\begin{itemize}
|
||||
\item Diese sind deutlich mächtiger als Vokabular auf RDFS-Basis
|
||||
\item Ermöglichen Attribute mit Transitivität, Symmetrie, Inversen, \dots
|
||||
\end{itemize}
|
||||
\item IPv6 wird immer verbreiteter verwendet
|
||||
\item $\rightarrow$ Die Abteilung Informatik benötigt einen IPv6-fähigen VPN-Dienst
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
@ -358,9 +21,5 @@ HAVING (AVG(?speed) > 130)
|
||||
\end{comment}
|
||||
|
||||
\begin{frame}[fragile]{EOF}
|
||||
Vielen Dank für Ihre Aufmerksamkeit!
|
||||
|
||||
Fragen?
|
||||
|
||||
Download der Software und Bachelorarbeit unter: \url{http://jpt.lu/thesispackage.zip}
|
||||
Haben Sie Fragen?
|
||||
\end{frame}
|
||||
Loading…
Reference in New Issue
Block a user