The Optique project aims at providing an end-to-end solution for scalable Ontology-Based Data Access to Big Data integration, where end-users will formulate queries based on a familiar conceptualization of the underlying domain, that is, over an ontology. From user queries the Optique platform will automatically generate appropriate queries over the underlying integrated data, optimize and execute them. The key components in the Optique platform are the ontology and mappings that provide the relationships between the ontology and the underlying data. In this paper we discuss the problem of bootstrapping and maintenance of ontologies and mappings. The important challenge in both tasks is debugging errors in ontologies and mappings. We will present examples of different kinds of error, and give our preliminary view on their debugging.
A typical problem that end-users face when dealing with Big Data is the data access
problem, which arises due to the three dimensions (the so called “3V”) of Big Data:
volume, since massive amounts of data have been accumulated over the decades,
velocity, since the amounts may be rapidly increasing, and variety, since the data are spread
over a huge variety of formats and sources. In the context of Big Data, accessing the
relevant information is an increasingly difficult problem. The Optique project7 [
The project is focused around two demanding use cases that provide it with motivation, guidance, and realistic evaluation settings. The first use case is provided by Siemens,8 and encompasses several terabytes of temporal data coming from sensors, with a growth rate of about 30 gigabytes per day. Users need to query this data in combination with many gigabytes of other relational data that describe events. The second predefined
quieries end-user information need specialised
quieries
use case is provided by Statoil9, and concerns more than one petabyte of geological
data. The data is stored in multiple databases which have different schemata, and the
user has to manually combine information from many databases in order to get the
results for a single query. In general, in the oil and gas industry, IT-experts spend 30–70%
of their time gathering and assessing the quality of data [
The main bottleneck in the use cases discussed above is data access being limited
to a restricted set of predefined queries (cf. Figure 1, top). Thus, if an end-user needs
data that current applications cannot provide, the help of an IT-expert is required to
translate the information need of the end-user to specialized queries and optimize them
for efficient execution (cf. Figure 1, bottom). This process can take several days, and
given the fact that in data-intensive industries engineers spend up to 80% of their time
on data access problems [
The approach known as “Ontology-Based Data Access” (OBDA) [
In complex domains, a complete specification of the ontology and the mappings
will typically be expensive to obtain, suggesting to start from partial specifications that
are incrementally refined and expanded according to users’ needs. Moreover, in some
9 http://www.statoil.com
10 Optique’s solutions are going to be integrated via the Information Workbench platform [
end-user Application r e s u lt s q u e r y
Mappings r e s u lt s
... heterogeneous data sources end-user
(Analytics)
... heterogeneous data sources q u e r y ...
streaming data applications, changes in the ontology and/or in the schemata of the data sources (and thus in the mappings) are likely to happen. Thus, some means for bootstrapping and maintenance of ontology and mappings is required. The classical OBDA approaches fail to provide support for these tasks.
In the Optique project we aim at developing a next generation OBDA system (cf. Figure 2, right); more precisely, the project aims at a cost-effective approach that includes the development of tools and methodologies for semi-automatic bootstrapping of the system with a suitable initial ontology and mappings, and for updating them “on the fly” as needed by a given application. This means that, in our context, ontologies are dynamic entities that evolve (i) to incorporate new vocabulary required in users’ queries, (ii) to accommodate new data sources, and (iii) to repair defects in ontologies and mappings. In all the cases, some way is needed to ensure that changes in the ontology and mappings are made in a coherent way. Due to this requirement, ontology debugging technologies will be a cornerstone of the system.
Besides ontology and mapping management, the Optique OBDA system will
address a number of additional challenges, including: (i) user-friendly query formulation
interface(s), (ii) processing and analytics over streaming data, (iii) automated query
translation, and (iv) distributed query optimisation and execution in the Cloud. We will
not, however, discuss these issues in this paper and refer the reader to [
The remainder of the paper is organized as follows. First, we discuss different ontology defects that may arise and will need to be debugged (Section 2). Then we discuss how such defects can occur during the operation of the Optique OBDA system (Section 3), and how they will be dealt with.
An OBDA setting includes three central components: data sources, an ontology, and mappings (from data sources to the ontology).
Data sources. A data source consists of a data schema and a number of corresponding data instances. A typical example for a data source is a relational or semi-structured database.
Example 1. Consider the two data sources in Figure 3 (left): Source 1 (or S1 for short) contains a unary table about production wells with the schema PWell and says that the well ‘w123’ is a production well. Source 2 (or S2 for short) contains a unary table about exploration wells with the schema EWell and says that ‘w123’ is an exploration well.
Ontology. In the context of OBDA, it is usual to consider the ontology to be a
Description Logic (DL) ontology [
Example 2. Consider the ontology in Figure 3, left, (in the box). It describes (a part of) the oil production domain and consists of three concepts: (i) the concept Well represents the class of wellbores,11 (ii) the concept PWell represents the class of production wells,12 and (iii) the concept EWell represents the class of exploration wells.13 This ontology says that production wells cannot be exploration wells (denoted as EWell v :PWell ), wells are exploration wells (Well v EWell ), and wells are production wells (Well v PWell ).
Mappings. Mappings associate data from the data sources with concepts in the ontology.14 A mapping m has the form m : q(x)
N (x);
where q is a query over the data sources, and N is an element of the ontological
vocabulary, i.e., a concept or property name. Intuitively, q returns constants (resp., pairs of
constants) from the data sources and propagates them into concept (resp., property) N
(that is, instantiates N with them).
11 A wellbore is any hole drilled for the purpose of exploration or extraction of natural resources,
e.g., oil.
12 Production wells are drilled primarily for producing oil or gas.
13 Exploration wells are drilled purely for exploratory (information gathering) purposes in a new
area.
14 The mappings we are considering here are usually referred to as global-as-view mappings [
m2 EWell ‘w123’ Source 2
EWell v ¬PWell EWell v Well PWell v Well
PWell t EWell v Well PWell ‘w123’ Source 1
EWell Source 2 hasCapacity ‘w456’ 1000
Source 3
Example 3. Consider Figure 3, left, again. The example includes two mappings, m1 and m2, which are depicted as arrows and defined as: m1 : PWell(x)
PWell (x); m2 : EWell(x)
EWell (x): Note that m1 connects S1 with the concept PWell , while m2 connects S2 with EWell : m1 says that tuples from the table PWell are instances of the concept PWell , and m2 analogously for EWell . I.e., m1 instantiates PWell and m2 instantiates EWell .
Summing up Examples 1–3, we have the following OBDA setting depicted in Figure 3, left:
(fS1; S2g; fEWell v :PWell ; Well v EWell ; Well v PWell g; fm1; m2g): Another OBDA setting is illustrated in Figure 3, right, and we will comment on it in the following section.
In what follows, we present a number of defects that can occur in an OBDA
setting and that may require debugging. We observe that several such defects have been
individually pointed out and studied in literature (see, for instance, [
We distinguish two types of defects, namely logical and modeling.
The three types of logical defects that are usually discussed in the literature (see,
for example, [
Example 4. The OBDA setting in Figure 3, left, is inconsistent. Indeed, the well ‘w123’ is an instance of both concepts PWell and EWell , and as the ontology asserts that PWell and EWell are disjoint, this makes the OBDA setting inconsistent.
The inconsistency in Example 4 could have been caused by a mistake in one of the data sources: either Source 1 or Source 2 provides wrong information about the well ‘w123’. Perhaps, this well was an exploration one at the beginning, but then became a production one, but the information in Source 2 has not been brought up to date. A possible solution would be to update the offending data source. In Figure 3, right, there is an updated Source 2.
Unsatisfiability and Incoherency of Ontologies. This two types of defects are tightly related. A concept in an ontology is unsatisfiable if it cannot be instantiated without causing inconsistency, and an ontology is incoherent if an unsatisfiable concept occurs in it.
Example 5. Continuing with the OBDA setting in Figure 3, left, consider the concept Well . Observe that if we instantiate the concept with some object, say, ‘w234’, then it will turn out that ‘w234’ is both exploration and production well, which is inconsistent. Hence, the concept Well is unsatisfiable and the ontology is incoherent.
Ontology incoherence is invariably indicative of an ontology design error. In Example 5, the two axioms stating that wells are exploration wells and wells are productive wells are in conflict with both our intuition and with the axiom stating that PWell and EWell are disjoint. Repairing this error will require one or more of these axioms to be modified or deleted. A possible repair plan is to replace the two counterintuitive axioms with axioms that make intuitive sense: EWell v Well (exploration wells are wells), and PWell v Well (productive wells are wells). Figure 3, right, contains a repaired version of the ontology.
Empty Mappings in OBDA settings. A mapping of an OBDA setting is empty if it does not propagate any individuals (resp., pairs of individuals) into any concept (resp., property) in the ontology.
Example 6. Consider the OBDA setting in Figure 3, right. Besides the mappings m1 and m2 from Example 3, it includes the following mapping: m3 : PWell(x); hasCapacity(x; y)
PWell (x): that describes how to populate the concept PWell by joining tuples from tables PWell and hasCapacity on the well’s ID and projecting out the capacity value. Observe that the mapping m3 is empty in this setting: when applying the mapping to the data sources, no object will be propagated into the concept PWell, since there is no x such that it appears in both table PWell and table hasCapacity.
Now consider the following mappings: m4 : q1(x) m5 : q1(x) Since the ontology states that PWell v :EWell , it follows that the query q1 has to be empty, i.e., its evaluation over the data sources must return the empty tuple.
The defect with the mapping m3 in Example 6 could be caused by (i) a mappingdesign error, that is, tables PWell and hasCapacity are incorrectly related in m3, or (ii) incompleteness of data sources. In the former case, m3 should be deleted or repaired, while in the later case the problem should be solved at the data source level. Moreover, mappings m4 and m5 show that combining the knowledge about the mapping and the ontology is a key aspect towards the formal analysis of the OBDA specification.
Modeling defects are less intuitive than logical ones. A typical modeling defect is
redundancy [
Redundancy. We distinguish three types of redundancy: redundant axioms, concepts, and mappings. Intuitively, an axiom, concept, or mapping is redundant in an OBDA setting if the deletion of it from the setting results in a logically equivalent setting. Example 7. Recall the OBDA system in Figure 3, right. To observe the phenomenon of redundant axioms, note that the axiom = PWell t EWell v Well (both production and exploration wells are wells) would be redundant in this setting. Indeed, the pair of axioms PWell v Well and EWell v Well already state the same thing, i.e., they are logically equivalent to , and so adding would be vacuous.
To observe the phenomenon of redundant concepts, assume that the ontology implies that two concepts, say PWell and ExWell (standing for Exploited Well) are equivalent, i.e., PWell v ExWell and ExWell v PWell . Then, these two concepts are synonymous, and we may prefer to remove one of them from the ontology.15 Even if the ontology does not imply the logical equivalence of PWell and ExWell , but the mappings for these concepts are the same, then the two concepts may be de facto synonymous.
To observe the phenomenon of redundant mappings, consider the mapping m3 (Example 6) and the following mapping m5: m6 : PWell(x)
PWell (x): Note that, in the presence of m6, m3 becomes redundant. Indeed, m3 instantiates the concept PWell with some objects from the table PWell, while m6 instantiates PWell with all the objects found in PWell. Thus, m3 can be harmlessly dropped. 15 This is not always the case as synonyms may capture differences in vocabulary usage amongst different user groups.
To conclude this section, we would like to note that it is not trivial to understand whether a modeling defect is actually a defect and hence requires debugging. For example, as noted above, redundancy can be intentionally introduced in an ontology by an ontology engineer. Thus, the necessity of debugging such errors depends on the application, and should be decided on a case-by-case basis. 3
Essential functionalities, required to support the life cycle of an OBDA system, are: – Detection of defects, – OBDA debugging, – Ontology and mapping bootstrapping, – OBDA evolution, – OBDA transformation.
We will now discuss these functionalities in more detail.
An OBDA system should be able to analyze itself w.r.t. both logical and
modeling defects as presented above. Thus, the system should be equipped with an OBDA
analyser: a routine that takes an OBDA setting as input, and returns a set of defects as
output. Based on the result of such analyses, the system should be able to debug itself.
Since, as we discussed in the previous section, there is no universal way to debug an
OBDA system, it is natural for the debugging to be semi-automatic. Thus, the system
should be equipped with an OBDA debugger: a routine that takes an OBDA setting
and its defects as input, and returns a debugged version of the setting, that is free from
the input defects. For examples of tools that perform these tasks, we refer the reader
to [
Clearly, OBDA systems crucially depend on the existence of suitable ontologies and mappings. Developing them from scratch is likely to be expensive and a practical OBDA system should support a (semi-) automatic bootstrapping of an initial ontology and set of mappings. Thus, an OBDA system should be equipped with an OBDA bootstrapper: a routine that takes a set of database schemata and possibly instances over these schemata as input, and returns an ontology and mappings connecting it to the input schemata.
As was discussed above, OBDA systems are not static objects and are subjects of frequent changes, that is, evolution. Natural types of evolution are: – Adding/deleting a new concept together with a mapping. It might be the case that the ontology lacks some concepts, or some concept should be dropped from the ontology, e.g., when it is synonymous with another concept. For example, consider the ontology in Figure 3, right. Assume that a new concept, e.g., OilPr (Oil Producer), is needed. Then one might add this concept to the ontology and create a mapping that instantiates the concept. – Adding/deleting an ontological axiom. An ontology may be missing relations between concepts. For example, one may want to assert that the concept OilPr is a subconcept of Well . This can be done by adding the axiom OilPr v Well to the ontology. Integrated via Information Workbench
Presentation Layer
Visualisation
engine Query Formulation
Processing Components Ontology Processing
Ontology reasoners Ontology modularization
O W L A P
I Application
Layer Components
Ontology and Mapping
Management Interface
Information Workbench frontend API (E.g., widget development, Java, REST)
Ontology & Mapping Manager's
Processing Components O&M revision, control, editing
O&M evolution and transformation engine
O&M analyser, reasoner O&M matching, alignment system
O&M bootstrapper Sesame API
Shared triple store - ontology - mappings - configuration - queries - answers - history - lexical
information - etc.
Application receiving answers Component Front end: mainly Web-based
API
Colouring Convention
Optique solution
External solution
A task related to both bootstrapping and evolution is ontology transformation. For example, one may want to reuse an existing third party ontology or mappings instead of (or combined with) bootstrapping them from the data sources. It is possible that the existing ontology or mappings are in a language that the system at hand does not support. Thus, one will have to transform them into the supported language. This may involve changes in the syntax and/or expressivity of the ontology.
Another reason for a transformation is optimization. One may want to improve the
overall performance of an OBDA system by restricting the expressiveness of the
ontology language, e.g., by moving from an OWL 2 ontology O to an OWL 2 QL ontology
O0. This would in general require “approximation” of O using the weaker OWL 2 QL
language [
To connect the five functionalities above, we observe that bootstrapping, evolution, and transformation functionalities naturally introduce errors in OBDA settings, while the detection functionality can detect the errors, and the debugging one can repair them.
In the following section, we present the Optique OBDA system, which will provide all of the life cycle supporting functionalities described above. 4
In Figure 4, we present the Ontology and Mapping Management component (the O&M
manager) of the Optique OBDA system. The O&M manager has a Web interface at
the presentation layer. Functionalities of the O&M manager are intended for IT-experts
rather than end-users. The manager includes five subcomponents:
– The Bootstrapper extracts an initial ontology and mappings from data sources, as
discussed above. In Section 4.1, we will present our initial ideas on how to
implement the bootstrapper.
– The Matching and alignment system performs ontology alignment.
– The Analyser and reasoner checks ontologies for defects.
– The Evolution and transformation engine performs debugging on defects found by
the analyser.
– The Revision, control and editing system supports versioning (which can be based
on, e.g., ContentCVS [
Also, the O&M manager interacts with other components of the Optique OBDA system. In particular, – It accesses the Shared triple store, where the ontology and mappings are physically stored. It can both read the ontology and mappings and update them when needed. – The analyser, alignment system, and evolution engine have access to reasoning capabilities, e.g., external ontology reasoners, ontology modularization engines, etc. – The Query Formulation Component can call the O&M manager whenever a user decides to add a new concept or axiom. We refer to this as query-driven ontology construction. – Finally, the O&M manager is connected to a Visualisation engine. 4.1
In the development of the Optique OBDA system, we plan to exploit existing techniques
from ontology evolution, e.g. [
We have presented a selection of possible logical and modeling errors in OBDA systems and the main challenges to be faced in supporting the life-cycle of OBDA systems. Current approaches and methods only partially address the issues related to the construction, maintenance, and transformation of an OBDA specification. Although the EU project Optique is still at an early stage, we aim to turn our preliminary ideas into novel solutions in the very near future, and to evaluate their effectiveness in our industry use-cases. This will provide us with invaluable feedback to inform ongoing research and development of enhanced ontology and mapping management components.
The research presented in this paper was financed by the Seventh Framework Program (FP7) of the European Commission under Grant Agreement 318338, the Optique project. Horrocks, Jime´nez-Ruiz, Kharlamov, and Zheleznyakov were also partially supported by the EPSRC projects ExODA and Score! 16 http://www.w3.org/TR/2011/WD-rdb-direct-mapping-20110324/ 17 http://www.w3.org/TR/r2rml/