[okram]

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]

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.

[tasogare]

> , which have been W3C standards since 1997 and 2008, respectively.

While RDF forms a graph, it is not a general graph model. In particular, two things that are enabled by graph databases (having data in the node itself, and associating data with edge) are not directly possible and need tricks such as relationship reification.

On the social side, the sectarism and bikeshedding tendencies of the community can be another turn off.

[namedgraph]

RDF is a directed graph model. Nowhere does it say properties have to have properties in a graph model. You can always model them as intermediary nodes.

[tasogare]

Using intermediate node is changing the structure of the graph. RDF is not a general graph model. The fact that a node cannot hold data by itself (a link to literal is required) is risible.

Naming of nodes with IRI is also a ridiculous, especially in Linked Data where changing your hosting domain (and even the protocol to access data) requires changing the data itself.

[namedgraph]

Are you kidding? IRIs is what sets RDF above and beyond other data models. Global identifiers are crucial if you want to work with data interchange on a web scale.

Show me a definition of a "general graph model"? Nothing shows up on Wikipedia.

There is on the other hand a directed graph model: https://en.wikipedia.org/wiki/Directed_graph This is exactly what RDF is, with labeled vertices and edges.

[tasogare]

You can have global identifier without IRIs, for example using GUID (that’s the solution used for COM components for instance).

The thing is you can’t represent "A"->"B" directly in RDF. You need to stretch the representation to at least use a resource node as subject, but also for the object too if this node could be used as subject in another predicate. And of course both these resources must be encoded as IRI and then linked to the literals that contains the data. That’s four nodes and three links instead of two and one. It’s a lot of boilerplate code for a simple problem. And as said before, putting key:value on an edge require reification of the edge... which undermine the simple SPO model because it’s now SP(O as P)PO.

You may think it the same but it’s not. Usability matters and that’s why the SemWeb stack has almost zero adoption since its inception while graph databases are trendy.

[okram]

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.