Major change
authorPhilipp Martis <>
Thu, 19 May 2016 17:59:05 +0000 (19:59 +0200)
committerPhilipp Martis <>
Fri, 20 May 2016 06:51:16 +0000 (08:51 +0200)
Change involving restructuring (chapter 4 was split up)
and additional subsections
Due to this restructuring, the files program_code.tex and
program_tools.tex were renamed and furthermore, osl.tex
was split up; besides this, there were only slight changes -
as regards content, only one short paragraph is added (to
Much new content is added in Chapter 2 and Chapter 3.
Bibliography was changed and extended.

27 files changed:
Bachelor thesis.pdf
Bachelor thesis.tex
Images/bootstrapping_materialized.pdf [new file with mode: 0644]
Images/bootstrapping_virtual.pdf [new file with mode: 0644]
Images/direct_graph.pdf [new file with mode: 0644]
Images/specification_structure.pdf [new file with mode: 0644]
bootstrapping.tex [new file with mode: 0644]
bootstrapping_dirm.tex [new file with mode: 0644]
bootstrapping_iris.tex [new file with mode: 0644]
bootstrapping_spec.tex [new file with mode: 0644]
impl.tex [new file with mode: 0644]
impl_code.tex [moved from program_code.tex with 94% similarity]
impl_tools.tex [moved from program_tools.tex with 98% similarity]
osl_intro.tex [new file with mode: 0644]
osl_spec.tex [new file with mode: 0644]
program_versioning.tex [deleted file]

index 11e89fa..4832bc7 100644 (file)
Binary files a/Bachelor thesis.pdf and b/Bachelor thesis.pdf differ
index 7b82baf..00038c2 100644 (file)
@@ -8,6 +8,8 @@
        relational databases}
+\newcommand{\osllong}{\name{OBDA Specification Language}}
+\newcommand{\oslboth}{\osllong{} (\osl{})}
 % Bilder / Graphiken
 % Mathematische Symbole etc.
             supervisor={M. Sc. Leif Harald Karlsen},
             startdate={23rd of November 2015},
             enddate={24th of May 2016},
-            crk={D.0},
+            crk={D.0, H.2.8},
 % Appendix
 % Background
+% On bootstrapping and IRI generation
 % The OBDA Specification Language (OSL)
 % The db2osl software
+% Implementation aspects of \name{db2osl}
 % Summary
diff --git a/Images/bootstrapping_materialized.pdf b/Images/bootstrapping_materialized.pdf
new file mode 100644 (file)
index 0000000..513cc38
Binary files /dev/null and b/Images/bootstrapping_materialized.pdf differ
diff --git a/Images/bootstrapping_virtual.pdf b/Images/bootstrapping_virtual.pdf
new file mode 100644 (file)
index 0000000..8421dab
Binary files /dev/null and b/Images/bootstrapping_virtual.pdf differ
diff --git a/Images/direct_graph.pdf b/Images/direct_graph.pdf
new file mode 100644 (file)
index 0000000..e1c12c9
Binary files /dev/null and b/Images/direct_graph.pdf differ
diff --git a/Images/specification_structure.pdf b/Images/specification_structure.pdf
new file mode 100644 (file)
index 0000000..effeb1e
Binary files /dev/null and b/Images/specification_structure.pdf differ
index 02340dd..4a24fd6 100644 (file)
Binary files a/OSL-Specification.pdf and b/OSL-Specification.pdf differ
index 8e191b6..f2e82ff 100644 (file)
@@ -8,6 +8,8 @@
+\newcommand{\osllong}{\name{OBDA Specification Language}}
+\newcommand{\oslboth}{\osllong{} (\osl{})}
@@ -60,7 +62,8 @@
 % Bilder / Graphiken
 % The OBDA Specification Language (OSL)
+% Generating unique IRIs for OBDA specification entities
+%\chapter{IRI generation}
 %% The db2osl software
+%% Implementation aspects of \name{db2osl}
 %% Summary
index 766877c..ca25707 100644 (file)
 \chapter{Background and related work}
-TODO: Grundlagen (?)\\
-As explained in section \fullref{motivation}, the sole bootstrapping of
+\subsection{Ontology-based data access (OBDA)}
+TODO: References
+Storing data in relational databases is a very common proceeding, since the
+notion of a relational database is comprehensible and widely known, while the
+required software is widely available both commercially and as open-source
+Thus, it is easy for a domain expert to set up and populate a database.
+Furthermore, relational databases provide significant advantages concerning
+performance, data consistency and integrity, integration abilities, support
+and general prominence.
+These topics definitely played a major role in the success and the extensive
+exploration that databases discovered, up to the degree that these are the
+main fields the strengths of databases are seen in.
+Many -- if not all -- of these strengths trace back to the relatively fixed
+and rigid schema databases embody: a well-defined database schema imposing
+strong and clear cut constraints on the contained data.
+However, this principle also induces notable disadvantages.
+The database schema, although theoretically changeable, constitutes a
+significant burden on TODO the representation of data of dynamic
+environments, incomplete data or changing requirements,
+especially when dealing with large amounts of data.
+The resulting representation of data in unintuitive, suboptimal schemata
+makes the use of prolonged and complex query constructs inevitable, which
+lets more elaborate queries quickly become unmanageable for non-experts
+and time-consuming and error-prone even for experts.
+Ontologies, on the other hand, are much more flexible regarding incomplete
+data or changing requirements or environments and allow for much more
+intuitive and abstract query systems, while still being a quite
+comprehensible formalism
+(see Section~\ref{ontologies} for publications describing
+ontologies and the semantic web).
+Besides, ontologies provide support for different data records referencing
+the same entity, while databases do not \cite{eng}, and for the deduction of
+implicit information \cite{eng}, which with common database systems, if at
+all, is at least not possible out of the box and in an easy manner.
+Often, however, relational databases are preferred for their advantages
+(although the availability of cheaper yet more powerful hardware in some
+cases offsets these) or simply erroneously.
+Besides, in some cases, the migration to ontology-based systems,
+even if beneficial, is to costly to be seriously considered.
+%, often due to the large amounts of data that would have to be converted.
+Ontology-based data access often provides a solution to this collision of
+By adding an ontology-based front-end processing the queries that is
+sensibly mapped to the data representation,
+the querying facilities of ontology-based systems are introduced,
+and changes in the data representation most often can be carried out
+without breaking existing queries; only the mapping has to be changed
+-- in a one-time effort -- and only when it introduces changes in the way
+it presents existing structures to the user, existing queries have to be
+The creation of these mappings in turn can happen computer-aided or, in
+simple cases or to a certain degree of completeness and accuracy,
+the mappings can be completely bootstrapped.
+Moreover, in cases where it is to costly or for other cases infeasible
+to carry out a complete data duplication, the data can remain in the
+underlying database as is and the query front-end merely acts as an
+interface transforming the query into a database query \cite{eng} by
+making use of a backward-chaining technique called \emph{query rewriting}
+This approach is called \emph{virtual OBDA} or \emph{virtual RDF view}
+\cite{eng} and is illustrated in Figure~\ref{back_subfig_virtual}.
+The oppositional approach of duplicating all data is called
+\emph{materialized OBDA} or \emph{materialized RDF view} and is
+illustrated in Figure~\ref{back_subfig_materialized}.
+Virtual OBDA provides limited abilities compared to materialized OBDA
+in that it does not allow for decoupling from the source data by for
+example adding inferred information or applying elaborate transformations
+and does not support ``fragments of OWL for which query
+rewriting is not a complete deduction method'' \cite{eng}.
+However, the response time of systems is hard to predict solely from the
+architectural approach used, so if it is critical, several systems should
+be prototyped and evaluated upfront on what are expected to be
+typical queries \cite{eng}.
+       \begin{subfigure}[b]{0.8\textwidth}
+                       \includegraphics[scale=1.2]{Images/bootstrapping_materialized.pdf}
+                       \caption{OBDA system architecture with materialized \name{RDF} view}
+                       \label{back_subfig_materialized}
+       \end{subfigure}\\~\\
+       \begin{subfigure}[b]{0.8\textwidth}
+                       \includegraphics[scale=1.2]{Images/bootstrapping_virtual.pdf}
+                       \caption{OBDA system architecture with a virtual \name{RDF} view}
+                       \label{back_subfig_virtual}
+       \end{subfigure}
+       \caption[The two basic OBDA system architectures]
+               {The two basic OBDA system architectures:
+               materialized and virtual \name{RDF} views (from \cite{eng})}
+       \label{back_fig_bootstrapping}
+Finally, it has to be mentioned, that ontology-based data access is not
+limited to databases.
+Although this is the most common scenario and the only one this thesis
+deals with, ontology-based data access also works with other sources of
+structured information, like \name{ODS}, \name{XLS} or \name{CSV} files,
+though some additional preparation might be necessary in these cases \cite{eng}.
+\subsection{OBDA specifications}
+As mentioned in Section~\fullref{motivation}, the sole bootstrapping of
 \name{RDF} triples \cite{rdf} or other forms of structured information
 from relational database schemata is a relatively well understood topic.
+This is outlined more comprehensively in Section~\fullref{related}.
+Nonetheless, bootstrapping remains an elaborate process involving complex
+tools to be invoked -- possibly in different versions and configurations
+and processing different formats -- and working on changing input data
+This is why Skjæveland and others proposed the introduction of OBDA
+specifications centralizing the task of driving these tools and
+to gather in one place all the information describing the desired mapping
+between the source database and the target ontology \cite{eng}.
+As described in Section~\fullref{related}, their approach is the
+foundation of this thesis, which describes and specifies a format for
+storing and exchanging such OBDA specifications -- the \oslboth{} -- and
+introduces a tool that in turn automatically bootstraps OBDA Specifications
+from relational database schemata -- the \myprog{} software.
-TODO: OPTIQUE \cite{optique}
+The bootstrapping process using OBDA specifications and \myprog{} is
+illustrated in Figure~\ref{intro_fig_bootstrapping}
+in Section~\fullref{approach}.
+\subsection{The \name{OPTIQUE} project}
+The problems addressed in Section~\fullref{motivation} are a big issue
+inter alia TODO in the oil and gas industry:
+$30 \%$ to $70 \%$ of the working time of engineers is spent on collecting
+data or assessing its quality \cite{crompton}.
+This led to the origination of the \name{OPTIQUE} project in TODO which
+``advocates for a next generation of the well known Ontology-Based Data Access
+(OBDA) approach to address the data access problem [...] [aiming] at
+solutions that reduce the cost of data access dramatically'' \cite{optique}.
+Thus, the \name{OPTIQUE} project tries to reach exactly the benefits a
+well-developed OBDA system can provide (explained in Section~\ref{obda}):
+an easy end-user access to data without knowing about its structuring
+while taking advantage of automatic translations \cite{optique2}.
+In doing so, ascertained shortcomings of existing OBDA systems were addressed:
+\emph{usability} (for example the need to use formal query languages),
+\emph{costly prerequisites} (consider, for example, the disadvantages
+of materialized OBDA described in Section~\ref{obda}) and
+\emph{efficiency} (which was perceived as being insufficiently addressed
+in previous approaches) \cite{optique}.
 \section{Related work}
+\subsection{Ontologies and the semantic web -- publications}
+\subsection{OBDA specifications -- publications}
+A publication building the foundation of the work presented in this thesis, is
+the summarizing and benchmarking work on OBDA specifications by Skjæveland et al.
+\cite{eng}, the group that developed them in their present form.
+\subsection{OBDA systems -- publications}
+\subsection{General ontology bootstrapping -- publications}
+Skjæveland, Lian and Horrocks \cite{npd} provided an exemplifying description of
+the transformation of the \emph{NPD FactPages}, an enormous collection of data
+related to oil drilling on the Norwegian continental shelf, provided by
+the Norwegian Petroleum Dictorate (NPD).
+Sequeda et al. \cite{survey} provided an overview over different
+direct mapping approaches.
+Sequeda, Arenas and Miranker \cite{ondirm} \cite{autodirm}
+describe the direct mapping of relational databases to \name{RDF}
+and \name{OWL} formally.
+Stojanovic, Stojanovic and Volz \cite{sac} published a formal description of
+the mapping of relational databases onto ontology-based structures, describing
+concepts preceding and/or supplementing \name{OWL} and using \name{F-LOGIC} TODO
+as target language.
+\subsection{The \name{OPTIQUE} project -- publications}
+Calvanese et al. \cite{optique2} presented the \name{OPTIQUE} project including
+its underlying OBDA system and showed limitations of current OBDA systems.
+Kharlamov et al. \cite{optique} described the first version of the \name{OPTIQUE}
+system, customized for use with the \emph{NPD FactPages} of the
+Norwegian Petroleum Dictorate (NPD).
+Skjæveland and Lian \cite{benefits} summarized the benefits of and the
+proceeding for converting the \name{NPD FactPages} to linked data \cite{linked}
+and discuss associated terms like linked data, URIs, \name{RDF} and
+\subsection{Alternative approaches -- publications}
+Barrasa, Corcho and P{\'e}rez \cite{r2o} proposed a declarative mapping
+language -- \name{r2o} -- able to express a mapping between a relational
+database and ontologies represented in the \name{OWL} and \name{RDF} formats.
+This approach however aims at connecting existing databases
+and existing ontologies.
index d3acd4d..6bfc84f 100644 (file)
   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 = {},
   booktitle = {International Semantic Web Conference (Posters \& Demos)},
-  crossref = {conf/semweb/2013p},
   editor = {Blomqvist, Eva and Groza, Tudor},
   ee = {},
   interhash = {ee631e8fa9c8764e12ef94e82b4458a2},
@@ -279,3 +278,36 @@ month={April},
   url = {},
   year = 1989
+       author={J. A. Miller and G. T. Baramidze and A. P. Sheth and P. A. Fishwick},
+       booktitle={Simulation Symposium, 2004. Proceedings. 37th Annual},
+       title={Investigating ontologies for simulation modeling},
+       year={2004},
+       pages={55-63},
+       keywords={Internet;data mining;discrete event simulation;modelling;DeMO;Web-accessible ontologies;discrete-event modeling ontology;discrete-event simulation;domain knowledge capturing;domain organization;heterogeneous information source integration;knowledge discovery;prototype OWL-based ontology;semantic browsing;semantic search;simulation modeling;Biological system modeling;Computational modeling;Computer science;Discrete event simulation;Ontologies;Organizing;Search engines;Taxonomy;Vocabulary;XML},
+       doi={10.1109/SIMSYM.2004.1299465},
+       ISSN={1080-241X},
+       month={April},}
+       shorthand={NCFK\textsuperscript{+}03},
+       title={Protege-2000: an open-source ontology-development and knowledge-acquisition environment},
+       author={Noy, Natalya F and Crub{\'e}zy, Monica and Fergerson, Ray W and Knublauch, Holger and Tu, Samson W and Vendetti, Jennifer and Musen, Mark A and others},
+       booktitle={AMIA Annu Symp Proc},
+       volume={953},
+       pages={953},
+       year={2003}
+       title={TODO: Keynote talk at the W3C Workshop on Sem. Web in Oil \& Gas Industry},
+       author={Crompton, J.},
+       url={},
+       year={2008}
+       title={TODO: R\textsubscript{2}O, an Extensible and Semantically Based Database-to-ontology Mapping Language},
+       author={Barrasa and Corcho and G{\'o}mez-P{\'e}rez},
diff --git a/bootstrapping.tex b/bootstrapping.tex
new file mode 100644 (file)
index 0000000..aed10a8
--- /dev/null
@@ -0,0 +1,8 @@
+\chapter{On bootstrapping and IRI generation}
diff --git a/bootstrapping_dirm.tex b/bootstrapping_dirm.tex
new file mode 100644 (file)
index 0000000..adbef6a
--- /dev/null
@@ -0,0 +1,90 @@
+\section{Ontology bootstrapping using direct mapping}
+As its name suggests, the direct mapping approach is a relatively simple
+and straight forward approach.
+Direct mapping is currently a \name{W3C} recommendation, which defines the
+production of an \name{RDF} graph TODO -- which is called the
+\emph{direct graph} -- from a relational schema \cite{dirm}.
+As a matter of fact, the main definition of the direct graph, excluding
+definitions of rather trivial subcomponents, fits on one computer screen.
+The direct graph contains all data held in the source database but it
+does not contain additional schema information like uniqueness of or
+non-null constraints on columns \cite{dirm}.
+\subsection{Overview on the direct graph}
+The constitution of the direct graph is illustrated in
+Its basic components are, for each row, the \emph{row type triple},
+its \emph{literal triple}s and its \emph{reference triple}s.
+Here, the row type triple encodes which table the respective row
+belongs to, the literal triples encode the data in non-foreign-key
+columns and the reference triples encode the data in foreign key
+These triples are then by degrees united to the direct graph:
+the row triples of each row form the row graph, the row graphs of
+each table form the table graph and all table graphs united
+constitute the final direct graph.
+               \includegraphics[scale=0.86]{Images/direct_graph.pdf}
+               \caption[Constitution of the \emph{direct graph}]{
+                       Constitution of the \emph{direct graph}.
+                       ``$\rightarrow$'' means ``is part of''.}
+               \label{dirm_fig_direct_graph}
+Carefully assigning IRIs to the \name{RDF} entities is an essential
+part of the approach, since otherwise, name clashes can occur.
+Indeed, there seems to be a corner case which was not considered.
+For details on IRI generation in direct mapping, see
+\subsection{Data representation in direct mapping}
+Since the result of a direct mapping is an \name{RDF} graph, the
+means to represent data are limited to valid \name{RDF} vocabulary.
+This is no problem for IRIs and expressions that only involve IRIs
+(row type triples and reference triples).
+To encode the non-foreign-key data content of the source database,
+thus literal triples, the \name{R2RML} mapping language is used,
+a language providing a mapping from the relational data model to
+the \name{RDF} data model \cite{r2rml}.
+\name{R2RML} expressions thereby are by themselves \name{RDF} statements.
+The data value contained in a direct mapping literal triple is
+defined to be the \emph{R2RML natural RDF literal} representation of
+the value \cite{dirm}, which, as the name suggests, is a single
+\name{RDF} literal \cite{r2rml}.
+\subsection{IRI generation in direct mapping}
+As all \name{RDF} triples generated by the direct mapping are simply
+united to constitute the final \emph{direct graph}
+(see Section~\fullref{dirm_overview} for details),
+a senseful IRI assigning is vital to the functioning of the approach.
+By design, IRIs for different kinds of entities have a different
+structure, which prevents name clashes on the one hand, but on the other
+hand induces that, in case of a clash, all entities with the conflicting
+IRI are of the same kind, which means a high risk of producing ambiguous
+information and thus losing data.
+The relatively simple way IRIs are assigned in direct mapping is
+described in the following \cite{dirm}:
+       \item Table IRIs correspond to the table name.
+       \item Literal property IRIs consist of the table name and the
+       column name, separated by a hash character (`\#').
+       \item Reference property IRIs consist of the parent table name, the
+       string ``\#ref-'' and the parent table column names of the
+       respective foreign key, separated by a semicolon (`;').
+       \item All contained names are included in their percent-encoded
+       form TODO.
+The encoding of reference property IRIs can lead to name clashes in the
+corner case that multiple foreign keys exist which contain exactly the
+same columns -- which is allowed for example in \name{MYSQL} TODO.
+To remove this flaw, the child table name and the child table column
+names of the respective foreign key also must be included in the IRI.
diff --git a/bootstrapping_iris.tex b/bootstrapping_iris.tex
new file mode 100644 (file)
index 0000000..ebbf05c
--- /dev/null
@@ -0,0 +1,2 @@
+\section{Generating unique IRIs for OBDA specification entities}
diff --git a/bootstrapping_spec.tex b/bootstrapping_spec.tex
new file mode 100644 (file)
index 0000000..b2f67e0
--- /dev/null
@@ -0,0 +1,33 @@
+\section{Ontology bootstrapping using OBDA specifications}
+\subsection{Structure of OBDA specifications}
+An OBDA specification consists of several so-called ``maps'', which are
+data records containing data and references to each other describing
+parts of the OBDA specification in statically defined fields \cite{eng}.
+For different aspects of the specification, there are different map types,
+while usually several maps exist for each type.
+Namely, these are \emph{Entity maps} describing database tables,
+\emph{Attribute maps} describing database columns,
+\emph{Identifier maps} describing database primary keys,
+\emph{Relation maps} describing database foreign keys,
+\emph{Subtype maps} describing ``is-a'' relationships in the data and
+\emph{Translation tables} describing desired translations of data.
+The fields of the several types of maps and their interconnection via
+references is shown in Figure~\ref{spec_fig_structure}.
+               \includegraphics[scale=1.0]{Images/specification_structure.pdf}
+               \caption[Constitution of an OBDA specification]{
+                       Constitution of an OBDA specification.
+                       ``$\rightarrow$'' means ``references''. (from \cite{eng})}
+               \label{spec_fig_structure}
+While ,
+Subtype maps and Translation tables.
+\subsection{Using OBDA specifiations}
+\subsection{Bootstrapping OBDA specifications}
diff --git a/impl.tex b/impl.tex
new file mode 100644 (file)
index 0000000..7bd9bf8
--- /dev/null
+++ b/impl.tex
@@ -0,0 +1,12 @@
+\chapter{Implementation of \name{db2osl}}
+TODO: intro
+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.
similarity index 94%
rename from program_code.tex
rename to impl_code.tex
index 4b6c112..5a00b3c 100644 (file)
@@ -21,7 +21,7 @@ to yield clean, readable and extensible code.
 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 effacing the ambiguity with comments.
-This approach is further explained in section \fullref{speaking} and
+This approach is further explained in Section~\fullref{speaking} and
 rendered many uses of comments unnecessary.
 In fact, the number of (plain, e.g. non-\name{Javadoc}) comments was
@@ -55,12 +55,12 @@ of the used \name{Javadoc} comments \cite{doxygen} (but not vice versa \cite{jav
 \subsection{``Speaking code''}
-As mentioned in section \fullref{comments}, the code was tried to be designed to
+As mentioned in Section~\fullref{comments}, the code was tried to be designed to
 ``speak for itself'' as much as possible instead of making its readers depend on
 comments that provide an understanding.
 In doing so, besides reducing code size due to the missing comments,
 clean code amenable to unfamiliar readers and unpredictable changes was enforced.
-This is especially important since, as described in section \fullref{arch},
+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.
@@ -79,7 +79,7 @@ conceived as ``speaking code'':
 ~\\The rest of this section describes these topics in some detail.
 Besides, an intuitive architecture and suitable, well-designed libraries
-also contribute to the clarity of the code.
+also contributed to the clarity of the code (TODO: move).
 \subsubsection{Meaningful typing}
 Meaningful typing includes the direct mapping of entities of the modeled world
@@ -195,8 +195,8 @@ 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},
+const correctness (see Paragraph~``\nameref{const}''
+in Section~\fullref{code_classes} TODO), 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
@@ -256,7 +256,12 @@ In this case, since the two \code{Boolean} objects are compared for identity \ci
 the former comparison can return \code{false}, even when the two boolean values are in fact
 the same.
 However, since this case was considered much less common than cases in which the other
-solution could make programmers making mistakes produce undetected errors, it was preferred.
+solution could make incautious programmers introduce subtle errors, it was preferred.
+Besides, wrapper classes like \code{Boolean}, \code{Integer}, \code{Long}
+and \code{Float} are an integral part of the \name{Java} language \cite{java},
+so \name{Java} programmers were expected to manage to use them properly, so
+ultimately, since the new solution effectively prevents errors while
+abstaining from introducing new artifacts, it was considered fair and clean.
 TODO: summary
@@ -275,11 +280,11 @@ as described and recommended by Stroustrup \cite{str3}, proved to be extremely u
 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
+As described in Section~\fullref{speaking}, class names were chosen to be concise
 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}.
+For details about package use, see Section~\fullref{code_packages}.
 Care was taken not to introduce unnecessary classes, thereby complicating
 code structure and increasing the number of source files and program entities.
@@ -368,7 +373,7 @@ 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 \fullref{fine}, all program classes either
+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
 So, except from the standalone classes, an interface existed anyway, either
@@ -382,7 +387,7 @@ unnecessary at least, if not messy.
 \subsection{Use of packages}
-As mentioned in section \fullref{code_classes}, class names were chosen to be
+As mentioned in Section~\fullref{code_classes}, class names were chosen to be
 concise but nevertheless expressive.
 This only was possible through the use of \name{Java} \code{package}s,
 which also helped structure the program.
@@ -397,7 +402,7 @@ each source file is to be found exactly one directory below the root
 program source directory, which in many cases eases their handling.
 For the description of the packages, their interaction and considerations on
-their structuring, see section \fullref{coarse}.
+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
@@ -405,4 +410,4 @@ Each package is documented in the source code also, namely in a file
 This is a common scheme supported by the \name{Eclipse} IDE as well as the
 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}).
+as described in Section~\fullref{tools}).
similarity index 98%
rename from program_tools.tex
rename to impl_tools.tex
index 010d588..e9644ce 100644 (file)
@@ -3,7 +3,7 @@
 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.
+Their 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.
index 8023712..26d341b 100644 (file)
@@ -14,6 +14,7 @@ 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}.
@@ -40,14 +41,22 @@ and to drive the entire tool chain \cite{eng}.
 This thesis describes the development of a specification language to serialize
 the declarative specification of the bootstrapping process
-(see section \fullref{motivation}) and of a
+(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''.
+Furthermore, this thesis suggests a scheme for generating the IRIs that
+occur in OBDA specification, identifying their parts \cite{eng}.
+Currently, this issue is only exemplified and there is room for improvement
+in that a simple and straight-forward approach can be used to generate
+IRIs for all constituents of OBDA specifications without introducing
+name clashes in corner cases.
+This approach is described in Section~\fullref{iris}.
 Using a declarative specification makes the entire bootstrapping process a
-two-step-procedure, illustrated in figure \ref{intro_fig_bootstrapping}:
+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,
@@ -73,8 +82,12 @@ 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 these goals, use of existing tools, languages and conventions was
 made wherever possible.
-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.
+For example, the \osllong{} was defined to be a subset of \name{OWL}.
+This facilitates meeting the objective of a powerful, easy-to-use, flawless and
+well-documented language that can be extended and handled by existing tools.
+To fit into the environment used in the \name{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,
 possibly serving as the basis for a program library in the future.
@@ -88,5 +101,5 @@ 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.
 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}.
+thoroughly in Section~\fullref{code}, while
+the resulting structure of the software is discussed in Section~\fullref{arch}.
diff --git a/osl.tex b/osl.tex
index c5ea8e3..f3652fd 100644 (file)
--- a/osl.tex
+++ b/osl.tex
@@ -1,196 +1,3 @@
-\chapter{The OBDA Specification Language (OSL)}
-TODO: aims, proceeding, structure
-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 \name{OWL}, with data
-properties 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.
-Therefore, an ideal base for the OBDA Specification Language is \name{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 that the language has to represent rather than
-primarily dealing with technical details.
-In particular, many of those details can be formulated as \name{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 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.
-\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,
-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.
-\p \label{spec_ignored} An \osl{} document may contain more \name{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
-from each other (except those which are ignored, see paragraph \ref{spec_ignored}).\\
-It is recommended to use the \texttt{owl:AllDifferent} \name{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 is recommended to use that base IRI as \texttt{xml:base} XML attribute.\\
-IRIs prefixed with \texttt{osl:} are IRIs relative to the IRI\\
-\p An \osl{} document has to import the following ontology
-(referred to as ``the \osl{} header'' in the following):\\
-\p The \name{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\\
-to the \texttt{OWL class URI} field of the respective entity map for entity maps,\\
-to the \texttt{OWL class URI} field of the associated entity map for identifier maps,\\
-to the \texttt{OWL class URI} field of the associated entity map for subtype maps and\\
-to the \texttt{OWL class URI} field of the entity map associated with the respective subtype map
-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 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 weren't empty).
-       \begin{tabular}{l|l}
-               \textbf{Map type} & \textbf{\name{OWL} IRI} \\ \hline
-               Entity map & \textit{$<$class URI$>$}\texttt{\_\_ENTITY\_MAP} \\
-               Attribute map & \textit{$<$property URI$>$}\texttt{\_\_ATTRIBUTE\_MAP} \\
-               Identifier map & \textit{$<$class URI$>$}\texttt{\_\_IDENTIFIER\_MAP} \\
-               Relation map & \textit{$<$property URI$>$}\texttt{\_\_RELATION\_MAP} \\
-               Subtype map & \textit{$<$class URI$>$}\texttt{\_\_SUBTYPE\_MAP} \\
-               Translation table of attribute map &
-                       \textit{$<$property URI$>$}\texttt{\_\_ATTRIBUTE\_MAP\_\_TRANSLATION\_TABLE} \\
-               Translation table of subtype map &
-                       \textit{$<$class URI$>$}\texttt{\_\_SUBTYPE\_MAP\_\_TRANSLATION\_TABLE} \\
-       \end{tabular}
-       \caption{\name{OWL} individual IRIs in \osl{}}
-       \label{spec_tbl_indv_iris}
-\p The \name{OWL} individuals described by the \osl{} document representing
-the certain types of OBDA maps
-must be of the \name{OWL} types specified in table \ref{spec_tbl_types}
-(for base IRIs, see paragraph \ref{spec_base}).
-               \begin{tabular}{l|l}
-                       \textbf{Map type} & \textbf{\name{OWL} class IRI} \\ \hline
-                       Entity map & \texttt{osl:EntityMap} \\
-                       Attribute map & \texttt{osl:AttributeMap} \\
-                       Identifier map & \texttt{osl:IdentifierMap} \\
-                       Relation map & \texttt{osl:RelationMap} \\
-                       Subtype map & \texttt{osl:SubtypeMap} \\
-                       Translation table & \texttt{osl:TranslationTable} \\
-               \end{tabular}
-               \caption{\name{OWL} class membership of map representations in \osl{}}
-               \label{spec_tbl_types}
-\p The \name{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}).
-               \begin{tabular}{l|l|l|l}
-                       \textbf{Map type} & \textbf{Field label} & \textbf{Field name} & \textbf{\name{OWL} IRI} \\ \hline
-                       Entity map & \texttt{E1} & \texttt{Table name} & \texttt{osl:em\_\_tableName} \\
-                       Entity map & \texttt{E2} & \texttt{Label} & \texttt{osl:em\_\_label} \\
-                       Entity map & \texttt{E3} & \texttt{Identifier map} & \texttt{osl:em\_\_identifierMap} \\
-                       Entity map & \texttt{E4} & \texttt{Attribute maps...} & \texttt{osl:em\_\_attributeMaps} \\
-                       Entity map & \texttt{E5} & \texttt{OWL class URI} & \texttt{osl:em\_\_owlClassURI} \\
-                       Entity map & \texttt{E6} & \texttt{Description} & \texttt{osl:em\_\_description} \\ \hline
-                       Attribute map & \texttt{A1} & \texttt{Column name} & \texttt{osl:am\_\_columnName} \\
-                       Attribute map & \texttt{A2} & \texttt{SQL datatype} & \texttt{osl:am\_\_sqlDatatype} \\
-                       Attribute map & \texttt{A3} & \texttt{Mandatory} & \texttt{osl:am\_\_mandatory} \\
-                       Attribute map & \texttt{A4} & \texttt{Label} & \texttt{osl:am\_\_label} \\
-                       Attribute map & \texttt{A5} & \texttt{OWL property URI} & \texttt{osl:am\_\_owlPropertyURI} \\
-                       Attribute map & \texttt{A6} & \texttt{Property type} & \texttt{osl:am\_\_propertyType} \\
-                       Attribute map & \texttt{A7} & \texttt{Translation} & \texttt{osl:am\_\_translation} \\
-                       Attribute map & \texttt{A8} & \texttt{URI pattern} & \texttt{osl:am\_\_uriPattern} \\
-                       Attribute map & \texttt{A9} & \texttt{RDF language} & \texttt{osl:am\_\_rdfLanguage} \\
-                       Attribute map & \texttt{A10} & \texttt{XSD datatype} & \texttt{osl:am\_\_xsdDatatype} \\
-                       Attribute map & \texttt{A11} & \texttt{Description} & \texttt{osl:am\_\_description} \\ \hline
-                       Identifier map & \texttt{I1} & \texttt{Entity map} & \texttt{osl:im\_\_entityMap} \\
-                       Identifier map & \texttt{I2} & \texttt{Attribute maps...} & \texttt{osl:im\_\_attributeMaps} \\
-                       Identifier map & \texttt{I3} & \texttt{URI pattern} & \texttt{osl:im\_\_uriPattern} \\ \hline
-                       Relation map & \texttt{R1} & \texttt{Source entity map} & \texttt{osl:rm\_\_sourceEntityMap} \\
-                       Relation map & \texttt{R2} & \texttt{Source column} &
-                               \texttt{osl:rm\_\_sourceColumn\textcolor{red}{\textbf{s}}} \\
-                       Relation map & \texttt{R3} & \texttt{Target entity map} & \texttt{osl:rm\_\_targetEntityMap} \\
-                       Relation map & \texttt{R4} & \texttt{Target column} &
-                               \texttt{osl:rm\_\_targetColumn\textcolor{red}{\textbf{s}}} \\
-                       Relation map & \texttt{R5} & \texttt{OWL property URI} & \texttt{osl:rm\_\_owlPropertyURI} \\ \hline
-                       Subtype map & \texttt{S1} & \texttt{Entity Map} & \texttt{osl:sm\_\_entityMap} \\
-                       Subtype map & \texttt{S2} & \texttt{Column Name} & \texttt{osl:sm\_\_columnName} \\
-                       Subtype map & \texttt{S3} & \texttt{OWL superclass URI} & \texttt{osl:sm\_\_owlSuperclassURI} \\
-                       Subtype map & \texttt{S4} & \texttt{Prefix} & \texttt{osl:sm\_\_prefix} \\
-                       Subtype map & \texttt{S5} & \texttt{Suffix} & \texttt{osl:sm\_\_suffix} \\
-                       Subtype map & \texttt{S6} & \texttt{Translation} & \texttt{osl:sm\_\_translation} \\ \hline
-                       Translation table & \texttt{T1} & \texttt{Source value...} &
-                               \texttt{osl:tt\_\_sourceValue\textcolor{red}{\textbf{s}}} \\
-                       Translation table & \texttt{T2} & \texttt{RDF ressource...} &
-                               \texttt{osl:tt\_\_rdfRessource\textcolor{red}{\textbf{s}}} \\
-               \end{tabular}
-               \caption{\name{OWL} property IRIs in \osl{}}
-               \label{spec_tbl_prop_iris}
-\p The following \name{OWL} properties in the \osl{} document refer
-to lists of elements:
-       \item[] \texttt{osl:rm\_\_sourceColumns}
-       \item[] \texttt{osl:rm\_\_targetColumns}
-       \item[] \texttt{osl:tt\_\_sourceValues}
-       \item[] \texttt{osl:tt\_\_rdfRessources}
-Therefore, they have the \name{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.\\
-If the represented list is not empty, the list elements are represented by other
-\texttt{osl:StringListNode} individuals connected seriatim by the property
-\texttt{osl:nextNode}, with the first individual being connected to the root node.
-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.
-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.
\ No newline at end of file
diff --git a/osl_intro.tex b/osl_intro.tex
new file mode 100644 (file)
index 0000000..334ebf5
--- /dev/null
@@ -0,0 +1,27 @@
+\chapter{The OBDA Specification Language (OSL)}
+TODO: aims, proceeding, structure
+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 \name{OWL}, with data
+properties 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.
+Therefore, an ideal base for the \osllong{} is \name{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 that the language has to represent rather than
+primarily dealing with technical details.
+In particular, many of those details can be formulated as \name{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 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.
diff --git a/osl_spec.tex b/osl_spec.tex
new file mode 100644 (file)
index 0000000..f8cb257
--- /dev/null
@@ -0,0 +1,169 @@
+\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,
+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.
+\p \label{spec_ignored} An \osl{} document may contain more \name{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
+from each other (except those which are ignored, see Paragraph~\ref{spec_ignored}).\\
+It is recommended to use the \texttt{owl:AllDifferent} \name{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 is recommended to use that base IRI as \texttt{xml:base} XML attribute.\\
+IRIs prefixed with \texttt{osl:} are IRIs relative to the IRI\\
+\p An \osl{} document has to import the following ontology
+(referred to as ``the \osl{} header'' in the following):\\
+\p The \name{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\\
+to the \texttt{OWL class URI} field of the respective entity map for entity maps,\\
+to the \texttt{OWL class URI} field of the associated entity map for identifier maps,\\
+to the \texttt{OWL class URI} field of the associated entity map for subtype maps and\\
+to the \texttt{OWL class URI} field of the entity map associated with the respective subtype map
+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 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 weren't empty).
+       \begin{tabular}{l|l}
+               \textbf{Map type} & \textbf{\name{OWL} IRI} \\ \hline
+               Entity map & \textit{$<$class URI$>$}\texttt{\_\_ENTITY\_MAP} \\
+               Attribute map & \textit{$<$property URI$>$}\texttt{\_\_ATTRIBUTE\_MAP} \\
+               Identifier map & \textit{$<$class URI$>$}\texttt{\_\_IDENTIFIER\_MAP} \\
+               Relation map & \textit{$<$property URI$>$}\texttt{\_\_RELATION\_MAP} \\
+               Subtype map & \textit{$<$class URI$>$}\texttt{\_\_SUBTYPE\_MAP} \\
+               Translation table of attribute map &
+                       \textit{$<$property URI$>$}\texttt{\_\_ATTRIBUTE\_MAP\_\_TRANSLATION\_TABLE} \\
+               Translation table of subtype map &
+                       \textit{$<$class URI$>$}\texttt{\_\_SUBTYPE\_MAP\_\_TRANSLATION\_TABLE} \\
+       \end{tabular}
+       \caption{\name{OWL} individual IRIs in \osl{}}
+       \label{spec_tbl_indv_iris}
+\p The \name{OWL} individuals described by the \osl{} document representing
+the certain types of OBDA maps
+must be of the \name{OWL} types specified in table \ref{spec_tbl_types}
+(for base IRIs, see Paragraph~\ref{spec_base}).
+               \begin{tabular}{l|l}
+                       \textbf{Map type} & \textbf{\name{OWL} class IRI} \\ \hline
+                       Entity map & \texttt{osl:EntityMap} \\
+                       Attribute map & \texttt{osl:AttributeMap} \\
+                       Identifier map & \texttt{osl:IdentifierMap} \\
+                       Relation map & \texttt{osl:RelationMap} \\
+                       Subtype map & \texttt{osl:SubtypeMap} \\
+                       Translation table & \texttt{osl:TranslationTable} \\
+               \end{tabular}
+               \caption{\name{OWL} class membership of map representations in \osl{}}
+               \label{spec_tbl_types}
+\p The \name{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}).
+               \begin{tabular}{l|l|l|l}
+                       \textbf{Map type} & \textbf{Field label} & \textbf{Field name} & \textbf{\name{OWL} IRI} \\ \hline
+                       Entity map & \texttt{E1} & \texttt{Table name} & \texttt{osl:em\_\_tableName} \\
+                       Entity map & \texttt{E2} & \texttt{Label} & \texttt{osl:em\_\_label} \\
+                       Entity map & \texttt{E3} & \texttt{Identifier map} & \texttt{osl:em\_\_identifierMap} \\
+                       Entity map & \texttt{E4} & \texttt{Attribute maps...} & \texttt{osl:em\_\_attributeMaps} \\
+                       Entity map & \texttt{E5} & \texttt{OWL class URI} & \texttt{osl:em\_\_owlClassURI} \\
+                       Entity map & \texttt{E6} & \texttt{Description} & \texttt{osl:em\_\_description} \\ \hline
+                       Attribute map & \texttt{A1} & \texttt{Column name} & \texttt{osl:am\_\_columnName} \\
+                       Attribute map & \texttt{A2} & \texttt{SQL datatype} & \texttt{osl:am\_\_sqlDatatype} \\
+                       Attribute map & \texttt{A3} & \texttt{Mandatory} & \texttt{osl:am\_\_mandatory} \\
+                       Attribute map & \texttt{A4} & \texttt{Label} & \texttt{osl:am\_\_label} \\
+                       Attribute map & \texttt{A5} & \texttt{OWL property URI} & \texttt{osl:am\_\_owlPropertyURI} \\
+                       Attribute map & \texttt{A6} & \texttt{Property type} & \texttt{osl:am\_\_propertyType} \\
+                       Attribute map & \texttt{A7} & \texttt{Translation} & \texttt{osl:am\_\_translation} \\
+                       Attribute map & \texttt{A8} & \texttt{URI pattern} & \texttt{osl:am\_\_uriPattern} \\
+                       Attribute map & \texttt{A9} & \texttt{RDF language} & \texttt{osl:am\_\_rdfLanguage} \\
+                       Attribute map & \texttt{A10} & \texttt{XSD datatype} & \texttt{osl:am\_\_xsdDatatype} \\
+                       Attribute map & \texttt{A11} & \texttt{Description} & \texttt{osl:am\_\_description} \\ \hline
+                       Identifier map & \texttt{I1} & \texttt{Entity map} & \texttt{osl:im\_\_entityMap} \\
+                       Identifier map & \texttt{I2} & \texttt{Attribute maps...} & \texttt{osl:im\_\_attributeMaps} \\
+                       Identifier map & \texttt{I3} & \texttt{URI pattern} & \texttt{osl:im\_\_uriPattern} \\ \hline
+                       Relation map & \texttt{R1} & \texttt{Source entity map} & \texttt{osl:rm\_\_sourceEntityMap} \\
+                       Relation map & \texttt{R2} & \texttt{Source column} &
+                               \texttt{osl:rm\_\_sourceColumn\textcolor{red}{\textbf{s}}} \\
+                       Relation map & \texttt{R3} & \texttt{Target entity map} & \texttt{osl:rm\_\_targetEntityMap} \\
+                       Relation map & \texttt{R4} & \texttt{Target column} &
+                               \texttt{osl:rm\_\_targetColumn\textcolor{red}{\textbf{s}}} \\
+                       Relation map & \texttt{R5} & \texttt{OWL property URI} & \texttt{osl:rm\_\_owlPropertyURI} \\ \hline
+                       Subtype map & \texttt{S1} & \texttt{Entity Map} & \texttt{osl:sm\_\_entityMap} \\
+                       Subtype map & \texttt{S2} & \texttt{Column Name} & \texttt{osl:sm\_\_columnName} \\
+                       Subtype map & \texttt{S3} & \texttt{OWL superclass URI} & \texttt{osl:sm\_\_owlSuperclassURI} \\
+                       Subtype map & \texttt{S4} & \texttt{Prefix} & \texttt{osl:sm\_\_prefix} \\
+                       Subtype map & \texttt{S5} & \texttt{Suffix} & \texttt{osl:sm\_\_suffix} \\
+                       Subtype map & \texttt{S6} & \texttt{Translation} & \texttt{osl:sm\_\_translation} \\ \hline
+                       Translation table & \texttt{T1} & \texttt{Source value...} &
+                               \texttt{osl:tt\_\_sourceValue\textcolor{red}{\textbf{s}}} \\
+                       Translation table & \texttt{T2} & \texttt{RDF ressource...} &
+                               \texttt{osl:tt\_\_rdfRessource\textcolor{red}{\textbf{s}}} \\
+               \end{tabular}
+               \caption{\name{OWL} property IRIs in \osl{}}
+               \label{spec_tbl_prop_iris}
+\p The following \name{OWL} properties in the \osl{} document refer
+to lists of elements:
+       \item[] \texttt{osl:rm\_\_sourceColumns}
+       \item[] \texttt{osl:rm\_\_targetColumns}
+       \item[] \texttt{osl:tt\_\_sourceValues}
+       \item[] \texttt{osl:tt\_\_rdfRessources}
+Therefore, they have the \name{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.\\
+If the represented list is not empty, the list elements are represented by other
+\texttt{osl:StringListNode} individuals connected seriatim by the property
+\texttt{osl:nextNode}, with the first individual being connected to the root node.
+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.
+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.
index 26d70cd..1e40545 100644 (file)
@@ -1,45 +1,34 @@
 \chapter{The db2osl software}
-Besides the conception of the  ``OBDA Specification Language'' (\osl{}), the design
+Besides the conception of the \oslboth{}, 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 \ref{functionality} describes the functionality the program offers.
-Section \ref{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 \ref{bootstrapping} explains in detail how the bootstrapping
-process was realized.
-Section \ref{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 \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 \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.
+Section~\ref{stats} mentions some numbers and statistics about the program.
+Implementation topics are dealt with in Chapter~\ref{impl}.
 For detailed descriptions of the classes and packages of \myprog{}, refer to
 Appendices TODO.
-Except the last section, this chapters' sections present the information in a
+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}).
index 61d7be5..5904210 100644 (file)
@@ -5,6 +5,7 @@
 TODO: overall description, modularity, extendability, ex: easy to add new in-/output formats
 TODO: mapping profiles (maybe better in next subsection)
 \subsubsection{Package structuring}
 The $45$ classes of \myprog{} were assigned to $11$ packages, each containing
@@ -14,11 +15,11 @@ with obvious task fields on the one hand, while on the other hand implementing a
 incisive separation with a notable degree of decoupling.
 Packages were chosen not to be nested but to be set out vapidly.
 Since this doesn't have any functional implications \cite{java}, but is rather an
-implementation detail, this is further explained in section \fullref{code_packages}.
+implementation detail, this is further explained in Section~\fullref{code_packages}.
 The packages are introduced and described in table \ref{arch_tbl_packages}.
 The lists of classes each package contains are given in table \ref{arch_tbl_classes}
-in the next section \fullref{fine}.
+in the next Section~\fullref{fine}.
 For a detailed package description, refer to Appendix TODO.
@@ -31,7 +32,7 @@ For a detailed package description, refer to Appendix TODO.
                \code{helpers} & Helper classes used program-wide\\
                \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{osl} & Classes representing OBDA specifications (as described in \cite{eng}) using the \oslboth{}\\
                \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{}\\
@@ -93,8 +94,9 @@ Dependencies of or on package \code{helpers} are not considered in the following
 since this package precisely was meant to offer services used by many other packages.
 In fact, all facilities provided by \code{helpers} could just as well be part of
 the \name{Java} API, but unfortunately are not.
-The current dependency structure, factoring in this restriction, is shown in figure
-\ref{arch_fig_packages} and reveals a conceivably tidy system of dependencies.
+The current dependency structure, factoring in this restriction, is shown in
+Figure~\ref{arch_fig_packages} and reveals a conceivably tidy system of
@@ -106,7 +108,7 @@ The current dependency structure, factoring in this restriction, is shown in fig
 Except for the package \code{settings} (which is further explained below),
 every package has at most two outgoing edges, that is packages it depends on.
 Previous versions of \myprog{} had a quite more complicated package dependency structure,
-depicted in figure \ref{arch_fig_packages_earlier}.
+depicted in Figure~\ref{arch_fig_packages_earlier}.
 In this previous package structure, the maximum number of dependencies of
 packages other than \code{settings} on other packages is three, which also seems
 reasonably less.
@@ -129,7 +131,7 @@ This may seem odd at first glance, considering that most of the edges connecting
 the \code{settings} node are outgoing edges and only one is incoming,
 whereas in a design where the settings are configured from within a single package
 and accessed from many other packages this would be the other way round.
-The reason for this constellation is that, as described in section \fullref{interface},
+The reason for this constellation is that, as described in Section~\fullref{interface},
 all settings in \myprog{} are configured per bootstrapping job
 (there are no global settings) and so \code{settings}
 contains a class \code{Job} (and currently no other classes),
@@ -138,7 +140,7 @@ provides a \code{perform()} method combining the facilities offered by the other
 By this means, the \code{perform()} method of the \code{Job} class acts as the central
-driver performing the bootstrapping process, reducing the \code{main()} method two
+driver performing the bootstrapping process, reducing the \code{main()} method to
 only $7$ lines of code and turning \code{settings} into something like an externalized
 part of the \code{main} package.
 If, in a future version of the program, this approach is changed and global settings or
@@ -154,7 +156,7 @@ to have the driver class reside in a package called ``settings''.
 \subsection{Fine structuring}
-While the packages in \myprog{} are introduced and described in section \fullref{coarse},
+While the packages in \myprog{} are introduced and described in Section~\fullref{coarse},
 the classes that comprise them are addressed in this section.
 For a detailed class index, refer to Appendix TODO.
 TODO: total classes etc.
@@ -260,73 +262,128 @@ roles, behave in an intuitive way, ideally representing artifacts from the world
 modeled in the program directly \cite{str3}, is a prerequisite to make the code
 clear and comprehensible on the architectural level.
-Section \fullref{code_classes} as part of section \fullref{code}
+Section \fullref{code_classes} as part of Section~\fullref{code}
 describes the identification and naming scheme for the classes in \myprog{}.
 However, it is also important, to arrange these classes in useful, comprehensible
 class hierarchies to avoid code duplication, make appropriate use of the type system,
 ease the design of precise and flexible interfaces and enhance the
 adaptability and extensibility of the program.
-Figure \ref{arch_fig_hierachies} shows the class hierarchies in \myprog{},
-while standalone classes are listed in table \ref{arch_tbl_lone_classes}.
-               \ContinuedFloat*
+       {\value{myFigureNumber}}}
+       {\value{mySubfigureNumber}}}
-               \label{first_hierarchy}
-               \ContinuedFloat*
-               \includegraphics[scale=0.86]{Images/inherit_graph_5.pdf}
-       \end{center}\end{figure}
-               \ContinuedFloat*
+               \caption{\code{ColumnSet} class hierarchy in \myprog{}}
+               \label{hier_colset}
+               \includegraphics[scale=0.86]{Images/inherit_graph_8_simplified.pdf}
+               \stepsubfigcounter{}
+               \caption{\code{ColumnSet} class hierarchy in \myprog{} -- simplified}
+               \label{hier_colset_simple}
-               \ContinuedFloat*
-               \includegraphics[scale=0.86]{Images/inherit_graph_19.pdf}
-               \ContinuedFloat*
+               \stepsubfigcounter{}
+               \caption{\code{Column} class hierarchy\\in \myprog{}}
+               \label{hier_column}
+       \stepfigcounter{}
+       \caption[Database class hierarchies in \myprog{}]{
+               Database class hierarchies in \myprog{}.
+               Interface names are italicized,
+               external classes or interfaces are hemmed with a gray frame.}
+       \label{hiers_db}
-               \ContinuedFloat*
+               \label{hier_uribuilder}
+               \caption{\code{URIBuilder} class hierarchy in \myprog{}}
+               \includegraphics[scale=0.86]{Images/inherit_graph_19.pdf}
+               \stepsubfigcounter{}
+               \caption{\code{OBDAMap} class hierarchy in \myprog{}}
+               \label{hier_obdamap}
+       \stepfigcounter{}
+       \caption[OBDA specification class hierarchies in \myprog{}]{
+               OBDA specification class hierarchies in \myprog{}.
+               Interface names are italicized,
+               external classes or interfaces are hemmed with a gray frame.}
+       \label{hiers_obdaspec}
-               \ContinuedFloat*
-               \includegraphics[scale=0.86]{Images/inherit_graph_21_extended.pdf}
-               \ContinuedFloat*
+               \caption{\code{SpecPrinter} class hierarchy in \myprog{}}
+               \label{hier_specprinter}
-               \ContinuedFloat*
+               \stepsubfigcounter{}
+               \caption{\code{StreamHandler} class hierarchy in \myprog{}}
+               \label{hier_streamhandler}
+       \stepfigcounter{}
+       \caption[Logging and output class hierarchies in \myprog{}]{
+               Logging and output class hierarchies in \myprog{}.
+               Interface names are italicized,
+               external classes or interfaces are hemmed with a gray frame.}
+       \label{hiers_output}
+       \includegraphics[scale=0.86]{Images/inherit_graph_18.pdf}
+       \caption[\code{Job} class hierarchy in \myprog{}]{
+               \code{Job} class hierarchy in \myprog{}.
+               Interface names are italicized,
+               external classes or interfaces are hemmed with a gray frame.}
+       \label{hier_job}
+               \includegraphics[scale=0.86]{Images/inherit_graph_5.pdf}
+               \caption{\code{Iterable} class hierarchy in \myprog{}}
+               \label{hier_iterable}
+               \includegraphics[scale=0.86]{Images/inherit_graph_21_extended.pdf}
+               \stepsubfigcounter{}
+               \caption{\code{ReadOnlyIterator} class\\hierarchy in \myprog{}}
+               \label{hier_roiterator}
-               \ContinuedFloat*
-               \includegraphics[scale=0.86]{Images/inherit_graph_18.pdf}
-               \ContinuedFloat*
+               \stepsubfigcounter{}
+               \caption{\code{Iterator} class hierarchy in \myprog{}}
+               \label{hier_iterator}
-               \ContinuedFloat*
+               \stepsubfigcounter{}
+               \caption{\code{Exception} class hierarchy\\in \myprog{}}
+               \label{hier_exception}
-               \setcounter{figure}{\value{figureNumberOfClassHierarchyFigure}}
-               \caption[Class hierarchies in \myprog{}]{Class hierarchies in \myprog{}.
-                       Interface names are italicized,
-                       external classes or interfaces are hemmed with a gray frame.}
-               \label{arch_fig_hierachies}
+               \stepsubfigcounter{}
+               \caption{\code{RuntimeException} class hierarchy in \myprog{}}
+               \label{hier_rtexception}
+       \stepfigcounter{}
+       \caption[Miscellaneous class hierarchies in \myprog{}]{
+               Miscellaneous class hierarchies in \myprog{}.
+               Interface names are italicized,
+               external classes or interfaces are hemmed with a gray frame.}
+       \label{hiers_misc}
@@ -344,7 +401,7 @@ while standalone classes are listed in table \ref{arch_tbl_lone_classes}.
                        \itm{} \code{test.GetSomeDBSchema}\\
        \caption{Standalone classes in \myprog{}}
-       \label{arch_tbl_lone_classes}
+       \label{lone_classes}
 Note that every class hierarchy has at least one \code{interface} at its top.
@@ -355,30 +412,26 @@ 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}.
-The details of this consideration are explained in section \fullref{code_interfaces}.
+The details of this consideration are explained in Paragraph~``\nameref{code_interfaces}''
+in Section~\fullref{code_classes}.
 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
 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}).
+described in Paragraph~``\nameref{const}''
+(which is part of Section~\fullref{code_classes}) TODO.
 This technique forced class \code{Column} to
 \code{implement} an interface, thus needlessly making it part of a class hierarchy,
 but also complicated the structure of some class hierarchies.
 Consider the class hierarchy around \code{ColumnSet},
-shown in the \hyperref[first_hierarchy]{first graph} of figure \ref{arch_fig_hierachies}.
+shown in Figure~\ref{hier_colset_simple}.
 Definitely, it seems overly complicated at the first glance.
 But this complexity solely is introduced by the artificial
 \code{Readable...} interfaces;
 would \name{Java} provide a mechanism like \name{C++}'s \code{const},
-this hierarchy would be as simple as in the following graph:
-               \includegraphics[scale=0.86]{Images/inherit_graph_8_simplified.pdf}
-               \caption{\code{ColumnSet} class hierarchy in \myprog{} -- simplified}
-               \label{arch_fig_colset_hierarchy_simplified}
+this hierarchy would be as simple as in TODO.
 However, since const correctness is an important mechanism effectively preventing
 errors while on the other hand introducing clarity by itself, it was considered
@@ -390,4 +443,4 @@ The const correctness mechanism itself thereby hinders uninformed or ignorant
 programmers from mistakenly using the wrong class in an interface in many cases.
 For more information about the program structure on the class level,
-see section \fullref{code}, while for a detailed class index refer to Appendix TODO.
+see Section~\fullref{code}, while for a detailed class index refer to Appendix TODO.
index 7db1da4..595c385 100644 (file)
@@ -8,9 +8,10 @@ which then can be used by other tools to drive the actual bootstrapping process.
 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}.
+How this functionality is exposed to users is described in Section~\fullref{interface}.
+The bootstrapping process using direct mapping as the core functionality
+of the software is described in Section~\ref{dirm}.
 TODO: reference to OBDA topics
 \subsection{Function description}
@@ -24,15 +25,16 @@ 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 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.
+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
-the underlying objects is supported, which is useful for debugging
+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{osl_spec}).
+(for more information on the \osl{} header, see the specification of the \osllong{}
+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
@@ -68,14 +70,13 @@ The functionality of the \myprog{} software can be summarized as follows:
        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}
+       \item Use the \osl{} format described in Chapter~\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{osl_spec} for details)
+       (see the specification of the \oslboth{} 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
index 9b5846a..6dc6a8a 100644 (file)
@@ -1,9 +1,10 @@
 \section{Interface and usage}
 This section describes the interface to the operating system and the user interface.
-For information on programming interfaces, see section \fullref{arch}.
+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.
@@ -128,15 +129,16 @@ Thus, a parameter defined for one operation (like the password
 in the example) will have no effect on other operations.
 This ensures that typical errors are prevented when merging several invocations
 of \myprog{} into one (or vice versa)
-and allows for a straight-forward and comprehensive implementation.
+and allows for a straight-forward and comprehensible implementation.
 \subsubsection{Advanced modifications}
 Since \osl{} specifications are plain text files, a user can edit them in any desired
 text editor if he wants to change them in ways that go beyond the functionality
 \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{osl_spec}), 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.
@@ -145,11 +147,16 @@ specification automatically or manually.
 Doing so, care has to be taken to make the ontology remain a conforming \osl{}
 specification. However, since the restrictions imposed by \osl{} are rather
 small and intuitive, this is easily achieved.
-Furthermore, upcoming tools supporting \osl{} (see section \fullref{future}) most
+One of the most popular ontology editors \cite{protegepopular}, \name{Protégé},
+is an open, \name{Java} based platform supporting plug-ins \cite{protege};
+for a habitual \name{Protégé} user it should be an easy task to write an
+\osl{} plugin.
+Furthermore, upcoming tools supporting \osl{} (see Section~\fullref{future}) most
 likely will be able to check input files for conformity with the \osl{} definition.
 \subsection{Integration into systems}
-Besides the use cases described in section ``\nameref{basic}'',
+Besides the use cases described in Paragraph~``\nameref{basic}''
+and in Paragraph~``\nameref{advanced}'' in the previous Section~\ref{usage},
 there are many other ways in which \myprog{} can be used.
 For example, a database can be periodically checked for changes that make a
 re-bootstrapping necessary:
@@ -173,13 +180,6 @@ that bootstraps all databases on a server:
        \ind regex="\`{} printf \%s "\$regex" | sed -e "s,\textbackslash\textbackslash\textbackslash\textbackslash\$,\$|\$dbname\$," \`{}"\\
-Newer versions than version 1.0 described here provide a command-line parameter
-\code{-a} (or, alternatively, \code{\textendash \textendash all)}
-which makes \myprog{} bootstrap \emph{all} databases matching the given
-regular expression.
-However, using this approach, all bootstrapped specifications will be output
-to one single file.
 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.
@@ -188,7 +188,7 @@ Additionally, it is possible to deploy it as a Web application TODO.
 To simplify integration on the code level, the architecture of \myprog{} was
 designed to be highly modular and to cleanly separate code with different areas of
 responsibility into different packages
-(for details about the structuring of \myprog{}, see section \fullref{arch}).
+(for details about the structuring of \myprog{}, see Section~\fullref{arch}).
 This modularity, besides facilitating understanding the code,
 allows for a high degree of code reusability.
index 1315510..09015a5 100644 (file)
@@ -1,7 +1,7 @@
 \section{Numbers and statistics}
-The following numbers and statistics can be stated about \myprog{}, version $1.0$:
+The following numbers and statistics can be stated about \myprog{}:
diff --git a/program_versioning.tex b/program_versioning.tex
deleted file mode 100644 (file)
index ec384f1..0000000
+++ /dev/null
@@ -1,44 +0,0 @@
-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{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}