7 databases in 7 weeks - why no RDF?

I guess many of you have read this book from Eric Redmond and Jim R. Wilson.

It was written in May 2012, but it seems there is no mention of RDF and triple stores...
[edited] This book does compare the existing ways of handling data nowadays to choose the right tool for the right purpose. It compares one relational database (Postgres), two key-value stores (Riak, Redis), a column-oriented database (HBase), two document-oriented databases (MongoDB, CouchDB), and a graph database (Neo4J). But there is no single word about RDF/Triple stores. It gives pros/cons of the different systems, about scalability, CAP theorem, query possibilities, etc. At first glance, it seems to me "unfair" not having RDF/Triple stores introduced by such a book. Does anybody know how come doesn't such a book talk about Semantic Web techonologies ? Maybe only the author could answer that question.

Also, it does focus on the NoSQL movement, and it is unclear to me wether RDF should clearly be considered NoSQL or not ? I've just found How RDF Databases Differ from Other NoSQL Solutions.

Thank you for any opinion about that.

I read this excellent book and sent Redmond some suggestions a few months ago, the main one being that of the four categories of NoSQL databases that they covered, a triplestore would be an excellent addition for the graph database category. The wrap-up of their MongoDB chapter has entire paragraphs that could describe RDF and SPARQL as well, and I always felt that the table metaphor people use when describing column-oriented databases was a bit strained--it sounds like triples to me, but maybe it just looks like a nail because I have a hammer.

I was reading the book to learn more about what NoSQL fans are looking for, and something else in RDF technology that should appeal to them is the role of RDFS: the "schema vs. schemaless" point is a common discussion with them, and an optional (standardized!) schema language sounds like the perfect compromise to me. The existence of a standardized, well-implemented query language is also something that none of the NoSQL tools offer, although (as with SPARQL) the term "SQL-like" does come up a lot.

In explaining RDF technology to to people with that kind of background I've also cut way back on mentioning "semantic web" or "linked data" for reasons explained at http://www.snee.com/bobdc.blog/2012/11/selling-rdf-technology-to-big.html The NoSQL people can obviously handle technologies with strange acronyms for names, so instead of selling them on a particular vision and then telling them the technology to implement it, I think it's best to just tell them the advantages of the technology and where it fits in with what they're trying to do and how they're trying to do it.

Here's a great answer by @Signified, specifically the section about how RDF compares to SQL/NoSQL: http://answers.semanticweb.com/questions/2467/killer-applications-for-rdf-data-stores?page=1&focusedAnswerId=2468#2468

Note that RDF isn't really a database. It's a resource description framework (duh!). That means that you could very well use any of the databases explained in that book, and still generate RDF out of them. You can think of the database as the implementation part, and RDF as the interface - if you're a programmer this should makes sense. They're not strictly related most of the time. Just like you don't need to talk about HTML in a database book, you also are not obliged to talk about RDF either.

I personally think the main difference is that you use RDF if the system you're building needs to interact with external data. This includes using data from other sources, and providing data to other systems. Does your system need that? Or is it just an application that doesn't need to interact with other resources?

If your application needs to interact with external resources, than RDF is really the main player in town. Sure you can use XML/JSON/etc web-services and maybe provide a RESTful JSON API of your data... but the mind-switching scenario of RDF is that you don't need to build your own API schema, you can re-use the ones already built.

Otherwise, if you don't need to share data much, than RDF won't probably be much useful, and the locked-in schema that we're used to with SQL/NoSQL databases, will work just fine.

EDIT I haven't read that book, but if it doesn't talk about RDF, than it probably means that it's targeting a specific niche of users that don't need to build systems that interact with external resources. You could very well talk about databases and not mention RDF at all... it just depends what story the book is trying to tell.