views:

73

answers:

1

I'm considering storing the content of a web app in an RDF or OWL ontology instead of an RDBMS.

However, when I research ontologies they seem to always exist in the context of publicly accessible data stores serving as the backbone of the semantic web. I've never heard of them being used as the content engine behind a web app.

Is it reasonable to use an ontology instead of an RDBMS for such an application?

(Again, this is just for content. User data, commerce and stuff like that will stay in a database as I see no need to reinvent the wheel there.)

+1  A: 

by "storing the content of a web app in an RDF or OWL", do you mean "storing the data in a bunch of XML files"?

the reason why people use RDBMS is not their beauty. I hate the semantics of RDBMS. A lot. They always contradict my programming model at some point. but they provide a lot of benefits as well.

basically, the question is, what kind of storage engine(s) will you use? you want your storage to be fast, so it should have caching and indexing for search operation. you want it to be reliable, so it would be nice to have something robust, that degrades gracefully. you'll probably want it to be able to handle concurrency, so you'll like to have ACID properties. and you might want it to be easily scalable, so the best would be if it support storage on distributed machines.
"storing the data in a bunch of XML files", as I bluntly put it, simply doesn't meet any of these criteria. I don't know whether or not there are XML-oriented document stores, but I imagine there are.

So why RDBMS? When we say RDBMS, we actually mean SQL. There may be alternatives, but anything you'll come accross in "normal life" is SQL in some sort. Most of these SQL databases have the desired properties. so do some document stores and some key-value-stores. the difference is, SQL technically is a standard (although implementations really vary a lot) and because for most SQL database drivers, there are bindings in virtually any language and because most of these database systems have been around for a long time.

So no, there is no reason for you to use RDBMS. However you really should use a storage engine. You can store RDF as you want, but probably you should really have a look at Triplestore.

hope this helps ;)

greetz
back2dos

back2dos
@back2dos, thanks for your reply. I guess I had in mind something a little more robust than 'a bunch of XML files.' I've seen Triplestore and other engines like Seseme (Java-based) which can manage large and complex ontologies. I figured that ontologies in general were designed to grow incredibly large and still function so why not use them for a website? As for concurrency and scalability, I'm interested in exactly where RDF falls short. Maybe the storage engines out there are designed to mitigate those issues? The only drawback over SQL that I can see right now is raw speed.
Thomas
@Thomas: well, I am not that sure ontologies should grow that big actually. I think the whole idea of the WWW and RESTful systems in general is to be distributed. RDF has support for that. Actually HTML's and RDF's ability to reference other documents/data is what makes it so powerful. IMHO using RDF misses the point a little, if you don't reference other sources and other sources don't reference you. when you have all that stuff figured out, then swapping the storage engine should be the least of your concerns. ;)
back2dos
@back2dos: To me, what makes ontologies so powerful is the ability to add properties to objects as the dataset grows. So if I have several 'dog' objects in my system and one day I decide that all dogs belong to the 'mammal' object I can simply update the definition as opposed to adding tables and changing the db schema. I could see value in setting up a system like this w/o connecting to any outside sources. Although the concurrency and scalability issues you brought up make me question this.
Thomas
@Thomas: if that is your main concern, then you'll probably wanna take a look at MongoDB and CouchDB.
back2dos
@back2dos - nice and thorough answers. Didn't figure why you didn't get a +1 so I raised it. I also think that MongoB / CouchDB are good alternatives for the "associative array" type of problem @Thomas raised. And I second your explanation above, well said.
Etamar L.