DOCSLIB.ORG

Graph Data Models, Query Languages and Programming Paradigms ∗

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Graph Data Models, Query Languages and Programming Paradigms ∗ Graph Data Models, Query Languages and Programming Paradigms ∗ [Tutorial Summary] Alin Deutsch Yannis Papakonstantinou UC San Diego UC San Diego [email protected] [email protected] ABSTRACT Finally we compare with prior nested and graph query Numerous databases support semi-structured, schemaless languages (notably OQL, XQuery, Lorel, StruQL, PigLatin) and heterogeneous data, typically in the form of graphs (of- and we transfer into the modern graph database context ten restricted to trees and nested data). They also provide lessons from the semistructured query processing research corresponding high-level query languages or graph-tailored of the 90s and 00s, combining them with insights on current programming paradigms. graph databases. The evolving query languages present multiple variations: PVLDB Reference Format: Some are superficial syntactic ones, while other ones are A. Deutsch, Y. Papakonstantinou. Graph Data Models, Query genuine differences in modeling, language capabilities and Languages and Programming Paradigms. PVLDB, 11 (12): 2106- semantics. Incompatibility with SQL presents a learning 2109, 2018. DOI: https://doi.org/10.14778/3229863.3229879 challenge for graph databases, while table orientation of- ten leads to cumbersome syntactic/semantic structures that are contrary to graph data. Furthermore, the query lan- 1. TUTORIAL TOPIC AND AUDIENCE guages often fall short of full-fledged semistructured and Numerous graph and nested databases promoted as SQL- graph query language capabilities, when compared to the on-Hadoop, NewSQL and NoSQL support Big Data appli- yardsticks set by prior academic efforts. cations. These databases generally support semi-structured, We survey features, the designers’ options and differences schemaless and heterogeneous data, which is the focus of this in the approaches taken by current systems. We cover both tutorial. Broadly, the data models are either graphs, or trees declarative query languages, whose semantics is indepen- (nested data) as exemplified by JSON and variations thereof. dent of the underlying model of computation, as well as lan- The databases provide corresponding query languages. We guages with an operational semantics that is more tightly review characteristic ones: Apache Hive [27], MongoDB [22], coupled with the model of computation. For the declar- Couchbase’s N1QL [12, 9], SPARQL [26], Neo4j’s Cypher ative languages over both general graphs and tree-shaped [13], Facebook’s GraphQL [17], Apache Spark SQL [25], graphs (as motivated by XML and the recent generation of CosmosDB, Apache Gremlin [18], TigerGraph’s GSQL [19]. nested formats, such as JSON and Parquet) we compare to We use SQL-92 as the anchor of SQL compliance and also an SQL baseline and present SQL reductions and extensions comment on additional databases and query languages ([10, that capture the essentials of such database systems. More 11, 7, 6, 16, 5]). precisely, rather than presenting a single SQL extension, we The audience of this tutorial is roughly divided in present multiple configuration options whereas multiple pos- three categories: First, developers that want to use these sible (and different) semantics are formally captured by the databases are overwhelmed by their number and want to multiple options that the language’s semantic configuration make sense of the options provided in this space. Second, options can take. We show how appropriate setting of the database language designers who are building new features configuration options morphs the semantics into the seman- (for graph and nested data) and are interested in a deep tics of multiple surveyed languages, hence providing a com- analysis of the available options. Third, database builders pact and formal tool to understand the essential semantic and researchers who work on expanding the databases’ query differences between different systems. language abilities. Both parties face the challenges described below regarding surveying and comparing models and query ∗Supported by NSF IIS129263, NSF SHB1237174, Informat- ica Inc. gift and Couchbase Inc. gift. languages, past and present. Both parties need a deep un- derstanding of what is different from plain SQL. This tuto- rial provides a deep understanding of the current data mod- els and query languages of graph and nested data databases, This work is licensed under the Creative Commons Attribution- hence enabling comparisons. NonCommercial-NoDerivatives 4.0 International License. To view a copy The tutorial does not limit itself to the current status of of this license, visit http://creativecommons.org/licenses/by-nc-nd/4.0/. For graph querying: The database builders and researchers need any use beyond those covered by this license, obtain permission by emailing to draw lessons from the rich body of past research on nested [email protected]. [20, 24, 1], object-oriented [4] and semistructured data mod- Proceedings of the VLDB Endowment, Vol. 11, No. 12 Copyright 2018 VLDB Endowment 2150-8097/18/8. els and querying [14, 8, 23], which have been a topic of in- DOI: https://doi.org/10.14778/3229863.3229879 tense database research: They were first researched in the 2106 form of labeled graphs in the mid-90s. Then semistructured need to appreciate the available options, in order to data research boomed in the form of XML and its labeled proceed to well-designed fully-fledged languages and tree abstraction. Many of the important language design efficient implementations thereof. issues of the first eras must be recalled in the new era of semistructured data. More broadly, we compare SQL (which we use as a base- 3. A SYSTEMATIC SURVEY OF MODEL line) with the recent crop of graph and nested databases and AND LANGUAGE OPTIONS AND VARI- connect the recent activity around graph and JSON query- ATIONS ing to the (much richer) past activity on nested relational, Step 1: Extending the relational model and SQL for OQL and XML/labeled tree models and respective query graphs As discussed above, part of the confusion is derived languages and implementations. from the lack of compatibility with the well-known, baseline SQL, which both researchers and practitioners generally un- 2. CHALLENGES IN COMPREHENDING derstand. THE SPACE OF GRAPH AND NESTED Towards a uniform explanation of the large space of cur- rent and past systems, this tutorial reduces the declarative DATA DBS languages to (minimally extended) SQL. We start by re- A first challenge is that the evolving semistructured query calling the insight that graphs can be modeled as relational languages have many variations. (By “semistructured" we databases by using appropriate vertex tables and edge ta- refer to both graph and nested data.) Some variations are bles. Vice versa, most relational databases can be viewed due to superficial syntactic differences that simply create as graphs whose vertices are tuples and whose edges are “noise" when one tries to understand and compare systems. key-foreign key pairs. We develop this analogy and show However, other variations are genuine differences in query that multi-way SQL join queries correspond to fixed-length language capabilities and semantics. multi-hop path navigation. We then introduce a series of Indeed, the evolving query languages of both the genuine minimal extensions that enhance the expressiveness of SQL semistructured databases and the SQL/JSON databases fall towards reaching that of graph query languages. short of full-fledged semi-structured query language capa- One extension introduces controlled amounts of recursion 1 bilities - as set by early academic efforts in the 90s. The via path expressions that specify reachability in the graph. designers of the new query languages can gain by under- We track the concept’s evolution from early systems like standing and picking the salient features of past full-fledged OQL [4], Lorel [2], WebSQL [21], StruQL [15] via the stan- declarative query languages for non-relational data models: dard XPath/XQuery [28] and the de facto standard Regular OQL [4], the nested relational model [20, 24, 1], XQuery, Path Queries (RPQs) [3], all the way to contemporary lan- and other XML query languages [23, 14, 8]. guages such as Cypher [13] and Gremlin [18]. Path expres- Part of the confusion around semistructured query lan- sions may start with a variable, and multiple path expres- guages is derived from the lack of compatibility with the well sions may appear in the FROM clause, potentially correlated known SQL. In the interest of broadening the audience, this with previously defined variables of the same FROM clause. tutorial assumes that the audience is well-aware of SQL and This correlation feature is ruled out by SQL-92 but it has the standard material of graduate textbooks on SQL system been prominently present since OQL. implementation. The tutorial does not assume knowledge of Additional extensions collaborate towards ensuring lan- other query languages. Consequently we explain the JSON guage compositionality, by enabling queries to output model and query languages as minimal extensions to SQL. In graphs. A key enabler is the ability to invent fresh values to particular SQL-92, as it represents the well-supported com- model the identities of newly constructed nodes and edges. mon denominator of all SQL systems and corresponds to This ability has its roots in object-oriented languages and normalized databases. The tutorial does not require knowl- its various incarnations can be invoked by the programmer edge of non-1NF, often proprietary, features that have been either explicitly or implicitly. We additionally demonstrate added to SQL-92. Rather it only requires textbook SQL-92 simultaneous construction of multiple linked tuples via each language and teaches the non-1NF concepts, as well as the application of the SELECT clause. Moreover, we show full graph concepts. compositionality, in the sense that subqueries can appear A final challenge in understanding the new space of anywhere, potentially creating nested results when they ap- semistructured data is the lack of a succinct, mathemati- pear in the SELECT clause. cally clear, formal syntax and semantics by the vendors.
Load more

Recommended publications
  • Empirical Study on the Usage of Graph Query Languages in Open Source Java Projects
    Empirical Study on the Usage of Graph Query Languages in Open Source Java Projects Philipp Seifer Johannes Härtel Martin Leinberger University of Koblenz-Landau University of Koblenz-Landau University of Koblenz-Landau Software Languages Team Software Languages Team Institute WeST Koblenz, Germany Koblenz, Germany Koblenz, Germany [email protected] [email protected] [email protected] Ralf Lämmel Steffen Staab University of Koblenz-Landau University of Koblenz-Landau Software Languages Team Koblenz, Germany Koblenz, Germany University of Southampton [email protected] Southampton, United Kingdom [email protected] Abstract including project and domain specific ones. Common applica- Graph data models are interesting in various domains, in tion domains are management systems and data visualization part because of the intuitiveness and flexibility they offer tools. compared to relational models. Specialized query languages, CCS Concepts • General and reference → Empirical such as Cypher for property graphs or SPARQL for RDF, studies; • Information systems → Query languages; • facilitate their use. In this paper, we present an empirical Software and its engineering → Software libraries and study on the usage of graph-based query languages in open- repositories. source Java projects on GitHub. We investigate the usage of SPARQL, Cypher, Gremlin and GraphQL in terms of popular- Keywords Empirical Study, GitHub, Graphs, Query Lan- ity and their development over time. We select repositories guages, SPARQL, Cypher, Gremlin, GraphQL based on dependencies related to these technologies and ACM Reference Format: employ various popularity and source-code based filters and Philipp Seifer, Johannes Härtel, Martin Leinberger, Ralf Lämmel, ranking features for a targeted selection of projects.
    [Show full text]
  • Towards an Analytics Query Engine *
    Towards an Analytics Query Engine ∗ Nantia Makrynioti Vasilis Vassalos Athens University of Economics and Business Athens University of Economics and Business Athens, Greece Athens, Greece [email protected] [email protected] ABSTRACT with black box libraries, evaluating various algorithms for a This vision paper presents new challenges and opportuni- task and tuning their parameters, in order to produce an ef- ties in the area of distributed data analytics, at the core of fective model, is a time-consuming process. Things become which are data mining and machine learning. At first, we even more complicated when we want to leverage paralleliza- provide an overview of the current state of the art in the area tion on clusters of independent computers for processing big and then analyse two aspects of data analytics systems, se- data. Details concerning load balancing, scheduling or fault mantics and optimization. We argue that these aspects will tolerance can be quite overwhelming even for an experienced emerge as important issues for the data management com- software engineer. munity in the next years and propose promising research Research in the data management domain recently started directions for solving them. tackling the above issues by developing systems for large- scale analytics that aim at providing higher-level primitives for building data mining and machine learning algorithms, Keywords as well as hiding low-level details of distributed execution. Data analytics, Declarative machine learning, Distributed MapReduce [12] and Dryad [16] were the first frameworks processing that paved the way. However, these initial efforts suffered from low usability, as they offered expressive but at the same 1.
    [Show full text]
  • Graph Database for Collaborative Communities Rania Soussi, Marie-Aude Aufaure, Hajer Baazaoui
    Graph Database for Collaborative Communities Rania Soussi, Marie-Aude Aufaure, Hajer Baazaoui To cite this version: Rania Soussi, Marie-Aude Aufaure, Hajer Baazaoui. Graph Database for Collaborative Communities. Community-Built Databases, Springer, pp.205-234, 2011. hal-00708222 HAL Id: hal-00708222 https://hal.archives-ouvertes.fr/hal-00708222 Submitted on 14 Jun 2012 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Graph Database For collaborative Communities 1, 2 1 Rania Soussi , Marie-Aude Aufaure , Hajer Baazaoui2 1Ecole Centrale Paris, Applied Mathematics & Systems Laboratory (MAS), SAP Business Objects Academic Chair in Business Intelligence 2Riadi-GDL Laboratory, ENSI – Manouba University, Tunis Abstract Data manipulated in an enterprise context are structured data as well as un- structured data such as emails, documents, social networks, etc. Graphs are a natural way of representing and modeling such data in a unified manner (Structured, semi-structured and unstructured ones). The main advantage of such a structure relies in the dynamic aspect and the capability to represent relations, even multiple ones, between objects. Recent database research work shows a growing interest in the definition of graph models and languages to allow a natural way of handling data appearing.
    [Show full text]
  • E6895 Advanced Big Data Analytics Lecture 4: Data Store
    E6895 Advanced Big Data Analytics Lecture 4: Data Store Ching-Yung Lin, Ph.D. Adjunct Professor, Dept. of Electrical Engineering and Computer Science Chief Scientist, Graph Computing, IBM Watson Research Center E6895 Advanced Big Data Analytics — Lecture 4 © CY Lin, 2016 Columbia University Reference 2 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Spark SQL 3 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Spark SQL 4 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Apache Hive 5 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Using Hive to Create a Table 6 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Creating, Dropping, and Altering DBs in Apache Hive 7 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Another Hive Example 8 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Hive’s operation modes 9 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Using HiveQL for Spark SQL 10 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Hive Language Manual 11 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Using Spark SQL — Steps and Example 12 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Query testtweet.json Get it from Learning Spark Github ==> https://github.com/databricks/learning-spark/tree/master/files 13 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University SchemaRDD 14 E6895 Advanced Big Data Analytics – Lecture 4: Data Store © 2015 CY Lin, Columbia University Row Objects Row objects represent records inside SchemaRDDs, and are simply fixed-length arrays of fields.
    [Show full text]
  • Graphql Attack
    GRAPHQL ATTACK Date: 01/04/2021 Team: Sun* Cyber Security Research Agenda • What is this? • REST vs GraphQL • Basic Blocks • Query • Mutation • How to test What is the GraphQL? GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. GraphQL was developed internally by Facebook in 2012 before being publicly released in 2015. • Powerful & Flexible o Leaves most other decisions to the API designer o GraphQL offers no requirements for the network, authorization, or pagination. Sun * Cyber Security Team 1 REST vs GraphQL Over the past decade, REST has become the standard (yet a fuzzy one) for designing web APIs. It offers some great ideas, such as stateless servers and structured access to resources. However, REST APIs have shown to be too inflexible to keep up with the rapidly changing requirements of the clients that access them. GraphQL was developed to cope with the need for more flexibility and efficiency! It solves many of the shortcomings and inefficiencies that developers experience when interacting with REST APIs. REST GraphQL • Multi endpoint • Only 1 endpoint • Over fetching/Under fetching • Fetch only what you need • Coupling with front-end • API change do not affect front-end • Filter down the data • Strong schema and types • Perform waterfall requests for • Receive exactly what you ask for related data • No aggregating or filtering data • Aggregate the data yourself Sun * Cyber Security Team 2 Basic blocks Schemas and Types Sun * Cyber Security Team 3 Schemas and Types (2) GraphQL Query Sun * Cyber Security Team 4 Queries • Arguments: If the only thing we could do was traverse objects and their fields, GraphQL would already be a very useful language for data fetching.
    [Show full text]
  • Orchestrating Big Data Analysis Workflows in the Cloud: Research Challenges, Survey, and Future Directions
    00 Orchestrating Big Data Analysis Workflows in the Cloud: Research Challenges, Survey, and Future Directions MUTAZ BARIKA, University of Tasmania SAURABH GARG, University of Tasmania ALBERT Y. ZOMAYA, University of Sydney LIZHE WANG, China University of Geoscience (Wuhan) AAD VAN MOORSEL, Newcastle University RAJIV RANJAN, Chinese University of Geoscienes and Newcastle University Interest in processing big data has increased rapidly to gain insights that can transform businesses, government policies and research outcomes. This has led to advancement in communication, programming and processing technologies, including Cloud computing services and technologies such as Hadoop, Spark and Storm. This trend also affects the needs of analytical applications, which are no longer monolithic but composed of several individual analytical steps running in the form of a workflow. These Big Data Workflows are vastly different in nature from traditional workflows. Researchers arecurrently facing the challenge of how to orchestrate and manage the execution of such workflows. In this paper, we discuss in detail orchestration requirements of these workflows as well as the challenges in achieving these requirements. We alsosurvey current trends and research that supports orchestration of big data workflows and identify open research challenges to guide future developments in this area. CCS Concepts: • General and reference → Surveys and overviews; • Information systems → Data analytics; • Computer systems organization → Cloud computing; Additional Key Words and Phrases: Big Data, Cloud Computing, Workflow Orchestration, Requirements, Approaches ACM Reference format: Mutaz Barika, Saurabh Garg, Albert Y. Zomaya, Lizhe Wang, Aad van Moorsel, and Rajiv Ranjan. 2018. Orchestrating Big Data Analysis Workflows in the Cloud: Research Challenges, Survey, and Future Directions.
    [Show full text]
  • Evaluation of Xpath Queries on XML Streams with Networks of Early Nested Word Automata Tom Sebastian
    Evaluation of XPath Queries on XML Streams with Networks of Early Nested Word Automata Tom Sebastian To cite this version: Tom Sebastian. Evaluation of XPath Queries on XML Streams with Networks of Early Nested Word Automata. Databases [cs.DB]. Universite Lille 1, 2016. English. tel-01342511 HAL Id: tel-01342511 https://hal.inria.fr/tel-01342511 Submitted on 6 Jul 2016 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Universit´eLille 1 – Sciences et Technologies Innovimax Sarl Institut National de Recherche en Informatique et en Automatique Centre de Recherche en Informatique, Signal et Automatique de Lille These` pr´esent´ee en premi`ere version en vue d’obtenir le grade de Docteur par l’Universit´ede Lille 1 en sp´ecialit´eInformatique par Tom Sebastian Evaluation of XPath Queries on XML Streams with Networks of Early Nested Word Automata Th`ese soutenue le 17/06/2016 devant le jury compos´ede : Carlo Zaniolo University of California Rapporteur Anca Muscholl Universit´eBordeaux Rapporteur Kim Nguyen Universit´eParis-Sud Examinateur Remi Gilleron Universit´eLille 3 Pr´esident du Jury Joachim Niehren INRIA Directeur Abstract The eXtended Markup Language (Xml) provides a format for representing data trees, which is standardized by the W3C and largely used today for exchanging information between all kinds of computer programs.
    [Show full text]
  • Semantics Developer's Guide
    MarkLogic Server Semantic Graph Developer’s Guide 2 MarkLogic 10 May, 2019 Last Revised: 10.0-8, October, 2021 Copyright © 2021 MarkLogic Corporation. All rights reserved. MarkLogic Server MarkLogic 10—May, 2019 Semantic Graph Developer’s Guide—Page 2 MarkLogic Server Table of Contents Table of Contents Semantic Graph Developer’s Guide 1.0 Introduction to Semantic Graphs in MarkLogic ..........................................11 1.1 Terminology ..........................................................................................................12 1.2 Linked Open Data .................................................................................................13 1.3 RDF Implementation in MarkLogic .....................................................................14 1.3.1 Using RDF in MarkLogic .........................................................................15 1.3.1.1 Storing RDF Triples in MarkLogic ...........................................17 1.3.1.2 Querying Triples .......................................................................18 1.3.2 RDF Data Model .......................................................................................20 1.3.3 Blank Node Identifiers ..............................................................................21 1.3.4 RDF Datatypes ..........................................................................................21 1.3.5 IRIs and Prefixes .......................................................................................22 1.3.5.1 IRIs ............................................................................................22
    [Show full text]
  • Building Machine Learning Inference Pipelines at Scale
    Building Machine Learning inference pipelines at scale Julien Simon Global Evangelist, AI & Machine Learning @julsimon © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Problem statement • Real-life Machine Learning applications require more than a single model. • Data may need pre-processing: normalization, feature engineering, dimensionality reduction, etc. • Predictions may need post-processing: filtering, sorting, combining, etc. Our goal: build scalable ML pipelines with open source (Spark, Scikit-learn, XGBoost) and managed services (Amazon EMR, AWS Glue, Amazon SageMaker) © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Apache Spark https://spark.apache.org/ • Open-source, distributed processing system • In-memory caching and optimized execution for fast performance (typically 100x faster than Hadoop) • Batch processing, streaming analytics, machine learning, graph databases and ad hoc queries • API for Java, Scala, Python, R, and SQL • Available in Amazon EMR and AWS Glue © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. MLlib – Machine learning library https://spark.apache.org/docs/latest/ml-guide.html • Algorithms: classification, regression, clustering, collaborative filtering. • Featurization: feature extraction, transformation, dimensionality reduction. • Tools for constructing, evaluating and tuning pipelines • Transformer – a transform function that maps a DataFrame into a new
    [Show full text]
  • RDF Query Languages Need Support for Graph Properties
    RDF Query Languages Need Support for Graph Properties Renzo Angles1, Claudio Gutierrez1, and Jonathan Hayes1,2 1 Dept. of Computer Science, Universidad de Chile 2 Dept. of Computer Science, Technische Universit¨at Darmstadt, Germany {rangles,cgutierr,jhayes}@dcc.uchile.cl Abstract. This short paper discusses the need to include into RDF query languages the ability to directly query graph properties from RDF data. We study the support that current RDF query languages give to these features, to conclude that they are currently not supported. We propose a set of basic graph properties that should be added to RDF query languages and provide evidence for this view. 1 Introduction One of the main features of the Resource Description Framework (RDF) is its ability to interconnect information resources, resulting in a graph-like structure for which connectivity is a central notion [GLMB98]. As we will argue, basic concepts of graph theory such as degree, path, and diameter play an important role for applications that involve RDF querying. Considering the fact that the data model influences the set of operations that should be provided by a query language [HBEV04], it follows the need for graph operations support in RDF query languages. For example, the query “all relatives of degree 1 of Alice”, submitted to a genealogy database, amounts to retrieving the nodes adjacent to a resource. The query “are suspects A and B related?”, submitted to a police database, asks for any path connecting these resources in the (RDF) graph that is stored in this database. The query “what is the Erd˝osnumber of Alberto Mendelzon”, submitted to (a RDF version of) DBLP, asks simply for the length of the shortest path between the nodes representing Erd˝osand Mendelzon.
    [Show full text]
  • Evaluation of SPARQL Queries on Apache Flink
    applied sciences Article SPARQL2Flink: Evaluation of SPARQL Queries on Apache Flink Oscar Ceballos 1 , Carlos Alberto Ramírez Restrepo 2 , María Constanza Pabón 2 , Andres M. Castillo 1,* and Oscar Corcho 3 1 Escuela de Ingeniería de Sistemas y Computación, Universidad del Valle, Ciudad Universitaria Meléndez Calle 13 No. 100-00, Cali 760032, Colombia; [email protected] 2 Departamento de Electrónica y Ciencias de la Computación, Pontificia Universidad Javeriana Cali, Calle 18 No. 118-250, Cali 760031, Colombia; [email protected] (C.A.R.R.); [email protected] (M.C.P.) 3 Ontology Engineering Group, Universidad Politécnica de Madrid, Campus de Montegancedo, Boadilla del Monte, 28660 Madrid, Spain; ocorcho@fi.upm.es * Correspondence: [email protected] Abstract: Existing SPARQL query engines and triple stores are continuously improved to handle more massive datasets. Several approaches have been developed in this context proposing the storage and querying of RDF data in a distributed fashion, mainly using the MapReduce Programming Model and Hadoop-based ecosystems. New trends in Big Data technologies have also emerged (e.g., Apache Spark, Apache Flink); they use distributed in-memory processing and promise to deliver higher data processing performance. In this paper, we present a formal interpretation of some PACT transformations implemented in the Apache Flink DataSet API. We use this formalization to provide a mapping to translate a SPARQL query to a Flink program. The mapping was implemented in a prototype used to determine the correctness and performance of the solution. The source code of the Citation: Ceballos, O.; Ramírez project is available in Github under the MIT license.
    [Show full text]
  • Unravel Data Systems Version 4.5
    UNRAVEL DATA SYSTEMS VERSION 4.5 Component name Component version name License names jQuery 1.8.2 MIT License Apache Tomcat 5.5.23 Apache License 2.0 Tachyon Project POM 0.8.2 Apache License 2.0 Apache Directory LDAP API Model 1.0.0-M20 Apache License 2.0 apache/incubator-heron 0.16.5.1 Apache License 2.0 Maven Plugin API 3.0.4 Apache License 2.0 ApacheDS Authentication Interceptor 2.0.0-M15 Apache License 2.0 Apache Directory LDAP API Extras ACI 1.0.0-M20 Apache License 2.0 Apache HttpComponents Core 4.3.3 Apache License 2.0 Spark Project Tags 2.0.0-preview Apache License 2.0 Curator Testing 3.3.0 Apache License 2.0 Apache HttpComponents Core 4.4.5 Apache License 2.0 Apache Commons Daemon 1.0.15 Apache License 2.0 classworlds 2.4 Apache License 2.0 abego TreeLayout Core 1.0.1 BSD 3-clause "New" or "Revised" License jackson-core 2.8.6 Apache License 2.0 Lucene Join 6.6.1 Apache License 2.0 Apache Commons CLI 1.3-cloudera-pre-r1439998 Apache License 2.0 hive-apache 0.5 Apache License 2.0 scala-parser-combinators 1.0.4 BSD 3-clause "New" or "Revised" License com.springsource.javax.xml.bind 2.1.7 Common Development and Distribution License 1.0 SnakeYAML 1.15 Apache License 2.0 JUnit 4.12 Common Public License 1.0 ApacheDS Protocol Kerberos 2.0.0-M12 Apache License 2.0 Apache Groovy 2.4.6 Apache License 2.0 JGraphT - Core 1.2.0 (GNU Lesser General Public License v2.1 or later AND Eclipse Public License 1.0) chill-java 0.5.0 Apache License 2.0 Apache Commons Logging 1.2 Apache License 2.0 OpenCensus 0.12.3 Apache License 2.0 ApacheDS Protocol
    [Show full text]