Major change

[u/philim/db2osl_thesis.git] / background.tex

\chapter{Background and related work}

\section{Background}
\subsection{Basic concepts}
\label{back_basic}
TODO: r2rml, rdf, rdfs, owl, xml, iris, baseiri, end with :

\subsection{Ontology-based data access (OBDA)}
\label{back_obda}
TODO: References

Storing data in relational databases is a very common proceeding, since the
notion of a relational database is comprehensible and widely known, while the
required software is widely available both commercially and as open-source
software.
Thus, it is easy for a domain expert to set up and populate a database.
Furthermore, relational databases provide significant advantages concerning
performance, data consistency and integrity, integration abilities, support
and general prominence.
These topics definitely played a major role in the success and the extensive
exploration that databases discovered, up to the degree that these are the
main fields the strengths of databases are seen in.
Many -- if not all -- of these strengths trace back to the relatively fixed
and rigid schema databases embody: a well-defined database schema imposing
strong and clear cut constraints on the contained data.

However, this principle also induces notable disadvantages.
The database schema, although theoretically changeable, constitutes a
significant burden on TODO the representation of data of dynamic
environments, incomplete data or changing requirements,
especially when dealing with large amounts of data.
The resulting representation of data in unintuitive, suboptimal schemata
makes the use of prolonged and complex query constructs inevitable, which
lets more elaborate queries quickly become unmanageable for non-experts
and time-consuming and error-prone even for experts.
Ontologies, on the other hand, are much more flexible regarding incomplete
data or changing requirements or environments and allow for much more
intuitive and abstract query systems, while still being a quite
comprehensible formalism
(see Section~\ref{ontologies} for publications describing
ontologies and the semantic web).
Besides, ontologies provide support for different data records referencing
the same entity, while databases do not \cite{eng}, and for the deduction of
implicit information \cite{eng}, which with common database systems, if at
all, is at least not possible out of the box and in an easy manner.
Often, however, relational databases are preferred for their advantages
(although the availability of cheaper yet more powerful hardware in some
cases offsets these) or simply erroneously.
Besides, in some cases, the migration to ontology-based systems,
even if beneficial, is to costly to be seriously considered.
%, often due to the large amounts of data that would have to be converted.

Ontology-based data access often provides a solution to this collision of
interests:
By adding an ontology-based front-end processing the queries that is
sensibly mapped to the data representation,
the querying facilities of ontology-based systems are introduced,
and changes in the data representation most often can be carried out
without breaking existing queries; only the mapping has to be changed
-- in a one-time effort -- and only when it introduces changes in the way
it presents existing structures to the user, existing queries have to be
modified.
The creation of these mappings in turn can happen computer-aided or, in
simple cases or to a certain degree of completeness and accuracy,
the mappings can be completely bootstrapped.

Moreover, in cases where it is to costly or for other cases infeasible
to carry out a complete data duplication, the data can remain in the
underlying database as is and the query front-end merely acts as an
interface transforming the query into a database query \cite{eng} by
making use of a backward-chaining technique called \emph{query rewriting}
\cite{eng}.
This approach is called \emph{virtual OBDA} or \emph{virtual RDF view}
\cite{eng} and is illustrated in Figure~\ref{back_subfig_virtual}.
The oppositional approach of duplicating all data is called
\emph{materialized OBDA} or \emph{materialized RDF view} and is
illustrated in Figure~\ref{back_subfig_materialized}.
Virtual OBDA provides limited abilities compared to materialized OBDA
in that it does not allow for decoupling from the source data by for
example adding inferred information or applying elaborate transformations
and does not support ``fragments of OWL for which query
rewriting is not a complete deduction method'' \cite{eng}.
However, the response time of systems is hard to predict solely from the
architectural approach used, so if it is critical, several systems should
be prototyped and evaluated upfront on what are expected to be
typical queries \cite{eng}.

\begin{figure}[H]\begin{center}
	\begin{subfigure}[b]{0.8\textwidth}
			\includegraphics[scale=1.2]{Images/bootstrapping_materialized.pdf}
			\caption{OBDA system architecture with materialized \name{RDF} view}
			\label{back_subfig_materialized}
	\end{subfigure}\\~\\
	\begin{subfigure}[b]{0.8\textwidth}
			\includegraphics[scale=1.2]{Images/bootstrapping_virtual.pdf}
			\caption{OBDA system architecture with a virtual \name{RDF} view}
			\label{back_subfig_virtual}
	\end{subfigure}
	\caption[The two basic OBDA system architectures]
		{The two basic OBDA system architectures:
		materialized and virtual \name{RDF} views (from \cite{eng})}
	\label{back_fig_bootstrapping}
\end{center}\end{figure}

Finally, it has to be mentioned, that ontology-based data access is not
limited to databases.
Although this is the most common scenario and the only one this thesis
deals with, ontology-based data access also works with other sources of
structured information, like \name{ODS}, \name{XLS} or \name{CSV} files,
though some additional preparation might be necessary in these cases \cite{eng}.

\subsection{OBDA specifications}
\label{back_obdaspecs}
TODO: more, maybe shorten introduction

As mentioned in Section~\fullref{motivation}, the sole bootstrapping of
\name{RDF} triples \cite{rdf} or other forms of structured information
from relational database schemata is a relatively well understood topic.
This is outlined more comprehensively in Section~\fullref{related}.

Nonetheless, bootstrapping remains an elaborate process involving complex
tools to be invoked -- possibly in different versions and configurations
and processing different formats -- and working on changing input data
\cite{eng}.
This is why Skjæveland and others proposed the introduction of OBDA
specifications centralizing the task of driving these tools and
to gather in one place all the information describing the desired mapping
between the source database and the target ontology \cite{eng}.
As described in Section~\fullref{related}, their approach is the
foundation of this thesis, which describes and specifies a format for
storing and exchanging such OBDA specifications -- the \oslboth{} -- and
introduces a tool that in turn automatically bootstraps OBDA Specifications
from relational database schemata -- the \myprog{} software.

The bootstrapping process using OBDA specifications and \myprog{} is
illustrated in Figure~\ref{intro_fig_bootstrapping}
in Section~\fullref{approach}.

\subsection{The \name{OPTIQUE} project}
The problems addressed in Section~\fullref{motivation} are a big issue
inter alia TODO in the oil and gas industry:
$30 \%$ to $70 \%$ of the working time of engineers is spent on collecting
data or assessing its quality \cite{crompton}.
This led to the origination of the \name{OPTIQUE} project in TODO which
``advocates for a next generation of the well known Ontology-Based Data Access
(OBDA) approach to address the data access problem [...] [aiming] at
solutions that reduce the cost of data access dramatically'' \cite{optique}.
Thus, the \name{OPTIQUE} project tries to reach exactly the benefits a
well-developed OBDA system can provide (explained in
Section~\ref{back_obda}):
an easy end-user access to data without knowing about its structuring
while taking advantage of automatic translations \cite{optique2}.
In doing so, ascertained shortcomings of existing OBDA systems were addressed:
\emph{usability} (for example the need to use formal query languages),
\emph{costly prerequisites} (consider, for example, the disadvantages
of materialized OBDA described in Section~\ref{back_obda}) and
\emph{efficiency} (which was perceived as being insufficiently addressed
in previous approaches) \cite{optique}.

\section{Related work}
\label{related}
\subsection{Ontologies and the semantic web -- publications}
\label{ontologies}

\subsection{OBDA specifications -- publications}
A publication building the foundation of the work presented in this thesis, is
the summarizing and benchmarking work on OBDA specifications by Skjæveland et al.
\cite{eng}, the group that developed them in their present form.

\subsection{OBDA systems -- publications}

\subsection{General ontology bootstrapping -- publications}
Skjæveland, Lian and Horrocks \cite{npd} provided an exemplifying description of
the transformation of the \emph{NPD FactPages}, an enormous collection of data
related to oil drilling on the Norwegian continental shelf, provided by
the Norwegian Petroleum Dictorate (NPD).

Sequeda et al. \cite{survey} provided an overview over different
direct mapping approaches.

Sequeda, Arenas and Miranker \cite{ondirm} \cite{autodirm}
describe the direct mapping of relational databases to \name{RDF}
and \name{OWL} formally.

Stojanovic, Stojanovic and Volz \cite{sac} published a formal description of
the mapping of relational databases onto ontology-based structures, describing
concepts preceding and/or supplementing \name{OWL} and using \name{F-LOGIC} TODO
as target language.

\subsection{The \name{OPTIQUE} project -- publications}
Calvanese et al. \cite{optique2} presented the \name{OPTIQUE} project including
its underlying OBDA system and showed limitations of current OBDA systems.

Kharlamov et al. \cite{optique} described the first version of the \name{OPTIQUE}
system, customized for use with the \emph{NPD FactPages} of the
Norwegian Petroleum Dictorate (NPD).

Skjæveland and Lian \cite{benefits} summarized the benefits of and the
proceeding for converting the \name{NPD FactPages} to linked data \cite{linked}
and discuss associated terms like linked data, URIs, \name{RDF} and
\name{SPARQL}.

\subsection{Alternative approaches -- publications}
Barrasa, Corcho and P{\'e}rez \cite{r2o} proposed a declarative mapping
language -- \name{r2o} -- able to express a mapping between a relational
database and ontologies represented in the \name{OWL} and \name{RDF} formats.
This approach however aims at connecting existing databases
and existing ontologies.

TODO: R2RML, SQL2SW