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?
