Major change
authorPhilipp Martis <martispp@hspc26.informatik.uni-stuttgart.de>
Mon, 25 Apr 2016 13:21:23 +0000 (15:21 +0200)
committerPhilipp Martis <martispp@hspc26.informatik.uni-stuttgart.de>
Mon, 25 Apr 2016 13:21:23 +0000 (15:21 +0200)
The remaining bachelor thesis is included.
The OSL section is changed.

45 files changed:
Bachelor thesis.pdf [new file with mode: 0644]
Bachelor thesis.tex [new file with mode: 0644]
Images/inherit_graph_0.png [new file with mode: 0644]
Images/inherit_graph_1.png [new file with mode: 0644]
Images/inherit_graph_10.png [new file with mode: 0644]
Images/inherit_graph_11.png [new file with mode: 0644]
Images/inherit_graph_12.png [new file with mode: 0644]
Images/inherit_graph_13.png [new file with mode: 0644]
Images/inherit_graph_14.png [new file with mode: 0644]
Images/inherit_graph_15.png [new file with mode: 0644]
Images/inherit_graph_16.png [new file with mode: 0644]
Images/inherit_graph_17.png [new file with mode: 0644]
Images/inherit_graph_18.png [new file with mode: 0644]
Images/inherit_graph_19.png [new file with mode: 0644]
Images/inherit_graph_2.png [new file with mode: 0644]
Images/inherit_graph_20.png [new file with mode: 0644]
Images/inherit_graph_21.png [new file with mode: 0644]
Images/inherit_graph_22.png [new file with mode: 0644]
Images/inherit_graph_23.png [new file with mode: 0644]
Images/inherit_graph_3.png [new file with mode: 0644]
Images/inherit_graph_4.png [new file with mode: 0644]
Images/inherit_graph_5.png [new file with mode: 0644]
Images/inherit_graph_6.png [new file with mode: 0644]
Images/inherit_graph_7.png [new file with mode: 0644]
Images/inherit_graph_8.png [new file with mode: 0644]
Images/inherit_graph_9.png [new file with mode: 0644]
OSL-Specification.pdf
OSL-Specification.tex
abstract.tex [new file with mode: 0644]
appendix.tex [new file with mode: 0644]
background.tex [new file with mode: 0644]
bibliography.bib
introduction.tex [new file with mode: 0644]
kurzfassung.tex [new file with mode: 0644]
nomenclature.tex [new file with mode: 0644]
osl.tex
program.tex [new file with mode: 0644]
program_arch.tex [new file with mode: 0644]
program_code.tex [new file with mode: 0644]
program_functionality.tex [new file with mode: 0644]
program_interface.tex [new file with mode: 0644]
program_stats.tex [new file with mode: 0644]
program_tools.tex [new file with mode: 0644]
program_versioning.tex [new file with mode: 0644]
summary.tex [new file with mode: 0644]

diff --git a/Bachelor thesis.pdf b/Bachelor thesis.pdf
new file mode 100644 (file)
index 0000000..e7e8575
Binary files /dev/null and b/Bachelor thesis.pdf differ
diff --git a/Bachelor thesis.tex b/Bachelor thesis.tex
new file mode 100644 (file)
index 0000000..7052070
--- /dev/null
@@ -0,0 +1,198 @@
+%&latex
+% headsepline: Linie am oberen Blattrand unterhalb der Seitennummer
+% bibtotoc: Aufnahme des Literaturverzeichnisses ins Inhaltsverzeichnis
+%\documentclass[a4paper,headsepline,bibtotoc]{scrreprt}
+
+% Constants
+\newcommand{\mytitle}{Bootstrapping ontology-based data access specifications from
+       relational databases}
+\newcommand{\myprog}{\name{db2osl}}
+\newcommand{\osl}{\name{OSL}}
+\newcommand{\oslspec}{\osl{} specification}
+\newcommand{\myfontsize}{12pt}
+\newcommand{\smallerfontsize}{11pt}
+\newcommand{\smallfontsize}{10pt}
+\newcommand{\oslbaseurl}{\url{http://w3studi.informatik.uni-stuttgart.de/~martispp/ont\#}}
+\newcommand{\oslheaderurl}{\url{http://w3studi.informatik.uni-stuttgart.de/~martispp/ont/db2osl.owl}}
+%\newcommand{\spacebeforetable}{2em}
+\newcommand{\itm}{\textbullet \ }
+
+% New commands
+%\newcommand{\file}[1]{{\sffamily\slshape #1}}
+\newcommand{\file}[1]{\textsf{#1}}
+\newcommand{\name}[1]{\textsc{#1}}
+\newcommand{\sbr}[1]{\texttt{#1}}
+\newcommand{\var}[1]{\textsl{\texttt{#1}}}
+\newcommand{\cmd}[1]{\uppercase{\texttt{#1}}}
+\newcommand{\ind}{\hspace*{30pt}}
+\newcommand{\code}[1]{\texttt{#1}}
+\newcommand{\codepar}[1]{\begin{itemize}\item[]\code{#1}\end{itemize}\vspace{12pt}}
+\newcommand{\fullref}[1]{\ref{#1} -- \nameref{#1}}
+
+% Documentclass etc.
+\documentclass[\myfontsize,a4paper,twoside=semi]{scrreprt}
+\usepackage[utf8]{inputenc}
+\usepackage[T1]{fontenc}
+\usepackage{lmodern}
+\usepackage{color}
+
+% Einstellungen bez. des 'scrreprt'-Stils
+% Caption Schriftstil und -Groesse
+\renewcommand{\capfont}{\footnotesize}
+\renewcommand{\caplabelfont}{\footnotesize\bfseries}
+\typearea{15}  %Einstellung des Verh�ltnisses Gr��e des Textes zur Papiergr��e
+%\renewcommand{\familydefault}{\sfdefault}       % "moderne" Schrift
+%\renewcommand{\headfont}{\normalfont\sf}        % Kolumnentitel serifenlos
+%\renewcommand{\pnumfont}{\normalfont\sffamily}  % Seitennummern serifenlos
+
+% Sprache
+\usepackage[ngerman,english]{babel}
+\selectlanguage{english}
+\setlength{\parindent}{0pt}
+
+\addto\extrasgerman{\renewcommand{\figurename}{Abb.}}
+\addto\extrasgerman{\renewcommand{\tablename}{Tab.}}
+
+% Bilder
+\usepackage[rflt]{floatflt}
+\usepackage{epsfig,wrapfig}
+\usepackage{subcaption}
+\usepackage{float}
+
+% Mathematische Symbole
+\usepackage{amsmath,amssymb}
+
+% Tabellen
+\usepackage{longtable,lscape}
+\usepackage{multirow}
+\usepackage{tabularx}
+
+% Kopfzeilen
+\usepackage[automark,headsepline]{scrlayer-scrpage}
+\pagestyle{plain}
+\renewcommand{\chaptermark}[1]{\markboth{#1}{}}
+\renewcommand{\sectionmark}[1]{\markboth{\thesection\ #1}{}}
+\clearpairofpagestyles
+\cfoot[\pagemark]{\pagemark}
+\lehead{\headmark}
+\rohead{\headmark}
+\pagestyle{scrheadings}
+
+% Listenerscheinung
+\setlength{\itemsep}{0ex}
+\setlength{\parsep}{0ex}
+\setlength{\parskip}{2mm}
+
+% Biblatex
+\usepackage[style=alphabetic,maxnames=10,backref=true,backend=bibtex]{biblatex}
+\bibliography{bibliography}
+
+% Hyperref
+\usepackage[]{hyperref}
+\hypersetup{
+       unicode,
+       pdftitle={\mytitle{}},
+       pdfauthor={Philipp Martis},
+       pdfsubject={Ontology-based data access (OBDA)},
+       pdfkeywords={Ontology, Database, Database access, Big data},
+       pdfpagelayout=TwoPageRight,
+       linktoc=all,
+       colorlinks=true,
+       breaklinks=true,
+       extension=pdf,
+%      destlabel=true,
+%      allcolors=blue,
+       linkcolor=blue,
+       citecolor=green,
+       filecolor=cyan,
+       urlcolor=magenta,
+       pdfstartview=FitH,
+       pdfpagemode=UseOutlines,
+       bookmarksnumbered=true,
+       bookmarksopen=true,
+       bookmarksopenlevel=1
+}
+\usepackage{caption}  % Always link to the top of a figure or table
+
+
+\begin{document}
+
+% Seitennumerierung bis zum Beginn der Einleitung auf kleine roemische Zahlen setzen
+\pagenumbering{roman}
+
+% Title page
+\KOMAoption{fontsize}{\smallerfontsize{}}
+\title{\mytitle{}}
+
+\author{Bachelor thesis \\
+       by \\
+       stud.\ inf.\ Philipp Martis}
+
+\publishers{realized at the \\
+       Institute for Parallel and Distributed Systems, \\
+       University of Stuttgart \\[5ex]
+       Stuttgart, in May 2016}
+
+\date{}
+\maketitle
+\KOMAoption{fontsize}{\myfontsize{}}
+
+% Abstract
+\include{abstract}
+\addcontentsline{toc}{chapter}{Abstract}
+\include{kurzfassung}
+\addcontentsline{toc}{chapter}{Kurzfassung}
+
+% Contents
+\tableofcontents
+\addcontentsline{toc}{chapter}{Contents}
+
+%% Nomenclature
+%\addcontentsline{toc}{chapter}{Nomenclature}
+%\include{nomenclature}
+
+% List of figures
+\listoffigures
+\addcontentsline{toc}{chapter}{List of figures}
+
+% List of tables
+\listoftables
+\addcontentsline{toc}{chapter}{List of tables}
+
+\clearpage
+\pagestyle{plain}
+\renewcommand{\chaptermark}[1]{\markboth{#1}{}}
+\renewcommand{\sectionmark}[1]{\markboth{\thesection\ #1}{}}
+
+% Seitennumerierung ab der folgenden Einleitung auf arabische Zahlen setzen
+\pagenumbering{arabic}
+
+% Introduction
+\include{introduction}
+
+% Background
+\include{background}
+
+% The OBDA Specification Language (OSL)
+\include{osl}
+
+% The db2osl software
+\include{program}
+
+% Summary
+\include{summary}
+
+% Appendix
+\include{appendix}
+\addcontentsline{toc}{chapter}{Appendix}
+
+% Bibliography bibtex (add pagebackref=true to hyperref options if desired)
+%\bibliographystyle{alpha}
+%\bibliography{bibliography}
+%\addcontentsline{toc}{chapter}{Bibliography}
+
+% Bibliography biblatex
+\printbibliography
+\addcontentsline{toc}{chapter}{Bibliography}
+
+\end{document}
diff --git a/Images/inherit_graph_0.png b/Images/inherit_graph_0.png
new file mode 100644 (file)
index 0000000..f858560
Binary files /dev/null and b/Images/inherit_graph_0.png differ
diff --git a/Images/inherit_graph_1.png b/Images/inherit_graph_1.png
new file mode 100644 (file)
index 0000000..0c2afb0
Binary files /dev/null and b/Images/inherit_graph_1.png differ
diff --git a/Images/inherit_graph_10.png b/Images/inherit_graph_10.png
new file mode 100644 (file)
index 0000000..8bd2f81
Binary files /dev/null and b/Images/inherit_graph_10.png differ
diff --git a/Images/inherit_graph_11.png b/Images/inherit_graph_11.png
new file mode 100644 (file)
index 0000000..03987e8
Binary files /dev/null and b/Images/inherit_graph_11.png differ
diff --git a/Images/inherit_graph_12.png b/Images/inherit_graph_12.png
new file mode 100644 (file)
index 0000000..a896fb2
Binary files /dev/null and b/Images/inherit_graph_12.png differ
diff --git a/Images/inherit_graph_13.png b/Images/inherit_graph_13.png
new file mode 100644 (file)
index 0000000..2b3517e
Binary files /dev/null and b/Images/inherit_graph_13.png differ
diff --git a/Images/inherit_graph_14.png b/Images/inherit_graph_14.png
new file mode 100644 (file)
index 0000000..c99827e
Binary files /dev/null and b/Images/inherit_graph_14.png differ
diff --git a/Images/inherit_graph_15.png b/Images/inherit_graph_15.png
new file mode 100644 (file)
index 0000000..f7cefb1
Binary files /dev/null and b/Images/inherit_graph_15.png differ
diff --git a/Images/inherit_graph_16.png b/Images/inherit_graph_16.png
new file mode 100644 (file)
index 0000000..f505867
Binary files /dev/null and b/Images/inherit_graph_16.png differ
diff --git a/Images/inherit_graph_17.png b/Images/inherit_graph_17.png
new file mode 100644 (file)
index 0000000..4f781f6
Binary files /dev/null and b/Images/inherit_graph_17.png differ
diff --git a/Images/inherit_graph_18.png b/Images/inherit_graph_18.png
new file mode 100644 (file)
index 0000000..6c9cdd9
Binary files /dev/null and b/Images/inherit_graph_18.png differ
diff --git a/Images/inherit_graph_19.png b/Images/inherit_graph_19.png
new file mode 100644 (file)
index 0000000..042c0f1
Binary files /dev/null and b/Images/inherit_graph_19.png differ
diff --git a/Images/inherit_graph_2.png b/Images/inherit_graph_2.png
new file mode 100644 (file)
index 0000000..ca5b210
Binary files /dev/null and b/Images/inherit_graph_2.png differ
diff --git a/Images/inherit_graph_20.png b/Images/inherit_graph_20.png
new file mode 100644 (file)
index 0000000..00da99c
Binary files /dev/null and b/Images/inherit_graph_20.png differ
diff --git a/Images/inherit_graph_21.png b/Images/inherit_graph_21.png
new file mode 100644 (file)
index 0000000..a86f00e
Binary files /dev/null and b/Images/inherit_graph_21.png differ
diff --git a/Images/inherit_graph_22.png b/Images/inherit_graph_22.png
new file mode 100644 (file)
index 0000000..223c7ad
Binary files /dev/null and b/Images/inherit_graph_22.png differ
diff --git a/Images/inherit_graph_23.png b/Images/inherit_graph_23.png
new file mode 100644 (file)
index 0000000..402e20f
Binary files /dev/null and b/Images/inherit_graph_23.png differ
diff --git a/Images/inherit_graph_3.png b/Images/inherit_graph_3.png
new file mode 100644 (file)
index 0000000..f68bedf
Binary files /dev/null and b/Images/inherit_graph_3.png differ
diff --git a/Images/inherit_graph_4.png b/Images/inherit_graph_4.png
new file mode 100644 (file)
index 0000000..b51a5aa
Binary files /dev/null and b/Images/inherit_graph_4.png differ
diff --git a/Images/inherit_graph_5.png b/Images/inherit_graph_5.png
new file mode 100644 (file)
index 0000000..9a842da
Binary files /dev/null and b/Images/inherit_graph_5.png differ
diff --git a/Images/inherit_graph_6.png b/Images/inherit_graph_6.png
new file mode 100644 (file)
index 0000000..87bfb63
Binary files /dev/null and b/Images/inherit_graph_6.png differ
diff --git a/Images/inherit_graph_7.png b/Images/inherit_graph_7.png
new file mode 100644 (file)
index 0000000..a44762f
Binary files /dev/null and b/Images/inherit_graph_7.png differ
diff --git a/Images/inherit_graph_8.png b/Images/inherit_graph_8.png
new file mode 100644 (file)
index 0000000..adce2bf
Binary files /dev/null and b/Images/inherit_graph_8.png differ
diff --git a/Images/inherit_graph_9.png b/Images/inherit_graph_9.png
new file mode 100644 (file)
index 0000000..790b5cf
Binary files /dev/null and b/Images/inherit_graph_9.png differ
index 5aa9507..f70588b 100644 (file)
Binary files a/OSL-Specification.pdf and b/OSL-Specification.pdf differ
index 3d5654a..0b3bb4b 100644 (file)
@@ -4,13 +4,30 @@
 %\documentclass[a4paper,headsepline,bibtotoc]{scrreprt}
 
 % Constants
-\newcommand{\mytitle}{OBDA Specification Language (OSL)\\Specification}
+\newcommand{\mytitle}{OBDA Specification Language (OSL)\\
+       Specification}
+\newcommand{\myprog}{\name{db2osl}}
+\newcommand{\osl}{\name{OSL}}
+\newcommand{\oslspec}{\osl{} specification}
 \newcommand{\myfontsize}{12pt}
 \newcommand{\smallerfontsize}{11pt}
 \newcommand{\smallfontsize}{10pt}
-\newcommand{\oslbase}{\url{http://w3studi.informatik.uni-stuttgart.de/~martispp/ont\#}}
-\newcommand{\oslheader}{\url{http://w3studi.informatik.uni-stuttgart.de/~martispp/ont/db2osl.owl}}
-\newcommand{\spacebeforetable}{2em}
+\newcommand{\oslbaseurl}{\url{http://w3studi.informatik.uni-stuttgart.de/~martispp/ont\#}}
+\newcommand{\oslheaderurl}{\url{http://w3studi.informatik.uni-stuttgart.de/~martispp/ont/db2osl.owl}}
+%\newcommand{\spacebeforetable}{2em}
+\newcommand{\itm}{\textbullet \ }
+
+% New commands
+%\newcommand{\file}[1]{{\sffamily\slshape #1}}
+\newcommand{\file}[1]{\textsf{#1}}
+\newcommand{\name}[1]{\textsc{#1}}
+\newcommand{\sbr}[1]{\texttt{#1}}
+\newcommand{\var}[1]{\textsl{\texttt{#1}}}
+\newcommand{\cmd}[1]{\uppercase{\texttt{#1}}}
+\newcommand{\ind}{\hspace*{30pt}}
+\newcommand{\code}[1]{\texttt{#1}}
+\newcommand{\codepar}[1]{\begin{itemize}\item[]\code{#1}\end{itemize}\vspace{12pt}}
+\newcommand{\fullref}[1]{\ref{#1} -- \nameref{#1}}
 
 % Documentclass etc.
 \documentclass[\myfontsize,a4paper,twoside=semi]{scrreprt}
@@ -39,6 +56,8 @@
 % Bilder
 \usepackage[rflt]{floatflt}
 \usepackage{epsfig,wrapfig}
+\usepackage{subcaption}
+\usepackage{float}
 
 % Mathematische Symbole
 \usepackage{amsmath,amssymb}
 \setlength{\parskip}{2mm}
 
 % Biblatex
-\usepackage[style=alphabetic,maxnames=10,backref=true]{biblatex}
+\usepackage[style=alphabetic,maxnames=10,backref=true,backend=bibtex]{biblatex}
 \bibliography{bibliography}
 
 % Hyperref
 \usepackage[]{hyperref}
 \hypersetup{
        unicode,
-       pdftitle={\mytitle},
+       pdftitle={\mytitle{}},
        pdfauthor={Logic and Intelligent Data research group, University of Oslo},
        pdfsubject={Ontology-based data access (OBDA)},
        pdfkeywords={Ontology, Database, Database access, Big data},
 }
 \usepackage{caption}  % Always link to the top of a figure or table
 
+
 \begin{document}
 
 % Seitennumerierung bis zum Beginn der Einleitung auf kleine roemische Zahlen setzen
 \pagenumbering{roman}
 
-% new commands
-%\newcommand{\file}[1]{{\sffamily\slshape #1}}
-\newcommand{\file}[1]{\mdseries\textsl{\textsf{#1}}}
-\newcommand{\sbr}[1]{\texttt{#1}}
-\newcommand{\var}[1]{\mdseries\textsl{\texttt{#1}}}
-\newcommand{\cmd}[1]{\uppercase{\texttt{#1}}}
-
 % Title page
-\KOMAoption{fontsize}{\smallerfontsize}
-\title{\mytitle}
+\KOMAoption{fontsize}{\smallerfontsize{}}
+\title{\mytitle{}}
 
 \author{}
 
 
 \date{}
 \maketitle
-\KOMAoption{fontsize}{\myfontsize}
+\KOMAoption{fontsize}{\myfontsize{}}
 
 %% Abstract
-%\clearpage
 %\include{abstract}
 %\addcontentsline{toc}{chapter}{Abstract}
 %\include{kurzfassung}
 %\addcontentsline{toc}{chapter}{Contents}
 
 %% Nomenclature
-%\clearpage
 %\addcontentsline{toc}{chapter}{Nomenclature}
 %\include{nomenclature}
 
 \pagenumbering{arabic}
 
 %% Introduction
-%\clearpage
 %\include{introduction}
 
 %% Background
-%\clearpage
 %\include{background}
 
-% The OSL language
-\clearpage
+% The OBDA Specification Language (OSL)
 \include{osl}
 
+%% The db2osl software
+%\include{program}
 
 %% Summary
-%\clearpage
 %\include{summary}
 
 %% Appendix
-%\clearpage
 %\include{appendix}
 %\addcontentsline{toc}{chapter}{Appendix}
 
 \printbibliography
 \addcontentsline{toc}{chapter}{Bibliography}
 
-
 \end{document}
diff --git a/abstract.tex b/abstract.tex
new file mode 100644 (file)
index 0000000..15377dc
--- /dev/null
@@ -0,0 +1,3 @@
+\chapter*{Abstract}
+Nach der Titelseite des Berichtes und dem Aufgabenblatt soll das Wesentliche aus dem Inhalt der Arbeit in
+wenigen Sätzen zusammengefasst werden. Diese Übersicht soll keine Formeln und möglichst keine Literaturhinweise enthalten.
diff --git a/appendix.tex b/appendix.tex
new file mode 100644 (file)
index 0000000..1282700
--- /dev/null
@@ -0,0 +1,4 @@
+\chapter*{Appendix}
+Hierher gehören zur Dokumentation Tabellen, Messprotokolle,
+Rechnerprotokolle, Konstruktionszeichnungen, kurze Programmausdrucke
+und Ähnliches.
diff --git a/background.tex b/background.tex
new file mode 100644 (file)
index 0000000..7c9a025
--- /dev/null
@@ -0,0 +1,18 @@
+\chapter{Background and related work}
+Bei experimentellen Untersuchungen sind die benutzte Versuchsanordnung
+sowie Messanordnungen und Messverfahren ausführlich zu
+beschreiben. Analog sind die Grundlagen eventuell verwendeter oder
+erweiterter Berechnungsprogramme zusammenfassend darzustellen. Bei
+übernommenen Formeln, Bildern, Tabellen und bei Zitaten ist stets die
+Quelle durch den Namen des Verfassers und die zugehörige Nummer im
+Literaturverzeichnis anzugeben (z.B. \cite{eng})
+
+Nam eu dolor a nisl faucibus suscipit. Nulla interdum sapien id lectus. Curabitur fringilla pulvinar nibh. Aenean porta luctus purus. Cras dictum mauris quis velit. Nullam pharetra pede at risus. Nullam orci sapien, porttitor eu, iaculis et, bibendum ultricies, ipsum. Mauris eget justo. Donec semper auctor tortor. Mauris a ante et magna facilisis mollis. Proin sem turpis, interdum quis, fermentum aliquet, faucibus scelerisque, quam. In mi nibh, facilisis eu, euismod sed, luctus ut, sapien. Etiam ut dui eget libero dapibus elementum.
+
+Nulla ut felis et libero tempus luctus. Praesent vitae velit. Vivamus pharetra pharetra sem. Morbi id mauris. Ut sem mauris, fermentum non, interdum eu, nonummy non, nunc. Aenean a sem et odio ornare dictum. Phasellus fermentum justo quis justo. Aenean et felis. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Curabitur faucibus ornare augue. Nullam blandit pellentesque odio. Vestibulum tempor tempor ante. Etiam scelerisque elementum diam. Vestibulum enim sem, dictum et, rhoncus vitae, ullamcorper ut, dolor. Sed diam.
+
+Sed dignissim diam vel erat. Pellentesque ac lacus sed dui vehicula tristique. Curabitur justo sapien, convallis in, faucibus nec, hendrerit eu, sapien. Quisque imperdiet lacus vitae lacus. Vestibulum aliquet rutrum enim. Fusce et leo. Ut id dui non felis rhoncus laoreet. Nullam ipsum. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Cras et dolor. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
+
+
+\section{Background}
+\section{Related work}
index 215ff88..a4a7dc3 100644 (file)
        note           = {[Accessed: 2016-04-02]}\r
 }\r
 \r
+@misc{dirm,\r
+       shorthand      = {W3C12},\r
+       author         = {TODO},\r
+       title          = {A Direct Mapping of Relational Data to RDF},\r
+       year           = 2012,\r
+       howpublished   = {\url{https://www.w3.org/TR/rdb-direct-mapping/}},\r
+       note           = {[Accessed: 2016-04-06]}\r
+}\r
+\r
 @article{deepweb,\r
        author         = {He, Bin and Patel, Mitesh and Zhang, Zhen and Chang, Kevin Chen-Chuan},\r
        title          = {Accessing the deep web.},\r
@@ -56,6 +65,7 @@
        volume         = 50,\r
        year           = 2007\r
 }\r
+\r
 @article{thesemanticweb,\r
        author         = {Berners-Lee, Tim and Hendler, James and Lassila, Ora},\r
        title          = {The Semantic Web},\r
diff --git a/introduction.tex b/introduction.tex
new file mode 100644 (file)
index 0000000..18a17b2
--- /dev/null
@@ -0,0 +1,85 @@
+\chapter{Introduction}
+Sie führt in die Problematik ein, skizziert die Motivation und
+Zielsetzung sowie das geplante Vorgehen und die angestrebten
+Ergebnisse und sollte ca. 1 - 2 Seiten umfassen.\\
+
+\section{Motivation}
+As estimated in 2007 \cite{deepweb}, publicly available databases contained
+up to 500 times more data than the static web and roughly 70 \% of all
+websites were backed by relational databases back then.
+As hardware has become cheaper yet more powerful, open source tools have
+become more and more widespread and the web has gotten more and more dynamic
+and interactive, it's likely that these numbers have even increased since then.
+This makes the publication of available data in a structured,
+machine-processable form
+and its retrieval with eligible software (Ontology based data access, OBDA)
+an interesting topic.
+This vision emerged as early as TODO and was entitled with the term ``semantic web''
+by Tim Berners-Lee \cite{thesemanticweb}.
+Definitely, the automatic translation of relational databases to RDF
+or similar representations of structured information is
+an integral part of the success of the semantic web \cite{deepweb}.
+This automatic translation process is commonly called ``bootstrapping''.
+
+Early work regarding the development of bootstrapping systems includes TODO.
+Today, the pure translation process is a relatively well understood topic,
+ranging from the rather simple direct mapping approach \cite{dirm} to TODO.
+On the other hand, the handling of the complexity introduced by these approaches
+and the use of sophisticated tools to perform various related tasks
+meanwhile has become a significant challenge in its own right \cite{eng}.
+Besides the parametrization of the tools in use, this includes the management of
+the several kinds of artifacts accruing during the process, possibly needed in
+different versions and formats for the use of different tools and output formats,
+while also taking changing input data into account \cite{eng}.
+Skjæveland and others therefore suggested an approach using a
+declarative description of the data to be mapped, concentrating in one place
+all the information needed to coordinate the bootstrapping process
+and to drive the entire tool chain \cite{eng}.
+
+\section{Approach}
+This thesis describes the development of a specification language to serialize
+the declarative specification of the bootstrapping process and of a
+software to in turn bootstrap it from a relational database schema.
+After the tasks they accomplish,
+the specification language was called ``OBDA Specification Language'' (``OSL'')
+and the software bootstrapping the specification was called ``db2osl''.
+
+Using a declarative specification makes the entire bootstrapping process a
+two-step-procedure: First, the OBDA specification is derived from the
+database schema using \myprog{}.
+It specifies the actual bootstrapping process in a very general way,
+so it only has to be recreated when the database schema changes.
+The second step is to use the OBDA specification to coordinate and drive the
+actual bootstrapping process.
+The development of a software that uses the OBDA specification
+to perform this second step currently is subject to ongoing work.
+It will be able to be parameterized accordingly to support different output
+formats, tools, tool versions and application ranges.
+\\\\TODO: illustration of overall process
+
+\section{Requirements and goals}
+The final system shall be able to cleanly fit into existing bootstrapping systems
+while being easy to use, taking the burden of dealing with \osl{} specifications
+manually from its users instead of adding even more complexity to the process.
+To achieve the former goal, use of existing tools, languages and conventions was
+made wherever possible.
+To fit into the environment used in the OPTIQUE project TODO it is ultimately
+part of, Java was used for the bootstrapping software.
+Care was taken to design it to be modular and flexible, making it
+usable not only as a whole but also as a collection of independent components
+possibly serving as the basis for a program library in the future.
+To further support this aim TODO and to make the software more easily
+understandable and extensible, it was documented carefully and thoroughly.
+
+As the software will be maintained by diverse people after its development and will
+likely be subject to changes, general code quality was also an issue to consider.
+Following good object-oriented software development practice TODO,
+real world artifacts like database schemas, database tables, columns, keys,
+OBDA specifications et cetera were modeled as software objects, provided with a
+carefully chosen set of operations to manipulate them and make them collaborate.
+Scarce, informative comments were inserted at places of higher complexity and to
+expose logical subdivisions, but care was taken to use ``speaking code'' in favor
+of rampant comments.
+Complex, misleading and hard-to-use interfaces were avoided wherever possible.
+External software libraries employed were chosen to be stable, specific,
+well structured, publicly available and ideally in wide use.
diff --git a/kurzfassung.tex b/kurzfassung.tex
new file mode 100644 (file)
index 0000000..026846f
--- /dev/null
@@ -0,0 +1,5 @@
+\begin{otherlanguage}{ngerman}
+\chapter*{Kurzfassung}
+Nach der Titelseite des Berichtes und dem Aufgabenblatt soll das Wesentliche aus dem Inhalt der Arbeit in
+wenigen S"atzen zusammengefasst werden. Diese "`Übersicht"' soll keine Formeln und m"oglichst keine Literaturhinweise enthalten.
+\end{otherlanguage}
diff --git a/nomenclature.tex b/nomenclature.tex
new file mode 100644 (file)
index 0000000..d570a4d
--- /dev/null
@@ -0,0 +1,42 @@
+\newpage
+\chapter*{Nomenklatur}
+\begin{tabular}{lll}
+       \vspace{1mm}
+       $a_i$            & [-]            & Polynomkoeffizient \\
+       \vspace{1mm}
+       $c_f$            & [-]            & Reibungswiderstandsbeiwert der
+turbulent umstr"omten ebenen Platte \\
+       \vspace{1mm}
+       $c_{w_V}$        & [-]            & volumenbezogener
+Widerstandsbeiwert \\
+       \vspace{1mm}
+       $D$              & [m]             & Durchmesser \\
+       \vspace{1mm}
+       $L$              & [m]            & K"orperl"ange \\
+       \vspace{1mm}
+       $n_{krit.}$      & [-]            & kritischer Anfachungsfaktor
+(relevant f"ur die Umschlagsberechnung) \\
+       \vspace{1mm}
+       $Re_L$           & [-]            & l"angenbezogene Reynoldszahl \\
+       \vspace{1mm}
+       $Re_V$           & [-]            & volumenbezogene Reynoldszahl \\
+       \vspace{1mm}
+       $r$              & [m]            & Radius \\
+       \vspace{1mm}
+       $U_{\infty}$     & [$m/s$]        & Anstr"omgeschwindigkeit \\
+       \vspace{1mm}
+       $V$              & [$m^3$]        & Volumen \\
+       \vspace{1mm}
+       $W$              & [$N$]          & Widerstand \\
+       \vspace{1mm}
+       $x, y, z$        & [m]            & kartesische Koordinaten \\
+
+
+       \vspace{1mm}
+       $\alpha$        & [$^{\circ}$] & Anstellwinkel \\
+       \vspace{1mm}
+       $\nu$           & [$m^2/s$]    & kinematische Viskosit"at des
+Str"omungsmediums \\
+       \vspace{1mm}
+       $\rho$          & [$kg/m^3$]   & Dichte des Str"omungsmediums \\
+\end{tabular}
diff --git a/osl.tex b/osl.tex
index e87c79e..b2f56af 100644 (file)
--- a/osl.tex
+++ b/osl.tex
@@ -1,58 +1,61 @@
-\chapter{The OSL language}
+\chapter{The OBDA Specification Language (OSL)}
+\label{osl}
 
 As described in \cite{eng}, an OBDA specification consists of several types of maps,
 all containing data entries and links to other maps.
 This fits perfectly into the environment of ontologies and OWL, with data properties
-being the obvious thing to represent contained data entries and object properties being
-the obvious thing to represent links between maps.
+being the obvious choice to represent contained data entries and object properties being
+the obvious choice to represent links between maps.
 Also, a potential user probably to some degree is familiar with this environment,
 since this is what the bootstrapping process at the end amounts to.
 
-So an ideal base for the OBDA Specification Language is OWL,
+Therefore, an ideal base for the OBDA Specification Language is OWL,
 being a solid framework for data and constraint representation
 with a high degree of software support,
 while imposing only a minimum of introductory preparation to the user.
 
 Another advantage of this approach is that the specification is kept
-compact and focused on the entities the language has to represent rather than
+compact and focused on the entities that the language has to represent rather than
 primarily dealing with technical details.
 In particular, many of those details can be formulated as OWL restrictions
 in a header ontology demanded to be imported by documents conforming
-to the OSL specification.
-Thus, they are not only specified precisely but also in a machine-readable form
-for which tools are widely available, enabling the user to check many aspects of
-an OSL document for conformance with minimum effort.
+to the \osl{} specification.
+Thus, they are not only specified precisely but they are also stipulated in a
+machine-readable form for which tools are widely available, enabling the user to check
+many aspects of an \osl{} document for conformity with minimal effort.
 
 \section{Specification}
-
+\label{oslspec}
 \newcounter{parcount}
 \newcommand{\parnum}{\textsuperscript{\arabic{parcount}}}
 \newcommand{\p}{\refstepcounter{parcount} \parnum \hspace{1em}}
 
-\p An OSL document is a valid OWL 2 document \cite{owl} containing individuals
-and data representing the OBDA Specification, as well as OWL properties connecting them.
+\p An \osl{} document is a valid OWL 2 document (as described in \cite{owl})
+containing individuals and data that represent the OBDA Specification,
+as well as OWL properties that connect them.
 The individuals and OWL properties are recognized and mapped to their roles by their IRIs.
 
-\p\label{spec_ignored} An OSL document may contain more OWL entities
+\p\label{spec_ignored} An \osl{} document may contain more OWL entities
 (with IRIs not defined in this specification), which are ignored.
 
-\p An OSL document has to declare all individuals having different IRIs as different
+\p An \osl{} document has to declare all individuals having different IRIs as different
 from each other (except those which are ignored, see paragraph \ref{spec_ignored}).\\
-It's recommended to use the \texttt{owl:AllDifferent} OWL statement for this purpose.
+It is recommended to use the \texttt{owl:AllDifferent} OWL statement for this purpose.
 
 \p\label{spec_base} Unless stated otherwise, IRIs mentioned in the following are IRIs relative
 to a base IRI chosen by the user being empty (which makes the IRIs absolute \cite{xmlbase})
 or ending with a hash character (`\#').\\
-It's recommended to use that base IRI as \texttt{xml:base} XML attribute.\\
+\newpage
+It is recommended to use that base IRI as \texttt{xml:base} XML attribute.\\
 IRIs prefixed with \texttt{osl:} are IRIs relative to the IRI\\
-\oslbase
+\oslbaseurl{}\;.
 
-\newpage
-\p An OSL document has to import the following ontology
-(referred to as ``the OSL header'' in the following):\\
-\oslheader
+%\newpage
+\p An \osl{} document has to import the following ontology
+(referred to as ``the \osl{} header'' in the following):\\
+\oslheaderurl{}
 
-\p The OWL individuals described by the OSL document representing the certain types of OBDA maps
+\p The OWL individuals described by the \osl{} document representing the certain types of OBDA maps
 must have the IRIs specified in table \ref{spec_tbl_indv_iris}
 (for base IRIs, see paragraph \ref{spec_base}).
 Here, \textit{$<$class URI$>$} refers\\
@@ -64,14 +67,14 @@ to the \texttt{OWL class URI} field of the entity map associated with the respec
 for translation tables of subtype maps.\\
 Similarly, \textit{$<$property URI$>$} refers\\
 to the \texttt{OWL property URI} field of the respective attribute map for attribute maps
-(or, if it is empty, the value that would have been generated for it if it wouldn't ought to be empty),\\
+(or, if it is empty, the value that would have been generated for it if it weren't empty),\\
 to the \texttt{OWL property URI} field of the respective relation map for relation maps and\\
 to the \texttt{OWL property URI} field of the respective attribute map
 for translation tables of attribute maps (or, if it is empty, the value that would have
-been generated for it if it wouldn't ought to be empty).
+been generated for it if it weren't empty).
 
-%\vspace{\spacebeforetable}
-\KOMAoption{fontsize}{\smallerfontsize}
+%\vspace{\spacebeforetable{}}
+\KOMAoption{fontsize}{\smallerfontsize{}}
 \begin{table}[]\begin{center}
        \begin{tabular}{l|l}
                \textbf{Map type} & \textbf{OWL IRI} \\ \hline
@@ -85,16 +88,16 @@ been generated for it if it wouldn't ought to be empty).
                Translation table of subtype map &
                        \textit{$<$class URI$>$}\texttt{\_\_SUBTYPE\_MAP\_\_TRANSLATION\_TABLE} \\
        \end{tabular}
-       \caption{OWL individual IRIs in OSL}
+       \caption{OWL individual IRIs in \osl{}}
        \label{spec_tbl_indv_iris}
 \end{center}\end{table}
-\KOMAoption{fontsize}{\myfontsize}
+\KOMAoption{fontsize}{\myfontsize{}}
 
-\p The OWL individuals described by the OSL document representing the certain types of OBDA maps
+\p The OWL individuals described by the \osl{} document representing the certain types of OBDA maps
 must be of the OWL types specified in table \ref{spec_tbl_types}
 (for base IRIs, see paragraph \ref{spec_base}).
 
-%\vspace{\spacebeforetable}
+%\vspace{\spacebeforetable{}}
 \begin{table}[]\begin{center}
                \begin{tabular}{l|l}
                        \textbf{Map type} & \textbf{OWL class IRI} \\ \hline
@@ -105,16 +108,16 @@ must be of the OWL types specified in table \ref{spec_tbl_types}
                        Subtype map & \texttt{osl:SubtypeMap} \\
                        Translation table & \texttt{osl:TranslationTable} \\
                \end{tabular}
-               \caption{Class membership of map representations in OSL}
+               \caption{Class membership of map representations in \osl{}}
                \label{spec_tbl_types}
 \end{center}\end{table}
 
-\p The OWL properties described by the OSL document representing the fields of the certain OBDA maps
+\p The OWL properties described by the \osl{} document representing the fields of the certain OBDA maps
 must have the IRIs specified in table \ref{spec_tbl_prop_iris}
 (for base IRIs, see paragraph \ref{spec_base}).
 
-%\vspace{\spacebeforetable}
-%\KOMAoption{fontsize}{\smallerfontsize}
+%\vspace{\spacebeforetable{}}
+%\KOMAoption{fontsize}{\smallerfontsize{}}
 \begin{table}[]\begin{center}
                \begin{tabular}{l|l|l|l}
                        \textbf{Map type} & \textbf{Field label} & \textbf{Field name} & \textbf{OWL IRI} \\ \hline
@@ -156,21 +159,21 @@ must have the IRIs specified in table \ref{spec_tbl_prop_iris}
                        Translation table & \texttt{T2} & \texttt{RDF ressource...} &
                                \texttt{osl:tt\_\_rdfRessource\textcolor{red}{\textbf{s}}} \\
                \end{tabular}
-               \caption{OWL property IRIs in OSL}
+               \caption{OWL property IRIs in \osl{}}
                \label{spec_tbl_prop_iris}
 \end{center}\end{table}
-%\KOMAoption{fontsize}{\myfontsize}
+%\KOMAoption{fontsize}{\myfontsize{}}
 
-\newpage
-\p The following OWL properties in the OSL document refer to lists of elements:
+%\newpage
+\p The following OWL properties in the \osl{} document refer to lists of elements:
 \begin{itemize}
        \item[] \texttt{osl:rm\_\_sourceColumns}
        \item[] \texttt{osl:rm\_\_targetColumns}
        \item[] \texttt{osl:tt\_\_sourceValues}
        \item[] \texttt{osl:tt\_\_rdfRessources}
 \end{itemize}
-Therefore, they have the OWL class \texttt{osl:StringListNode} as range,
-as required by the OSL header.
+Therefore, they have the OWL class \texttt{osl:StringListNode} as their range,
+as is required by the \osl{} header.
 They must connect the respective individual to an
 \texttt{osl:StringListNode} individual in every case.
 This ``root node'' must \emph{not} have an \texttt{osl:hasValue} property.\\
@@ -181,4 +184,6 @@ The node representing the last list element must not have an
 \texttt{osl:nextNode} property.\\
 All nodes except the root node \emph{may} have an \texttt{osl:hasValue} property
 connecting them to their values.
-It's recommended to enumerate the node IRIs, using $0$ for the root node.
+The actual list consists of exactly these values, thus, nodes without values
+are ignored.\\
+It is recommended to enumerate the node IRIs, using $0$ for the root node.
diff --git a/program.tex b/program.tex
new file mode 100644 (file)
index 0000000..020820d
--- /dev/null
@@ -0,0 +1,38 @@
+\chapter{The db2osl software}
+Besides the conception of the  ``OBDA Specification Language'' (\osl{}), the design
+and implementation of the \myprog{} software was an important part of this work.
+The program itself and its creation process are described in the following sections:
+Section \fullref{functionality} describes the functionality the program offers.
+Section \fullref{interface} describes how this functionality is exposed to the
+program environment.
+Section \fullref{tools} explains what tools where used to create the program.
+Section \fullref{arch} describes the program architecture both on a coarse and
+a fine level.
+Section \fullref{code} describes concepts and decisions that where implemented
+on the code level to yield clean code.
+Section \fullref{stats} mentions some figures about the program.
+Section \fullref{versioning} gives a brief timewise TODO overview over the program
+development and describes important milestones.
+
+Except the last section, this chapters' sections present the information in a
+functionally-structured fashion: the concepts and decisions are described along with
+the topics they are linked to and the problems that made them arise.
+However, the last section, besides giving an overview about the program versions,
+tries to give an insight about development succession.
+
+Unless stated differently, program version $1.0$ is described
+(for details, see section \fullref{versioning}).
+
+\input{program_functionality}
+
+\input{program_interface}
+
+\input{program_tools}
+
+\input{program_arch}
+
+\input{program_code}
+
+\input{program_stats}
+
+\input{program_versioning}
diff --git a/program_arch.tex b/program_arch.tex
new file mode 100644 (file)
index 0000000..5c5561f
--- /dev/null
@@ -0,0 +1,83 @@
+\section{Architecture}
+\label{arch}
+\subsection{Libraries used}
+\subsection{Coarse structuring}
+TODO: overall description, modularity, extendability, ex: easy to add new in-/output formats
+TODO: mapping profiles (maybe better in next subsection)
+TODO: package description
+TODO: package interaction description
+
+\subsection{Fine structuring}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_8.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_7.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_5.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_19.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_1.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_17.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_21.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_13.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_3.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_18.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_12.png}
+\end{center}\end{figure}
+\begin{figure}[H]\begin{center}
+               \ContinuedFloat*
+               \includegraphics[scale=0.86]{Images/inherit_graph_4.png}
+               \setcounter{figure}{1}
+               \caption{Class hierarchies in \myprog{}}
+               \label{arch_fig_inheritance}
+\end{center}\end{figure}
+
+
+\begin{table}[H]\begin{center}
+               \begin{tabular}{l}
+                       \itm{} \code{main.Main}\\
+                       \itm{} \code{database.Helpers}\\
+                       \itm{} \code{database.RetrieveDBSchema}\\
+                       \itm{} \code{database.SQLType}\\
+                       \itm{} \code{database.Table}\\
+                       \itm{} \code{specification.OBDASpecification}\\
+                       \itm{} \code{osl.OSLSpecification}\\
+                       \itm{} \code{bootstrapping.Bootstrapping}\\
+                       \itm{} \code{cli.CLIDatabaseInteraction}\\
+                       \itm{} \code{log.GlobalLogger}\\
+                       \itm{} \code{test.CreateTestDBSchema}\\
+                       \itm{} \code{test.GetSomeDBSchema}\\
+               \end{tabular}\\
+       \caption{Standalone classes in \myprog{}}
+       \label{arch_tbl_classes}
+\end{center}\end{table}
+
+%For more information about the program structure on the class level, see section \fullref{code}.
diff --git a/program_code.tex b/program_code.tex
new file mode 100644 (file)
index 0000000..223d7a7
--- /dev/null
@@ -0,0 +1,273 @@
+\section{Code style}
+\label{code}
+TODO: Conventions, ex.: iterators
+As the final system hopefully will have a long living cycle TODO
+and will be used and refined by many people, high code quality was an important aim.
+Beyond architectural issues this also involves cleanness on the lower level,
+like the design of classes and the implementation of methods.
+Common software development principles were followed TODO and
+the unfamiliar reader was constantly taken into account
+to yield clean, usable and readable code.
+
+\subsection{Comments}
+\label{comments}
+Comments were used at places ambiguities or misinterpretations could arise,
+yet care was taken to face such problems at their roots and solve them
+wherever possible instead of just eliminating the ambiguity with comments.
+
+Consider the following method in \file{CLIDatabaseInteraction.java}:
+\codepar{public static void promptAbortRetrieveDBSchemaAndWait\\
+       \ind(final FutureTask<DBSchema> retriever) throws SQLException}
+
+It could have been called \code{promptAbortRetrieveDBSchema} only, with the
+waiting mentioned in a comment.
+However, the waiting is such an important part of its behavior, that this
+wouldn't have been enough, so the waiting was included in the function name.
+Since the method is called at one place only, the lengthening of the method
+name by 7 characters or about 26 \% is really not a problem.
+
+More generally, ``speaking code'' was used wherever possible,
+as described in section \fullref{speaking},
+which rendered many uses of comments unnecessary.
+In fact, the number of (plain, e.g. non-Javadoc) comments was consciously minimized,
+to enforce speaking code and avoid redundancy.
+This technique is known TODO.
+
+An exception of course from this is the highlighting of subdivisions.
+In class and method implementations, comments like
+\codepar{//********************** Constructors **********************TODO}
+
+were deliberately used to ease navigation inside source files for unfamiliar
+readers, but also to enhance readability: independent parts of method
+implementations, for example, were optically separated this way.
+Another alternative would have been to use separate methods for this code
+pieces, as was done in other cases, but this would then have introduced
+additional artifacts with either long or non-speaking names.
+Additionally, it would have increased complexity, because these methods
+would have been callable at least from everywhere in the source file,
+and would have interrupted the reading flow.
+This technique is known TODO, while TODO
+
+Wherever possible, appropriate Javadoc comments were used in favor of
+plain comments, for example to specify parameters, return types, exceptions
+and links to other parts of the documentation.
+
+\subsection{Speaking code}
+\label{speaking}
+As mentioned in section \fullref{comments}, the use of ``speaking code'' as
+introduced TODO
+renders many uses of comments unnecessary.
+In particular, the following aspects are commonly considered when referring to
+the term ``speaking code'' TODO:
+
+\begin{itemize}
+       \item Variable names
+       \item Control flow
+\end{itemize}
+
+\subsubsection{Variable names}
+A very important part of speaking code 
+
+\subsection{Robustness against incorrect use}
+Care was taken to produce code that is robust to incorrect use, making it
+suitable for the expected environment of sporadic updates by unfamiliar and
+potentially even unpracticed programmers who very likely have their emphasis
+on the concepts of bootstrapping rather than details of the present code.
+
+In fact, carefully avoiding the introduction of technical artifacts to mind,
+preventing programmers from focusing on the actual program logic,
+is an important principle of writing clean code TODO.
+
+In modern programming languages, of course the main instruments for achieving
+this are the type system and exceptions.
+In particular, static type information should be used to reflect data
+abstraction and the ``kind'' of data, an object reflects,
+while dynamic type information should only be used implicitly,
+through dynamically dispatching method invocations\cite{str4}.
+Exceptions on the other hand should be used at any place related to errors
+and error handling, separating error handling noticeably from other code and
+enforcing the treatment of errors, preventing the programmer from using
+corrupted information in many cases.
+
+An example of both mechanism, static type information and exceptions, acting
+in combination, while cleanly fitting into the context of dynamic dispatching,
+are the following methods from \file{Column.java}:
+\codepar{public Boolean isNonNull()\\public Boolean isUnique()}
+
+There return type is the Java class \code{Boolean}, not the plain type
+\code{boolean}, because the information they return is not always known.
+In an early stage of the program, they returned \code{boolean} and were
+accompanied TODO by two methods
+\code{public boolean knownIsNonNull()} and \code{public boolean knownIsUnique()},
+telling the caller whether the respective information was known and thus the
+value returned by \code{isNonNull()} or \code{isUnique()}, respectively,
+was reliable.
+
+They were then changed to return the Java class \code{Boolean} and to return
+null pointers in case the respective information is not known.
+This eliminated any possibility of using unreliable data in favor of generating
+exceptions instead, in this case a \code{NullPointerException}, which is thrown
+automatically by the Java Runtime Environment if the programmer forgets the
+null check and tries to get a definite value from one of these methods
+when the correct value currently is not known.
+
+Comparing two unknown values -- thus, two null pointers --
+also yields the desired result, \code{true}, since the change,
+even when the programmer forgets that he deals with objects.
+However, when comparing two return values of one of the methods in general
+-- as opposed to comparing one such return value against a constant --,
+errors could occur if the programmer writes \code{col1.isUnique() == col2.isUnique()}
+instead of \code{col1.isUnique().booleanValue() == col2.isUnique().booleanValue()}.
+\\TODO: Java rules.
+
+TODO: more, summary
+
+\subsection{Classes}
+\label{classes}
+Following the object-oriented programming paradigm, classes were heavily used
+to abstract from implementation details and to yield intuitively usable objects with
+a set of useful operations \cite{obj}.
+
+\subsubsection{Identification of classes}
+To identify potential classes, entities from the problem domain were -- if reasonable --
+directly represented as Java classes.
+The approach of choosing ``the program that most directly models the aspects of the
+real world that we are interested in'' to yield clean code,
+as described and recommended by Stroustrup \cite{str3}, proved to be extremely useful
+and effective.
+As a consequence, the code declares classes like \code{Column}, \code{ColumnSet},
+\code{ForeignKey}, \code{Table}, \code{TableSchema} and \code{SQLType}.
+As described in section \fullref{speaking}, class names were chosen to be concise
+but nevertheless expressive TODO.
+Java packages were used to help attain this aim, which is why the previously mentioned
+class names are unambiguous (for details about package use see section \fullref{packages}).
+
+Care was taken not to introduce unnecessary classes, thereby complicating
+code structure and increasing the number of source files and program entities.
+Especially artificial classes, having little or no reference to real-world
+objects, could most often be avoided.
+On the other hand of course, it usually is not the cleanest solution
+to avoid such artificial classes entirely.
+
+\subsubsection{Const correctness}
+Specifying in the code which objects may be altered and which shall remain constant, thus
+allowing for additional static checks preventing undesired modifications,
+is commonly referred to as ``const correctness'' TODO.
+
+Unfortunately, Java lacks a keyword like C++'s \code{const}, making it harder to
+achieve const correctness.
+It only specifies the similar keyword \code{final}, which is much less expressive and
+doesn't allow for a similarly effective error prevention \cite{final}.
+In particular, because \code{final} is not part of an object's type information,
+it is not possible to declare methods that return read-only objects TODO --
+placing a \code{final} before the method's return type would declare the
+method \code{final}. Similarly, there is no way to express that a method must not change
+the state of its object parameters. A method like \code{public f(final Object obj)}
+is only liable to not assigning a new value to its parameter object \code{obj} \cite{java}
+(which, if allowed, wouldn't affect the caller anyway \cite{java}).
+Methods changing its state, however, are allowed to be called on \code{obj} without
+restrictions \cite{java}.
+
+Several possibilities were considered to address this problem:
+\begin{itemize}
+       \item Not implementing const correctness, but stating the access rules in
+       comments only
+       \item Giving the methods which modify object states special names
+       like\\\code{setName\textendash\textendash USE\_WITH\_CARE}
+       \item Delegating changes of objects to special ``editor'' objects to be
+       obtained when an object shall be altered
+       \item Deriving classes offering the modifying methods from the read-only
+       classes
+\end{itemize}
+
+Not implementing const correctness at all of course would have been the simplest
+possibility, producing the shortest and most readable code, but since
+incautious manipulation of objects would possibly have introduced subtle,
+hard-to-spot errors which in many cases would have occurred under additional
+conditions only and at other places, for example when inserting a \code{Column}
+into a \code{ColumnSet}, this method was not seriously considered.
+
+Using intentionally angular, conspicuous names also was not considered seriously,
+since it would have cluttered the code for the only sake of hopefully warning
+programmers of possible errors -- and not attempting to avoid them technically.
+
+So the introduction of new classes was considered the most effective and cleanest
+solution, either in the form of ``editor'' classes or derived classes offering the
+modifying methods directly. Again -- as in the identification of classes --,
+the most direct solution was considered the best, so the latter form of introducing
+additional classes was chosen and classes like \code{ReadableColumn},
+\code{ReadableColumnSet} et cetera were introduced which offer only the read-only
+functionality and usually occur in interfaces.
+Their counterparts including modifying methods also were derived from them and the
+implications of modifications were explained in their documentation, while the
+issue and the approach as such were also mentioned in the documentation of the
+\code{Readable...} classes.
+The \code{Readable...} classes can be converted to their fully-functional
+counterparts via downcasting (only), thereby giving a strong hint to
+programmers that the resulting objects are to be used with care.
+
+\subsubsection{Java interfaces}
+In Java programming, it is quiet common and often recommended, that every
+class has at least one \code{interface} it \code{implemen,ts},
+specifying the operations the class provides. TODO
+If no obvious \code{interface} exists for a class or the desired
+interface name is already given to some other entity,
+the interface is often given names like \code{ITableSchema}
+or \code{TableSchemaInterface}.
+
+However, for a special purpose program with a relatively fixed set of classes
+mostly representing real-world artifacts from the problem domain,
+this approach was considered overly cluttering, introducing artificial
+code entities for no benefit.
+In particular, as explained in section TODO, all program classes either are
+standing alone TODO or belong to a class hierarchy derived from at least one
+interface.
+So, except from the standalone classes, an interface existed anyway, either
+``naturally'' (as in the case of \code{Key}, for example) or because of
+the chosen way to implement const correctness.
+In some cases, these were interfaces declared in the program code, while
+in some cases, Java interfaces like \code{Set} were implemented
+(an obvious choice, of course, for \code{ColumnSet}).
+Introducing artificial interfaces for the standalone classes was considered
+unnecessary at least, if not messy.
+
+\subsection{Packages}
+\label{packages}
+As mentioned in section \fullref{classes}, class names were chosen to be
+concise but nevertheless expressive.
+This only was possible through the use of Java \code{package}s,
+which also helped structure the program.
+
+For the current, relatively limited, extent of the program which currently
+comprises $45$ (\code{public}) classes, a flat package structure was
+considered ideal, because it is simple and doesn't stash source files deep
+in subdirectories (in Java, the directory structure of the source tree
+is required to reflect the package structure TODO).
+Because also every class belongs to a package,
+each source file is to be found exactly one directory below the root
+program source directory, which in many cases eases their handling.
+
+The following $11$ packages exist in the program
+(their purpose and more details about the package structure are
+described in section TODO):
+\begin{itemize}
+       \item \code{boostrapping}
+       \item \code{cli}
+       \item \code{database}
+       \item \code{helpers}
+       \item \code{log}
+       \item \code{main}
+       \item \code{osl}
+       \item \code{output}
+       \item \code{settings}
+       \item \code{specification}
+       \item \code{test}
+\end{itemize}
+TODO: two columns
+
+Each package is documented in the source code also, particularly in a file
+\file{package-info.java} residing in the respective package directory.
+This is a common scheme supported by the \name{Eclipse} IDE as well as the
+documentation generation systems \name{javadoc} and \name{doxygen} TODO
+(all of which were used in the creation of the program,
+as described in section TODO).
diff --git a/program_functionality.tex b/program_functionality.tex
new file mode 100644 (file)
index 0000000..e4680a0
--- /dev/null
@@ -0,0 +1,85 @@
+\section{Functionality}
+\label{functionality}
+As described in the introduction, the \myprog{} software basically is a program which
+automatically derives an OBDA specification from a relational database schema,
+which then can be used by other tools to drive the actual bootstrapping process.
+Its functionality is described in the next section
+(while leaving out self-evident features) and is then listed completely
+in the section after that.
+
+\subsection{Description}
+The database schema is retrieved by connecting to an \name{SQL} database
+and querying its schema information.
+Parsing \name{SQL} specifications TODO or \name{SQL} dumps currently is not supported.
+%Naturally, authentication on the \name{SQL} server is supported, also by
+%interactively querying for passwords while hiding the typed input.
+The databases to derive information from can be specified by regular expressions,
+while there are also options to use other databases than specified or even
+other database servers, taken from a list of hard-coded strings.
+While these features may not seem to carry real benefit at the first glance,
+they proved to be very useful for testing purposes, especially since the retrieval of a
+database schema can take some time (see TODO).
+For the same purpose, \myprog{} allows the processing of a hard-coded example database schema.
+
+In addition to \osl{} output, a low-level output format containing information on all fields of
+the underlying objects is supported, which is useful for debugging
+(however, this feature has to be enabled via one slight change in the source code).
+To allow for some customization, the insertion of an own \osl{} header is supported
+(for more information on the \osl{} header, see the specification of the \osl{} language
+in section \ref{oslspec}).
+If the standard \osl{} header is used, it is by default loaded from a hard-coded copy,
+so bootstrapping information from a database server running locally or from the hard-coded
+example schema requires no Internet connection
+(simply inserting the \code{owl:imports} statement of course would not anyway,
+but the generated underlying ontology is always checked for consistency with the
+\osl{} header to prevent the generation of invalid output).
+
+The \myprog{} software can be used both in an interactive and in a non-interactive mode,
+while skipping a database or a database server or aborting the entire bootstrapping process
+is possible in either mode.
+Multiple database servers can be specified for a bootstrapping operation,
+which then are checked in order for a matching database,
+allowing to make use of mirrors or fallback servers.
+Additionally, multiple bootstrapping operations can be specified to be performed in sequence
+with one invocation of \myprog{}, while all features and settings previously described
+are enabled, disabled or set per operation.
+Finally, a help text can be displayed which describes the usage of \myprog{} including the
+description of all command-line arguments.
+
+\subsection{Summary}
+The functionality of the \myprog{} software can be summarized as follows:
+
+\begin{itemize}
+       \item Bootstrap one or more OBDA specifications from a database schema
+       by connecting to an \name{SQL} database server
+       \item Specify a custom port, login and password for the database server
+       \item Ask for passwords interactively (before starting any bootstrapping
+       operation), hide them if desired
+       \item Specify database names by regular expressions
+       \item Process an arbitrary database if the specified database
+       could not be found or unconditionally
+       \item Connect to a database server containing example databases
+       without having to specify any further details
+       \item Process a hard-coded example database schema
+       without having to specify any further details
+       \item Use the \osl{} format described in section \fullref{osl}
+       or a detailed low-level format for output
+       (the latter is for debugging purposes and has to be enabled
+       in the source code)
+       \item Write to standard output or to a file
+       \item Insert a custom \osl{} header
+       (see the specification of the OBDA Specification Language (\osl{})
+       in section \ref{oslspec} for details)
+       \item Consistency check against a custom \osl{} header
+       \item Consistency check against the standard \osl{} header without internet connection
+       \item Act interactively or non-interactively
+       \item Skip currently retrieved database (and try next on server),
+       skip current server or abort the overall process at any time, even in
+       non-interactive mode
+       \item Define multiple database servers to check in order for the specified database
+       \item Specify multiple bootstrapping operations to perform in order
+       \item Configure the features described in the above notes
+       per bootstrapping operation
+       \item Display a help text describing the usage of \myprog{},
+       including the description of all command-line arguments
+\end{itemize}
diff --git a/program_interface.tex b/program_interface.tex
new file mode 100644 (file)
index 0000000..d86c8f8
--- /dev/null
@@ -0,0 +1,100 @@
+\section{Interface}
+\label{interface}
+This section describes the interface to the operating system and the user interface.
+For information on programming interfaces, see section \fullref{arch}.
+
+\subsection{User interaction and configuration}
+\subsubsection{Basic usage}
+Currently, the only user interface of \myprog{} is a command-line interface.
+Since the program is supposed to bootstrap the OBDA Specification automatically and
+thus there is little interaction, but a lot of output, this was considered ideal.
+Because of its ability to write to the standard output (which is also the default
+behavior), it is easy to pipe the output of \myprog{} directly to a program that
+handles it in a Unix-/POSIX-like fashion TODO:
+\codepar{db2osl myserver.org | osl2onto myserver.org}
+
+(supposed \name{osl2onto} is a tool that reads an \osl{} specification from its
+standard input and uses it to bootstrap an ontology from the database
+specified on its command line).\\
+This scheme is known as ``filter-pattern'' TODO.
+
+By inserting additional ``filters'', the bootstrapping process can be customized
+without changing any of the involved programs:
+\codepar{db2osl mydatabase.org | customize\_uris.sh | osl2onto mydatabase.org}
+
+(supposed \name{customize\_uris.sh} is a shell script that modifies the URIs
+contained in an \osl{} specification in the manner the user desires).
+
+\subsubsection{Command-line arguments}
+The behavior of \myprog{} itself can be adjusted via command-line arguments.
+The syntax for their application follows the POSIX standard TODO.
+Most features can be configured via short options (as, for example, \code{-P}).
+To allow for enhanced readability of \myprog{} invocations, each feature can (also)
+be configured via a long option (like \code{\textendash\textendash password}).
+
+The command-line arguments \myprog{} currently supports and their effects are
+described in table \ref{if_tbl_arguments}.
+There currently is no switch to set the output format, since the only supported
+output format, besides \osl{}, is a low-level output format for debugging purposes.
+Because of this and since the change that has to be made in the source code to enable it
+only involves changing one token, it was preferred not to offer a command-line option
+for this, thus not unnecessarily complicating the command-line interface for the
+normal, non-debugging, user.
+
+\begin{table}[]\begin{center}
+               \begin{tabular}{l|l|l}
+                       Option(s) & Description, taken from the help page of \myprog{} & Default value (if present)\\
+                       \hline
+                       \code{\textendash\textendash database, -d} & database name (Java regular expression) databases have to match to be processed; see also: \code{\textendash\textendash loose-database-match} & .*\\
+                       \code{\textendash\textendash echo-password} & echo input when prompting for SQL password -- must be specified before \code{\textendash\textendash password-prompt} to get effective & false\\
+                       \code{\textendash\textendash help, -h, } & show this help and exit & false\\
+                       \code{\textendash\textendash interactive, -i} & be interactive when chosing database & false\\
+                       \code{\textendash\textendash login, -L} & SQL login & anonymous\\
+                       \code{\textendash\textendash loose-database-match} & if no database matching the regex specified with \code{\textendash\textendash database} is found on the given server and \code{\textendash\textendash interactive} is not specified for this job, use some other database & false\\
+                       \code{\textendash\textendash osl-header} & use the specified custom (non-standard) OSL header, implies \code{\textendash\textendash remote-osl-header} (to import no header, specify the empty string) & Default: <empty string>\\
+                       \code{\textendash\textendash output-file, -o} & use the specified output file (for the standard output, specify ``-'') & -\\
+                       \code{\textendash\textendash password, -P} & SQL password; use \code{\textendash\textendash password-prompt} to get a password prompt (if you do both, the password set via this switch will be ignored) & Default: <empty string>\\
+                       \code{\textendash\textendash password-prompt, -p} & prompt for SQL password; a password set via \code{\textendash\textendash password} is ignored & false\\
+                       \code{\textendash\textendash remote-osl-header, -R} & don't use hard-coded version of the OSL header for verification & false\\
+                       \code{\textendash\textendash remote-test} & try to retrieve a database schema from a hard-coded list of servers and take the first one successfully retrieved (and accepted, when \code{\textendash\textendash interactive} is given; note: give a dummy server if you want to do a test besides other jobs) & false\\
+                       \code{\textendash\textendash test} & use hard-coded test database schema, ignore given servers (note: give a dummy server if you want to do a test besides other jobs) & false\\
+               \end{tabular}\\
+               \caption{Command-line arguments in \myprog{}}
+               \label{if_tbl_arguments}
+       \end{center}\end{table}
+
+The sole invocation of \myprog{}, without any arguments, does not initiate any processing
+but displays the usage directions instead, in addition to an error message.
+
+\subsubsection{Multiple bootstrapping operations or multiple servers}
+To perform multiple bootstrapping operations with one invocation of \myprog{},
+it is sufficient to concatenate the command-line arguments for each operation,
+separated by blanks, to get the final command line.
+However, when combining a test job with other operations, some arbitrary string has to be
+inserted as dummy server to allow distinguishing the different jobs and assigning
+each command-line argument to the appropriate job.
+
+On the other hand, to check several servers in order for the database to be used
+for one bootstrapping operation, these servers have to be concatenated,
+separated by blanks.
+Again, the distinction of the different bootstrapping jobs has to be possible,
+so all but the first operation have to have at least one command-line argument
+(which is no practical problem, since to enforce this, a default argument simply
+can be stated explicitly without changing the behavior of the invocation).
+
+All settings are configured per operation, so, when using a shell that separates batched
+commands by `;',
+\codepar{db2osl \textendash\textendash database employees \textendash\textendash
+       password itsme sql.myemployer.com\\
+       \textendash\textendash database test myserver.org backup.myserver.org}
+is equivalent to
+\codepar{db2osl \textendash\textendash database employees \textendash\textendash
+       password itsme sql.myemployer.com;\\
+       db2osl \textendash\textendash database test myserver.org backup.myserver.org}
+
+Thus, currently 
+
+\subsection{Integration into systems}
+TODO: modularity -> reusability
+TODO: logger
+TODO: operating system -> Java
diff --git a/program_stats.tex b/program_stats.tex
new file mode 100644 (file)
index 0000000..395b2dd
--- /dev/null
@@ -0,0 +1,3 @@
+\section{Numbers and statistics}
+\label{stats}
+TODO: Retrieval times, (NC)LOC and other statistics
diff --git a/program_tools.tex b/program_tools.tex
new file mode 100644 (file)
index 0000000..84ac919
--- /dev/null
@@ -0,0 +1,2 @@
+\section{Tools employed}
+\label{tools}
diff --git a/program_versioning.tex b/program_versioning.tex
new file mode 100644 (file)
index 0000000..8c45b7c
--- /dev/null
@@ -0,0 +1,2 @@
+\section{Versioning}
+\label{versioning}
diff --git a/summary.tex b/summary.tex
new file mode 100644 (file)
index 0000000..1577195
--- /dev/null
@@ -0,0 +1,5 @@
+\chapter{Summary and future work}
+Für den eiligen Leser ist die Vorgehensweise zusammen mit den
+wesentlichen Ergebnissen am Schluss in einer ``Zusammenfassung'' klar
+herauszustellen. Diese soll ausführlicher sein als die  ``Übersicht'' am Anfang der Arbeit. Auch diese Zusammenfassung soll möglichst keine Formeln enthalten.
+