So I’m a Semantic Web researcher at UMD, when I’m not editing XML.com. Which means I spend a lot of time talking about RDF, OWL, formal semantics, as well as HTTP, content-negotiation, and RFCs. Recently, however, I’ve been talking to people on both sides of the aisle about Rails, Django, RDF, and SPARQL. Lemme explain…
The new wave of web frameworks, which usefully encompass web apps and web services, are what I like to call Kitchen Sink MVC frameworks. In other words, they’re based on the Model-View-Controller pattern (which is at least as old as Smalltalk), and they come laden with every feature but the kitchen sink. Add these two properties to the fact they are often developed in an Agile Language, and you end up with more productivity boosters than a case of Jolt.
Rails and Django are two of the hottest Kitchen Sink MVC frameworks around, and each trades on the strengths of its host language, Ruby and Python respectively.
But they have far more in common, ultimately, than it might seem, because, ultimately, both Rails and Django (Rails-Django from now on) are about turning relational database rows into programming language objects, and then doing the standard CRUD operations upon those objects. And whether you choose MySQL or PostgreSQL or something else, you’re still developing web apps and services backed by the relational model.
And that’s how Phillip Greenspun got to the point that anyone cares about his photography… But I digress. :>
My point here, and in the next weblog post or two, is to wonder aloud what Rails-Django would look like if instead of SQL and RDBMS… What if the “M” in MVC were composed of RDF, SPARQL, and a triplestore like Kowari?
Sure, Kowari is probably slower than MySQL, and you probably know SQL a lot better than SPARQL, but RDF is a schemaless data representation thingie. You can start with as little or as much schema as you want or need, and you can use the full expressive power of OWL (which is significantly more powerful than SQL’s DDL) when you need it.
This is a non-trivial undertaking, and there are lots of tradeoffs, but it’s an interesting space that I hope I’ll have to more to say about soon. For now, I’ll just point you to Sparta, which is an RDF databinding library for Python. It or something like it would play an active role in a Semantic Kitchen Sink MVC framework.
Good idea
Sounds like a neat idea. What I'd really like to see from something like this:
1) Have the framework use multiple types of repository in a sort of 'best of breeds' approach; a triples/RDF store for metadata, and an XML database for the xml-y data (e.g. XHTML or Docbook, or whatever) - then have them hook into each other via the app/framework logic.
2) Ideally the framework would be able to expose the underlying repository through some kind of (REST, I guess) API/Service, so that as more people implement the framewok in their localy environments, the opportunity for each of the repositories to hook into triples in another (remote) one becomes a possibility...
been talking about this for awhile
Deep Integration of Ruby with Semantic Web Technologies
http://jroller.com/page/obie/20050726
ActiveOntology Update
http://jroller.com/page/obie?entry=activeontology_update
Semantic Web Meet Ruby on Rails
http://jroller.com/page/obie/20050614
Don't Forget The Other Guy!
Sign. Rails. Django. Rails. Django. Don't forget the other perl MVC framework that's just as good IMHO: Catalyst (http://catalyst.perl.org/) .
Expediency
I think they use relational databases because it's very expedient. No other persistence mechanisms I know of offer the same set of features -- transparency, robustness, strong admin tools, fast querying. And all of these are highly predictable, which is extremely important; in part they are predictable because people have a lot of experience using these tools, in part they are predictable simply because relational databases are mature and powerful and simple (especially when you use them like Rails and Django do, ignoring most more sophisticated RDBMS features).
You could use other datastores, but you'll lose a lot of focus as a result, where Rails and Django are very good at focusing people on the UI. It's not inevitable that you'll lose focus, it's simply because those other datastores aren't as well understood, on an individual or collective level, and you have to pay them more attention as a result.
I know it's a rather late comment, but have a look at http://activerdf.m3pe.org. It does exactly that: putting RDF on Rails.