<p>@Michael, I am happy that you step in as you definitely know more than me on this :) . I am on a learning journey at this point. At your request here is one of the paper that inspired my understanding:</p>

<blockquote>
  <p>arxiv.org/abs/1801.02911 (SPARQL querying of Property Graphs using
  Gremlin Traversals)</p>
</blockquote>

<p>I quote them </p>

<blockquote>
  <p>"We present a comprehensive empirical evaluation of Gremlinator and
  demonstrate its validity and applicability by executing SPARQL queries
  on top of the leading graph stores Neo4J, Sparksee and Apache
  TinkerGraph and compare the performance with the RDF stores Virtuoso,
  4Store and JenaTDB. Our evaluation demonstrates the substantial
  performance gain obtained by the Gremlin counterparts of the SPARQL
  queries, especially for star-shaped and complex queries."</p>
</blockquote>

<p>They explain however that things depends somehow on the type of queries.</p>

<p>Or as another answer put that in stack overflow <a href="https://stackoverflow.com/questions/13046442/comparison-of-relational-databases-and-graph-databases">Comparison of Relational Databases and Graph Databases</a> would also help understand the issue between Set and path. My understanding is that TripleStore works with Set too. This being said i am definitely not aware of all the optimization technics implemented in TripleStore lately, and i saw several papers explaining technics to significantly prune set join operation. </p>

<p>On distribution it is more a guts feelings. For instance, doing join operation in a distributed fashion sounds very but very expensive to me. I don't have the papers and my research is not exhaustive on the matters. But from what I have red and I will have to dig in my Evernote :) to back it, that's the fundamental problem with distribution. Automated smart sharding here seems not to help alleviate the issue.</p>

<p>@Michael this a very but very complex subject. I'm definitively on the journey and that's why i am helping myself with stackoverflow to guide my research. You probably have an idea of as to why. So feel free to provides with pointers indeed. </p>

<p>This being said, I am not saying that there is a problem with RDF and that Property-Graph are better. I am saying that somehow, when it comes to graph traversal, there are ways of implementing a backend that makes this fast. The data model is not the issue here, the data structure used to support the traversal is the issue. The second thing that i am saying is that, it seems that the choice of the query language influence how the "traversal" is performed and hence the data structure that is used to back the data model. </p>

<p>That's my understanding so far, and yes I do understand that there are a lot of other factor at play, and feel free to enumerate some of them to guide my journey. </p>

<p>In short my question comes down to, is it possible to have RDF stores backed by a so-called Native Graph Storage and then Implement Sparql in term of Traversal steps rather than joins over set as per its algebra ? Wouldn't that makes things a bit faster. It seems to be that this is somewhat the approach taken by <a href="https://github.com/graknlabs/grakn" rel="nofollow noreferrer">https://github.com/graknlabs/grakn</a> which is primarily backed by janusGraph for a graph like storage. Although it is not RDF, Graql is the same Idea as having RDFS++ + Sparql. They claim to just do it better, for which i have my reservation, but that's not the fundamental question of this thread. The bottom line is they back knowledge representation by the information retrieval (path traversal) and the accompanying storage approach that Property-Graph championed. Let me be clear on this, I am not saying that the graph native storage is the property of property graph. It is just in my mind a storage approach optimized to store Graph Structure where the information retrieval involve (path) traversal: <a href="https://docs.janusgraph.org/latest/data-model.html" rel="nofollow noreferrer">https://docs.janusgraph.org/latest/data-model.html</a>.</p>
Why aren't TripleStore implemented as Native Graph Store as Property-Graph Store are?
<p>Sparql based store or put another way, TripleStore, are known to be less efficient than property graph store, on top of not being able to be distributed while maintaining performance as property graph. </p>

<p>I understand that there are a lot of things at stake here, such as inferencing and what not. Putting distribution and inferencing aside where we could limit ourself to RDFS which can be fully captured via SPARQL, I am wondering why that is ? </p>

<p>More specifically why is the storage the issue. What is limiting Sparql Based store to store data as Property graph store does, and performing traversal instead of massive join queries. Can't sparql simply be translated to Gremlin steps for instance ? What is the limitation there? Can't the join be avoided ?</p>

<p>My assumption is, if sparql can be translated in efficient step traversal, and data is stored as property graph do, such as as janusGraph does <a href="https://docs.janusgraph.org/latest/data-model.html" rel="nofollow noreferrer">https://docs.janusgraph.org/latest/data-model.html</a> , then the issue of performance would be bridged while maintaining some inference such as RDFS. </p>

<p>This being said, Sparql is not Turing-complete of course, but at least for what it does, it would do it fast and possibly at scale as well. The goal is not to compete in my view, but to benefit for SPARQL ease of use and using traversal language like gremlin for things that really requires it e.g. OLAP.  </p>

<p>Is there any project in that direction, has Apache jena considered any of this? </p>

<p>I saw that Graql of Grakn seem to be using that road for the reason I explain above, hence what's stopping the TripleStore community ?</p>