Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

It's Time for a Single Property Graph Query Language [Vote Now]

DZone's Guide to

It's Time for a Single Property Graph Query Language [Vote Now]

Is it the right time for a single, standardized, graph-querying language? Find out how you can have your say in this post.

· Database Zone ·
Free Resource

Compliant Database DevOps and the role of DevSecOps DevOps is becoming the new normal in application development, and DevSecOps is now entering the picture. By balancing the desire to release code faster with the need for the same code to be secure, it addresses increasing demands for data privacy. But what about the database? How can databases be included in both DevOps and DevSecOps? What additional measures should be considered to achieve truly compliant database DevOps? This whitepaper provides a valuable insight. Get the whitepaper

The time has come to create a single, unified property graph query language.

Different languages for different products help no one. We've heard from the graph community that a common query language would be powerful: more developers with transferable expertise, portable queries, solutions that leverage multiple graph options, and less vendor lock-in.

One language, one skill set.

The Property Graph Space Has Grown...A Lot

Property graph technology has a big presence from Neo4j and SAP HANA to Oracle PGX and Amazon Neptune. An international standard would accelerate the entire graph solution market, to the mutual benefit of all vendors and — more importantly — to all users.

That's why we are proposing a unified graph query language, GQL (Graph Query Language), that fuses the best of three property graph languages.

Relational Data Has SQL, and Property Graphs Need GQL

Although SQL has been fundamental for relational data, we need a declarative query language for the powerful — and distinct — property graph data model to play a similar role.

Like SQL, the new GQL needs to be an industry standard. It should work with SQL but not be confined by SQL. The result would be better choices for developers, data engineers, data scientists, CIOs, and CDOs alike.

Right now, there are three property graph query languages that are closely related. We have Cypher (from Neo4j and the openCypher community), we have PGQL (from Oracle), and we have G-CORE, a research language proposal from the Linked Data Benchmark Council [LDBC] (co-authored by world-class researchers from the Netherlands, Germany, Chile, the U.S, and technical staff from SAP, Oracle, Capsenta, and Neo4j).

The proposed GQL (Graph Query Language) would combine the strengths of Cypher, PGQL, and G-CORE into one vendor-neutral and standardized query language for graph solutions, much like SQL is for RDBMS.

Each of these three query languages has similar data models, syntax, and semantics. Each has its merits and gaps, yet their authors share many ambitions for the next generation of graph queryings, such as a composable graph query language with graph construction, views, and named graphs; and a pattern-matching facility that extends to regular path queries.

Let Your Voice Be Heard on GQL

The Neo4j team is advocating that the database industry and our users collaborate to define and standardize one language.

Bringing PGQL, G-CORE, and Cypher together, we have a running start. Two of them are industrial languages with thousands of users, and combined with the enhancements of a research language, they all share a common heritage of ASCII art patterns to match, merge, and create graph models.

What matters most right now is a technically strong standard with strong backing among vendors and users. So we're appealing for your vocal support.

Please vote now on whether we should unite to create a standard Graph Query Language (GQL), in the same manner as SQL.

Should the property graph community unite to create a standard Graph Query Language, GQL, alongside SQL?

For more information, you can read the GQL manifesto here and watch for ongoing updates.

Emil Eifrem, CEO;
Philip Rathle, VP of Products;
Alastair Green, Lead, Query Languages Standards & Research;
for the entire Neo4j team

Compliant Database DevOps and the role of DevSecOps DevOps is becoming the new normal in application development, and DevSecOps is now entering the picture. By balancing the desire to release code faster with the need for the same code to be secure, it addresses increasing demands for data privacy. But what about the database? How can databases be included in both DevOps and DevSecOps? What additional measures should be considered to achieve truly compliant database DevOps? This whitepaper provides a valuable insight. Get the whitepaper

Topics:
neo4j ,graph database ,cypher ,query ,language ,standard ,databases ,database ,gql ,sql

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}