We examine whether the existing ‘Database in the Cloud’ service SimpleDB can be used as a back end to quickly and reliably store RDF data for massive parallel access. Towards this end we have
implemented ‘Stratustore’, an RDF store which acts as a back end for the Jena Semantic Web framework and stores its data within the SimpleDB.
We used the Berlin SPARQL Benchmark to evaluate our solution and compare it to state of the art triple stores. Our results show that for certain simple queries and many parallel accesses such a solution can have a higher throughput than state of the art triple stores. However, due to the very limited expressiveness of SimpleDB’s query language, more complex queries run multiple orders of magnitude slower than the state of the art and would require special indexes. Our results point
to the need for more complex database services as well as the need for robust, possible query dependent index techniques for RDF.

http://www.semanticoverflow.com/questions/723/rdf-storages-vs-other-nosql-storages

Also, I have written up some of my own thoughts on the subject at:

http://blog.datagraph.org/2010/04/rdf-nosql-diff

@dret – RDF’s focus on ‘GET’ is natural. SemWeb is a project fundamentally about describing stuff. It’s by nature pretty passive and declarative, which is a natural fit with read-only emphasis on HTTP GET. Of course there are places (SPARQL Update) where we go beyond describing stuff, but that really is our core business. So the focus on GET is quite natural…

Although the data from KV might be seriously uninteresting and the storage suboptimal, the developer would have the option (somehow?) of later enriching it.

(Ages ago I did a replacement for Java Property files [straight KV] using a triplestore – worked fine, though no doubt wasn’t worth the coding effort…)

I will be at NoSQL Live talking about HyperGraphDB (http://www.kobrix.com/hgdb.jsp), and would love to chat with you about this as well. We should definitely meet up. I’m very skeptical of the possibility to standardize NoSQL, and even more skeptical of the idea of reducing it to a one particular data model like RDF with SPARQL…in the sense that it will be very hard to see all NoSQL products implement SPARQL or some derivative as a standard query language. HyperGraphDB’s model is even more general than RDF or any other graph model/database for that matter, and still it is a model with certain assumptions, certain rules to follow, certain best practices etc., and it would be to its detriment if the interface to it to be a common denominator with other DBs. I suspect the same is true for the other NoSQL DBs.

That said, your post is right on the mark since there are a lot of benefits to be gained in making semantic web standards part of the mainstream programmer’s toolkit. NoSQL can help with that because it’s lightweight, dynamic, low-cost, buzzy etc. while RDF can help NoSQL by putting in the “industry standard” label in power point presentations

Cheers,
Boris

There have been some efforts in the past to create a query language for semantic graph databases. I’m not sure of the status of the current effort but this paper is an interesting read on the topic. You are probably aware of these efforts, but just in case, here is the link: http://www.bearcave.com/misl/misl_tech/dsge_query_language.pdf

But, as I am just starting to investigate how to use graph DBs in a Social Semantic Web platform that we’re starting to build, I am no expert. Perhaps this issue is now moot.

I’m encouraged by Peter’s comment as we are looking closely at using Neo4j. The other contender is InfoGrid.

It seems to me that graph DBs, with their ability to clearly define link types, are powerful systems that can effectively encode semantic relationships between nodes. In fact, they appear to be perfect modelers of RDF triples, with the nodes representing subjects and objects and the edges (relationships) representing predicates. Perhaps creating a SPARQL abstraction layer for graphDBs would allow these data to be effectively discovered.

Initial binding point between NoSQL and Quad Stores is that both are EAV Graph oriented.

Graph traversal expressions are main thing NoSQL folks assume is missing from SPARQL based RDF Quad Stores.

As for reasoning, this aspect is sorta lost on the NoSQL community (as is it most). But as huge amounts of Linked Data continue to emerge, the value of reasoning will become self evident.

As you can imagine, Virtuoso handles graph traversal expressions via SPARQL extensions, here are some live examples based on the 8.5 Billion+ RDF Quad Store at: http://lod.openlinksw.com (/sparql or /isparql will work for custom queries):

1. http://bit.ly/9QNdec — N degrees of TimBL using Virtuoso’s SPARQL path expressions extension
2. http://lod.openlinksw.com/demo_queries/ — for other queries you can run against this LOD Cloud Cache instance of Virtuoso .

Kingsley