Mark's web presence nothing very exciting, just some guy's web presence

Note: This article is based on a posting I made at digitizationblog on 2005-10-11. I will update this document as my investigations progress.

Why Drupal?

I use Drupal as the content management system (CMS) for a course I am currently teaching. Drupal is a general CMS in that it powers blogs, community websites, and general websites equally well. Some examples of Drupal sites include the JPEG 2000 in Libraries and Archives site and the journal Copyright's community site. As the student who started the Drupal thread on the course website pointed out, Ann Arbor District Library uses Drupal to power its website.

One of Drupal's virtues is that it uses a robust "module" architecture, which allows developers to extend its functionality by writing code that pretty much just drops into the core application to do a specific task. Drupal is not alone in this ability -- WordPress uses plugins, and the Open Journal Systems application is moving rapidly in that direction. However, Drupal's is probably one of the most mature module architectures out there. Morbus Iff has even written a Drupal module that uses FRBR to model bibliographic records for personal book, music, and video collections. If the existence of niche modules is a sign of a mature CMS, then this one means Drupal is mature.

The most useful module I've deployed on my course site is flexinode, which allows users to create new "content types" to add to Drupal sites. flexinode allows you to create web forms that represent your content; you can add text fields, drop-down lists, image fields, color pickers and other interactive elements, and media-specifc elements such as upload tools and links to mp3 files. In my course site, I have used this module to create "reading" and "collection" content types, both of which are basically simplified bibliographic formats.

Drupal as library CMS

While participating in the discussion thread mentioned in the first paragraph, I realized that flexinode could be used to create a simple content type that would illustrate some of the digital library CMS concepts we were discussing (such as flexible, robust metadata handling; tools to process and display various types of content including still images, complex objects like scanned books, etc.; user-friendly but function-rich search and display; and collection maintenance and management tools). I was impressed to find that flexinode allowed me to add multiple form fields with the same name (or as librarians know them, repeating fields), flat and hierarchical taxonomies (a.k.a. authority lists), check boxes and other useful widgets to customize the input and display of my data. It also provided, out of the box (although not very well documented), fairly decent search and browse functions. After a couple of days of intermittent poking around, I had put together a prototype digital library CMS using nothing but flexinode's existing functionality.

The prototype is not intended to compete with Fedora, Greenstone, Streetprint, CONTENTdm, or any other dedicated digital collection management system. I put it together to explore the limits of flexinode, to see what functionality it could not deliver that we normally associate with digital library CMSs. Compared to Streetprint, for example, which has quite nice page-turning mechanisms, this prototype can only handle single-file digital objects. The prototype does not have the flexibility of Fedora, or the sophisticated content production tools or powerful fulltext retrieval engine of Greenstone (although there is a Drupal module that lets you integrate swish-e indexing). The prototype has no digital asset management or preservation functionality (which DSpace does have to a certain degree), and it lacks batch ingest tools and the ability to export METS records, features that Fedora, DSpace, and CONTENTdm all have.

Despite what Drupal/flexinode cannot do that we require in digital library CMSs, the screen captures below are intended to illustrate that it is possible to create a full set of suprisingly functional add/update/delete and search/display tools very easily using Drupal and flexinode. The relative importance of having the capabilites of Fedora or Greenstone might decrease for some people given that by using Drupal to organize and deliver digital library collections they will automatically inherit the other functionality that Drupal offers, including a flexible website publishing framework, full user management tools, blogging tools, user comment/review capabilities, RSS feeds and all the aggregated functionality that other Drupal modules offer. In other words, you get a lot.

So, here's what flexinode offers you, out of the box:

Search form: All the text fields in a flexinode content type are searched at the same time using the single text field provided in the search form.

Results list: Users can sort the results list by clicking on column headers, and result lists are fully paged ("Next", "Previous").

Display of an image record: It is possible to customize flexinode's "record display" using Drupal's template system. The example shown here has not been customized.

Tool to add an image record: This form looks busier than it has to because in my course Drupal I have also enabled a module that allows users to schedule when a blog entry, page, etc. appears and disappears.

I want more

I plan on exploring further the potential for using flexinode and other Drupal modules to build a digital library CMS. I'd be interested in seeing how complex, multipart objects could be handled, for example, and how Drupal's user management system could be used to create workflows for distributed collection maintenance. The upcoming version of flexinode will have "advanced" search tools that allow you to easily create a search form that contains fields and options matching those you define in your add/edit forms. And since Drupal uses a standard relational database back end, it would be fairly easy to create a batch ingest script to populate the Drupal database with prepared metadata and content files (in fact, there are already a couple of generic import-export modules), and to create a METS export tool if desired, provided Drupal could be configured to manage complex METS data associated with digital library objects. I bet it could.