CommitLineData
c31df1ed 1\chapter{Introduction}
002fa020 2\label{intro}
c31df1ed
PM
3
4\section{Motivation}
002fa020 5\label{motivation}
c31df1ed
PM
6As estimated in 2007 \cite{deepweb}, publicly available databases contained
7up to 500 times more data than the static web and roughly 70 \% of all
8websites were backed by relational databases back then.
9As hardware has become cheaper yet more powerful, open source tools have
10become more and more widespread and the web has gotten more and more dynamic
11and interactive, it's likely that these numbers have even increased since then.
002fa020
PM
12This makes the publication of available data in a structured, machine-processable
13form and its retrieval with eligible software an interesting topic.
14The most important formalism to represent structured data without the need of
15a fixed (database) schema is ontologies, and thus this approach is known
16under the term Ontology based data access'' (OBDA'').
17The vision of a machine-processable web emerged as early as 1989 \cite{web}
18and was entitled with the term semantic web''
19by Tim Berners-Lee in 1999 \cite{weavingweb}.
20Definitely, the automatic translation of relational databases to \name{RDF}
21\cite{rdf} or similar representations of structured information is
c31df1ed
PM
22an integral part of the success of the semantic web \cite{deepweb}.
23This automatic translation process is commonly called bootstrapping''.
24
002fa020 25Today, the pure bootstrapping process is a relatively well understood topic,
c31df1ed
PM
26ranging from the rather simple direct mapping approach \cite{dirm} to TODO.
27On the other hand, the handling of the complexity introduced by these approaches
28and the use of sophisticated tools to perform various related tasks
29meanwhile has become a significant challenge in its own right \cite{eng}.
30Besides the parametrization of the tools in use, this includes the management of
31the several kinds of artifacts accruing during the process, possibly needed in
32different versions and formats for the use of different tools and output formats,
33while also taking changing input data into account \cite{eng}.
34Skjæveland and others therefore suggested an approach using a
35declarative description of the data to be mapped, concentrating in one place
36all the information needed to coordinate the bootstrapping process
37and to drive the entire tool chain \cite{eng}.
38
39\section{Approach}
002fa020 40\label{approach}
c31df1ed 41This thesis describes the development of a specification language to serialize
002fa020
PM
42the declarative specification of the bootstrapping process
43(see section \fullref{motivation}) and of a
c31df1ed
PM
44software to in turn bootstrap it from a relational database schema.
45After the tasks they accomplish,
46the specification language was called OBDA Specification Language'' (OSL'')
47and the software bootstrapping the specification was called db2osl''.
48
49Using a declarative specification makes the entire bootstrapping process a
002fa020
PM
50two-step-procedure, illustrated in figure \ref{intro_fig_bootstrapping}:
51First, the OBDA specification is derived from the
c31df1ed
PM
52database schema using \myprog{}.
53It specifies the actual bootstrapping process in a very general way,
54so it only has to be recreated when the database schema changes.
55The second step is to use the OBDA specification to coordinate and drive the
56actual bootstrapping process.
57The development of a software that uses the OBDA specification
58to perform this second step currently is subject to ongoing work.
59It will be able to be parameterized accordingly to support different output
60formats, tools, tool versions and application ranges.
002fa020
PM
61
62\begin{figure}[H]\begin{center}
63 \includegraphics[scale=0.9]{Images/bootstrapping_illustration.pdf}
64 \caption[Illustration of the overall
65 bootstrapping process]{Illustration of the overall
66 bootstrapping process using a declarative OBDA specification}
67 \label{intro_fig_bootstrapping}
68 \end{center}\end{figure}
c31df1ed
PM
69
70\section{Requirements and goals}
71The final system shall be able to cleanly fit into existing bootstrapping systems
72while being easy to use, taking the burden of dealing with \osl{} specifications
73manually from its users instead of adding even more complexity to the process.
002fa020 74To achieve these goals, use of existing tools, languages and conventions was
c31df1ed 75made wherever possible.
002fa020 76To fit into the environment used in the OPTIQUE project\cite{optique2} it is ultimately
28b54c67 77part of, \name{Java} was used for the bootstrapping software.
c31df1ed 78Care was taken to design it to be modular and flexible, making it
002fa020 79usable not only as a whole but also as a collection of independent components,
c31df1ed 80possibly serving as the basis for a program library in the future.
002fa020 81To achieve this aim and to make the software more easily
c31df1ed
PM
82understandable and extensible, it was documented carefully and thoroughly.
83
84As the software will be maintained by diverse people after its development and will
85likely be subject to changes, general code quality was also an issue to consider.
002fa020
PM
86Following good object-oriented software development practice \cite{str3},
87real world artifacts like database schemata, database tables, columns, keys,
88and OBDA specifications were modeled as software objects, provided with a
c31df1ed 89carefully chosen set of operations to manipulate them and make them collaborate.
002fa020
PM
90This approach and other actions aiming at yielding clean code are described more
91thoroughly in section \fullref{code}, while
92the resulting structure of the software is discussed in section \fullref{arch}.