The Fabulator extension for Radiant is forming up well. I’m planning on extracting the core engine from the extension and publishing it as a standalone Ruby library that can be plugged in to other systems. I’ll be working it in to the Writing and Learning Communities software as a way to build assignment modules.

If you’re familiar with MVC design, or at least with Ruby on Rails, then you’ve heard of CRUD: create, read, update, delete. These are the basic operations that are possible for data. There are various ways to do each of them, but these four are at the heart of any data-driven web application.

The Fabulator is a data-driven web application engine, so it makes sense that it should support the four CRUD operations. Since the database is essentially an RDF model, we need to map CRUD to RDF.

In a post from quite a while back, I talk about eXtensible State Machines, a way to reduce a web application to an XML document. The original implementation was a stand-alone web application environment/framework written in Perl. The web has evolved since that initial work. We now have web 2.0, Ruby on Rails, and content management systems that are easy to extend (e.g., Radiant).

Michael Godwin, General Counsel, Wikipedia Foundation, is on campus today visiting with various digital humanities groups and giving a talk titled, "After the Revolution." I've been thinking about the role of libraries and the Internet and academic responses to Wikipedia.

Since starting in the College of Liberal Arts in November, 2007, as the new lead developer for digital humanities, I've been putting together some design ideas and initial code towards a Digital Resources Workbench.

The NEH and other U.S. federal government agencies are pushing the digital humanities projects to result in something that can be shared. If this is an application that people can use, especially an application that resides on a central server, then the NEH is also wanting provisions for long-term maintenance. Ultimately, digital humanities projects should seek to be a resource that other scholarly work can build on. In this post, I want to explore what this might mean for web-based applications.

I was looking around the web for references about EAD, an XML vocabulary mentioned in a Digital Humanities Working Group meeting Monday. I could see cases where people would want to have documents marked up with both TEI and EAD.

I remember my early days of computing, setting the telephone headset on the earmuffs of the modem and dialing CompuServe's access number. The text would scroll across the screen almost too fast to read at 300 baud. The wealth of information available in the libraries and newsgroups was almost overwhelming at the time.

"What publishing can learn from the iPhone" points in a direction I've been thinking about for a while: we need to lessen our tie to notebooks and desktops when interacting with data.

Part of this equation is Google Gears which allows offline interaction with web applications. When I'm in the store and want to know if I have a particular book in my library, or what that wine was that I enjoyed the previous week but can't quite remember exactly which one it was, I want to have access to the information I need so I can make a well-informed decision. I want to be able to update my catalog at the point of purchase instead of trying to remember to do so later after I get home. Maybe I'm in another city, or traveling. The closer in time I can make all the tasks that go together, the more likely I am to do all of them. Managing data syncing and allowing client-side storage of data enables this.

Something that web developers have been looking for, but haven't been able to do, is now possible with Google Gears. Namely, accessing a file from JavaScript. It still isn't possible to access an arbitrary file, but with Gears, you can access the contents of a file that the user has selected in a file input element.