Major change master
authorPhilipp Martis <martispp@hspc31.informatik.uni-stuttgart.de>
Fri, 13 May 2016 17:05:53 +0000 (19:05 +0200)
committerPhilipp Martis <philipp2100@web.de>
Sun, 22 May 2016 16:51:21 +0000 (18:51 +0200)
Change involving (slight) restructuring and additional (sub)subsections
Subsection-division of section "Functionality" was abandoned.
Lots of text was added.
Bibliography was changed and extended.

16 files changed:
Bachelor thesis.pdf
Bachelor thesis.tex
OSL-Specification.tex
appendix.tex
background.tex
bibliography.bib
bootstrapping_dirm.tex
bootstrapping_iris.tex
bootstrapping_spec.tex
impl_code.tex
osl_spec.tex
program.tex
program_arch.tex
program_functionality.tex
program_interface.tex
program_stats.tex

index 4832bc7..f066289 100644 (file)
Binary files a/Bachelor thesis.pdf and b/Bachelor thesis.pdf differ
index 00038c2..783dba9 100644 (file)
@@ -28,7 +28,7 @@
 \newcommand{\ind}{\hspace*{30pt}}
 \newcommand{\code}[1]{\texttt{#1}}
 \newcommand{\codepar}[1]{\begin{itemize}\item[]\code{#1}\end{itemize}\vspace{12pt}}
-\newcommand{\fullref}[1]{\ref{#1} -- \nameref{#1}}
+\newcommand{\fullref}[1]{\ref{#1}~--~\nameref{#1}}
 
 % Documentclass etc.
 \documentclass[\myfontsize,a4paper,twoside=semi]{scrreprt}
             language=english]{cs-cover/uni-stuttgart-cs-cover}
 
 % Appendix
-\usepackage{appendix}
+\usepackage[title,titletoc]{appendix}
 
 % Links
 %\usepackage{url}
 
 % Appendix
 \include{appendix}
-\addcontentsline{toc}{chapter}{Appendix}
 
 % Bibliography bibtex (add pagebackref=true to hyperref options if desired)
 %\bibliographystyle{alpha}
index f2e82ff..a9d2fb1 100644 (file)
@@ -28,7 +28,7 @@
 \newcommand{\ind}{\hspace*{30pt}}
 \newcommand{\code}[1]{\texttt{#1}}
 \newcommand{\codepar}[1]{\begin{itemize}\item[]\code{#1}\end{itemize}\vspace{12pt}}
-\newcommand{\fullref}[1]{\ref{#1} -- \nameref{#1}}
+\newcommand{\fullref}[1]{\ref{#1}~--~\nameref{#1}}
 
 % Documentclass etc.
 \documentclass[\myfontsize,a4paper,twoside=semi]{scrreprt}
 \bibliography{bibliography}
 
 %% Appendix
-%\usepackage{appendix}
+%\usepackage[title,titletoc]{appendix}
 
 % Links
 %\usepackage{url}
 
 %% Appendix
 %\include{appendix}
-%\addcontentsline{toc}{chapter}{Appendix}
 
 % Bibliography bibtex (add pagebackref=true to hyperref options if desired)
 %\bibliographystyle{alpha}
index 1282700..68dc848 100644 (file)
@@ -1,4 +1,97 @@
-\chapter*{Appendix}
-Hierher gehören zur Dokumentation Tabellen, Messprotokolle,
-Rechnerprotokolle, Konstruktionszeichnungen, kurze Programmausdrucke
-und Ähnliches.
+\begin{appendices}
+\appendixpage
+\chapter{Details on the \myprog{} implementation}
+\section{Package contents (\myprog{})}
+\label{app_pkgs}
+\KOMAoption{fontsize}{\smallerfontsize{}}
+The following table lists the contents of each of \myprog{}s packages:
+
+\begin{table}[H]
+       \begin{multicols}{2}\begin{itemize} \KOMAoption{fontsize}{\smallfontsize{}}
+                       \item \code{bootstrapping}
+                       \begin{itemize}
+                               \item \code{Bootstrapping}
+                               \item \code{DirectMappingURIBuilder}
+                               \item \code{URIBuilder}
+                       \end{itemize}
+                       \item \code{cli}
+                       \begin{itemize}
+                               \item \code{CLIDatabaseInteraction}
+                       \end{itemize}
+                       \item \code{database}
+                       \begin{itemize}
+                               \item \code{Column}
+                               \item \code{ColumnSet}
+                               \item \code{DatabaseException}
+                               \item \code{DBSchema}
+                               \item \code{ForeignKey}
+                               \item \code{Key}
+                               \item \code{PrimaryKey}
+                               \item \code{ReadableColumn}
+                               \item \code{ReadableColumnSet}
+                               \item \code{ReadableForeignKey}
+                               \item \code{ReadableKey}
+                               \item \code{ReadablePrimaryKey}
+                               \item \code{RetrieveDBSchema}
+                               \item \code{Table}
+                               \item \code{TableSchema}
+                       \end{itemize}
+                       \item \code{helpers}
+                       \begin{itemize}
+                               \item \code{Helpers}
+                               \item \code{MapValueIterable}
+                               \item \code{MapValueIterator}
+                               \item \code{ReadOnlyIterable}
+                               \item \code{ReadOnlyIterator}
+                               \item \code{SQLType}
+                               \item \code{UserAbortException}
+                       \end{itemize}
+                       \newpage
+                       \item \code{log}
+                       \begin{itemize}
+                               \item \code{ConsoleDiagnosticOutputHandler}
+                               \item \code{GlobalLogger}
+                       \end{itemize}
+                       \item \code{main}
+                       \begin{itemize}
+                               \item \code{Main}
+                       \end{itemize}
+                       \item \code{osl}
+                       \begin{itemize}
+                               \item \code{OSLSpecification}
+                       \end{itemize}
+                       \item \code{output}
+                       \begin{itemize}
+                               \item \code{ObjectSpecPrinter}
+                               \item \code{OSLSpecPrinter}
+                               \item \code{SpecPrinter}
+                       \end{itemize}
+                       \item \code{settings}
+                       \begin{itemize}
+                               \item \code{Job}
+                       \end{itemize}
+                       \item \code{specification}
+                       \begin{itemize}
+                               \item \code{AttributeMap}
+                               \item \code{EntityMap}
+                               \item \code{IdentifierMap}
+                               \item \code{InvalidSpecificationException}
+                               \item \code{OBDAMap}
+                               \item \code{OBDASpecification}
+                               \item \code{RelationMap}
+                               \item \code{SubtypeMap}
+                               \item \code{TranslationTable}
+                       \end{itemize}
+                       \item \code{test}
+                       \begin{itemize}
+                               \item \code{CreateTestDBSchema}
+                               \item \code{GetSomeDBSchema}
+                       \end{itemize}
+               \end{itemize}\end{multicols} \KOMAoption{fontsize}{\myfontsize{}}
+               \caption{Class attachment to packages in \myprog{}}
+               \label{app_tbl_classes}
+\end{table}
+
+\KOMAoption{fontsize}{\myfontsize{}}
+
+\end{appendices}
index ca25707..762fbe2 100644 (file)
@@ -1,8 +1,12 @@
 \chapter{Background and related work}
 
 \section{Background}
+\subsection{Basic concepts}
+\label{back_basic}
+TODO: r2rml, rdf, rdfs, owl, xml, iris, baseiri, end with :
+
 \subsection{Ontology-based data access (OBDA)}
-\label{obda}
+\label{back_obda}
 TODO: References
 
 Storing data in relational databases is a very common proceeding, since the
@@ -106,6 +110,9 @@ structured information, like \name{ODS}, \name{XLS} or \name{CSV} files,
 though some additional preparation might be necessary in these cases \cite{eng}.
 
 \subsection{OBDA specifications}
+\label{back_obdaspecs}
+TODO: more, maybe shorten introduction
+
 As mentioned in Section~\fullref{motivation}, the sole bootstrapping of
 \name{RDF} triples \cite{rdf} or other forms of structured information
 from relational database schemata is a relatively well understood topic.
@@ -139,13 +146,14 @@ This led to the origination of the \name{OPTIQUE} project in TODO which
 (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}):
+well-developed OBDA system can provide (explained in
+Section~\ref{back_obda}):
 an easy end-user access to data without knowing about its structuring
 while taking advantage of automatic translations \cite{optique2}.
 In doing so, ascertained shortcomings of existing OBDA systems were addressed:
 \emph{usability} (for example the need to use formal query languages),
 \emph{costly prerequisites} (consider, for example, the disadvantages
-of materialized OBDA described in Section~\ref{obda}) and
+of materialized OBDA described in Section~\ref{back_obda}) and
 \emph{efficiency} (which was perceived as being insufficiently addressed
 in previous approaches) \cite{optique}.
 
index 6bfc84f..07382b8 100644 (file)
@@ -27,8 +27,8 @@
 }
 
 @misc{dirm,
-       shorthand      = {W3CR12},
-       author         = {RDB2RDF Working Group},
+       shorthand      = {W3CR12a},
+       author         = {W3C RDB2RDF Working Group},
        title          = {A Direct Mapping of Relational Data to RDF},
        year           = 2012,
        howpublished   = {\url{https://www.w3.org/TR/rdb-direct-mapping/}},
@@ -300,14 +300,95 @@ month={April},
        year={2003}
 }
 
-@inproceedings{crompton,
-       title={TODO: Keynote talk at the W3C Workshop on Sem. Web in Oil \& Gas Industry},
+@misc{crompton,
+       title={Keynote talk at the W3C Workshop on Sem. Web in Oil \& Gas Industry},
        author={Crompton, J.},
        url={http://www.w3.org/2008/12/ogws-slides/Crompton.pdf},
        year={2008}
 }
 
 @inproceedings{r2o,
-       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},
+       title={R\textsubscript{2}O, an Extensible and Semantically Based Database-to-ontology Mapping Language},
+       author={Barrasa Rodr{\'\i}guez, Jes{\'u}s and Corcho, {\'O}scar and G{\'o}mez-P{\'e}rez, Asunci{\'o}n},
+    booktitle={SWDB'04: 2nd Workshop on Semantic Web and Databases},
+    pages={1069--1070},
+    year={2004},
+    publisher={Springer-Verlag}
+}
+
+@incollection{npd,
+  title={Publishing the Norwegian Petroleum Directorate's FactPages as Semantic Web Data},
+  author={Skj{\ae}veland, Martin G and Lian, Espen H and Horrocks, Ian},
+  booktitle={The Semantic Web -- ISWC 2013},
+  pages={162--177},
+  year={2013},
+  publisher={Springer}
+}
+
+@article{survey,
+  title={Survey of directly mapping SQL databases to the Semantic Web},
+  author={Sequeda, Juan F. and Tirmizi, Syed Hamid and Corcho, Oscar and Miranker, Daniel P.},
+  journal={The Knowledge Engineering Review},
+  volume={26},
+  number={04},
+  pages={445--486},
+  year={2011},
+  publisher={Cambridge University Press}
+}
+
+@inproceedings{ondirm,
+ author = {Sequeda, Juan F. and Arenas, Marcelo and Miranker, Daniel P.},
+ title = {On Directly Mapping Relational Databases to RDF and OWL},
+ booktitle = {Proceedings of the 21st International Conference on World Wide Web},
+ year = {2012},
+ isbn = {978-1-4503-1229-5},
+ location = {Lyon, France},
+ pages = {649--658},
+ numpages = {10},
+ doi = {10.1145/2187836.2187924},
+ acmid = {2187924},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {OWL, RDB2RDF, RDF, SPARQL, SQL, direct mapping, relational databases, semantic web},
+}
+
+@inproceedings{autodirm,
+  title={A Completely Automatic Direct Mapping of Relational Databases to RDF and OWL},
+  author={Sequeda, Juan F. and Arenas, Marcelo and Miranker, Daniel P.},
+  booktitle={International Semantic Web Conference (Posters \& Demos)},
+  publisher={Citeseer},
+  year={2011}
+}
+
+@inproceedings{sac,
+  title={Migrating data-intensive web sites into the semantic web},
+  author={Stojanovic, Ljiljana and Stojanovic, Nenad and Volz, Raphael},
+  booktitle={Proceedings of the 2002 ACM symposium on Applied computing},
+  pages={1100--1107},
+  year={2002},
+  organization={ACM}
+}
+
+@article{linked,
+  title={Linked data -- the story so far},
+  author={Bizer, Christian and Heath, Tom and Berners-Lee, Tim},
+  journal={Semantic Services, Interoperability and Web Applications: Emerging Concepts},
+  pages={205--227},
+  year={2009}
+}
+
+@article{benefits,
+  title={Benefits of Publishing the Norwegian Petroleum Directorate's FactPages as Linked Open Data},
+  author={Skj{\ae}veland, Martin G and Lian, Espen H},
+  journal={Norsk informatikkonferanse (NIK 2013). Tapir},
+  year={2013}
+}
+
+@misc{r2rml,
+       shorthand      = {W3CR12b},
+       author         = {W3C RDB2RDF Working Group},
+       title          = {R2RML: RDB to RDF Mapping Language},
+       year           = 2012,
+       howpublished   = {\url{https://www.w3.org/TR/r2rml/}},
+       note           = {[Accessed: 2016-05-20]}
 }
index adbef6a..4835ef9 100644 (file)
@@ -1,5 +1,7 @@
 \section{Ontology bootstrapping using direct mapping}
 \label{dirm}
+TODO: more, individuals <- data
+TODO: no alternative approach
 
 As its name suggests, the direct mapping approach is a relatively simple
 and straight forward approach.
@@ -76,15 +78,15 @@ 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
+       \item Reference property IRIs consist of the child table name, the
+       string ``\#ref-'' and the child table column names of the
        respective foreign key, separated by a semicolon (`;').
        \item All contained names are included in their percent-encoded
        form TODO.
 \end{itemize}
 
-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.
+The encoding of reference property IRIs can lead to name clashes in
+cases multiple foreign keys exist which contain exactly the
+same columns -- which is allowed for example in \name{SQL} TODO.
+To remove this flaw, the parent table name and the parent table column
+names of the respective foreign key must also be included in the IRI.
index ebbf05c..ba296ac 100644 (file)
@@ -1,2 +1,321 @@
-\section{Generating unique IRIs for OBDA specification entities}
+\section{Generating unique IRIs for OBDA specification map fields}
 \label{iris}
+As explained in Section~\fullref{back_basic}, IRIs play a central role in
+diverse topics related to ontology-based data access.
+They provide the means to uniquely identify entities, which of course is
+a necessity for data retrieval.
+As also explained in Section~\ref{back_basic}, every URI is also a IRI, so
+although Skjæveland et al. use the term ``URI'' in the introduction of
+their approach of using OBDA specifications for ontology bootstrapping --
+and that term is also used in Section~\ref{bootstrap_spec}, which describes
+this approach -- in this section the general term ``IRI'' is used, marking
+that the introduced concepts are valid for all types of IRIs.
+
+When dealing with ontology bootstrapping using OBDA specifications, it is
+important to differentiate between the three types of IRIs occurring
+in this matter, which will be underlined by the following unambiguous naming:
+\begin{itemize}
+       \item \emph{Data IRIs} identify entities in the bootstrapped ontology
+       \item \emph{OBDA IRIs} are used as values for the fields of
+       OBDA specification entities
+       \item \emph{OSL IRIs} identify components in serialized OBDA specifications,
+       using the \oslboth{} introduced in Chapter~\ref{osl} for serialization
+\end{itemize}
+
+Skjæveland et al. do not define or assume a particular scheme for IRI generation
+in their introduction of OBDA specifications \cite{eng}.
+Instead, the IRI generation strategy is only adumbrated by giving examples
+of entities having IRIs.
+The examplified scheme was used for the implementation of the \myprog{} software
+bootstrapping OBDA specifications from relational database schemata, which is
+described in this thesis
+(see Section~\fullref{program} and Section~\fullref{impl}).
+The direct mapping approach for ontology bootstrapping described in
+Section~\ref{dirm}, on the other hand, introduces a scheme for
+IRI generation \cite{dirm}, but with this scheme, name clashes can occur,
+as explained in Section~\ref{dirm_iris}.
+The \oslboth{}, finally, defines a proper scheme for OSL IRIs,
+as is explained in Section~TODO.
+
+In the following, an enhanced scheme for the generation of OBDA IRIs
+is proposed, which resembles the previously mentioned scheme used for
+OSL IRIs and which also may serve as a blueprint for
+other IRI generation strategies.
+
+\subsection{Requirements for the IRI scheme}
+\label{iris_req}
+As explained in Section~\fullref{back_basic}, the main requirement on a IRI
+generation scheme is uniqueness of the IRIs: no two entities must be possibly
+assigned the same IRI, regardless of their kind, of how low the probability
+of a name clash (IRI collision) is or of the conditions leading
+to a name clash.
+Additionally, IRI uniqueness shall be independent from the base IRIs,
+thus a base IRI shall be arbitrarily selectable for each generation process
+without introducing name clashes even with IRIs having other base IRIs.
+
+As to OBDA specification entities, the following kinds of IRIs
+have to be available, including IRI patterns:
+\begin{itemize}
+       \item Entity map OWL class IRIs
+       \item Identifier map IRI patterns
+       \item Attribute map OWL property IRIs
+       \item Attribute map IRI patterns
+       \item Relation map OWL property IRIs
+       \item Subtype map (IRI) prefixes
+       \item Subtype map (IRI) suffixes
+       \item Subtype map OWL superclass IRIs
+\end{itemize}
+
+As Subtype map OWL superclass IRIs are IRIs of data entities
+already existing in the target ontology by some means
+(see Section~\fullref{bootstrap_spec_using}), they do not have to be
+generated and thus are ignored in the following.
+Exactly the same holds for Attribute map IRI patterns.
+Furthermore, this approach creates Subtype map IRI prefixes already leading to
+unique IRIs for Subtype map subclasses and so Subtype map IRI suffixes are
+ignored in the following.
+Since an IRI generation scheme cannot avoid collisions with existing IRIs
+out of its outreach and these collisions can easily be prevented,
+for example, by giving them another base IRI (see Setion~\fullref{back_basic}),
+this case is excluded from the requirement that no two URIs must collide
+under any circumstances.
+However, the user shall be able to chose such externally generated IRIs
+from an infinite set of IRIs, while being sure that no name clashes
+will occur.
+
+So compendious, the requirements on the IRI generation scheme are that
+Entity map OWL class IRIs, Identifier map IRI patterns,
+Attribute map OWL property IRIs, Relation map OWL property IRIs and
+Subtype map IRI prefixes can be generated that, regardless of the
+chosen base IRIs, don't clash among another, while leaving an
+infinite set of predictable IRIs that don't clash with any of the
+generated IRIs.
+
+\subsection{Avoiding name clashes in the IRI scheme}
+\label{iris_clashes}
+Generating unique Entity map OWL class IRIs ignoring base IRIs is not much of
+a problem, assuming database table names are distinct, which is guaranteed in a
+common database system like SQL \cite{sql}.
+Including the table name into an Entity map OWL class IRI is sufficient to
+prevent it from colliding with other IRIs with the same base IRI.
+However, when taking two different base IRIs into account that are used for
+two IRIs created according to this scheme, things get more complicated.\\
+Consider, for example, a database table named ``\code{Persons}'' and a
+table named \\ ``\code{Persons\_\_TABLE\_\_Persons}''.
+Generating an IRI according to the scheme
+``<base:>\code{TABLE\_\_}   <table name>'' for each of these tables, using the
+base IRI ``\code{TABLE\_\_Persons\_\_}'' for the first one and the
+empty base IRI for the second one, both tables will get the IRI\\
+``\code{TABLE\_\_Persons\_\_TABLE\_\_Persons}'', although
+the table name was included into the IRI in both cases.
+The problem is that the ``\code{TABLE\_\_}'' string occurring in the
+table name cannot be discriminated from the ``\code{TABLE\_\_}'' string
+added in the course of IRI generation or the ``\code{TABLE\_\_}'' string
+occurring in the base IRI.
+To solve the problem, a marker has to be included in the URI which definitely
+indicates the beginning of the table name. In addition, this marker will
+uniquely identify Entity map OWL class IRIs.
+For both aims to be achieved, an escape symbol must be used, which makes
+the marker unique at least outside the base IRI part, by escaping the marker
+whenever it occurs in the table name.
+
+Regarding Identifier map IRI patterns, the IRI resulting from the expansion of
+the pattern will contain the column names of the primary key represented by
+the respective Identifier map \cite{eng}.
+Further on, the table name of the database table containing that primary
+key has to be included in the IRI pattern, since
+two distinct tables may have primary keys with equally named columns.
+This will make the IRI pattern a unique Identifier map IRI pattern,
+since a database table can be assumed to only have one primary key,
+as is the case in common database systems like SQL \cite{sql}.
+The fact that primary key values are unique for each dataset ensures that
+unique Identifier map IRI patterns expand to unique IRIs.
+Moreover, it has to be ensured, that IRIs resulting from the expansion of
+Identifier map IRI patterns do not collide with IRIs of other kinds.\\
+Taking arbitrary and particularly varying base IRIs into account,
+a definite marker has to be included in the IRI pattern and other occurrences
+of this marker in the IRI pattern have to be escaped. This uniquely
+identifies Identifier map IRI patterns and unambiguously
+distinguishes the table name from the rest of the IRI.
+
+Concerning Attribute map OWL property IRIs, they will be unique among their
+kind when they include the column name of the database column they
+represent besides the table name of the table containing it,
+since database table names can be assumed to be distinct and
+column names can be assumed to be unique within a table, which is
+guaranteed in a common database system like SQL \cite{sql}.
+Furthermore, Attribute map OWL property IRIs have to be prevented from
+colliding with IRIs of other kinds.\\
+Taking arbitrary and particularly varying base IRIs into account,
+definite markers have to be included in the IRI and other occurrences
+of this marker in the IRI have to be escaped. This uniquely
+identifies Attribute map OWL property IRIs and unambiguously
+distinguishes the table name and the column name from the rest of the IRI
+and from one another.
+
+Regarding Relation map OWL property IRIs, including the table name and
+the column names of both the foreign key represented by the Relation map
+(or the containing table, respectively) and the referenced key (or its
+containing table, respectively) in the IRI will make it a unique
+Relation map OWL property IRI.
+Note that including only the table name and the column names of the foreign
+key (or its containing table, respectively) would not be sufficient, since
+several distinct foreign keys covering exactly the same columns can exist
+in a table (this is what the IRI generation scheme of the direct mapping
+approach misses). The same applies of course for the referenced table and
+its columns -- several foreign keys can reference them.
+Moreover, these Regarding Relation map OWL property IRIs have to be
+prevented from colliding with IRIs of other kinds.\\
+Taking arbitrary and particularly varying base IRIs into account,
+definite markers have to be included in the IRI pattern and other occurrences
+of this marker in the IRI have to be escaped. This uniquely
+identifies Relation map OWL property IRIs and in particular their parts
+providing the table and column names.
+
+Concerning Subtype map IRI prefixes, they must include the column name of
+the database column containing the values to be declared belonging to
+the subclass. Further on, since another database table could contain a
+column of the same name, the IRI must include the table name of the
+database table containing the column.
+This will make Subtype map IRI prefixes unique among their kind.
+Note that a Subtype map IRI prefix, similarly to a IRI pattern,
+does not specify the final IRI but is subject to expansion.
+This expansion can yield the same IRI for different data records, which,
+however, is not considered a collision, since this behavior is
+intentional -- every two data records having the same value in
+the respective column, and only those, will get the same IRI.
+Additionally, it has to be ensured, that IRIs resulting from such an
+expansion do not collide with IRIs of other kinds.\\
+Taking arbitrary and particularly varying base IRIs into account,
+definite markers have to be included in the IRI pattern and other occurrences
+of this marker in the IRI prefix have to be escaped. This uniquely
+identifies Subtype map IRI prefixes and unambiguously
+distinguishes the table name and the column name from the rest of the IRI
+and from one another.
+
+For an example that makes awkwardly -- or fraudulently -- chosen base
+IRIs introduce name clashes, see the paragraph about Entity map
+OWL class IRIs at the beginning of this section.
+
+\subsection{The proposed IRI generation scheme}
+\label{iris_scheme}
+This section introduces an IRI generation scheme meeting the requirements
+formulated in Section~\ref{iris_req}.
+
+In this section, the following strings are subsumed under the term
+\emph{marking strings}:\\
+``\code{TABLE\_\_}'', ``\code{TBL\_\_}'', ``\code{PROP\_\_}'',
+``\code{REF\_\_}'' and ``\code{SUBTYPE\_\_}''.\\
+The string built by escaping (prefixing) all occurrences of marking strings or
+`\textasciitilde' characters in a string $s$ with a `\textasciitilde'
+character will be called the \emph{IRI-safe version} of $s$.
+
+The IRI generation scheme is presented in Table~\ref{bootstrap_tab_iris}.
+Here, \\ \emph{<base:>} refers to the base IRI to be used for
+the generated IRI (see Section~\fullref{back_basic}),\\
+\emph{<cl. tbl name>} refers to the table name of the database table
+concerning (see Section~\ref{iris_clashes}) in its IRI-safe version,\\
+\emph{<cl. name 1st pk col>} refers to the name of the first primary key
+column concerning (see Section~\ref{iris_clashes}) in its IRI-safe version,\\
+\emph{<\code{/}...>} refers to the continuation of the previous pattern
+using the remaining primary key or foreign key columns,\\
+\emph{<cl. col name>} refers to the name of the column in question
+(see Section~\ref{iris_clashes}) in its IRI-safe version,\\
+\emph{<cl. src tbl>} refers to the table name of the database table
+containing the respective foreign key (see Section~\ref{iris_clashes})
+in its IRI-safe version,\\
+\emph{<cl. 1st src col>} refers to the name of the first foreign key
+column of the respective foreign key (see Section~\ref{iris_clashes})
+in its IRI-safe version,\\
+\emph{<cl. tgt tbl>} refers to the table name of the table referenced by
+the respective foreign key (see Section~\ref{iris_clashes})
+in its IRI-safe version and\\
+\emph{<cl. 1st tgt col>} refers to the name of the first column referenced
+by the respective foreign key (see Section~\ref{iris_clashes})
+in its IRI-safe version.\\
+
+\begin{table}[H]\begin{centering}
+               \begin{tabular}{p{6.3cm}|p{9.7cm}}
+                       \textbf{IRI type} & \textbf{Proposed IRI} \\ \hline
+                       Entity map OWL class IRI & <base:>\code{TABLE\_\_}<cl. tbl name>\\
+                       Identifier map IRI pattern & <base:>\code{TBL\_\_}<cl. tbl name>\code{/}<cl. name 1st pk col>\newline \ind{} \code{/\{\$1\}/}<\code{/}...>\\
+                       Attribute map OWL property IRI & <base:>\code{PROP\_\_}<cl. tbl name>\code{\_\_}<cl. col name>\\
+                       Relation map OWL property IRI & <base:>\code{REF\_\_}<cl. src tbl>\code{/}<cl. 1st src col>\newline \ind{} <\code{/}...>\code{/}<cl. tgt tbl>\code{/}<cl. 1st tgt col><\code{/}...>\\
+                       Subtype map IRI prefixes & <base:>\code{SUBTYPE\_\_}<cl. tbl name>\code{\_\_}\newline \ind{} <cl. col name>\code{/}\\
+%                      % Slanted and with underscores and without "clean":
+%                                                                      Entity map OWL class IRI & \textit{<base>}\code{:TABLE\_\_}\textit{<table\_name>}\\
+%                                                                      Identifier map IRI pattern & \textit{<base>}\code{:TBL\_\_}\textit{<table\_name>}\code{/}\textit{<name\_1st\_pk\_col>}\newline \ind{} \code{/\{\$1\}/}\textit{<\code{/}...>}\\
+%                                                                      Attribute map OWL property IRI & \textit{<base>}\code{:PROP\_\_}\textit{<table\_name>}\code{\_\_}\textit{<col\_name>}\\
+%                                                                      Relation map OWL property IRI & \textit{<base>}\code{:REF\_\_}\textit{<src\_table>}\code{/}\textit{<1st\_fk\_src\_col>}\newline \ind{} \textit{<\code{/}...>}\code{/}\textit{<tgt\_table>}\code{/}\textit{<1st\_fk\_tgt\_col>}\textit{<\code{/}...>}\\
+%                                                                      Subtype map IRI prefixes & \textit{<base>}\code{:SUBTYPE\_\_}\textit{<table\_name>}\code{\_\_}\textit{<col\_name>}\code{/}\\
+               \end{tabular}
+               \caption{Proposed IRIs to be used in OBDA specification map fields}
+               \label{bootstrap_tab_iris}
+\end{centering}\end{table}
+
+It is easily verified that the proposed IRI scheme is correct
+regarding the requirements described in Section~\ref{iris_req}:
+it provides unique IRIs for all types of IRIs it allows to create,
+regardless of the chosen base IRI
+(see proof in Section~\ref{iris_proof}).
+Furthermore, the IRI scheme is expressive: ignoring the base
+IRI part, the kind of entity identified by the IRI can be
+determined by beginning of the IRI.
+In addition, it is regular in that
+the name of the containing table always occurs before the
+name of the first database column.
+
+Taking the information in Section~\ref{iris_clashes} into account,
+it is trivial to observe that the suggested IRI scheme, leaving
+out the demand of IRI-safe versions, is still correct, given that
+all IRIs are generated using the same base IRI.
+
+Note that it is in any case necessary that the beginnings
+of all kinds of IRIs be mutually different:
+if, for example, an Identifier map IRI pattern also would
+commence with ``<base:>\code{TABLE\_\_}'', a table named
+``\code{PERSONS/\{17\}}'' -- which is a valid table name for
+example in SQL \cite{sql} -- possibly could get an Entity map OWL
+class IRI assigned which clashes with the IRI resulting from the
+expansion of the IRI pattern
+``<base:>\code{TABLE\_\_PERSONS/\{\$1\}}''.
+
+\subsection{Proof of correctness of the proposed IRI scheme}
+\label{iris_proof}
+As described in Section~\ref{iris_req}, the previously described
+IRI schema is required to generate several types of IRIs without
+introducing name clashes, thus two equal IRIs for two distinct
+entities, independently of the chosen base IRIs.
+Additionally, the user shall be able to chose additional IRIs
+he can be sure won't collide with IRIs generated with the scheme
+from an infinite set.
+
+In this proof, like in Section~\ref{iris_clashes}, the strings
+``\code{TABLE\_\_}'', ``\code{TBL\_\_}'', ``\code{PROP\_\_}'',
+``\code{REF\_\_}'' and ``\code{SUBTYPE\_\_}'' are called
+\emph{marking strings}.\\
+Strings prefixed by `\textasciitilde' are referred to as
+\emph{escaped}, while strings not prefixed by `\textasciitilde'
+are referred to as \emph{unescaped}.
+
+In the following, it is proven that the IRIs of each type do not
+clash, neither among themselves nor with IRIs of other types.
+Since all generated IRIs begin with a marking string, every IRI \emph{not}
+beginning with a marking string, thus an infinite quantity,
+is sure not to collide with any of the generated IRIs, and so,
+the correctness regarding to the stated requirements is then proven.
+
+Each Entity map OWL class IRI (including its base IRI) is of the form
+$\alpha$\code{TABLE\_\_}$\beta$, with $\alpha$ not ending with `\textasciitilde'
+and $\alpha$ and $\beta$ not containing any unescaped marking strings.\\
+Thus, $\beta$ is the table name, making the IRI unique among all
+other Entity map OWL class IRIs (see considerations in
+Section~\ref{iris_clashes}).
+Because the IRI does not contain any unescaped marking strings,
+it cannot collide with any IRI of another type and thus is indeed unique.
+
+The proof for Identifier map IRI patterns, Attribute map OWL property IRIs,
+Relation map OWL property IRIs and Subtype map IRI prefixes is exactly
+analog.
+
+\hfill $\Box$
\ No newline at end of file
index b2f67e0..b141ab7 100644 (file)
@@ -1,21 +1,39 @@
 \section{Ontology bootstrapping using OBDA specifications}
 \label{bootstrap_spec}
+TODO: only mapping, no duplication, r2rml
 
 \subsection{Structure of OBDA specifications}
+\label{bootstrap_spec_struc}
 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{Attribute maps} describing database columns,
 \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}.
+Here, each field specifies, in that order, the field label, the field's
+long name, the bootstrapping steps in which the field is used and the
+field's short name. Fields storing a set of values have both their short
+and their long name suffixed with ``\code{...}''.
+Note that each reference between two fields is denoted with a short field
+name contained in the source of the reference, specifying the field
+in which the reference is stored.
+What the values of the fields of the several types of maps express
+exactly and how they can be used is described in
+Section~\ref{bootstrap_spec_using}.
+For a full description as well of the structure of OBDA specifications
+as of their application and the general idea behind them,
+refer to \cite{eng}.
+How OBDA specifications can in turn be automatically bootstrapped,
+excluding Subtype maps and Translation tables is
+described in Section~\ref{bootstrap_bootstrap}.
 
 \begin{figure}[H]\begin{center}
                \includegraphics[scale=1.0]{Images/specification_structure.pdf}
@@ -25,9 +43,445 @@ references is shown in Figure~\ref{spec_fig_structure}.
                \label{spec_fig_structure}
 \end{center}\end{figure}
 
-While ,
-Subtype maps and Translation tables.
+Entity maps, Identifier maps, Attribute maps and Relation maps
+directly relate to database concepts and each of them describes
+exactly one database table, primary key, column or foreign key,
+respectively, and vice versa.
+Subtype maps and Translation tables, on the other hand,
+represent concepts of the bootstrapping process or data to be added to
+the target ontology and are somewhat harder to obtain:
+Subtype maps represent ``is-a'' relationships in the target ontology
+to be determined from the source data \cite{eng} -- heuristically or
+semi-automatically --, while Translation tables allow for the
+transformation of data values,
+for example from \code{TRUE} to \code{true} or from \code{No} to
+\code{false} \cite{eng}.
+Therefore, they also have to be determined heuristically or semi-
+automatically from the source data --
+considering the database schema only is not sufficient \cite{eng}.
+Note that, because of this, special care has to be taken to keep the maps
+synchronized with the data in case of Subtype maps and Translation tables.
+
+The structural description of OBDA specifications in \cite{eng}
+does not propose a serialization format in which OBDA specifications can
+be stored or read and written by software and human agents.
+How this can be done is subject to this thesis, which introduces the
+\oslboth{} designed exactly for this purpose in Chapter~\ref{osl}.
 
 \subsection{Using OBDA specifiations}
+\label{bootstrap_spec_using}
+TODO: dirm
+TODO: r2rml
+
+As described in in Section~\fullref{back_obdaspecs}, using OBDA
+specifications provides several benefits when concerned in ontology
+bootstrapping.
+Principally, information about the bootstrapping process is collected in
+one place and can be used to manage the tools involved.
+This includes the availability of the URIs to be used in the constructed
+ontology from a central place, which is a great advantage, since URIs
+are central to an ontology TODO.
+Additionally, all information on the database schema of the source
+database is available.
+Using Translation tables, all these information can at will be made
+subject to transformations normalizing or correcting the data
+changing the database \cite{eng}.
+
+By the use of a single specification language like the \oslboth{}
+to store OBDA specifications,
+the expense of converting between different data formats can be
+reduced significantly:
+assumed that there are $n$ different formats to be handled with no means
+provided to convert between them, the converting costs decrease from
+$\mathcal{O}(n^2)$ to $\mathcal{O}(n)$ by introducing a single central
+language TODO.
+
+Besides the structure of OBDA specifications, described in
+Section~\ref{bootstrap_spec_struc}, Skjæveland et al. introduce a set
+of formal rules defining the bootstrapping process and the mapping of the
+source data to the generated ontology \cite{eng}.
+Using an OBDA specification, tools implementing these rules can
+easily and in a well-defined manner bootstrap an ontology and
+a mapping from the source data onto this ontology (or duplicate that
+source data, if the materialized OBDA approach is used, see
+Section~\ref{back_obda}).
+The mapping rules produce RDF triples which can be interpreted by R2RML
+to establish the mapping (see Section~\fullref{back_basic}).
+They are accompanied by SQL statements specifying the
+queries over the source database used to link the ontology to the data.
+If the data source is not a relational database but another form of
+structured data, like \name{CSV} files, a database schema can be
+bootstrapped first by applying additional ``database rules'' \cite{eng}.
+Afterwards, the proceeding can continue as if the data source were a
+database, so this case is neglected in the following.
+
+The rest of this section contains description of the information contained
+in the various types of OBDA specification maps and how it is used during
+bootstrapping, based on the description in \cite{eng}.
+Keep in mind that ``bootstrapping'' here refers to the ontology
+bootstrapping process specified by the OBDA specification, yielding a
+target ontology and mappings
+relating it to the source database -- it does not refer to the
+bootstrapping of the OBDA specification itself.
+The text is meant to give a brief explanatory overview over the bootstrapping
+process using OBDA specifications.
+Thus, it focuses on the information they provide and how they are used to
+link the bootstrapped ontology to the source data, leaving out the
+SQL statements to be used to gain the datasets.
+How exactly the ontology is created is also left out, since this would have
+involved introducing too many technical details, and moreover, the topic is
+also comprehensible by describing the mapping only.
+For a detailed description of the bootstrapping process, including ontology
+creation and all formal rules to be applied, see \cite{eng}.
+For an explanation about how an OBDA specification containing Entity maps,
+Identifier maps, Attribute maps and Relation maps can be bootstrapped from
+a relational database schema, see Section~\ref{bootstrap_bootstrap}.
+For details on URI generation, refer to Section~\fullref{iris}.
+
+\subsubsection{Entity maps}
+Entity maps provide information about the tables contained in the
+source database or in the intermediate database schema to be constructed,
+if the data source is not a database but some other source of structured
+information (see Section~\fullref{back_obda}).
+The information provided by an Entity map includes the table name,
+a label describing the table and a (more detailed) description
+of the table.
+Furthermore, each Entity map references an Identifier map representing
+its primary key and a set of Attribute maps representing its columns.
+Finally, an Entity map provides an OWL class URI identifying the
+represented table uniquely in the resulting ontology.
+As the name suggests, this URI is given to an OWL class which serves as
+OWL type (or more precisely: \code{rdf:type}) for all OWL individuals
+representing the datasets from the respective table in the target ontology
+(see Paragraph~``\nameref{iden}'').
+
+Suppose, for example, that an Entity map for a table ``\code{persons}''
+provides the OWL class URI ``\code{mydb:persons}''.
+Then, in the target ontology, all OWL individuals representing rows in the
+``\code{persons}'' table, will be of \code{rdf:type}
+``\code{mydb:persons}''.
+If a data record in the ``\code{persons}'' table has the identifying URI
+pattern ``\code{mydb:person/\{pno\}}'' (see Paragraph~\nameref{iden}),
+this type information will be expressed by the following RDF triple:\\
+\code{mydb:person/\{pno\} rdf:type mydb:persons}.
+
+\subsubsection{Identifier maps}
+\label{iden}
+Identifier maps describe database primary keys contained in the
+source database or in the intermediate database schema to be constructed,
+if the data source is not a database (see Section~\ref{back_obda}).
+Each Identifier map contains a reference back to the respective
+Entity map, representing the database table the primary key belongs to.
+Furthermore, each Identifier map references a set of Attribute maps,
+representing the database columns the primary key consists of
+(see next paragraph).
+Finally, an Identifier map provides a URI pattern, allowing OWL
+individuals in the bootstrapped target ontology that represent
+datasets to be identified.
+A URI pattern contains placeholders like ``\code{\{\$1\}}'' for
+all primary key columns, which are replaced with the respective column
+names, surrounded by curly braces, during the bootstrapping process,
+to yield a valid R2RML template \cite{r2rml}.
+Since the column name substituted in is still a placeholder,
+the result of this substitution is still a URI pattern and not a URI.
+Since such a URI pattern uniquely identifies a dataset from a given
+database table -- when data values are substituted in --,
+it will be called \emph{identifying URI pattern} in the following.
+
+Consider the URI pattern ``\code{mydb:person/\{\$1\}}''.
+Replacing the placeholder ``\code{\{\$1\}}'' with the column name
+``\code{pno}'' in curly braces yields the following identifying URI
+pattern: \\ ``\code{mydb:person/\{pno\}}''.
+
+\subsubsection{Attribute maps}
+Attribute maps provide information about database columns contained in the
+source database.
+Each Attribute map carries the column name, information whether having a
+value in this column is mandatory for a dataset (in SQL terms: whether it
+has a \code{NOT NULL} constraint), a label describing the column as well as
+an extended description of the column.
+A database column is represented as a relation in the final ontology, thus,
+in OWL terms, as an \code{owl:DataProperty} or an \code{owl:ObjectProperty}.
+The Attribute map provides the URI for this OWL property.
+
+Additionally, it specifies the datatype of values in the
+represented column in the following manner:
+Three fields are provided for this purpose, \code{SQL datatype},
+\code{RDF language} and \code{XSD datatype}.
+If the \code{XSD datatype} field is nonempty, its value is specified to be
+the datatype for values in the column the Attribute map represents
+(note that OWL only knows XSD datatypes TODO).
+Otherwise, if the value of the \code{SQL datatype} is a standard SQL type,
+it will be mapped to an XSD datatype and the resulting type is
+specified as datatype for values in the respective column.
+If neither of the above is the case and the \code{RDF language} field is
+nonempty, values in the respective column will be interpreted as strings
+with the value of the \code{RDF language} field applied as RDF language tag
+(TODO).
+If neither of the above is the case, values in the respective column will be
+interpreted as strings without an RDF language tag.
+
+Finally, an Attribute map specifies whether the column shall be represented
+as an \\ \code{owl:DataProperty} (for non-foreign-key columns) or as an
+\code{owl:ObjectProperty} (for foreign key columns).
+The field specifying that -- \code{Property type} -- also allows, as a
+further distinction of object properties, whether the property's
+target URI should be the column name placed in an URI pattern
+provided by the Attribute map,
+similarly to URI patterns in Identifier maps (see example at the end of this
+paragraph), or if it shall simply be the column name, possibly with a
+translation from a Translation table, specified by the Attribute map,
+applied.
+The former option is useful for example when using custom property URIs
+to express relations between source data and the target ontology.
+If an \code{owl:DataProperty} is generated, it always has the column name
+as target URI, without the use of an URI pattern.
+Note that it is sufficient to have the column name be the target of the
+property, since only a \emph{mapping} to the source data is generated.
+
+Consider an Attribute map representing a column named ``\code{name}'' to
+be mapped to an \\ \code{owl:DataProperty}.
+Suppose the OWL property URI the Attribute map specifies is\\
+``\code{mynamespace:lastName}'' and each dataset containing the
+\code{name} column has the identifying URI pattern
+``\code{mydb:person/\{pno\}}'' (see Paragraph~``\nameref{iden}'').
+Then, during the bootstrapping process
+the following RDF triple will be produced:\\
+\code{mydb:person/\{pno\} mynamespace:lastName "\{name\}"}.\\
+This triple can easily be interpreted by R2RML, which on request then
+retrieves the queried \code{name} from the data source.
+
+Consider, as a more elaborate example,
+an Attribute map representing a column named
+``\code{company}'' and to be mapped to an \code{owl:ObjectProperty} with the
+use of the URI pattern ``\code{http://otherdb/\{\$1\}}''.
+Suppose the OWL property URI the Attribute map specifies is
+``\code{mynamespace:hasSameOwnerAs}'', there is no datatype specified
+and each dataset containing the
+\code{company} column has the identifying URI pattern
+``\code{mydb:company/\{cmpno\}}''
+(see Paragraph~``\nameref{iden}'').
+Then, the following RDF triple will be produced during the bootstrapping
+process:\\
+\code{mydb:company/\{cmpno\} mynamespace:hasSameOwnerAs
+       http://otherdb/\{company\}}.\\
+Note that this only makes sense if R2RML can expand
+``\code{http://otherdb/\{company\}}'' to a valid subject
+for each value in the \code{company} column of the database,
+and if all rows in the respective database table are
+indeed entities having the same owner as the company specified in the
+\code{company} column.
+
+\subsubsection{Relation maps}
+Relation maps represent foreign keys contained in the
+source database.
+Each Relation map references the Entity maps representing the foreign key's
+child table and parent table, respectively.
+Furthermore, it provides the column names of both the foreign key columns
+and the referenced columns and specifies an OWL property URI.
+Relation maps allow the relations expressed in the source data via
+foreign key relationships to be included into the bootstrapped ontology.
+This happens in a simple and straight-forward manner:
+for each foreign key relationship, exactly one triple is generated which
+contains the two identifying
+URI patterns representing the source and the target dataset of the foreign
+key, respectively, and the OWL property URI specified by the Relation map.
+
+Suppose, for example, that a Relation map expressing a relation between
+datasets with the identifying URI patterns (see Paragraph~``\nameref{iden}'')
+``\code{mydb:persons/pno/\{pno\}}'' and
+``\code{mydb:companies/cmpno/\{cmpno\}}'', respectively, and specifying
+the OWL property URI ``\code{mynamespace:isEmployedAt}''.
+This will result in the following RDF triple to be generated during the
+bootstrapping process:\\
+\code{mydb:persons/pno/\{pno\} mynamespace:isEmployedAt
+        mydb:companies/cmpno/\{cmpno\}}
+
+\subsubsection{Subtype maps}
+Subtype maps provide a means to automatically add subclass-superclass
+relationships to the target ontology during the bootstrapping process.
+They specify an Entity map and a column name defining a table and a
+column, respectively, that exist in the source database and contain the
+values to be declared as belonging to the subclass.
+Furthermore, they store a prefix, a suffix and possibly a reference to
+a Translation table which are used to generate a URI for that subclass.
+Finally, they provide the URI of the superclass.
+This can be, for instance, some OWL class being created during the
+bootstrapping process or already existing in some imported ontology.
+The URI generated for the subclass contains the data value of the
+respective database column, thus every dataset gets its own (sub)class.
+During bootstrapping, an RDF triple declaring the value to belong to that
+subclass is generated for each data value of the respective table column in
+the source database.
+The limitation to the desired value only thereby happens by a restriction
+on the SQL statement accompanying the respective triple, not by
+limiting the triple to only cover a specific data value.
+The actual subclass-superclass relationship is expressed during the
+creation of the ontology.
+Note the difference from the previously described mapping rules, which
+produced triples independent from the data values in the source database.
+
+Consider a Subtype map specifying a table column containing the values
+``\code{Purchase}'' and ``\code{Sales}'' with the datasets having the
+identifying URI pattern (see Paragraph~``\nameref{iden}'')
+``\code{mydb:managers/mno/\{mno\}}''.
+Suppose, the Subtype map specifies the prefix\\
+``\code{mydb:manager/of\_department/}'', no suffix, no translation table
+and the supertype URI ``\code{mynamespace:persons}''.
+This will result in the generation of the following triples during the
+bootstrapping process:\\
+\code{mydb:managers/mno/\{mno\} rdf:type mydb:manager/of\_department/Purchase}\\
+\code{mydb:managers/mno/\{mno\} rdf:type mydb:manager/of\_department/Sales},\\
+while ``\code{mydb:manager/of\_department/Purchase}'' \\ and
+``\code{mydb:manager/of\_department/Sales}'' will be subclasses of class\\
+``\code{mynamespace:persons}'' in the target ontology.
+The accompanying SQL statement will ensure that, despite the use of the
+R2RML template ``\code{mydb:managers/mno/\{mno\}}'', not \emph{every}
+manager will be declared as the manager of \emph{every} department.
+
+\subsubsection{Translation tables}
+Translation tables allow for transforming URIs or other strings in
+arbitrary ways, by simply mapping each string to be translated to a
+target string.
+
+They don't reflect in the target ontology in any form but are used
+only during the bootstrapping process.
 
 \subsection{Bootstrapping OBDA specifications}
+\label{bootstrap_bootstrap}
+How OBDA specifications can in turn be bootstrapped from database schemata
+is subject to this thesis and is explained in this section.
+For the description of the software developed to automate this, see
+Chapter~\fullref{program}.
+The description in this section assumes an SQL database as data source.
+However, ontology-based data access and OBDA specifications are not limited
+to SQL databases, as mentioned in Section~\fullref{back_obda} and in
+Section~\fullref{bootstrap_spec_using}.
+Furthermore, this section refers to OBDA specifications without assuming
+any specific format in which they are represented.
+How OBDA specifications are represented internally by the \myprog{}
+software, is described in Section~\fullref{fine}.
+For the description of a format to serialize OBDA specifications
+-- the output format of \myprog{} --,
+refer to Chapter~\fullref{osl}.
+
+Subtype maps and Translation tables are not considered in this approach,
+since they cannot be bootstrapped from schema information only but have to
+be determined from the input data (see Section~\fullref{bootstrap_spec_struc}).
+Thus, the bootstrapped OBDA specification does not contain maps of these
+types. Including them is a significant challenge in its own right and,
+since the use of heuristics or user decisions would be necessary,
+would make the process involve human supervision at least.
+Apart from that, the bootstrapping is an easy and straight-forward task
+which can be carried out fully automatic TODO.
+
+Recall the structure of an OBDA specification explained in
+Section~\fullref{bootstrap_spec_struc}.
+The map types considered in this approach are Entity maps, Attribute maps,
+Identifier maps and Relation maps.
+The assignment of values to their fields is summarized in
+Table~\ref{bootstrap_tab_mapping}, only hinting at how maps are
+generated. Both the generation of the maps and the assignment of values
+to their fields are described in the rest of this section, with one
+exception:
+since the generation of URIs (or IRIs) in the context of OBDA specifications
+is an essential topic which requires some conceptual efforts, it is
+described in a separate section, Section~\ref{iris}.
+
+\begin{table}[H]\begin{centering}
+               \begin{tabular}{p{3.2cm}|p{4.0cm}|p{8.3cm}}
+                       \textbf{Map type} & \textbf{Field name} & \textbf{Value} \\ \hline
+                       Entity map & Table name & SQL table name \\
+                       Entity map & Label & <empty> \\
+                       Entity map & \emph{Identifier map} & Identifier map for table \\
+                       Entity map & \emph{Attribute maps...} & Attribute maps for table columns \\
+                       Entity map & OWL class URI & URI(table) \\
+                       Entity map & Description & SQL table description \\ \hline
+                       Identifier map & \emph{Entity map} & Entity map for corresponding table \\
+                       Identifier map & \emph{Attribute maps...} & Attribute maps for primary key columns \\
+                       Identifier map & URI pattern & URIpattern(table) \\ \hline
+                       Attribute map & Column name & SQL column name \\
+                       Attribute map & SQL datatype & SQL datatype of column \\
+                       Attribute map & Mandatory & SQL \code{NOT NULL} property of column\newline(\code{true} or \code{false}) \\
+                       Attribute map & Label & <empty> \\
+                       Attribute map & OWL property URI & <empty> for foreign key columns,\newline else URI(table, column) \\
+                       Attribute map & Property type & ``\code{ObjectProperty}'' for foreign key columns,\newline else ``\code{DataProperty}'' \\
+                       Attribute map & \emph{Translation} & <empty> \\
+                       Attribute map & URI pattern & <empty> \\
+                       Attribute map & RDF language & <empty> \\
+                       Attribute map & XSD datatype & <empty> \\
+                       Attribute map & Description & SQL column description \\ \hline
+                       Relation map & \emph{Source entity map} & Entity map for foreign key child table \\
+                       Relation map & Source column & Foreign key child columns\newline(SQL column names) \\
+                       Relation map & \emph{Target entity map} & Entity map for foreign key parent table \\
+                       Relation map & Target column & Foreign key parent columns\newline (SQL column names) \\
+                       Relation map & OWL property URI & URI(table, foreignKey) \\
+               \end{tabular}
+                       \caption{Assignment of values to fields of OBDA specification maps}
+                       \label{bootstrap_tab_mapping}
+\end{centering}\end{table}
+
+\subsubsection{Entity maps}
+Exactly one Entity map and one Identifier map is generated per table
+contained in the source database.
+The generated Identifier map is referenced by the Entity map's
+\code{Identifier map} field.
+Similarly, exactly one Attribute map is generated per table column
+and these Attribute maps are referenced by the Entity map's
+\code{Attribute maps...} field.
+The Entity map's \code{Table name} field is set to the SQL name of
+the table, the \code{Label} field remains empty.
+An URI identifying the table is generated and stored in the
+Entity map's \code{OWL class URI} field.
+The SQL table description is copied into the Entity map's
+\code{Description} field.
+
+\subsubsection{Identifier maps}
+An Identifier map represents exactly one primary key in the source
+database and is referenced by the Entity map representing the table
+containing the primary key constraint.
+In addition, it references this table in its
+\code{Entity map} field, so that there is a bidirectional referencing.
+The Attribute maps representing the columns constituting the primary
+key are referenced by the Identifier map's \code{Attribute maps...}
+field.
+An URI pattern, allowing datasets (thus, rows in the source database)
+to be identified in the target ontology, is generated and put in
+the Identifier map's \code{URI pattern} field.
+
+\subsubsection{Attribute maps}
+An Attribute map represents exactly one column in the source database
+and is referenced by the Entity map representing the table
+containing the column.
+The Attribute map's \code{Column name} field is set to the SQL column
+name of the column, the \code{SQL datatype} field is set
+to its SQL datatype.
+The \code{Mandatory} field is set to \code{true} if the column has
+the SQL \code{NOT NULL} constraint, otherwise to \code{false}.
+If the column is part of a foreign key, the \code{OWL propert URI}
+field remains empty. Otherwise,
+an URI identifying the column is generated and stored in the
+Attribute map's \code{OWL property URI} field.
+The \code{Property type} field is set to ``\code{ObjectProperty}''
+if the column is part of a foreign key, otherwise to
+``\code{DataProperty}''.
+The SQL column description is copied into the Attribute map's
+\code{Description} field.
+The remaining columns, \code{Label}, \code{Translation},
+\code{URI pattern}, \code{RDF language} and \code{XSD datatype}
+remain empty.
+
+\subsubsection{Relation maps}
+A Relation map represents exactly one foreign key in the source database.
+It contains fields storing the parent and child table of the foreign
+key: the \code{Source entity map} field, referencing the
+Entity map representing the child table of the foreign key, and
+the \code{Target entity map} field, referencing the
+Entity map representing the parent table of the foreign key.
+The SQL column names of the foreign key columns (thus, column names
+in the child table) are copied into the \code{Source column}
+field of the Relation map, and the SQL column names of the referenced
+columns in the parent table are copied into its \code{Target column}
+field.
+Note that, in contrast to Identifier maps representing primary keys,
+it is not referenced by any Entity map (or any other map).
index 5a00b3c..ed8f92e 100644 (file)
@@ -107,7 +107,7 @@ 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}
+       \ind{}(final FutureTask<DBSchema> retriever) throws SQLException}
 
 It could have been called \code{promptAbortRetrieveDBSchema} only, with the
 waiting mentioned in a comment.
index f8cb257..09cde00 100644 (file)
@@ -33,7 +33,7 @@ IRIs prefixed with \texttt{osl:} are IRIs relative to the IRI\\
 
 \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}
+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,\\
@@ -55,15 +55,25 @@ been generated for it if it weren't empty).
 \begin{table}[]\begin{center}
        \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} \\
+               Entity map & $<$class URI$>$\texttt{\_\_ENTITY\_MAP} \\
+               Attribute map & $<$property URI$>$\texttt{\_\_ATTRIBUTE\_MAP} \\
+               Identifier map & $<$class URI$>$\texttt{\_\_IDENTIFIER\_MAP} \\
+               Relation map & $<$property URI$>$\texttt{\_\_RELATION\_MAP} \\
+               Subtype map & $<$class URI$>$\texttt{\_\_SUBTYPE\_MAP} \\
                Translation table of attribute map &
-                       \textit{$<$property URI$>$}\texttt{\_\_ATTRIBUTE\_MAP\_\_TRANSLATION\_TABLE} \\
+                       $<$property URI$>$\texttt{\_\_ATTRIBUTE\_MAP\_\_TRANSLATION\_TABLE} \\
                Translation table of subtype map &
-                       \textit{$<$class URI$>$}\texttt{\_\_SUBTYPE\_MAP\_\_TRANSLATION\_TABLE} \\
+                       $<$class URI$>$\texttt{\_\_SUBTYPE\_MAP\_\_TRANSLATION\_TABLE} \\
+%                                      % Slanted:
+%                                      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}
@@ -72,7 +82,7 @@ been generated for it if it weren't empty).
 
 \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}
+must be of the \name{OWL} types specified in Table~\ref{spec_tbl_types}
 (for base IRIs, see Paragraph~\ref{spec_base}).
 
 %\vspace{\spacebeforetable{}}
@@ -92,7 +102,7 @@ must be of the \name{OWL} types specified in table \ref{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}
+must have the IRIs specified in Table~\ref{spec_tbl_prop_iris}
 (for base IRIs, see Paragraph~\ref{spec_base}).
 
 %\vspace{\spacebeforetable{}}
index 1e40545..6d0deae 100644 (file)
@@ -1,5 +1,7 @@
-\chapter{The db2osl software}
+\chapter{The \myprog{} software}
 \label{program}
+TODO: uris
+
 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:
index 5904210..d3e3542 100644 (file)
@@ -1,13 +1,13 @@
-\section{Architecture}
+\section{Architecture of \myprog{}}
 \label{arch}
-\subsection{Libraries used}
-\subsection{Coarse structuring}
+\subsection{Libraries used in \myprog{}}
+\subsection{Coarse structuring of \myprog{}}
 \label{coarse}
 TODO: overall description, modularity, extendability, ex: easy to add new in-/output formats
 TODO: mapping profiles (maybe better in next subsection)
 TODO: Java, OPTIQUE
 
-\subsubsection{Package structuring}
+\subsubsection{Package structuring of \myprog{}}
 The $45$ classes of \myprog{} were assigned to $11$ packages, each containing
 classes responsible for the same area of operation or taking over similar roles.
 Care was taken that package division happened senseful, producing meaningful packages
@@ -17,10 +17,9 @@ 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}.
 
-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}.
-For a detailed package description, refer to Appendix TODO.
+The packages are introduced and described in Table~\ref{arch_tbl_packages}.
+The lists of classes each package contains are given in Table~\ref{app_tbl_classes}
+in Appendix~\fullref{app_pkgs}.
 
 \begin{table}[H]
        \begin{tabular}{p{3cm}|p{13cm}} %\KOMAoption{fontsize}{\smallerfontsize{}}
@@ -154,107 +153,24 @@ to have the driver class reside in a package called ``settings''.
 %Package \code{helpers} depends on package \code{database}, which provides the \code{static}
 %method \code{getSQLTypeName}.
 
-\subsection{Fine structuring}
+\subsection{Fine structuring of \myprog{}}
 \label{fine}
+TODO: OBDA spec rep
+
 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.
+For a list of classes contained in each package, refer to Appendix \ref{app_pkgs}.
+
 TODO: total classes etc.
 
 \subsubsection{Package contents}
 \label{package_details}
 
-Table \ref{arch_tbl_classes} lists the classes each package contains.
+Table~\ref{app_tbl_classes} lists the classes each package contains.
 The packages \code{cli}, \code{main}, \code{osl} and \code{settings} contain only
 one class each, while the by far most extensive package is \code{database},
 containing $15$ classes.
 
-\begin{table}[H]
-       \begin{multicols}{2}\begin{itemize} %\KOMAoption{fontsize}{\smallerfontsize{}}
-                       \item \code{bootstrapping}
-                       \begin{itemize}
-                               \item \code{Bootstrapping}
-                               \item \code{DirectMappingURIBuilder}
-                               \item \code{URIBuilder}
-                       \end{itemize}
-                       \item \code{cli}
-                       \begin{itemize}
-                               \item \code{CLIDatabaseInteraction}
-                       \end{itemize}
-                       \item \code{database}
-                       \begin{itemize}
-                               \item \code{Column}
-                               \item \code{ColumnSet}
-                               \item \code{DatabaseException}
-                               \item \code{DBSchema}
-                               \item \code{ForeignKey}
-                               \item \code{Key}
-                               \item \code{PrimaryKey}
-                               \item \code{ReadableColumn}
-                               \item \code{ReadableColumnSet}
-                               \item \code{ReadableForeignKey}
-                               \item \code{ReadableKey}
-                               \item \code{ReadablePrimaryKey}
-                               \item \code{RetrieveDBSchema}
-                               \item \code{Table}
-                               \item \code{TableSchema}
-                       \end{itemize}
-                       \item \code{helpers}
-                       \begin{itemize}
-                               \item \code{Helpers}
-                               \item \code{MapValueIterable}
-                               \item \code{MapValueIterator}
-                               \item \code{ReadOnlyIterable}
-                               \item \code{ReadOnlyIterator}
-                               \item \code{SQLType}
-                               \item \code{UserAbortException}
-                       \end{itemize}
-                       \newpage
-                       \item \code{log}
-                       \begin{itemize}
-                               \item \code{ConsoleDiagnosticOutputHandler}
-                               \item \code{GlobalLogger}
-                       \end{itemize}
-                       \item \code{main}
-                       \begin{itemize}
-                               \item \code{Main}
-                       \end{itemize}
-                       \item \code{osl}
-                       \begin{itemize}
-                               \item \code{OSLSpecification}
-                       \end{itemize}
-                       \item \code{output}
-                       \begin{itemize}
-                               \item \code{ObjectSpecPrinter}
-                               \item \code{OSLSpecPrinter}
-                               \item \code{SpecPrinter}
-                       \end{itemize}
-                       \item \code{settings}
-                       \begin{itemize}
-                               \item \code{Job}
-                       \end{itemize}
-                       \item \code{specification}
-                       \begin{itemize}
-                               \item \code{AttributeMap}
-                               \item \code{EntityMap}
-                               \item \code{IdentifierMap}
-                               \item \code{InvalidSpecificationException}
-                               \item \code{OBDAMap}
-                               \item \code{OBDASpecification}
-                               \item \code{RelationMap}
-                               \item \code{SubtypeMap}
-                               \item \code{TranslationTable}
-                       \end{itemize}
-                       \item \code{test}
-                       \begin{itemize}
-                               \item \code{CreateTestDBSchema}
-                               \item \code{GetSomeDBSchema}
-                       \end{itemize}
-               \end{itemize}\end{multicols} %\KOMAoption{fontsize}{\myfontsize{}}
-               \caption{Class attachment to packages in \myprog{}}
-               \label{arch_tbl_classes}
-\end{table}
-
 \subsubsection{Class organization}
 \label{hierarchies}
 Organizing classes in a structured, obvious manner such that classes have well-defined
index 595c385..f23553c 100644 (file)
@@ -5,16 +5,14 @@ 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 following section,
-leaving out self-evident features, and is then listed completely
-in the section after that.
+Its functionality is described in this section,
+leaving out self-evident features, and is then listed completely.
 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}
 The database schema is retrieved by connecting to an \name{SQL} database
 and querying its schema information.
 Parsing \name{SQL} scripts or \name{SQL} dumps currently is not supported.
@@ -54,7 +52,6 @@ are enabled, disabled or set per operation.
 Finally, a help text can be displayed which describes the usage of \myprog{} including the
 description of all command-line arguments.
 
-\subsection{Function summary}
 The functionality of the \myprog{} software can be summarized as follows:
 
 \begin{itemize}
index 6dc6a8a..047c283 100644 (file)
@@ -41,8 +41,8 @@ seen as unnecessary complicating
 while not addressing any real difficulties.
 
 The command-line arguments \myprog{} currently supports are
-described in table \ref{if_tbl_arguments_desc};
-their default values are listed in table \ref{if_tbl_arguments_def}.
+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.
 Because of this and since the change that has to be made in the source code to enable it
@@ -163,8 +163,8 @@ re-bootstrapping necessary:
 \codepar{db2osl -d mydb myserver.org | sha256sum >oldsum\\
        cp oldsum newsum\\
        while diff oldsum newsum; do\ \ \# while checksums are the same\\
-       \ind sleep 3600\ \ \# wait 1 hour\\
-       \ind db2osl -d mydb myserver.org | sha256sum >newsum\\
+       \ind{} sleep 3600\ \ \# wait 1 hour\\
+       \ind{} db2osl -d mydb myserver.org | sha256sum >newsum\\
        done\\
        rm oldsum newsum\\
        \# notify web admin via e-mail:\\
@@ -174,10 +174,10 @@ Another possible example is the integration of \myprog{} into a shell script
 that bootstraps all databases on a server:
 \codepar{regex=\textquotesingle(?!\$).*\textquotesingle\ \ \# accept all nonempty database names first\\
        while db2osl -d "\$regex" -o spec myserver.org; do\\
-       \ind dbname="\`{} sed -ne \textquotesingle/xmlns:ont/ \{ s|.*/||; s|\#"||p \}\textquotesingle\ spec \`{}"\\
-       \ind mv spec "\$dbname".osl\\
-       \ind \# don't use this database a second time:\\
-       \ind regex="\`{} printf \%s "\$regex" | sed -e "s,\textbackslash\textbackslash\textbackslash\textbackslash\$,\$|\$dbname\$," \`{}"\\
+       \ind{} dbname="\`{} sed -ne \textquotesingle/xmlns:ont/ \{ s|.*/||; s|\#"||p \}\textquotesingle\ spec \`{}"\\
+       \ind{} mv spec "\$dbname".osl\\
+       \ind{} \# don't use this database a second time:\\
+       \ind{} regex="\`{} printf \%s "\$regex" | sed -e "s,\textbackslash\textbackslash\textbackslash\textbackslash\$,\$|\$dbname\$," \`{}"\\
        done}
 
 Since the programming language used to implement \myprog{} is \name{Java},
index 09015a5..7c96006 100644 (file)
@@ -1,6 +1,6 @@
 \section{Numbers and statistics}
 \label{stats}
-
+TODO: consequences
 The following numbers and statistics can be stated about \myprog{}:
 
 \begin{table}[H]\begin{centering}