Ontology-based data access (OBDA) is a new paradigm for managing complex information systems through semantic technologies. In this paper we present what we believe is the first industrial experience of a comprehensive OBDA project, developed jointly by Sapienza University of Rome and the Department of Treasury of the Italian Ministry of Econonomy and Finance. After illustrating the state of the art of ODBA research at the beginning of the project, we describe the various steps we have carried out in order to apply the research results in a real-world settings, and the new techniques and tools we have devised to make the overall approach effective.
Ontology-based data access [
In this paper we present what we believe is the first experience of a comprehensive
OBDA project, developed jointly by Sapienza University of Rome and the Department
of Treasury of the Italian Ministry of Economy and Finance (MEF), with the support
of Consip S.pA., an in-house IT company owned by MEF. When we started the project
in 2011, the OBDA paradigm was in its very early days. The study of OBDA had
essentially focused on the case where data is stored in a so-called ABox, a specialized
structure representing a set of membership assertions on concepts and roles. The
outcome of this study had been twofold. On the one side, it had allowed to outline the
ontology language expressibility boundaries for achieving query answering
tractability [
On the other side, assuming that data is stored in an ABox had quickly turned out to be unrealistic in practice. Indeed, organizations actual data reside in their information systems, and are typically managed by commercial DBMSs. Hence, assuming data to be stored in an ABox would require the organization either to restructure its information system in order to make it compliant with the ontology, or to devise an ExtractTransform-Load process. Clearly, both these solutions would be extremely expensive in terms of initial investment, as well as of the overall information system efficiency.
Some exceptions among works on OBDA, before 2011, are [
As for OBDA experimentation, in 2011, only few projects had been carried out,
which are reported in [
As we said before, the aim of this paper is to report on a comprehensive experimentation of the OBDA approach. In particular, the focus is on describing the various steps we have out in order to apply the research results in a real-world settings, and the new techniques and tools we had to devise according to the peculiar needs of such setting. 2
The Second Directorate of the Department of Treasury, a.k.a. the Public Dept Directorate, is responsible for the following matters: issuance and management of the public debt, liquidity management, management of the government securities amortization fund, analysis of the problems inherent to the management of the public debt at both national and international level and to the functioning of the financial markets, coordination and supervision of the access to the financial markets by public entities.
The share of greater significance is however the Central Administration debt, which consists, for the most part, of securities issued on the domestic market. The Public Dept Directorate is in turn organized into offices that deal with specific components, each of which has solved its information problems with dedicated applications, none of which can represent the whole issue of the public debt. Furthermore, the euro area debt crisis
that hit Italy in last years has led the Public Dept Directorate to introduce frequent innovations in the market of government securities, both in terms of new securities offered to expand the demand for risk diversification and greater penetration of the market, which required a greater monitoring of the secondary market. These frequent innovations put under stress the information systems, unable to respond quickly to contingent needs.
Within the above scenario, the adoption of OBDA has several motivations: - Although each sub-unit of the department has a clear understanding of a particular portion of the public debt domain, a shared and formalized description of the relevant concepts and relations in the whole domain is missing. This lack means that, when different offices manage the same information according to different purposes, is not uncommon a misunderstanding about the nature and theoretical definition of data.
- Data within the various sources are managed by different systems, and their structure has been heavily modified and updated during the years, often to serve specific application needs. The result is that the original modeling of the data is hidden in the data structures currently used by applications and processes. Consequently, only few experts of the systems have the skill to access data, while domain users access the information system only by means of pre-defined queries. Hence, when a new information need arises, managers of the Department of Treasury have to resort to complex processes, typically requiring several weeks and a considerable investment to be accomplished.
- Integrity constraints on the data are often not enforced in the running systems, mainly because of performance reasons. Business rules are therefore managed within software processes. The result is that the data quality is hampered, or difficult to assess. 3
The ontology we realized formalizes the overall scenario we sketched in the previous section. It is specified over an alphabet containing around 350 concept names, 150 role names, 200 attribute names, and contains around 3000 DL-Lite axioms.
Our experience proved that (i) on the one hand, the basic logics of the DL-Lite
family [
As shown by the theoretical studies in [
Continuing the above example, consider that institutions may act as both lenders
and borrowers of loans (cf. role is lender in Figure 1). For example, a region can be
beneficiary of a loan guaranteed by a credit institution, but also lender of loans whose
borrowers are the municipalities located in the region. Of course, we do not want an
institution to be at the same time lender and borrower of the same loan. This can be
specified through a denial assertion, which imposes that the boolean query
has borrower(x; y); is borrower(y; z); is lender(z; x)
has to be evaluated to false on every ontology instance. Again, this feature is not allowed
by ontology languages such as OWL, but important in real-world use cases. The needs
encountered in our experience pushed therefore the theoretical study of denial
assertions in DL-Lite languages. In [
In MASTRO, the mapping is a set of assertions, each one associating an element of
the ontology with an SQL query over the sources, which actually corresponds to GAV
mapping in the data integration terminology [
Within our project, we mapped a portion of the ontology through the definition of 800 mapping assertions, which involve 80 relational tables stored in various separate databases, all managed by Microsoft SQL Server. These databases contain around 250 tables, storing approximately 5 million tuples, for an overall size of 2.7 gigabytes.
In order to define mappings, we started by deeply analyzing the structure of the data sources, to understand the meaning of relational tables they store and the dependencies among them. This has been a very time consuming phase of our project, due to the lack of accurate documentation, at least on some of the sources we considered. On the other hand, such an analysis has to be carried out only once during an OBDA project, and faced again only in case new sources need to be added to the OBDA system.
From our analysis of the sources clearly emerged that data about distinct ontology concepts were often mixed together within the sources. This regards, for instance, financial instruments, characterized by properties like the type, the maturity, or the interest rate they offer, and the amount of the actual debt they produce. As a specific example consider the mapping assertion below.
SELECT L.ID FROM D LOAN L WHERE NOT EXISTS (SELECT *
FROM D SHARED S WHERE S.LOAN ID=L.ID)
Unshared Loan(ln(ID))
In the assertion, we select at the sources identifications of unshared loans, i.e., loans
with only one borrower, and map them to the corresponding concept in the
ontology, i.e., Unshared Loan, which, together with Shared Loan, partitions the concept
Loan. Since the table D LOAN contains both shared and unshared loans, we obtain IDs
of unshared loans as the difference between all loans and shared ones, all occurring in
the table D SHARED. In the right-hand side of the mapping, ln is, intuitively, a function
symbol used to construct objects denoting unshared loans starting from IDs (cf. [
The ultimate goal of our project is to provide the user with various services for accessing the data through the lens of the ontology. In this section, we briefly describe how MASTRO has been used and improved for providing an effective query answering service in our scenario. To this aim, note that query answering in MASTRO is divided into two steps: (i) ontology rewriting, where the original query is rewritten with respect to the ontology into a new query; (ii) mapping rewriting, where the query thus obtained is reformulated over the source database schema using the mapping assertions.
While in recent years we have seen many approaches to the ontology rewriting step
and its optimizations, (see, e.g., [
The first experiments of computing query answering on our scenario showed that the above mentioned combinatorial explosion could be often avoided. Indeed, we noticed that in many cases, several subqueries of the final union of SQL subqueries were actually redundant, i.e., contained into other subqueries. So, we reached the conclusion that in principle it is possible to optimize the mapping rewriting phase by limiting the combinatorial explosion, in particular if we could exploit the knowledge on containment between the SQL subqueries used in the mapping. Note that checking containment of arbitrary SQL queries is an undecidable problem. However, even sound and incomplete containment checking algorithms (i.e., algorithms that do not guarantee to discover all containments) make sense in this context. Indeed, discovering even a small number of containments between SQL subqueries can drastically lower the size of the final SQL query, thus making query answering over the OBDA system feasible.
Based on the above considerations, our experience in real world OBDA scenarios led us to realize the following optimizations:
1. We added view inclusions to the OBDA specification, i.e., inclusion assertions between the SQL queries used in mapping assertions, or, more precisely, between the corresponding view predicates. Based on such inclusions, we were able to eliminate subqueries contained into other subqueries of the rewritten query.
2. Given that the above optimization is applied only after generating the unoptimized mapping rewriting of the query, we have designed a further optimization of the whole query rewriting process. Intuitively, this has been realized through a kind of semantic caching approach. When the algorithm discovers that the query to be answered contains subqueries that have been already processed in previous executions, and for which the mapping rewriting has been stored, it directly uses such mapping rewritings to reformulate the query at hand, thus saving time.
With the above optimizations, we have been able to provide the users with an
effective query answering service,which allows the users to obtain various reports on the
data stored in the sources by directly querying the ontology. For details see [
Dealing with a complex real world scenario like the Italian Department of Treasury helped to identify several critical issues that are general enough to be taken into account in the OBDA approach regardless of the organization, and that can be summarized in: (i) communication with the experts of the domain of interest; (ii) development and refinement of the ontology; (iii) documentation of the ontology.
As for the first aspect, we notice that developing an ontology requires to exchange knowledge with people that are generally not expert of logical formalisms, but that have a deep understanding of the domain of interest. Exchanging this kind of knowledge requires a common tool that is understood on both parts. A useful solution to this problem was the adoption of a novel graphical language for ontology representation (cf. Fig. 1). According to this new formalism, the graphical representation of the ontology has a graph-like structure, similar to that of an ER diagram, that is both easy to understand and also easy to translate into other logical formalisms suitable for automatic reasoning, like OWL and DL-Lite.
This approach was an improvement also for ontology development and refinement, since it effectively supports the definition, the update, and the analysis of the ontology. In particular, the analysis of the ontology is crucial both for validating and for identifying mistakes. To this aim, alongside with the tool for the inspection of the graphical representation of the ontology, we developed a novel Fig. 2. MASTRO STUDIO GUI screenshot tool for intensional reasoning, to verify formal properties of the ontology, such as concept satisfiability.
As for the ontology documentation issue, we resorted to a structured wiki-like documentation (one wiki-page for each ontology concept, attribute and role), where various contributions are gathered together with the help of collaborative tools. This enables the cooperation of all the parts participating to the ontological analysis.
In order to tackle the above mentioned issues, during this project the collection of OBDA services offered by MASTRO evolved into a more complex suite of tools, called MASTRO STUDIO. MASTRO STUDIO is a web-application based on Drupal3, an open source CMS (Content Management System), and thus comprises: (i) Drupal core modules; (ii) contributed Drupal modules, for the management and the moderation of collaborative editing of the ontology wiki-like documentation; and (iii) custom modules (i.e., extensions of the CMS) for the loading and the analysis of the OBDA specification, as well as the invocation of reasoning services over it, and the analysis of their results.
Beside the web-gui, MASTRO STUDIO offers several utilities, including a tool for the translation of graphical representations of ontologies into the OWL functionalsyntax representation required by components of the reasoning layer, and a tool for the automatic generation and update of the wiki-like documentation, starting from the OBDA specification. An example of wiki-like documentation page (in italian) of the concept Loan is shown in Figure 2. Finally, MASTRO STUDIO provides a reasoning
layer, which comprises modules that invoke and exploit MASTRO reasoning services, through a web-service interface. 7
We have illustrated how the application of the OBDA principles in a real-world scenario have led us to devise new techniques for making the whole approach effective. It is our opinion that this is one of the most important outcome of the project: on the one hand, the Department of Treasury benefits from the effective use of a new technology in various critical tasks, and on the other hand, the experience has guided the research activities towards the goal of solving real-world problems arising in practice. Acknowledgments. The research on OBDA, and in particular on mapping management, at the basis of the experience described in this paper has been partially funded by the EU under FP7 project Optique – Scalable End-user Access to Big Data (grant n. FP7-318338).