The Digital Humanities Summer Institute (DHSI) is in a week. I'll be teaching a course on data discovery, management, and presentation using a platform I've been developing for the last couple years. This will be the first time other people will try to use the platform to build a project. I've been writing the workbook for the week-long course and I think we can do it.
For those who aren't familiar with what I call the Fabulator, I've developed a compute engine as an extension to Radiant, an open source content management system. The goal is to provide a platform for dynamic, data-driven digital humanities project sites that fill the role of the traditional monograph. These sites make a scholarly argument using interactive web applications instead of static text. The problem is that libraries don't want to touch these projects. No one wants to provide the long-term maintenance required to keep a web application running as the underlying languages and systems change.
The Fabulator system takes a different approach. Instead of building a project from a set of applications and content (e.g., text, images, or videos), it makes the application side of the project equal with the content. Now, everything is content and the framework is the player. This insulates the application side from the vagaries of the operating system and programming languages.
Ah, you say, but there's still a programming language in there somewhere! And yes, there is. But there are a few things about the language that make it workable. Like PDF and Postscript, it's domain specific and versioned. If the language undergoes significant changes, we attach a new version number and know which syntax or set of functions to expect. I'm designing the language to describe the problem instead of how to carry out the solution. We still have some work to do in this area, but it's shaping up well.
By reducing the interactive, algorithmic project site to a collection of pages in a content management system, we get closer to being able to treat the entire project in the same way as we treat PDFs. We have players/readers for PDFs. We don't update all the PDFs if there's a security hole or a change in languages. Instead, we update our readers. Even when we update our readers, though, we can still read the PDFs we could read before.
This move to seeing the underlying framework as just a player for the content that is the project site allows us to focus our long-term maintenance on the framework. If we have a large number of projects that all use the same framework or player, then our maintenance load is greatly reduced. Instead of maintaining code for a hundred projects, we support code for one.
Long term, I need to move from Radiant to a system that allows large-scale production and publication of digital projects. Once I return from DHSI, I'll be tackling a rewrite of the framework to create a publication workflow: begin with a work area for building the project, move through a submission and review process, and then to final publication. Hopefully we can create a publication environment for dynamic, interactive, data-driven and possibly crowd sourcing digital humanities projects.