[TASK] Generic commit
This commit is contained in:
parent
ebc64836cf
commit
771074ad5c
|
|
@ -202,14 +202,14 @@ Das Domänenwissen enthält in diesem Szenario folgende Informationen:
|
|||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
||||
\todo{GRAFIK: Grobes Informationsnetzwerk zur Veranschaulichung der Zusammenhänge zwischen den drei Elementen (Ströme + Hintergrundwissen).}
|
||||
|
||||
|
||||
\chapter{Grundlagen}\label{cpt:basics}
|
||||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
\todo{In der Motivation wurde grob erklärt, warum jetzt CEP das Mittel der Wahl sein soll. Aber was bedeutet das eigentlich? Was ist denn CEP und was ist RDF? Das kommt in diesem Kapitel.}
|
||||
|
||||
\todo{Mehr Fachbegriffe nutzen und früher einführen}
|
||||
\dots In der Motivation wurde grob erklärt, warum jetzt CEP das Mittel der Wahl sein soll. Aber was bedeutet das eigentlich? Was ist denn CEP und was ist RDF? Das kommt in diesem Kapitel.
|
||||
|
||||
|
||||
\section{Einführung in das semantische Web}
|
||||
|
|
@ -219,13 +219,15 @@ Das Domänenwissen enthält in diesem Szenario folgende Informationen:
|
|||
|
||||
\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.
|
||||
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 um eine einfache Aussage zu formen. 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 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 Car-Subjekt \texttt{\#23} über das Prädikat \texttt{isCarModel} dem Objekt CarModell \texttt{\#42} zu.
|
||||
|
||||
\todo{GRAFIK: zwei Elipsen und ein Pfeil, alle mit je S/P/O beschriftet zur Verdeutlichung.}
|
||||
|
||||
\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.
|
||||
|
|
@ -239,7 +241,6 @@ car:23 carOnt:isCarModel carModel:42 .
|
|||
Über Prädikate können diesem Subjekt mit Spezifikation im Objekt-Teil des Tripels bestimmte Attribute mit Werten zugesprochen werden oder Verknüpfungen mit anderen Subjekten hergestellt werden.
|
||||
|
||||
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 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#> .
|
||||
|
|
@ -266,11 +267,23 @@ 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 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.
|
||||
|
||||
\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.
|
||||
\subsection{RDFS}
|
||||
|
||||
Das RDFS, kurz für \enquote{RDF Schema},
|
||||
|
||||
\cite{hitzler:semanticweb}[Siehe Kapitel 3.4]
|
||||
\begin{itemize}
|
||||
\item RDF Schema
|
||||
\item Objektklassen
|
||||
\item \texttt{subclassOf}, \texttt{propertyOf}, \dots
|
||||
\item \enquote{Literale}
|
||||
\item Kann zur groben Strukturierung von Daten genutzt werden
|
||||
\end{itemize}
|
||||
|
||||
\subsection{OWL-Ontologien}
|
||||
In OWL (Web Ontology Language) formulierte Ontologien werden im semantischen Web sehr häufig zur Strukturierung von RDF-Daten verwendet. Ähnlich wie RDFS definieren OWL-Ontologien 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.
|
||||
|
||||
\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}.)
|
||||
|
|
@ -491,7 +504,7 @@ Grobe Eckpunkte zur Orientierung:
|
|||
|
||||
\todo{Zusammenfassungsüberleitung über das Kapitel}
|
||||
|
||||
\todo{In diesem Kapitel werden abstrakte Condition-Action-Regeln für das Beispielszenario formuliert und dann mit konkreten \enquote{C-SPARQL}-CSPARQL-Queries umgesetzt. }
|
||||
In diesem Kapitel werden abstrakte Condition-Action-Regeln für das Beispielszenario formuliert und dann mit konkreten CSPARQL-Queries für die \enquote{C-SPARQL}-Engine umgesetzt. Die Ergebnisse dieser Queries kommen im nächsten Kapitel, da sie näher an der Implementierung dran sind. Grundlegende Idee: Query mit ggf. nötigem Beiwerk registrieren und dann die Ergebnisse präsentieren.
|
||||
|
||||
|
||||
\section{Resoning auf RDF-Datenströmen?}
|
||||
|
|
@ -502,7 +515,7 @@ Grobe Eckpunkte zur Orientierung:
|
|||
\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
|
||||
\item Einer der möglichen Ansätze: Reasoner errechnet für die Ereignisse Tripel mit begrenzter Lebensdauer (z.B. in C-SPARQL-Engine verwendet)
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue