Yep. Mainstream adoption of "graph thinking" is hindered by not having an SQL like idiom that is widely implemented and can handle most use cases. There are good candidates of course, but it does not feel like anything will settle anytime soon. Maybe because there is no killer app based on a graph database that will just pick an ad-hoc winner.
I have deep respect for how the fields around medicine and biosciences embrace information technologies. Maybe it goes with their territory, being serious and for the long term rather than the "fake it till you make" type cultures and continuous churn and hypes that you see elsewhere.
You can see the impact e.g. in the R ecosystem where a good chunk of packages is bio related or the fact that the only user-friendly ontology tool (protege) and the main example of good use of related graph concepts is from bioinformatics
I wouldn't exactly call protege user friendly.
But this reminds me of a joke we told in our working group:
"SNOMED can't tell you whats wrong with you when you're sick, but it can infer that your "Toe bone is connected to your foot bone" a whopping 2 million times a second."
What, whatever is demoed by Neo4J in their playground is awesome, I used it for just a couple of days but could pull up convoluted queries off DBPedia (producers who worked with artists who were born in countries who have orange in their flag, things like that).
The basic uses of SQL are indeed easy to learn, but quickly you find out that many types of nested queries are no-nos.
The reason might be that the sort of flexibility that graph models provide for queries is only critical at the exploration phase for power users. 'In production' things can be organized or approximated within the relational database toolkit. It is also true that "linked data" is still the exception rather than the norm.
A lot of footguns and performance optimising mostly. For triples it would be around reifying and ranking (with RDF-Star helps with but doesn't solve) and the SPARQL syntax still feels like a esotetic syntax at times.
Cypher is OK, but doesn't really follow any existing paradigms, and LPGs can be a massive footgun without a semantic layer since you can pretty much throw any property on a node type.
Federation over named graphs, or different sources as well.
It's an awful language w/o formal grammar and plenty of the same problems people knew SQL has had for ages: modules, variety of collections other than the only main kind.
Writing in Cypher takes a lot of guessing, and there's no real explanation for why sometimes things that seem like they should work -- don't. It feels like a language designed by an amateur, built around a gimmick syntax of (x)-[y]->(z), but as soon as you need something a little more complex, there's nothing.
GP is in a completely different category of things. It has a deep mathematical formalism behind it, a unique and worth of exploring computation model.
Cypher in comparison to GP is like my 3 y.o doodles compared to Rembrandt's doodles. Superficially, both are a bunch of squiggly lines...
Was expecting to find the grammar, but found nothing of the kind.
From my experience with how Cypher is implemented in Neo4j (admittedly, from a while back), it was a bunch of regular expressions and some hand-tailored string processing.
There's nothing useful (for programmers who want to use Cypher) in the link you provided, just some information about the work group that works on this language. Without much research, I'd imagine that this is an organization sponsored or otherwise supported by Neo4j to promote the use of their database.
OpenCypher is a group that includes Microsoft and others. The results will likely be the standard.
Being able to match patterns in a graph is pretty much how you retrieve data. Being able to identify properties of relationships is what Cypher does extremely well.
The GP thing from the OP is mathematical and useless for most software engineers.
It would be nice to play with the code.