Rdflib and zope: how, why, what?¶

I got a question on how, why and what regarding my rdflib + zope work. I'm quoting my reply below, as it might also interest others. Well, why rdflib? Rdflib is pure python. You can use redland for instance, which has an python interface. But I wanted a product for zope which you can install without hassle. So: just dumping one product in one directory, restart, run. Not getting redland or java's Jena to run and configuring some connection to a zope frontend afterwards. Well, it works. Even the 0.02 version got the comment from somebody that "it worked out of the box". Which was the intention. (Not that it did do anything useful...)

So that would be goal #1: plug-and-play install.

A nice thing on rdflib (the 1.3.1 version) is that it contained a module that stores the rdflib data in a Zope object database! That made it really attractive.

The drawback of rdflib, to me, is that there isn't any OWL support yet. I'll probably put graphpath in front of rdflib. Graphpath is a query/reasoning python library which you plug into rdflib. They claim that it should be possible to handle most owl stuff.

Goal #2 would be that it supports what I want to do with it. What that is, exactly, isn't completely clear. What's unclear is mostly how much I want the rdflib-in-zope product to do and how much I want a wrapper around that product to do. So: do I use an rdflib product and put some customised code and some customised templates on top of it. Or do I write another product that just uses an rdflib store to store some data.

It'll probably be the second thing, but I'm still juggling it. The major challenge is DECOUPLING. How do I decouple the rdflib stuff from the actual applications that use it.

Part of the problem is the rdf data model. Zope is object-based, rdf is triple-based. And you cannot abstract everything away.

My usecase: having a couple of OWL-like ontologies that build on eachother. For the building&construction industry. So one or two base ontologies ("house", "doorframe", "fire resistance") and a set of ontologies that extend that base info into the details of the various domains. And on top of that a few applications that use it. (In my case a building specification application).

My approach: hacking from both ends. I'm now working on the ontology application, which 'll need some rdf support soon. And I'm working on the rdflib-in-zope (rope), seeing what that can do. Hopefully they will meet in the middle, but probably I'll at least get some idea of what to change in one or the other.

On code quality: I haven't done any unit tests, so I consider the code to be just a first try. It works, but that is all. Secondly, I've had to change rdflib a bit. It uses new-style (python 2.2+) classes, which zope's object database cannot handle. I had to take that all out and replace it with "old style" code. So it is in a way a fork of rdflib, which isn't my intention.

I'm going to europython in june, where I hope to get some better info on zope3. That'll have a fresher zope object database, which can handle the new-style classes. Coupled with a better support for "plain" python products, zope3 should make it possible to have just a small wrapper around rdflib.

So: the current version is a work-in-progress prototype. A proof of concept, awaiting a permanent zope3 version.

Another note: I've now implemented the user interface in plone. Using plone's archetype's UML generator tool. That makes for a snappy, good looking user interface, but it is an extra requirement. But I'm not going to make my own user interfaces when plone/archetypes can handle 75% of the work all right :-)

See the permanent status page