Killing Two Birds with One Stone -- Querying Property Graphs using SPARQL via GREMLINATOR

01/25/2018 ∙ by Harsh Thakkar, et al. ∙ University of Athens Technische Informationsbibliothek University of Bonn 0

Knowledge graphs have become popular over the past decade and frequently rely on the Resource Description Framework (RDF) or Property Graph (PG) databases as data models. However, the query languages for these two data models -- SPARQL for RDF and the PG traversal language Gremlin -- are lacking interoperability. We present Gremlinator, the first translator from SPARQL -- the W3C standardized language for RDF -- and Gremlin -- a popular property graph traversal language. Gremlinator translates SPARQL queries to Gremlin path traversals for executing graph pattern matching queries over graph databases. This allows a user, who is well versed in SPARQL, to access and query a wide variety of Graph Data Management Systems (DMSs) avoiding the steep learning curve for adapting to a new Graph Query Language (GQL). Gremlin is a graph computing system-agnostic traversal language (covering both OLTP graph database or OLAP graph processors), making it a desirable choice for supporting interoperability for querying Graph DMSs. Gremlinator currently supports the translation of a subset of SPARQL 1.0, specifically the SPARQL SELECT queries.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1. Introduction

Knowledge graphs model the real world in terms of entities and relations between them. They became popular as they are an intuitive and simple data model, which allows to execute many types of queries efficiently and can serve as a foundation for a range of Artificial Intelligence applications. The Resource Description Framework (RDF) and Property Graphs (PGs) are popular languages for knowledge graphs. For RDF, the SPARQL query language was standardized by W3C, whereas for PGs several languages are frequently used, including Gremlin 

(Rodriguez, 2015).

PGs and RDF have evolved from different origins and still have largely disjoint user communities. RDF is part of the Semantic Web initiative with a focus on expressive data modelling as well as data publication and linking. PGs originate from the database community with a focus on efficient execution of graph traversals.

With Gremlinator, we build a bridge between both communities and research the interoperability of RDF and PG query languages (Thakkar et al., 2018). Moreover, we allow combining the best of both worlds: Powerful modelling capabilities as well as data publication and interlinking methods combined with efficient graph traversal execution. In particular, Gremlinator has the following advantages: (1) Existing SPARQL-based applications can switch to property graphs in a non-intrusive way. (2) It provides the foundation for a hybrid use of RDF triple stores and property graph DMS – a system could detect which DMS is more efficient for answering a particular query (Das et al., 2014) and redirect the query accordingly. In particular, property graph databases have been shown to work very well for a wide range of queries which benefit from locality in a graph. Rather than performing expensive joins, property graph databases use micro indices to perform traversals. (3) Users familiar with the W3C standardized SPARQL query language do not need to learn another query language.

Overall, we make the following contributions:

  • [nosep]

  • A novel approach for mapping SPARQL queries to Gremlin pattern matching traversals, Gremlinator, which is the first work converting an RDF to a property graph query language to the best of our knowledge.

  • An openly available implementation for executing SPARQL queries over a plethora of third party graph DMS such as Neo4J, Sparksee, OrientDB, etc. using the Apache TinkerPop framework.

The remainder of the article is organized as follows: Section 2 summarizes the related work. Section 3 sheds light on the importance of Gremlin, briefly discusses the Gremlinator approach and its limitations. Section 4 presents the demonstration details and the value Gremlinator will cater to its users. Finally, Section 5 concludes the article and describes the future work.

2. Related Work

We present a brief summary of related work with regard to techniques and tools that support the translation and execution of formal query languages, addressing the interoperability issue.

SPARQL SQL: There is a substantial amount of work been done for conversion of SPARQL queries to SQL queries, such as – Ontop (Calvanese et al., 2017), R2RML (Rodriguez-Muro and Rezk, 2015), Elliot et al. (Elliott et al., 2009), Chebotko et al. (Chebotko et al., 2009), Zemke et al. (Zemke, 2006), Priyanka et al. (Priyatna et al., 2014). Ontop (Calvanese et al., 2017), one of the most popular system, exposes relational databases as virtual RDF graphs by linking the terms (classes and properties) in the ontology to the data sources through mappings. This virtual RDF graph can then be queried using SPARQL.

SQL SPARQL: RETRO (Rachapalli et al., 2011) presents a formal semantics preserving the translation from SQL to SPARQL. It follows a schema and query mapping approach rather than to transform the data physically. The schema mapping derives a domain-specific relational schema from RDF data. Query mapping transforms an SQL query over the schema into an equivalent SPARQL query, which in turn is executed against the RDF store.

SQL CYPHER: CYPHER111CYPHER Query Language (https://neo4j.com/developer/cypher-query-language/) is the graph query language used to query the Neo4j222Neo4j (https://neo4j.com/) graph database. There has been no work yet to use SQL on top of CYPHER. However, there are some examples333SQL to CYPHER (https://neo4j.com/developer/guide-sql-to-cypher/) that show the equivalent CYPHER queries for certain SQL queries.

3. Gremlinator Approach

In this section we discuss the why we choose Gremlin as a property graph query language and briefly describe the Gremlinator approach.

3.1. Why Apache TinkerPop Gremlin?

Gremlin is a system-agnostic query language developed by Apache TinkerPop444Gremlin: Apache TinkerPop’s graph traversal language and machine (https://tinkerpop.apache.org/). It supports both – pattern matching (declarative) and graph traversal (imperative) style of querying over property graphs.

Figure 1. The Gremlin Traversal Language and Machine.

Gremlin is more general than, e.g. ,CYPHER, as it provides in addition to a query language a common execution platform for supporting any graph computing system (including both OLTP and OLAP graph processors), for addressing the querying interoperability issue (see Figure 1 (a)). Together with Apache TinkerPop framework, Gremlin is a language and a virtual machine, it is possible to design another traversal language that compiles to the Gremlin traversal machine (analogous to how Scala compiles to the JVM), ref. Figure 1 (b). Gremlin provides the declarative (SPARQL style) pattern matching querying construct using the .match()-step.

For brevity, we abstain from dwelling into the definitions and formal semantics of Gremlin, rather point the interested reader to the literature (Rodriguez, 2015; Thakkar et al., 2017). Furthermore, one may also refer to (Thakkar et al., 2018), where the complete SPARQL to Gremlin translation approach is discussed in detail.

3.2. Gremlinator Pipeline

We now present the architectural overview of Gremlinator in Figure 2 and discuss each of the four steps of its execution pipeline.

Step 1. The input SPARQL query is first parsed using the Jena ARQ module, thereby: (i) validating the query and (ii) generating its abstract syntax tree (AST) representation.

Step 2. From the obtained AST of the parsed SPARQL query, Gremlinator then visits each basic graph pattern (BGP), mapping them to the corresponding Gremlin single step traversals (SSTs). A SST in Gremlin is an atomic traversal step () we describe in (Thakkar et al., 2018) in detail.

Step 3. Thereafter, depending on the operator precedence obtained from the AST of the parsed SPARQL query, each of the corresponding SPARQL keywords are mapped to their corresponding instruction steps from the Gremlin instruction library. Thereafter a final conjunctive traversal () is generated appending the SSTs and instruction steps. This can be perceived analogous to the SPARQL query language, wherein a set of BGPs form a single complex graph pattern (CGP).

Step 4. This final conjunctive traversal () is used to generate bytecode555Bytecode is simply serialized representation of a traversal, i.e. a list of ordered instructions where an instruction is a string operator and a (flattened) array of arguments. which can be used on multiple language and platform variants of the Apache TinkerPop Gremlin family.

Figure 2. The architectural overview of Gremlinator.

3.3. Pre-defined Queries

Considerations. We encode the prefixes of SPARQL queries within the Gremlinator implementation. In order to aid the SPARQL to Gremlin translation process, we define custom prefixes preserving the categories of Gremlin instruction steps. For instance, the standard rdfs:label prefix (which is generally a predicate) is represented as e:label or v:label (where e = edge and v = vertex).

For the demonstration of Gremlinator, we provide a set of 30 pre-defined SPARQL queries for reference, for each dataset, covering 10 different SPARQL query features (i.e. three queries per feature with a combination of various modifiers) as shown in Table 1. These features were selected after a systematic study of SPARQL query semantics (Angles et al., 2016; Pérez et al., 2006; Schmidt et al., 2010) and from BSBM (Bizer and Schultz, 2009) explore use cases666BSBM Explore Use Cases (https://goo.gl/y1ObNN) and Watdiv Query templates777Watdiv Query Features (http://dsg.uwaterloo.ca/watdiv/basic-testing.shtml). Furthermore, we encourage the end user to write and execute custom SPARQL queries for both the datasets, for further exploration.

Query Id. Feature Description
C1-C3 CGPs Queries with mixed number of BGPs
F1-F3 FILTER CGPs with a combination of 1 FILTER constraints
L1-L3 LIMIT+OFFSET CGPs with a combination of LIMIT + OFFSET constraints
G1-G3 GROUP BY CGPs with GROUP BY feature
Gc1-Gc3 GROUP COUNT CGPs with GROUP BY + COUNT
O1-O3 ORDER BY CGPs with ORDER BY feature
U1-U3 UNION CGPs with UNION feature
Op1-Op3 OPTIONAL CGPs with OPTIONAL BGPs
M1-M3 MIX CGPs with a combination of all above features
S1-S3 STAR CGPs forming a STAR shape execution plan (10 BGPs)
Table 1. Query feature and description

3.4. Limitations

Gremlinator is an on-going effort for achieving seamless translation of SPARQL queries to Gremlin traversals. The current version of Gremlinator supports the SPARQL 1.0 SELECT queries with the following excceptions: 1.) REGEX (regular expressions) in FILTER (restrictions) of a graph pattern are currently not supported. 2.) Gremlinator does not support variables for the property predicate, i.e. the predicate {p} in a graph pattern {s p o .} has to be defined or known for the traversal to be generated. This is because traversing a graph is not possible without knowing the precise traversal operation to the destination (vertex or edge) from the source (vertex or edge).

4. Demonstration Details

As a part of the demonstration of our system Gremlinator, we provide– (i) an online screencast888Gremlinator Demo Screencast – https://youtu.be/Z0ETx2IBamw (ii) a web application, see Figure 3)999Gremlinator Web Demo – http://gremlinator.iai.uni-bonn.de:8080/Demo (iii) a desktop application of Gremlinator (standalone .jar bundle) which requires Java 1.8 JRE installed on the corresponding host machine, downloadable from the web demo website.

The demonstration work-flow for all the above mentioned Gremlinator versions is identical, wherein – (i) the user selects a dataset (Northwind or BSBM) from the corresponding drop-down menu; (ii) the user selects a query (one of the ten SPARQL query features) from the corresponding drop-down menu; (iii) the user executes the query; (iv) Gremlinator returns the selected SPARQL query, the translated Gremlin traversal and the result of the traversal execution; (v) the user can also edit or write custom SPARQL queries and execute them at selected dataset using the integrated query editor at will.

Figure 3. Gremlinator Web application demonstration screenshot.

We will present the live demonstration of Gremlinator using a pre-configured laptop with all the resources including the SPARQL queries and datasets. In order to demonstrate the correctness of our approach we will provide a custom docker-based Openlink Virtuoso SPARQL endpoint, pre-loaded with the datasets, for a one-to-one query result comparison (for interested visitors).

Value. Gremlinator will serve as a user friendly medium to – (i) execute SPARQL queries over property graphs bridging the query interoperability gap; (ii) conduct performance analysis of query results, comparisons of SPARQL vs. Gremlin traversal operations using frameworks such as LITMUS (Thakkar, 2017; Thakkar et al., 2017); and (iii) enable querying a spectrum of graph databases via SPARQL 1.0 query fragment (ref. Figure 4), leveraging the advantages of the Apache TinkerPop framework.

Figure 4. Gremlinator powered by Apache TinkerPop will enable querying a variety of Graph databases.

5. Conclusion & Future Work

We presented a demonstration of Gremlinator, a novel approach for supporting the execution of SPARQL queries on property graphs using Gremlin traversals. Gremlinator has obtained clearance by the Apache Tinkerpop development team and is currently in production phase to be released as a plugin during TinkerPop’s next framework cycle. Gremlinator has also been integrated into the SANSA Stack (Lehmann et al., 2017) (v0.3) framework as an experimental plugin. Furthermore, Gremlinator is freely available under the Apache 2.0 license for public use from the Maven Central repository.

As future work, we are working on – (i) adding support for REGEX in restriction (FILTERs), variables for property predicates, and (ii) supporting translation of SPARQL 1.1 query features such as property paths, in the upcoming releases.

6. Author Biographies

Harsh Thakkar - is a Marie Skłodowska-Curie Ph.D. student at the University of Bonn, Germany. He earned his M.Tech. in Computer Science from NIT Surat, India. His research interests include Graph and RDF Data Management, Benchmarking, Graph Query Languages and Question Answering.
Dharmen Punjani - is a Marie Skłodowska-Curie Ph.D. student at the National and Kapodistrian University of Athens, Greece. He earned his M.Tech. in Computer Science from NIT Surat, India. His research interests include Geo-Spatial and RDF Data Management, N.L.P., and Question Answering.
Jens Lehmann

is professor for Software and Data Engineering, leads the Smart Data Analytics (SDA) research group at the University of Bonn and is a lead scientist at the Enterprise Information Systems (EIS) department at Fraunhofer IAIS. His main research interests are semantic technologies and machine learning.

Sören Auer

is professor for Data Science and Digital Libraries at University of Hannover and director of TIB Leibniz Information Center for Science and Technology. His research interests revolve around semantic technologies, scholarly communication and digital libraries.

Acknowledgements

This work is supported by the funding received from EU-H2020 WDAqua ITN (GA. 642795). We would like to thank Dr. Marko Rodriguez and Mr. Daniel Kuppitz, of the Apache TinkerPop project, for their support and quality insights in developing Gremlinator.

References

  • (1)
  • Angles et al. (2016) Renzo Angles, Marcelo Arenas, Pablo Barceló, Aidan Hogan, Juan L. Reutter, and Domagoj Vrgoc. 2016. Foundations of Modern Graph Query Languages. CoRR abs/1610.06264 (2016).
  • Bizer and Schultz (2009) Christian Bizer and Andreas Schultz. 2009. The berlin sparql benchmark. (2009).
  • Calvanese et al. (2017) Diego Calvanese, Benjamin Cogrel, Sarah Komla-Ebri, Roman Kontchakov, Davide Lanti, Martin Rezk, Mariano Rodriguez-Muro, and Guohui Xiao. 2017. Ontop: Answering SPARQL queries over relational databases. Semantic Web 8, 3 (2017), 471–487.
  • Chebotko et al. (2009) Artem Chebotko, Shiyong Lu, and Farshad Fotouhi. 2009. Semantics preserving SPARQL-to-SQL translation.

    Data & Knowledge Engineering

    68, 10 (2009), 973–1000.
  • Das et al. (2014) Souripriya Das, Jagannathan Srinivasan, Matthew Perry, Eugene Inseok Chong, and Jayanta Banerjee. 2014. A Tale of Two Graphs: Property Graphs as RDF in Oracle.. In EDBT. 762–773.
  • Elliott et al. (2009) Brendan Elliott, En Cheng, Chimezie Thomas-Ogbuji, and Z Meral Ozsoyoglu. 2009. A complete translation from SPARQL into efficient SQL. In Proceedings of the 2009 International Database Engineering & Applications Symposium. ACM, 31–42.
  • Lehmann et al. (2017) Jens Lehmann, Gezim Sejdiu, Lorenz Bühmann, Patrick Westphal, Claus Stadler, Ivan Ermilov, Simon Bin, Nilesh Chakraborty, Muhammad Saleem, and Axel-Cyrille Ngonga Ngomo. 2017. Distributed Semantic Analytics using the SANSA Stack. In Proceedings of the 16th International Semantic Web Conference (ISWC). Springer, 147–155.
  • Pérez et al. (2006) Jorge Pérez, Marcelo Arenas, and Claudio Gutierrez. 2006. Semantics and Complexity of SPARQL. In International semantic web conference. Springer, 30–43.
  • Priyatna et al. (2014) Freddy Priyatna, Oscar Corcho, and Juan Sequeda. 2014. Formalisation and experiences of R2RML-based SPARQL to SQL query translation using Morph. In Proceedings of the 23rd international conference on World wide web. ACM, 479–490.
  • Rachapalli et al. (2011) Jyothsna Rachapalli, Vaibhav Khadilkar, Murat Kantarcioglu, and Bhavani Thuraisingham. 2011. RETRO: A Framework for Semantics Preserving SQL-to-SPARQL Translation. The University of Texas at Dallas 800 (2011), 75080–3021.
  • Rodriguez (2015) Marko A. Rodriguez. 2015. The Gremlin graph traversal machine and language (invited talk). In Proceedings of the 15th Symposium on Database Programming Languages, Pittsburgh, PA, USA, October 25-30, 2015. 1–10.
  • Rodriguez-Muro and Rezk (2015) Mariano Rodriguez-Muro and Martin Rezk. 2015. Efficient SPARQL-to-SQL with R2RML mappings. Web Semantics: Science, Services and Agents on the World Wide Web 33 (2015), 141–169.
  • Schmidt et al. (2010) Michael Schmidt, Michael Meier, and Georg Lausen. 2010. Foundations of SPARQL query optimization. In Proceedings of the 13th International Conference on Database Theory. ACM, 4–33.
  • Thakkar (2017) Harsh Thakkar. 2017. Towards an Open Extensible Framework for Empirical Benchmarking of Data Management Solutions: LITMUS. In The Semantic Web - 14th International Conference, ESWC 2017, Portorož, Slovenia, May 28 - June 1, 2017, Proceedings, Part II. 256–266.
  • Thakkar et al. (2017) Harsh Thakkar, Yashwant Keswani, Mohnish Dubey, Jens Lehmann, and Sören Auer. 2017. Trying Not to Die Benchmarking: Orchestrating RDF and Graph Data Management Solution Benchmarks Using LITMUS. In Proceedings of the 13th International Conference on Semantic Systems, SEMANTICS 2017, Amsterdam, The Netherlands, September 11-14, 2017. 120–127.
  • Thakkar et al. (2018) Harsh Thakkar, Dharmen Punjani, Yashwant Keswani, Jens Lehmann, and Sören Auer. 2018. A Stitch in Time Saves Nine – SPARQL querying of Property Graphs using Gremlin Traversals. CoRR abs/1801.02911 (2018).
  • Thakkar et al. (2017) Harsh Thakkar, Dharmen Punjani, Maria-Esther Vidal, and Sören Auer. 2017. Towards an Integrated Graph Algebra for Graph Pattern Matching with Gremlin. In Proceedings of the 28th International Conference, DEXA 2017, Lyon, France, August 28-31, 2017, Proceedings, Part I. Springer, 81–91.
  • Zemke (2006) F Zemke. 2006. Converting sparql to sql. Technical Report. Technical Report, October 2006.