Major change
[u/philim/db2osl_thesis.git] / bootstrapping_spec.tex
1 \section{Ontology bootstrapping using OBDA specifications}
2 \label{bootstrap_spec}
3 TODO: only mapping, no duplication, r2rml
5 \subsection{Structure of OBDA specifications}
6 \label{bootstrap_spec_struc}
7 An OBDA specification consists of several so-called ``maps'', which are
8 data records containing data and references to each other describing
9 parts of the OBDA specification in statically defined fields \cite{eng}.
10 For different aspects of the specification, there are different map types,
11 while usually several maps exist for each type.
12 Namely, these are \emph{Entity maps} describing database tables,
13 \emph{Identifier maps} describing database primary keys,
14 \emph{Attribute maps} describing database columns,
15 \emph{Relation maps} describing database foreign keys,
16 \emph{Subtype maps} describing ``is-a'' relationships in the data and
17 \emph{Translation tables} describing desired translations of data.
19 The fields of the several types of maps and their interconnection via
20 references is shown in Figure~\ref{spec_fig_structure}.
21 Here, each field specifies, in that order, the field label, the field's
22 long name, the bootstrapping steps in which the field is used and the
23 field's short name. Fields storing a set of values have both their short
24 and their long name suffixed with ``\code{...}''.
25 Note that each reference between two fields is denoted with a short field
26 name contained in the source of the reference, specifying the field
27 in which the reference is stored.
28 What the values of the fields of the several types of maps express
29 exactly and how they can be used is described in
30 Section~\ref{bootstrap_spec_using}.
31 For a full description as well of the structure of OBDA specifications
32 as of their application and the general idea behind them,
33 refer to \cite{eng}.
34 How OBDA specifications can in turn be automatically bootstrapped,
35 excluding Subtype maps and Translation tables is
36 described in Section~\ref{bootstrap_bootstrap}.
38 \begin{figure}[H]\begin{center}
39                 \includegraphics[scale=1.0]{Images/specification_structure.pdf}
40                 \caption[Constitution of an OBDA specification]{
41                         Constitution of an OBDA specification.
42                         ``$\rightarrow$'' means ``references''. (from \cite{eng})}
43                 \label{spec_fig_structure}
44 \end{center}\end{figure}
46 Entity maps, Identifier maps, Attribute maps and Relation maps
47 directly relate to database concepts and each of them describes
48 exactly one database table, primary key, column or foreign key,
49 respectively, and vice versa.
50 Subtype maps and Translation tables, on the other hand,
51 represent concepts of the bootstrapping process or data to be added to
52 the target ontology and are somewhat harder to obtain:
53 Subtype maps represent ``is-a'' relationships in the target ontology
54 to be determined from the source data \cite{eng} -- heuristically or
55 semi-automatically --, while Translation tables allow for the
56 transformation of data values,
57 for example from \code{TRUE} to \code{true} or from \code{No} to
58 \code{false} \cite{eng}.
59 Therefore, they also have to be determined heuristically or semi-
60 automatically from the source data --
61 considering the database schema only is not sufficient \cite{eng}.
62 Note that, because of this, special care has to be taken to keep the maps
63 synchronized with the data in case of Subtype maps and Translation tables.
65 The structural description of OBDA specifications in \cite{eng}
66 does not propose a serialization format in which OBDA specifications can
67 be stored or read and written by software and human agents.
68 How this can be done is subject to this thesis, which introduces the
69 \oslboth{} designed exactly for this purpose in Chapter~\ref{osl}.
71 \subsection{Using OBDA specifiations}
72 \label{bootstrap_spec_using}
73 TODO: dirm
74 TODO: r2rml
76 As described in in Section~\fullref{back_obdaspecs}, using OBDA
77 specifications provides several benefits when concerned in ontology
78 bootstrapping.
79 Principally, information about the bootstrapping process is collected in
80 one place and can be used to manage the tools involved.
81 This includes the availability of the URIs to be used in the constructed
82 ontology from a central place, which is a great advantage, since URIs
83 are central to an ontology TODO.
84 Additionally, all information on the database schema of the source
85 database is available.
86 Using Translation tables, all these information can at will be made
87 subject to transformations normalizing or correcting the data
88 changing the database \cite{eng}.
90 By the use of a single specification language like the \oslboth{}
91 to store OBDA specifications,
92 the expense of converting between different data formats can be
93 reduced significantly:
94 assumed that there are $n$ different formats to be handled with no means
95 provided to convert between them, the converting costs decrease from
96 $\mathcal{O}(n^2)$ to $\mathcal{O}(n)$ by introducing a single central
97 language TODO.
99 Besides the structure of OBDA specifications, described in
100 Section~\ref{bootstrap_spec_struc}, Skj√¶veland et al. introduce a set
101 of formal rules defining the bootstrapping process and the mapping of the
102 source data to the generated ontology \cite{eng}.
103 Using an OBDA specification, tools implementing these rules can
104 easily and in a well-defined manner bootstrap an ontology and
105 a mapping from the source data onto this ontology (or duplicate that
106 source data, if the materialized OBDA approach is used, see
107 Section~\ref{back_obda}).
108 The mapping rules produce RDF triples which can be interpreted by R2RML
109 to establish the mapping (see Section~\fullref{back_basic}).
110 They are accompanied by SQL statements specifying the
111 queries over the source database used to link the ontology to the data.
112 If the data source is not a relational database but another form of
113 structured data, like \name{CSV} files, a database schema can be
114 bootstrapped first by applying additional ``database rules'' \cite{eng}.
115 Afterwards, the proceeding can continue as if the data source were a
116 database, so this case is neglected in the following.
118 The rest of this section contains description of the information contained
119 in the various types of OBDA specification maps and how it is used during
120 bootstrapping, based on the description in \cite{eng}.
121 Keep in mind that ``bootstrapping'' here refers to the ontology
122 bootstrapping process specified by the OBDA specification, yielding a
123 target ontology and mappings
124 relating it to the source database -- it does not refer to the
125 bootstrapping of the OBDA specification itself.
126 The text is meant to give a brief explanatory overview over the bootstrapping
127 process using OBDA specifications.
128 Thus, it focuses on the information they provide and how they are used to
129 link the bootstrapped ontology to the source data, leaving out the
130 SQL statements to be used to gain the datasets.
131 How exactly the ontology is created is also left out, since this would have
132 involved introducing too many technical details, and moreover, the topic is
133 also comprehensible by describing the mapping only.
134 For a detailed description of the bootstrapping process, including ontology
135 creation and all formal rules to be applied, see \cite{eng}.
136 For an explanation about how an OBDA specification containing Entity maps,
137 Identifier maps, Attribute maps and Relation maps can be bootstrapped from
138 a relational database schema, see Section~\ref{bootstrap_bootstrap}.
139 For details on URI generation, refer to Section~\fullref{iris}.
141 \subsubsection{Entity maps}
142 Entity maps provide information about the tables contained in the
143 source database or in the intermediate database schema to be constructed,
144 if the data source is not a database but some other source of structured
145 information (see Section~\fullref{back_obda}).
146 The information provided by an Entity map includes the table name,
147 a label describing the table and a (more detailed) description
148 of the table.
149 Furthermore, each Entity map references an Identifier map representing
150 its primary key and a set of Attribute maps representing its columns.
151 Finally, an Entity map provides an OWL class URI identifying the
152 represented table uniquely in the resulting ontology.
153 As the name suggests, this URI is given to an OWL class which serves as
154 OWL type (or more precisely: \code{rdf:type}) for all OWL individuals
155 representing the datasets from the respective table in the target ontology
156 (see Paragraph~``\nameref{iden}'').
158 Suppose, for example, that an Entity map for a table ``\code{persons}''
159 provides the OWL class URI ``\code{mydb:persons}''.
160 Then, in the target ontology, all OWL individuals representing rows in the
161 ``\code{persons}'' table, will be of \code{rdf:type}
162 ``\code{mydb:persons}''.
163 If a data record in the ``\code{persons}'' table has the identifying URI
164 pattern ``\code{mydb:person/\{pno\}}'' (see Paragraph~\nameref{iden}),
165 this type information will be expressed by the following RDF triple:\\
166 \code{mydb:person/\{pno\} rdf:type mydb:persons}.
168 \subsubsection{Identifier maps}
169 \label{iden}
170 Identifier maps describe database primary keys contained in the
171 source database or in the intermediate database schema to be constructed,
172 if the data source is not a database (see Section~\ref{back_obda}).
173 Each Identifier map contains a reference back to the respective
174 Entity map, representing the database table the primary key belongs to.
175 Furthermore, each Identifier map references a set of Attribute maps,
176 representing the database columns the primary key consists of
177 (see next paragraph).
178 Finally, an Identifier map provides a URI pattern, allowing OWL
179 individuals in the bootstrapped target ontology that represent
180 datasets to be identified.
181 A URI pattern contains placeholders like ``\code{\{\$1\}}'' for
182 all primary key columns, which are replaced with the respective column
183 names, surrounded by curly braces, during the bootstrapping process,
184 to yield a valid R2RML template \cite{r2rml}.
185 Since the column name substituted in is still a placeholder,
186 the result of this substitution is still a URI pattern and not a URI.
187 Since such a URI pattern uniquely identifies a dataset from a given
188 database table -- when data values are substituted in --,
189 it will be called \emph{identifying URI pattern} in the following.
191 Consider the URI pattern ``\code{mydb:person/\{\$1\}}''.
192 Replacing the placeholder ``\code{\{\$1\}}'' with the column name
193 ``\code{pno}'' in curly braces yields the following identifying URI
194 pattern: \\ ``\code{mydb:person/\{pno\}}''.
196 \subsubsection{Attribute maps}
197 Attribute maps provide information about database columns contained in the
198 source database.
199 Each Attribute map carries the column name, information whether having a
200 value in this column is mandatory for a dataset (in SQL terms: whether it
201 has a \code{NOT NULL} constraint), a label describing the column as well as
202 an extended description of the column.
203 A database column is represented as a relation in the final ontology, thus,
204 in OWL terms, as an \code{owl:DataProperty} or an \code{owl:ObjectProperty}.
205 The Attribute map provides the URI for this OWL property.
207 Additionally, it specifies the datatype of values in the
208 represented column in the following manner:
209 Three fields are provided for this purpose, \code{SQL datatype},
210 \code{RDF language} and \code{XSD datatype}.
211 If the \code{XSD datatype} field is nonempty, its value is specified to be
212 the datatype for values in the column the Attribute map represents
213 (note that OWL only knows XSD datatypes TODO).
214 Otherwise, if the value of the \code{SQL datatype} is a standard SQL type,
215 it will be mapped to an XSD datatype and the resulting type is
216 specified as datatype for values in the respective column.
217 If neither of the above is the case and the \code{RDF language} field is
218 nonempty, values in the respective column will be interpreted as strings
219 with the value of the \code{RDF language} field applied as RDF language tag
220 (TODO).
221 If neither of the above is the case, values in the respective column will be
222 interpreted as strings without an RDF language tag.
224 Finally, an Attribute map specifies whether the column shall be represented
225 as an \\ \code{owl:DataProperty} (for non-foreign-key columns) or as an
226 \code{owl:ObjectProperty} (for foreign key columns).
227 The field specifying that -- \code{Property type} -- also allows, as a
228 further distinction of object properties, whether the property's
229 target URI should be the column name placed in an URI pattern
230 provided by the Attribute map,
231 similarly to URI patterns in Identifier maps (see example at the end of this
232 paragraph), or if it shall simply be the column name, possibly with a
233 translation from a Translation table, specified by the Attribute map,
234 applied.
235 The former option is useful for example when using custom property URIs
236 to express relations between source data and the target ontology.
237 If an \code{owl:DataProperty} is generated, it always has the column name
238 as target URI, without the use of an URI pattern.
239 Note that it is sufficient to have the column name be the target of the
240 property, since only a \emph{mapping} to the source data is generated.
242 Consider an Attribute map representing a column named ``\code{name}'' to
243 be mapped to an \\ \code{owl:DataProperty}.
244 Suppose the OWL property URI the Attribute map specifies is\\
245 ``\code{mynamespace:lastName}'' and each dataset containing the
246 \code{name} column has the identifying URI pattern
247 ``\code{mydb:person/\{pno\}}'' (see Paragraph~``\nameref{iden}'').
248 Then, during the bootstrapping process
249 the following RDF triple will be produced:\\
250 \code{mydb:person/\{pno\} mynamespace:lastName "\{name\}"}.\\
251 This triple can easily be interpreted by R2RML, which on request then
252 retrieves the queried \code{name} from the data source.
254 Consider, as a more elaborate example,
255 an Attribute map representing a column named
256 ``\code{company}'' and to be mapped to an \code{owl:ObjectProperty} with the
257 use of the URI pattern ``\code{http://otherdb/\{\$1\}}''.
258 Suppose the OWL property URI the Attribute map specifies is
259 ``\code{mynamespace:hasSameOwnerAs}'', there is no datatype specified
260 and each dataset containing the
261 \code{company} column has the identifying URI pattern
262 ``\code{mydb:company/\{cmpno\}}''
263 (see Paragraph~``\nameref{iden}'').
264 Then, the following RDF triple will be produced during the bootstrapping
265 process:\\
266 \code{mydb:company/\{cmpno\} mynamespace:hasSameOwnerAs
267         http://otherdb/\{company\}}.\\
268 Note that this only makes sense if R2RML can expand
269 ``\code{http://otherdb/\{company\}}'' to a valid subject
270 for each value in the \code{company} column of the database,
271 and if all rows in the respective database table are
272 indeed entities having the same owner as the company specified in the
273 \code{company} column.
275 \subsubsection{Relation maps}
276 Relation maps represent foreign keys contained in the
277 source database.
278 Each Relation map references the Entity maps representing the foreign key's
279 child table and parent table, respectively.
280 Furthermore, it provides the column names of both the foreign key columns
281 and the referenced columns and specifies an OWL property URI.
282 Relation maps allow the relations expressed in the source data via
283 foreign key relationships to be included into the bootstrapped ontology.
284 This happens in a simple and straight-forward manner:
285 for each foreign key relationship, exactly one triple is generated which
286 contains the two identifying
287 URI patterns representing the source and the target dataset of the foreign
288 key, respectively, and the OWL property URI specified by the Relation map.
290 Suppose, for example, that a Relation map expressing a relation between
291 datasets with the identifying URI patterns (see Paragraph~``\nameref{iden}'')
292 ``\code{mydb:persons/pno/\{pno\}}'' and
293 ``\code{mydb:companies/cmpno/\{cmpno\}}'', respectively, and specifying
294 the OWL property URI ``\code{mynamespace:isEmployedAt}''.
295 This will result in the following RDF triple to be generated during the
296 bootstrapping process:\\
297 \code{mydb:persons/pno/\{pno\} mynamespace:isEmployedAt
298          mydb:companies/cmpno/\{cmpno\}}
300 \subsubsection{Subtype maps}
301 Subtype maps provide a means to automatically add subclass-superclass
302 relationships to the target ontology during the bootstrapping process.
303 They specify an Entity map and a column name defining a table and a
304 column, respectively, that exist in the source database and contain the
305 values to be declared as belonging to the subclass.
306 Furthermore, they store a prefix, a suffix and possibly a reference to
307 a Translation table which are used to generate a URI for that subclass.
308 Finally, they provide the URI of the superclass.
309 This can be, for instance, some OWL class being created during the
310 bootstrapping process or already existing in some imported ontology.
311 The URI generated for the subclass contains the data value of the
312 respective database column, thus every dataset gets its own (sub)class.
313 During bootstrapping, an RDF triple declaring the value to belong to that
314 subclass is generated for each data value of the respective table column in
315 the source database.
316 The limitation to the desired value only thereby happens by a restriction
317 on the SQL statement accompanying the respective triple, not by
318 limiting the triple to only cover a specific data value.
319 The actual subclass-superclass relationship is expressed during the
320 creation of the ontology.
321 Note the difference from the previously described mapping rules, which
322 produced triples independent from the data values in the source database.
324 Consider a Subtype map specifying a table column containing the values
325 ``\code{Purchase}'' and ``\code{Sales}'' with the datasets having the
326 identifying URI pattern (see Paragraph~``\nameref{iden}'')
327 ``\code{mydb:managers/mno/\{mno\}}''.
328 Suppose, the Subtype map specifies the prefix\\
329 ``\code{mydb:manager/of\_department/}'', no suffix, no translation table
330 and the supertype URI ``\code{mynamespace:persons}''.
331 This will result in the generation of the following triples during the
332 bootstrapping process:\\
333 \code{mydb:managers/mno/\{mno\} rdf:type mydb:manager/of\_department/Purchase}\\
334 \code{mydb:managers/mno/\{mno\} rdf:type mydb:manager/of\_department/Sales},\\
335 while ``\code{mydb:manager/of\_department/Purchase}'' \\ and
336 ``\code{mydb:manager/of\_department/Sales}'' will be subclasses of class\\
337 ``\code{mynamespace:persons}'' in the target ontology.
338 The accompanying SQL statement will ensure that, despite the use of the
339 R2RML template ``\code{mydb:managers/mno/\{mno\}}'', not \emph{every}
340 manager will be declared as the manager of \emph{every} department.
342 \subsubsection{Translation tables}
343 Translation tables allow for transforming URIs or other strings in
344 arbitrary ways, by simply mapping each string to be translated to a
345 target string.
347 They don't reflect in the target ontology in any form but are used
348 only during the bootstrapping process.
350 \subsection{Bootstrapping OBDA specifications}
351 \label{bootstrap_bootstrap}
352 How OBDA specifications can in turn be bootstrapped from database schemata
353 is subject to this thesis and is explained in this section.
354 For the description of the software developed to automate this, see
355 Chapter~\fullref{program}.
356 The description in this section assumes an SQL database as data source.
357 However, ontology-based data access and OBDA specifications are not limited
358 to SQL databases, as mentioned in Section~\fullref{back_obda} and in
359 Section~\fullref{bootstrap_spec_using}.
360 Furthermore, this section refers to OBDA specifications without assuming
361 any specific format in which they are represented.
362 How OBDA specifications are represented internally by the \myprog{}
363 software, is described in Section~\fullref{fine}.
364 For the description of a format to serialize OBDA specifications
365 -- the output format of \myprog{} --,
366 refer to Chapter~\fullref{osl}.
368 Subtype maps and Translation tables are not considered in this approach,
369 since they cannot be bootstrapped from schema information only but have to
370 be determined from the input data (see Section~\fullref{bootstrap_spec_struc}).
371 Thus, the bootstrapped OBDA specification does not contain maps of these
372 types. Including them is a significant challenge in its own right and,
373 since the use of heuristics or user decisions would be necessary,
374 would make the process involve human supervision at least.
375 Apart from that, the bootstrapping is an easy and straight-forward task
376 which can be carried out fully automatic TODO.
378 Recall the structure of an OBDA specification explained in
379 Section~\fullref{bootstrap_spec_struc}.
380 The map types considered in this approach are Entity maps, Attribute maps,
381 Identifier maps and Relation maps.
382 The assignment of values to their fields is summarized in
383 Table~\ref{bootstrap_tab_mapping}, only hinting at how maps are
384 generated. Both the generation of the maps and the assignment of values
385 to their fields are described in the rest of this section, with one
386 exception:
387 since the generation of URIs (or IRIs) in the context of OBDA specifications
388 is an essential topic which requires some conceptual efforts, it is
389 described in a separate section, Section~\ref{iris}.
391 \begin{table}[H]\begin{centering}
392                 \begin{tabular}{p{3.2cm}|p{4.0cm}|p{8.3cm}}
393                         \textbf{Map type} & \textbf{Field name} & \textbf{Value} \\ \hline
394                         Entity map & Table name & SQL table name \\
395                         Entity map & Label & <empty> \\
396                         Entity map & \emph{Identifier map} & Identifier map for table \\
397                         Entity map & \emph{Attribute maps...} & Attribute maps for table columns \\
398                         Entity map & OWL class URI & URI(table) \\
399                         Entity map & Description & SQL table description \\ \hline
400                         Identifier map & \emph{Entity map} & Entity map for corresponding table \\
401                         Identifier map & \emph{Attribute maps...} & Attribute maps for primary key columns \\
402                         Identifier map & URI pattern & URIpattern(table) \\ \hline
403                         Attribute map & Column name & SQL column name \\
404                         Attribute map & SQL datatype & SQL datatype of column \\
405                         Attribute map & Mandatory & SQL \code{NOT NULL} property of column\newline(\code{true} or \code{false}) \\
406                         Attribute map & Label & <empty> \\
407                         Attribute map & OWL property URI & <empty> for foreign key columns,\newline else URI(table, column) \\
408                         Attribute map & Property type & ``\code{ObjectProperty}'' for foreign key columns,\newline else ``\code{DataProperty}'' \\
409                         Attribute map & \emph{Translation} & <empty> \\
410                         Attribute map & URI pattern & <empty> \\
411                         Attribute map & RDF language & <empty> \\
412                         Attribute map & XSD datatype & <empty> \\
413                         Attribute map & Description & SQL column description \\ \hline
414                         Relation map & \emph{Source entity map} & Entity map for foreign key child table \\
415                         Relation map & Source column & Foreign key child columns\newline(SQL column names) \\
416                         Relation map & \emph{Target entity map} & Entity map for foreign key parent table \\
417                         Relation map & Target column & Foreign key parent columns\newline (SQL column names) \\
418                         Relation map & OWL property URI & URI(table, foreignKey) \\
419                 \end{tabular}
420                         \caption{Assignment of values to fields of OBDA specification maps}
421                         \label{bootstrap_tab_mapping}
422 \end{centering}\end{table}
424 \subsubsection{Entity maps}
425 Exactly one Entity map and one Identifier map is generated per table
426 contained in the source database.
427 The generated Identifier map is referenced by the Entity map's
428 \code{Identifier map} field.
429 Similarly, exactly one Attribute map is generated per table column
430 and these Attribute maps are referenced by the Entity map's
431 \code{Attribute maps...} field.
432 The Entity map's \code{Table name} field is set to the SQL name of
433 the table, the \code{Label} field remains empty.
434 An URI identifying the table is generated and stored in the
435 Entity map's \code{OWL class URI} field.
436 The SQL table description is copied into the Entity map's
437 \code{Description} field.
439 \subsubsection{Identifier maps}
440 An Identifier map represents exactly one primary key in the source
441 database and is referenced by the Entity map representing the table
442 containing the primary key constraint.
443 In addition, it references this table in its
444 \code{Entity map} field, so that there is a bidirectional referencing.
445 The Attribute maps representing the columns constituting the primary
446 key are referenced by the Identifier map's \code{Attribute maps...}
447 field.
448 An URI pattern, allowing datasets (thus, rows in the source database)
449 to be identified in the target ontology, is generated and put in
450 the Identifier map's \code{URI pattern} field.
452 \subsubsection{Attribute maps}
453 An Attribute map represents exactly one column in the source database
454 and is referenced by the Entity map representing the table
455 containing the column.
456 The Attribute map's \code{Column name} field is set to the SQL column
457 name of the column, the \code{SQL datatype} field is set
458 to its SQL datatype.
459 The \code{Mandatory} field is set to \code{true} if the column has
460 the SQL \code{NOT NULL} constraint, otherwise to \code{false}.
461 If the column is part of a foreign key, the \code{OWL propert URI}
462 field remains empty. Otherwise,
463 an URI identifying the column is generated and stored in the
464 Attribute map's \code{OWL property URI} field.
465 The \code{Property type} field is set to ``\code{ObjectProperty}''
466 if the column is part of a foreign key, otherwise to
467 ``\code{DataProperty}''.
468 The SQL column description is copied into the Attribute map's
469 \code{Description} field.
470 The remaining columns, \code{Label}, \code{Translation},
471 \code{URI pattern}, \code{RDF language} and \code{XSD datatype}
472 remain empty.
474 \subsubsection{Relation maps}
475 A Relation map represents exactly one foreign key in the source database.
476 It contains fields storing the parent and child table of the foreign
477 key: the \code{Source entity map} field, referencing the
478 Entity map representing the child table of the foreign key, and
479 the \code{Target entity map} field, referencing the
480 Entity map representing the parent table of the foreign key.
481 The SQL column names of the foreign key columns (thus, column names
482 in the child table) are copied into the \code{Source column}
483 field of the Relation map, and the SQL column names of the referenced
484 columns in the parent table are copied into its \code{Target column}
485 field.
486 Note that, in contrast to Identifier maps representing primary keys,
487 it is not referenced by any Entity map (or any other map).