In Ontology-Based Data Access (OBDA), queries are posed over a high-level conceptual view, and then translated into queries over a potentially very large (usually relational) data source. The ontology is connected to the data sources through a declarative specification given in terms of mappings. Although prototype OBDA systems providing the ability to answer SPARQL queries over the ontology are available, a significant challenge remains: performance. To properly evaluate OBDA systems, benchmarks tailored towards the requirements in this setting are needed. OWL benchmarks, which have been developed to test the performance of generic SPARQL query engines, however, fail to evaluate OBDA specific features. In this work, we propose a novel benchmark for OBDA systems based on the Norwegian Petroleum Directorate (NPD). Our benchmark comes with novel techniques to generate, from available data, datasets of increasing size, taking into account the requirements dictated by the OBDA setting. We validate our benchmark on significant OBDA systems, showing that it is more adequate than previous benchmarks not tailored for OBDA.
In Ontology-Based Data Access (OBDA), queries are posed over a high-level
conceptual view, and then translated into queries over a potentially very large (usually
relational) data source. The conceptual layer is given in the form of an ontology that
defines a shared vocabulary. The ontology is connected to the data sources through a
declarative specification given in terms of mappings that relate each (class and property)
symbol in the ontology to a (SQL) view over the data. The W3C standard R2RML [
In this work, we propose a novel benchmark for OBDA systems based on the Norwegian Petroleum Directorate (NPD), which is a real world use-case adopted in the EU project Optique1. In the benchmark, which is available online2, we adopt the NPD
Fact Pages as dataset, the NPD Ontology, which has been mapped to the NPD Fact Pages
stored in a relational database, and queries over such an ontology developed by domain
experts. One of the main challenges we address here has been to develop a data generator
for generating datasets of increasing size, starting from the available data. This problem
has been studied before in the context of databases [
In Section 2, we present the necessary requirements for an OBDA Benchmark. In Section 3, we discuss the requirements for an OBDA instance generator. In Section 4, we present the NPD benchmark and an associated relational database generator that gives rise to a virtual instance through the mapping; we call our generator Virtual Instance Generator (VIG). In Section 5, we perform a qualitative analysis of the virtual instances obtained using VIG. In Section 6, we carry out a validation of our benchmark, showing that it is more adequate than previous benchmarks not tailored for OBDA. We conclude in Section 7. 2
In this section we study the requirements that are necessary for a benchmark to
evaluate OBDA systems. In order to define these requirements, we first recall that the
three fundamental components of such systems are: (i) the conceptual layer constituted
by the ontology; (ii) the data layer provided by the data sources; and (iii) the mapping
layer containing the declarative specification connecting the ontological terms to the
data sources. It is this mapping layer that decouples the virtual instance being queried,
from the physical data stored in the data sources. Observe that triple stores cannot be
considered as full-fledged OBDA systems, since they do not make a distinction between
physical and virtual layer. However, given that both, OBDA systems and triple stores,
are considered as (usually SPARQL) query answering systems, we consider it important
that a benchmark for OBDA can also be used to evaluate triple stores. Also, since one
of the components of an OBDA system is an ontology, the requirements we identify
include those to evaluate general knowledge based systems [
Typically OBDA systems follow the workflow below for query answering:
1. Starting phase. The system loads the ontology, the mappings, and performs some
auxiliary tasks needed to process/answer queries in a later stage. Depending on the
system, this step step might be critical, since it might include some reasoning tasks,
for example inference materialization or the embedding of the inferences into the
mappings (T-mappings [
Quality Metrics (T ) — (T ) 4. Query execution phase. The data query is executed over the original data source, answers are produced according to the data source schema, and are translated into answers in terms of the ontology vocabulary and RDF data types, thus obtaining an answer for the original input query.
Note that a variation of the above workflow has actually been proposed in [
Ideally, an OBDA benchmark should provide meaningful measures for each of these phases. Unfortunately, such a fine-grained analysis is not always possible, for instance because the system comes into the form of a black-box with proprietary code with no APIs providing the necessary information, e.g., the access to the rewritten query; or because a system combines one or more phases, e.g., query rewriting and query translation. Based on the above phases, we identify the measures important for evaluating OBDA systems in Table 1. The meaning of the Performance Measures is clear from the name, but we will give a brief explanation of the meaning of the Quality Metrics: – Simplicity R Query. Simplicity of the rewritten query in terms of language dependent measures, like the number of rules in case the rewritten query is a datalog program. In addition, one can include system-dependent features, e.g., # of tree-witnesses in Ontop. – Simplicity U Query. This measures the simplicity of the query over the data source, including relevant SQL-specific metrics like the number of joins/left-join, the number of inner queries, etc. – Weight of R+U. It is the cost of the construction of the SQL query divided by the overall cost.
We label with (T) those measures that are also valid for triple stores, and with (T ) those that are valid only if the triple store is based on query rewriting (e.g., Stardog). Notice that the two Simplicity measures, even when retrievable, are not always suitable for comparing different OBDA systems. For example, it might not be possible to compare the simplicity of queries in the various phases, when such queries are expressed in different languages.
With these measures in mind, the different components of the benchmark should be designed so as to reveal strengths and weaknesses of a system in each phase. The conclusions drawn from the benchmark are more significant if the benchmark resembles a typical real-world scenario in terms of the complexity of the ontology and queries and size of the data set. Therefore, we consider the requirements in Table 2.
O1 The ontology should include rich hierarchies of classes and properties.
O2 The ontology should contain a rich set of axioms that infer new objects and could lead to inconsistency, in order to test the reasoner capabilities.
D1
be based on real world data.
M1 The mappings should be defined for elements of most hierarchies.
M2 The mappings should contain redundancies, and suboptimal SQL queries to test optimizations.
S1 The languages of the ontology, mapping, and query should be standard, i.e., based on R2RML, SPARQL, and OWL respectively.
The current benchmarks available for OBDA do not meet several of the requirements
above. Next we list some of the best known benchmarks and their shortcomings when it
comes to evaluate OBDA systems. We show general statistics in Table 3.
Adolena: Designed in order to extend the South African National Accessibility
Portal [
Requirements Missing: O1, Q2, D2, S1
LUBM: The Lehigh University Benchmark (LUBM) [
Requirements Missing: O1, Q2, M1, M2, D1 DBpedia: The DBpedia benchmark consists of a relatively large—yet, simple3— ontology, a set of user queries chosen among the most popular queries posed against the DBpedia4 SPARQL endpoint, and a synthetic RDF data generator able to generate data having similar properties to the real-world data. This benchmark is specifically tailored to triple stores, and as such it does not provide any OBDA specific components like R2RML mappings, or a data set in the form of a relational database.
Requirements Missing: O1, O2, Q2, M1, M2
BSBM: The Berlin SPARQL Benchmark [
Requirements Missing: O1, O2, Q2, M1, M2, D1,
FishMark: FishMark [
This benchmark is based in the FishBase real world dataset, and the queries are extracted from popular user SQL queries over FishBase; they are more complex than those from BSBM. However, the benchmark comes neither with mappings nor with a data generator. The data size is rather small ( 20M triples).
Requirements Missing: O1, D2, S1
A specific challenge comes from requirements D1 and D2, i.e., given an initial real-world dataset, together with a rich ontology and mappings, expand the dataset in such a way that it populates the virtual instance in a sensible way (i.e., coherently with the ontology constraints and relevant statistical properties of the initial dataset). We address this problem in the next section. 3
In this section, we present the requirements for an OBDA data generator, under the assumption that we have an initial database that can be used as a seed to understand the 3 In particular, it is not suitable for reasoning w.r.t. existentials.
distribution of the data that needs to be increased. To ease the presentation, we illustrate the main issues that arise in this context with an example.
Example 1. Suppose we have the following database tables, where the primary keys are in bold font and the foreign keys are emphasized. We assume that every employee sells the majority of the products, hence the table TSellsProduct contains roughly the cross product of the tables TEmployee and TProduct. Next we present only a fragment of the data.
TEmployee TAssignment TSellsProduct TProduct id name branch branch task id product product size
Consider the following mappings populating the ontology concepts Employee, Branch, and ProductSize, and the object properties SellsProduct and AssignedTo.
M1 :{id} rdf:type :Employee M2 :{branch} rdf:type :Branch M3 :{branch} rdf:type :Branch M4 :{id} :SellsProduct :{product} M5 :{size} rdf:type :ProductSize M6 :{id} :AssignedTo :{task}
SELECT id from TEmployee SELECT branch FROM TAssignments SELECT branch FROM TEmployee SELECT id, product FROM TSellsProduct SELECT size FROM TProduct SELECT id, task FROM TEmployee NATURAL JOIN
TAssignments
The virtual instance corresponding to the above database and mappings includes the following RDF triples:
Suppose now we want to increase the virtual RDF graph by a growth-factor of 2. Observe that this is not as simple as doubling the number of triples in every concept and property, or the number of tuples in every database relation. Let us first analyze the behavior of some of the ontology elements w.r.t. this aspect, and then how the mappings to the database come into play.
– ProductSize: This concept will contain two individuals, namely small and big, independently of the growth-factor. Therefore, the virtual instances of the concept should not be increased when the RDF graph is extended. – Employee and Branch: Since these classes do not depend on other properties, and since they are not intrinsically constant, we expect their size to grow linearly with the growth-factor. – AssignedTo: Since this property represents an n-to-n relationship, we expect its size to grow roughly quadratically with the growth-factor. – SellsProduct: The size of this property grows roughly with the product of the numbers of Employees and Products. Hence, when we double these numbers, the size of SellsProduct will roughly quadruplicate. In fact, the above considerations show that we do not have one uniform growth-factor for the ontology elements. Our choice is to characterize the growth in terms of the increase in size of those concepts in the ontology that are not intrinsically constant (e.g., ProductSize), and that do not “depend” on any other concept, considering the semantics of the domain of interest (e.g., Employee). We take this as measure for the growth-factor.
The problem of understanding how to generate from a given RDF graph new
additional triples coherently with the domain semantics is addressed in [
– The property SellsProduct grows linearly w.r.t. the size of the table TSellsProduct, hence also this table has to grow quadratically with the growthfactor. Since TSellsProduct has foreign keys from the tables TEmployee and TProduct, to preserve the inter-table correlation (according to which roughly every employee is connected to every product), the two tables TEmployee and TProduct have both to grow linearly. It is worth noting that, to produce one SellsProduct triple in the virtual instance, we have to insert three tuples in the database. – Since also the Branches concept should grow linearly with the growth-factor, while preserving the intra- and inter-table correlations, also the TAssignment table should grow linearly, and there should always be less branches than employees in TEmployee. – Since ProductSize does not grow, the attribute Size must contain only two values, despite the linear growth of TProduct.
The previous example illustrated several challenges that need to be addressed by the generator regarding the analysis of the virtual and physical data, and the insertion of values in the database. Our goal is to generate a synthetic virtual graph where the cost of the queries is as similar as possible to the cost that the same query would have in a real-world virtual graph of comparable size. Observe that the same virtual graph can correspond to different database instances, that could behave very differently w.r.t. the cost of SQL query evaluation. Therefore, in order to keep the cost of the SPARQL query “realistic”, we need to keep the cost of the translated SQL “realistic” as well.
We are interested in data generators that perform an analysis phase on real-world data, and that use the statistical information learned in the analysis phase for their task. We present first in Table 5 the measures that are relevant in the analysis phase. We then derive the requirements for the data generator by organizing them in two categories: one for the analysis phase, and one for the generation phase.
Measures for the Analysis Phase. Table 5 is divided in three parts. The top part refers to measures relevant at virtual instance level, i.e., those capturing the shape of the virtual instance. Virtual correlation measures the correlation between individuals connected through a property, i.e., the number of individuals/values to which every individual is connected via an object/data property. Virtual growth is the expected growth for each ontology term w.r.t. the growth-factor. Observe that these two measures are strongly related to each other. The middle part refers to measures at the physical level that strongly affect the shape of the virtual instance through the form of the mappings. They are based on the sets of attributes of a table used to define individuals and values in the ontology through the mapping. We call such a set of attributes an IGA (individual-generating attributes set). Establishing the relevant statistics requires to identify pairs of IGAs through mapping analysis. Specifically, intra-table IGA correlation is defined for two IGAs of the same table, both mapped to individuals/values at the virtual level. It is measured for tuples over the IGAs as the virtual correlation of the individuals that are generated via the mapping from the tuples. Inter-table IGA correlation is measured for IGAs belonging to two different tables, by taking the intra-table IGA correlation over the join of the two tables. The bottom part refers to measures at the physical level that do not affect correlation at the virtual instance level, but that influence growth at the virtual level and the overall performance of the system. Specifically, IGA duplication measures the number of identical copies of tuples over an IGA, while (intra-table and inter-table) IGA-pair duplication is measured as the number of identical copies of a tuple over two correlated IGAs. Notice that, for benchmarking purposes, both IGA correlation and IGA duplication are important.
Now we are ready to list the requirements for a data generator for OBDA systems. Requirements for the Analysis Phase. The generator should be able to analyze the physical instance and the mappings, in order to acquire statistics to assess the measures identified in Table 5.
Requirements for the Generation Phase. We list now important requirements for the generation of physical data that gives rise through the mappings to the desired virtual data instance.
Tunable. The user must be able to specify a growth factor according to which the virtual instance should be populated.
Virtually Sound. The virtual instance corresponding to the generated physical data must meet the statistics discovered during the analysis phase and that are relevant at the virtual instance level.
Physically Sound. The generated physical instance must meet the statistics discovered during the analysis phase and that are relevant at the physical instance level. Database Compliant. The generator must generate data that does not violate the constraints of the RDBMS engine—e.g., primary keys, foreign keys, constraints on datatypes, etc.
Fast. The generator must be able to produce a vast amount of data in a reasonable
amount of time (e.g., 1 day for generating an amount of data sufficient to push the
limits of the considered RDBMS system). This requirement is important because
OBDA systems are expected to operate in the context of “big-data” [
The Norwegian Petroleum Directorate5 (NPD) is a governmental organisation whose
main objective is to contribute to maximize the value that society can obtain from the oil
and gas activities. The initial dataset that we use are the NPD Fact Pages6, containing
information regarding the petroleum activities on the Norwegian continental shelf. The
ontology, the query set, and the mappings to the dataset have all been developed at the
University of Oslo [
The Ontology. The ontology contains OWL axioms specifying comprehensive information about the underlying concepts in the dataset; specifically rich hierarchies of classes and properties, axioms that infer new objects, and disjointness assertions. We took the OWL QL fragment of this ontology, and we obtained 343 classes, 142 object properties, 238 data properties, 1451 axioms, and maximum hierarchy depth of 10. Since we are interested in benchmarking OBDA systems that are able to rewrite queries over the ontology into SQL-queries that can be evaluated by a relational DBMS, we concentrate
here on the OWL 2 QL profile8 of OWL, which guarantees rewritability of unions of
conjunctive queries (see, e.g., [
From the previous facts, it follows that the ontology satisfies requirements O1, O2, S1. The Query Set. The original NPD SPARQL query set contains 25 queries obtained by interviewing users of the NPD dataset. Starting from the original NPD query set, we devised 14 queries having different degrees of complexity (see Table 6). In particular, observe that most complex queries involve both classes with a rich hierarchy and tree witnesses, which means that they are particularly suitable for testing the reasoner capabilities. We also fixed some minor issues, e.g., the absence in the ontology of certain concepts present in the queries, removing aggregates (to be tackled in future work), and flattening of nested sub-queries.
From the previous facts, it follows that the queries satisfy requirements Q1, Q2, S1. The Mappings. The R2RML mapping consists of 1190 assertions mapping a total of 464 among classes, objects properties, and data properties. The SQL queries in the mappings count an average of 2:6 unions of select-project-join queries (SPJ), with 1:7 joins per SPJ. We observe that the mappings have not been optimized to take full advantage of an OBDA framework, e.g., by trying to minimize the number of mappings that refer to the same ontology class or property, so as to reduce the size of the SQL query generated by unfolding the mapping. This gives the opportunity to the OBDA system to apply different optimization on the mappings at loading time.
From the previous facts, it follows that the mappings satisfies requirements M1, M2, S1. 4.1
VIG: The Data Generator.
Next we present the Virtual Instances Generator (VIG) that we implemented in the NPD Benchmark. VIG produces a virtual instance by inserting data into the original database. The generator is general in the sense that, although it currently works with the NPD database, it can produce data also starting from instances different than NPD. The algorithm can be divided into two main phases, namely (i) an analysis phase, where
statistics for relevant measures on the real-world data are identified; (ii) a generation phase, where data is produced according to the statistics identified in the analysis phase.
VIG starts from a non-empty database D. Given a growth factor g, VIG generates a new database D0 such that jT 0j = jT j (1 + g), for each table T of D (where jT j denotes the number of tuples of T ). This first approach assumes that each table in the database should grow linearly with respect to the growth factor, which is not true in general, but it holds for NPD. In addition, VIG approximates the measures described Table 5 as shown below.
Measures (D), (Intra-D). We compute (an approximation for) these measures by Duplicate Values Discovery. For each column T:C of a table T 2 D, VIG discovers the duplicate ratio for values contained in that column. The duplicate ratio is the ratio (jjT:Cjj jT:Cj)=jjT:Cjj, where jjT:Cjj denotes the number of values in the column T:C, and jT:Cj denotes the number distinct of values in T:C. A duplicate ratio “close to 1” indicates that the content of the column is essentially independent from the size of the database, and it should not be increased by the data generator.
Measures (Intra-C), (Inter-C), (Inter-D). Instead of computing (an approximation for) these measures, VIG identifies the domain of each attribute. That is, for each non-fixed domain column T:C in a table T , VIG analyzes the content of T:C in order to decide the range of values from which fresh non-duplicate values can be chosen. More specifically, if the domain of T:C is a string or unordered (e.g., polygons), then simply a random value is generated. Instead, if the domain is a total order, then fresh values can be chosen from the non-duplicate values in the interval [min(T:C); max(T:C)] or in the range of values adjacent to it. Observe that this helps in maintaining the domain of a column similar to the original one, and this in turn helps in maintaining intra- and inter-table correlations. VIG also preserves standard database constraints, like primary keys, foreign keys, and datatypes, that during the generation phase will help in preserving the IGA correlations. For instance, VIG analyses the loops in foreign key dependencies in the database. Let T1 ! T2 denote the presence of a foreign key from table T1 to table T2. In case of a cycle T1 ! T2 ! ! Tk ! T1, inserting a tuple in T1 could potentially trigger an infinite number of insertions. VIG performs an analysis on the values contained in the columns involved by the dependencies and discovers the maximum number of insertions that can be performed in the generation phase.
Next we describe the generation phase, and how it meets some of the requirements given in Section 5.
Duplicate Values Generation. VIG inserts duplicates in each column according to the
duplicate ratio discovered in the analysis phase. Each duplicate is chosen with a uniform
probability distribution. This ensures, for those concepts that are not dependent from
other concepts and whose individual are “constructed” from a single database column, a
growth that is equal to the growth factor. In addition, it prevents intrinsically constant
concepts from being increased (by never picking a fresh value in those columns where
the duplicates ratio is close to 1). Finally, it helps keeping the sizes for join result sets
“realistic” [
Requirement: Physically/Virtually Sound. Fresh Values Generation. For each column, VIG picks fresh non-duplicate values from the interval discovered during the analysis phase. If the number of values to insert exceeds the number of different fresh values that can be chosen from the interval I, then values outside the interval are allowed. The choices for the generation of new value guarantee that columns always contain values “close” to the ones already present in the column. This ensures that the number of individual for concepts based on comparisons grows accordingly to the growth factor.
Requirement: Physically/Virtually Sound.
Metadata Constraints VIG generates values that do not violate the constraints of the underlying database, like primary keys, foreign keys, or type constraints. The NPD database makes use of geometric datatypes available in MYSQL. Some of them come with constraints, e.g., a polygon is a closed non-intersecting line composed of a finite number of straight lines. For each geometric column in the database, VIG first identifies the minimal rectangular region of space enclosing all the values in the column, and then it generates values in that region. This ensures that artificially generated geometric values will fall in the result sets of selection queries.
Requirement: Database Compliant/Virtually Sound.
Length of Chase Cycles. In case a cycle of foreign key dependencies was identified during the analysis phase, then VIG stops the chain of insertions according to the boundaries identified in the analysis phase, while ensuring that no foreign key constraint is violated. This is done by inserting either a duplicate or a null in those columns that have a foreign key dependency.
Requirement: Database Compliant.
Furthermore, VIG allows the user to tune the growth factor, and the generation process is considerably fast, for instance, it takes 10hrs to generate 130 Gb of data. 5
In this section we perform a qualitative analysis of the virtual instances obtained using VIG. We focus our analysis on those concepts and properties that either are supposed to grow linearly w.r.t. the growth factor or are supposed not to grow. These are 138 concepts, 28 object properties, and 226 data properties.
We report in Table 7 the growth of the ontology elements w.r.t. the growth of databases produced by VIG and by a purely random generator. The first column indicates the type of ontology elements being analyzed, and the growth factor g (e.g., “class npd2” refers to the population of classes for the database incremented with a growth factor g = 2). The columns “avg dev” show the average deviation of the actual growth from the expected growth, in terms of percentage of the expected growth. The remaining columns report the number and percentage of concepts (resp., object/data properties) for which the deviation was greater than 50%.
Concerning concepts, VIG behaves close to optimally. For properties, the difference between the expected virtual growth and the actual virtual growth is more evident. However, it is orders of magnitude better than the random generator. We shall see how this difference strongly affects the results of the benchmark (Section 6). preserved for the 28 object properties that are generated from a single table. That is, the correlation remains constant and it grows only in the case of cartesian products on columns with high duplicate ratio and that together form a primary key. More results can be found in the benchmark page. 6
We ran the benchmark on the Ontop system9 [
MYSQL was used as underlying relational database system. The hardware consisted of an HP Proliant server with 24 Intel Xeon X5690 CPUs (144 cores @3.47GHz), 160GB of RAM and a 1TB 15K RPM HD. The OS is Ubuntu 12.04 LTS. Due to space
— — — — — constraints, we present the results for only one running client. We obtained results with the existential reasoning on and off.
In order to test the scalability of the systems w.r.t. the growth of the database, we used the data generator described in Section 4.1 and produced several databases, the largest being approximately 1500 times bigger than the original one (“NPD1500” in Table 8, 117 GB of size on disk ( 6 Bn triples)).
Table 8 shows the 9 easiest queries from the initial query set, for which the unfolding produces a single select-project-join SQL query. These results were obtained in Ontop. The query mix of 9 queries was executed 10 times, each time with different filter conditions so that the effect of caching is minimized, and statistics were collected in each execution. We measure the sum of the query execution time (avg(ex time)), the time spent by the system to display the results to the user (avg(out time)), the number of results (avg(res size)), and the query mixes per hour (qmpH), that is, the number of times that the 9 queries can be answered in one hour.
Table 9 contains results showing the number of unions of SPJ queries generated after rewriting (#rw) and after unfolding (#un) for the 5 hardest queries. In addition, it shows the time spent by Ontop on rewriting and unfolding. Here we can observe how existential reasoning can produce a noticeable performance overhead, by producing queries consisting of unions of more than 5000 sub-queries (c.f., q12). This blow-up is due to the combination of rich hierarchies, existentials, and mappings. These queries are meant to be used in future research on query optimization in OBDA.
Table 10 contains results for the 5 hardest queries in Ontop. Each query was run
once, since qmpH is not so informative in this case. Observe that the response time
tends to grow faster than the growth of the underlying database. This follows from the
complexity of the queries produced by the unfolding step, which usually contain several
joins (remember that the worst case cardinality of a result set produced by a join is
quadratic in the size of the original tables). Column NPD10 RAND witnesses how using
a purely random data generator gives rise to datasets for which the queries are much
simpler to evaluate. This is mainly due to the fact that a random generation of values
tends to decrease the ratio of duplicates inside columns, resulting in smaller join results
over the tables [
Table 11 shows the 6 queries where the performance difference is bigger. As expected, the 3 queries with worst performance in OBDA are those that were affected by the blowup shown in Table 9. On the other hand, the 3 queries that perform the best are those where the different optimization led to a simple SPJ SQL query. Note how in these 3 queries, in Ontop, the overhead caused by the increment of dataset size is minimum. 7
The benchmark proposed in this work is the first one that thoroughly analyzes a
complete OBDA system in all significant components. So far, little or no work has
been done in this direction, as pointed out in [
In: Proc. of VLDB. pp. 8–19 (1983) tion Systems 5(2), 1–24 (2009) (2005) Garilao, C.: FishMark: A linked data application benchmark. In: Proc. of the Joint Workshop on Scalable and High-Performance Semantic Web Systems (SSWS+HPCSW 2012), vol. 943, pp. 1–15. CEUR, ceur-ws.org (2012) synthetic GPS traces with real-life data characteristics. In: Selected Topics in Performance Evaluation and Benchmarking, LNCS, vol. 7755, pp. 140–155. Springer (2013) Kharlamov, E., Kllapi, H., Klu¨ wer, J., Koubarakis, M., Lamparter, S., Mo¨ ller, R., Neuenstadt, C., Nordtveit, T., O¨ zcep, O¨ ., Rodriguez-Muro, M., Roshchin, M., Ruzzi, M., Savo, F., Schmidt, M., Soylu, A., Waaler, A., Zheleznyakov, D.: The Optique project: Towards OBDA systems for industry (Short paper). In: Proc. of OWLED. CEUR, ceur-ws.org, vol. 1080 (2013)