Multi-model RDF store vs Graph database

Question

I have read the question on SO: Graph DBs vs. Document DBs vs. Triplestores.

I understand that there's a lot of advantage using OWL/RDFS for semantic data because they are compact and they're just a collection of edges. I was gonna try a triplestore (like Jena) but was wary of certain graph algorithms I couldn't execute on it (like shortest paths and weighed edges).

Ever since I've set out to build something like Google Knowledge Base, I have come across hybrid or multi-model data stores (RDF store + Graph DB), like Blazegraph, Amazon Neptune, Google Cayley (not an actual Google product), Virtuoso, Grakn and the like.

This has gotten me to wonder why I can't just export all the RDF data into a plain and simple Graph Database? Like Neo4j or OrientDB? After all, the RDF data is still a graph. Why do the creators of Knowledge Graphs insist on using a hybrid store? Why not just use a plain, old graph database? If you think the answer is optimization, then why not use just a hypergraph database? What operations on a hybrid database are not available on a graph database? Let me quote verbatim from a blog:

The emerging paradigm of organising and managing complex, highly interconnected data as so-called knowledge graphs poses a peculiar combination of knowledge and data representation challenges. Knowledge-graph-based applications need to operate efficiently over semantically rich, yet well-structured and constrained graph data. While relational modelling techniques and graph databases are useful tools to address some of the specific issues, they cannot offer a comprehensive technical and conceptual infrastructure for the entire task.

In fact, Sail actually provides an RDF layer on top of a graph database (like OrientDB). Doesn't this further reduce the allure of hybrid databases? I do not get the point of building an RDF implementation atop a graph database when RDF data is itself a graph?

Answer 1

Here is a link to tabulated comparison of Database Management Systems based on the following:

1. Identifiers
2. Entity Relationship Type (Relations) Modeling
3. Entity Relationship Type (Relations) Structure (N-Tuples, 3-tuples etc.)
4. Entity Relationship Type (Relations) Notations for representing Structure
5. Data Definition and Manipulation Language Support
6. Reasoning and Inference Languages
7. Relevant Open Standards

I can't place the table inline here due to markdown support for table using this particular platform.