[TASK] Generic commit.
This commit is contained in:
parent
b0c9336bd6
commit
4641e4be42
|
|
@ -281,6 +281,11 @@ car:0 carOnt:isDrivenBy driver:0 .
|
|||
driver:0 carOnt:drives car:0
|
||||
\end{lstlisting}
|
||||
|
||||
\paragraph{ABox und TBox}
|
||||
Bei der Modellierung von Wissen mit Hilfe von Beschreibungslogiken, zu denen auch OWL und RDFS zählen, werden die formulierten Aussagen in zwei Gruppen unterteilt\cite{hitzler:semanticweb}[Kapitel 6.1]: Die Assertion Box (ABox) und die Terminology Box (TBox). Während die TBox Aussagen mit terminologischem Schemawissen wie Definitionen von Objektklassen, Prädikaten und ihren Verhältnissen zueinander enthält, beinhaltet die ABox sogenanntes \emph{assertionales Instanzwissen}\cite{hitzler:semanticweb}[Kapitel 6.1], welches aus Aussagen über konkrete Klasseninstanzen und deren Merkmale und Beziehungen besteht. In diesen Aussagen der ABox wird dabei das in der TBox definierte Vokabular genutzt.
|
||||
|
||||
\todo{GRAFIK: Ein wenig visualisiertes Wissen, welches TBox und ABox-Inhalte getrennt voneinander darstellt. (Eine Ebene mit Klassen und Attributen, eine andere Ebene mit konkreten Klasseninstanzen und deren Merkmalen)}
|
||||
|
||||
\paragraph{Objektklassen und -instanzen}
|
||||
\todo{Teile von Listing~\ref{lst:sample_rdf_data} erklären und mal auf \texttt{rdf:type} eingehen}
|
||||
|
||||
|
|
@ -314,10 +319,23 @@ Natürlich ist es möglich, mehrere verschiedene Ontologien gleichzeitig zu verw
|
|||
\paragraph{Open World Assumption}
|
||||
Sollte es nötig sein, für eigene Terminologie eine Ontologie zu erzeugen, so ist es wichtig hervorzuheben, dass für in RDF abgebildete Fakten nahezu immer die Annahme gilt, dass diese Daten nicht vollständig sind und somit nicht alle realen Fakten auch in RDF erfasst sind. Die meisten existierenden Ontologien respektieren diese Annahme und verzichten auf die Definition von expliziten Regeln, die über die konkrete Bedeutung der Abwesenheit von bestimmten Fakten entscheiden würden. (In der Welt der relationalen Datenbanksysteme gibt es eine ähnliche Problematik in Zusammenhang mit der Verwendung des Schlüsselworts \texttt{NULL}.)
|
||||
|
||||
\paragraph{ABox und TBox}
|
||||
Bei der Modellierung von Wissen mit Hilfe von Beschreibungslogiken, zu denen auch OWL und RDFS zählen, werden die formulierten Aussagen in zwei Gruppen unterteilt\cite{hitzler:semanticweb}[Kapitel 6.1]: Die Assertion Box (ABox) und die Terminology Box (TBox). Während die TBox Aussagen mit terminologischem Schemawissen wie Definitionen von Objektklassen, Prädikaten und ihren Verhältnissen zueinander enthält, beinhaltet die ABox sogenanntes \emph{assertionales Instanzwissen}\cite{hitzler:semanticweb}[Kapitel 6.1], welches aus Aussagen über konkrete Klasseninstanzen und deren Merkmale und Beziehungen besteht. In diesen Aussagen der ABox wird dabei das in der TBox definierte Vokabular genutzt.
|
||||
|
||||
\todo{GRAFIK: Ein wenig visualisiertes Wissen, welches TBox und ABox-Inhalte getrennt voneinander darstellt. (Eine Ebene mit Klassen und Attributen, eine andere Ebene mit konkreten Klasseninstanzen und deren Merkmalen)}
|
||||
\subsection{Anreicherung von RDF-Daten durch Reasoning}\label{cpt:reasoning}
|
||||
|
||||
\todo{OWL-Reasoning vs RDFS-Reasoning (Mächtigkeit)}
|
||||
|
||||
\todo{Warum ist Reasoning hilfreich/wichtig/sinnvoll? - Automatische Anreicherung auf Basis der TBox}
|
||||
|
||||
Durch den Einsatz von Terminologiewissen in Form von OWL-Ontologien oder RDF-Schemata ergibt sich die Möglichkeit, die Fakten aus der ABox automatisch um über die Terminologie abgeleitetes Wissen anzureichern. Diesen Prozess der bezeichnet man als \emph{Reasoning}.
|
||||
|
||||
In diesem Prozess werden aus den in RDF vorliegenden Fakten (Assertion Box) und den in den verwendeten Ontologien definierten Objektklassen, Regeln und Zusammenhängen (Terminology Box) neues Wissen abgeleitet \cite{hitzler:semanticweb} und die lokale Datenbasis damit angereichert. So können beispielsweise implizite Klassentypen errechnet werden (\enquote{Ein PKW ist auch ein Fahrzeug}), oder regelbasierte Zugehörigkeiten zu Objektklassen ermittelt werden: Die Aussagen \enquote{Der PKW x rollt.} und \enquote{Der PKW x ist verriegelt.} können zu der Folgerung \enquote{Der PKW x ist eine Gefahrenquelle.} führen.
|
||||
\todo{Andere Beispiele im Kontext statischer Daten?}
|
||||
|
||||
Enthält eine Ontologie strukturelle Informationen über Fahrer, PKW und Attribute bezüglich technischer Daten über PKW-Modelle, so ist es beispielsweise möglich auf Basis der Fakten aus Listing~\ref{lst:sample_rdf_data} zusätzliche Attribute der Fahrer wie \enquote{isDrivingCarModel} oder der PKW wie \enquote{hasEmergencyContactNumber} zu errechnen. Dieses funktioniert natürlich nur, falls in den Fakten bekannt ist, dass ein Fahrer ein Fahrzeug fährt und somit zu diesem Fahrzeug verbunden ist. Limitiert werden die Möglichkeiten des Reasoning ebenfalls durch die \emph{Open World Assumption} (OWA), also die Annahme einer offenen Welt, über die nur \emph{unvollständiges Wissen} vorliegt. Deshalb sollten für Reasoning nur explizit bekannte Fakten genutzt werden: Nur weil in Listing~\ref{lst:sample_rdf_data} keine Informationen über weitere PKW oder Fahrer vorhanden sind heißt das nicht, dass diese nicht existieren oder Einfluss auf die bekannten Fakten haben könnten. Weiterführende Beispiele zu den Möglichkeiten von OWL Reasoning finden sich unter \cite{man:owl}.
|
||||
|
||||
Da Ontologien auch genutzt werden können, um Wissen aus den Strukturen einer Ontologie in die Struktur einer anderen Ontologie zu übersetzen, kann ein Reasoner die daraus resultierende Übersetzung direkt errechnen und der lokalen Datenbasis hinzufügen. Dadurch steht Abfragen, die schon auf die Ziel-Ontologie zugeschnitten sind, ein viel größerer Informationspool zur Verfügung, aus dem das Abfrageergebnis berechnet werden soll.
|
||||
|
||||
Die Vorteile von Reasoning erkauft man sich durch einen nicht unerheblichen Einsatz von Rechenleistung, da im Prozess des Reasoning eine Menge von zusätzlichen Daten entsteht, für die zusätzlich zu den bereits vorhandenen Daten die Regeln aller genutzten Ontologien berücksichtigt werden müssen. Behandelt man lediglich statische Daten, die sich kaum bis garnicht ändern, so ist der nötige Aufwand für Reasoning übersichtlich und liegt auch für große Mengen von Daten und Ontologien in einem akzeptablem Rahmen. Ändern sich jedoch häufig Daten, so muss für das Subset der veränderten Daten der Reasoning-Prozess erneut durchgeführt werden um eine vollständig aktuelle Datenbasis zu erhalten.
|
||||
|
||||
|
||||
\subsection{Abfrage von RDF-Daten via SPARQL}\label{cpt:rdf-sparql}
|
||||
|
|
@ -358,24 +376,6 @@ CONSTRUCT {
|
|||
Wie in Listing~\ref{lst:sample_sparql_construct} gezeigt, können einfache Operationen in SPARQL-Abfragen durchgeführt werden, deren Ergebnisse über die \texttt{BIND}-Anweisung in einen vorgegebenen Platzhalter \texttt{?rpmTolerance} eingesetzt werden. In diesem Beispiel wurde die Differenz zwischen der maximalen und der minimalen empfohlenen Motordrehzahl eines Automodells ausgerechnet und ein neues Tripel mit dieser Information generiert.
|
||||
|
||||
|
||||
\subsection{Anreicherung von RDF-Daten durch Reasoning}\label{cpt:reasoning}
|
||||
|
||||
\todo{OWL-Reasoning vs RDFS-Reasoning (Mächtigkeit)}
|
||||
|
||||
\todo{Warum ist Reasoning hilfreich/wichtig/sinnvoll? - Automatische Anreicherung auf Basis der TBox}
|
||||
|
||||
Durch den Einsatz von Terminologiewissen in Form von OWL-Ontologien oder RDF-Schemata ergibt sich die Möglichkeit, die Fakten aus der ABox automatisch um über die Terminologie abgeleitetes Wissen anzureichern. Diesen Prozess der bezeichnet man als \emph{Reasoning}.
|
||||
|
||||
In diesem Prozess werden aus den in RDF vorliegenden Fakten (Assertion Box) und den in den verwendeten Ontologien definierten Objektklassen, Regeln und Zusammenhängen (Terminology Box) neues Wissen abgeleitet \cite{hitzler:semanticweb} und die lokale Datenbasis damit angereichert. So können beispielsweise implizite Klassentypen errechnet werden (\enquote{Ein PKW ist auch ein Fahrzeug}), oder regelbasierte Zugehörigkeiten zu Objektklassen ermittelt werden: Die Aussagen \enquote{Der PKW x rollt.} und \enquote{Der PKW x ist verriegelt.} können zu der Folgerung \enquote{Der PKW x ist eine Gefahrenquelle.} führen.
|
||||
\todo{Andere Beispiele im Kontext statischer Daten?}
|
||||
|
||||
Enthält eine Ontologie strukturelle Informationen über Fahrer, PKW und Attribute bezüglich technischer Daten über PKW-Modelle, so ist es beispielsweise möglich auf Basis der Fakten aus Listing~\ref{lst:sample_rdf_data} zusätzliche Attribute der Fahrer wie \enquote{isDrivingCarModel} oder der PKW wie \enquote{hasEmergencyContactNumber} zu errechnen. Dieses funktioniert natürlich nur, falls in den Fakten bekannt ist, dass ein Fahrer ein Fahrzeug fährt und somit zu diesem Fahrzeug verbunden ist. Limitiert werden die Möglichkeiten des Reasoning ebenfalls durch die \emph{Open World Assumption} (OWA), also die Annahme einer offenen Welt, über die nur \emph{unvollständiges Wissen} vorliegt. Deshalb sollten für Reasoning nur explizit bekannte Fakten genutzt werden: Nur weil in Listing~\ref{lst:sample_rdf_data} keine Informationen über weitere PKW oder Fahrer vorhanden sind heißt das nicht, dass diese nicht existieren oder Einfluss auf die bekannten Fakten haben könnten. Weiterführende Beispiele zu den Möglichkeiten von OWL Reasoning finden sich unter \cite{man:owl}.
|
||||
|
||||
Da Ontologien auch genutzt werden können, um Wissen aus den Strukturen einer Ontologie in die Struktur einer anderen Ontologie zu übersetzen, kann ein Reasoner die daraus resultierende Übersetzung direkt errechnen und der lokalen Datenbasis hinzufügen. Dadurch steht Abfragen, die schon auf die Ziel-Ontologie zugeschnitten sind, ein viel größerer Informationspool zur Verfügung, aus dem das Abfrageergebnis berechnet werden soll.
|
||||
|
||||
Die Vorteile von Reasoning erkauft man sich durch einen nicht unerheblichen Einsatz von Rechenleistung, da im Prozess des Reasoning eine Menge von zusätzlichen Daten entsteht, für die zusätzlich zu den bereits vorhandenen Daten die Regeln aller genutzten Ontologien berücksichtigt werden müssen. Behandelt man lediglich statische Daten, die sich kaum bis garnicht ändern, so ist der nötige Aufwand für Reasoning übersichtlich und liegt auch für große Mengen von Daten und Ontologien in einem akzeptablem Rahmen. Ändern sich jedoch häufig Daten, so muss für das Subset der veränderten Daten der Reasoning-Prozess erneut durchgeführt werden um eine vollständig aktuelle Datenbasis zu erhalten.
|
||||
|
||||
|
||||
\section{Einführung in Complex Event Processing}\label{cpt:cep_intro}
|
||||
|
||||
Von Transaktionen im Handel über Messereignisse von Sensoren bis hin zu Benutzerinteraktionen auf Webseiten entstehen täglich eine Vielzahl von Ereignisdaten, die für einen begrenzten Zeitraum einen Teil der echten Welt abbilden. Um aus diesen großen Datenmengen innerhalb kürzester Zeit Muster erkennen zu können und daraus höherwertige Informationen zu aggregieren, ist Complex Event Processing (CEP) ein geeignetes Werkzeug.
|
||||
|
|
@ -414,50 +414,6 @@ Ereignisdaten enthalten einige wenige Angaben über die Situation, in der sie en
|
|||
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.
|
||||
|
||||
|
||||
\chapter{CEP auf RDF-Datenströmen}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
Nachdem ein grober Einblick in die Welten von RDF und CEP gegeben wurde, soll nun Complex Event Processing verwendet werden, um Ereignisdatenströme im RDF-Format zu verarbeiten.
|
||||
|
||||
|
||||
\section{Ereignisse}
|
||||
|
||||
\begin{itemize}
|
||||
\item Wie sehen RDF-Ereignisse aus, warum sind es Quadrupel anstatt einfacher Tripel?
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Sprachkonzepte}
|
||||
|
||||
\todo{Dieser Bereich wird definitiv mit abstrakter Sprache und dann konkretem C-SPARQL CSPARQL-Query demonstriert.}
|
||||
\begin{itemize}
|
||||
\item Sliding Windows zur Betrachtung der Ereignisströme
|
||||
\item Mustererkennung
|
||||
\item Aggregation von Ereignissen
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Mustererkennung, Sliding Windows, Aggregation von Ereignissen}
|
||||
|
||||
|
||||
|
||||
\subsection{Auslösen von Aktionen}
|
||||
Erzeugen von Ereignissen innerhalb von CSPARQL-Queries. Hinweise auf Möglichkeit der Auslösung von Reaktionen beim Beobachten der Abfrageergebnisse.
|
||||
|
||||
|
||||
|
||||
\section{Einbindung von Domänenwissen}
|
||||
Integration von Hintergrundwissen findet live im Query statt ohne extra Klimmzüge, da alles innerhalb der CSPARQL-Queries abzufragen ist.
|
||||
|
||||
|
||||
\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{Vergleich aktueller RDF-fähiger CEP-Engines}\label{cpt:engine_comparison}
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
|
|
@ -525,6 +481,50 @@ 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{CEP auf RDF-Datenströmen}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
Nachdem ein grober Einblick in die Welten von RDF und CEP gegeben wurde, soll nun Complex Event Processing verwendet werden, um Ereignisdatenströme im RDF-Format zu verarbeiten.
|
||||
|
||||
|
||||
\section{Ereignisse}
|
||||
|
||||
\begin{itemize}
|
||||
\item Wie sehen RDF-Ereignisse aus, warum sind es Quadrupel anstatt einfacher Tripel?
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Sprachkonzepte}
|
||||
|
||||
\todo{Dieser Bereich wird definitiv mit abstrakter Sprache und dann konkretem C-SPARQL CSPARQL-Query demonstriert.}
|
||||
\begin{itemize}
|
||||
\item Sliding Windows zur Betrachtung der Ereignisströme
|
||||
\item Mustererkennung
|
||||
\item Aggregation von Ereignissen
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Mustererkennung, Sliding Windows, Aggregation von Ereignissen}
|
||||
|
||||
|
||||
|
||||
\subsection{Auslösen von Aktionen}
|
||||
Erzeugen von Ereignissen innerhalb von CSPARQL-Queries. Hinweise auf Möglichkeit der Auslösung von Reaktionen beim Beobachten der Abfrageergebnisse.
|
||||
|
||||
|
||||
|
||||
\section{Einbindung von Domänenwissen}
|
||||
Integration von Hintergrundwissen findet live im Query statt ohne extra Klimmzüge, da alles innerhalb der CSPARQL-Queries abzufragen ist.
|
||||
|
||||
|
||||
\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{Umsetzung des Beispielszenarios}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
|
|
|||
Loading…
Reference in New Issue