What advantages do RDF storages have against other NoSQL storages?

The one advantage I can see is inference engines integration. But I'm not sure, may be there are other NoSQL storages types with this "feature" enabled.

asked 13 Apr '10, 05:46

Idsa's gravatar image

accept rate: 0%

edited 13 Apr '10, 14:48

Rob%20Vesse's gravatar image

Rob Vesse ♦

If you are dealing with data in RDF format, it's better to have an RDF triple/quad store. You will not need to worry about dealing with parsing different serializations, IRIs, encoding IRIs, building your own indexes, implementing a SPARQL query engine, etc.

NoSQL storage systems tend to be key-value stores and have very simple (but hugely scalable) ways to retrieve your data (i.e. direct access or parallel scan (see: HBase)) with limited support for indexes.

Personally, I don't see RDF triple/quad store and NoSQL as two opposed communities/technologies/trends.

Indeed, they might work well together, for example (as inspiration):

I would like to see more RDF stored in HBase :-)

See also:

permanent link

answered 13 Apr '10, 05:55

castagna's gravatar image

accept rate: 27%

edited 13 Apr '10, 06:20


@castagna Thank you for answer. Blogpost at bdecentralyze.com was very useful for me.

(13 Apr '10, 06:34) Idsa Idsa's gravatar image

It's a pleasure.

Indeed, it would be interesting to know which kind of inference you would need.

(13 Apr '10, 13:52) castagna castagna's gravatar image

You may be interested in how Seevl uses Redis to store and query RDF data: http://seevl.net/blog/2013/01/15/storing-and-querying-rdf-data-with-redis/

(21 Jun '13, 06:48) Tomasz Plusk... Tomasz%20Pluskiewicz's gravatar image

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.

permanent link

answered 16 Apr '10, 18:48

Arto%20Bendiken's gravatar image

Arto Bendiken
accept rate: 20%

See also Sandro Hawke's "Toward Standards for NoSQL" slides from NoSQL Live in Boston last month: http://www.w3.org/2010/Talks/0311-nosql/talk.pdf

(18 Apr '10, 17:30) Arto Bendiken Arto%20Bendiken's gravatar image

I've expanded my answer and added some general-audience context in my blog post "How RDF Databases Differ from Other NoSQL Solutions" just now: http://blog.datagraph.org/2010/04/rdf-nosql-diff

(22 Apr '10, 20:21) Arto Bendiken Arto%20Bendiken's gravatar image

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.

permanent link

answered 16 Apr '10, 20:17

Ian%20Davis's gravatar image

Ian Davis
accept rate: 13%

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

permanent link

answered 19 Apr '10, 08:45

inge%20Henriksen's gravatar image

inge Henriksen
accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 13 Apr '10, 05:46

question was seen: 11,080 times

last updated: 21 Jun '13, 06:48