[TASK] Generic commit
This commit is contained in:
parent
6e95900f4d
commit
ebc64836cf
@ -170,32 +170,32 @@ Diesbezüglich soll ergründet werden, welche CEP-Engines Reasoning bereits impl
|
||||
|
||||
\section{Szenario}\label{cpt:scenario}
|
||||
|
||||
\todo{Eventuell platziere ich die Details des Szenarios vor das Konzept-Kapitel und halte die Beschreibung allgemeiner? --- Jap, so könnte es gehen. Dann wird hier nur grob erklärt, welche Daten für das Szenario interessant sind; die einzelnen Datenströme und Formate der Ereignisse kommen dann in das Konzept-Kapitel.}
|
||||
|
||||
Das bereits erwähnte Beispielszenario, welches für diese Arbeit verwendet wird, ist eine Autoverleihgesellschaft, die ihren Fuhrpark überwachen möchte, um ihren Kunden vergünstigte Tarife für verschleißarmes Fahrverhalten anbieten zu können. Weiterhin soll auf plötzlich auftretende Probleme an den Leihwagen möglichst schnell reagiert werden können um Schäden zu begrenzen, gefährliche Situationen zu vermeiden und bei Bedarf dem Kunden unverzüglich einen Ersatzwagen oder weitere Serviceleistungen anbieten zu können. Um dies zu erreichen, werden zwei RDF-Datenströme zur späteren Verarbeitung eingerichtet.
|
||||
Das bereits erwähnte Beispielszenario, welches für diese Arbeit verwendet wird, ist eine Autoverleihgesellschaft, die ihren Fuhrpark überwachen möchte, um ihren Kunden vergünstigte Tarife für verschleißarmes Fahrverhalten anbieten zu können. Weiterhin soll auf plötzlich auftretende Probleme an den Leihwagen möglichst schnell reagiert werden können um Schäden zu begrenzen, gefährliche Situationen zu vermeiden und bei Bedarf dem Kunden unverzüglich einen Ersatzwagen oder weitere Serviceleistungen anbieten zu können. Um dies zu erreichen, werden zwei RDF-Ereignisdatenströme zur späteren Verarbeitung eingerichtet und eine Sammlung von Fakten in lokalem Domänenwissen aufgebaut.
|
||||
|
||||
\paragraph{Statusdatenstrom der Autos}
|
||||
Über diesen Datenstrom melden die einzelnen Autos kontinuierlich ihre Statuswerte:
|
||||
\begin{itemize}
|
||||
\item Auto verschlossen (ja/nein)
|
||||
\item Status des Motor (an/aus)
|
||||
\item Status des Motors (an/aus)
|
||||
\item Status der Handbremse (angezogen/gelöst)
|
||||
\item Momentangeschwindigkeit in km/h
|
||||
\item Drehzahl des Motors
|
||||
\item Reifendrücke der Reifen in bar
|
||||
\end{itemize}
|
||||
Besonders wichtige Ereignisse, wie das Aufleuchten der Motorkontrollleuchte oder das Auslösen des Airbags, werden separat gemeldet.
|
||||
Besonders wichtige Ereignisse, wie das Aufleuchten der Motorkontrollleuchte oder das Auslösen des Airbags, werden über diesen Datenstrom separat von den Statusdaten gemeldet.
|
||||
|
||||
\paragraph{Interaktionsstrom der Kunden}
|
||||
Wird einem Kunden ein Auto zugewiesen oder gibt ein Kunde ein geliehenes Auto wieder zurück, so wird hierfür ein Ereignis in diesen Datenstrom eingespeist. Diese Ereignisse enthalten immer eine eindeutige Kundennummer und die Nummer des geliehenen Fahrzeugs.
|
||||
Wird einem Kunden ein Auto zugewiesen oder gibt ein Kunde ein geliehenes Auto wieder zurück, so wird hierfür ein Ereignis in diesen Datenstrom eingespeist. Diese Ereignisse enthalten immer die eindeutige Kundennummer und die Nummer des geliehenen Fahrzeugs, um eine Zuordnung vornehmen zu können.
|
||||
|
||||
\paragraph{Domänenwissen}
|
||||
Um die Ereignisdaten aus den beiden beschriebenen Datenströmen bei der Verarbeitung in einen eindeutigen Kontext setzen zu können, wird lokal verfügbares Hintergrundwissen benötigt. Dieses enthält für dieses Szenario folgende Informationen:
|
||||
Um die Ereignisdaten aus den beiden beschriebenen Datenströmen bei der Verarbeitung in einen eindeutigen Kontext setzen zu können, wird lokal verfügbares Hintergrundwissen benötigt. Es baut die Zuordnung von Kunden zu den von ihnen geliehenen Autos auf, ordnet die einzelnen Autos bestimmten Automodellen zu und ermöglicht so eine konkrete Interpretation der von den Autos gemeldeten Daten.
|
||||
|
||||
Das Domänenwissen enthält in diesem Szenario folgende Informationen:
|
||||
\begin{itemize}
|
||||
\item Eindeutige Zuordnung von Kundennummer zu einem Kunden
|
||||
\item Kundendaten wie Name und Telefonnummer
|
||||
\item Eindeutige Zuordnung von Fahrzeugnummer zu Automodell
|
||||
\item Wissen über die verschiedenen Automodelle:
|
||||
\item Wissen über Automodelle:
|
||||
\begin{itemize}
|
||||
\item Empfohlene Motordrehzahlbereiche für verschleißarmes Fahren
|
||||
\item Vorgeschriebener Reifendruck
|
||||
@ -211,20 +211,22 @@ Um die Ereignisdaten aus den beiden beschriebenen Datenströmen bei der Verarbei
|
||||
|
||||
\todo{Mehr Fachbegriffe nutzen und früher einführen}
|
||||
|
||||
|
||||
\section{Einführung in das semantische Web}
|
||||
|
||||
|
||||
\todo{Da wir CEP auf RDF-Datenströmen betreiben wollen kommt jetzt erst einmal eine Einführung in die bisher typische Welt von RDF, der dazugehörigen Abfragesprache SPARQL und ein kleiner Ausblick auf die Fähigkeiten von Reasoning.}
|
||||
\todo{Da wir CEP auf RDF-Datenströmen betreiben wollen kommt jetzt erst einmal eine Einführung in die bisher typische Welt von RDF, der dazugehörigen Abfragesprache SPARQL und ein kleiner Ausblick auf die Fähigkeiten von Reasoning auf statischen Daten.}
|
||||
|
||||
|
||||
\subsection{RDF im semantischen Web}\label{cpt:rdf-semantic-web}
|
||||
|
||||
Das Ressource Description Framework (RDF) wird im semantischen Web zur Modellierung und Beschreibung von Wissen verwendet. RDF-Daten bestehen aus einer Menge von Tripeln, welche sich aus den drei Komponenten Subjekt, Prädikat und Objekt in genau dieser Abfolge zusammensetzen. Jeder dieser drei Bestandteile eines Tripels wird durch einen eindeutigen Uniform Resource Identifier (URI\footnote{Der URI wird in RFC 3986 beschrieben. Anstelle eines URI kann auch ein IRI (Internationalized Resource Identifier) verwendet werden --- die internationalisierte Form des URI nach RFC 3987.}) identifiziert.
|
||||
\begin{lstlisting}[caption={Ein einzelnes RDF-Tripel},label={lst:sample_rdf_triple}]
|
||||
\begin{lstlisting}[caption={Ein RDF-Tripel},label={lst:sample_rdf_triple}]
|
||||
<http://example.org/carSim/objects/Car#23> <http://example.org/carSim/carSimulationOntology#isCarModel> <http://example.org/carSim/objects/CarModel#42> .
|
||||
\end{lstlisting}
|
||||
|
||||
Das in Listing~\ref{lst:sample_rdf_triple} enthaltene Tripel ordnet das Auto-Subjekt \texttt{\#23} über das Prädikat \texttt{isCarModel} dem Objekt Automodell \texttt{\#42} zu.
|
||||
Das in Listing~\ref{lst:sample_rdf_triple} enthaltene Tripel ordnet das Car-Subjekt \texttt{\#23} über das Prädikat \texttt{isCarModel} dem Objekt CarModell \texttt{\#42} zu.
|
||||
|
||||
\paragraph{Turtle-Notation mit Prefixen}
|
||||
Wie anhand des Beispiels erkennbar ist, ist die explizite Notation für Tripel aufgrund der häufigen Nennung von vollständigen URIs wenig platzsparend und für große Datenmengen somit nicht empfehlenswert. Hierfür bietet sich die Nutzung von Prefixen an, die nach einmaliger Definition innerhalb eines Kontextes (zum Beispiel einer Datei) verwendet werden können.
|
||||
Listing~\ref{lst:sample_rdf_triple_with_prefix} zeigt die Notation von Tripeln im Turtle\footnote{Siehe auch die Spezifikation der Turtle-Notation nach \cite{w3c:turtle}}-Format unter Verwendung von Prefixen.
|
||||
\begin{lstlisting}[caption={Das Beispieltripel aus Listing~\ref{lst:sample_rdf_triple} mit Prefixen},label={lst:sample_rdf_triple_with_prefix}]
|
||||
@ -238,20 +240,42 @@ car:23 carOnt:isCarModel carModel:42 .
|
||||
|
||||
Aufgrund der Flexibilität dieser Struktur ist es möglich, nahezu jede Art von Informationen auf Tripel abzubilden, wie Listing~\ref{lst:sample_rdf_data} an einem Beispiel zeigt.
|
||||
|
||||
\begin{lstlisting}[caption={RDF-Daten beschreiben ein Auto und einen Fahrer},label={lst:sample_rdf_data}]
|
||||
\begin{lstlisting}[caption={RDF-Daten beschreiben ein Auto und dessen Fahrer},label={lst:sample_rdf_data}]
|
||||
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
|
||||
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
|
||||
@prefix car: <http://example.org/carSim/objects/Car#> .
|
||||
@prefix carModel: <http://example.org/carSim/objects/CarModel#> .
|
||||
@prefix driver: <http://example.org/carSim/objects/Driver#> .
|
||||
@prefix carOnt: <http://example.org/carSim/carSimulationOntology#> .
|
||||
|
||||
car:0 rdf:type carOnt:Car .
|
||||
car:0 carOnt:isCarModel carModel:0 .
|
||||
|
||||
carModel:0 rdf:type carOnt:CarModel .
|
||||
carModel:0 carOnt:minimumMotorRPM 2000 .
|
||||
carModel:0 carOnt:maximumMotorRPM 4300 .
|
||||
carModel:0 carOnt:minimumTirePressure 2.9 .
|
||||
carModel:0 carOnt:maximumTirePressure 3.2 .
|
||||
carModel:0 carOnt:requiresDriverLicense "B"^^xsd:string
|
||||
|
||||
driver:0 rdf:type carOnt:Driver .
|
||||
driver:0 carOnt:hasName "Max Mustermann"^^xsd:string .
|
||||
driver:0 carOnt:hasPhoneNumber "+49 111 123456789"^^xsd:string .
|
||||
driver:0 carOnt:hasDriverLicense "B"^^xsd:string .
|
||||
|
||||
car:0 carOnt:isDrivenBy driver:0 .
|
||||
driver:0 carOnt:drives car:0
|
||||
\end{lstlisting}
|
||||
|
||||
Da innerhalb des semantischen Web angestrebt wird, in RDF vorliegende Informationen gemeinsam zu nutzen, miteinander zu kombinieren und vernetzen zu können, werden RDF-Tripel meist als Quadrupel gehandhabt, in denen als zusätzliche Information der sogenannte Graph genannt wird, in dem die Tripel enthalten sind. Ein Graph wird durch eine URI identifiziert und dient somit als Namensraum für die Tripel, die er enthält. Dies vereinfacht die gleichzeitige Nutzung von mehreren Datenquellen, da jedes Tripel eindeutig einem Graphen zugeordnet werden kann und innerhalb von Abfragen spezifisch Tripel aus verschiedenen Graphen kombiniert werden können.
|
||||
Da innerhalb des semantischen Web angestrebt wird, in RDF vorliegende Informationen gemeinsam zu nutzen und miteinander zu vernetzen zu können, werden RDF-Tripel meist als Quadrupel gehandhabt, in denen als zusätzliche Information der sogenannte Graph genannt wird, in dem die Tripel enthalten sind. Ein Graph wird durch eine URI identifiziert und dient als Namensraum für die Tripel, die er enthält. Dies vereinfacht die gleichzeitige Nutzung von mehreren Datenquellen, da jedes Tripel eindeutig einem Graphen zugeordnet werden kann und innerhalb von Abfragen spezifisch Tripel aus verschiedenen Graphen selektiert werden können.
|
||||
|
||||
Zusätzlich werden im semantischen Web in OWL (Web Ontology Language) formulierte Ontologien als \enquote{Strukturgerüst} verwendet. Eine Ontologie definiert ein Vokabular mit logischen Domänenobjektklassen und bestimmt für diese Objektklassen Prädikate und Attribute, um bestimmte Sachverhalte eindeutig abbilden zu können. Eine Ontologie für Listing~\ref{lst:sample_rdf_data} würde beispielsweise eine Objektklasse \enquote{person} definieren, auf welches die eigenen Prädikate \enquote{isGender}, \enquote{hasName} und \enquote{hasSibling} angewandt werden können. Mit eigenen Attributen für das Prädikat \enquote{isGender} und spezifischen Regeln dafür, welche Attribute ein Prädikat wie \enquote{hasSibling} in Frage kommen können, werden Daten aus der Welt einer Ontologie --- ähnlich wie bei einem relationalen Datenbankschema --- eindeutig strukturiert. Hierbei ist jedoch wichtig hervorzuheben, dass für in RDF abgebildete Daten nahezu immer die Annahme gilt, dass diese Daten nicht vollständig sind (die sogenannte \enquote{Open World Assumption}). Die meisten 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.
|
||||
\subsection{Ontologien}
|
||||
Im semantischen Web werden sehr häufig in OWL (Web Ontology Language) formulierte Ontologien als eine Art \enquote{Strukturgerüst} für RDF-Daten verwendet. Eine Ontologie definiert ein Vokabular mit logischen Domänenobjektklassen und bestimmt für diese Objektklassen Prädikate und Attribute, um bestimmte Sachverhalte eindeutig abbilden zu können. Eine Ontologie für Listing~\ref{lst:sample_rdf_data} würde beispielsweise eine Objektklasse \texttt{Driver} definieren, auf welche das eigens hierfür definierte Prädikat \texttt{hasName} mit einem Attribut vom Typ \texttt{xsd:string} angewandt werden kann. Durch die Möglichkeiten dieser Restriktionen können RDF-Daten aus der Welt einer Ontologie --- ähnlich wie bei einem relationalen Datenbankschema --- eindeutig strukturiert werden.
|
||||
|
||||
Weiterhin ist es möglich, beliebig viele verschiedene Ontologien gleichzeitig zu verwenden. Diese Flexibilität ermöglicht beispielsweise, dass eine bereits in RDF abgebildete Person durch beliebige Informationen mit weiteren Ontologien ergänzt werden kann, oder dass die Informationen einer abgebildeten Person in verschiedenen, für andere Parteien geläufigen Strukturen verfügbar gemacht werden können. Auch kann innerhalb einer Ontologie auf Objektklassen und Attribute zurückgegriffen werden, die in anderen Ontologien definiert werden. Dies ermöglicht neben Erweiterungen für spezifische Zwecke auch das Übersetzen von Wissen zwischen verschiedenen Ontologien.
|
||||
\paragraph{Open World Assumption}
|
||||
Es ist wichtig hervorzuheben, dass für in RDF abgebildete Daten nahezu immer die Annahme gilt, dass diese Daten nicht vollständig sind und somit nicht alle Fakten wirklich bekannt sind. Die meisten 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}.)
|
||||
|
||||
Natürlich ist es möglich, mehrere verschiedene Ontologien gleichzeitig zu verwenden. Diese Flexibilität ermöglicht beispielsweise, dass eine bereits in RDF abgebildete Person durch beliebige Informationen mit weiteren Ontologien ergänzt werden kann, oder dass die Informationen einer abgebildeten Person in verschiedenen, für andere Parteien geläufigen Strukturen verfügbar gemacht werden können. Auch kann innerhalb einer Ontologie auf Objektklassen und Attribute zurückgegriffen werden, die in anderen Ontologien definiert werden. Dies ermöglicht neben Erweiterungen für spezifische Zwecke auch das Übersetzen von Wissen zwischen verschiedenen Ontologien.
|
||||
|
||||
|
||||
\subsection{Abfrage von RDF-Daten via SPARQL}\label{cpt:rdf-sparql}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user