The Semantic Web needs a MySQL

One thing was clear in the comments of many industry-facing participants of ISWC 2010: a big impediment to adoption of semantic web technologies is the lack of an off-the-shelf triplestore that “just works.”

There are many other problems, of course: RDF an awkward format when it comes to real world programming because the graph model doesn’t align to the object-dictionary model of OO programming; JavaScript favors JSON instead of RDF; URIs and namespaces can be a burden to craft the first time around. But these problems can be lessened, or eradicated, with good development frameworks.

Underlying these surface problems is a deployment one: even if a company wanted to, there’s no clear hassle-free solution to getting a triplestore up and running with the same ease, access, and reliability that relational solutions such as MySQL and Postgres provide. And as long as this is the case, otherwise semantic-web savvy individuals are going to continue to live in the relational world. When people are spread thin, and want to focus on user experience instead of database administration, they’ll pick the database product that allows them to focus on other things.

So what gives? Do we wait for a Mike Stonebraker of the triplestore world to come around? Or do we try to bolt our technologies onto non-relational databases with gaining momentum such as MongoDB or CouchDB?

6 Responses to “The Semantic Web needs a MySQL”

  • Jamey Hicks says:

    This is a very good point.

    If you wait for another Mike Stonebraker to appear, it might take a very long time. It has already been quite a long time and none have really done so.

    So I would say your best bet is an easy-to-install, reliable, high performance layer on top of or integrated with an existing database, relational or otherwise.

  • Leandro López (inkel) says:

    Very good point, as stated by Jamey.

    I’ve been thinking about how feasible would be to have a triple store in these brand new NoSQL technologies, somehow the whole idea seems to be well suited for some level of RDF storage, but only in the case of document oriented DB, like MongoDB. There are others that are key-value stores, like memcachedb, that might not be to right solution.

    I totally agree with your point about Semantic Web having a hard time gaining acceptance in the business world today, that’s my main concern. I love the SW, but I need to pay my bills, and the SW is not giving me any option to do that at this moment.

  • I’ve been wondering the same thing; Neo4j is already a graph database. And Riak has named links between objects; if the objects have a bit of structure (e.g., if they’re JSON), then you have something very close to the RDF model:

  • David Broderick says:

    It’s good to read this because that’s exactly what I’ve been working on, and I will be publishing it in December. If you want a preview, let me know at

  • nchauvat says:


    I am no Stonebraker, but standing on the shoulder of the database giants is
    what we have been trying to do with the framework
    that’s layered on top of Postgresql.

    It was designed to publish the stored data both as RDF and thru a HTML GUI.
    One tool to address both the web of data and the web of documents.

    This is not the holy grail, aka the efficient and scalable graph database, but it already
    powers high-traffic public websites and critical intranets apps. And it is LGPL software.

  • Patrick Logan says:

    RDF and its storage is good for an app like insurance policy issuing and claims. Clear semantics and terms benefit from all that the RDF systems provide. “Simpler” apps like blogs or project trackers are not so obviously going to benefit compared to the speed of developing with more familiar tools. I think they would benefit and finding the sweet spot of the best of both worlds is important.