RDF storages vs. other NoSQL storages

Without extolling too much the virtues of RDF in general, I think the short of it is that RDF database systems are the only standardized NoSQL solutions available at the moment, providing several key advantages compared to run-of-the-mill NoSQL database systems:

• A homogeneous standard data model. NoSQL databases typically have one-off, ad-hoc data models and capabilities designed specifically for each implementation in question. As a rule, these data models are neither interoperable nor standardized in any way. Take e.g. Cassandra, which has a data model that "can most easily be thought of as a four or five dimensional hash" and the specifics of which are described in a wiki page, blog posts here and there, and ultimately only nailed down in version-specific API documentation and the code base itself. Compare to RDF database systems that all share the same well-specified and W3C-standardized data model at their base.

• A powerful standard query language. NoSQL databases typically do not provide any high-level declarative query language equivalent of SQL. Querying these databases is a programmatic data-model-specific, language-specific and even application-specific affair. Where query languages exist, they are entirely implementation-specific (think SimpleDB or GQL). SPARQL is a very big win for RDF databases here, providing a standardized and interoperable query language that even (some) non-programmers can make use of, and one which meets or exceeds SQL in its capabilities and power.

• Standardized serialization formats. RDBMSes have (somewhat implementation-specific) SQL dumps, and (some) NoSQL databases have import/export capability e.g. from/to implementation-specific structures expressed in XML, JSON or CSV formats. RDF databases, by contrast, have import/export capability based on well-defined, standardized, entirely implementation-agnostic serialization formats such as N-Triples/N-Quads.

From the preceding points it follows that RDF-based NoSQL solutions enjoy concrete advantages such as:

• Data portability. If you need to switch RDF storage solutions in-house, to make use of multiple different solutions concurrently, or to share data with external parties, your data travels with you without needing to write and utilize any glue code for converting some ad-hoc export format into some other incompatible ad-hoc import format.

• Toolchain portability. The RDBMS world has its various database abstraction layers, but the very concept is nonsensical for NoSQL solutions in general (see "ad-hoc data model"). RDF solutions, however, represent a special case: libraries and toolchains for RDF are typically only loosely coupled to any particular DBMS implementation. Learn to use and program with Sesame or Jena for Java, RDFlib for Python, or RDF.rb for Ruby, and it generally doesn't matter which particular RDF-based system you are accessing. Just as with RDBMS-based database abstraction layers, your RDF-based code doesn't need to change just because you want to do the RDF equivalent of switching from MySQL to PostgreSQL.

• No vendor lock-in. If the RDF database solution A was easy to get going with but eventually hits a brick wall, just switch to RDF database solution B or C or any other of the dozens of available interoperable solutions. Unlike switching between two non-RDF NoSQL solutions, it doesn't have to be a big deal. Needless to say there also exist synergistic ecosystem benefits with regards to the available talent pool or the commercial support options.

• Future proof. It's not an unreasonable bet that RDF data will still be usable as-is by, say, 2038. It's not at all evident, however, that the same would hold for any of the other NoSQL solutions out there at the moment, many which will inevitably prove to be rather short-lived in the big picture.

Now, there are, of course, numerous other benefits to RDF itself, such as those relating to publishing and using data on the Linked Data web, but they go somewhat beyond the scope of any attempted "apples to apples, oranges to oranges" comparison to other NoSQL solutions.

One difference between NoSQL and RDF stores that I see is that the former don't provide for searching or for joins. RDF stores do both but share the NoSQL benefit of schemaless data.

Good answers here, also wanted to add that some RDF stores will provide a SPARQL query interface that allows for declerative queries into the RDF data model, without this there will be a unnessessary performance overhead converting between different data models. To be more precise, if you use a object-oriented API to access the storage you are doing unnessessary convertions between a imperative query and a declerative one. This is because SPARQL and object-oriented programming are two very different programming paradigms[1]; respectively the Declarative paradigm and the Imperative paradigm. Where a declerative query is specified by "What you want to achieve", the imperative is specified by "How you want to achieve it". Thus, a simple API call may result in tens-, hundreds-, or even thousands of often tiny declerative queries to convert between the paradigms. If performance is important for you then you should perhaps take this into consideration.

[1]: http://en.wikipedia.org/wiki/Programming_paradigm Programming Paradigm