16 ms·

New Query Language for Graph Databases to Become International Standard

290 points by Anon84 7y ago

the_duke 7y ago
So, is there a draft spec yet? I can't find anything. Also, the name is of course justified, but it will be a mess to search for due to (Facebook) GraphQL.
- np_tedious 7y ago
  Also google has a query language for some of its Cloud data products with that name https://cloud.google.com/datastore/docs/reference/gql_reference https://cloud.google.com/datastore/docs/reference/gql_refere...
- sbarzowski 7y ago
  Seriously, people should not choose names which are already taken in the same general area of technology. Even if it "makes sense". The whole point of naming things is to refer to things more or less unambiguously.
- irrational 7y ago
  Is GQL already used elsewhere? As long as nobody calls it graphql we should be fine, right? Nobody says structured ql or even structured query language, its just sql.
  - nailer 7y ago
    I read the entire article and came away mistakenly thinking this was the same thing as GraphQL.
  - andyfleming 7y ago
    .gql extensions are already associated with GraphQL in some IDEs.
  - dragonwriter 7y ago
    > Is GQL already used elsewhere? GQL (for “Google Query Language”) is the SQL-like query language for Google Cloud Datastore, and has been around since it was just the App Engine datastore.
  - fuddle 7y ago
    Yes, it's used by a lot of GraphQl libraries: graphql-python/gql: A GraphQL client in Python graphql-python/gql-next: A Python GraphQL Client grooviter/gql: Groovy GraphQL library 99designs/gqlgen: go generate based graphql server
- dragonwriter 7y ago
  > Also, the name is of course justified, but it will be a mess to search for due to (Facebook) GraphQL. Google's GQL [0], which is older than either, doesn't help the searchability, either. [0] https://cloud.google.com/datastore/docs/reference/gql_reference https://cloud.google.com/datastore/docs/reference/gql_refere...
- b3tt3rw0rs3 7y ago
  The GQL project just started. Since it is going to be an ISO standard, the specification is only available for members while under development but may be purchased from ISO once final (Same as for SQL, though you can find copies on the internet). GQL will be a declarative language in the spirit of existing property graph query languages like Cypher, so that gives you an idea. I'm sure as the project proceeds, various artefacts (software or otherwise) will become freely available. If you want to dig deeper, gqlstandards.org links to some documents that are copyright Neo4j and have been submitted to the standards process. https://drive.google.com/drive/folders/16CUhVI1PQ4hBlhD80_YsY4WoRpBS24wK https://drive.google.com/drive/folders/16CUhVI1PQ4hBlhD80_Ys...
  - xpe 7y ago
    "Purchased"? Really? Hmmm. However, ISO does have a store that prominently features "best selling standards": https://www.iso.org/store.html https://www.iso.org/store.html
    - woodrowbarlow 7y ago
      that's nothing new. draft versions are usually released for free, but the final ISO standards have always required fees for access and the copyright for the documents belongs to ISO. a standard for the C programming language, for example, will run about $200. average developers don't usually need access to the standard, as they will be working with an implementation of the standard anyway (which should be providing its own documentation).
      - b3tt3rw0rs3 7y ago
        Many standards are also available via the national standards body of your locale (e.g. ANSI), often at a cheaper rate.
- olefoo 7y ago
  https://s3.amazonaws.com/artifacts.opencypher.org/M14/railroad/Cypher.html https://s3.amazonaws.com/artifacts.opencypher.org/M14/railro... See http://www.opencypher.org/resources http://www.opencypher.org/resources for more.
  - ummonk 7y ago
    Is GQL a new name for Cypher?
    - johnymontana 7y ago
      Sort of. ISO GQL is largely about taking the best ideas from Cypher (and other graph query languages) into a language overseen by an international standards body backed by multiple companies and implementations.
- WhitneyLand 7y ago
  Can we have a search uniqueness tag, like 'GQL19'? We have search terms, meta data keywords, urls, but no short optimized for humans search uniqueness tag? Seems like there should be some standard or convention at least, given it could be opt-in. It would help any site or content that referenced the tag and anything that didn't would still work as well as usual.
  - b3tt3rw0rs3 7y ago
    Just say ISO GQL
- baddox 7y ago
  Or even a single code sample? It sounds like they've decided simply that "the international standard will be called 'GQL'" but they have no idea what the language will be (or they're keeping it a secret, which would be even more troubling).
tannhaeuser 7y ago
There is an ISO-standardized graph query language: Prolog and its decidable fragment Datalog, both widely used (relatively) for decades. Will the new language be based on it? Another question is whether the model having driven ISO standardization in the past (software vendors working together to create a large, visible, and diverse market) is still relevant in post-standard cloud times. I sure hope it is, but we haven't seen public demand for standards (with the exception of web standards) for well over a decade now.
- deleted 7y ago
  [deleted]
- jrumbut 7y ago
  I think the cloud times renews the need for standards. Ten years ago devs in the linux/BSD world had the vast majority of the code that would make up our stack, from OS kernel to the front end (with perhaps some proprietary driver or external API call here or there). The code was the standard, which traded easy readability for complete accuracy and transparency.
  - tannhaeuser 7y ago
    > The code was the standard That's emphatically not what a standard is about. Standards in the field you described were developed over many years by proprietary Unix vendors (including BSD as descendents of the original TCP/IP stack), enshrined in POSIX/SUS (also published as Open Group and ISO standards), and then implemented on Linux. Apart from early RedHat stuff such as PAM and things like LSB, it is only since about 2005 or so that Linux dominates the market by de-facto implementations rather than standards (such as bash, Docker-style containers based on Linux namespaces, etc.)
    - jrumbut 7y ago
      Of course that's not what a standard is about, but I believe it's what happened for technologies during the time that standards fell off. I identified 2009 as about when you expected de facto open source implementations instead of any talk of standards but I would buy 2005 as well. Obviously it's a fuzzy boundary.
rambojazz 7y ago
What's wrong with SPARQL? What advantages has this over SPARQL?
- smitty1e 7y ago
  SPARQL suffers from Not Invented Here Syndrome.
- waffle_ss 7y ago
  SPARQL is for RDF data, which not every graph database conforms to.
  - namedgraph 7y ago
    And every graph database conforms to Cypher or GQL? These are not even standards, ar least yet.
- amirouche 7y ago
  SPARQL doesn't allow unbound recursive queries.
- baq 7y ago
  i can read Cypher having almost zero experience with it, i have no idea what a slightly-more-than-trivial SPARQL query does.
- moxious 7y ago
  SPARQL is purpose built for the RDF world where you're mixing and matching a zillion different vocabularies, all of which have to be painstakingly declared and name spaced every time. For most of us working not on the "semantic web", we typically only have 1-2 vocabularies, which is our data model, and SPARQL is super clunky to use.
  - staticassertion 7y ago
    I don't suppose you could give me an example that demonstrates the clunkiness? I have not worked with SPARQL myself, but I'm very curious as someone who's been leveraging a graph database (dgraph)
mehrdadn 7y ago
I'm rather uninitiated on this... what's the difference between a graph database and a traditional relational database that makes them need different query languages?
- pcl 7y ago
  SQL generally doesn't have primitives that let you traverse arbitrary relationships. You can join multiple tables together, but the nature of those relationships is expressed directly in the SQL statement you're writing. Some RDBs provide extensions to the SQL standard to do some basic graph traversals (Oracle's CONNECT BY, for example), but these are just the most-basic sorts of graph traversals. In a graph database, the primary notions are nodes and edges and properties associated with them, whereas in a relational database, the primary notions are tables (aka "relations"), foreign keys that allow you to connect together multiple tables, and rows in those tables. Those differences in primary notions surface in the query languages as well.
  - mehrdadn 7y ago
    Thanks for the response. I'm having trouble seeing what kinds of queries come up of this nature that SQL wouldn't be fit for, though. What would be an example of a realistic graph query one would want to do that would be too difficult to do in SQL?
    - zaphar 7y ago
      Graphs have arbitrary depth. As a result some queries need an unknown number of joins on an unknown number of keys. Representing this in just SQL would be impossible. You could do it in a stored procedure but that is a superset of SQL not vanilla SQL. You can also do it by just making the SQL calls over and over in your code as you get each row but that's not going to be very optimized.
      - deleted 7y ago
        [deleted]
    - 7y ago
sandGorgon 7y ago
why did Tinkerpop's Gremlin not work out ? anyone has a summary of the discussion from a language design perspective ? A lot of the Google-able references talk about how Gremlin is more optimizable than Cypher, etc.
- deleted 7y ago
  [deleted]
- amirouche 7y ago
  Gremlin traversal language is a piece of a complete database query as run by TinkerPop's Rexster database. You can see it as a lazy sequence or stream API (think srfi-41 or r7rs scheme generators) with sugar syntax optimized for property graphs. To take complete advantage of TinkerPop Rexster you really need to embed the Gremlin DSL inside a Turing Complete language (like groovy) and execute that. I think Gremlin failed because a) the similar look to SQL of cypher queries b) long running and massive marketing campaign by the company behind cypher. c) since tinkerpop developers were hired by the company behind Cassandra, tinkerpop (and Janus graph) have lost momentum. All this narrow data expert systems that persist data on-disk (!) are doomed to fail! The future is ordered key-value store and multi-model databases with ACID transactions.
- maxdemarzi 7y ago
  Gremlin was written by a genius level developer to be used by other genius level developers. There are maybe a handful of Gremlin experts in the entire world and less than 100 that are any good at it. It is extremely powerful, but after a few lines, the mental acrobatics needed to understand what the query does is beyond your average developer. My first paid Neo4j gig 7 years ago was writing a rules engine in gremlin. It was about 25 lines of code. If you were to ask me today what each of those lines did, I would be at a loss. So would anyone who didn't live in those specific queries day in and day out. Graph adoption was severely limited by its use. Cypher can be learned in a day, and "business people" can look at a cypher query and understand what is going on for the most part. It takes about a week to "bolt on" Gremlin to any database. I've done it myself, that's why you see it so often. It takes months to be any good at it.
blumomo 7y ago
That's quiet an unfortunate name clash with the existing GraphQL language in a similar domain.
- gizmo385 7y ago
  I think GQL from Neo4J has been around for quite a while before GraphQL.
  - dragonwriter 7y ago
    > I think GQL from Neo4J has been around for quite a while before GraphQL. Cypher has been, GQL has not. GQL from Google has, but that's another problem with the (EDIT: naming of the) new GQL.
    - b3tt3rw0rs3 7y ago
      How would you think anyone should call a graph query language done by the SQL committee?
      - dragonwriter 7y ago
        SGQL? SQL-GRAPH? G? Or, heck, Cypher (with SQL itself, and most other languages, ISO didn't change the name even though the spec they adopted didn't necessarily exactly match what existed previously, they kept the name of the existing language they were standardizing.)
pcr910303 7y ago
Hmm... There's this big, great, 'perfect', heavyweight graph query language (GQL) that is on process of standardized while an alternative (GraphQL) language is more readable (much more lightweight syntax IMO), has gained much more traction, etc... While GQL and GraphQL's target is different(one is for interacting with Graph DBs while the other one is interacting with backends), there is a lot of overlap ongoing, and I just can't erase the feeling of the overlap between XML & JSON (where while XML was more 'perfect', JSON won the war). Edit: Ok, GraphQL is insufficient for GraphDB Querying. Thanks for everyone's clarification.
- the_mitsuhiko 7y ago
  > while an alternative (GraphQL) language is more readable It's also entirely insufficient. GraphQL is nice to query APIs but almost pointless to query databases unless you map an entire DSL on top of it.
- SuperFerret 7y ago
  GraphQL has nothing to do with graph databases.
  - pcr910303 7y ago
    Why? GraphQL is about modeling business domain objects in graphs [0] and querying them. Isn't that basically what Graph DB languages do too? [0] https://graphql.org/learn/thinking-in-graphs/ https://graphql.org/learn/thinking-in-graphs/
    - frant-hartm 7y ago
      It is a query language for APIs, name like RestQL or JsonQL would be much more suitable. The expressiveness of GraphQL is severely limited, it doesn't allow you to express even simple patterns like triangles, depth n, paths etc..
  - AzzieElbab 7y ago
    aside from google search results for GQL :)
vkhn 7y ago
oh good, I wonder if they realize developers frequently refer to GraphQL as gql.
sickcodebruh 7y ago
I spent many years working on a Neo4j Ruby gem and really grew to love Cypher, their query language. I always found it phenomenally expressive, one of those things that seems simple (almost trivial) at first but was extremely flexible and powerful when you needed more from it. It's highly readable, easy to teach, and intuitive in a way that I never found SQL to be. It's been years since I've worked with the product and while I don't miss Neo4j, I do miss the query language. It's a little unclear to me how GQL will incorporate Cypher but I hope the initiative is successful if for no other reason than a selfish one: I'd love Cypher to be around if I ever wind up using a GraphDB again.
- vosper 7y ago
  > It's been years since I've worked with the product and while I don't miss Neo4j, I do miss the query language Would you mind expanding on what you don't miss about Neo4j?
  - sickcodebruh 7y ago
    I was trying to use it instead of Postgres as a general database and it just didn't shine in that role. The value proposition made sense on paper: it's a more natural way to reason about data than RDBMS, relationships as first-class citizens offer some really great benefits, avoiding the schema seems reasonable when the rest of your stack is dynamic, Cypher is more pleasant than SQL. While some of that might be true, I encountered the following: - Using a somewhat esoteric database increased my devops responsibilities. - Open source license didn't allow hot backups. - Ruby is just slow. I was using it before the binary protocol was implemented so performance was often lousy compared to Postgres. - Writes were slow. Neo4j seemed to excel at reads and, in particular, the kinds of reads that are best handled by a graph. Shocking, I know. - I really didn't have enough data or the need for the kinds of queries that would really let it shine. - A big part of the culture at meetups and tutorials was based on "DON'T YOU JUST HATE JOINS!?" It felt culty. I was a big part of that problem for a long time. The last meetup I went to just felt like people bashing Postgres. So I think that a lot of the things that I don't miss are because I wasn't right for it, I should have just been using Postgres. All that said, there was so much about it to love. Cypher, as already mentioned. While the culture at meetups might have kind of relied on bashing SQL and RDBMS, the company itself was full of brilliant, generous, creative, wonderful people. Their CEO (Emil) in particular is a total sweetheart. The organization was extremely supportive of open source projects, very inclusive, very eager to get people involved, and it made a big impact on me. So, again, while Postgres is the tool I always reach for first, I think that Neo4j as an organization does great work and as a product has a lot to offer if you're the right fit for it. I'm glad to see they're doing well.
RocketSyntax 7y ago
So will neo4j switch to gql? and will spark support switch to gql?
- johnymontana 7y ago
  Yup, you can think of ISO GQL as the future of Cypher.
The_rationalist 7y ago
Neo4j would become the standard while being far less used than Gremlin? This is nonsense isn't it?
- maxdemarzi 7y ago
  Neo4j is by far used more than any other graph database out there. Regardless, the standard is not Neo4j specific. It was a collaboration from many companies in the space. They all agree it's a good move.
  - The_rationalist 7y ago
    Well I've no statistics about tinkerpop vs neo4j and other usage, I may be wrong. But I know for sure that far more graph databases supports gremlin than supports opencypher. E.g the latest graph database from Microsoft https://docs.microsoft.com/fr-fr/azure/cosmos-db/graph-introduction https://docs.microsoft.com/fr-fr/azure/cosmos-db/graph-intro... Also, Cypher has performance and expressivity issues.
    - b3tt3rw0rs3 7y ago
      Just looking at https://db-engines.com/en/ranking/graph+dbms https://db-engines.com/en/ranking/graph+dbms clearly shows Neo4j as the most prominent graph db. I think even Cosmos as number 2 might be misleading here, as Cosmos is a multi-model product and db engines doesn't distinguish between graph and non-graph use in the ranking. (Same for ArangoDB)
    - hobofan 7y ago
      > E.g the latest graph database from Microsoft As a contrast, the recently introduced RedisGraph only supports Cypher.
westurner 7y ago
Graph query languages are nice and all, but what about Linked Data here? Queries of schemaless graphs miss lots of data because without a schema this graph calls it "color" and that graph calls it "colour" and that graph calls it "色" or "カラー". (Of course this is also an issue even when there is a defined schema; but it's hardly possible to just happen to have comprehensible inter or even intra-organizational cohesion without e.g. RDFS and/or OWL and/or SHACL for describing (and changing) the shape of the data) So, the task is then to compile schema-aware SPARQL to GQL or GraphQL or SQL or interminable recursive SQL queries or whatever it is. For GraphQL, there's GraphQL-LD (which somewhat unfortunately contains a hashtag-indeterminate dash). I cite this in full here because it's very relevant to the GQL task at hand: "GraphQL-LD: Linked Data Querying with GraphQL" (2018) https://comunica.github.io/Article-ISWC2018-Demo-GraphQlLD/ https://comunica.github.io/Article-ISWC2018-Demo-GraphQlLD/ > GraphQL is a query language that has proven to be a popular among developers. In 2015, the GraphQL framework [3] was introduced by Facebook as an alternative way of querying data through interfaces. Since then, GraphQL has been gaining increasing attention among developers, partly due to its simplicity in usage, and its large collection of supporting tools. One major disadvantage of GraphQL compared to SPARQL is the fact that it has no notion of semantics, i.e., it requires an interface-specific schema. This therefore makes it difficult to combine GraphQL data that originates from different sources. This is then further complicated by the fact that GraphQL has no notion of global identifiers, which is possible in RDF through the use of URIs. Furthermore, GraphQL is however not as expressive as SPARQL, as GraphQL queries represent trees [4], and not full graphs as in SPARQL. > In this work, we introduce GraphQL-LD, an approach for extending GraphQL queries with a JSON-LD context [5], so that they can be used to evaluate queries over RDF data. This results in a query language that is less expressive than SPARQL, but can still achieve many of the typical data retrieval tasks in applications. Our approach consists of an algorithm that translates GraphQL-LD queries to SPARQL algebra [6]. This allows such queries to be used as an alternative input to SPARQL engines, and thereby opens up the world of RDF data to the large amount of people that already know GraphQL. Furthermore, results can be translated into the GraphQL-prescribed shapes. The only additional requirement is their queries would now also need a JSON-LD context, which could be provided by external domain experts. > In related work, HyperGraphQL [7] was introduced as a way to expose access to RDF sources through GraphQL queries and emit results as JSON-LD. The difference with our approach is that HyperGraphQL requires a service to be set up that acts as a intermediary between the GraphQL client and the RDF sources. Instead, our approach enables agents to directly query RDF sources by translating GraphQL queries client-side. All of these RDFS vocabularies and OWL ontologies provide structure that minimizes the costs of merging and/or querying multiple datasets: https://lov.linkeddata.es/dataset/lov/ https://lov.linkeddata.es/dataset/lov/ All of these schema.org/Dataset s in the "Linked Open Data Cloud" are easier to query than a schemaless graph: https://lod-cloud.net/ https://lod-cloud.net/ . Though one can query schemaless graphs with SPARQL, as well. For reference, RDFLib has a bunch of RDF graph implementations over various key/value and SQL store backends. RDFLib-sqlachemy does query parametrization correctly in order to minimize the risk of query injection. FOR THE RECORD, SQL Injection is the CWE Top 25 #1 most prevalent security weakness; which is something that any new spec and implementation should really consider before launching anything other than an e.g. overly-verbose JSON-based query language that people end up bolting a micro-DSL onto. https://github.com/RDFLib/rdflib-sqlalchemy https://github.com/RDFLib/rdflib-sqlalchemy Most practically, I frequently want to read a graph of objects into RAM; update, extend, and interlink; and then transactionally save the delta back to the store. This requires a few things: (1) an efficient binary serialization protocol like Apache Arrow (SIMD), Parquet, or any of the BSON binary JSONs; (2) a transactional local store that can be manually synchronized with the remote store until it's consistent. SPARQL Update was somewhat of an out-of-scope afterthought. Here's SPARQL 1.1 Update: https://www.w3.org/TR/sparql11-update/ https://www.w3.org/TR/sparql11-update/ Here's SOLID, which could be implemented with SPARQL on GQL, too; though all the re-serialization really shouldn't be necessary for EAV triples with a named graph URI identifier: https://solidproject.org/ https://solidproject.org/ 5 star data: PDF -> XLS -> CSV -> RDF (GQL, AFAIU (but with no URIs(!?))) -> LOD https://5stardata.info/en/ https://5stardata.info/en/
maitredusoi 7y ago
Anyone know the difference with ArangoDB's AQL ? (I haven't use neo4j as I use ArangoDB)
- b3tt3rw0rs3 7y ago
  AQL is a vendor-specific multi model language that lately has picked up some ideas from openCypher, like pattern matching. GQL is a project for creating an International Standard language in the process of being created by experts from many countries that represent the interests of multiple vendors.
- pluma 7y ago
  I haven't had a look at GQL yet but the obvious one would likely be that as ArangoDB aims to support native multi-model, AQL is not just a graph querying language. Graph databases generally only consider edges between vertices (identified by IDs) and those edges typically only have a handful of attributes. In ArangoDB edges and vertices are stored as documents, so they can be represented as arbitrary JSON objects. So if you want to work with a mix of data or want to access your data in different ways, I wouldn't expect GQL to support that whereas with AQL you can mix and match your queries even within the same request. Full disclosure: I'm an external contributor to ArangoDB but this is my personal take.
The_rationalist 7y ago
What advantages/limitations does it have compared to SHACL? https://en.m.wikipedia.org/wiki/SHACL https://en.m.wikipedia.org/wiki/SHACL
paul009 7y ago
Isn't xquery basically a graph query language similar to GraphQL? If so, why are we not using xquery to query objects and sub-objects?
- lmkg 7y ago
  I'm not familiar with xquery, does it handle general graphs or only DAGs? Your mention of "objects and sub-objects" makes me think you're expecting a different use-case than actual graph databases, which deals more with peer-to-peer connections (like knowledge graphs) than hierarchical models.
- namedgraph 7y ago
  XQuery is for the XML data model, which is a tree and not a graph.
Vaslo 7y ago
So if I want to learn this GQL, where do I even start? I'm also confused about the naming, is there more than one language that could be called GQL?
- johnymontana 7y ago
  While the ISO GQL standards draft is being prepared, the best way for a developer to learn and prepare for ISO GQL is to learn the Cypher query language.[1] Many of the concepts from Cypher will be carried over into ISO GQL. [1]: https://neo4j.com/developer/cypher-basics-i/ https://neo4j.com/developer/cypher-basics-i/
lpghatguy 7y ago
Should GQL be pronounced with a hard or soft G? Is "geequel" going to take off akin to "sequel" for SQL?
peterwwillis 7y ago
Huh. Now if only we could do this for configuration management, service mapping/scheduling/coordination, resource allocation, monitoring, alerting, logging, access control, artifact packaging, and execution pipelines.
okram 7y ago
There is something really special about the graph database space. For as long as the space has been around (15 or so years), every vendor and dedicated practitioner has taken solid jabs at trying to realize "the best way" to think about graph traversals. This behavior seems particular to the graph space (vs. document, wide-column, relational, key/value, etc.). While this speaks to the complexity of the type of problems you can solve with graphs, thinking back, I believe this was a cultural anomaly. When it was Neo4j, OrientDB, TinkerPop: the language trifurcation occurred. I'm excited that Neo4j is continuing to take the query language seriously. In an age when software development is about making it easy for the 90% of developers out there with REST APIs, GraphQL, and overly SQL'd embeddings, ... graph is still searching for "that best way." I, personally, have moved on from language-level. However, our new work is going to help my fellow data system colleagues get there languages exposed to as many developers as possible regardless of data model. It is important to me that people can come to respect the numerous ways in which we think about data and has the language we use is so important. The difference between living in Plato's Cave or not. In an effort to support query languages in general, I'll be working on mm-ADT designing a new cluster-oriented virtual machine architecture for storage, processing, and query language developers. I see a veritable Tower of Babel on the horizon! Congrats Neo4j on reaping the benefits of your hard work. I hope our work will converge in for a positive collaboration in 2020.
- namedgraph 7y ago
  For some reason you neglect to mention RDF graph data model and its SPARQL query language, which have been W3C standards since 1997 and 2008, respectively. They have a healthy ecosystem of both open-source and commercial software, and unlike property graphs were designed with data interchange in mind from the outset. SPARQL was the first and still is the only standard NoSQL query language.
  - okram 7y ago
    It just wasn't "the scene" at the time. RDF/SPARQL had its world -- permeated throughout academia and some enterprise deployments with quad/triple-stores like AllegroGraph. But it wasn't going to make a PoW in the software industry because they didn't ride the razor-edge well enough. OWL was a foolish mistake. Triple is a clean and simple idea, but in practice -- reification and URI character hell becoming mind numbing. The RDF-guys did nail it with SPARQL. That is such a pretty query language. Simple, intuitive. I haven't studied the recent path expression advances. I should. But yea, lots of ways of fugglin' with the data.

290 points by Anon84 7y ago

So, is there a draft spec yet? I can't find anything. Also, the name is of course justified, but it will be a mess to search for due to (Facebook) GraphQL.

np_tedious 7y ago
Also google has a query language for some of its Cloud data products with that name https://cloud.google.com/datastore/docs/reference/gql_reference https://cloud.google.com/datastore/docs/reference/gql_refere...
sbarzowski 7y ago
Seriously, people should not choose names which are already taken in the same general area of technology. Even if it "makes sense". The whole point of naming things is to refer to things more or less unambiguously.
irrational 7y ago
Is GQL already used elsewhere? As long as nobody calls it graphql we should be fine, right? Nobody says structured ql or even structured query language, its just sql.
- nailer 7y ago
  I read the entire article and came away mistakenly thinking this was the same thing as GraphQL.
- andyfleming 7y ago
  .gql extensions are already associated with GraphQL in some IDEs.
- dragonwriter 7y ago
  > Is GQL already used elsewhere? GQL (for “Google Query Language”) is the SQL-like query language for Google Cloud Datastore, and has been around since it was just the App Engine datastore.
- fuddle 7y ago
  Yes, it's used by a lot of GraphQl libraries: graphql-python/gql: A GraphQL client in Python graphql-python/gql-next: A Python GraphQL Client grooviter/gql: Groovy GraphQL library 99designs/gqlgen: go generate based graphql server
dragonwriter 7y ago
> Also, the name is of course justified, but it will be a mess to search for due to (Facebook) GraphQL. Google's GQL [0], which is older than either, doesn't help the searchability, either. [0] https://cloud.google.com/datastore/docs/reference/gql_reference https://cloud.google.com/datastore/docs/reference/gql_refere...
b3tt3rw0rs3 7y ago
The GQL project just started. Since it is going to be an ISO standard, the specification is only available for members while under development but may be purchased from ISO once final (Same as for SQL, though you can find copies on the internet). GQL will be a declarative language in the spirit of existing property graph query languages like Cypher, so that gives you an idea. I'm sure as the project proceeds, various artefacts (software or otherwise) will become freely available. If you want to dig deeper, gqlstandards.org links to some documents that are copyright Neo4j and have been submitted to the standards process. https://drive.google.com/drive/folders/16CUhVI1PQ4hBlhD80_YsY4WoRpBS24wK https://drive.google.com/drive/folders/16CUhVI1PQ4hBlhD80_Ys...
- xpe 7y ago
  "Purchased"? Really? Hmmm. However, ISO does have a store that prominently features "best selling standards": https://www.iso.org/store.html https://www.iso.org/store.html
  - woodrowbarlow 7y ago
    that's nothing new. draft versions are usually released for free, but the final ISO standards have always required fees for access and the copyright for the documents belongs to ISO. a standard for the C programming language, for example, will run about $200. average developers don't usually need access to the standard, as they will be working with an implementation of the standard anyway (which should be providing its own documentation).
    - b3tt3rw0rs3 7y ago
      Many standards are also available via the national standards body of your locale (e.g. ANSI), often at a cheaper rate.
olefoo 7y ago
https://s3.amazonaws.com/artifacts.opencypher.org/M14/railroad/Cypher.html https://s3.amazonaws.com/artifacts.opencypher.org/M14/railro... See http://www.opencypher.org/resources http://www.opencypher.org/resources for more.
- ummonk 7y ago
  Is GQL a new name for Cypher?
  - johnymontana 7y ago
    Sort of. ISO GQL is largely about taking the best ideas from Cypher (and other graph query languages) into a language overseen by an international standards body backed by multiple companies and implementations.
WhitneyLand 7y ago
Can we have a search uniqueness tag, like 'GQL19'? We have search terms, meta data keywords, urls, but no short optimized for humans search uniqueness tag? Seems like there should be some standard or convention at least, given it could be opt-in. It would help any site or content that referenced the tag and anything that didn't would still work as well as usual.
- b3tt3rw0rs3 7y ago
  Just say ISO GQL
baddox 7y ago
Or even a single code sample? It sounds like they've decided simply that "the international standard will be called 'GQL'" but they have no idea what the language will be (or they're keeping it a secret, which would be even more troubling).

tannhaeuser 7y ago

There is an ISO-standardized graph query language: Prolog and its decidable fragment Datalog, both widely used (relatively) for decades. Will the new language be based on it? Another question is whether the model having driven ISO standardization in the past (software vendors working together to create a large, visible, and diverse market) is still relevant in post-standard cloud times. I sure hope it is, but we haven't seen public demand for standards (with the exception of web standards) for well over a decade now.

deleted 7y ago
[deleted]
jrumbut 7y ago
I think the cloud times renews the need for standards. Ten years ago devs in the linux/BSD world had the vast majority of the code that would make up our stack, from OS kernel to the front end (with perhaps some proprietary driver or external API call here or there). The code was the standard, which traded easy readability for complete accuracy and transparency.
- tannhaeuser 7y ago
  > The code was the standard That's emphatically not what a standard is about. Standards in the field you described were developed over many years by proprietary Unix vendors (including BSD as descendents of the original TCP/IP stack), enshrined in POSIX/SUS (also published as Open Group and ISO standards), and then implemented on Linux. Apart from early RedHat stuff such as PAM and things like LSB, it is only since about 2005 or so that Linux dominates the market by de-facto implementations rather than standards (such as bash, Docker-style containers based on Linux namespaces, etc.)
  - jrumbut 7y ago
    Of course that's not what a standard is about, but I believe it's what happened for technologies during the time that standards fell off. I identified 2009 as about when you expected de facto open source implementations instead of any talk of standards but I would buy 2005 as well. Obviously it's a fuzzy boundary.

rambojazz 7y ago

What's wrong with SPARQL? What advantages has this over SPARQL?

smitty1e 7y ago
SPARQL suffers from Not Invented Here Syndrome.
waffle_ss 7y ago
SPARQL is for RDF data, which not every graph database conforms to.
- namedgraph 7y ago
  And every graph database conforms to Cypher or GQL? These are not even standards, ar least yet.
amirouche 7y ago
SPARQL doesn't allow unbound recursive queries.
baq 7y ago
i can read Cypher having almost zero experience with it, i have no idea what a slightly-more-than-trivial SPARQL query does.
moxious 7y ago
SPARQL is purpose built for the RDF world where you're mixing and matching a zillion different vocabularies, all of which have to be painstakingly declared and name spaced every time. For most of us working not on the "semantic web", we typically only have 1-2 vocabularies, which is our data model, and SPARQL is super clunky to use.
- staticassertion 7y ago
  I don't suppose you could give me an example that demonstrates the clunkiness? I have not worked with SPARQL myself, but I'm very curious as someone who's been leveraging a graph database (dgraph)

mehrdadn 7y ago

I'm rather uninitiated on this... what's the difference between a graph database and a traditional relational database that makes them need different query languages?

pcl 7y ago
SQL generally doesn't have primitives that let you traverse arbitrary relationships. You can join multiple tables together, but the nature of those relationships is expressed directly in the SQL statement you're writing. Some RDBs provide extensions to the SQL standard to do some basic graph traversals (Oracle's CONNECT BY, for example), but these are just the most-basic sorts of graph traversals. In a graph database, the primary notions are nodes and edges and properties associated with them, whereas in a relational database, the primary notions are tables (aka "relations"), foreign keys that allow you to connect together multiple tables, and rows in those tables. Those differences in primary notions surface in the query languages as well.
- mehrdadn 7y ago
  Thanks for the response. I'm having trouble seeing what kinds of queries come up of this nature that SQL wouldn't be fit for, though. What would be an example of a realistic graph query one would want to do that would be too difficult to do in SQL?
  - zaphar 7y ago
    Graphs have arbitrary depth. As a result some queries need an unknown number of joins on an unknown number of keys. Representing this in just SQL would be impossible. You could do it in a stored procedure but that is a superset of SQL not vanilla SQL. You can also do it by just making the SQL calls over and over in your code as you get each row but that's not going to be very optimized.
    - deleted 7y ago
      [deleted]
  - 7y ago

sandGorgon 7y ago

why did Tinkerpop's Gremlin not work out ? anyone has a summary of the discussion from a language design perspective ? A lot of the Google-able references talk about how Gremlin is more optimizable than Cypher, etc.

deleted 7y ago
[deleted]
amirouche 7y ago
Gremlin traversal language is a piece of a complete database query as run by TinkerPop's Rexster database. You can see it as a lazy sequence or stream API (think srfi-41 or r7rs scheme generators) with sugar syntax optimized for property graphs. To take complete advantage of TinkerPop Rexster you really need to embed the Gremlin DSL inside a Turing Complete language (like groovy) and execute that. I think Gremlin failed because a) the similar look to SQL of cypher queries b) long running and massive marketing campaign by the company behind cypher. c) since tinkerpop developers were hired by the company behind Cassandra, tinkerpop (and Janus graph) have lost momentum. All this narrow data expert systems that persist data on-disk (!) are doomed to fail! The future is ordered key-value store and multi-model databases with ACID transactions.
maxdemarzi 7y ago
Gremlin was written by a genius level developer to be used by other genius level developers. There are maybe a handful of Gremlin experts in the entire world and less than 100 that are any good at it. It is extremely powerful, but after a few lines, the mental acrobatics needed to understand what the query does is beyond your average developer. My first paid Neo4j gig 7 years ago was writing a rules engine in gremlin. It was about 25 lines of code. If you were to ask me today what each of those lines did, I would be at a loss. So would anyone who didn't live in those specific queries day in and day out. Graph adoption was severely limited by its use. Cypher can be learned in a day, and "business people" can look at a cypher query and understand what is going on for the most part. It takes about a week to "bolt on" Gremlin to any database. I've done it myself, that's why you see it so often. It takes months to be any good at it.

blumomo 7y ago

That's quiet an unfortunate name clash with the existing GraphQL language in a similar domain.

gizmo385 7y ago
I think GQL from Neo4J has been around for quite a while before GraphQL.
- dragonwriter 7y ago
  > I think GQL from Neo4J has been around for quite a while before GraphQL. Cypher has been, GQL has not. GQL from Google has, but that's another problem with the (EDIT: naming of the) new GQL.
  - b3tt3rw0rs3 7y ago
    How would you think anyone should call a graph query language done by the SQL committee?
    - dragonwriter 7y ago
      SGQL? SQL-GRAPH? G? Or, heck, Cypher (with SQL itself, and most other languages, ISO didn't change the name even though the spec they adopted didn't necessarily exactly match what existed previously, they kept the name of the existing language they were standardizing.)

pcr910303 7y ago

Hmm... There's this big, great, 'perfect', heavyweight graph query language (GQL) that is on process of standardized while an alternative (GraphQL) language is more readable (much more lightweight syntax IMO), has gained much more traction, etc... While GQL and GraphQL's target is different(one is for interacting with Graph DBs while the other one is interacting with backends), there is a lot of overlap ongoing, and I just can't erase the feeling of the overlap between XML & JSON (where while XML was more 'perfect', JSON won the war). Edit: Ok, GraphQL is insufficient for GraphDB Querying. Thanks for everyone's clarification.

the_mitsuhiko 7y ago
> while an alternative (GraphQL) language is more readable It's also entirely insufficient. GraphQL is nice to query APIs but almost pointless to query databases unless you map an entire DSL on top of it.
SuperFerret 7y ago
GraphQL has nothing to do with graph databases.
- pcr910303 7y ago
  Why? GraphQL is about modeling business domain objects in graphs [0] and querying them. Isn't that basically what Graph DB languages do too? [0] https://graphql.org/learn/thinking-in-graphs/ https://graphql.org/learn/thinking-in-graphs/
  - frant-hartm 7y ago
    It is a query language for APIs, name like RestQL or JsonQL would be much more suitable. The expressiveness of GraphQL is severely limited, it doesn't allow you to express even simple patterns like triangles, depth n, paths etc..
- AzzieElbab 7y ago
  aside from google search results for GQL :)

vkhn 7y ago

oh good, I wonder if they realize developers frequently refer to GraphQL as gql.

sickcodebruh 7y ago

I spent many years working on a Neo4j Ruby gem and really grew to love Cypher, their query language. I always found it phenomenally expressive, one of those things that seems simple (almost trivial) at first but was extremely flexible and powerful when you needed more from it. It's highly readable, easy to teach, and intuitive in a way that I never found SQL to be. It's been years since I've worked with the product and while I don't miss Neo4j, I do miss the query language. It's a little unclear to me how GQL will incorporate Cypher but I hope the initiative is successful if for no other reason than a selfish one: I'd love Cypher to be around if I ever wind up using a GraphDB again.

vosper 7y ago
> It's been years since I've worked with the product and while I don't miss Neo4j, I do miss the query language Would you mind expanding on what you don't miss about Neo4j?
- sickcodebruh 7y ago
  I was trying to use it instead of Postgres as a general database and it just didn't shine in that role. The value proposition made sense on paper: it's a more natural way to reason about data than RDBMS, relationships as first-class citizens offer some really great benefits, avoiding the schema seems reasonable when the rest of your stack is dynamic, Cypher is more pleasant than SQL. While some of that might be true, I encountered the following: - Using a somewhat esoteric database increased my devops responsibilities. - Open source license didn't allow hot backups. - Ruby is just slow. I was using it before the binary protocol was implemented so performance was often lousy compared to Postgres. - Writes were slow. Neo4j seemed to excel at reads and, in particular, the kinds of reads that are best handled by a graph. Shocking, I know. - I really didn't have enough data or the need for the kinds of queries that would really let it shine. - A big part of the culture at meetups and tutorials was based on "DON'T YOU JUST HATE JOINS!?" It felt culty. I was a big part of that problem for a long time. The last meetup I went to just felt like people bashing Postgres. So I think that a lot of the things that I don't miss are because I wasn't right for it, I should have just been using Postgres. All that said, there was so much about it to love. Cypher, as already mentioned. While the culture at meetups might have kind of relied on bashing SQL and RDBMS, the company itself was full of brilliant, generous, creative, wonderful people. Their CEO (Emil) in particular is a total sweetheart. The organization was extremely supportive of open source projects, very inclusive, very eager to get people involved, and it made a big impact on me. So, again, while Postgres is the tool I always reach for first, I think that Neo4j as an organization does great work and as a product has a lot to offer if you're the right fit for it. I'm glad to see they're doing well.

RocketSyntax 7y ago

So will neo4j switch to gql? and will spark support switch to gql?

johnymontana 7y ago
Yup, you can think of ISO GQL as the future of Cypher.

The_rationalist 7y ago

Neo4j would become the standard while being far less used than Gremlin? This is nonsense isn't it?

maxdemarzi 7y ago
Neo4j is by far used more than any other graph database out there. Regardless, the standard is not Neo4j specific. It was a collaboration from many companies in the space. They all agree it's a good move.
- The_rationalist 7y ago
  Well I've no statistics about tinkerpop vs neo4j and other usage, I may be wrong. But I know for sure that far more graph databases supports gremlin than supports opencypher. E.g the latest graph database from Microsoft https://docs.microsoft.com/fr-fr/azure/cosmos-db/graph-introduction https://docs.microsoft.com/fr-fr/azure/cosmos-db/graph-intro... Also, Cypher has performance and expressivity issues.
  - b3tt3rw0rs3 7y ago
    Just looking at https://db-engines.com/en/ranking/graph+dbms https://db-engines.com/en/ranking/graph+dbms clearly shows Neo4j as the most prominent graph db. I think even Cosmos as number 2 might be misleading here, as Cosmos is a multi-model product and db engines doesn't distinguish between graph and non-graph use in the ranking. (Same for ArangoDB)
  - hobofan 7y ago
    > E.g the latest graph database from Microsoft As a contrast, the recently introduced RedisGraph only supports Cypher.

westurner 7y ago

Graph query languages are nice and all, but what about Linked Data here? Queries of schemaless graphs miss lots of data because without a schema this graph calls it "color" and that graph calls it "colour" and that graph calls it "色" or "カラー". (Of course this is also an issue even when there is a defined schema; but it's hardly possible to just happen to have comprehensible inter or even intra-organizational cohesion without e.g. RDFS and/or OWL and/or SHACL for describing (and changing) the shape of the data) So, the task is then to compile schema-aware SPARQL to GQL or GraphQL or SQL or interminable recursive SQL queries or whatever it is. For GraphQL, there's GraphQL-LD (which somewhat unfortunately contains a hashtag-indeterminate dash). I cite this in full here because it's very relevant to the GQL task at hand: "GraphQL-LD: Linked Data Querying with GraphQL" (2018) https://comunica.github.io/Article-ISWC2018-Demo-GraphQlLD/ https://comunica.github.io/Article-ISWC2018-Demo-GraphQlLD/ > GraphQL is a query language that has proven to be a popular among developers. In 2015, the GraphQL framework [3] was introduced by Facebook as an alternative way of querying data through interfaces. Since then, GraphQL has been gaining increasing attention among developers, partly due to its simplicity in usage, and its large collection of supporting tools. One major disadvantage of GraphQL compared to SPARQL is the fact that it has no notion of semantics, i.e., it requires an interface-specific schema. This therefore makes it difficult to combine GraphQL data that originates from different sources. This is then further complicated by the fact that GraphQL has no notion of global identifiers, which is possible in RDF through the use of URIs. Furthermore, GraphQL is however not as expressive as SPARQL, as GraphQL queries represent trees [4], and not full graphs as in SPARQL. > In this work, we introduce GraphQL-LD, an approach for extending GraphQL queries with a JSON-LD context [5], so that they can be used to evaluate queries over RDF data. This results in a query language that is less expressive than SPARQL, but can still achieve many of the typical data retrieval tasks in applications. Our approach consists of an algorithm that translates GraphQL-LD queries to SPARQL algebra [6]. This allows such queries to be used as an alternative input to SPARQL engines, and thereby opens up the world of RDF data to the large amount of people that already know GraphQL. Furthermore, results can be translated into the GraphQL-prescribed shapes. The only additional requirement is their queries would now also need a JSON-LD context, which could be provided by external domain experts. > In related work, HyperGraphQL [7] was introduced as a way to expose access to RDF sources through GraphQL queries and emit results as JSON-LD. The difference with our approach is that HyperGraphQL requires a service to be set up that acts as a intermediary between the GraphQL client and the RDF sources. Instead, our approach enables agents to directly query RDF sources by translating GraphQL queries client-side. All of these RDFS vocabularies and OWL ontologies provide structure that minimizes the costs of merging and/or querying multiple datasets: https://lov.linkeddata.es/dataset/lov/ https://lov.linkeddata.es/dataset/lov/ All of these schema.org/Dataset s in the "Linked Open Data Cloud" are easier to query than a schemaless graph: https://lod-cloud.net/ https://lod-cloud.net/ . Though one can query schemaless graphs with SPARQL, as well. For reference, RDFLib has a bunch of RDF graph implementations over various key/value and SQL store backends. RDFLib-sqlachemy does query parametrization correctly in order to minimize the risk of query injection. FOR THE RECORD, SQL Injection is the CWE Top 25 #1 most prevalent security weakness; which is something that any new spec and implementation should really consider before launching anything other than an e.g. overly-verbose JSON-based query language that people end up bolting a micro-DSL onto. https://github.com/RDFLib/rdflib-sqlalchemy https://github.com/RDFLib/rdflib-sqlalchemy Most practically, I frequently want to read a graph of objects into RAM; update, extend, and interlink; and then transactionally save the delta back to the store. This requires a few things: (1) an efficient binary serialization protocol like Apache Arrow (SIMD), Parquet, or any of the BSON binary JSONs; (2) a transactional local store that can be manually synchronized with the remote store until it's consistent. SPARQL Update was somewhat of an out-of-scope afterthought. Here's SPARQL 1.1 Update: https://www.w3.org/TR/sparql11-update/ https://www.w3.org/TR/sparql11-update/ Here's SOLID, which could be implemented with SPARQL on GQL, too; though all the re-serialization really shouldn't be necessary for EAV triples with a named graph URI identifier: https://solidproject.org/ https://solidproject.org/ 5 star data: PDF -> XLS -> CSV -> RDF (GQL, AFAIU (but with no URIs(!?))) -> LOD https://5stardata.info/en/ https://5stardata.info/en/

maitredusoi 7y ago

Anyone know the difference with ArangoDB's AQL ? (I haven't use neo4j as I use ArangoDB)

b3tt3rw0rs3 7y ago
AQL is a vendor-specific multi model language that lately has picked up some ideas from openCypher, like pattern matching. GQL is a project for creating an International Standard language in the process of being created by experts from many countries that represent the interests of multiple vendors.
pluma 7y ago
I haven't had a look at GQL yet but the obvious one would likely be that as ArangoDB aims to support native multi-model, AQL is not just a graph querying language. Graph databases generally only consider edges between vertices (identified by IDs) and those edges typically only have a handful of attributes. In ArangoDB edges and vertices are stored as documents, so they can be represented as arbitrary JSON objects. So if you want to work with a mix of data or want to access your data in different ways, I wouldn't expect GQL to support that whereas with AQL you can mix and match your queries even within the same request. Full disclosure: I'm an external contributor to ArangoDB but this is my personal take.

The_rationalist 7y ago

What advantages/limitations does it have compared to SHACL? https://en.m.wikipedia.org/wiki/SHACL https://en.m.wikipedia.org/wiki/SHACL

paul009 7y ago

Isn't xquery basically a graph query language similar to GraphQL? If so, why are we not using xquery to query objects and sub-objects?

lmkg 7y ago
I'm not familiar with xquery, does it handle general graphs or only DAGs? Your mention of "objects and sub-objects" makes me think you're expecting a different use-case than actual graph databases, which deals more with peer-to-peer connections (like knowledge graphs) than hierarchical models.
namedgraph 7y ago
XQuery is for the XML data model, which is a tree and not a graph.

Vaslo 7y ago

So if I want to learn this GQL, where do I even start? I'm also confused about the naming, is there more than one language that could be called GQL?

johnymontana 7y ago
While the ISO GQL standards draft is being prepared, the best way for a developer to learn and prepare for ISO GQL is to learn the Cypher query language.[1] Many of the concepts from Cypher will be carried over into ISO GQL. [1]: https://neo4j.com/developer/cypher-basics-i/ https://neo4j.com/developer/cypher-basics-i/

lpghatguy 7y ago

Should GQL be pronounced with a hard or soft G? Is "geequel" going to take off akin to "sequel" for SQL?

peterwwillis 7y ago

Huh. Now if only we could do this for configuration management, service mapping/scheduling/coordination, resource allocation, monitoring, alerting, logging, access control, artifact packaging, and execution pipelines.

okram 7y ago

There is something really special about the graph database space. For as long as the space has been around (15 or so years), every vendor and dedicated practitioner has taken solid jabs at trying to realize "the best way" to think about graph traversals. This behavior seems particular to the graph space (vs. document, wide-column, relational, key/value, etc.). While this speaks to the complexity of the type of problems you can solve with graphs, thinking back, I believe this was a cultural anomaly. When it was Neo4j, OrientDB, TinkerPop: the language trifurcation occurred. I'm excited that Neo4j is continuing to take the query language seriously. In an age when software development is about making it easy for the 90% of developers out there with REST APIs, GraphQL, and overly SQL'd embeddings, ... graph is still searching for "that best way." I, personally, have moved on from language-level. However, our new work is going to help my fellow data system colleagues get there languages exposed to as many developers as possible regardless of data model. It is important to me that people can come to respect the numerous ways in which we think about data and has the language we use is so important. The difference between living in Plato's Cave or not. In an effort to support query languages in general, I'll be working on mm-ADT designing a new cluster-oriented virtual machine architecture for storage, processing, and query language developers. I see a veritable Tower of Babel on the horizon! Congrats Neo4j on reaping the benefits of your hard work. I hope our work will converge in for a positive collaboration in 2020.

namedgraph 7y ago
For some reason you neglect to mention RDF graph data model and its SPARQL query language, which have been W3C standards since 1997 and 2008, respectively. They have a healthy ecosystem of both open-source and commercial software, and unlike property graphs were designed with data interchange in mind from the outset. SPARQL was the first and still is the only standard NoSQL query language.
- okram 7y ago
  It just wasn't "the scene" at the time. RDF/SPARQL had its world -- permeated throughout academia and some enterprise deployments with quad/triple-stores like AllegroGraph. But it wasn't going to make a PoW in the software industry because they didn't ride the razor-edge well enough. OWL was a foolish mistake. Triple is a clean and simple idea, but in practice -- reification and URI character hell becoming mind numbing. The RDF-guys did nail it with SPARQL. That is such a pretty query language. Simple, intuitive. I haven't studied the recent path expression advances. I should. But yea, lots of ways of fugglin' with the data.