Ontology Driven Query Language for NoSQL Databases

Transcription

1 Ontology Driven Query Language for NoSQL Databases 1 Shreya Banerjee, 2 Takaaki Goto, 3 Narayan C Debnath, 4 Anirban Sarkar 1,4 Department of Computer Science & Engineering, National Institute of Technology, Durgapur, India 2 Faculty of Distribution and Logistics Systems, Ryutsu Keizai University, Japan 3 Department of Computer Science, Winona State University, MN, USA { 1 shreya.banerjee85@gmail.com, 2 tg@gotolab.net, 3 ndebnath@winona.edu, 4 sarkar.anirban@gmail.com} Abstract Most NoSQL databases have been devised independently from each other with specific application requirements. This has resulted in developing separate own data model and query language for each NoSQL database. The lack of standards in data models and query languages make applications and data less portable using these databases. Further, absence of formal semantics in query languages inhibits a precise understanding of query over NoSQL databases. To handle these issues, in this paper, an ontology driven query language for NoSQL databases is proposed. The proposed query language provides an efficient and common abstraction over the operational aspects on various kinds of NoSQL databases. The language includes formal common syntax and semantics of distinct query operators of NoSQL databases and those are represented in Description Logic. Further, usefulness of proposed query operators are proved using a suitable case study. Keywords Query Language, Query Operators, Ontology, Formal Semantics, Description Logic I. INTRODUCTION Over the last few years, there is an emergence rise of new type of databases known as NoSQL. These databases have crucial features those are distinguished from traditional relational databases. Such as flexible schema, persistent and non-relational data, dynamic insertion of any kind of data, high availability of data, massive horizontal scaling, distribution, replication, support towards BASE (Basically Available, Soft State, Eventually Consistent) and CAP (Consistency, Availability and Persistence) consistency model [1]. A variety of NoSQL databases are developed by practitioners to meet their requirements [2]. Experts have classified those in four basic categories based on different physical level data models. Those are Key-Value store (for example Riak), Document Store (for example MongoDB), Column-Family store (for example HBase) and Graph databases (for example Neo4j) [3]. Most NoSQL databases have been developed independently from one other, each with specific application objectives, but with the general goal of offering rather simple operations on flexible data structures [4]. Usually, each NoSQL database has implemented its own query language. Such as Cassandra Query Language (CQL) is developed for Cassandra database; MongoDB uses MongoDB query language; Cypher query language is developed for Neo4j etc. [6]. Hence, querying these new generations of databases are physical data model specific [5]. Consequently, applications and data using these databases are not portable. This lack of standard in data models and query languages is a great concern for organizations interested in adopting any of these databases. Thus, a research question has been arose that how to represent a common standard in data models and query languages for most of NoSQL databases. Query languages of distinct NoSQL databases have many variations. Some variations are due to syntactic differences. Other variations are due to differences in query language capabilities and semantics [7]. For developing a common query language for NoSQL databases, these differences need to be reduced. Syntactic differences can be omitted using a common data model that can be mapped towards heterogeneous physical data models of NoSQL databases. On the other hand, query capabilities and semantic differences can be handled by representing distinct query operations using common semantics and capabilities for distinct NoSQL databases. However, common semantics and syntax for query operators need to be precise and consistent. Further, this will be more effective if implicit information can be derived from databases through query answering by the process of reasoning. This can be achieved when semantics and syntax of query languages are represented formally. Yet, lack of succinct, formal syntax and semantics inhibits a deep understanding of various NoSQL databases and less efficient query answering [7]. This paper is aimed for addressing the above mentioned research question of representing a common and formal query language for various NoSQL databases. To compensate syntax differences in querying languages, in the proposed work an ontology driven data model for NoSQL databases known as Ontology Driven NoSQL Data Model (ODNSDM) described in [8] is used. ODNSDM is a conceptual model that provides common abstraction over the varied kind of NoSQL databases. Further, it has supported common representation of data over both schema-based and schema-less databases. Advantage of using ontology based data model is to get benefits of providing common formal syntax and semantics towards different physical level data models of NoSQL databases. Ontology is explicit formal specification of shared conceptualization [9]. Due to this benefit, ontology is also used in the proposed work to reduce semantic and capability differences of distinct query languages over NoSQL databases. Novelty of the proposed work is to specify common formal semantics and syntax of distinct query operators used for different NoSQL databases. Proposed query operators are of two types data definition and data manipulation. These query operators are represented in Description Logic (DL) [14]. DL is subset of first order logic. Representing query operators in DL is advantageous as it is decidable and aided efficient reasoning. Consequently, proposed /17/$ IEEE 951

2 formal semantics of query operators is necessary in development of a suitable reasoner for query answering. II. RELATED WORK In literature, few approaches are exist in the field of representing formal semantics of query operators used for NoSQL databases. In [7], syntax and semantics of a query language known as SQL++ has been described using Backus Naur form or Backus normal form (BNF) grammar for both Java Script Object Notation (JSON) native stores and SQL databases. However, BNF grammar is not as much proficient like DL in aiding reasoning. In [10], Unstructured Query Language (UnQL) has been described. However, this query language has SQL like syntax and can be used across various document oriented databases including CouchDB and MongoDB. Besides, this language is not much formally enriched in order to represent precise semantics of distinct query operators. An approach regarding uniform access towards NoSQL databases has been described in [4] named as Save Our System (SOS). In this approach, a common data model has been described that has allowed the querying of NoSQL databases defined in MongoDB, HBase, Redis using a common set of simple atomic operations such as get, put and delete. In [6], a unified query engine has been described known as ZQL. This query engine is acted as middleware and has different features including support towards cross database operations such as Create, Update, Read, and Delete (CRUD). ZQL is applied towards two underlying exemplary databases MySQL and Hive. However, both [4, 6] have not carried out formal analysis of query operators and thus not useful for further reasoning over query answering. In [11], a query language has been defined known as OntoQL to support ontology based databases. Yet, this approach has provided formal semantics towards distinct query operators superficially of traditional relational databases. In [12], Ontology Based Data Access (OBDA) framework is described for querying arbitrary databases through a mediating ontology. In this approach, this framework is applied on MongoDB as an exemplary database for answering SPARQL queries over MongoDB. Likewise in [13], OBDA is applied for answering ontology mediated queries on top of key-value databases. In this approach, the data model and queries of key-value databases are formalized. Besides, a rule language has been described for reasoning on key-value databases. However, this approach is specific towards only keyvalue databases. In this context, relevant formal specifications of query operators have been required in order to device a common query language for distinct NoSQL databases and efficient query answering. The proposed work in this paper has specified these formal specifications using DL that has facilitated in efficient reasoning in query answering over distinct NoSQL databases. III. BRIEF DESCRIPTION OF ONTOLOGY DRIVEN NOSQL DATA MODEL (ODNSDM) The proposed formal specification of query operators is based on constructs of an ontology driven meta-model for NoSQL databases known as ODNSDM [8]. The model is comprised of three main layers Collection, Family and Attribute. These layers have their respective construct type - Collection (Col), Family (FA) and Attribute (AT). Attribute construct types are atomic and it is the bottom most layer of the data model. Family is the intermediate layer of the meta-model. This layer can be further decomposed into multiple levels. Several semantically related Attributes are gathered together to form the lowest level Family Layer. Collection is the top-most layer of the data model. Semantically related upper most level Families are collected together to form a Collection. Constructs of discrete layers and levels are connected with each other using different kinds of relationships. These relationships are of two types Intra-layer kind and Inter-layer kind. Inter-layer kind relationships include Containment, Inverse Containment and Reference relationships. On the other hand Intra-layer kind relationships can include Containment, Inverse Containment, Reference, Inheritance and Association relationships. Using, Containment relationships one construct type has encapsulated same or different types of construct types. On the other hand, Inverse Containment relationship has enabled one construct type to de-encapsulate itself in order to dynamically encapsulate similar or dissimilar construct types. Besides, distinct constructs of this meta-model has different properties such as Multiplicity, Modality, Availability, Ordering and Conditional-Participation. From the top level, the entire database can be viewed as a set of Collections. Figure 1 has illustrated the layer hierarchy of ODNSDM. Fig. 1. Different Layers, construct types and relationships of ODNSDM IV. PROPOSED ONTOLOGY DRIVEN SPECIFICATION OF QUERY OPERATORS FOR NOSQL DATABASES Proposed ontology driven specification of query operators has include both data definition and data manipulation part for NoSQL databases. Data definition operators include Create (CT) and Write (WR) operators. On the other hand, data manipulation operators include Select (ST), Retrieve (RT), Update (UP), Delete (DT) and Aggregate (AG) operators. Further, the proposed operators are based on ODNSDM that is a layered organization. Therefore, a specific path is needed to establish or search for accessing the specific construct type in the data model. Regarding this, two additional operators known as Get_Path and Check_Construct-Type are proposed. All of these operators are represented using Description Logic (DL). Definition and formal specification of these operators are described in following sub-sections. A. Formal specification of Get_Path and Check_Construct- Type operators Get_Path and Check_Construct-Type operators are formally specified in this section. Usually in NoSQL databases, query operators has required to identify the specific construct type and the path ended towards the construct type for various query requirements. So, these operators need to be formally described. 952

3 Check_Construct-Type operator: It is an operator that has specified the type of specific construct type - Family, Collection or Attribute of ODNSDM. The formal expression of this operator is as follows. F1: ( h _ _. _ ((. _ ) (. ) ( _ )) (((. ) (. _ )) ((. _ ) (. )) ((. _ ) (. _ )) ( _ )) ((. ) (. ) ((. ) (. ) (. ) (. _ ) ( _ ))) Explanation: Check Construct_Type is a concept representing Check_Construct-Type operator for identifying type of specific construct type. Construct_Type is a concept that has specified the particular construct whose type has been checked. Operate_on is a role specifying relationship between Check_Construct-Type operator and Construct_Type. The formalization has identified the type of construct type by three disjunctive conditions. The first condition is ((. _ ) (. ) ( _ )). It has stated that if range of all Containment relationships in ODNSDM is a Family and domain is the construct whose type is to be checked, then the construct type is a Collection. In this condition, Family is a construct specifying Family construct type of ODNSDM. Containment is a role specifying Containment relationship of ODNSDM. Further, (. _ ) and (. ) these fragments of F1 have represented domain and range of Containment relationship respectively. The second condition is (((. ) (. _ )) ((. _ ) (. )) ((. _ ) (. _ )) ( _ )). This condition is again combination of three disjunctive conditions. The first condition is if domain of any Containment relationship is a Collection and range is the specific construct whose type is to be checked, then the construct type is a Family. The second condition is if domain and range of any Containment relationship is similar specific construct whose type is to be checked, then the construct type is a Family. The third condition is if domain of any Containment relationship is the specific construct whose type is to be checked, and range is an Attribute then the construct type is a Family. In this part of formalization, the interpretations of other concepts is similar as in first condition. The third condition is ((. ) (. ) ((. ) (. ) (. ) (. _ ) ( _ )). This condition is again combination of three consecutive conditions. The first condition is if domain of any Containment relationship is a Collection and range is a Family. The second condition is if domain and range of any Containment relationship are Families. The third condition is if domain of any Containment relationship is a Family, and range is the construct whose type is to be identified, then the construct type is Attribute. In this formalization, the interpretations of other concepts is similar as in first condition Get_Path Operator: It is an operator that has returned paths towards a specific construct type initiated from a Collection. F2: _ h _ ((. h _ ) ( h _ h. )) ((. h _ ) ( h ( _ h. ) ( _ h. ))) ((. h _ ) ( h ((( _ h1. ) ( _ h1. )) _ h2. ))) ((( _ h1. ) ( _ h1. )) _ h2. )) (( _ h3. ) ( _ h3. ))))) Explanation: Get_Path Construct_Type is a concept representing Get_Path Operator for getting path from a Collection towards specific construct type. The formalization has specified path from Collection towards three types of constructs using three disjunctive conditions. The first condition is ((. h _ ) ( h _ h. )). This condition has specified that there should be no path present from Collection towards another Collection, since only one Collection can be a root of a specific layer organization in ODNSDM. In this formalization, (. h _ ) - this fragment has specified that Get_Path operator has called Check_Construct-Type operator and identify if the type of construct type is a Collection. Further, h _ h. - this fragment has specified that there should be no path between two Collections. The second condition is ((. h _ ) ( h ( _ h. ) ( _ h. ))).This condition has stated that there should be a path present from a Collection towards a Family. (. h _ ) - This fragment has specified that Get_Path operator has called Check_Construct-Type operator and identify if the type of construct type is Family. Further, ( _ h. ) - this fragment has specified that the path should be initiated from a Collection. Subsequently, ( _ h. ) this fragment has specified that the path is ended on a Family. 953

4 The third condition is ((. h _ ) ( h ((( _ h1. ) ( _ h1. )) _ h2. ))) ((( _ h1. ) ( _ h1. )) _ h2. )) (( _ h3. ) ( _ h3. )))). This condition has stated that there should be a path present from a Collection towards an Attribute via a Family or Families. (. h _ ) - This fragment has specified that Get_Path operator has called Check_Construct- Type operator and identify if the type of construct type is Attribute. Further, the rest part has specified that the Path from a Collection to an Attribute is sequences of either Path1 (from Collection to Family), and Path2 (from Family to Attribute) or Path1 (from Collection to Family), Path2 (from Family to Family) and Path3 (from Family to Attribute). B. Formal specification of Data Definition and Data Manipulation query operators Several query operators have been proposed in this section in order to provide common query interface for distinct NoSQL databases. These operators can be classified in two parts Data Definition Operators and Data Manipulation Operators. Data Definition Operators have provided definition of distinct construct types of ODNSDM as well as different NoSQL databases. Create (CT) and Write (WR) operators are belongs to Data Definition Operators. On the other hand, Data Manipulation operators have manipulated distinct construct types of ODNSDM as well as different NoSQL databases. Select (ST), Retrieve (RT), Update (UP), Delete (DT) and Aggregate (AG) operators are belongs to Data Manipulation Operators. Definition and formal specification are described below. Create Operator (CT): This operator has created Collections, and Families in ODNSDM. The mathematical expression of this operator is as follows. F3: ( ( _. (. ) (. ) (. ) _ h. _ h )) Explanation: CT Collection-Family is a concept representing Create operator. Further, setcontainment is a role that has set domain and range of Containment relationship as Collection and Family respectively. (. ) - this fragment has specified that setcontainment role has never set the range of Containment relationship as Collection. Further, set_path is a role that has associated with concept Get_Path Family. This role set a path from Collection towards Family equivalent with the Path obtained through Get_Path Family operator. Write Operator (WR): This operator has written records into Collection. Those records can be represented as R. This R is consisting of Attributes and its related values. Further, this operator may dynamically insert multiple records at same time. Thus, through this operator, flexible schema of NoSQL databases can be populated. Thus, the operator is related with Inverse Containment relationship of ODNSDM. Further, those multiple records can be linked with each other using logical AND operator. F4: ( _. ( h. ( _ h_. _ h ( _ h_. _ h _. )) (( _ _. ) ( _ _. ) _ h. _ h _. )) Explanation: This formalization has specified that Write operator will write records towards Collection according to R- Value. The operator at first search if there is a path from Collection towards Family using the part _ h_. _ h. If the path is exist, then it has set domain and range of Inverse Containment towards Attribute and Family respectively using( _ _. ) ( _ _. ). Next, set path from Collection towards Attribute using _ h. _ h and write value of record into the Attribute using _.. However, if the path from Collection to specific Family is not exist, then value will not be insert in the Attribute. Select Operator (ST): This operator has select specific Families contained in a Collection or specific Attributes contained within a Family according to some predicates P and rules R. P can be some atomic predicates or composite predicates denoted as p1 <op> p2 <op> <op>pn. op is a logical operator such as AND, OR etc. Rules R can be denoted as semantic rules that has facilitated in retrieving implicit information contained in the data. Those predicates such as p1, p2 can be specific Families or Attributes. The mathematical formalization of Select Operator is as follows. F5: ( _. (( h. 1 h. 2) ( h. 1 h. 2)) ( _. _. ) _ h. _ h_. _ h _ h_. _ h ) Explanation: This formalization has specified that Select operator will select the path towards Family and Attribute according to rules R and predicates P. h and _ h are roles through which the operator is linked with P and R respectively. Further, using _ h_. _ h and is_path_to.get_path Attribute the operator has select the path from Collection towards specific Family and Attribute. Retrieve Operator (RT): This operator has retrieved specific Families contained in a Collection or specific Attributes contained within a Family according to several conditions CON. CON can be based on Select operator. It can be of the form of 1 < > 2 < > 3. op is a logical operator such as AND, OR etc. 954

5 F6: ( _. (( h _. 1 h _. 2 ) ( h _. 1 h _. 2 )).. ) Explanation: This formalization has specified that Retrieve operator will return specific Family or Attribute according to s everal conditions. h _ is a role through which the operator is linked with Select operator. Besides, read is a role through which the operator has returned or read specific Families and Attributes according to the condition CON. Update Operator (UP): This operator has updated or modified a Collection with addition of specific Families and Attributes belongs to Record R. The mathematical expression of this operator is as follows. F7: ( _. h. ( _ h_. _ h ( _ h_. _ h (( _ _. ) ( _ _. )) _. _ _. _ h. _ h )) ( _ h_. _ h ( _ h_. _ h (( _ _. ) ( _ _. )) _. _ _. _ h. _ h )) Explanation: This formalization has specified that Update operator will modify old value of specific Family or Attribute or add specific Family or Attribute according to several new records R towards Collection. h is a role through which the operator is linked with concept of NewRecord. Besides, remove_value is a role through which the operator has omitted the old value of Family or Attribute. Further, write_new_value is a role through which the operator has written new value towards Family or Attribute. Rest part of the formalization are similar as for Write operator. Delete Operator (DT): This operator has removed specific record from Collection according to several deletion criteria DC or delete whole Collection. The mathematical expression of this operator is as follows. F8: ( _. ( h. h. ) ( _ h_. _ h (. ) (. ).. ) ( _ h_. _ h. )) Explanation: This formalization has specified that Delete operator will delete specific Family or Attribute according to several criteria. h is a role through which the operator is informed about Families and Attributes those to be deleted. Besides, remove is a role through which the operator has deleted specific Families and Attributes according to DC. Rest parts of the formalization are specified in above specifications. Aggregate Operators (AG): This operator has performed aggregate functions F on Collections, Families or Attributes. These aggregate functions can be of many types such as sum, count, group, set union, set difference, set intersection etc. Record R has specified the specific Families, and Attributes on which aggregate functions have executed. The mathematical expression of this operator is as follows. F9: ( _. ( _. _. ) h. ( _ h_. _ h _.. ) ( _ h_. _ h _.. )) Explanation: This formalization has specified that Aggregate operator has executed distinct functions F on record R containing specific Families or Attributes. h is a role through which the operator is linked with specific function such as sum, count, set intersection. Besides, Associate_Record is a role through which the operator is connected towards specific record. Further, F_execute is a role that has performed specific aggregate functions on Family or Attribute. Furthermore, returnresult is a role that has returned result after execution of aggregate function over Family or Attribute. Rest parts of the formalization are specified in above specifications. V. ILLUSTRATIONS OF PROPOSED QUERY OPERATORS USING A CASE STUDY Let an e-prescription application, using which a doctor can prescribe a prescription towards patient electronically. This application is capable to aid doctors to query about medication of patient, their previous prescriptions, and medical history. It has several facets such as patient, doctor, medication advices, medical history of patients etc. This case study is adopted from [15]. In this case, often patients may have no previous prescriptions or medical history. In addition, drug information can also be frequently changed. Moreover, a patient may have e-prescriptions prescribed by different doctors for same disease. All these characteristics imply that the data set is highly irregular and need flexible representation. Hence, NoSQL databases are required to manage this data set. The key elements of this case study are listed below. Collections are specified in bold letters. Families are identified in italic letters. Attributes are denoted in non-italic letters. Elements within parenthesis are mandatory whether elements within braces are optional that can be added on the fly. E-Prescription (E_Prescription Info, Patient, Doctor, {Medications}) E_Prescription Info(e_prescription_number, prescription_date) Patient (Patient_Personnal_info, Patient_Medical_history) Patient_Personnal_info(Patient_Name,patient_age,patient_ gender, patient_registration_number, {Patient_Address}) Doctor(doctor_name, doctor_registration_number, doctor_contact_number) Medications (anyof {Drug Generic Name, comments}, {dosage_form}, {quantity}, {duration}) Query 1: Create a database E-Prescription Records that contain information of E-Prescription Info, Patient and Doctor. 955

6 Powered by TCPDF ( For this query Create Operator (CT) will be used. The expression can be as follows ( (. ((. ) (. ) (. ) (. )) ( _ h. _ h _ h. _ h _ h. _ h )) Query 2: Insert in this database information of Medication. Update Operator (UP) will be used for this query. The reason is that the main schema is already built. So, information of Medication will be added towards the database by modifying the schema. ( _. h. ( _ h_. _ h (( _ _. ) ( _ _. ))) _ _. _ h. _ h ) Query 3: Display the name of Drug Generic Name prescribed for the patient whose name is A. Roy. Both Select (ST) and Retrieve (RT) operators are used for this query. ST will select the path from E-Prescription towards patient and drug generic name. Then, RT will retrieve the information of drug generic name. _, (. ( h. Patient_Name h. Drug Generic Name) ( _ h_. _ h _ _ h_. _ h ) _., (. h _. _, ). Patient_Name. Drug Generic Name) Query 4: Insert in this database Address of Patient Write Operator (WR) will be used for this query. Because, in NoSQL databases basic level data those are Attributes can be inserted dynamically without modifying the main schema. _ ( _. ( h. Patient_Address ( _ h_. _ h _ (( _ _. Patient_Address) ( _ _. ) _ h. _ h _ _. Patient_Address)) VI. CONCLUSION AND FUTURE WORK Query languages of NoSQL databases are specific to respective physical level data models. Consequently, there is a lack of a standard formal query language for these new generation databases. This has made applications utilizing those databases difficult to be portable. Besides, this drawback has resulted in less efficient query answering. To address these issues in this paper an ontology driven common query language for NoSQL databases has been proposed. Novelty of the proposed work is to specify common formal semantics and syntax of distinct query operators used for different NoSQL databases in description logic (DL). Besides, both data definition and data modification query operators have been formalized. Further, proposed formal semantics represented in DL are decidable and will facilitate to devise efficient reasoning algorithms. Thus, proposed formal semantics are necessary for development of a suitable reasoner for query answering over NoSQL databases. Moreover, the proposed query language is based on ODNSDM specifically, but can be used over any NoSQL data model in general. Future work will include representing of proposed formal semantics of query operators in a rule language so that a suitable reasoned can be built for efficient query answering. Besides, transformation of these operators towards native NoSQL databases will be an important future work. REFERENCES [1] D. Pritchett, BASE: An ACID Alternative, ACM Queue, vol. 6(3), pp , [2] R. Cattell, Scalable SQL and NoSQL Data Stores, ACM SIGMOD Record, vol. 39(4), pp , December, [3] R. Hecht, S. Jablonski, NoSQL evaluation: A use case oriented survey, 2011 International Conference on Cloud and Service Computing (CSC '11), IEEE Computer Society, Hong Kong, China, pp , [4] P. Atzeni, F. Bugiotti and L. Rossi, Uniform access to NoSQL systems, Information Systems, vol. 43(C), pp , [5] K. Kaur, R. Rani, "Modeling and querying data in NoSQL databases," 2013 IEEE International Conference on Big Data, Silicon Valley, CA, pp. 1-7, [6] J. Xu,, M. Shi,, C. Chen, Z. Zhang, J. Fu, and C.H. Liu, ZQL: A Unified Middleware Bridging Both Relational and NoSQL Databases, 14th Intl Conf on Dependable, Autonomic and Secure Computing, 14th Intl Conf on Pervasive Intelligence and Computing, 2nd Intl Conf on Big Data Intelligence and Computing and Cyber Science and Technology Congress (DASC/PiCom/DataCom/CyberSciTech), IEEE, pp , [7] K.W. Ong, Y. Papakonstantinou,, R. Vernoux, The SQL++ query language: Configurable, unifying and semi-structured, arxiv preprint arxiv: , [8] S. Banerjee, A. Sarkar, Ontology Driven Meta-Modeling for NoSQL Databases: A Con-ceptual Perspective, Int. J. of Software Engg. and Its Applications, Science & Engineering Research Support Society (SERSC). vol. 10(12), pp , [9] N. Guarino, D. Oberle, S. Staab, What is an Ontology?, Handbook on Ontologies, second edition, ed: Springer-Verlag, pp. 1-17, [10] P. Buneman, M. Fernandez, D. Suciu, UnQL: a query language and algebra for semistructured data based on structural recursion, The VLDB Journal The International Journal on Very Large Data Bases, vol. 9(1), pp , [11] S. Jean, Y. Aït-Ameur, G. Pierra, Querying ontology based database using ontoql (an ontology query language), OTM Confederated International Conferences On the Move to Meaningful Internet Systems, Springer Berlin Heidelberg, pp , [12] E. Botoeva, D. Calvanese, B. Cogrel, M. Rezk, G. Xiao, OBDA beyond relational DBs: A study for MongoDB, birth, 1926, pp.08-27, [13] M.L. Mugnier, M.C. Rousset, F. Ulliana, Ontology-mediated queries for NOSQL databases, AAAI: Conference on Artificial Intelligence, pp , February, [14] M. Krotzsch, F. Simancik, I. Horrocks, Description logics, IEEE Intelligent Systems, vol. 29(1), pp.12-19, [15] S. Banerjee, A. Sarkar, Modeling NoSQL Databases: From Conceptualto Logical Level Design, 3rd Intl. Conf. on Applications and Innovations in Mobile Computing (AIMoC), India, pp , February,