The process of translating end-users' information needs into executable and optimised queries over the data is the main problem that end-users face in Big Data scenarios. In this paper we present the recently started EU project Optique, which advocates for a next generation of the well known Ontology-Based Data Access (OBDA) approach to address this problem. We discuss challenges, present ongoing work, and our current preliminary solutions with regards to the query formulation and query-driven ontology extension.
Massive amounts of data have been accumulated over decades; moreover, data keeps
increasing fast; and it is spread over a vast variety of formats and sources, being
modeled using different conceptualisations of the domain, often using schemata that are
optimized for efficient processing rather than for intuitive access. These three aspects
go hand in hand with the volume, velocity, and variety dimensions of Big Data [
Accessing the relevant data in this context is becoming increasingly difficult for
end-users. For example, in large enterprises, such as Statoil,5 end-users work with
applications that allow accessing data through a limited set of predefined queries. In
situations where an end-user needs data that these predefined queries do not provide, the
help of IT-experts (e.g., database managers) is required. The IT-experts need to
translate the end-users’ information needs into suitable queries and this process may require
several iterations. In particular in the oil and gas industry, IT-experts spend 30–70%
of their time gathering and assessing the quality of data [
end-user Application r e s u lt s q u e r y
IT-expert Ontology
Mappings Query Answering
... heterogeneous data sources r e s u lt s q u e r y OBDA systems have the potential to address the data access problem by presenting a general ontology-based and end-user oriented query interface over heterogeneous data sources. The core elements in a classical OBDA system (Figure 1, left) are an ontology, which describes the application domain in terms of user-oriented vocabulary of classes (usually referred as concepts) and relationships between them (usually referred as roles), and a set of mappings, which relates the terms in the ontology and the schema of the underlying data sources. End-users formulate queries using the terms defined by the ontology, which should correspond to their view of the domain, and thus, they are not required to understand the data source schemata. For example, in the Statoil use case the ontology would provide concepts such as WellBores, their purpose, etc., while the mappings would associate SQL queries to each term of the ontology vocabulary, i.e., similarly to SQL view definitions. For example, the ontology concept Water Injection Wellbore would be mapped to the SQL query:
SELECT * FROM DevelopmentWellBore
WHERE purpose=Injection and content=Water To be precise, one should extend this mapping with a reification function that transforms tuples returned by the query above into constants, i.e, exact identifiers of water injection wellbores. Another alternative is to adjust the query by changing the select clause to the following: SELECT ID.
State-of-the-art OBDA systems that are based on classical OBDA architecture (Figure 1, left), however, have shown among others the following four limitations. 1. The usability of OBDA systems regarding the user interface is still an open issue.
Even if the vocabulary provided by the ontology is familiar to end-users, they may find difficult to formulate complex queries when several concepts and roles are involved. 2. OBDA systems critically depend on a suitable ontology and the corresponding set of mappings, which are in practice expensive to obtain. Even if we assume that the ontology and the mappings are given, they are not static artifacts and should evolve according to the new end-users’ information requirements. Both bootstrapping of ontologies and mappings for an initial installation of OBDA systems and subsequent maintenance are challenging topics which are still in a premature stage. 3. Treatment of query answering is usually limited to query rewriting and there is little support of distributed query optimisation and processing in OBDA systems. 4. Streaming, e.g., sensor, data and corresponding analytical tools are generally ignored by OBDA systems, which seriously limits their applicability in enterprises such as Statoil.
The Optique project, which started in November 2012 and has a four years time span, aims at addressing these four limitations by developing a next generation OBDA system that targets the demands of today’s Big Data challenges. The core components of the Optique’s OBDA solution are presented in Figure 1, right: (i) query formulation, (ii) ontology and mapping management, (iii) query transformation, and (iv) distributed query optimisation and processing. Besides the core components, Optique’s OBDA system integrates both data streams and databases, and supports data analytics.
In this paper we focus on the first and partially the second limitation above. More specifically, we focus on the query formulation component of Optique’s solution. We will also discuss the query-driven ontology extension sub-component of the query formulation component which in fact partially addresses issues of the second limitation (ontology maintenance). In the following sections we discuss challenges, introduce our ongoing work, and illustrate our preliminary solutions. Moreover, we present an envisaged architecture of our query formulation component. 2
The ontology in an OBDA system, as already mentioned, is intended to provide a useroriented conceptual model of the domain. This allows users to formulate queries using familiar terms and shields from understanding the structure of the underlying data sources. However, in order to provide the necessary power and flexibility, the required query language will inevitably be rather complex and it would be unrealistic to expect all end-users to formulate queries directly in such a query language.
In Optique we advocate for a query by navigation (QbN) approach combined with
faceted search to address the usability problem. We refer interested readers to [
Representation paradigms. Query by navigation approaches usually combine navigational search and faceted search techniques over an underlying ontology graph (or any other kind of structured knowledge). Thus, in this scenario, the ontology not only provides the domain vocabulary but also guides the end-user to formulate complex queries. Existing approaches, however, are mostly dominated with one type of representation paradigm (e.g., forms, diagrams etc.), hence limited to the confines of a particular model. We believe that multiple representation paradigms should be used in collaboration where each paradigm is responsible for the tasks for which it is best suited.
We have also observed that current solutions do not adequately employ a very important paradigm, namely the graph representation metaphor of OWL ontologies. The formal underpinning of OWL (and its revision OWL 2) is provided by Description Logics (DLs) where the fundamental modelling concept is an axiom (i.e., a logical statement relating roles and/or concepts). This is a key difference from traditional graph-based knowledge representation paradigms (e.g., semantic networks). OWL ontologies may include complex axioms and concept constructors such as universal restrictions that do not have a direct representation in a graph structure.
Correlations between navigation and query construction. Given a navigation paradigm, one has to understand how the actual navigation influences the construction of a query. More precisely, how the navigation corresponds to operators in a given query language. For example, how to form a query with negation, disjunction, or aggregation via a graph navigation? For navigation over graphs there is a natural correspondence to conjunctive queries: moving along a graph can be seen as an extension of the corresponding query with more conjuncts corresponding to the (labels of) edges and nodes met on the way. This correspondence gives good opportunities for designing QbN algorithms. For other types of queries, however, establishing the correlation is a challenging problem that will require further research.
The representation paradigms and the correlation between navigation and query construction give two dimensions of choices for query by navigation approaches. Orthogonally, the ontology and query languages give another two dimensions to choose from. In the following we elaborate on the OWL 2 QL ontology language and queries that essentially correspond to a conjunctive fragment of SPARQL. For this choice we will discuss possible issues and challenges.
OWL 2 QL and conjunctive queries. Even in the simplified scenario where the ontology
language is reduced to the OWL 2 QL profile [
its subconcepts, it may also make sense to suggest for a given concept the (potential) restrictions of its subconcepts. For example, consider an ontology including GasWell and OilWell as (direct or indirect) subconcepts of Well and the axioms OilWell v 9hasProduction:Oil and GasWell v 9hasProduction:Gas, then the concept Well could potentially be related to the concepts Oil and Gas. 3. Cycles in the ontology graph. Ontology axioms such as inclusion between concepts or inverse roles can lead to cycles in the ontology graph. Thus, the navigation should take into account these cycles and, in some cases, avoid repetitive suggestions. For example, if one constructs a query by navigating through the following ontology and starts the navigation from the concept Wellbore, then one gets back to Wellbore in two steps, via the concepts Core and StratigraphicLayer.
Should the system suggest or allow the user to go to Wellbore via the layerOf relation when StratigraphicLayer is reached? The answer depends on the query that the user has in mind. For example, if the user has the following query in mind,8 then Wellbore should be recommended.
layerOf(“Neolithic”,u), Wellbore(u).
Since the way to cope with cycles depends on the user’s intention, we do not envision generic solutions to this problem. At the same time, it is useful to notify users when they are confronted by cycles and to provide them with some form of control, e.g., by restricting the depth of constructed queries or by allowing recursion. 4. Negative information. Negative information such as disjointness between concepts should be exploited accordingly. For example, if the end-user selects the wells with oil as a production type and the concepts OilWell and GasWell are disjoint in the ontology, then the navigation system could safely skip suggestions related to GasWell. 5. Role inclusion axioms will also lead to extra complexity when navigating over the ontology graph. For example, consider the axioms BottomHoleAssembly v 9hasBit:DrillBit and hasBit v hasPart, then the concept DrillBit should also be suggested as a part of BottomHoleAssembly.
In Optique we intend to design and implement novel techniques that take into
account the issues above. We aim at providing an intuitive end-user interface while
preserving the semantics of the underlying ontology in order to formulate both complex
and valid queries. In particular, we intend to look at existing work, where query
formulation is driven from a Description Logic model of the domain, e.g., [
2.1
Query-driven ontology extensions
The ontology may not include all the vocabulary expected or needed by the end-user.
Moreover, the vocabulary is to a certain extent specific to individuals, projects,
departments, etc. and subject to change. Thus, keeping the ontology up-to-date with respect
to the end-user needs arises as an indirect (but crucial) challenge in query
formulation. In Optique we differentiate the following changing scenarios driven by end-user
information requirements:
1. Adding new synonyms. Concept synonyms (e.g. annotation labels) do not represent
new logical extension of the ontology, and hence end-users will be able to add
them to the ontology with no (logical) harm. For example, the concept WellBore
can be extended with the labels “drill hole” or “borehole”. In order to avoid an
overloading of the ontology with synonyms, we advocate a separation between the
ontology (e.g. logical axioms) and the terminological information (e.g. synonyms,
descriptions, related terms, etc.) as proposed in [
1. Editing components. Different users may cooperate on the same query or set of
queries, thus, the Optique solution aims at providing (at least) three kind of
interfaces to formulate the query (i.e. components): (i) direct editing, (ii) context
sensitive editing, and (iii) query by navigation exploiting faceted search and other
navigation paradigms. Technically versed users may prefer the direct editing of the
query using a formal language (e.g. SPARQL, stream query language), while other
end-user should be provided with a less technical interface such as query by
navigation. Additionally, direct editing should also allow the possibility of exploiting
the ontology, and provide context sensitive completion. All three interfaces should
provide views on the partially constructed query, and users should be able to switch
between views at will.
2. Query-driven ontology extension component will manage the ontology extensions
driven by the query requirements and will send the new ontology versions to the
Ontology Revision Control component for further analysis and validation of the
performed changes.
3. The Ontology Processing component. The ontology will be a key element for the
query formulation component and thus, the ontology processing component (e.g.
OWL API, OWL reasoners) will also play an important role. Furthermore,
logicbased ontology modularization techniques [
All components will be integrated into the Information Workbench [
Widget-based solution
A mashup based approach (cf. [
Widgets are managed by a widget environment which provides basic communication and persistence services to widgets. The orchestration of widgets relies on the requirement that each widget discloses its functionality to the environment through a client side interface and notifies any other widget in the environment (e.g., broadcast, subscription etc.) and/or the widget environment upon each user action. Then, either each widget decides on what action to execute in response, by considering the syntactic or semantic signature of the received event; or, the environment decides which widgets to invoke with which functionality. The core benefits of such an approach are that, i it becomes easier to deal with the complexity, since the management of functionality and data can be delegated to different widgets; ii each widget can employ a different visualization paradigm that best suits the functionality that it is expected to provide; iii widgets can be used alone or together, in different combinations, for different contexts and experiences; and, iv the functionality of the overall interface can be extended by introducing new widgets (e.g., such as for result visualization).
A possible architecture for a query formulation interface based on widget-based mashups is depicted in Figure 3. The architecture assumes that each widget has client side and server side components (for complex processing), and that widgets can communicate with each other and with the environment through a communication channel. Communication usually happens through the client side, but a server side communication mechanism can also be realized in order to support remote experiences (e.g., while widgets running on remote devices). The architecture assumes that there exists an environment controller at the client side and a component control logic at the server side. The former is responsible for operational tasks such as collecting the event notifications from widgets and submitting control commands to them. The latter is responsible for the orchestration logic, that is it decides how widgets should react to specific events.
JOIN
Menu-‐based and Icon-‐based Widget (QbN)
SELECT and PROJECT
Form-‐based and Menu-‐based Widget
(Faceted Search) Widget 2 Widget 4
JOIN
Diagram-‐based Widget (QbN) JOIN and VIEW
Form-‐based (table result) Widget
(QbN)
Catarci et al. [
We have observed that a single representation and interaction paradigm is not
sufficient for developing a successful query formulation interface. Therefore, we strive to
combine the best parts of different paradigms (cf. [
The first widget is responsible for join actions, and determines the focus of interface. First, available domain concepts are shown to the user; as soon as a user selects a domain concept, the selected concept becomes the focus, and relationships pertaining to this concept are listed. The second widget is responsible for providing an overview by allowing the user to switch between a graph visualization of the query and the ontology. The third widget presents the properties of the focus concept in the form of fields and menu-items to enable the user to select properties of interest and to specify constraints on them. The fourth widget represents query results in a common table view and enables user to navigate at instance level by accessing other facts that are linked to the result items in the table view.
The proposed approach provides a good balance between view and overview and
supports domain exploration and query construction efforts. It also provides an ample
amount of room for supportive features, since it is typically not possible to address every
requirement with visual representations [
We have presented the main challenges to be faced in the design and development of the query formulation and query-driven ontology extension solutions. Although the EU project Optique is still in an early stage, we aim at turning our preliminary ideas into novel solutions in the very near future, and to evaluating their effectiveness in our industry use cases. This will provide us with invaluable feedback to inform ongoing research and development of enhanced query formulation components.
Acknowledgements. 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. Cuenca Grau, Horrocks, Jime´nez-Ruiz, Kharlamov, and Zheleznyakov were also partially supported by the EPSRC projects ExODA and Score!