
Introducing OpenCypher, the open graph query language project - ryguyrg
http://neo4j.com/blog/open-cypher-sql-for-graphs/
======
klapinat0r
> _Why We Need a Common Graph Query Language_

> _I believe that graph query language is Cypher._

I, and others, believe gremlin is that common graph query language.

My first meet with graph databases was in fact Neo4j, but quickly pivoted to
Titan, and now using Cayley for smaller projects (although its Cassandra model
will make an interesting future).

All except Neo4j supported gremlin, which to me is expressive, formal and
actual-human readable.

Cypher looks cool, and has intuitive method of writing the edge query parts,
but while it looks hip, I didn't find it obvious nor human parsable. Human
readable yes. You recognize the terms, but translating it into an AST is
simpler and easier in gremlin than in Cypher (in my opinion)

~~~
optimuspaul
Gremlin is certainly more readable in my opinion. Cypher has always felt like
it was trying to hard to be different.

~~~
okram
[http://www.slideshare.net/slidarko/the-gremlin-traversal-
lan...](http://www.slideshare.net/slidarko/the-gremlin-traversal-language)

------
jerven
I always wonder how readable those queries really are. Its a nice claim but
has anyone done any really serious research about this at all? For example the
same in SPARQL 1.1

    
    
      SELECT ?cypher_attributes
      WHERE {
        ?cypher a <QueryLanguage> ;
                <queries> ?graphs ;
                <attributes> ?cypher_attributes .
        ?user <USES> ?cypher .
        FILTER (?user IN ‘Oracle’, ‘Apache Spark’, ‘Tableau’, ‘Structr’)
        ?opencypher <MAKES_AVAILBLE> ?cypher .        
      }
    

Instead of

    
    
      MATCH (cypher:QueryLanguage)-[:QUERIES]->(graphs)
      MATCH (cypher)<-[:USES]-(u:User) WHERE u.name IN [‘Oracle’, ‘Apache Spark’, ‘Tableau’, ‘Structr’]
      MATCH (openCypher)-[:MAKES_AVAILBLE]->(cypher)
      RETURN cypher.attributes
    

In the SPARQL case the graph flow does not revert on the edge with <USES> (it
can using ?cypher ^<USES> ?user, but it would be weird and in the larger
queries very confusing). The SPARQL case also tends to group related concepts
together.

This assumes a DEFAULT BASE URI is selected for the SPARQL version that
contains all the modeled relations. Which in a straight comparison to Cypher
is a fair comparison.

I find Gremlin a lot nicer than Cypher, and a lot more powerful as well. Also
up to today Neo4J just has not scaled all that well. I am awaiting the LDBC
Benchmark results of Neo4J to see if I am wrong.

What Neo4J has been great at is making a nice solid product that aims at
solving developer problems. I believe as a database it has not been that great
at solving enterprise or life science community problems. Its still a single
database instance without federation on demand.

~~~
jakewins
There's nothing stopping you from flipping that relationship order though, or
making that pattern more compact. In fact, I'd prefer an overall reversed
order, something like:

    
    
      MATCH (openCypher)-[:MAKES_AVAILBLE]->(cypher:QueryLanguage)-[:QUERIES]->(graphs),
            (u:User)-[:USES]->(cypher)
      WHERE u.name IN [‘Oracle’, ‘Apache Spark’, ‘Tableau’, ‘Structr’]
      RETURN cypher.attributes
    

I guess, in this particular case, it's subjective preference which language
you feel expresses the query pattern most legibly. I certainly prefer the
visual approach of cypher.

~~~
okram
Ah, thats better as you don't need all the unbound variables. However, you
still don't need "graphs" unless for the English reading of the promotion.

In Gremlin3, the above is:

    
    
      g.V().match(
        as("openCypher").out("makesAvailable").hasLabel("QueryLanguage").as("cypher").out("queries").as("graphs"),
        as("user").out("uses").as("cypher"),
          where("user", within(["Oracle","Apache Spark", "Tableau", "Structr"])),
            select("cypher").by("attributes")

------
mk3
Neo4j has this thing on ignoring other graph databases. One example is their
O'Reily book Graph databases covering you guessed it one graph database. I
know it's good for marketing purposes. I like the way Cypher works, though not
sure whether I would like to see Neo4j controlling how graph query language
evolves.

~~~
jakewins
So, it's to a large extent to address that last concern that we are doing
this, right. We are moving the ownership of the language out into its own
project, and inviting others to design the future of graph query languages
together with us. We think that, while that means we loose a lot of control of
our golden goose, so to speak, it is exactly the right choice if we want, as
we do, for cypher to be the go to standard for querying graphs across the
industry.

~~~
grandalf
Thanks for all the work you guys are doing. I have used neo4j on a few
projects, one in node and the other in python, and have really loved using
cypher. The projects end up so simple with so many fewer lines of code it's
amazing.

------
dmoreno
Why is similar to SQL but different, wouldn't be better to add the MATCH
parameter to SELECT on good old SQL?

From
[https://en.wikipedia.org/wiki/Cypher_Query_Language](https://en.wikipedia.org/wiki/Cypher_Query_Language):

    
    
        MATCH (charlie:Person { name:'Charlie Sheen' })-[:ACTED_IN]-(movie:Movie)
        RETURN movie
    

to

    
    
      SELECT movie
      FROM Movie movie, Person person
      WHERE person.name = 'Charlie Sheen'
      MATCH person-[:ACTED_IN]->movie;

~~~
okram
This is an exact replica in Gremlin3:

    
    
      g.V().has("name","Charlie Sheen").
        as("person").out("actedIn").as("movie").
          select("movie")
    

However, this can be expressed in a much simpler form as you don't need all
the variables. Simply do:

    
    
      g.V().has("name","Charlie Sheen").out("actedIn")

~~~
cheerfulstoic
Sometimes you do need the labels, depending on what you're trying to query
for. If, for example, a person could have acted in both plays and movies,
sometimes you might want one or the other specifically.

------
tsturge
As the designer of MQL (Metaweb/Freebase's query language) which is a GraphQL
like language on top of a graph database, I'm always surprised by other graph
query languages. Since JSON represents a tree easily, it a natural model for
non-cyclic queries.

Using JSON for the template also leads to a clear correspondence between the
query and the result which is a very nice property few query languages have.

[http://mql.freebaseapps.com/ch03.html](http://mql.freebaseapps.com/ch03.html)

to take trip back to 2007.

~~~
owyn
Now that freebase is shutting down, is there ever going to be an open source
version of the server side implementation of MQL?

~~~
barakm
I implemented a "light" version of MQL atop Cayley
([https://github.com/google/cayley](https://github.com/google/cayley)) that
I'd be happy to extend :)

tsturge did a prescient job with the original (yeah, GraphQL is 2007 all over
again) and I wanted to keep the flame alive.

------
sireat
I tried Cypher and Gremlin when working on smallish graph of about 3M nodes
and 20M edges a few years ago

Back then both were pretty rough, Gremlin looked more polished but wasn't
really (most promised features in the documentation were not working just
yet).

What has changed since?

~~~
okram
Apache TinkerPop3 has been in development for 2 years. It is a complete
rewrite since TinkerPop2. It was just released in July 2015. Its light years
ahead of Gremlin2.

[http://tinkerpop.incubator.apache.org/](http://tinkerpop.incubator.apache.org/)

The two big things:

1\. Gremlin language is much cleaner and easier to use.

2\. It supports OLTP graph databases (e.g. Titan/Neo4j/Stardog) and OLAP graph
processors (e.g. Hadoop/Spark/Giraph).

------
interdrift
I work with graphs at daily basis and I can tell you that I was really
suprised anyone hasn't come up with a solution to this.

------
rymohr
What can cypher do that GraphQL can't?

~~~
lobster_johnson
GraphQL, surprisingly, is neither a graph query language nor a query language.
The comparison isn't really valid.

It's better to understand GraphQL as a protocol that competes with REST. It's
only a language in the sense that JSON is a language; i.e., it has a syntax
that can be parsed.

For example, GraphQL supports queries like this:

    
    
      query movie {
        whereYear(max: 1985)
        actors {
          hasName(like: "goldblum")
        }
      }
    

But this is something the particular schema and implementation would need to
implement. If you want to filter by arbitrary attributes, you're out of luck
because the spec is just a syntax. I suppose you do something like:

    
    
      where(what: "year", max: 1985)
    

but you still have to invent a standard set of parameters here: min, max, eq,
notEq, lessThan, lessThanOrEq, like, etc. Again, totally ad hoc.

GraphQL, not being a language, also doesn't support variable bindings. So you
cannot do self-referencing queries like "find all movies with a director who
also acted in it", because that would require some kind of variable support.

(This is not a criticism of GraphQL, by the way. It's great at what it's
defined for.)

~~~
optimuspaul
I believe that is coming. The latest spec has variables for some use cases.

~~~
lobster_johnson
The latest spec's "variables" let you pass simple parameters to a query. I
don't see it going in the direction of a general-purpose graph query language.

------
baconner
Wait so... It's not about crypto? That's a little confusing name wise.

~~~
johnymontana
No, not crypto. Cypher is a graph query language, popularized in the Neo4j
graph database. Its name may have been inspired by the Matrix movie...

~~~
phpnode
This is great:

GraphQL has nothing to do with graphs.

OpenCypher has nothing to do with ciphers.

~~~
untothebreach
Clearly, I need to start a project named 'GraphCypher,' which is a new, high-
performance, HTTP2 server.

~~~
michaelmior
I actually laughed out loud at this, although given the requirement for TLS,
at least it would involve encryption.

~~~
untothebreach
hmmm....guess it will have to be a javascript framework then. Pivot! :)

------
jzd
[https://xkcd.com/927/](https://xkcd.com/927/)

~~~
jakewins
Except, we're not introducing something new :) We're taking what's already
used by 70-80% of graph database deployments and opening it up for other
vendors to collaborate with us on the design and implementation of it.

~~~
optimuspaul
citation needed.

~~~
keyboardwarrior
Wouldnt touch neo4j with a ten foot pole.

Between the orientdb/neo4j dick swinging contest and the whole oreilly "graph
database" book for pure fluff. I am left with a very bad taste in my mouth.

It tries to do the whole vendor lock-in thing... badly.

