Towards Query Formulation and Query-Driven Ontology Extensions in OBDA Systems B. Cuenca Grau2 , M. Giese4 , I. Horrocks2 , T. Hubauer3 , E. Jiménez-Ruiz2 , E. Kharlamov2 , M. Schmidt1 , A. Soylu4 , D. Zheleznyakov2 1 fluid Operations AG, Germany 2 Department of Computer Science, University of Oxford, Oxford UK, 3 Siemens Corporate Technology, Germany 4 Department of Informatics University of Oslo, Norway Abstract. The process of translating end-users’ information needs into execu- table 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 Op- tique, 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. Keywords: Ontology-Based Data Access, Query Formulation, Ontology Navigation 1 Introduction 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 mod- eled 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 [7]. 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 ap- plications that allow accessing data through a limited set of predefined queries. In sit- uations 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 trans- late 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 [5]. This is clearly very ex- pensive in terms of both time and money. The Optique project6 [7] advocates for the well-known Ontology-Based Data Access (OBDA) approach (e.g., [20, 2]) to address the bottlenecks that end-users face when accessing Big Data and aims at solutions that significantly reduce the cost of data access. 5 Statoil ASA is an oil and gas company and it is one of the uses case scenarios in Optique, which aims in particular at providing access to data for geologists, petrophysicists, etc. 6 http://www.optique-project.eu/ Classical OBDA Optique OBDA end-user IT-expert Application Query Ontology & Mapping (Analytics) Formulation Management end-user IT-expert results Application query Ontology Mappings query Ontology Mappings results Query Transformation Query Answering Distributed Query Optimisation and Processing ... ... ... heterogeneous heterogeneous streaming data data sources data sources Fig. 1. The general architecture of a classical (left) and the Optique (right) OBDA system OBDA systems have the potential to address the data access problem by present- ing 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 re- ferred 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 de- fined 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 Sta- toil 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 (Fig- ure 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 bootstrap- ping 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 ig- nored 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 sys- tem 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 for- mulation 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 envis- aged architecture of our query formulation component. 2 Challenges in Query Formulation The ontology in an OBDA system, as already mentioned, is intended to provide a user- oriented conceptual model of the domain. This allows users to formulate queries us- ing 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 [23, 17, 10, 21] for some state-of-the-art solutions. There are, however, two important concep- tual challenges related to the query by navigation approach: (i) representation paradigms for ontologies, and (ii) correlations between navigation and query construction. We will now elaborate on these challenges. Representation paradigms. Query by navigation approaches usually combine naviga- tional 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 pro- vides 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 collabo- ration 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 im- portant paradigm, namely the graph representation metaphor of OWL ontologies. The formal underpinning of OWL (and its revision OWL 2) is provided by Description Log- ics (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. Or- thogonally, 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 [19], and only conjunctive queries are formulated, there are still several issues regarding to the representation and navigation of the information shown to the user: 1. Top-down propagation of property restrictions. Traditional graph representations usually only include explicit information attached to a concept in the ontology; however, inherited restrictions will also play an important role in graph navigation. For example if the ontology includes the axiom Wellbore v ∃hasPath.Path,7 then the subconcepts of Wellbore should also suggest a link to the concept Path. How- ever, this can make the representation unfeasible when Wellbore has many subcon- cepts; thus a trade-off between readability and the amount of necessary information provided to the user should be achieved. 2. Bottom-up propagation of property restrictions. Since from a model-theoretic point of view the interpretation of an OWL concept also includes the interpretations of all 7 The axiom says that every wellbore has (at least) one path. its subconcepts, it may also make sense to suggest for a given concept the (poten- tial) 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 ∃hasProduction.Oil and GasWell v ∃hasProduction.Gas, then the con- cept 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. Wellbore v ∃hasCore.Core Core v ∃hasLayer.StratigraphicLayer StratigraphicLayer v ∃layerOf.Wellbore. Should the system suggest or allow the user to go to Wellbore via the layerOf re- lation 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. Q(x) :- Wellbore(x), hasCore(x,y), hasLayer(y,“Neolithic”), layerOf(“Neolithic”,u), Wellbore(u). Since the way to cope with cycles depends on the user’s intention, we do not envi- sion 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 on- tology, 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 ∃hasBit.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 ac- count the issues above. We aim at providing an intuitive end-user interface while pre- serving 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 formu- lation is driven from a Description Logic model of the domain, e.g., [1, 4]. 8 This query is written in the Datalog notation 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, depart- ments, 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 formula- tion. 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 [14]. 2. Adding basic extensions. End-user queries may also require basic extension of the ontology hierarchy, such as adding a new concept GeologicalWellBore un- der WellBore (i.e. GeologicalWellBore v WellBore). These types of additions can be considered safe since they represent a conservative extension of the ontol- ogy [12]. However other additions to the ontology may require further analysis by the IT-expert if they are not conservative extensions (e.g. reclassifying the concept WellBore under the new concept PlannedSideTrack). 3. “On the fly” extensions. This represents the more challenging scenario where we intend to exploit ontology learning techniques in order to mine formulated queries and to identify relevant new concepts and relations (e.g., [24, 16]). Ontology align- ment techniques (e.g. [11]) will also be required in order to relate the new vocabu- lary to the existing ontology concepts. 4. IT-expert assistance. In the cases where the manual or on-the-fly extensions are insufficient, the assistance of the IT expert will be required to extend the ontology accordingly. 3 Envisaged Architecture and Approach Figure 2 shows the main query formulation components envisaged for the Optique OBDA solution and their interaction with other components of the system. Next we give a brief overview of each of them. Note that many components deal with both one- time queries, e.g., SPARQL queries, and continuous queries, e.g., CSPARQL queries. 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 in- terfaces 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 nav- igation. Additionally, direct editing should also allow the possibility of exploiting Integrated via Information Workbench Presentation Query Formulation Layer Interface Information Workbench frontend API (E.g., widget dev., Java, REST) Query Formulation Processing Components Configuration Direct Editing of modules Workbench Export Users Feedback visualisation functionality functionality 1-time Q Stream Q SPARQL QDriven ont LDAP engine construction authentification 1-time Q External Answer Communication SPARQL Stream Q visualisation Manager Chanel or Hub Ontology & engines Hub Mapping Manager's Query by Navig. Processing 1-time Q Components Answers to 1-time SPARQL Stream Q Stream analytics queries, e.g., SPARQL Ont/Mapp revision, mining Context Sens. Ed. control, Answers to stream Faceted 1-time Q editing log analysis queries, e.g., CSPARQL SPARQL Stream Q search ... Query Answering Component OWL API Sesame API Ontology Processing - ontology Distrib. Query Query transformation - mappings Execution Ontology reasoner 1 - configuration Answer manager Ontology reasoner 2 - queries 1-time Q Shared - answers SQL->RDF Stream Q ... triple Shared - history Ontology store - lexical Application database modularization information Layer - etc. Components Colouring Convention Types of Users Front end: Application receiving Expert users Component mainly Web-based Optique solution answers API External solution End users Group of components Fig. 2. Query Formulation components of the Optique OBDA system 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, logic- based ontology modularization techniques [6] will also be exploited to achieve a good balance between overview and focus when dealing with large ontologies. The properties of such modules guarantee that the semantics of the concepts of interest are preserved while providing (in general) a much smaller fragment of the ontology. 4. The The Query Answering component will transform the formulated queries into executable and optimized queries with respect to the data sources (e.g. streaming data, relational databases). 5. The Answer Manager component. This component should deal with the (basic) visualization of the query results and their transformation (i.e. export functionality) into the required output formats (e.g. input formats of external Statoil tools). 6. The User Feedback component. This component is intended to allow the user to semi-automatically refine a query if the (partially) obtained results are not the ex- pected ones. Furthermore, similar or related queries to the partially constructed query will also be suggested in order to help end-users in the refinement. 7. The Ontology Revision Control component. Different versions of the ontology may exist concurrently (e.g. extensions driven by different formulated queries or query requirements). These versions will be managed by the IT-experts through a revision control system in order to detect logical defects (e.g. unsatisfiabilities), logical con- flicts among versions as in [13], and OWL 2 profile violations (e.g. a new version is outside the OWL 2 QL profile). All components will be integrated into the Information Workbench [9, 8], a generic plat- form for semantic data management, which provides a central triple store for managing the OBDA system assets (such as ontologies, mappings, etc.), generic interfaces and APIs for semantic data management, and a flexible user interface that will be used for implementing the query formulation components. The user interface follows a semantic wiki approach, based on a rich, extensible pool of widgets for visualization, interaction, mashup, and collaboration, which can be flexibly integrated into semantic wiki pages, allowing developers to compose comprehensive, actionable user interfaces without any programming effort. The following subsection presents the technical architecture for the query formulation interface and the solution approach based on widget-based mashups. 3.1 Widget-based solution A mashup based approach (cf. [22]) is promising for the construction of an extensible and flexible query formulation interface. The mashup idea, in our context, is grounded on the possibility to combine the functionality and data of a set of individual applica- tions in a common graphical space, for common tasks. Widgets are the building blocks of mashups, where each widget corresponds to a standalone application with less com- plex functionality and presentation compared to full-fledged applications. In query for- mulation scenario, a set of widgets can be employed, for instance, one for query by navigation and one for faceted search for handling the construction of queries; and one for representing results in table and one for visualizing the result in a graph to handle communication of results to the end-users. Widgets are managed by a widget environment which provides basic communi- cation 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, Widget based implementation of Query Formulation Interface Client side Query by Presentation Faceted Direct Query Driven Context Sens. Dynamic Navigation Search Editing Ont. Contract. Result Interface Layer Interface Interface Edit. Interface Communication Chanel Interface Controller Logics of Answering Query by Faceted Direct Context Query Driven Logic Navigation Search Editing Sensitiv Ont. Contract. Logics Logics Logics Logics Ranking Component Feedback Control Logic Export Query Formulation Processing Components Application Layer Server side Components Colouring Convention Types of Users Front end: Widget Expert users Component Optique solution End users mainly Web-based Fig. 3. Query Formulation interface based on widget-based mashups 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 func- tionality that it is expected to provide; iii widgets can be used alone or together, in different combinations, for different con- texts and experiences; and, iv the functionality of the overall interface can be extended by introducing new wid- gets (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 com- municate with each other and with the environment through a communication channel. Communication usually happens through the client side, but a server side communica- tion 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 en- vironment 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. Widget  1   Widget  3   JOIN   SELECT  and  PROJECT       Menu-­‐based  and  Icon-­‐based  Widget   Form-­‐based  and  Menu-­‐based  Widget   (QbN)   (Faceted  Search)     JOIN   Widget  2     Diagram-­‐based  Widget   (QbN)         Widget  4   JOIN  and  VIEW     Form-­‐based  (table  result)  Widget   (QbN)   Fig. 4. An initial approach combining different paradigms for query formulation 3.2 Query formulation interface Catarci et al. [3] categorize data access efforts into understanding the reality of inter- est (i.e., exploration), which relates to activities for finding and understanding schema concepts and relationships relevant to information need; and query construction, which concerns the compilation of relevant concepts and constraints into formal information needs. The query construction task is normally considered as a series of actions, each of which can be either a select, join, or project action. The join type of actions enables users to combine different concepts and to form path expressions for queries, where the select and project type of actions allow users to specify the properties that are to be returned and to impose constraints to filter the results. As such, the choice of visual representation and interaction paradigm, along with underlying metaphors, analogies etc., is of primary importance for the query formulation interface. We have observed that a single representation and interaction paradigm is not suf- ficient for developing a successful query formulation interface. Therefore, we strive to combine the best parts of different paradigms (cf. [18]). A conceptual sketch of our first attempt is shown in Figure 4. Initially, there are four widgets available. The first wid- get is based on a menu-based approach with QbN interaction paradigm, where domain concepts, properties, and relationships are distributed into a set of layers, with respect to a certain hierarchy or organization, and presented in the form of lists. This wid- get also employs an icon-based paradigm by supplementing domain vocabulary with meaningful icons. The second widget follows a diagram-based approach with QbN. The diagram-based approach utilizes geometric symbols to depict relationships among schema concepts. The third widget employs a form-based and menu-based approach in the form of a faceted search interface. The form-based approach adopts conventional paper forms as a metaphor. The final widget is also form-based, more specifically table- based, and employs a QbN based interaction style. The first widget is responsible for join actions, and determines the focus of inter- face. 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 en- ables 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 [15]. This particularly becomes true for large ontologies, in which guiding the user to relevant vocabulary is of crucial importance. For instance, a keyword search facility can support finding relevant concepts, properties and relationships in the first and second widgets. Each representation paradigm can han- dle different ontology axioms, for instance, a faceted search paradigm is better suited for representing disjointness, and a menu-based paradigm with QbN may be a better option for handling cycles (e.g., with path coloring). 4 Conclusions 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 indus- try 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 Sev- enth Framework Program (FP7) of the European Commission under Grant Agreement 318338, the Optique project. Cuenca Grau, Horrocks, Jiménez-Ruiz, Kharlamov, and Zheleznyakov were also partially supported by the EPSRC projects ExODA and Score! References 1. Bechhofer, S., Horrocks, I.: Driving User Interfaces from FaCT. In: Proceedings of the 2000 International Workshop on Description Logics. pp. 45–54 (2000) 2. Calvanese, D., Giacomo, G.D., Lembo, D., Lenzerini, M., Poggi, A., Rodriguez-Muro, M., Rosati, R., Ruzzi, M., Savo, D.F.: The MASTRO system for ontology-based data access. Semantic Web 2(1), 43–53 (2011) 3. Catarci, T., Costabile, M., Levialdi, S., Batini, C.: Visual query systems for databases: A survey. Journal of Visual Languages and Computing 8(2), 215–260 (APR 1997) 4. Catarci, T., Dongilli, P., Mascio, T.D., Franconi, E., Santucci, G., Tessaris, S.: An ontology based visual tool for query formulation support. In: ECAI. pp. 308–312 (2004) 5. Crompton, J.: Keynote talk at the W3C Workshop on Semantic Web in Oil & Gas Indus- try: Houston, TX, USA, 9–10 December (2008), available from http://www.w3.org/ 2008/12/ogws-slides/Crompton.pdf 6. Cuenca Grau, B., Horrocks, I., Kazakov, Y., Sattler, U.: Modular reuse of ontologies: Theory and practice. J. Artif. Intell. Res. 31, 273–318 (2008) 7. Giese, M., Calvanese, D., Haase, P., Horrocks, I., Ioannidis, Y., Kllapi, H., Koubarakis, M., Lenzerini, M., Möller, R., Özçep, O., Rodriguez Muro, M., Rosati, R., Schlatte, R., Schmidt, M., Soylu, A., Waaler, A.: Scalable End-user Access to Big Data. In: Rajendra Akerkar: Big Data Computing. Florida : Chapman and Hall/CRC. To appear. (2013) 8. Haase, P., Hütter, C., Schmidt, M., Schwarte, A.: The Information Workbench as a Self- Service Platform for Linked Data Applications. In: the WWW 2012 Developer Track (2012) 9. Haase, P., Schmidt, M., Schwarte, A.: The Information Workbench as a Self-Service Platform for Linked Data Applications. In: Proceedings of the Second International Workshop on Consuming Linked Data (COLD) (2011) 10. Heim, P., Ziegler, J.: Faceted visual exploration of semantic data. In: Second IFIP WG 13.7 conference on Human-computer interaction and visualization. pp. 58–75 (2011) 11. Jiménez-Ruiz, E., Cuenca Grau, B.: LogMap: Logic-based and Scalable Ontology Matching. In: Int’l Sem. Web Conf. (ISWC). pp. 273–288 (2011) 12. Jiménez-Ruiz, E., Cuenca Grau, B., Sattler, U., Schneider, T., Berlanga, R.: Safe and eco- nomic re-use of ontologies: A logic-based methodology and tool support. In: The 5th Euro- pean Semantic Web Conference, ESWC. vol. 5021, pp. 185–199 (2008) 13. Jiménez-Ruiz, E., Grau, B.C., Horrocks, I., Llavori, R.B.: Supporting concurrent ontology development: Framework, algorithms and tool. Data Knowl. Eng. 70(1), 146–164 (2011) 14. Jimeno-Yepes, A., Jiménez-Ruiz, E., Llavori, R.B., Rebholz-Schuhmann, D.: Reuse of ter- minological resources for efficient ontological engineering in life sciences. BMC Bioinfor- matics 10(S-10), 4 (2009) 15. Katifori, A., Halatsis, C., Lepouras, G., Vassilakis, C., Giannopoulou, E.: Ontology visual- ization methods - A survey. ACM Computing Surveys 39(4) (2007) 16. Kotis, K., Papasalouros, A., Maragoudakis, M.: Mining query-logs towards learning useful kick-off ontologies: an incentive to semantic web content creation. IJKEDM 1(4) (2011) 17. Lim, S.C.J., Liu, Y., Lee, W.B.: Faceted search and retrieval based on semantically annotated product family ontology. In: Proc. of teh Workshop on Exploiting Semantic Annotations in Information Retrieval. pp. 15–24 (2009) 18. Lohse, G., Biolsi, K., Walkner, N., Rueter, H.: A classification of visual representations. Communications of the ACM 37(12), 36–49 (DEC 1994) 19. Motik, B., Cuenca Grau, B., Horrocks, I., Wu, Z., Fokoue, A., Lutz, C.: OWL 2 Web Ontol- ogy Language: Profiles (2009), W3C Recommendation 20. Rodriguez-Muro, M., Calvanese, D.: High Performance Query Answering over DL-Lite On- tologies. In: the 13th Int’l Knowledge Representation and Reasoning Conf. (KR) (2012) 21. Soylu, A., Modritscher, F., De Causmaecker, P.: Ubiquitous web navigation through harvest- ing embedded semantic data: A mobile scenario. Integrated Computer-Aided Engineering 19(1), 93–109 (2012) 22. Soylu, A., Modritscher, F., Wild, F., De Causmaecker, P., Desmet, P.: Mashups by orches- tration and widget-based personal environments Key challenges, solution strategies, and an application. Program-Electronic Library and Information Systems 46(4), 383–428 (2012) 23. Suominen, O., Viljanen, K., Hyvänen, E.: User-Centric Faceted Search for Semantic Portals. In: Proc. of the 4th European Semantic Web Conf. (ESWC 2007). pp. 356–370 (2007) 24. Zhang, J., Xiong, M., Yu, Y.: Mining query log to assist ontology learning from relational database. In: Frontiers of WWW Research and Development (APWeb). pp. 437–448 (2006)