relational databases}
\newcommand{\myprog}{\name{db2osl}}
\newcommand{\osl}{\name{OSL}}
-\newcommand{\oslspec}{\osl{} specification}
\newcommand{\myfontsize}{12pt}
\newcommand{\smallerfontsize}{11pt}
\newcommand{\smallfontsize}{10pt}
% Mathematische Symbole etc.
\usepackage{amsmath,amssymb}
-\usepackage[binary-units=true,decimalsymbol=comma]{siunitx}
+%\usepackage[binary-units=true,decimalsymbol=comma]{siunitx}
% Algorithmen
-\usepackage{algpseudocode}
-\usepackage{algorithm}
-\usepackage{algorithmicx}
+%\usepackage{algpseudocode}
+%\usepackage{algorithm}
+%\usepackage{algorithmicx}
% Tabellen
\usepackage{longtable,lscape}
author={Philipp Martis},
type=bachelor,
institute=ipvs,
- number=TODO,
+ number=281,
course=cs,
examiner={PD\ Dr.\ Holger Schwarz},
supervisor={M. Sc. Leif Harald Karlsen},
Specification}
\newcommand{\myprog}{\name{db2osl}}
\newcommand{\osl}{\name{OSL}}
-\newcommand{\oslspec}{\osl{} specification}
\newcommand{\myfontsize}{12pt}
\newcommand{\smallerfontsize}{11pt}
\newcommand{\smallfontsize}{10pt}
% Mathematische Symbole etc.
\usepackage{amsmath,amssymb}
-\usepackage[binary-units=true,decimalsymbol=comma]{siunitx}
+%\usepackage[binary-units=true,decimalsymbol=comma]{siunitx}
% Algorithmen
-\usepackage{algpseudocode}
-\usepackage{algorithm}
-\usepackage{algorithmicx}
+%\usepackage{algpseudocode}
+%\usepackage{algorithm}
+%\usepackage{algorithmicx}
% Tabellen
\usepackage{longtable,lscape}
\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})
+TODO: Grundlagen (?)\\
-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.
+\section{Background}
+As explained 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.
-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.
+TODO: OPTIQUE \cite{optique}
-\section{Background}
\section{Related work}
-@COMMENTBook{schlichting67,
- author = {H.~Schlichting and E.~Truckenbrodt},
- title = {Aerodynamik des Flugzeugs, Band 1},
- publisher = {Springer Verlag},
- address = {Berlin/Heidelberg/New York},
- year = 1967
-}
-
-@COMMENTTechReport{hartwick71,
- author = {G.~Hartwick and S.~Sadler},
- title = {Program Documentation for Development and Application of a Method for Predicting Rotor Wake Geometries and Rotor Wake Geometries and Rotor Loads},
- institution = {NASA},
- address = {New York},
- year = 1971,
- type = {Report},
- number = {69-9}
-}
-
@Article{eng,
shorthand = {SGH\textsuperscript{+}15},
author = {Martin G. Skjæveland and Martin Giese and Dag Hovland and Espen H. Lian and Arild Waaler},
@misc{owl,
shorthand = {W3C12},
author = {W3C OWL Working Group},
- title = {OWL 2 Web Ontology Language, Document Overview (Second Edition)},
+ title = {OWL 2 Web Ontology Language - Document Overview (Second Edition)},
year = 2012,
howpublished = {\url{https://www.w3.org/TR/owl2-overview/}},
note = {[Accessed: 2016-04-02]}
}
@misc{dirm,
- shorthand = {W3C12},
- author = {TODO},
+ shorthand = {W3CR12},
+ author = {RDB2RDF Working Group},
title = {A Direct Mapping of Relational Data to RDF},
year = 2012,
howpublished = {\url{https://www.w3.org/TR/rdb-direct-mapping/}},
month = may,
number = 5,
pages = {34--43},
- url = {http://www.sciam.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21},
volume = 284,
year = 2001
}
address = {New York, NY, USA},
keywords = {Java, Javari, assignable, immutability, mutable, readonly, type system, verification},
}
+
+@inproceedings{optique,
+ shorthand = {KGJR\textsuperscript{+}13},
+ author = {Kharlamov, Evgeny and Giese, Martin and Jiménez-Ruiz, Ernesto and Skjæveland, Martin G. and Soylu, Ahmet and Zheleznyakov, Dmitriy and Bagosi, Timea and Console, Marco and Haase, Peter and Horrocks, Ian and Marciuska, Sarunas and Pinkel, Christoph and Rodriguez-Muro, Mariano and Ruzzi, Marco and Santarelli, Valerio and Savo, Domenico Fabio and Sengupta, Kunal and Schmidt, Michael and Thorstensen, Evgenij and Trame, Johannes and Waaler, Arild},
+ biburl = {http://www.bibsonomy.org/bibtex/2b2fd27981eefec0983a98a0da793f1a8/dblp},
+ booktitle = {International Semantic Web Conference (Posters \& Demos)},
+ crossref = {conf/semweb/2013p},
+ editor = {Blomqvist, Eva and Groza, Tudor},
+ ee = {http://ceur-ws.org/Vol-1035/iswc2013_demo_17.pdf},
+ interhash = {ee631e8fa9c8764e12ef94e82b4458a2},
+ intrahash = {b2fd27981eefec0983a98a0da793f1a8},
+ keywords = {dblp},
+ pages = {65--68},
+ publisher = {CEUR-WS.org},
+ series = {CEUR Workshop Proceedings},
+ title = {Optique 1.0: Semantic Access to Big Data: The Case of Norwegian Petroleum Directorate's FactPages},
+ volume = 1035,
+ year = 2013
+}
+
+@inproceedings{optique2,
+ shorthand = {CGH\textsuperscript{+}13},
+ title = {The Optique Project: Towards OBDA Systems for Industry (Short Paper)},
+ author = {D. Calvanese and M. Giese and P. Haase and I. Horrocks and T. Hubauer and Y. Ioannidis and E. Jim\'{e}nez-Ruiz and E. Kharlamov and H. Kllapi and J. Kl{\"u}wer and M. Koubarakis and S. Lamparter and R. M{\"o}ller and C. Neuenstadt and T. Nordtveit and {\"O}. {\"O}zcep and M. Rodriguez-Muro and M. Roshchin and Marco Ruzzi and F. Savo and M. Schmidt and A. Soylu and A. Waaler and D. Zheleznyakov},
+ year = "2013",
+ booktitle = "OWL Experiences and Directions Workshop (OWLED)",
+}
+
+@techreport{unix,
+ author = {M. D. McIlroy},
+ title = {A Research {UNIX} Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986},
+ institution = {{AT\&T} Bell Laboratories},
+ year = {1987},
+ number = {CSTR 139}
+}
+
+@book{patterns,
+ author = {Buschmann, Frank and Meunier, Regine and Rohnert, Hans and Sommerlad, Peter and Stal, Michael},
+ title = {Pattern-Oriented Software Architecture - Volume 1: A System of Patterns},
+ year = {1996},
+ isbn = {0471958697, 9780471958697},
+ publisher = {Wiley Publishing}
+}
+
+@book{gof,
+ address = {Reading, MA},
+ author = {Gamma, Erich and Helm, Richard and Johnson, Ralph and Vlissides, John},
+ biburl = {http://www.bibsonomy.org/bibtex/2b074c2848d5c64657278632da5ecbd08/chato},
+ citeulike-article-id = {240673},
+ interhash = {d46ec5e2c98583730aa182ceb4a3ab22},
+ intrahash = {b074c2848d5c64657278632da5ecbd08},
+ keywords = {design; patterns; programming},
+ publisher = {Addison Wesley},
+ title = {Design Patterns},
+ year = 1995
+}
+
+@article{posix,
+shorthand = {IEEE13},
+journal={IEEE Std 1003.1, 2013 Edition (incorporates IEEE Std 1003.1-2008, and IEEE Std 1003.1-2008/Cor 1-2013)},
+title={Standard for Information Technology - Portable Operating System Interface (POSIX) - Base Specifications, Issue 7},
+year={2013},
+keywords={Application programming interfaces;File systems;IEEE standards;Information technology;Operating systems;CPU;FIFO;IEEE 1003.1;X/Open System Interface (XSI);application program interface (API);argument;asynchronous;basic regular expression (BRE);batch job;batch system;built-in utility;byte;child;command language interpreter;extended regular expression (ERE);file access control mechanism;input/output (I/O);job control;network;parent;portable operating system interface (POSIX);shell;stream;string;synchronous;system;thread},
+doi={10.1109/IEEESTD.2013.6506091},
+month={April},
+}
+
+@book{log,
+ title={Logging in Java with the JDK 1.4 Logging API and Apache log4j},
+ author={Gupta, S.},
+ isbn={9781590590997},
+ lccn={2003005480},
+ series={Apresspod Series},
+ year={2003},
+ publisher={Apress}
+}
+
+@misc{rdf,
+ shorthand = {W3C14},
+ author = {W3C RDF Working Group},
+ title = {RDF 1.1 Concepts and Abstract Syntax},
+ year = 2014,
+ howpublished = {\url{https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/}},
+ note = {[Accessed: 2016-05-13]}
+}
+
+@misc{doxygen,
+ title={Doxygen: Source code documentation generator tool},
+ author={van Heesch, Dimitri},
+ howpublished={\url{http://www.doxygen.org}},
+ year={2016},
+ note={[Accessed: 2016-05-13]}
+}
+
+@misc{javadoc,
+ shorthand = {Ora16},
+ title={javadoc - The Java API Documentation Generator},
+ author={{Oracle Corporation}},
+ howpublished={\url{http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html}},
+ year={2016},
+ note={[Accessed: 2016-05-13]}
+}
+
+@book{struc,
+ author = {Dijkstra, E. W.},
+ editor = {Dahl, O. J. and Dijkstra, E. W. and Hoare, C. A. R.},
+ title = {Structured Programming},
+ year = {1972},
+ isbn = {0-12-200550-3},
+ source = {Library of Congress Catalog Card Number: 72-84452},
+ publisher = {Academic Press Ltd.},
+ address = {London, UK, UK}
+}
+
+@book{clean,
+ author = {Martin, Robert C.},
+ title = {Clean Code: A Handbook of Agile Software Craftsmanship},
+ year = {2008},
+ isbn = {0132350882, 9780132350884},
+ edition = {1},
+ publisher = {Prentice Hall PTR},
+ address = {Upper Saddle River, NJ, USA}
+}
+
+@book{weavingweb,
+ author = {Berners-Lee, Tim and Fischetti, Mark},
+ title = {Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web by Its Inventor},
+ year = {1999},
+ isbn = {0062515861},
+ edition = {1st},
+ publisher = {Harper San Francisco}
+}
+
+@techreport{web,
+ added-at = {2016-05-10T14:36:44.000+0200},
+ author = {Berners-Lee, Tim},
+ biburl = {http://sandbox.academic-puma.de/bibtex/27025bb82bcc97e330af31c908df0818a/alistair},
+ institution = {CERN},
+ interhash = {8fad800e51f4c9ae788b2ec32fa605e8},
+ intrahash = {7025bb82bcc97e330af31c908df0818a},
+ keywords = {grammar linguistic},
+ note = {March 1989, May 1990},
+ timestamp = {2017-11-18T00:00:13.000+0100},
+ title = {{I}nformation {M}anagement: {A} {P}roposal},
+ topics = {area.hyper,area.www},
+ url = {http://www.w3.org/History/1989/proposal.html},
+ year = 1989
+}
\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.\\
+\label{intro}
\section{Motivation}
+\label{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
+This makes the publication of available data in a structured, machine-processable
+form and its retrieval with eligible software an interesting topic.
+The most important formalism to represent structured data without the need of
+a fixed (database) schema is ontologies, and thus this approach is known
+under the term ``Ontology based data access'' (``OBDA'').
+The vision of a machine-processable web emerged as early as 1989 \cite{web}
+and was entitled with the term ``semantic web''
+by Tim Berners-Lee in 1999 \cite{weavingweb}.
+Definitely, the automatic translation of relational databases to \name{RDF}
+\cite{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,
+Today, the pure bootstrapping 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
and to drive the entire tool chain \cite{eng}.
\section{Approach}
+\label{approach}
This thesis describes the development of a specification language to serialize
-the declarative specification of the bootstrapping process and of a
+the declarative specification of the bootstrapping process
+(see section \fullref{motivation}) 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
+two-step-procedure, illustrated in figure \ref{intro_fig_bootstrapping}:
+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.
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
+
+\begin{figure}[H]\begin{center}
+ \includegraphics[scale=0.9]{Images/bootstrapping_illustration.pdf}
+ \caption[Illustration of the overall
+ bootstrapping process]{Illustration of the overall
+ bootstrapping process using a declarative OBDA specification}
+ \label{intro_fig_bootstrapping}
+ \end{center}\end{figure}
\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
+To achieve these goals, 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
+To fit into the environment used in the OPTIQUE project\cite{optique2} it is ultimately
part of, \name{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
+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
+To achieve this aim 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
+Following good object-oriented software development practice \cite{str3},
+real world artifacts like database schemata, database tables, columns, keys,
+and OBDA specifications 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.
+This approach and other actions aiming at yielding clean code are described more
+thoroughly in section \fullref{code}, while
+the resulting structure of the software is discussed in section \fullref{arch}.
many aspects of an \osl{} document for conformity with minimal effort.
\section{Specification}
-\label{oslspec}
+\label{osl_spec}
\newcounter{parcount}
\newcommand{\parnum}{\textsuperscript{\arabic{parcount}}}
\newcommand{\p}{\refstepcounter{parcount} \parnum \hspace{1em}}
\p An \osl{} document is a valid \name{OWL} 2 document (as described in \cite{owl})
-containing individuals and data that represent the OBDA Specification,
+containing individuals and data that represent the OBDA specification,
as well as \name{OWL} properties that connect them.
The individuals and \name{OWL} properties are recognized and mapped to their roles
by their IRIs.
\chapter{The db2osl software}
+\label{program}
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
+Section \ref{functionality} describes the functionality the program offers.
+Section \ref{interface} describes how this functionality is exposed to the
program environment.
-Section \fullref{bootstrapping} explains in detail how the bootstrapping
+Section \ref{bootstrapping} explains in detail how the bootstrapping
process was realized.
-Section \fullref{arch} describes the program architecture both on a coarse and
+Section \ref{arch} describes the program architecture both on a coarse and
a fine level.
-Section \fullref{tools} explains what tools where used to create the program.
-Section \fullref{code} describes concepts and decisions that where implemented
+Section \ref{tools} explains what tools where used to create the program.
+Section \ref{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
+Section \ref{stats} mentions some numbers and statistics about the program.
+Section \ref{versioning} gives a brief chronological overview over the program
development and describes important milestones.
For detailed descriptions of the classes and packages of \myprog{}, refer to
Appendices TODO.
\code{log} & Classes related to logging and diagnostic output\\
\code{main} & The \code{Main} class\\
\code{osl} & Classes representing OBDA specifications (as described in \cite{eng}) using the OBDA Specification Language (\osl{})\\
- \code{output} & Classes used to output OBDA Specifications as described in \cite{eng}\\
+ \code{output} & Classes used to output OBDA specifications as described in \cite{eng}\\
\code{settings} & Classes related to program and job settings (including command line parsing)\\
\code{specification} & Classes representing (parts of) OBDA specifications (as described in \cite{eng}) directly, without involving \osl{}\\
\code{test} & Classes offering testing facilities\\
comprehensible structuring, emphasizing different roles and thus being a more proper
foundation for future extensions of the program.
For example, because the \code{bootstrapping} package is central to the program and
-takes over TODO an active, processing role and in that is completely different
+takes over an active, processing role and in that is completely different
from the classes of the \code{specification} package which on their part have a
\emph{representing} role, it was considered senseful not to merge these two packages.
This undergirds the separation of concerns within the program and stresses that
reasonably less.
However, in the new structuring, \code{specification} has no packages it depends on
and thus suits its purpose of providing a mundane and straight-forward
-representation of an OBDA Specification much better.
+representation of an OBDA specification much better.
%Furthermore, \code{output} doesn't depend on \code{database} anymore.
\begin{figure}[H]\begin{center}
Note that every class hierarchy has at least one \code{interface} at its top.
Classes not belonging to a class hierarchy were chosen not to be given an interface
-``factitiously'', which would have made them part of a (small) class hierarchy TODO.
-Deliberately, the scheme often recommended in the Java world TODO
+``factitiously'', which would have made them part of a (small) class hierarchy \cite{java}.
+Deliberately, the scheme often recommended \cite{gof}
to give every class an interface it \code{implements} was not followed
but the approach described by Stroustrup \cite{str4} to provide a rich set of
so called ``concrete types'' not designed for use within class hierarchies, which
-``build the foundation of every well-designed program \cite{str4}'' TODO.
+``build the foundation of every well-designed program'' \cite{str4}.
The details of this consideration are explained in section \fullref{code_interfaces}.
In fact, many useful types were already offered by the \name{Java} API
and of course were not re-implemented.
-Class \code{Column} with its interface \code{ReadableColumn} is an exception TODO
+Class \code{Column} with its interface \code{ReadableColumn} is an exception
in that it was given an interface although it is basically a concrete type.
The reason for this is the chosen way to implement const correctness,
described in section \nameref{const} (which is part of section \fullref{code_classes}).
\section{Code style}
\label{code}
-TODO: Conventions, ex.: iterators
-As the final system hopefully will have a long living cycle TODO
+TODO: Conventions, ex.: iterators\\
+As the final system hopefully will have a long lifetime cycle
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
+Common software development principles were followed and
the unfamiliar reader was constantly taken into account
to yield clean, readable and extensible code.
+%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.
+
\subsection{Comments}
\label{comments}
Comments were used at places ambiguities or misinterpretations could arise,
plain comments, for example to specify parameters, return types, exceptions
and links to other parts of the documentation.
This proved even more useful due to the fact that \name{Doxygen} supports all
-of the used \name{Javadoc} comments TODO (but not vice versa TODO).
+of the used \name{Javadoc} comments \cite{doxygen} (but not vice versa \cite{javadoc}).
\subsection{``Speaking code''}
\label{speaking}
This is especially important since, as described in section \fullref{arch},
\myprog{} was designed to not only be a standalone program but also offer
components suitable for reusability.
-%TODO: understandability <- code size
+
+TODO: understandability <- code size
The following topics were identified to be addressed to get what can be
conceived as ``speaking code'':
\item Variable names
\item Intuitive control flow
\item Limited nesting
- \item Compact code units
\item Usage of well-known structures
\end{itemize}
code duplication and to separate implementations from interfaces \cite{str4}.
All real-world artifacts to be modeled like database schemata, tables, table schemata.
-columns, keys and OBDA Specifications with their certain map types were directly
+columns, keys and OBDA specifications with their certain map types were directly
translated into classes having simple predicting names like \code{Table},
\code{TableSchema} and \code{Key}.
Package affiliation provided the correct context to unambiguously understand these names.
to a local scope, and neither are easily changeable without affecting callers
\cite{java}.
-Care was taken that method names reflect all important aspects of the respective
-method's behavior and
-
-Consider the following method in \file{CLIDatabaseInteraction.java}:
+Ultimately, care was taken that method names reflect all important aspects
+of the respective method's behavior.
+Consider the following method from \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.
+However, the waiting (blocking) is such an important part of its behavior, that this
+was considered not 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.
been necessary.
\subsubsection{Intuitive control flow}
+To consequently stick to the maxim of speaking code and further increase readability,
+control flow was tried to kept intuitive.
+\code{do-while} loops, for example, are unintuitive: they complicate matters due to
+the additional, unconditional, loop their reader has to keep in mind.
+Even worse, \name{Java}'s Syntax delays the occurrence of their most important
+control statement -- the loop condition -- till after the loop body.
+Usually, \code{do-while} loops can be circumvented by properly setting variables
+influencing the loop condition immediately before the loop and using a \code{while}
+loop.
+Consequently, \code{do-while} loops were omitted -- the code of \myprog{} does not
+contain a single \code{do-while} loop.
+TODO: references
+
+Another counterproductive technique is the avoidance of the advanced loop control
+statements \code{break}, \code{continue} and \code{return} and the sole direction
+of a loop's control flow with its loop condition, often drawing on additional
+boolean variables like \code{loopDone} or \code{loopContinued}.
+This approach is an essential part of the ``structured programming (paradigm)''
+\cite{struc} and its purpose is to enforce that a loop is always
+left regularly, by unsuccessfully checking the loop condition, which shall ease
+code verification \cite{struc}.
+A related topic is the general avoidance of the \code{return} statement (except at
+the end of a method) for similar considerations \cite{struc}.
+However, both are not needed \cite{clean} and, as always, the introduction
+of artificial technical constructs impairs readability and the ability of the code
+to ``speak for itself''.
+
+Consequently, control flow was not distorted for technical considerations
+and care was taken to yield straight-forward loops, utilizing advanced control
+statements to be concise and intuitive and cleverly designed methods that benefit
+from well-placed \code{return} statements.
\subsubsection{Limited nesting}
-
-\subsubsection{Compact code units}
+A topic related to intuitive control flow is limited code nesting.
+Most introductions of new nesting levels greatly increase complexity,
+since the associated conditions for the respective code to be reached
+combine with the previous ones in often inscrutable ways.
+Besides being aware of the execution condition for the code he is currently
+reading, the reader is forced to either remember the sub-conditions introduced
+with each nesting level, as well as the current nesting level,
+or to jump back to the introduction of one or more nestings to figure out the
+relevant execution condition again.
+
+Naturally, such code is far from being readable and expressive.
+Thus, overly deep nesting was avoided by rearranging code or using control
+statements like \code{return} in favor of opening a new \code{if} block.
+The deepest and most complicated nesting in \myprog{} has level $5$
+(with normal, non-nested method code having level $0$), with
+one of these nestings being dedicated to a big enclosing \code{while} loop,
+one to a \code{try-catch} block and the remaining three to \code{if} blocks
+with no \code{else} parts and trivial one-expression conditions.
+Additionally, in this case all of the nesting blocks only contained
+a few lines of code, making the whole construction easily fit on one screen,
+so this was considered all right.
+At a few other places there occurs similar, less complicated, nesting up to level $5$.
+%These were similar to the above but with two enclosing loops and one or
+%even two \code{try-catch} blocks.
+TODO: references
\subsubsection{Usage of well-known structures}
+Great benefit can be taken from constructs familiar to programmers
+regarding expressiveness.
+Surely, implementations based on such well-known constructs and patterns
+are much more likely to be instantly understood by programmers and therefore
+have a much higher ability of ``speaking for themselves''.
+
+Examples in \myprog{} are the (extensively used) iterator concept,
+const correctness (see paragraph ``\nameref{const}''
+in section \fullref{code_classes}), exceptions, predicates \cite{str4},
+run-time type information \cite{str4}, helper functions \cite{str4}
+and well-known interfaces from the \name{Java} API like \code{Set} or
+\code{Collection}, as well as common \name{Java} constructs, like
+classes performing a single action (e.g. \code{OSLSpecPrinter}), and
+naming schemes, like \code{get...}/\code{set...}/\code{is...}.
\subsection{Robustness against incorrect use}
-Care was taken to produce code that is robust to incorrect use, making it
+Care was taken to produce code that is geared to incorrect use, making it
suitable for the expected environment of sporadic updates by unfamiliar and
potentially even unpracticed programmers, who besides have their emphasis
on the concepts of bootstrapping rather than details of the present code anyway.
are the following methods from \file{Column.java}:
\codepar{public Boolean isNonNull()\\public Boolean isUnique()}
-There return type is the \name{Java} class \code{Boolean}, not the plain type
+Their return type is the \name{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 by two methods
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 \name{Java Runtime Environment} if the programmer forgets the
-null check and tries to get a definite value from one of these methods
+automatically by the \name{Java} Runtime Environment \cite{java} 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 --
TODO: summary
-\subsection{Classes}
+\subsection{Use of classes}
\label{code_classes}
-Following the object-oriented programming paradigm, classes were heavily used
+Following the object-oriented programming paradigm \cite{obj}, classes were heavily used
to abstract from implementation details and to yield intuitively usable objects with
-a set of useful operations \cite{obj}.
+a set of useful operations.
\subsubsection{Identification of classes}
To identify potential classes, entities from the problem domain were -- if reasonable --
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.
+but nevertheless expressive.
\name{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{code_packages}.
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 --
+it is not possible to declare methods that return read-only objects \cite{final} --
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
+method \code{final} \cite{java}.
+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}.
+Methods changing its state, on the other hand,
+are allowed to be called on \code{obj} without restrictions.
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 TODO
- \item Deriving classes offering the modifying methods from the read-only
- classes
+ \item Not implementing const correctness, but giving the methods which modify
+ object states special names like
+ \code{setName\textendash\textendash USE\_WITH\_CARE}
+ \item Implementing const correctness by delegating changes of objects
+ to special ``editor'' objects to be
+ obtained when an object shall be modified
+ \item Implementing const correctness by deriving classes offering
+ the modifying methods from read-only classes
\end{itemize}
Not implementing const correctness at all of course would have been the simplest
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,
+Not implementing const correctness but 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 --,
+modifying methods directly. Again -- as during 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
\subsubsection{Java interfaces}
\label{code_interfaces}
-In \name{Java} programming, it is quiet common and often recommended, that every
-class has at least one \code{interface} it \code{implements},
-specifying the operations the class provides. TODO
+In \name{Java} programming, it is quiet common and often recommended \cite{gof}
+that every class has at least one \code{interface} it \code{implements},
+specifying the operations the class provides.
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}
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
+In particular, as explained in section \fullref{fine}, all program classes either
+are standing alone 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
Introducing artificial interfaces for the standalone classes was considered
unnecessary at least, if not messy.
-\subsection{Packages}
+\subsection{Use of packages}
\label{code_packages}
As mentioned in section \fullref{code_classes}, class names were chosen to be
concise but nevertheless expressive.
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 \name{Java}, the directory structure of the source tree
-is required to reflect the package structure TODO).
+is required to reflect the package structure \cite{java}).
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 \fullref{coarse}):
-\begin{multicols}{3}\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}\end{multicols}
-
For the description of the packages, their interaction and considerations on
their structuring, see section \fullref{coarse}.
For a detailed package description, refer to Appendix TODO.
Each package is documented in the source code also, namely 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
+documentation generation systems \name{Javadoc} and \name{Doxygen}
(all of which were used in the creation of the program,
as described in section \fullref{tools}).
\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,
+As described in the \hyperref[intro]{introduction} of this thesis,
+the \myprog{} software is
+a program automatically deriving 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,
+Its functionality is described in the following section,
leaving out self-evident features, and is then listed completely
in the section after that.
+How this functionality is exposed to users is described in section \fullref{interface}.
The bootstrapping process as the core functionality of the software is described in
section \fullref{bootstrapping}.
+TODO: reference to OBDA topics
-\subsection{Description}
+\subsection{Function 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.
+Parsing \name{SQL} scripts 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).
+they proved to be useful for testing purposes, especially since the retrieval of a
+database schema can take some time TODO (see section \fullref{stats}).
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
(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}).
+in section \ref{osl_spec}).
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
Finally, a help text can be displayed which describes the usage of \myprog{} including the
description of all command-line arguments.
-\subsection{Summary}
+\subsection{Function summary}
The functionality of the \myprog{} software can be summarized as follows:
\begin{itemize}
\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)
+ in section \ref{osl_spec} 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
\subsubsection{Basic usage}
\label{basic}
Currently, the only user interface of \myprog{} is a command-line interface.
-Since the program is supposed to bootstrap the OBDA Specification automatically and
+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.
Basically, one invocation of \myprog{} will initiate the automatic, non-interactive
bootstrapping of exactly one \osl{} specification written to the standard output,
a behavior which can be modified via command-line arguments.
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 into a program that
-handles it in a Unix-/POSIX-like fashion TODO:
+handles it in a Unix-/POSIX-like fashion \cite{unix}:
\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.
+This scheme is known as ``Pipes and Filters architectural pattern'' \cite{patterns}.
By inserting additional ``filters'', the bootstrapping process can be customized
without changing any of the involved programs:
\subsubsection{Configuration via command-line arguments}
The behavior of \myprog{} itself can be adjusted via command-line arguments (only).
-The syntax for their application follows the POSIX standard TODO.
+%The syntax for their application follows the POSIX standard \cite{posix} (no!).
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}).
while not addressing any real difficulties.
The command-line arguments \myprog{} currently supports are
-described in table \ref{if_tbl_arguments_desc},
+described in table \ref{if_tbl_arguments_desc};
their default values are listed in table \ref{if_tbl_arguments_def}.
There is currently no switch to set the output format, since the only supported
output format, besides \osl{}, is a low-level output format for debugging purposes.
\myprog{} provides or that can be achieved by scripts or programs modifying their
input automatically.
Because of \osl{} being a subset of \name{OWL} (see the specification
-of \osl{} in section \ref{oslspec}), he can thereby take advantage of editors
+of \osl{} in section \ref{osl_spec}), he can thereby take advantage of editors
supporting syntax highlighting or other features making the handling of
the respective \name{OWL} serialization more comfortable.
done\\
rm oldsum newsum\\
\# notify web admin via e-mail:\\
- mutt -s "Re-bootstrapping necessary" web-admin@myserver.org}
+ date | mutt -s "Re-bootstrapping necessary" web-admin@myserver.org}
Another possible example is the integration of \myprog{} into a shell script
that bootstraps all databases on a server:
Since the programming language used to implement \myprog{} is \name{Java},
it is possible to deploy it on all platforms offering the
-\name{Java Runtime Environment} TODO.
+\name{Java} Runtime Environment TODO.
Additionally, it is possible to deploy it as a Web application TODO.
To simplify integration on the code level, the architecture of \myprog{} was
this of course has to be implemented.
If not, it is sufficient to replace the used \code{Logger} object by anohter one
providing the desired behavior, since the \code{Logger} class is part of the
-\name{Java} API and widely used TODO.
+\name{Java} API and widely used \cite{log}.
This is a good example of how using well-known and commonly used classes can
greatly improve modularity and reusability.
\section{Numbers and statistics}
\label{stats}
-TODO: Retrieval times, (NC)LOC and other statistics
+
+The following numbers and statistics can be stated about \myprog{}, version $1.0$:
+
+\begin{table}[H]\begin{centering}
+ \begin{tabular}{p{8.4cm}|p{3.1cm}|p{4.5cm}}
+ \textbf{Subject} & \textbf{Value} & \textbf{Details in sections} \\ \hline
+ Number of classes/interfaces & 45 & \ref{fine}, \ref{code_classes}, \ref{code_interfaces} \\
+ Number of packages & 11 & \ref{coarse}, \ref{code_packages} \\
+ Classes per package & ca 4.1 & \ref{coarse} \\
+ Number of methods & TODO & \\
+ Number of comments & & \ref{comments} \\
+ Number of \name{Javadoc} comments & & \ref{comments}, \ref{tools} (TODO) \\
+ Number of non-\name{Javadoc} comments & & \ref{comments} \\
+ Average length of non-\name{Javadoc} comments & & \ref{comments} \\
+ Lines of code (LOC) & TODO \\
+ Non-comment lines of code (NCLOC) & TODO \\
+ Average NCLOC length & TODO & \\
+ NCLOC per comment & TODO & \ref{comments} \\
+ NCLOC per function & TODO \\
+ NCLOC per class & TODO \\
+ NCLOC per package & TODO \\
+ Average NCLOC per method & TODO & \ref{comments} \\
+ TODO: Method/class coupling & TODO & \ref{fine} \\
+ Deepest nesting level & 5 & \ref{speaking} \\ \hline
+ Retrieval time for \hyperref[example_schema]{example schema} & TODO & \ref{benchmarking} \\
+ Bootstrapping time for \hyperref[example_schema]{example schema} & TODO & \ref{benchmarking} \\
+ \end{tabular}
+ \caption{Numbers and statistics about \myprog{}}
+ \label{stats_tbl}
+\end{centering}\end{table}
+
+\subsection{Benchmarking details}
+\label{benchmarking}
+\subsubsection{The example schema}
+\label{example_schema}
+TODO: description, URI
+
+\subsubsection{The benchmark process}
+\label{benchmark_process}
+TODO: description
+
+\subsubsection{The benchmark system}
+\label{benchmark_system}
+TODO: description
\section{Tools employed}
\label{tools}
+
+Several tools were used for the creation of \myprog{}, some of which also
+proved useful during the creation of this thesis.
+There use is described briefly in this section.
+
+Thank is proffered to the contributers of these tools, all of which are free
+and open-source software TODO.
+
+\subsubsection{Debian GNU/Linux}
+The operating system to run the other tools on was \name{Debian GNU/Linux},
+version $8.0$ (``Jessie'').
+
+\subsubsection{Basic Unix tools}
+Some of the basic Unix shell tools, namely \name{find}, \name{cat}, \name{grep},
+\name{sed}, \name{less}, \name{diff}
+and, of course, the shell itself (\name{bash} was used) were very
+useful, for instance, for searching all source code files for common errors
+or for remains of obsolete constructs that were replaced,
+for carrying out changes on all source files and
+for detecting and removing debugging code.
+
+All of the tools were implementations created as part of the \name{GNU} project.
+
+\subsubsection{\name{git}}
+\name{git} was used both for version control and for shared access to the
+source code and related artifacts.
+
+\subsubsection{\name{vim}}
+To apply changes involving advanced regular expressions, to perform block editing
+(insert or remove columns from multiple lines at once), to insert debugging code
+and similar editing tasks, \name{vim} was very useful.
+
+\subsubsection{\name{Eclipse}}
+The IDE to develop the program in was \name{Eclipse}.
+It proved very useful particularly due to its abilities to easily create
+packages and move source files between them, to ease the creation of in-code
+documentation and other useful features like automatic indention or the
+automatic insertion of \code{final} keywords.
+
+\subsubsection{\name{OpenJDK}}
+The \name{Java} compiler, the \name{Javadoc} tool (see next paragraph),
+the \name{Java} debugger and the \name{Java} Runtime Environment
+used were the implementations provided by
+the \name{OpenJDK} project, version $7$.
+
+\subsubsection{\name{Javadoc}}
+\name{Javadoc} was used as the primary documentation generation system due to
+its ability to create clear and well-arranged documentations.
+Besides, documentations created by \name{Javadoc} are familiar to most
+\name{Java} programmers and cleanly integrate into the \name{Java} environment;
+for example, methods (automatically) inherited from the \code{Object}
+class are incorporated and links to methods and classes
+provided by the \name{Java} API are automatically generated.
+
+\subsubsection{\name{Doxygen}}
+To complement the documentation generated by \name{Javadoc} (see previous
+paragraph), \name{Doxygen} was used, which supports all used \name{Javadoc}
+constructs.
+This was particularly sensible, because \name{Doxygen} is able to create a
+much more in-depth documentation, that for instance includes \code{private}
+and \code{protected} members, the complete source code with syntax highlighting
+and references to it and detailed dependency and call graphs for all classes
+or methods, respectively.
+Thus, the \name{Doxygen} documentation is meant to be a more extensive,
+detail-oriented documentation providing insight into implementation issues.
\section{Versioning}
\label{versioning}
+
+As mentioned in the introduction of \hyperref[program]{this section},
+the program version of \myprog{} described so far is version $1.0$.
+
+However, since \name{git} was used to manage the source code artifacts and the
+software has not been productively used, there basically was no need for an
+explicit versioning; if necessary versions could be identified by the commit name
+generated by \name{git} or their commit date.
+For this reason, an explicit versioning scheme used for the very first
+versions of \myprog{} was quickly abandoned and for now, version $1.0$ is regarded
+as the only version having a version number assigned.
+
+The following table lists important milestones of the \myprog{} software,
+using the commit date, their \name{git} commit name and, in case of version $1.0$,
+their version number for identification:
+
+\begin{table}[H]\begin{centering}
+ \begin{tabular}{p{3.1cm}|p{12.9cm}}
+ \textbf{Version date} & \textbf{Commit name and description} \\ \hline
+ 27.12.2015 & \code{0f3690720a329ba8a3981948ebd822a20a41fa5b} \\ &
+ Early prototype without support for important features and containing
+ some bugs, but internally already closely resembling version $1.0$ \\
+ 07.01.2016 & \code{1f0ae35c566603c7c24115284fd7a66057b17617} \\ &
+ First version that produces correct OBDA specifications \\
+ 07.01.2016 & \code{9682a863b62fef15ae952e7cd46d213ea4344ca9} \\ &
+ OSL output added \\
+ 24.01.2016 & \code{4052000d3d8a3fea402fbf00d06531eed6201a35} \\ &
+ Command-line arguments added \\
+ 11.02.2016 & \code{42fec808ea13a2131fe6d19869024fd9ca34543f} \\ &
+ First version producing correct \osl{} output, regarding the
+ specification of \osl{} as described in section \ref{osl_spec}. \\
+ 12.02.2016 & \code{e197c9cf47730c72d65d3fe9fbed364dabcb222d} \\ &
+ Version tested by the Logic and Intelligent Data research group at the
+ University of Oslo (no issues were reported) \\
+ TODO (v1.0) & TODO \\ &
+ Version described in this thesis, including minor improvements \\
+ TODO & TODO \\ &
+ New features added
+ \end{tabular}
+ \caption{Important milestones of \myprog{}}
+ \label{version_tbl}
+\end{centering}\end{table}
git://git.uio.no / u / philim / db2osl_thesis.git / commitdiff
